Over the Reich - Creation Thread

[JPetroski]

I've accomplished quite a bit today. Unfortunately during testing I learned that a unit cannot transport via a teleporter city improvement unless it is allowed on the other map. Allowing it to be on the other map also allows the city to build it. Basically, my idea for Wilde Sau doesn't work (I never bothered to build one during our playtest so I didn't check it until now!)

Is it possible for you to implement a new lua key press event that a German aircraft can transfer from low-alt daylight to low-alt night at cost of full MP and only if they are in a city, and only once Wilde Sau advance (59) is researched by the Germans?

 

[Prof. Garfield]

Yes, I can do the Wilde Sau effect through events. However, it should be possible to use the canBuild event to disallow the production of the relevant aircraft on the night map anyway, if you would still prefer to use the buildings.

I'm just about done writing veteran swap, and will probably debug it this evening.

 

[JPetroski]

Well the advantage of not using the buildings is that the Germans can transfer as many aircraft as they'd like each turn, so that would probably be better. It's balanced in that they can't move them and use them that same turn, but if things go really wrong they can redeploy as needed en masse.

 

[Prof. Garfield]

The events are available, but please post that you have them. I'll post the next time I take them, if you don't already have them.

Here is veteran swap. The key to activate is 3. Swapping requires full health and movement from both units, and they must be in a city to do so. It is possible to set a money cost of veteran swapping, but at the moment it is set to 0. Swapping vet status also swaps the home city of the units. Changing the arguments to vetswap.buildBasicVetSwap can change these settings. See vetswap.lua for the details. We can customize more if we need to, but I think this is sufficient.

search for 'vet swap' or 'vetswap' in the events file to find the table of unit categories for veteran swapping. (vetSwapCategories).

For anyone else building a scenario that might be interested in veterancy swapping, this will work almost 'out of the box.' All you have to do is provide the category list, and make a few choices in a function call (mostly true or false choices) to get the vetSwap function to put in the onKeyPress event. This is in contrast to some other events I've made, where much of the work is left to the end user to make the necessary functions (notably the reaction functionality). If you need options I did not foresee, vetswap.lua is probably 'modular' enough that you can probably still use most of it.

 

[JPetroski]

I've had a busy day. I consider the scenario close to being complete after today's work:

CHANGELOG
-Fixed improvements so they can't be sold and made many automatically be destroyed on city capture.
-Add in "1" and instructions of how to bring up points system
-Changed the text for the Battle of the Atlantic
-Added text for freight train spawn in Southern France
-Changed text for Italian Theatre and Russian Front
-Beefed up German radar system - Allies can no longer cripple it on turn 1
-As radar no longer has to be on installation terrain to fire, removed installation terrain under the sets so that it isn't obvious where they are.
-Added special resources to forests, industry, and hills but only did this on the low-alt daylight map, as I reason you wouldn't see coal deposits from 30,000 feet.
-Fixed railtrack terrain near Cherbourg
-Eliminated "railroad to nowhere" NE of Bordeaux since the player can't build an airfield along it.
-Fixed railtrack near Wilhelmshaven on night map
-Fixed railtrack near Merseburg
-Added a demarcation line for Occupied France (x=227) so that players have a clear visual of where their units need to be. I also added some text explaining the line.
-Added reference to the "2 key" in the readme "Special Keys." Placeholder set for explaining the concept further.
-Added to the table of contents so people know what subsection is what for the major game concepts as we have so many.
-Placeholders for veteran upgrades, newspaper, air protected stacks revisited, and special missions.
-Created appendix for Special Missions.
-Added a handful of fuel dumps (roads) to the map to give the player a hint that they can build them
-Increased map diversity a bit more with farmland, etc.
-Fixed Spysound so that it now works as designed and sounds like a camera.
-Created sound files for turn 1 Allies & Germans, Red Army arrival, and B-17 arrival. I do need to add these to events at some point and there are directions below as to how/where to do that.
-Added describe.txt for advances since several have hidden functions.

TO DO:

civ.playSound('Turn1RAF.wav') -- needs to be added after 5081 (if turn == 1 then)
civ.playSound('FlyingFortress.wav') -- needs to be added after 5091 (if turn == 2 then)
civ.playSound('LuftwaffeMarch.wav') -- needs to be added after 5303 (if tribe == tribeAliases.Germans and turn == 1 then
civ.playSound('RedArmy.wav') -- needs to be added after 5210 (if tribe == tribeAliases.Allies and counterValue("AlliedScore") >= specialNumbers.vistulaOderThreshold and not civ.hasTech(tribeAliases.Allies, civ.getTech(76)) and state.DDayInvasion == true then
-Continue working through describe.txt to make sure everything is accurate.

TO CONSIDER:
-Should we waste a unit slot to give barbarians an indestructable "Sweden" unit to disallow aircraft from flying over Sweden and Ireland? I don't really see this as being a huge problem. Perhaps this could be reassessed after the open playtest.
-Do we need the "this is turn 1 and the tribe is the Allies" or was that something to help troubleshoot?

 

[JPetroski]

I have the events - I'll add the sound file play events and will let you know when complete (tonight if I don't fall asleep putting the kids to bed).

 

[Prof. Garfield]

Well the advantage of not using the buildings is that the Germans can transfer as many aircraft as they'd like each turn, so that would probably be better. It's balanced in that they can't move them and use them that same turn, but if things go really wrong they can redeploy as needed en masse.

That makes sense. I'll implement it when I have a chance.

Uh-oh. Just noticed that you posted. I'll take your events and re-do my portion. The part in the main event file wasn't very complicated.

 

[Prof. Garfield]

TO CONSIDER:
-Should we waste a unit slot to give barbarians an indestructable "Sweden" unit to disallow aircraft from flying over Sweden and Ireland? I don't really see this as being a huge problem. Perhaps this could be reassessed after the open playtest.
-Do we need the "this is turn 1 and the tribe is the Allies" or was that something to help troubleshoot?

I think forbidding overflight of neutral territory is probably a good idea. We especially don't want the Allies sending a DDay barge to Sweden to set up an airfield or anything like that.

The "This is turn x and the tribe is XXXX" was to double check that the 'afterProduction' events were happening. Since we haven't noticed a time where they didn't happen, I think it is safe to remove the text box.

Do we want to sometimes create a 'downed pilot' unit when a plane is destroyed over land, to provide a sort of home territory defence bonus? I might have to alter veteran swap to allow the same unit to swap status with multiple categories of units if we do, but it might be worth it if you find the concept interesting.

 

[JPetroski]

The events are once again yours. I have added the four sound events to the file.

I think forbidding overflight of neutral territory is probably a good idea. We especially don't want the Allies sending a DDay barge to Sweden to set up an airfield or anything like that.

I'll add Barbarian units around Sweden and Ireland. I'm pretty sure barbarian units will hang around the entire scenario. If playtests prove this is false then I'll do a double line of Allied units/German units so that neither side can penetrate.

The "This is turn x and the tribe is XXXX" was to double check that the 'afterProduction' events were happening. Since we haven't noticed a time where they didn't happen, I think it is safe to remove the text box.

I forgot to edit this out. Can you please?

Do we want to sometimes create a 'downed pilot' unit when a plane is destroyed over land, to provide a sort of home territory defence bonus? I might have to alter veteran swap to allow the same unit to swap status with multiple categories of units if we do, but it might be worth it if you find the concept interesting.

This is a really interesting idea. It's up to you if you want to add more to your plate. I don't have art for it but could ask or perhaps come up with something. Some thoughts:

-It should be a random chance and probably 1/5 or 1/6 - something that doesn't happen often.

I'd say that the Allied downed pilot should pop up on or near the shoot down on the low daylight map, and if it can make its way to occupied France, it presses 'k' and depending on the same German score system as the freight trains, it has a chance of moving over to England.

The Germans would have a considerably easier time because they simply need to get to a home field. Perhaps they could have lower odds of spawning to compensate.

We could always just have it be a unit that gives a good boost to production rather than swapping into a brand new aircraft so you don't have to rewrite the entire veteran swap.

 

[JPetroski]

Actually I just took a look at the table - I see I can add more to it. I can do that in a word pad though while you make what edits you need so you can still keep the events.

 

[JPetroski]

Can you add this to your events please? Basically, American fighters can swap with same; RAF fighters with same; Luftwaffe day fighters with same; Luftwaffe night fighters (and bomber destroyers) with same; etc. etc. etc.

Hopefully this doesn't make for too long of a list on some people's monitors. I think it would be pretty rare that a city would have every type of aircraft in it for that to happen.

local vetSwapCategories = {
{unitAliases.B17F, unitAliases.damagedB17F, unitAliases.B17G, unitAliases.damagedB17G, unitAliases.B24J},
{unitAliases.Stirling, unitAliases.Halifax, unitAliases.Lancaster},
{unitAliases.A20, unitAliases.B26, unitAliases.A26},
{unitAliases.Beaufighter, unitAliases.MosquitoII, unitAliases.MosquitoXIII},
{unitAliases.SpitfireIX, unitAliases.SpitfireXII, unitAliases.SpitfireXIV, unitAliases.HurricaneIV, unitAliases.Typhoon, unitAliases.Tempest, unitAliases.Meteor},
{unitAliases.P47D11, unitAliases.P47D25, unitAliases.P47D40, unitAliases.P38H, unitAliases.P38J, unitAliases.P38L, unitAliases.P51B, unitAliases.P51D, unitAliases.P80},
{unitAliases.Me109G6, unitAliases.Me109G14, unitAliases.Me109K4, unitAliases.Fw190A5, unitAliases.Fw190A8, unitAliases.Fw190D9, unitAliases.Ta152, unitAliases.He162, unitAliases.Me163, unitAliases.Me262},
{unitAliases.Me110, unitAliases.Me410, unitAliases.Ju88C, unitAliases.Ju88G, unitAliases.He219},
{unitAliases.Ju87G, unitAliases.Fw190F, unitAliases.Do335},
{unitAliases.He111, unitAliases.Do217, unitAliases.He277, unitAliases.Arado234, unitAliases.Go229},
}

 

[Prof. Garfield]

Will do. Don't worry about having a list that is too long. If there are more than 10 options, the selection is split into multiple pages. I didn't weed out 'duplicate' options, so that might end up being fairly common in a busy airbase. I can also change the number of selections per page if we find some monitors are too small.

 

[JPetroski]

Can the same unit be in multiple sub tables for veteran swap? If so, thinking your pilot idea further, perhaps the pilot unit is a veteran and the point of the unit is to go find a new plane to hop into.

 

[Prof. Garfield]

changelog november 28

Wilde Sau implemented, with key 'u' acting as the trigger. A message is shown to the player, either stating that the unit has been moved, or explaining a reason why Wilde Sau can't be used.

Search for Wilde Sau in the Events.lua file

All air units owned by Germany (except munitions) can take advantage of Wilde Sau once the advance has been discovered. Changing maps in this way expends all movement points.

The table governing what units can swap veteran status has been updated. At the moment, a unit can only be in one category, but I will probably update vetswap.lua eventually to allow a unit to be in multiple categories. vetswap is activated by '3'.

Generating a munition will check all adjacent squares for air protected strategic targets (i.e. a square with both an air unit and a strategic target). Where they exist, they will first try to place the aircraft on an adjacent empty square. If none exists, it will try to place the aircraft on an adjacent friendly square without a strategic target (it will not try to find the square with the fewest units or anything like that). If no such square can be found, the aircraft will be placed on a strategic target not adjacent to the munition generating unit. If there is still no place to put the unit, it will be left where it is.

I decided not to display a message if the unit is left where it is, since that would get very annoying if the situation couldn't be resolved and lots of munitions were being generated (either to kill that target with fighter fire, or to attack an adjacent target).

Strategic targets are defined by the following table

local stratTargetTable = {
unitAliases.Railyard ,
unitAliases.MilitaryPort,
unitAliases.Industry1 ,
unitAliases.Industry2 ,
unitAliases.Industry3 ,
unitAliases.ACFactory1 ,
unitAliases.ACFactory2 ,
unitAliases.ACFactory3 ,
unitAliases.Refinery1 ,
unitAliases.Refinery2 ,
unitAliases.Refinery3 ,
unitAliases.Urban1 ,
unitAliases.Urban2 ,
unitAliases.Urban3 ,
unitAliases.V1Launch ,
unitAliases.V2Launch ,
}

search for 'air protected stacks'

Removed the "It is turn X and the tribe is XXXX dialog"

Fixed an oversight in formations, so ground units with full movement points will always make it into the next square.

Removed the two entries from the table 'reactionWarningType', which made B17s part of the general category of 'bomber'. If we want categories of units instead of each individual unit listed, the table has to be filled in.

Units can now be in multiple categories for vet status swapping.

Let's think about the pilots idea a little bit more. It does create a (true to life) defensive bonus, at least in principle. However, if the unit appears right away, the attacker can just score an easy kill, unless he's extremely short of aircraft. If the unit doesn't appear right away (or at some distance from the plane), then we introduce a manhunt mechanic, which is probably even worse than submarine hunting (which, incidentally, would be substantially easier now that we have formations).

Stuff to do before release:
1) Destroy appropriate terrain when city captured.
2) Fix French trains
3) Special Target Events

Stuff that might be nice to improve:
4) Reaction Warnings
5) Combat reporting
6) "Newspaper"


Have I missed anything? For your part, there are some aircraft factories in England (e.g. Birmingham and Manchester that don't have corresponding industry tiles on the low map.

Not sure if this could be done in time, but do you want moving clouds? On your part, it would require changing the map so that everywhere there is cloud cover, the underlying terrain is put in place instead. We'd also have to figure out how we want them to behave.

 

[JPetroski]

I did this before I saw your post and then the clouds got me going....

Aircraft factories don't actually produce industry terrain - they are simply science buildings that also allow you to build prototype (trade) units.

My changelog since last:

As of 11/28/18
civ.playSound('Turn1RAF.wav') -- added
civ.playSound('FlyingFortress.wav') -- added
civ.playSound('LuftwaffeMarch.wav') -- added
civ.playSound('RedArmy.wav') -- added
-filled out table for veteran swap
-added section of readme describing veteran swap
-added "3" to special keys section in readme
-added barbarian neutral units to Sweden on all 3 maps
-added neutral boundary around Ireland on all 3 maps
-made neutral territory an air unit to prevent destroyers and u-boats from bumping into it and dying (all air units have 0 attack so they shouldn't be an issue)
-Fixed issue where Industry III improvement describe.txt wasn't showing in pedia
-changed neutral territory to a white flag
-added pedia.txt for jagdfliegerschule and also get rid of -1 to description and provide one instead in describe.txt
-Finished describe.txt for advances
-Finished and double-checked describe.txt for improvements and wonders
-Finished 1/3 of describe.txt for units. I'm up to the Meteor. I'm updating things from when I first wrote it and explaining how many times a unit can react, and against what and where. This is a redundancy from the readme but I do think it's important given how much we've changed gameplay here.

TO DO:

-Finish remaining 2/3 of units in describe.txt
-Do terrain describe.txt if only to explain how you secure factory and refinery terrain, etc.
-Do government section in describe.txt (only the 2 governments available)
-Do Game Concepts section of describe.txt - lift directly from readme

Not sure if this could be done in time, but do you want moving clouds? On your part, it would require changing the map so that everywhere there is cloud cover, the underlying terrain is put in place instead. We'd also have to figure out how we want them to behave.

I would place a significantly high value on this and would consider the tactical implications very much worth it. I'm curious if it is possible to do this in a way that makes it relatively simple/quick for you and then places more of a burden on me as I'm expecting to have some capacity to churn through some stuff in the next two weeks.

How difficult would it be for you to create an extremely labor-intensive but straightforward way for me to create several cloud cover tables, and then for the game to have a random chance that it will switch up every few turns? Perhaps a 1/3 or 1/4 chance? Except on the first turn where there is a 100% chance as we want clouds somewhere from the start?

What I'm thinking is it would be good if I could create tables with names that would then have a few sets of coordinate variations like:

"heavy cloud cover everywhere"
variation 1 (all coordinates that should swap to clouds)
variation 2 (all coordinates that should swap to clouds)
variation 3 (all coordinates that should swap to clouds)

"heavy cloud cover France light cloud cover Germany"
variation 1 (all coordinates that should swap to clouds)
variation 2 (all coordinates that should swap to clouds)
variation 3 (all coordinates that should swap to clouds)

"heavy cloud cover Germany light cloud cover France"
variation 1 (all coordinates that should swap to clouds)
variation 2 (all coordinates that should swap to clouds)
variation 3 (all coordinates that should swap to clouds)

And so on....

We would want a text box to pop up depending on what in quotes is called up so that the player knows what is going on with the weather and can divert to a secondary target if needed.

Would the game remember what the terrain used to be and revert back to it or would I also need to compile a list of what the "standard" terrain is for these tiles? I imagine I would need to take care not to have cloud cover over any coordinate that matches a factory, refinery, etc. but that is certainly possible to avoid given we already have all those coordinates and a simple search function could rule them out.

Also, how difficult would it be for you to create an event where the 250, 500, 1000lb bombs have their attack value halved if called up/activated on cloud terrain?

One of the big problems the Allies had was the terrible European weather and I think that not having a guarantee of finding the target/being able to attack it effectively would be a great amount of fun.

 

[JPetroski]

I'm not sure what other options are possible ways to implement this. We're you suggesting cloud patterns that move turn by turn?

I suppose this would enable a forecast of sorts. Perhaps it could be randomized just how fast the clouds would move and how far they'd offset per turn.

I'm interested to hear what you had in mind.

 

[Prof. Garfield]

My plan is that whenever a cloud is placed, the underlying terrain is stored in a table. When a cloud is removed, the game checks the table for the terrain that should be there. If the terrain is changed "under" a cloud, the cloud disappears and is replaced by the new terrain. That terrain loses the cloud cover bonus (until the clouds are re-calculated again), but the code should be relatively simple.

My thought was, indeed, to have the clouds move turn by turn (or, perhaps, only every couple turns). My plan is to have a 'storm centre' tile which is how I keep track of where the clouds are, and then have some sort of pattern (that periodically changes) of clouds around that centre. When the clouds move, I remove all the cloud tiles and replace them with what was underneath, then go to the new centre and re-build the cloud pattern. This would require us to choose how clouds move over Europe, and how they dissipate (or grow).

We could have a set of tables that governs the cloud patterns, or it could be generated programatically in some way (a square has a chance to be cloudy based on the distance from the centre and whether each of the adjacent tiles already have cloud cover or not).

Your idea of having a handful of cloud cover 'options' and randomly choosing between them could also work, and wouldn't involve a rudimentary weather engine.

In any case, for whatever we choose that requires entries in tables, I'll write a script that allows you to place the clouds over the map, and then prints a table to cut and paste into the events file.

Also, how difficult would it be for you to create an event where the 250, 500, 1000lb bombs have their attack value halved if called up/activated on cloud terrain?

One of the big problems the Allies had was the terrible European weather and I think that not having a guarantee of finding the target/being able to attack it effectively would be a great amount of fun.

Halving the attack value of bombs called up on cloud terrain is easy. It's a simple on activate, and we don't have to worry about them being in cities and getting called up from the city window. But I thought that cloud terrain already offers a defensive bonus anyway.

As long as we let the human player control the aircraft, we're not going to be able to do navigation difficulties (and I don't want to program something to substitute for human control at this point). Unless you meant that cloud cover would also represent the chance of not finding the target?

Aircraft factories don't actually produce industry terrain - they are simply science buildings that also allow you to build prototype (trade) units.

I thought that they put industry terrain some distance from the city, that you could build an airbase beside? Certainly that happened when I build new aircraft factories.

Also, if you've added sound events, does that mean you have the events now? (Last time I saw your changelog, I thought you were changing text boxes when you were actually changing the text on the map itself.) Also, can you send me the other files you've updated?

 

[JPetroski]

I don't have the events - I just kept a chage log of everything I had done since Tuesday. Sorry for the confusion.

I'll respond in more detail later to your comments, but yes, reducing bomb effectiveness would represent the chance of missing the target. The trade off is you're harder to kill due to the defensive bonus.

 

[JPetroski]

Attached please find a workon1 save, updated rules, and updated units. I trust you weren't interested in a 2/3 finished describe.txt.

I know you said that adding moving clouds would probably delay release of the scenario beyond the 12/14 target. Do you think we could make 12/21 or is this much more ambitious than that? I really think this is an idea that would make this scenario come alive and also increase replayability as well as force tactical adjustments throughout the game.

My plan is that whenever a cloud is placed, the underlying terrain is stored in a table. When a cloud is removed, the game checks the table for the terrain that should be there. If the terrain is changed "under" a cloud, the cloud disappears and is replaced by the new terrain. That terrain loses the cloud cover bonus (until the clouds are re-calculated again), but the code should be relatively simple.

My thought was, indeed, to have the clouds move turn by turn (or, perhaps, only every couple turns). My plan is to have a 'storm centre' tile which is how I keep track of where the clouds are, and then have some sort of pattern (that periodically changes) of clouds around that centre. When the clouds move, I remove all the cloud tiles and replace them with what was underneath, then go to the new centre and re-build the cloud pattern. This would require us to choose how clouds move over Europe, and how they dissipate (or grow).

I play another game called "Bombing the Reich" which is a very in-depth simulator of the air war and from what I can see from that as well as a quick google search, clouds in Europe generally move from west to east. If any of our European friends would like to chime in though, it would be appreciated.

We could have a set of tables that governs the cloud patterns, or it could be generated programatically in some way (a square has a chance to be cloudy based on the distance from the centre and whether each of the adjacent tiles already have cloud cover or not).

That's a pretty good idea and it sounds like it would be less hassle than my idea as mine would require making a large number of huge tables. If I'm understanding you right, yours would also involve some tables but we'd just be picking coordinates for "storm centers" rather than every single tile that should have cloud cover. So where my idea might require 100-300 coordinates per table, yours could probably work with 10-30. Let's go with your idea

Other thoughts:
-We need to make sure that clouds can never show up on terrain 9 on map 2 (airfields) - frankly they shouldn't show up on any tile that has a city, not that there would be a city ever on map 1.
-Clouds should never show up on terrain 10 (Ocean) because that will create land bridges and also just look weird since I can't get rid of the tile edge graphic - it'll look like little islands with a cloud on top of them rather than a cloud. A possible solution would be to change the special resource of the tile because ocean has clouds on both map 1 and 2 as special resources, but I'm not sure if that would be possible.
-If we go with a moving system, I think we might want to have each "weather pattern" last between 5-8 turns and then perhaps "clear up" with just scattered clouds for one turn and then a new weather pattern emerges. I say 5-8 turns so that players can't count on the clearing/time it.
-Some weather patterns should be heavier than others (greater number of "storm centers" )
-The movement rate of the storm centers ought to be randomized a bit so that a rudimentary forecast by the player is possible ("it looks like it will be cloudy over Berlin in 4 turns") but can't be guaranteed because a system could speed up, or slow down a bit, throwing your plans slightly out of whack.
-I don't really care if the same storm system is on the night map and day map at the same time. Day/night are abstract concepts anyway and a turn simply represents "a turn" rather than "an hour." It would probably be simpler for the player to have them share the system, but whatever is easier for you is fine by me.

Halving the attack value of bombs called up on cloud terrain is easy. It's a simple on activate, and we don't have to worry about them being in cities and getting called up from the city window. But I thought that cloud terrain already offers a defensive bonus anyway.

As long as we let the human player control the aircraft, we're not going to be able to do navigation difficulties (and I don't want to program something to substitute for human control at this point). Unless you meant that cloud cover would also represent the chance of not finding the target?

The benefit to clouds is that they give your aircraft a defensive bonus, however the drawback is that if you must attack a target from a cloud with bombs, there's a chance they won't find the target (which we will represent by the bombs being considerably less powerful - they still *could* hit, but it'll be much less likely, and the amount of damage they will do should be much less severe generally).

I thought that they put industry terrain some distance from the city, that you could build an airbase beside? Certainly that happened when I build new aircraft factories.

To be honest I will need to revisit the strategic bombing table as it has been months since I looked at it. I wasn't aware that aircraft factories change the terrain. I certainly didn't intend for them to. However, I don't have an issue with them doing that and actually it's pretty historically accurate for some airfields to deliberately be built near aircraft factories. The Germans had little "mini-squadrons" of aircraft that specifically were assigned to factories. So, in short, I will go back through, confirm that the events is adding the terrain change, and if so, I'll make the corrections to the terrain tiles on the map for the aircraft factories that are there at game start.

Also, if you've added sound events, does that mean you have the events now? (Last time I saw your changelog, I thought you were changing text boxes when you were actually changing the text on the map itself.) Also, can you send me the other files you've updated?

As stated earlier, they're all yours. Sorry for the confusion.

 

[Prof. Garfield]

changelog 30 November

Removed dependence of destroyer cost on the number of Allied Military Ports. If desired, we should re-introduce it on a unit that can only be built by the Allies.

Current French train generation scheme:
Full movement point Schutzen, Panzers, Artillery have their movement spent and contribute to a 'score' as follows:
Schutzen 3 points, Panzers 2 points, Artillery 1 point.
First 150 points don't count for anything. For every 15 points beyond 150, a train is generated, to a maximum of 6 trains.
Trains are generated on the tiles (166,144,0), (198,142,0), (214,134,0), in that order. If more than 3 trains are produced, start at (166,144,0) again for the next 3 trains.

Capturing a city now destroys all surrounding terrain that would be destroyed if all the strategic targets supported by that city were destroyed. This turned out to be really easy. I checked all units in the game for units homed to the captured city, and ran Knighttime's unit killed code on the units that are supported by the captured city.

I know you said that adding moving clouds would probably delay release of the scenario beyond the 12/14 target. Do you think we could make 12/21 or is this much more ambitious than that? I really think this is an idea that would make this scenario come alive and also increase replayability as well as force tactical adjustments throughout the game.

I'm currently taking a tax preparation course that has exams on the 14th and 17th, and a case study before that, so I might not get that much done that week. After that I'm free, so I will almost certainly be able to get the stuff done by the 21st. There turned out to be a dead simple way to destroy the strategic terrain on city capture, so I already have more time to devote to clouds at the moment. The more I think about them, the more convinced I am that they won't be too bad to do. I'll do clouds this weekend, and see where I get to.

I play another game called "Bombing the Reich" which is a very in-depth simulator of the air war and from what I can see from that as well as a quick google search, clouds in Europe generally move from west to east. If any of our European friends would like to chime in though, it would be appreciated.

A quick web search found me a couple videos on the cloud movement over western Europe, and west to east was the pretty universal pattern, with some drifting north or south.

Other thoughts:
-We need to make sure that clouds can never show up on terrain 9 on map 2 (airfields) - frankly they shouldn't show up on any tile that has a city, not that there would be a city ever on map 1.
-Clouds should never show up on terrain 10 (Ocean) because that will create land bridges and also just look weird since I can't get rid of the tile edge graphic - it'll look like little islands with a cloud on top of them rather than a cloud. A possible solution would be to change the special resource of the tile because ocean has clouds on both map 1 and 2 as special resources, but I'm not sure if that would be possible.
-If we go with a moving system, I think we might want to have each "weather pattern" last between 5-8 turns and then perhaps "clear up" with just scattered clouds for one turn and then a new weather pattern emerges. I say 5-8 turns so that players can't count on the clearing/time it.
-Some weather patterns should be heavier than others (greater number of "storm centers" )
-The movement rate of the storm centers ought to be randomized a bit so that a rudimentary forecast by the player is possible ("it looks like it will be cloudy over Berlin in 4 turns") but can't be guaranteed because a system could speed up, or slow down a bit, throwing your plans slightly out of whack.
-I don't really care if the same storm system is on the night map and day map at the same time. Day/night are abstract concepts anyway and a turn simply represents "a turn" rather than "an hour." It would probably be simpler for the player to have them share the system, but whatever is easier for you is fine by me.

OK, I won't put clouds over the ocean or any cities, and not on map 1. We'll figure out the details of our weather patterns once I have the mechanisms to place them.

I don't see any reason why it would be noticeably easier to have the same weather pattern at high altitude and night, so I'll give them each their own weather systems.

The benefit to clouds is that they give your aircraft a defensive bonus, however the drawback is that if you must attack a target from a cloud with bombs, there's a chance they won't find the target (which we will represent by the bombs being considerably less powerful - they still *could* hit, but it'll be much less likely, and the amount of damage they will do should be much less severe generally).

I would figure that if the factory is covered by clouds, then it is on a cloud terrain instead of its regular terrain (since there are no clouds on map 1, this doesn't affect production) and will get the terrain defensive bonus anyway. So we don't have to mess around with changing bomb effectiveness.

How should reactive fire depend on clouds? Assuming it is about equally easy to do both versions, do you want a smaller chance of damage, or less damage, but the same chance of damage (e.g. 50% of regular chance of a hit, or 50% of damage from a hit). Is flak different? Should it depend on whether the trigger unit is in clouds, or the reacting unit?