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 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?
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).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.
-- 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.
--
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.
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.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.
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.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 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 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.
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.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 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.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.
Here's a snippet of code from MechanicsFiles\airfieldMechanics.lua1. 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.
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'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.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 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.*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.
The delayedAction module should be able to handle this without much difficulty.*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).
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.*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.
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.
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.-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 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.)@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?
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.@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?