Over the Reich: Single Player - Development Thread

[JPetroski]

Edit- the answer was in the first page of this thread lol.

 

[JPetroski]

I am going to build out an excel sheet that helps me figure out all of these. I was thinking about it last night when I didn't have access to what we had worked on/come up with but I knew the below was generally built. When I was thinking it through, I thought I'd just assign a "combat value" for low alt, high alt, and night to each aircraft. Then, I'd simply rank aircraft and assign them values for each. My question is, do you foresee anything breaking if I simply used the same pursuit and escape speed for the same map, like the below?

I suppose it's good to have even more options (so honestly maybe a P-47D which can dive like the dickens would have a higher escape speed at high) but I was almost thinking of approaching it as more of an "overall combat ability" value vs. "speed" value, as a lot of things go into a dogfight. Views, agility, speed, climb, acceleration, etc.

There's no need to rename it or do any work on your end - these are perfectly good names - but I was thinking I'd just put an excel sheet together with all the aircraft on it ranked for each map and generally speaking, a better ranking aircraft would have a better chance at defeating a lower ranking aircraft on a particular map. I just want to make sure that what I'm trying to do would generally work.


combatParameters[object.uP47D11.id] = {
--pursuitSpeed = 410,
--escapeSpeed = 410,
pursuitSpeedLow = 200,
pursuitSpeedHigh = 400,
pursuitSpeedNight = 100,
escapeSpeedLow = 200,
escapeSpeedHigh = 400,
escapeSpeedNight = 100,
interceptionRange = 2,
attackMoveCost = 15,
}

 

[Prof. Garfield]

I am going to build out an excel sheet that helps me figure out all of these. I was thinking about it last night when I didn't have access to what we had worked on/come up with but I knew the below was generally built. When I was thinking it through, I thought I'd just assign a "combat value" for low alt, high alt, and night to each aircraft. Then, I'd simply rank aircraft and assign them values for each. My question is, do you foresee anything breaking if I simply used the same pursuit and escape speed for the same map, like the below?

That's fine. There is no reason they have to be different, and for most aircraft it probably makes sense for them to be the same. A radar equipped night fighter might get a bonus to its pursuit "speed" at night for being able keep better track of enemies. Basically, some calculation is done between the pursuitSpeed and escapeSpeed to determine the ability of a damaged unit to disengage from combat.

I suppose it's good to have even more options (so honestly maybe a P-47D which can dive like the dickens would have a higher escape speed at high) but I was almost thinking of approaching it as more of an "overall combat ability" value vs. "speed" value, as a lot of things go into a dogfight. Views, agility, speed, climb, acceleration, etc.

There's no need to rename it or do any work on your end - these are perfectly good names - but I was thinking I'd just put an excel sheet together with all the aircraft on it ranked for each map and generally speaking, a better ranking aircraft would have a better chance at defeating a lower ranking aircraft on a particular map. I just want to make sure that what I'm trying to do would generally work.

Overall combat ability would be represented by the attack and defense values. The speeds just determine the ability of the "losing" aircraft to leave combat before it is destroyed. Below I have the full list of parameter keys that I proposed (I don't remember how many I've implemented).

However, if you want to have a different set of parameters, I have no problem writing code to interpret it. I'm not committed to the system I wrote, I just needed to have something.

I should add that the civilopedia module can generate describe.txt files, so I can write code to interpret the fighters parameters and provide them in the civilopedia description.
EDIT: Added code tags so that indents work properly

--      Integer Keys for unit combat statistics
-- combatParameters[unitType.id] = {
--      These don't have to be 'real life' numbers, although
--      real life numbers might be a good starting point.
--      For example, a radar equipped night fighter might have a
--      high pursuitSpeedNight to reduce the chance of an enemy
--      escaping
--
--      pursuitSpeed = number
--          helps determine how likely an enemy plane is to
--          escape from combat with this plane
--      escapeSpeed = number
--          helps determine how likely a plane is to escape
--          from combat if desired
--      pursuitSpeedLow = number
--      escapeSpeedLow = number
--      escapeSpeedHigh = number
--      pursuitSpeedHigh = number
--      pursuitSpeedNight = number
--      escapeSpeedNight = number
--          these keys override pursuitSpeed and escapeSpeed for certain maps
--      interceptionRange = integer
--          Fighter can defend units this many squares away
--      attackMoveCost = integer or nil
--          cost (in full movement points) for the aircraft to
--          make an attack.  nil means expend all movement
--      attackModHigh = nil|number
--      attackModLow = nil|number
--      attackModNight = nil|number
--      defenseModLow = nil|number
--      defenseModHigh = nil|number
--      defenseModNight = nil|number
--      defenseModClimb = nil|number
--      defenseModDive = nil|number
--          These keys modify the combat statistics of attacking
--          and defending units based on where the attack takes
--          place and (for defending units) where the unit was originally
--          nil means 0
--      attackSupportHigh = nil|number>=0
--      attackSupportLow = nil|number>=0
--      attackSupportNight = nil|number>=0
--      defenseSupportLow = nil|number>=0
--      defenseSupportHigh = nil|number>=0
--      defenseSupportNight = nil|number>=0
--      defenseSupportClimb = nil|number>=0
--      defenseSupportDive = nil|number>=0
--          These keys specify the amount of "combat support"
--          each unit gives, depending on the situation.
--          The first combat support gives +1, the next 2 give
--          another +1, the next 4 give the next +1, and so
--          on, with each doubling giving the next +1
--          The actual formula is log_2(1+totalCombatSupport)
--      attackSupportRange = nil|number[0,maxInterceptionRange]
--          The distance at which the unit can offer attack
--          support to combat, measured from the unit to the
--          defender's tile.  (So 0 range means no support, even
--          if the unit is on the attacker's tile)
--          nil means 0
--      defenseSupportRange = nil|number[0,maxInterceptionRange]
--          The distance at which the unit can offer defense
--          support to combat, measured from the unit to the
--          defender's tile.
--

 

[JPetroski]

I think that most of what you have there should be sufficient - there's always something to come up with but for now I can't think of anything at least.

COMBAT
What I'm basically trying to come up with is a situation where, regardless of base "stats," it's very detrimental for certain aircraft to get involved with fighters on the wrong map. I think the escape/pursuit system is also good, because we don't want combat to mean a unit has to die every time, but I don't know that it'll handle things as well as I'd like - I'm open to suggestions.

I'm thinking in this version all daylight units can go on the low or high alt maps, as everything I've read has impressed upon me that both sides allocated aircraft to totally unsuitable roles from time to time. But there needs to be a significant threat to doing so, and I don't think a/d is going to cut it.

The Tempest for example is going to be a late war monster for the Allies at low level, but if it goes to high alt it should have significant issues. Likewise, while a P-47 would chew a Fw 190A-series to pieces at high altitude, the 190 would have a significant upper hand down low.

I'm not certain of the best way to handle this but I think whatever you and Tootall did to dynamically change unit stats depending on situation in Italy is probably the key to this. I noticed that depending on where certain units were, and what was attacking them, they had very different stats display. I think the escape probability is also good because even if a 190A survived the initial bounce, it would have slim chance against a P47 in a dive, for example, so I wouldn't suggest scrapping it. I'm just not certain it'll do everything we need.

TURNS
As to turns, I know you're a big proponent of making scenarios short enough that one can reasonably expect to complete them. 100 turns appears to be about the gold standard though slightly more or less I suppose can work

Time has always been weird/abstract in this scenario and there's nothing to do about that if we want to keep the turns to a reasonable amount. But, weather did play as much (if not more) of a part in the air campaigns as on the ground and I do think if we're making a final version of this all, I'd like to show the seasons a bit (hoping to have increased cloud cover, basically, during winter). I was thinking, abstractly, of trying to basically have chunks of turns represent "seasons." The scenario starts August 17, 1943 (so most of the way through Summer of '43) and would run until Spring of '45. This would be seven full seasons plus the partial one up front.

I counted out the map using some bases in the East Midlands and if we bumped B-17 movement up to 30 spaces, a round trip to Berlin could be accomplished in 8 turns.

I was thinking if we had each "full season/3 months" last approximately 16 turns, or two full-length missions to the opposite edge of the map or back, that might work pretty well. That would give 112 turns for the main game while adding in maybe 3-5 for the summer of '43 which would allow the bombers to hit Schweinfurt and Peenemunde and make their way back home. So probably about 115 - 117 turns in total which would be less than the original version. In about 32 of those, the weather would be very bad.

 

[JPetroski]

I was taking a look at it. This list is pretty much all the aircraft I could think of, without using German bombers, and it comes to 111, which would leave 78 more for targets, German bombers/v-weapons if desired, etc. As you can see, I've doubled up on many of them, figuring we can have a player decide what mission the unit is going on before it leaves. The /R versions of German fighters would have underwing rockets/cannons which would help them destroy bombers but do poorly against fighters. The (jabo) designation for the Allied aircraft would mean the aircraft were ready for ground attack but wouldn't do as well as fighters and maybe would have less range.

We probably should have ways for Germany to strike back if they decide to do that, so I'll need to use some slots for their bombers, but can't envision taking up more than 5-10 for that.

MS 406
Bf 109G-6
Bf 109G-6/R6
Bf 109G-10
Bf 109G-10/R6
Bf 109G-14
Bf 109G-14/R6
Bf 109K-4
Fw 190A-5
Fw 190A-6
Fw 190A-6/R1
Fw 190A-8/R1
Fw 190D-9
Fw 190F
Do 335
Bf 110G-2
Bf 110G-2/R3
Me 210
Me 410
Me 410B-2/R3
Ta 152
Bf 109G-6/U4N
Bf 110G-4
Do 217N-2
Fw 190A-5/U2
Ju 88C-6
Ju 88G
He 162A
Me 163
Me 262
Ta 183
Egon Mayer
Josef Priller
Adolf Galland
Gunther Rall
Walter Nowotny
H.W. Schnaufer
Erich Hartmann
Gerhard Barkhorn
Experten

A-20G Havoc
A-26B Invader
B-17F Fortress
B-17F Fortress (damaged)
B-17G Fortress
B-17G Fortress (damaged)
B-24 Liberator
B-25Mitchell
B-26 Marauder
Pathfinder B-17
Pathfinder B-24
Baltimore V
Boston III
Halifax
Lancaster
Stirling
Wellington
Wellington RCM
Mosquito B.IV
Mustang I
Mustang III
Mustang IV
Mustang I (jabo)
Mustang III (jabo)
Mustang IV (jabo)
P-38H Lightning
P-38J Lightning
P-38L Lightning
P-47D-6 Thunderbolt
P-47D-15 Thunderbolt
P-47D-20 Thunderbolt
P-47D-25 Thunderbolt
P-47M Thunderbolt
P-51B Mustang
P-51D Mustang
P-38H Lightning (jabo)
P-38J Lightning (jabo)
P-38L Lightning (jabo)
P-47D-6 Thunderbolt (jabo)
P-47D-15 Thunderbolt (jabo)
P-47D-20 Thunderbolt (jabo)
P-47D-25 Thunderbolt (jabo)
P-47M Thunderbolt (jabo)
P-51B Mustang (jabo)
P-51D Mustang (jabo)
Spitfire V
Spitfire VIII
Spitfire IX
Spitfire XIV
Beaufighter
Mosquito N.F.. II
Mosquito N.F. XIX
P-61A Black Widow
Huricane IV (jabo)
Typhoon IB
Tempest V
Whirlwind IA
Typhoon IB (jabo)
Tempest V (jabo)
332nd Fighter Group
Francis Gabreski
George Preddy
John Braham
Johnnie Johnson
Yak-3
La-7
Il-2
Meteor
P-80
Ace (US)
Ace (British)

 

[Prof. Garfield]

What I'm basically trying to come up with is a situation where, regardless of base "stats," it's very detrimental for certain aircraft to get involved with fighters on the wrong map. I think the escape/pursuit system is also good, because we don't want combat to mean a unit has to die every time, but I don't know that it'll handle things as well as I'd like - I'm open to suggestions.

I'm not certain of the best way to handle this but I think whatever you and Tootall did to dynamically change unit stats depending on situation in Italy is probably the key to this. I noticed that depending on where certain units were, and what was attacking them, they had very different stats display. I think the escape probability is also good because even if a 190A survived the initial bounce, it would have slim chance against a P47 in a dive, for example, so I wouldn't suggest scrapping it. I'm just not certain it'll do everything we need.

You may not have noticed because the indenting was bad without code tags above, but there are options to modify attack and defense based on altitude. (I think that was one of the last things I did before development petered out -- I may not have actually implemented the effect on combat yet.)

I don't remember doing much more than providing Tootall with the (register)combatModifiers system. I think the separate parameter system is better for our purposes, since I don't think I implemented a "check map" condition for combatModifiers.

If you think we need some sort of parameter that I haven't thought of, add it and I'll make the code work around it.

TURNS
As to turns, I know you're a big proponent of making scenarios short enough that one can reasonably expect to complete them. 100 turns appears to be about the gold standard though slightly more or less I suppose can work

Time has always been weird/abstract in this scenario and there's nothing to do about that if we want to keep the turns to a reasonable amount. But, weather did play as much (if not more) of a part in the air campaigns as on the ground and I do think if we're making a final version of this all, I'd like to show the seasons a bit (hoping to have increased cloud cover, basically, during winter). I was thinking, abstractly, of trying to basically have chunks of turns represent "seasons." The scenario starts August 17, 1943 (so most of the way through Summer of '43) and would run until Spring of '45. This would be seven full seasons plus the partial one up front.

I counted out the map using some bases in the East Midlands and if we bumped B-17 movement up to 30 spaces, a round trip to Berlin could be accomplished in 8 turns.

I was thinking if we had each "full season/3 months" last approximately 16 turns, or two full-length missions to the opposite edge of the map or back, that might work pretty well. That would give 112 turns for the main game while adding in maybe 3-5 for the summer of '43 which would allow the bombers to hit Schweinfurt and Peenemunde and make their way back home. So probably about 115 - 117 turns in total which would be less than the original version. In about 32 of those, the weather would be very bad.

If we're doing 16 turns per season, why not do 17 and have each turn be labelled as a week? I think having bombers take 4 turns to get to Berlin is about right, as long as there is enough slack that they can fly over the North Sea. 4 turns to Berlin gives enough variability to have improved fighter escorts over time. I think the idea of setting bomber movement first, based on turns to reach the target is a good one. From there, we adjust fighters/intercepters/etc. around that based on what we want them to do. Because I'm pretty sure that "movement allowance" and "speed" are not equivalent in this scenario.

Maybe we could do some sort of system where attacks must take place over "one night" or "one day." Imagine that each day/night is 12 hrs, and each turn represents 2 hours. The "date", actually time, is 8:00,10:00,12:00,2:00,4:00,6:00. Any aircraft still in the air at the end of the 6:00 turn is teleported to the alternate map, where it stays until it reaches an airfield (at which point, it is returned to its correct map). I'm not convinced that this is a good idea, but it seemed clever enough to share, since it has fixed beginning/end of operation time, without having half the aircraft do nothing. A downside to this idea that I've thought of is that the defender won't be asking are there bombers at this point this turn, but instead will say if there is an attack this night, it will have reached this point this turn. So surprises are reduced.

 

[JPetroski]

Well, time just isn't going to work very well for a scenario of this magnitude one way or another, regardless of what we choose. For the Battle of Britain, I think I'd like to condense it to just Aug 13, 1940 to September 15, 1940. So for that one, I think it would be ok to use turns that represent a few hours. I think for that one, the turns would be short enough with few enough units to move that even if we did 4 or 6 turns per day, one could reasonably get through the scenario.

For OTR, I think we need to be more abstract unfortunately.

Anyway I had a random thought I wanted to jot down before i lose it. In terms of light flak that defends airfields - I was thinking perhaps when one is destroyed, we could use a delayed action event to restore it, and the time it would take to restore it would be tied to the damage done to certain factories (either their presence or aggregate hit points).

Maybe they'd restore in 2 turns at full factory production, 4 at 75%, 6 at 50%, etc.

Perhaps this is even done with the heavier stuff.

 

[JPetroski]

OK - I have come up with 19 targets that I think make a lot of sense. I'm hoping what I've described below can work. Basically, I'm trying to create a situation where the only thing the player will ever choose to build is going to be the freight train (which will be built in cities) or various aircraft (which will be built in airfields).

I go into detail below. @Prof. Garfield is the below generally possible what I've outlined? I think it is fairly intuitive and should allow different "pathways."

Urban Area: Provides workers that combine with electric power plants to make everything below function. If one were to destroy all urban areas and electric power plants on the map, nothing else would work. Suppose there are 100 total Urban Areas/Electric Power Plants on the map. If 50% of them were destroyed, then all production of shields and fuel below would be cut by 50%. Restored by building the three “happiness” city improvements (temple, coliseum, cathedral renamed).

Electric Power Plant: See urban description above. Restored by building the three “trade” city improvements (marketplace, bank, stock exchange renamed).

Synthetic Fuel Refinery: One of two units (along with oil refineries) that produce “fuel” (which is a counter in this scenario). Will create a fuel train that will deliver fuel to oil storage tanks. Total HP of all synthetic fuel refineries and oil refineries taken into consideration to see how much fuel is produced. When destroyed on a turn, will regenerate 1-3 turns later at same spot, with sliver of health which will need to be restored over time.

Oil Refinery: See synthetic fuel refinery above.

Fuel Storage: Holds the fuel that refineries produce. There are multiple oil storage tanks in each region. Each region has a counter of the total fuel available in it. This is deducted by conducting operations with aircraft in that region. If there is not enough fuel available in the region, operations are severely curtailed (units will have their MP cut in half).

Rubber Factory: One of four prime resource factories (along with steel, aluminum, and ball bearings) that impact production values/costs. Total hitpoints of all such units is taken into consideration. For example, if there are 1000 total hitpoints of these units and only 750 have health, than the cost of building every item (train as well as aircraft) would be increased by 25%.

Steel Factory: See rubber factory.

Aluminum Factory: See rubber factory.

Ball Bearings Factory: See rubber factory.

Engine Factory: Two functions. First, it directly impacts the extent of shields available to a city. Restored by building a production city improvement (factory, power plant, manufacturing plant renamed). Scenario will start without every city having all of these available, but they can be invested in. The second function is that engine factories + aircraft factories determine how fast aircraft heal/restore hitpoints. More of these will allow aircraft to heal quicker. Note, because these are buildable in the scenario, it’s actually possible to get aircraft to heal in 1 turn eventually if you build enough of these and they aren’t destroyed.

Aircraft Factory: See engine factory.

Armaments Factory: Two functions. First, it directly impacts the extent of shields available to a city. Restored by building a production city improvement (factory, power plant, manufacturing plant renamed). Secondly, it impacts how quickly anti-air units heal and are replaced when they are destroyed.

Port Facility: Many trains originate here, especially in England, though Germany has a few as well. Destroying them destroys a source of “free” trains that aren’t produced by a city.

Convoy Route: Affects how many “free” trains show up in the port facilities above. Based on hitpoints of the convoy routes.

Railyards: Destroying these creates breaks in the rail line system that trains can’t pass, preventing them from bringing fuel or supplies from one location to another.

Freight Train: Built in cities with production (shields). The game will automatically move them along supply routes to airfields where they can be disbanded to build aircraft.

Fuel Train: Is built at oil and synthetic fuel refineries and will travel to oil storage tanks in various regions automatically.

U-Boat Pens: Impacts the number of free trains the Allies receive from their ports. Very tough target. Total impact is based on hitpoints of the targets, so if there was 100 hitpoints total and 50 of them were remaining, the Allies would get 50% more trains at their ports on any given turn.

V-Weapon Site: Impacts cost of special German fighters (basically anything with a jet engine or any other sort of wunderwaffen).

 

[Prof. Garfield]

@JPetroski

I like all these mechanics, and I think that they will be relatively easy to do in code. I will note that engine and armament factories are both tied to factory/powerplant/manufacturingplant improvements. How would that work? Did you mean to tie one or the other to something else?

A minor point, but it might also make sense to tie the progress of the war to armament production.

Urban Area: Provides workers that combine with electric power plants to make everything below function. If one were to destroy all urban areas and electric power plants on the map, nothing else would work. Suppose there are 100 total Urban Areas/Electric Power Plants on the map. If 50% of them were destroyed, then all production of shields and fuel below would be cut by 50%. Restored by building the three “happiness” city improvements (temple, coliseum, cathedral renamed).

Electric Power Plant: See urban description above. Restored by building the three “trade” city improvements (marketplace, bank, stock exchange renamed).

I think it probably makes sense to have some extra "capacity" in terms of urban areas, so bombing housing isn't immediately as effective as bombing a power plant. Maybe this just means that a lot of towns have 3 urban areas, but only one power plant.

 

[JPetroski]

I will note that engine and armament factories are both tied to factory/powerplant/manufacturingplant improvements. How would that work? Did you mean to tie one or the other to something else?

I think I just worded it awkwardly - engine, aircraft, and armaments would each have one industrial improvement assigned to them, like in the last version. So engine = factory, armament = manufacturing, aircraft = powerplant (or what have you). Although I suppose maybe if this is one of the improvements that most cities won't have at the start of the game, maybe I should add an "avionics factory" in for an industrial improvement, and then have the armament be for some other improvement (or none) since it will be how we determine how quickly flak regenerates/restores. I'll probably do that, thinking it through. We have the unit slot and it'll make the concept much more straight forward.

Also - I just want to confirm that one unit (urban) can be associated with three different improvements (temple, coliseum, cathedral) that are uniquely destroyed depending on the units placement on the map (so for example, urban unit at 2,14,3 might destroy the cathedral in Koln but the one at 4, 18, 3 would take out the temple). Is this simple enough and straight forward or would it be much easier to just have three urban units? We have **plenty** of unit slots left, even with my going crazy on the aircraft, so I'm not opposed to it. Just let me know.

I think it probably makes sense to have some extra "capacity" in terms of urban areas, so bombing housing isn't immediately as effective as bombing a power plant. Maybe this just means that a lot of towns have 3 urban areas, but only one power plant.

Well, powerplants were all over the place. After the war the Allies concluded they might have had more success concentrating on them, but there were just so many everywhere that they didn't. But there will be a ton of urban and powerplant units out there. Figure 3x urban for every city, right from the start, and then probably a fairly comparable number of power plants. They're at the bottom of the food chain and the whole thing collapses if they're taken out, so they are going to be everywhere. I think for capacity we could consider 76% (or whatever) the same as 100% but at 75% you get a penalty. Something like that.

I do have a few coding requests that would be very helpful to me in getting the map set up and since I figure you're probably tweaking code from the earlier versions of this to make it more straightforward, I'd see if you have it or can get it built earlier rather than trying to figure out where it is in the old jumble.

1. Can you please provide code that when a city is built on map 0 it will also build on map 2 with the same name but (N) behind it as you did last time? Note we need to use all 4 maps now because the AI in HOF was idiotic and I guarantee you if we don't have a low and high alt night, the AI Lancasters will spend most of their time attacking airfields.

2. Can you please establish the code where building different improvements will place the urban and industrial terrains? I can tweak it when I figure out what terrain slots each will have, but I need these terrains placed on all 4 maps please. I do need the capacity for urban improvements to modify more than 1 tile please.

With these two pieces I should be able to break ground and at least get the cities situated.

Also something to think about that we will definitely need but not necessary immediately:

*We will need ground units to have a mirrored equivalent on both map 0 (low day) and 2 (low night) meaning that they mirror hit points, location, MP, etc.
*While I originally thought "we can just have some units like radar be persistent and unkillable and the human will know not to bother with them when they are slivers," the AI is going to be dumb about this and keep attacking them, so we need a delay function system where units will restore at their old place after a set number of turns after being destroyed (likely connected somehow to the overall industry above).
*While I do think we should endeavor to have this be "hands off trains" I also think some people might want to micromanage that. I have the terrain space available to make "railtrack" to enable that to happen easily. But the "mirror image" point is going to need to apply to the trains even if the player moves them by themselves. So, move a train on the low daylight map, and the same train moves on the low nighttime map. Disband it, they both disband, etc.

Just some things I thought of earlier.

 

[Prof. Garfield]

Also - I just want to confirm that one unit (urban) can be associated with three different improvements (temple, coliseum, cathedral) that are uniquely destroyed depending on the units placement on the map (so for example, urban unit at 2,14,3 might destroy the cathedral in Koln but the one at 4, 18, 3 would take out the temple). Is this simple enough and straight forward or would it be much easier to just have three urban units? We have **plenty** of unit slots left, even with my going crazy on the aircraft, so I'm not opposed to it. Just let me know.

One "urban" unitType can be used for all 3 (or more) improvements. I did the work in my strategic targets module, so it is "free" now.

I do have a few coding requests that would be very helpful to me in getting the map set up and since I figure you're probably tweaking code from the earlier versions of this to make it more straightforward, I'd see if you have it or can get it built earlier rather than trying to figure out where it is in the old jumble.

I figure that there have been enough changes that it makes sense to start from a "new" template file, rather than trying to change the existing code. I can still bring stuff in wholesale if the mechanic is the same or similar.

1. Can you please provide code that when a city is built on map 0 it will also build on map 2 with the same name but (N) behind it as you did last time? Note we need to use all 4 maps now because the AI in HOF was idiotic and I guarantee you if we don't have a low and high alt night, the AI Lancasters will spend most of their time attacking airfields.

Here's a snippet of code from MechanicsFiles\airfieldMechanics.lua

function discreteEvents.onCityFounded(city) 
    local x,y,z = city.location.x,city.location.y,city.location.z
    local lowTile = civ.getTile(x,y,0)
    local highTile = civ.getTile(x,y,1)
    local nightTile = civ.getTile(x,y,2)
    local oldLow = lowTile.baseTerrain
    local oldHigh = highTile.baseTerrain
    local oldNight = nightTile.baseTerrain
    local activeCityTile = city.location
    local eventCityTile = nightTile
    if activeCityTile == nightTile then
        eventCityTile = lowTile
    end
    local eventCity = nil
    if not eventCityTile.city then
        eventCity = civ.createCity(city.owner,eventCityTile)
        if eventCityTile == nightTile then
            eventCity.name = city.name.." (N)"
        else
            eventCity.name = city.name
        end
    end
    if activeCityTile == nightTile then
        city.name = city.name.." (N)"
    end
    city:addImprovement(object.iAirbase)
    -- the cityCancelled() function is executed if the player
    -- decides not to found the city after all
    -- (so you can undo terrain changes, etc.
    local function cityCancelled()
        lowTile.baseTerrain = oldLow
        highTile.baseTerrain = oldHigh
        nightTile.baseTerrain = oldNight
    end
    return cityCancelled
end

I removed a couple things, but I think it will still work (or, at least, be really close to working).

2. Can you please establish the code where building different improvements will place the urban and industrial terrains? I can tweak it when I figure out what terrain slots each will have, but I need these terrains placed on all 4 maps please. I do need the capacity for urban improvements to modify more than 1 tile please.

I'll make that the priority once the rules are put together enough that I can start a new version of the template. MechanicsFiles\targetSettings does this in the existing version of the scenario, but I'll have to redo it with the new terrain associations. Also, I think with the new system, we don't have to try to "match" aircraft factories with airfields, so some of the code can go.

 

[Prof. Garfield]

*We will need ground units to have a mirrored equivalent on both map 0 (low day) and 2 (low night) meaning that they mirror hit points, location, MP, etc.

I think it will be easier to have a generic "always there" unit (say "base security") in the air bases, and use onChooseDefender to allow selection from both tiles. That way, the same unit can effectively be on both maps.

*While I originally thought "we can just have some units like radar be persistent and unkillable and the human will know not to bother with them when they are slivers," the AI is going to be dumb about this and keep attacking them, so we need a delay function system where units will restore at their old place after a set number of turns after being destroyed (likely connected somehow to the overall industry above).

The delayedAction module should be able to handle this without much difficulty.

*While I do think we should endeavor to have this be "hands off trains" I also think some people might want to micromanage that. I have the terrain space available to make "railtrack" to enable that to happen easily. But the "mirror image" point is going to need to apply to the trains even if the player moves them by themselves. So, move a train on the low daylight map, and the same train moves on the low nighttime map. Disband it, they both disband, etc.

For trains, I'd say at the end of the player's turn, have a 50-50 chance for each train to be moved to the night map until the next turn. Better still, only let the player set broad targets, and trains just get placed randomly, with rough correspondence to how busy a particular bit of track would be.

 

[JPetroski]

For trains, I'd say at the end of the player's turn, have a 50-50 chance for each train to be moved to the night map until the next turn. Better still, only let the player set broad targets, and trains just get placed randomly, with rough correspondence to how busy a particular bit of track would be.

The only problem with the trains is that they are what is used to disband and create an air unit. Here's a good question:

-Can we have a night air unit that is built on the day map automatically teleport to the night map BUT ONLY triggered by its production? Because I want Germany to be able to commit night fighters to daylight ops if they would like, so we can't just use a simple onActivate. So basically, unit already exists on day map because you specifically moved it there = it will stay there. But new "night" units built on day map teleport by default to the night map (where they can then be moved).

If we can achieve this, then I suppose there's absolutely no need to duplicate/mirror the trains.

I think it will be easier to have a generic "always there" unit (say "base security") in the air bases, and use onChooseDefender to allow selection from both tiles. That way, the same unit can effectively be on both maps.

That works fine by me - I was thinking about having 3 types of flak:

Light flak - present at all airfields (hub & spoke)
Medium flak - present at "Hub" airfields
Heavy flak - should move from city to city

The light and medium would always be at the airfields they start the game with and would never leave so if you can have the flak on map 0 defend / react / help air units on map 2 that's a perfectly acceptable solution to me.

 

[Prof. Garfield]

-Can we have a night air unit that is built on the day map automatically teleport to the night map BUT ONLY triggered by its production?

I just tested this, and yes, we can immediately teleport a unit to a different map using onCityProduction. Of course, if the whole trains thing is automated, then shields can be given to the night airfield anyway.

 

[JPetroski]

Here's what I have for the units. The clipped wing Spit and many of the 109s are (hopefully) placeholders if our good artists come to the rescue. I'm at a loss for what else is really necessary but since I can't do much with it this weekend I thought I'd put it out there for anyone looking at it.

You'll note I've gone a little wild and crazy with the flak, but I figure some places (like Berlin) can have the heavier stuff. I threw a flak train in just because there were so many of them. I never actually built one in the last version but on the other hand if flak isn't actually being built in this one and just kind of exists from the get go (or, at least, isn't built in the traditional sense), I don't think there's harm in it.

I am thinking maybe we have the armaments factory be tied to some (non industry) improvement, and perhaps have many of the cities have one associated with them at the start, and then maybe the ones that don't get a new heavy flak unit when it is built, that can then move around with the system we intend. This way you could increase flak defenses without making it completely crazy like in the last version as you'd always be capped at the total # of cities (also meaning, you could either choose to protect everything **slightly** but the second you double up somewhere else, there's another spot that has no flak protection). The Germans did invest a great deal of effort in expanding their flak defenses so I think this is a good compromise where it shouldn't turn into a Tempest-fest late game (especially if the bigger stuff doesn't go to airfields ever).

Anyway folks if you have a chance to look at this, it would be a most convenient time to point out stuff I'm missing now, before I start on the rules (hopefully next week).

@Prof. Garfield - that Wellington RCM is meant to be a radar jammer, btw. Not sure if we can get that working or not but I was thinking that radar can't see in a zone around it.

Spoiler :

Chain Home Radar
Engineer
Freya Radar
Wurzburg Radar
Barrage Balloon
Urban Area
Electric Power Plant
Synthetic Fuel Refinery
Oil Refinery
Fuel Storage Silos
Rubber Factory
Steel Factory
Aluminum Factory
Ball Bearings Factory
Engine Factory
Aircraft Factory
Avionics Factory
Armaments Factory
Port Facility
Convoy Route
Railyards
Freight Train
Fuel Train
U-Boat Pens
V-Weapons Site
German Division
Allied Division
MS 406
Bf 109G-6
Bf 109G-6/R6
Bf 109G-10
Bf 109G-10/R6
Bf 109G-14
Bf 109G-14/R6
Bf 109K-4
Fw 190A-5
Fw 190A-6
Fw 190A-6/R1
Fw 190A-8
Fw 190A-8/R1
Fw 190D-9
Ta 152
Bf 110G-2
Bf 110G-2/R3
Bf 110G-4
Me 210
Me 410
Me 410B-2/R3
He-219
Do 217N-2
Ju 88C-6
Ju 88G
He 162A
Me 163
Me 262
Ta 183
Fw 190F
Do 335
He 177
He 277
Arado 234
Go 229
Ju-188 Recon
Experten
Egon Mayer
Hermann Graf
Josef Priller
Adolf Galland
Gunther Rall
Walter Nowotny
H.W. Schnaufer
Erich Hartmann
SAVE - LUFTWAFFE
SAVE - LUFTWAFFE
SAVE - LUFTWAFFE
SAVE - LUFTWAFFE
SAVE - LUFTWAFFE
SAVE - LUFTWAFFE
SAVE - LUFTWAFFE
V-1 Rocket
V-2 Rocket
Spitfire V
Spitfire V Lf
Spitfire IX
Spitfire XIV
P-47D-6 Thunderbolt
P-47D-15 Thunderbolt
P-47D-20 Thunderbolt
P-47D-25 Thunderbolt
P-47M Thunderbolt
P-38H Lightning
P-38J Lightning
P-38L Lightning
P-51B Mustang
Mustang III
P-51D Mustang
Mustang IV
Beaufighter
Mosquito N.F.. II
Mosquito N.F. XIX
P-61A Black Widow
P-80
Meteor
Whirlwind IA
Huricane IV (jabo)
Mustang I
Typhoon IB
Tempest V
P-38J Lightning (jabo)
P-38L Lightning (jabo)
P-47D-15 Thunderbolt (jabo)
P-47D-20 Thunderbolt (jabo)
P-47D-25 Thunderbolt (jabo)
P-51B Mustang (jabo)
Mustang III (jabo)
P-51D Mustang (jabo)
Mustang IV (jabo)
332nd Fighter Group
Francis Gabreski
George Preddy
John Braham
Johnnie Johnson
US Ace
UK Ace
Baltimore V
Boston III
Wellington
Stirling
Halifax
Lancaster
Mosquito B.IV
Wellington RCM
A-20G Havoc
A-26B Invader
B-25Mitchell
B-26 Marauder
B-17F Fortress
B-17F Fortress (damaged)
B-17G Fortress
B-17G Fortress (damaged)
B-24 Liberator
Pathfinder B-17
Pathfinder B-24
15th AF B-25
15th AF B-24
Med Air Beaufighter
Med Air Wellinglton
Yak-3
La-7
Il-2
Photo Recond
SAVE - ALLIES
SAVE - ALLIES
SAVE - ALLIES
SAVE - ALLIES
SAVE - ALLIES
SAVE - ALLIES
SAVE - ALLIES
SAVE - ALLIES
SAVE - ALLIES
SAVE - ALLIES
SAVE - ALLIES
2cm Flakvierling
3.7cm Flak 36
8.8cm Flak 18
12.8cm Flak 40
Flak Train
Polsten 20mm
Bofors 40mm (UK)
Bofors 40mm (US)
3.7" Flak

 

[JPetroski]

@Prof. Garfield what parts of rules are you going to need completed first? I have all the units in there as well as civs and was planning on getting the terrain and improvements sorted away before breaking ground. The tech tree is a totally different monster, but I don't *think* you need that for anything immediately, right?

 

[Prof. Garfield]

@Prof. Garfield what parts of rules are you going to need completed first? I have all the units in there as well as civs and was planning on getting the terrain and improvements sorted away before breaking ground. The tech tree is a totally different monster, but I don't *think* you need that for anything immediately, right?

I should be able to get to work without the tech tree, and I can regenerate that section of the object.lua file once it is sorted out. Unless you object, I'm going to use the same repository for this new version of OTR5, so you should copy anything you want to keep out of your copy of the folder, since it will get replaced upon update. (That said, you should be able to use GitHub Desktop history to restore the older version, since that's one of the functions of Git.)

 

[JPetroski]

It's fine by me if that works best. I'm calling this "OTR Redux" but it doesn't matter what the folder says for now.

I've placed the cities (though not the airfields yet). The map is considerably larger than the last one. I did place quite a few cities because I figure we are planning on totally avoiding the need to move any ground units whatsoever, meaning the only "clicks" a player should have to do each turn are:

1. Decide if a city should change its production
2. Move air units around

Even so, I think it would be a very good idea if we could give players a hand with city production with some sort of system that will prioritize production, probably per region, to help out. Basically, I'm thinking of a situation where a player might be able to set overall production priorities and then have cities in a region more or less produce it. An example might be:

"How should we prioritize aircraft replacements in Northwest Germany?" (FOR AIRFIELDS)
1. Prioritize light fighters (will build the best 109 series available)
2. Prioritize interceptors (will build the best 190 series available)
3. Prioritize heavy fighters (will build the best heavy fighter/bomber destroyer available)
4. Prioritize night fighters (will build the best night fighter available)
5. Prioritize bombers (will build the best bomber available)
6. Prioritize jet fighters (will build the best jet available)
7. Prioritize wunderwaffen (will build the best rocket/guided bomb available)

or

"How should we prioritize factory production in Northwest Germany?" (FOR CITIES)
1. Prioritize production (freight trains)
2. Enhance production capacity (will try to build improvements that would increase shields, but build trains if none are available to city)
3. Enhance fuel refining capacity (will try to build improvements that would increase trade, but build trains if none are available to city)
4. Focus on researching new weapons (will try to build improvements that would increase science, but build trains if none are available to city)
5. Rebuild housing (will try to build improvements that would increase happiness, but build trains if none are available to city)

I think that this would be reasonable for a scenario like this, and maybe we could make 8 or so regions (NW, SW, SE, NE and Central Germany, Eastern France, Western France, Lowlands). I think this would be a welcome option for people who don't want to have to micromanage 200+ cities, though that option would always be there if you really felt the need.

Honestly I'd love an option like this for scenarios like Imperialism and such too.

 

[JPetroski]

@Prof. Garfield I was able to get this working to build a city and add an airfield improvement/SDI defense to it but it doesn't actually create a city on the night map with the correct name. For example, if I found a city and name it "Test" it only comes up as "(N)" on the night map instead of "Test (N)". I tried moving the quotation mark around but that didn't seem to help. Any thoughts?

function discreteEvents.onCityFounded(city)
local x,y,z = city.location.x,city.location.y,city.location.z
local lowTile = civ.getTile(x,y,0)
local highTile = civ.getTile(x,y,1)
local nightTile = civ.getTile(x,y,2)
local oldLow = lowTile.baseTerrain
local oldHigh = highTile.baseTerrain
local oldNight = nightTile.baseTerrain
local activeCityTile = city.location
local eventCityTile = nightTile
if activeCityTile == nightTile then
eventCityTile = lowTile
end
local eventCity = nil
if not eventCityTile.city then
eventCity = civ.createCity(city.owner,eventCityTile)
if eventCityTile == nightTile then
eventCity.name = city.name.." (N)"
else
eventCity.name = city.name
end
end
if activeCityTile == nightTile then
city.name = city.name.." (N)"
end
city:addImprovement(object.iAirbase)
for _,radiusTile in pairs(gen.cityRadiusTiles(city)) do
if factoryAirfield.needsAirfield(radiusTile) then
factoryAirfield.linkFactoryToAirfield(radiusTile,city)
break
end
end
-- the cityCancelled() function is executed if the player
-- decides not to found the city after all
-- (so you can undo terrain changes, etc.
local function cityCancelled()
lowTile.baseTerrain = oldLow
highTile.baseTerrain = oldHigh
nightTile.baseTerrain = oldNight
factoryAirfield.unlinkFactoryFromAirfield(city)
if eventCity then
factoryAirfield.unlinkFactoryFromAirfield(eventCity)
civ.deleteCity(eventCity)
end
end
return cityCancelled

end

 

[Prof. Garfield]

@Prof. Garfield I was able to get this working to build a city and add an airfield improvement/SDI defense to it but it doesn't actually create a city on the night map with the correct name. For example, if I found a city and name it "Test" it only comes up as "(N)" on the night map instead of "Test (N)". I tried moving the quotation mark around but that didn't seem to help. Any thoughts?

Was there a suggested city name? I'm guessing that city.name is the name that is suggested by city.txt, not the name you type into the name box. Let me see what I can do.