Over the Reich - Creation Thread

[JPetroski]

As you said you wouldn't be making changes I went back and made one more after thinking about it in the readme... All strategic bombers now have a range of 4 for defensive fire, which will enable large formations spread out over some space to provide mutually-supportive fire.

Edit - I may make further changes.

 

[Prof. Garfield]

A range of 4 seems rather high for a bomber reaction. That would basically mean that all of the formation targets the first few fighters that try to intercept (until they all run out of reactions).

Do a search for specialNumbers.reactionRangeToCheck and increase it to 5 or 6 if you plan to have a reaction range of 4 in some cases.

Keep the events as long as you need.

 

[JPetroski]

Well, I have the amount of damage they have down to 1 or 2 hit points per successful attack. We can always change it if necessary. I might make 4 exclusive to the B-17G to represent the bomber box tactic that was developed. This is just another way of making the B-17s as fearsome as they were to attack (also another reason you might build some in the next playtest).

--American heavy bombers will only fire defensive fire at high altitude as another incentive to keep them there
canReact[unitAliases.B17F.id] = {maxAttacks = 2, range = 2, highMap = reactionGroups.germanInterceptors}
canReact[unitAliases.B17G.id] = {maxAttacks = 2, range = 4, highMap = reactionGroups.germanInterceptors}
canReact[unitAliases.B24J.id] = {maxAttacks = 1, range = 1, highMap = reactionGroups.germanInterceptors}

--British bombers have lower range for defensive fire and this isn't generally as effective
canReact[unitAliases.Stirling.id] = {maxAttacks = 1, range = 1, nightMap = reactionGroups.germanInterceptors}
canReact[unitAliases.Halifax.id] = {maxAttacks = 1, range = 1, nightMap = reactionGroups.germanInterceptors}
canReact[unitAliases.Lancaster.id] = {maxAttacks = 1, range = 1, nightMap = reactionGroups.germanInterceptors}

--German bombers can defend as well, but on any map because the Germans would be more likely to use these in tactical role (also they're unlikely to have many so this shouldn't imbalance things)
canReact[unitAliases.He111.id] = {maxAttacks = 1, range = 1, sameMap = reactionGroups.alliedFighters}
canReact[unitAliases.Do217.id] = {maxAttacks = 1, range = 1, sameMap = reactionGroups.alliedFighters}
canReact[unitAliases.He277.id] = {maxAttacks = 1, range = 1, sameMap = reactionGroups.alliedFighters}

 

[Prof. Garfield]

I'm currently re-writing Radar (nothing that affects Events.lua just yet, but be sure to let me know when I can have them again).

I have two ways I can leave a radar 'mark'.

One is to use the system we've been currently using, which is to leave pollution (or railroad, farmland, fortress) actually on the map until it is specifically removed by a function. A 'picture' (i.e. placing a unit temporarily) is taken of the square to show the radar when it is there, and when it is removed, so that the radar user knows where the radar marks are.

The other method I have is to put down the radar mark and take a picture, and then remove radar mark. Since the map will show the last seen terrain improvements, the radar will remain visible to the player, and we don't have to worry about removing the radar afterward, nor about settlers/engineers making terrain improvements that don't persist (since removing the radar mark will restore terrain to its earlier improvements).

However, the 'new system' means that no radar mark will be visible once it has been within sight range of an aircraft (which could be a problem for imprecise radar or invisible targets), and there is no way to erase a previous turn's radar mark without sending an aircraft to 'investigate.'

I'm slightly leaning towards 'old system' so that the radar marks are persistent, but I'd like to get your take. While it might be useful to provide scenario makers with both types of radar functionality, they are sufficiently different that I can't offer a true/false choice in the same 'library'.

 

[JPetroski]

I'm very pleased with the way it is currently working. I can shoot you over the events in another hour or so.

 

[JPetroski]

Attached are the events. I think the radar works very well the way it is, especially since I hope we will have imprecise radar targets soon enough (although that looks like it'll mean more table work for me! But that is OK and actually enjoyable).

 

[Prof. Garfield]

I don't have any tables for you to fill in yet, but I can let you start imagining what you can do with the functionality you'll have (or complain that it is too complicated and/or missing something important). I have much (but not all) of the description of functionality complete.

-- Radar functionality will be governed by 2 tables
-- One table will deal mostly the radar using unit itself,
-- The other table will deal with how units are detected (or not detected) by radar

-- Radar User Details
-- Indexed by unit type id number
-- absent unit type means it is not a radar user of any kind
-- .keyCode = int ==> keyId for radar activation (specialNumbers.primaryAttackKey and specialNumbers.secondaryAttackKey )
-- .baseRangeTable = integer or table of 'rangeThreshold's
-- where rangeThreshold = {threshold, rangeIncrease}, 0<=threshold<=1, rangeIncrease = number > 0
-- A radar user's maximum range is determined by a 'random roll' between 0 and 1, lower being better for the radar user
-- If the roll is below the threshold of a rangeThreshold, add the rangeIncrease to the unit's radar range
-- If fractional range (after .baseRangeTable and other applicable bonuses), then round down
-- If integer, use fixed base range regardless of 'Roll'
-- .techRangeBonus = {technologyObject, rangeThreshold} or {technologyObject, table of rangeThreshold} or table of same
-- If the radar user has the technology corresponding to the technologyObject, merge the rangeThreshold (or table of them) into
-- the baseRangeTable for determining the radar range
-- absent means no bonus for technologies
-- Radar is assumed to work on the sameTime basis (i.e. detects on night map or on both day maps, depending on where the user is)
-- Override this with one of the following keys
-- .allMaps = true or false (nil means false)
-- If true, radar from this unit detects on all maps
-- .sameMap = true or false (nil means false)
-- if true, radar from this unit only detects on the same map (might be useful at sea or something)
-- .errorThresholdPerfect = integer (default 1)
-- .errorThresholdClose = integer (default 2)
-- .errorThresholdDetected = integer (default 3)
-- see Radar Detectability Details for info

-- Radar Detectability Details
-- Indexed by the (possibly) detected unit's type id number
-- absent units are not detected by any radar

-- When a radar user 'sweeps' a tile containing units, a detection 'error number' will be calculated,
-- compared with the error thresholds of the radar user, with the following consequences
-- If error number <= errorThresholdPerfect, then a radar marker is placed on that tile
-- If errorThresholdPerfect <error number <= errorThresholdClose,
-- a radar marker is placed somewhere on the 3x3 diamond that surrounds the tile in question,
-- 1 in 9 chance for each tile
-- If errorThresholdClose <error number <= errorThresholdDetected,
-- a radar marker is placed somewhere on the 5x5 diamond that surrounds the tile in question,
-- 1 in 25 chance for each tile
-- if errorThresholdDetected < error number
-- then the radar reports a false negative

-- When the tile is swept, a 'random roll' is made (lower is better for the radar user).
-- Based on the random roll, the radar user, and discovered technologies, a base 'detection error'
-- is computed for each unit (using the same random roll). The unit with the base lowest detection error
-- (low detection error is good for radar user) defines the base detection error number of the tile
-- in addition, each unit may have some 'volume detectability', which is subtracted off the base detection error
-- (this way, one plane might slip by, but 20 will probably be noticed, unless they have very low volume detectibility)

 

[JPetroski]

This looks like some absolutely brilliant work that is going to make the night game very interesting indeed. It's going to be important that we make the night attacks relevant for a long time to ensure that this gets good use. Perhaps a night target is worth 2 or even 3 times as many points as a day target? What is your take on that having played the Allies? Would you then pretty much abandon day attacks or would you try to balance the two? The day attacks would of course destroy Germany's production capacity while the night ones would move you closer to D-Day sooner.

If we can't balance with the points then we need some other method. Perhaps removing some of the techs that make the happiness improvements function as well once a certain number of successful night raids are done?

 

[Prof. Garfield]

I haven't really been thinking in terms of points vs strategy, so I'm not sure if a point imbalance would make me change strategy.

If we can't balance with the points then we need some other method. Perhaps removing some of the techs that make the happiness improvements function as well once a certain number of successful night raids are done?

Two ideas spring to mind. One is to tie the ability to build industry/refineries/aircraft factories to the number of happiness improvements in the city. So, a city might be able to carry on using existing industry after its housing is removed, but it couldn't build new factories until the housing situation is remedied. This would allow the RAF to make sure a down city stays down for longer, even after the Germans switch to high luxury production.

The other is to have a small chance that terror bombing actually works (either to force a surrender, to force a draw offer, or to do some other bad thing to the victim). This would also make it reasonable for the German player to try to use V1 and V2s against England (to try to scrape a victory/draw when things are falling apart), and for the Allied player to expend resources going after the launch pads.

 

[Prof. Garfield]

You have the events.

New Radar is implemented, probably with more customization than is actually needed. Search for "Radar Tables" to find the top of that section (currently line 1412), along with a description of how to use the functionality. I've done some testing, but let me know if anything breaks, or if I haven't been clear enough on how to use some functionality.

I also made it so that air units in cities (i.e. cities and airfields in this scenario) don't react to anything ever, and take no bystander damage form anything.

 

[JPetroski]

Two ideas spring to mind. One is to tie the ability to build industry/refineries/aircraft factories to the number of happiness improvements in the city. So, a city might be able to carry on using existing industry after its housing is removed, but it couldn't build new factories until the housing situation is remedied. This would allow the RAF to make sure a down city stays down for longer, even after the Germans switch to high luxury production.

The other is to have a small chance that terror bombing actually works (either to force a surrender, to force a draw offer, or to do some other bad thing to the victim). This would also make it reasonable for the German player to try to use V1 and V2s against England (to try to scrape a victory/draw when things are falling apart), and for the Allied player to expend resources going after the launch pads.

I really like these two ideas. Especially the first one. The British were, after all, "de-housing." This will also ensure that small cities (barring a few "special ones" in place at the start of the scenario) can't build massive industry, so the Germans will have a reason to build housing for new workers. I can implement the first one easily enough by myself and will do so before I return the events.

 

[JPetroski]

How do I add a second entry into this?

local RUDT = radarUserDetailsTable -- can use either form to make edits
RUDT[unitAliases.EarlyRadar.id] ={ keyCode = specialNumbers.primaryAttackKey,
baseRangeSchedule = {{.5,2.5},{1,6}},
techRangeBonus = {{tech = techAliases.AdvancedRadarI, rangeSchedule = {{1, .5}}},
{tech = techAliases.AdvancedRadarII, rangeSchedule = {{1,1.5},{.25, 1.5}}}},
allMaps = true,
errorThresholdPerfect = 1,
errorThresholdClose = {{tech = techAliases.FortiesI, bonus = 2},{tech = techAliases.AdvancedRadarII, bonus = 1}},
errorThresholdDetected = {{tech = techAliases.FortiesI, bonus = 3},
{tech = techAliases.AdvancedRadarI, bonus = 1},
{tech = techAliases.AdvancedRadarII, bonus = 1},},
moveCost = testingMoveCost or 4,
}

I'm not really sure where I start and end copying and pasting with this new (to me) format.

 

[Prof. Garfield]

RUDT[unitAliases.TheNextRadarUnit.id] = { stuff}
or
radarUserDetailsTable[unitAliases.TheNextRadarUnit.id] = {stuff}

both count as a new entry. Replace 'stuff' with the keys and values for the radar unit specification, just as you did before with reaction units.

If this didn't answer your question please say so and I'll try to explain more.

 

[JPetroski]

Busy week at work without too much of a chance to work on this but I'm hoping to dive into it tonight and have something to you shortly!

 

[Prof. Garfield]

Take your time. When you have something, you have it. I don't have any changes prepared for the events anyway.

 

[JPetroski]

When I go to test this by pressing backspace, it creates a damaged B-17G on the same tile as the radar unit:

RUDT[unitAliases.MosquitoXIII.id] ={ keyCode = specialNumbers.secondaryAttackKey,
baseRangeSchedule = {{.5,1},{1,3}},
techRangeBonus = {{tech = techAliases.AdvancedRadarI, rangeSchedule = {{1, 1}}},
                  {tech = techAliases.AdvancedRadarII, rangeSchedule = {{1,1}}}},
sameMap = true,
errorThresholdPerfect = 1,
errorThresholdClose = {{tech = techAliases.FortiesI, bonus = 2},{tech = techAliases.AdvancedRadarII, bonus = 1}},
errorThresholdDetected = {{tech = techAliases.FortiesI, bonus = 3},
                          {tech = techAliases.AdvancedRadarI, bonus = 1},
                          {tech = techAliases.AdvancedRadarII, bonus = 1},},
moveCost = testingMoveCost or 10,

 

[JPetroski]

Also, the RIDT table needs to be populated with each and every aircraft in the game that I want to be detected by radar, correct?

 

[Prof. Garfield]

When I go to test this by pressing backspace, it creates a damaged B-17G on the same tile as the radar unit:

My guess is that the damaged B17G took the unit slot of the Radar that the MosquitoXIII was meant to fire, and that the MosquitoXIII is still in the munition table.

Also, the RIDT table needs to be populated with each and every aircraft in the game that I want to be detected by radar, correct?

Yes, but if you have a default radar detectablility setting that will work for most units (or a couple of them for easily determined characteristics like land, sea, air), we could use a 'for' loop to populate most of the table, so you don't have to do it manually.

 

[JPetroski]

This has not been a productive week for me

I'm trying to keep the radar table pretty simple. Basically, anything flying during the day should be spotted, period. There's no getting past it/no stealth aircraft yet, and radar also can represent ground observers. It would be great if we could have two for loops - one that is pretty simply "will be detected" and one that is simply "won't be detected" (for Photo Recon, which probably needs to be invisible to stand a chance).

I believe the below is basically saying "these bombers have the same detect-ability however it is modified exclusively by if the other side has researched better night fighter tech. So for example if the Germans have Nightfighters III they'll be able to get a bonus spotting Lancasters until the Allies also get it?

RIDT[unitAliases.Stirling.id] = {baseError = {{.25, 1.2},{.5, 2},{.75, 2}},
volumePenalty = 0.07,
radarTech = {tech = techAliases.NightFightersI, detectors = {unitAliases.EarlyRadar},
                errorSchedule = {{0,-2},{.75,2}}, volumePenalty = 0.03},
intruderTech = {tech = techAliases.NightFightersI, detectors = {unitAliases.EarlyRadar},
                errorSchedule = {{0,2},{.75,-2}}, volumePenalty = -0.03, counterTo = techAliases.NightFightersI},
             
}
            RIDT[unitAliases.Halifax.id] = {baseError = {{.25, 1.2},{.5, 2},{.75, 2}},
volumePenalty = 0.07,
radarTech = {tech = techAliases.NightFightersI, detectors = {unitAliases.EarlyRadar},
                errorSchedule = {{0,-2},{.75,2}}, volumePenalty = 0.03},
intruderTech = {tech = techAliases.NightFightersII, detectors = {unitAliases.EarlyRadar},
                errorSchedule = {{0,2},{.75,-2}}, volumePenalty = -0.03, counterTo = techAliases.NightFightersII},
             
}
RIDT[unitAliases.Lancaster.id] = {baseError = {{.25, 1.2},{.5, 2},{.75, 2}},
volumePenalty = 0.07,
radarTech = {tech = techAliases.NightFightersI, detectors = {unitAliases.EarlyRadar},
                errorSchedule = {{0,-2},{.75,2}}, volumePenalty = 0.03},
intruderTech = {tech = techAliases.NightFightersIII, detectors = {unitAliases.EarlyRadar},
                errorSchedule = {{0,2},{.75,-2}}, volumePenalty = -0.03, counterTo = techAliases.NightFightersIII},

Edit - attached are the events. I believe I've added in all the "true" night fighters for the Germans, as well as all night Allied aircraft. Though the Germans can have any aircraft inhabit the night, I think a good reason to invest in actual night fighters would be their chance to be invisible, so I'm good with the rest of German aircraft falling into a schedule where they get no intruder bonuses/stealth.

If all my thoughts above are correct, you have the events.

 

[Prof. Garfield]

I believe the below is basically saying "these bombers have the same detect-ability however it is modified exclusively by if the other side has researched better night fighter tech. So for example if the Germans have Nightfighters III they'll be able to get a bonus spotting Lancasters until the Allies also get it?

At the moment, the bonus and counter bonus apply only when early radar is trying to make the detection. This may or may not be what you want. Add extra entries to the 'detectors' table for other units that should get the bonus when they try to detect.

Also, NightFightersII and III don't help detect Stirlings (and III doesn't help detect Halifaxes). If you don't want that, that's fine, but I thought I should point it out.

changelog

Added to radar tables:

(line 1635)
local intruder = {}
intruder.radarInvisible = { baseError = {{0,50}},}
intruder.alwaysSpotted = {baseError = {{0,0}},}

(line 1750)
RIDT[unitAliases.MossiePR.id] = intruder.radarInvisible

RIDT[unitAliases.Ju188.id] = intruder.radarInvisible


-- All air units not otherwise included in RIDT are included as 'always spotted' (including munitions, though this probably doesn't matter)
for i=0,130 do
if civ.getUnitType(i) and civ.getUnitType(i).domain == 1 and RIDT == nil then
RIDT = intruder.alwaysSpotted
end
end


Cleared the table that counts unit reactions each turn. (This is something I forgot to include when doing the 'reactions' stuff.)

The events are available if you want them. I've been ill for the past week, so I don't have any events 'saved up'.

On the topic of events, should we limit the how many freighters can dock in a port each turn? I'm thinking that Freighters should only be allowed to unload into cities that have a military port, and only once per turn. This would expose freighters to increased attack, and make the Allied military ports more important. But, maybe this would increase micromanagement too much, so I'm not completely sure.

Also, do you want any 'decoy' units. E.g. a unit that looks like a tank to the enemy, but is really a 0 attack and defence unit (and that you can tell the difference during your turn).