Over the Reich - Creation Thread

[Prof. Garfield]

As to the ports, the only thing I've thought of since our last discussion is that the Allies only start the scenario with 1 army group, and the reason for this is to prevent them from making too early of a landing (while still "theoretically" allowing them to land at any time. I'm a little concerned that if we give them a bonus of 3 battle groups if they capture a port intact, they might decide that they should rush a landing as soon as they have local air superiority. I'm not sure how that would play out as a strategy.

I almost think it's OK because if they get thrown into the sea they lose the game and the Germans start with so many more battle groups, but I wanted your thoughts on if there should be a "point delay" for this? Such as they only get the full three if they have so many points? Maybe they get 1 bonus BG for every 250 points up to a maximum of 750?

That's a good point about a rush to invade giving a big bonus, but I am also inclined to agree that the German starting advantage in troops is large enough that a rush is not to be undertaken lightly. Since being thrown back into the sea is a loss for the allies, we don't have to worry about the allies mounting a raid to achieve the bonus and then retreating back across the Channel.

I don't think that an early invasion would be overpowered for the Allies compared to a later invasion. However, it might make the Allies try to succeed with 4 or 5 Battle Groups and switch to tactical bombers over strategic bombers (instead of trying to get more reinforcements). That might make for an interesting game, but it would detract from the strategic bombing campaign that we are trying to model.

Maybe we should give the choice to the players? On the first turn, each player is presented with a checkbox list of possible game parameters that can be turned on or off. If the both agree on the parameter set, it is stored in the state table, and governs the rest of the game.

Edit--I think the freight trains that are spawning randomly in France for Germany are selecting the nearest city as a home city. This is causing issues because Lannes AF for example can't support them. Can we change their spawn to "none?"

That can certainly be done. I'll do it when I make some other changes to the events.

 

[JPetroski]

I don't think that an early invasion would be overpowered for the Allies compared to a later invasion. However, it might make the Allies try to succeed with 4 or 5 Battle Groups and switch to tactical bombers over strategic bombers (instead of trying to get more reinforcements). That might make for an interesting game, but it would detract from the strategic bombing campaign that we are trying to model.

Maybe we should give the choice to the players? On the first turn, each player is presented with a checkbox list of possible game parameters that can be turned on or off. If the both agree on the parameter set, it is stored in the state table, and governs the rest of the game.

Maybe we should just leave it simple and open ended. For this to be re-playable, you should be able to try out new strategies.

I am pretty pleased with how my single playtest is going so far. While I'm not exactly "min-maxing" or fretting over everything as I might in competition, I am trying to play reasonably well. I will tell you, the payload feature just completely changes everything. I think it's a great system and I'm so happy you figured out a way for planes to carry "ammo." It was a genius yet simple solution.

I was worried because I thought the wolfpacks were too outmatched as the Sunderlands do tend to kill them, but then I remembered that there are payload considerations. Early in the game, the Allies really don't have the resources to protect all their convoys (though they can do a fair job of protecting one). The convoys do take a bit to kill (2x Fw200 and 1x wolfpack haven't taken one out in my playtest), but even just being wounded is a big deal, because it means that resources will arrive later. I'm interested to see how this all plays out in terms of balance, especially since I've reduced the game length from 175 to 125 turns (aiming for about a 4-month game), but we'll see.

The payload also offers different strategies for dealing with bombers. You no longer "have" to chase the bomber stream and get totally out of place because you can plan to intercept them on the way out. I think inbound and outbound escorts are going to be important and the whole game should just take on a new feel.

I have noticed a few things that we might want to change:

1. I believe you tried to convince me at one point to add a "quality of life" mechanism to radar where at the stroke of a button, each radar set fired. I think this is a good idea, but I'd like it to have a pop up box that says something along the lines of, "yes, deploy the radar detection system," or "no, I have radar sets I'd like to move this turn." In other words, I think it's a good idea but it shouldn't be automatic each turn because if it is, people can't deploy radar.

2. I doubt there's a way to do this with the flak installations too so as to "sleep" all the ones that don't have detect a nearby raid, but I could see this becoming a new bottleneck for those who wish to play their best.

3. You had mentioned trying to come up with some way to incentivise the German to keep army groups in the east. What about tying it to the Red Army event and if there aren't enough units in the east when the Red Army arrives, the Red Army arrives in significantly greater strength? Or even earlier?

 

[Prof. Garfield]

1. I believe you tried to convince me at one point to add a "quality of life" mechanism to radar where at the stroke of a button, each radar set fired. I think this is a good idea, but I'd like it to have a pop up box that says something along the lines of, "yes, deploy the radar detection system," or "no, I have radar sets I'd like to move this turn." In other words, I think it's a good idea but it shouldn't be automatic each turn because if it is, people can't deploy radar.

Sure, this can be done. Probably with 'backspace' on a Radar Station (I don't think backspace does anything there). I'm inclined to think planes with radar should be activated manually.

2. I doubt there's a way to do this with the flak installations too so as to "sleep" all the ones that don't have detect a nearby raid, but I could see this becoming a new bottleneck for those who wish to play their best.

This shouldn't be too hard. After production just go through the list of units (or, maybe use the Wilde Sau key ('u' I think?) to activate the option). Any flak that does not have an enemy unit in range gets its order set to sleep, and the ones that do have nearby enemy units have their orders cleared. Only trouble is what to do with fortified flak. Maybe make flak fortify instantly via event, so that clearing the fortify order isn't detrimental. Another problem is that you might forget to move flak units destined for other locations.

3. You had mentioned trying to come up with some way to incentivise the German to keep army groups in the east. What about tying it to the Red Army event and if there aren't enough units in the east when the Red Army arrives, the Red Army arrives in significantly greater strength? Or even earlier?

I think making the Red Army arrive earlier is probably the best option. That way, troops are stationed in the East unless there is a pressing need for them elsewhere, but if they are needed elsewhere, the front doesn't immediately collapse or anything.

I am pretty pleased with how my single playtest is going so far. While I'm not exactly "min-maxing" or fretting over everything as I might in competition, I am trying to play reasonably well. I will tell you, the payload feature just completely changes everything. I think it's a great system and I'm so happy you figured out a way for planes to carry "ammo." It was a genius yet simple solution.

Are you planning on altering the number of bombs generated by bombers? If so, it might make sense to use "threshold tables" (part of my general library and explained in my 6th lua lesson) over the existing system of defining payload. Let me know if you want to make those changes (or, maybe, even use the munitions library I wrote), and I'll make appropriate alterations to the events.

A few things I've thought of that I want your input for:

I can do an onActivation trigger that reduces the defence of army groups to 0 if a munition is activated next to an army group/depleted army group and all adjacent army groups are at 10 hp or less (and resets it in all other situations). My only concern is that this leaves the possibility of exploiting the activate unit from inside a city bug to do stuff while the army groups have 0 defence.

Perhaps we should just move Army Groups off of airfields (in the same way we move planes off strategic units). I was originally thinking that doing so would make the planes vulnerable to ground attack from enemy army groups, and that this is undesirable since army groups should be able to defend the airfields. However, this may be the wrong way to think about it. If an army group is necessary to defend an airfield from ground attack, that means that the airfield is either very close to the front line or it has already been surrounded by the enemy. A surrounded airfield can't get fuel to operate, and it would seem to me that operating an airfield in or near a combat zone wouldn't be a very good idea anyway, even if the runways themselves haven't technically been overrun just yet.

Are there examples of significant airfields being operated close to enemy lines? Maybe the Stalingrad airlift was one? But that seems like a bit of an extraordinary circumstance.

The battle groups have 8 movement points, and that is cut to 2 on the turn they land on the beach. Most planes can go at least twice this distance in a turn, so even close support aircraft should be able to operate out of direct danger.

Maybe we should introduce an "obstacle" unit (perhaps the construction teams can create it with 'backspace'), a unit that is immune to munition damage and very weak, that simply serves to delay advancing armies. That way, a player could make sure that key areas can't be overrun before they have time to either retreat or bring in reinforcements. We may have to think about the mechanics a little bit. If it is immune to munitions, then ringing an airfield would render it immune to raids.

 

[JPetroski]

Sure, this can be done. Probably with 'backspace' on a Radar Station (I don't think backspace does anything there). I'm inclined to think planes with radar should be activated manually.

That would be perfect. I agree that planes should only activate manually.

This shouldn't be too hard. After production just go through the list of units (or, maybe use the Wilde Sau key ('u' I think?) to activate the option). Any flak that does not have an enemy unit in range gets its order set to sleep, and the ones that do have nearby enemy units have their orders cleared. Only trouble is what to do with fortified flak. Maybe make flak fortify instantly via event, so that clearing the fortify order isn't detrimental. Another problem is that you might forget to move flak units destined for other locations.

Couldn't we just have them all fortify instead of sleep if they aren't in range? The player would have to remember to grab one and activate it and then press u, but it would accomplish the same thing as placing them on sleep. We could have a similar "are you sure?" dialogue box that lets players know that if they "prepare flak barrages," they're going to need to check any flak that are in transit to make sure they unfortify them and move them?

I think making the Red Army arrive earlier is probably the best option. That way, troops are stationed in the East unless there is a pressing need for them elsewhere, but if they are needed elsewhere, the front doesn't immediately collapse or anything.

Right now there are 7 depleted Battle Groups east of Berlin, but of course this could be expanded or changed. There are also 2 full battle groups east of Hamburg. Even though it is a little weird to have most of the forces in the west, it isn't that weird considering the map only extends as east as Poland, and the Germans are pushing towards Stalingrad as the scenario starts. This might not even be that big of an issue, frankly. Maybe we don't need this after all?

Remember, the point of having a lot of troops in the west is to dissuade the Allies from doing something gamey and immediately invading (as is the point of not letting army groups be destroyed completely from the air - the Allies really need to build up some strength to succeed). But on the other hand if the Germans put everything in France the Allies could always sneak around and land in north Germany too, especially now that the faster Task Groups are the transports.

Looking at the map, I'm inclined to say it might not be an issue.

Are you planning on altering the number of bombs generated by bombers? If so, it might make sense to use "threshold tables" (part of my general library and explained in my 6th lua lesson) over the existing system of defining payload. Let me know if you want to make those changes (or, maybe, even use the munitions library I wrote), and I'll make appropriate alterations to the events.

I'm pretty satisfied with the damage to payload balance in the scenario. I didn't think that was an issue in my playtest with McMonkey. I was more concerned that my bombers could just loiter forever which wasn't really fair to him and made him chase them around and totally get out of position. There also wasn't any point to bringing them home as I could build replacements faster than I could get them home, and I had a chance to destroy more targets if they were in the air. I think the bomb load is fine, though we'll see.

Perhaps we should just move Army Groups off of airfields (in the same way we move planes off strategic units). I was originally thinking that doing so would make the planes vulnerable to ground attack from enemy army groups, and that this is undesirable since army groups should be able to defend the airfields. However, this may be the wrong way to think about it. If an army group is necessary to defend an airfield from ground attack, that means that the airfield is either very close to the front line or it has already been surrounded by the enemy. A surrounded airfield can't get fuel to operate, and it would seem to me that operating an airfield in or near a combat zone wouldn't be a very good idea anyway, even if the runways themselves haven't technically been overrun just yet.

This is probably the best option. If an army attacks the airfield instead of the nearby army group, they expose themselves to attack from the army group (I think with the ranged barrage attack, the person who fires first is going to have the advantage - it would seem like a poor choice to abandon that in favor of attacking planes that can only weaken you but not destroy you.

Are there examples of significant airfields being operated close to enemy lines? Maybe the Stalingrad airlift was one? But that seems like a bit of an extraordinary circumstance.

Henderson Field on Guadalcanal and Iwo Jima spring to mind. There may be others. It certainly wasn't a fun place to take off or try to land.

Maybe we should introduce an "obstacle" unit (perhaps the construction teams can create it with 'backspace'), a unit that is immune to munition damage and very weak, that simply serves to delay advancing armies. That way, a player could make sure that key areas can't be overrun before they have time to either retreat or bring in reinforcements. We may have to think about the mechanics a little bit. If it is immune to munitions, then ringing an airfield would render it immune to raids.

Could we make it so that the 1,000lb munitions can destroy it? Only fighter-bombers have that now, and they have a short range and can't hit strat targets so probably won't be built in huge numbers.

 

[Prof. Garfield]

TO DO List:

Battle Group scouting.

Details needed:
Rail Redeployment of battle groups and flak
Sabotage port functionality. For my purposes, all that is needed is the building that "performs" the sabotage.
Bonus for allies having a functioning military port on the continent.

Completed:
Make trains spawning in France be homed to NONE.
Use all radar at once function.
Fortify flak not in range of aircraft, clear orders of flak with target in range. Ignore flak with goto command.
Move battle groups off airfields (but not cities) when munitions are generated in an adjacent square.
All damaged bombers veteran.
Allow airfields in South France
Fix carriers
Hurricane and Stuka automatic home when on carrier.

Other Stuff To discuss:
Obstacles

Could we make it so that the 1,000lb munitions can destroy it? Only fighter-bombers have that now, and they have a short range and can't hit strat targets so probably won't be built in huge numbers.

If a few fighter-bombers can clear a path for the advancing unit, that kind of defeats the purpose I was thinking of. If the fighter-bomber is useful to speed up the advance of infantry at a key moment, then the player will have some fighter-bombers in reserve to take advantage. My concern is that 8 movement and relatively few units might allow for engagements that wouldn't happen if units were slower or there were more of them. For example, the allies spot a single German battle group, and move 3 of their own battle groups 8 squares away. An 8x8 square is fairly large, so the Germans miss the buildup in the one turn window that they have to see it. Next turn, 3 battle groups appear from the mist and bombard and defeat the Germans. If movement were slower, there would have been more opportunity to spot the danger and retreat. Obstacles might slow down the advance or at least force the attacker to be a little closer before rushing in for the attack.

Perhaps obstacles are not the answer to this danger (which might not even be significant). Maybe there simply has to be reconnaissance functionality, that is Radar but only showing Battle Groups. A battle group might automatically "see" other battle groups within 10 squares and thereby realize that an attack, reinforce, or retreat decision might be in order.

If obstacles can be placed side by side, they would restrict air movement. If they're forced to have gaps, the army groups could use airplanes to navigate between them anyway.

"Trainlift"

I've been thinking that maybe we need to be able to transport units via "train" using mechanics similar to airlifting. Flak is rather slow to redeploy, but maybe we could move it by "train," but only if the rail network is intact between the two cities. This would take a moderate amount of effort to implement, but I thought I would put it out there.

 

[JPetroski]

Sabotage port functionality. For my purposes, all that is needed is the building that "performs" the sabotage.
Bonus for allies having a functioning military port on the continent.

We'll use coastal fortress (28). There's no negative side effect because the task groups are 0 attack 'k' units, so the city won't get any actual defensive bonus from having it. While the game should only allow it to be built by water, I need it refined so it's only buildable in cities that have a port, too, in case someone builds an airfield near water.

Edit - I've added this to the game. I've made it cost 100 fuel per turn to prevent the Germans from spamming it. I've made it so it cannot be sold, but is automatically destroyed when the city is captured (note that ports too automatically are destroyed when a city is captured - hopefully that doesn't cause issues with identifying when the Allies have captured one).

Perhaps obstacles are not the answer to this danger (which might not even be significant). Maybe there simply has to be reconnaissance functionality, that is Radar but only showing Battle Groups. A battle group might automatically "see" other battle groups within 10 squares and thereby realize that an attack, reinforce, or retreat decision might be in order.

I would certainly rather save the unit slot for some special Luftwaffe treats. Maybe "onActivate" will have a pop up "enemy battle groups are approaching! They are marked with the "radar" icon. I think 10 spaces is reasonable

"Trainlift"

I've been thinking that maybe we need to be able to transport units via "train" using mechanics similar to airlifting. Flak is rather slow to redeploy, but maybe we could move it by "train," but only if the rail network is intact between the two cities. This would take a moderate amount of effort to implement, but I thought I would put it out there.

Great minds... I was actually thinking of something similar but said to myself, "Ah, I don't want to start adding to things." Of course you are never one not to keep adding good ideas

One game I've played as inspiration for this is Bombing the Reich. In it, there is an option for "strategic redeployment" where you can quickly move flak batteries. I think it's a great idea to have it function here and I was thinking of it working as so:

Flak presses a button to initiate strategic redeployment window. There are two potential pop ups:
"Would you like to strategically redeploy this flak unit by our rail system at a cost of 100 fuel?" (Yes, Let Me Reconsider)
"We cannot strategically redeploy this unit as our rail system in the area is compromised."

The mechanism checks for locations that the deployment can occur to:
-It takes a grid of maybe 20x20
-It returns the coordinates of terrain squares within that grid that are types 6,7, or 8 (refinery, installation, industry) which the player can scroll through and select which one they want the unit to deploy to.
(Even though flak "can" fire from urban terrain, there is so much of it that I'd recommend only allowing strategic redeployment to 6,7,8).
-The return takes into consideration water and won't return if there is no land path, period, to the target square (to prevent people from redeploying to England and invading that way).
-Ideally, the return would also take into consideration squares that have an enemy city within 5 or so squares, and kick out these as options too (enemies too close).

To keep things simple for the player to check for (and for us to code):
-This can only be done from within a city
-That city must have the railyards improvement (25)
-So long as that city has railyards, a unit can strategically redeploy from it
**I think it would be too complicated for too little gain to check if other cities nearby also have railyards. It would be harder to code, I imagine, and also importantly, harder for players to keep track of.

I'd suggest this should be a Germany-only option for a few reasons:
1. They're less likely to be able to exploit this in a meaningful way;
2. The Allies can prevent the Germans from going behind their lines by making a concerted effort against the railyards in France, which was a *major* objective prior to D-Day that has no real benefit in the scenario currently (for this reason I'd also argue that battle groups should be able to strategically redeploy as well).
3. The German player is the one who will have, by far, the most flak to move.

 

[JPetroski]

My playtest led me to have some concerns about the resilience of the B-17s and other aircraft now that vet status transfers to the munitions. I have found that veteran status is critical in this scenario and so there'll be a great reason for the Germans to build and maintain the expensive flight schools. On further testing, I think it is OK, but we might want to make all "damaged bombers" start as vets.

I just tested the 190A5 (which fires medium guns) vs. the B-17F (the first U.S. bomber). My methodology was to see how many "one attack kills" the 190s could achieve. Bear in mind that a 190A5 can attack up to three times per turn assuming they have MP left, but I was concerned with the one-shot kills that I was seeing routinely in the playtest and wanted to see how they'd play out over time.

Ace 190A5 vs. green B-17F: 60% of bombers destroyed on the first pass (this isn't actually that far off from real life chances - I've read that about 50% of the crew force was killed in the USAAF 8th AF and Bomber Command).
Ace 190A5 vs. Ace B-17F: 15% of bombers destroyed on the first pass
green 190A5 vs. green B-17F: 5% of bombers destroyed on the first pass
green 190A5 vs. Ace B-17F: 0% of bombers destroyed on the first pass (I tried pressing to a full three attacks and found that about 30% of the bombers fell to 3 shots or less).

As you can see, if an Ace 190 group encounters a green B-17 group, they can make short work of them.

I'm thinking that we should make all damaged bombers (meaning the ones that are on fire) ace units and then the player would want to use the veterancy swap to get their crews into fresh planes. I think this makes much more sense than just disbanding them to build new stuff. The crews were what was important - most of the bombers were write offs. If you implement this in the events, I'll reduce the shield price of the damaged bombers so they aren't that useful for disbanding and should be used to swap out crews instead. Once the Allies can build up a veteran air force (and start killing the veteran Luftwaffe pilots), they'll have a much better chance.

This also would make the burning bombers much more important targets for the Luftwaffe because you really don't want the 8th AF gaining experience or you're going to have a much tougher time.

 

[JPetroski]

Further testing reveals some issues we need to address in events:

*Need to remove The high command of the Luftwaffe has rejected a defense in depth - no need for it now that the trains spawn randomly. The Germans should be able to build airfields in France if they want them (with munitions, it's really important to have spare airfields if you want to have any bomber force).

Carriers - the new BotA is a lot of fun, but I've discovered a quirk that hadn't come up previously:

*With the way the carriers work, you can't attack them with anything except fighters. An annoying side effect I believe of the event you built to restrict only certain units to using them. Is it possible for air units on a carrier to lose air designator and change to a land unit when munitions called up next to carrier the carrier? As it stands, they are immune from attack by Task Forces, U-Boats, and bombers!

*Can a Hurricane or Ju87 Stuka that activates from the same square as a carrier have it's homecity set to something so it can rearm? I would suggest it searches for the same ports as the reinforcements and if all four of those ports are captured, it can't rearm. That or simply London/Berlin. We only want this for Hurricanes and Stukas so that other units don't exploit this.

 

[Prof. Garfield]

e'll use coastal fortress (28). There's no negative side effect because the task groups are 0 attack 'k' units, so the city won't get any actual defensive bonus from having it. While the game should only allow it to be built by water, I need it refined so it's only buildable in cities that have a port, too, in case someone builds an airfield near water.

Edit - I've added this to the game. I've made it cost 100 fuel per turn to prevent the Germans from spamming it. I've made it so it cannot be sold, but is automatically destroyed when the city is captured (note that ports too automatically are destroyed when a city is captured - hopefully that doesn't cause issues with identifying when the Allies have captured one).

Maybe we're thinking of a slightly different way of doing this.

I was thinking that they build the "sabotage port" building, and it has two effects. 1. It immediately destroys the Military Port in the city if there is one. 2. It prevents a military port from being built in the city. There doesn't seem to be a need to have this cost tons of fuel each turn. Once the port is destroyed, it is destroyed, and the Germans no longer gain any advantage from a port (or Allies receive detriment).

My line of reasoning is that in this scenario, a port "destroyed" by bombing is really just severely damaged but can be brought back to fighting capacity in relatively short order. If a demolition team is sent in to demolish it, it is not going to be usable for months and so can't act as a significant supply centre.

I would certainly rather save the unit slot for some special Luftwaffe treats. Maybe "onActivate" will have a pop up "enemy battle groups are approaching! They are marked with the "radar" icon. I think 10 spaces is reasonable

I don't really want to use onActivate for this, since that excludes fortified battle groups from scouting. I think it's best to just reveal (by creating a camera unit) any battle groups within 10 squares of your own battle group in the after production event. Of course, scouting across the channel won't be allowed. This would mean that battle groups can hide in cities and airbases. Cities are reasonable, and I'm willing to live with hiding in airbases (unless we make the scouting event move the unit out of the airbase, like we'll do with air attack).

Maybe one of those Luftwaffe treats could be a helicopter .

Great minds... I was actually thinking of something similar but said to myself, "Ah, I don't want to start adding to things." Of course you are never one not to keep adding good ideas

"I don't want to add more stuff" was also a reason why I didn't mention it before.

Flak presses a button to initiate strategic redeployment window. There are two potential pop ups:
"Would you like to strategically redeploy this flak unit by our rail system at a cost of 100 fuel?" (Yes, Let Me Reconsider)
"We cannot strategically redeploy this unit as our rail system in the area is compromised."

The mechanism checks for locations that the deployment can occur to:
-It takes a grid of maybe 20x20
-It returns the coordinates of terrain squares within that grid that are types 6,7, or 8 (refinery, installation, industry) which the player can scroll through and select which one they want the unit to deploy to.
(Even though flak "can" fire from urban terrain, there is so much of it that I'd recommend only allowing strategic redeployment to 6,7,8).
-The return takes into consideration water and won't return if there is no land path, period, to the target square (to prevent people from redeploying to England and invading that way).
-Ideally, the return would also take into consideration squares that have an enemy city within 5 or so squares, and kick out these as options too (enemies too close).

To keep things simple for the player to check for (and for us to code):
-This can only be done from within a city
-That city must have the railyards improvement (25)
-So long as that city has railyards, a unit can strategically redeploy from it
**I think it would be too complicated for too little gain to check if other cities nearby also have railyards. It would be harder to code, I imagine, and also importantly, harder for players to keep track of.

I'd suggest this should be a Germany-only option for a few reasons:
1. They're less likely to be able to exploit this in a meaningful way;
2. The Allies can prevent the Germans from going behind their lines by making a concerted effort against the railyards in France, which was a *major* objective prior to D-Day that has no real benefit in the scenario currently (for this reason I'd also argue that battle groups should be able to strategically redeploy as well).
3. The German player is the one who will have, by far, the most flak to move.

We might be able to use Knighttime's supply module to check if a rail link exists between a proposed destination and the redeploying unit. If we can, then I'd simply suggest moving units between cities, rather than trying to remember the exact coordinates of the installation tile you want to move to.

I'll remove the manual retreat option of battle groups, and give them strategic redeployment via railroad instead.

Maybe the Allied port bonus should be the ability to use strategic redeployment on the continent. That is, a proper port facility can unload trains and fuel in large enough quantities to use the rail network effectively.

On further testing, I think it is OK, but we might want to make all "damaged bombers" start as vets.

I'm thinking that we should make all damaged bombers (meaning the ones that are on fire) ace units and then the player would want to use the veterancy swap to get their crews into fresh planes. I think this makes much more sense than just disbanding them to build new stuff. The crews were what was important - most of the bombers were write offs. If you implement this in the events, I'll reduce the shield price of the damaged bombers so they aren't that useful for disbanding and should be used to swap out crews instead. Once the Allies can build up a veteran air force (and start killing the veteran Luftwaffe pilots), they'll have a much better chance.

Sure, I can make the damaged bombers gain veteran status.

*Need to remove The high command of the Luftwaffe has rejected a defense in depth - no need for it now that the trains spawn randomly. The Germans should be able to build airfields in France if they want them (with munitions, it's really important to have spare airfields if you want to have any bomber force).

Yes, I'll put that on the list. Maybe we should reduce the free shields the Allies get per airfield, since location of unit support is now important.

*With the way the carriers work, you can't attack them with anything except fighters. An annoying side effect I believe of the event you built to restrict only certain units to using them. Is it possible for air units on a carrier to lose air designator and change to a land unit when munitions called up next to carrier the carrier? As it stands, they are immune from attack by Task Forces, U-Boats, and bombers!

The easiest solution is probably to make the carrier have the "carrier" attribute when munitions are active. I don't think there is much of an exploit available here, since munitions are deleted every turn. However, this side effect is something to think about if I offer a "carrier" module to the "general public."

*Can a Hurricane or Ju87 Stuka that activates from the same square as a carrier have it's homecity set to something so it can rearm? I would suggest it searches for the same ports as the reinforcements and if all four of those ports are captured, it can't rearm. That or simply London/Berlin. We only want this for Hurricanes and Stukas so that other units don't exploit this.

This can be done. I'll probably just do London and Berlin. Or, maybe, whatever the home city is of the carrier it is landed on.

 

[JPetroski]

was thinking that they build the "sabotage port" building, and it has two effects. 1. It immediately destroys the Military Port in the city if there is one. 2. It prevents a military port from being built in the city. There doesn't seem to be a need to have this cost tons of fuel each turn. Once the port is destroyed, it is destroyed, and the Germans no longer gain any advantage from a port (or Allies receive detriment).

I just don't know that the Germans get enough of a benefit from the port to not destroy every one on the channel as soon as an invasion seems plausible. That's why I thought having a fuel detriment would at least make you try and time it somewhat. 100 might be way too high. I'd have to go back through McMonkey's saves and figure out about where he was financially at certain points where D-Day seems likely.

On the topic of ports, I have noticed on my playtest that many of the respawning u-boats spawn east of the channel. I think it'll be challenging for them to break through it consistently enough to keep the BotA active, but we'll see.

I don't really want to use onActivate for this, since that excludes fortified battle groups from scouting. I think it's best to just reveal (by creating a camera unit) any battle groups within 10 squares of your own battle group in the after production event. Of course, scouting across the channel won't be allowed. This would mean that battle groups can hide in cities and airbases. Cities are reasonable, and I'm willing to live with hiding in airbases (unless we make the scouting event move the unit out of the airbase, like we'll do with air attack).

Maybe one of those Luftwaffe treats could be a helicopter .

What about onActivate for the photo unit, which is an actual unit? Or maybe we're saying the same thing? It's pretty easy to add in low-alt-only "scout" units like the helicoptor (assuming I can find graphics for it). I could make the helicopter pretty cheap for the Germans and then the Allies would need to use their more expensive mosquito on the lower map. The "scout" should only work from the map the camera deploys on, I'd say.

We might be able to use Knighttime's supply module to check if a rail link exists between a proposed destination and the redeploying unit. If we can, then I'd simply suggest moving units between cities, rather than trying to remember the exact coordinates of the installation tile you want to move to.

I'll remove the manual retreat option of battle groups, and give them strategic redeployment via railroad instead.

Maybe the Allied port bonus should be the ability to use strategic redeployment on the continent. That is, a proper port facility can unload trains and fuel in large enough quantities to use the rail network effectively.

If it can easily be implemented then I think it is OK but if it is going to pull you too far into the rabbit hole I don't think it's "urgent." There's going to be a few things that come up during playtests that need to be fixed more than this. Having that supply lines be one of the new things Burma (presumably) introduces into the world wouldn't be a bad thing either. OTR is already quite complex. City to city redeployment is definitely easier to grasp than the manual retreat though - it's basically just an airlift that has unique considerations compliments of lua.

Yes, I'll put that on the list. Maybe we should reduce the free shields the Allies get per airfield, since location of unit support is now important.

I reduced it from 8 to 4. I'll do another test run.

The easiest solution is probably to make the carrier have the "carrier" attribute when munitions are active. I don't think there is much of an exploit available here, since munitions are deleted every turn. However, this side effect is something to think about if I offer a "carrier" module to the "general public."

That would work fine.

This can be done. I'll probably just do London and Berlin. Or, maybe, whatever the home city is of the carrier it is landed on.

If either is just as easy I'd prefer the home city of the carrier because if that city is lost the carrier sinks and the planes need to fly away to either another airbase or carrier.

There's also some general clean up we need to do. I noticed the following but there will be others now that we've gone full-blown sandbox on D-Day:

*Need to remove German victory text at point 500
*Make sure we've removed the Overlord event (1,000 points gives technology)

 

[JPetroski]

I've been tweaking stuff in the main game. I removed a number of land units for both parties, especially light flak. I found that the Germans were able to garrison pretty much every radar set and airfield with light flak, and I wanted to make them choose. To help compensate, I've given the Germans several more airfields.

I also bolstered the RAF Bomber Command so they start with enough assets to keep things interesting for the first several turns. Playing against myself, I'm able to shoot down many of the bombers but of course that won't be as easy against someone else.

Here are the updated rules and scenario files in case you're interested.

 

[JPetroski]

Weird bug. the u-boat at 20,106 can't fire a torpedo

D:\Test of Time\Scenario\OTR - update\events.lua:6627: attempt to index a nil value (field '?')
stack traceback:
D:\Test of Time\Scenario\OTR - update\events.lua:6627: in function <D:\Test of Time\Scenario\OTR - update\events.lua:6324>

There is a cloud over it, but it can fire at all nearby squares with clouds.

 

[Prof. Garfield]

Weird bug. the u-boat at 20,106 can't fire a torpedo

D:\Test of Time\Scenario\OTR - update\events.lua:6627: attempt to index a nil value (field '?')
stack traceback:
D:\Test of Time\Scenario\OTR - update\events.lua:6627: in function <D:\Test of Time\Scenario\OTR - update\events.lua:6324>

There is a cloud over it, but it can fire at all nearby squares with clouds.

This is a bug in civlua.lua. Same bug as when certain units couldn't fire munitions from "special" squares. In this case, civlua.createUnit is checking to make sure the new unit is created on an ocean tile or coastal city. Fix is here.

 

[Prof. Garfield]

I have the events.lua file for Over the Reich now.

 

[Prof. Garfield]

The events are available, but be sure to post if you take them again. I might do more later (but take them if you want/need them, other things have captured my interest also).

Changelog 17 August

The Operation Overlord event appears to have already been removed, in any case, the only occurrence of specialNumbers.overlordThreshold has been commented out.

The germanVictoryThreshold event and text has been commented out

Air protected carrier bug fixed.

Units can now rearm on carriers.

local rearmOnCarrier ={}
rearmOnCarrier[unitAliases.Ju87G.id] = true
rearmOnCarrier[unitAliases.HurricaneIV.id] = true

Germans can build airbases in South France again.

French Occupation Trains now have no home city when created.

The following units activate "mass radar" when backspace is pressed, and also participate in the detection

-- Activate All Radar Stations (not Aircraft)
-- All movement points will be expended for these units
local groupRadarUnits ={}
groupRadarUnits[unitAliases.EarlyRadar.id] = true
groupRadarUnits[unitAliases.AdvancedRadar.id] = true

Damaged B17s now get veteran status. Turns out the code was already there for it, and I simply had to edit the table survivingUnitTypes.


improvementAliases.airbase = civ.getImprovement(17)

Have made it so that certain units cannot defend airbases and/or cities. Such a unit is moved to a valid adjacent square when a munition is generated. Then, any aircraft are moved to avoid being on a strategic target. I figure that ships (with the possible exception of submarines) shouldn't be able to take refuge in a city without a port.

local canNotDefendAirfield ={}
canNotDefendAirfield[unitAliases.AlliedArmyGroup.id] = true
canNotDefendAirfield[unitAliases.AlliedBatteredArmyGroup.id] = true
canNotDefendAirfield[unitAliases.GermanArmyGroup.id] = true
canNotDefendAirfield[unitAliases.AlliedBatteredArmyGroup.id] = true
canNotDefendAirfield[unitAliases.RedArmyGroup.id] = true
canNotDefendAirfield[unitAliases.Convoy.id] = true
canNotDefendAirfield[unitAliases.AlliedTaskForce.id]=true
canNotDefendAirfield[unitAliases.GermanTaskForce.id]=true

local canNotDefendCity ={}

local canNotDefendCityWithoutPort = {}
canNotDefendCityWithoutPort[unitAliases.Convoy.id] = true
canNotDefendCityWithoutPort[unitAliases.AlliedTaskForce.id]=true
canNotDefendCityWithoutPort[unitAliases.GermanTaskForce.id]=true


After production, all flak is fortified that doesn't have a goto order or an enemy aircraft in range. For testing purposes, console.fortifyPassiveFlak can be used

-- Fortify flak not in range of enemies or with a goto command
-- groupFlakUnits[unitAliases.FlakUnit.id]=true
local groupFlakUnits = {}
groupFlakUnits[unitAliases.GermanFlak.id] = true
groupFlakUnits[unitAliases.AlliedFlak.id] = true
console.fortifyPassiveFlak

I may be able to make it so that flak which has been moved on the previous turn will not be fortified, enabling it to activate and remind the player that it should probably be moved. Not sure about this, though. I may be prevented by not being able to store the data.

 

[JPetroski]

I have the events

 

[Knighttime]

We might be able to use Knighttime's supply module to check if a rail link exists between a proposed destination and the redeploying unit. If we can, then I'd simply suggest moving units between cities, rather than trying to remember the exact coordinates of the installation tile you want to move to.

If it can easily be implemented then I think it is OK but if it is going to pull you too far into the rabbit hole I don't think it's "urgent." There's going to be a few things that come up during playtests that need to be fixed more than this. Having that supply lines be one of the new things Burma (presumably) introduces into the world wouldn't be a bad thing either. OTR is already quite complex.

I think the existing version of supplyLines that is out there (1.0) could handle the need as you described it above for OTR -- if you want to give it a shot. But it's absolutely fine if you decide not to pursue this, for any reason whatsoever.

Just so you know, I've also started working on an updated version of supplyLines, which will be released as 2.0 when it's finished. That will support significantly more complex rules and quite a few additional use cases. All existing functionality will be preserved, but it's possible that some of the function parameters will change -- I haven't finalized that yet.

I'm not in the loop on the Burma reference, but if you are planning to integrate supplyLines into any project, you're welcome to PM me with any details or questions -- especially if you have key functionality needs that don't seem to be possible with v1.0. Perhaps they will (or could) be covered by my next release.

 

[JPetroski]

The events are available. I used the time to clean up the "help" section and also add in a few things:

EVENTS CHANGED
-tweaked what units carry what bombs, etc.
-removed ability to build sabotage port in airfields
-added Red Army create unit to the Vistula event now that the Allies don't start the game with them in the city***
-added in some text for a few early turns to explain the flak batteries being fortified as well as how to use radar effectively.

***I think we need to change the terrain in this event (line 8524) too so as to open up the front, but I did not change this.

Other than that I just tried to work on the describe text and readme. I believe the units sections are OK at this point.

 

[Prof. Garfield]

I have the events. I found an off the shelf compression module https://github.com/Rochet2/lualzw to reduce the size of the state table (it can still read uncompressed state table serializations). It appears to have reduced error.hot from 1.8 MB to 1.4 MB, which is satisfying for almost no work. Of course, compressing the entire save file reduced it to ~130KB, so that is the way to go for someone keeping archives long term.

I think the existing version of supplyLines that is out there (1.0) could handle the need as you described it above for OTR -- if you want to give it a shot. But it's absolutely fine if you decide not to pursue this, for any reason whatsoever.

Just so you know, I've also started working on an updated version of supplyLines, which will be released as 2.0 when it's finished. That will support significantly more complex rules and quite a few additional use cases. All existing functionality will be preserved, but it's possible that some of the function parameters will change -- I haven't finalized that yet.

The code in 1.0 won't work off the shelf (at least based on the quick look I took), but I planned to copy an existing function into a new one that had a couple more arguments so that the condition for the depot could be defined when the function is called. What I need is a function isConnected(startTile,endTile, function canTraverse(tile)-->bool)-->bool, shortest distance might be nice. I might be able to find something off the shelf for that, or write an algorithm myself from an example. However, decent path finding that is easily integrated would probably be very useful to a lot of people. At this point, I kind of consider OTR to be a mashed together bundle of code anyway, so I'll likely just shove the square supplyLines 1.0 into the round hole of general path finding and call it a day, as long as it is fast enough as is.

I'm not in the loop on the Burma reference, but if you are planning to integrate supplyLines into any project, you're welcome to PM me with any details or questions -- especially if you have key functionality needs that don't seem to be possible with v1.0. Perhaps they will (or could) be covered by my next release.

Thus far, I've only said that I'd program the project once I've finished some other projects. With the lua lessons done until I get some feedback, that's looking closer.

***I think we need to change the terrain in this event (line 8524) too so as to open up the front, but I did not change this.

I'll have a look.

 

[Knighttime]

The code in 1.0 won't work off the shelf (at least based on the quick look I took), but I planned to copy an existing function into a new one that had a couple more arguments so that the condition for the depot could be defined when the function is called. What I need is a function isConnected(startTile,endTile, function canTraverse(tile)-->bool)-->bool, shortest distance might be nice.

Well, to provide a few more details then: version 2.0 will take any object that has a location (a city, a unit, or a tile itself) as the first argument, and derive the start tile from that. It will also support a table of tiles as a second argument for valid destinations; your case of endTile is really a subset of that, a table with one element. This serves as an alternative option to the version 1.0 approach of code within the isValidSupplyDepot() function that can be edited to calculate whether or not a tile is a valid destination. The concept of canTraverse(tile) is handled in version 1.0 by code contained within the isValidSupplyLink() function. That aspect of the functionality is going to be expanded upon as well in version 2.0, but the exact details are still a work in progress.

Regarding "shortest distance", version 1.0 lets you define a maximum distance and will seek to find a route that length or less; version 2.0 will also support a minimum distance. I haven't really attempted to solve the "shortest distance" problem, because (a) I'm concerned that it would slow down performance, and (b) I don't have a specific use case on hand which would make that necessary. Do you have details you can share about a proposed implementation where this would be significant?

It sounds as if conceptually, you'd like to see a fully static module that's scenario-independent, so you envision defining your own function externally and passing it in as a parameter, whereas I've been designing supplyLines as a module that is intended to be edited/customized by each scenario designer as they incorporate it. I see some pros and cons to both approaches, actually, and I'll think about that a little more.

I might be able to find something off the shelf for that, or write an algorithm myself from an example. However, decent path finding that is easily integrated would probably be very useful to a lot of people. At this point, I kind of consider OTR to be a mashed together bundle of code anyway, so I'll likely just shove the square supplyLines 1.0 into the round hole of general path finding and call it a day, as long as it is fast enough as is.

Honestly you seem rather hard to please. If I build something in Lua and don't post it, I seem to get criticized; when I do post it, I basically get criticized anyway -- or at least "damned by faint praise".

I freely admit there are shortcomings and missing features in version 1.0 -- it was a first attempt, after all -- and this will probably also be true with version 2.0. You are always welcome to build something yourself that works the way you want it to and aligns more perfectly with your needs. Seriously, there are no hard feelings if you prefer to go that route -- it's exactly what I would do if I found resources online that weren't quite what I was looking for. I'm merely offering what I have, no pressure, in case it's helpful.