Over the Reich: Single Player - Development Thread

[Prof. Garfield]

I pushed the changes to rules today that I made. The umlauts are showing up as weird symbols so I changed them. Not sure what's going on there.

(Take a gander and make sure I didn't screw this up. I note that in the github desktop I can see the changes in green so I think I did it right).

I will need to work on the speeds now.

I was able to pull the changes, so everything seems fine.

Civ II will definitely recognise the umlauts, but many text editor character sets only have characters for 7-bit ASCII, not 8-bit, so they show the unknown symbol. You can put them back.

 

[JPetroski]

Where would I find this to fix this?

WARNING for @LSTCOMBATGROUPS: entry for unit type with ID 93 is called B-25 but the unit type with that id has a name of 15th AF B-25.
WARNING for @LSTCOMBATGROUPS: entry for unit type with ID 103 is called Eirch Hartmann but the unit type with that id has a name of Erich Hartmann.
WARNING for @LSTDEMOTION: entry for unit type with ID 93 is called B-25 but the unit type with that id has a name of 15th AF B-25.
WARNING for @LSTDEMOTION: entry for unit type with ID 103 is called Eirch Hartmann but the unit type with that id has a name of Erich Hartmann.
WARNING for @LSTPROMOTION: entry for unit type with ID 93 is called B-25 but the unit type with that id has a name of 15th AF B-25.
WARNING for @LSTPROMOTION: entry for unit type with ID 103 is called Eirch Hartmann but the unit type with that id has a name of Erich Hartmann.
WARNING for @LSTPRODUCTIONVETERANSTATUS: entry for unit type with ID 93 is called B-25 but the unit type with that id has a name of 15th AF B-25.
WARNING for @LSTPRODUCTIONVETERANSTATUS: entry for unit type with ID 103 is called Eirch Hartmann but the unit type with that id has a name of Erich Hartmann.

 

[Patine]

Hello all,

@Prof. Garfield and I are teaming up once again to focus on the skies over Germany, this time trying to bring Over the Reich into a solid single player experience utilizing the powers of Lua. This thread is for its open development and observation. It's easier for us to work this way and also has the added benefit of maybe helping someone out there with their own creations. More to come!

For this project, we're using GitHub to collaborate, so we don't have to worry about who is using what file and remembering what files to pass along to the other person.

Our repository is here, for anyone who wants to follow along. Here's a video explaining the basics of Git, GitHub and GitHub desktop.

I recall I had asked about a single-player version of this scenario in some, then, murkky, hypothetical future in the original release thread quite a while ago. As I recall, @Prof. Garfield was dubious it would ever happen. I am very glad to this version is planned after all, as almost all of my civ games are single-player.

 

[JPetroski]

I recall I had asked about a single-player version of this scenario in some, then, murkky, hypothetical future in the original release thread quite a while ago. As I recall, @Prof. Garfield was dubious it would ever happen. I am very glad to this version is planned after all, as almost all of my civ games are single-player.

I think deep down we were both annoyed at how much of our lives we spent to make a MP-only scenario that almost no one would ever play LOL. I for one am never building a MP-only scenario again.

 

[Prof. Garfield]

Where would I find this to fix this?

WARNING for @LSTCOMBATGROUPS: entry for unit type with ID 93 is called B-25 but the unit type with that id has a name of 15th AF B-25.
WARNING for @LSTCOMBATGROUPS: entry for unit type with ID 103 is called Eirch Hartmann but the unit type with that id has a name of Erich Hartmann.
WARNING for @LSTDEMOTION: entry for unit type with ID 93 is called B-25 but the unit type with that id has a name of 15th AF B-25.
WARNING for @LSTDEMOTION: entry for unit type with ID 103 is called Eirch Hartmann but the unit type with that id has a name of Erich Hartmann.
WARNING for @LSTPROMOTION: entry for unit type with ID 93 is called B-25 but the unit type with that id has a name of 15th AF B-25.
WARNING for @LSTPROMOTION: entry for unit type with ID 103 is called Eirch Hartmann but the unit type with that id has a name of Erich Hartmann.
WARNING for @LSTPRODUCTIONVETERANSTATUS: entry for unit type with ID 93 is called B-25 but the unit type with that id has a name of 15th AF B-25.
WARNING for @LSTPRODUCTIONVETERANSTATUS: entry for unit type with ID 103 is called Eirch Hartmann but the unit type with that id has a name of Erich Hartmann.

In rules_lst.txt, the names of units are listed in column A of each section. This is strictly as an aid to the designer; the changes are made to the unit with the ID number corresponding to the row. However, if there is a name mismatch, these warnings are printed just in case units in the rules.txt were shuffled around or something, and they no longer match. These are not errors, so you don't have to make a change. However, you can fix the problem by making sure that names match between the rules.txt and rules_lst.txt.

I recall I had asked about a single-player version of this scenario in some, then, murkky, hypothetical future in the original release thread quite a while ago. As I recall, @Prof. Garfield was dubious it would ever happen. I am very glad to this version is planned after all, as almost all of my civ games are single-player.

The onInitiateCombat event means that we don't have to teach the AI to use munitions (or, if we do, for only a couple units that fire at range). That's probably the biggest enabler. The second enabler, for me, is that I've had some time away from the scenario. Third is that I've built a few modules (radar/strategic targets) that should make large parts of the coding much easier, and give more extensive testing to those modules. Fourth, with some more experience, enabling the AI a bit seems a bit less daunting.

 

[JPetroski]

@Prof. Garfield

Do you see an obvious issue with this? It's saying I need to close out the { at 39 after 41 (both highlighted). I'm working on the speeds now and figured it would be better not to upload something with an error but I could swear the } at the very end is what is needed? Certainly in Notepad++ it's showing as enclosing this properly.

local specificKeyTable = {
pursuitSpeed = {["number"] = true, ["nil"]=true}
escapeSpeed = {["number"] = true, ["nil"]=true}
pursuitSpeedLow = numberSpec,
pursuitSpeedHigh = numberSpec,
pursuitSpeedNight = numberSpec,
escapeSpeedLow = numberSpec,
escapeSpeedHigh = numberSpec,
escapeSpeedNight = numberSpec,
interceptionRange = {["number"]={minVal=0, maxVal = maxInterceptionRange, integer=true}},
attackMoveCost = {["number"]={minVal=0,maxVal=255,integer=true}},
}
error loading module 'combatParametersOTR' from file 'D:\Test of Time\Scenario\over-the-reich-v-5\LuaParameterFiles\combatParametersOTR.lua':
...-the-reich-v-5\LuaParameterFiles\combatParametersOTR.lua:41: '}' expected (to close '{' at line 39) near 'escapeSpeed'
stack traceback:
[C]: in ?
[C]: in function 'require'
...rio\over-the-reich-v-5\MechanicsFiles\combatSettings.lua:41: in main chunk
[C]: in function 'require'
D:\Test of Time\Scenario\over-the-reich-v-5\events.lua:193: in main chunk

 

[Prof. Garfield]

pursuitSpeed = {["number"] = true, ["nil"]=true}
escapeSpeed = {["number"] = true, ["nil"]=true}

These need a comma at the end of the line. That is probably what is causing the error.

 

[JPetroski]

I went ahead and pushed what I've done. More changes to rules (@UnitsAdvanced mostly). I also changed the LST file to match just to clean up the console for when we have errors, changed the workon save, and added an OTR5 scenario saved with the addition of some whirlwinds lying around at the start.

Finally, I've gotten "combatParameters" to a point where we can at least start testing. I've used "real" speed numbers (though I hesitate to say that). Aircraft speeds change in a non-linear fashion depending on altitude and other factors (and then there are many competing sources) so really, eh... Well, no purists will be happy But, at least it's a start. I tried to stay consistent and when I found weird numbers (example, Meteors that were setting speed records well after the war) I tried to use the figures close to actual wartime performance.

For "named" experten and aces, I simply had them at 500 for props and 600 for jets. For unnamed experten and aces, 475. This should make these units hard to kill.

As far as bonuses, for now I've only given a +25 bonus or -25 malus to high altitude performance for the various FW190, P47, and P38 that really had tremendous differences at altitude. Most other stuff just keeps their numbers across the board, but the A-series 190s were terrible at alt, all 47's are very good up there, and the P38's were poor at altitude until the L-series.

These need a comma at the end of the line. That is probably what is causing the error.

That fixed that, but a new issue that is a little strange. Note that this time it's talking "escapeSpeedHigh" however on another reload it was "escapeSpeedNight". I have pushed this with the error. If it's a simple fix would you mind fixing it so I could practice a pull, that would be great. If it requires a ton of repetitive changes that I've screwed up somewhere, I'm happy to make them if you let me know what it is.

WARNING: getLegacyEvents.lua not found. You will not have any legacy events.
...e\Scenario\over-the-reich-v-5\LuaCore\generalLibrary.lua:7763: new combatParameter: key: escapeSpeedHigh; Expected :number, ; Received: {['number'] = true,}
stack traceback:
[C]: in function 'error'
...e\Scenario\over-the-reich-v-5\LuaCore\generalLibrary.lua:7763: in function 'generalLibrary.validateTableValue'
...e\Scenario\over-the-reich-v-5\LuaCore\generalLibrary.lua:7917: in function <...e\Scenario\over-the-reich-v-5\LuaCore\generalLibrary.lua:7906>
(...tail calls...)
...e\Scenario\over-the-reich-v-5\LuaCore\generalLibrary.lua:6302: in metamethod '__newindex'
...-the-reich-v-5\LuaParameterFiles\combatParametersOTR.lua:135: in main chunk
[C]: in function 'require'
...rio\over-the-reich-v-5\MechanicsFiles\combatSettings.lua:41: in main chunk
[C]: in function 'require'
D:\Test of Time\Scenario\over-the-reich-v-5\events.lua:193: in main chunk

 

[Prof. Garfield]

@JPetroski

I've just uploaded the changes. Try pulling them. Note: make sure you save all your current work before pulling the changes. Otherwise, things don't work correctly. (I lost a bit of work that way...)

The problem was that you have a bunch of keys which are 'assigned' the numberSpec table. I wrote a macro to comment out those lines, then increased the maximum interception range to match the ME163.

 

[Prof. Garfield]

I've updated the repo.

I've updated onChooseDefender so it can search for units which can climb or dive to defend a unit.

I've added the code for combat support, and, based on a few tests, it seems to be working as I expect.

The double support value --> +1 combat is implemented with a base 2 logarithm function, and with the attacker/defender giving itself 1 combat support (regardless of what it would regularly get). So, 1 combat support is +0, 2 combat support is +1, 4 is +2, and so on. Of note, however, is that 3 combat support, for example, give +1.58 (I think rounded down somewhere to the nearest 1/8 increment). If you want, I can use math.floor to give distinct thresholds. However, I think that would be a bad idea. The player would end up spending time adding up support to see if thresholds are met, rather than being able to get a general idea by eyeballing it

At the moment, all units provide their full combat support all the time. I wonder if it is better to prorate based on HP?

How do we want to handle units that can't make it back home? At the moment, I have them not providing combat support, and only being eligible to defend a tile if they are actually on the tile.

In the old game, we made them lose combat automatically if they were beyond their operating range. Now, we can tell if the unit can actually make it back to base. I think it still makes sense to make the unit lose combat, but maybe we should kill the unit at the end of its turn if it won't make it back to base? That way, it can't scout or be a decoy or whatever.

Or, should we stick to the "combat radius" version of things, so the player isn't punished as harshly for accidentally getting out of range?

 

[Prof. Garfield]

I've pushed the change to make stacks have more minimum combat before escape can happen. So, now it is 1 round, plus 2 more for every unit on the tile (including the defender itself).

I forgot to mention that last time I added the "carrier" and "useCarrier" traits. I've added the "carrier" trait to the aircraft carrier, but I haven't added the "useCarrier" traits to any aircraft. I was thinking that since we have some extra unit slots, it might make sense to have separate units for carriers, since I'm pretty sure not every pilot could land on a carrier.

 

[JPetroski]

Sorry up at the lake with very little service- will have to get back to you when I return Sunday

 

[JPetroski]

In the old game, we made them lose combat automatically if they were beyond their operating range. Now, we can tell if the unit can actually make it back to base. I think it still makes sense to make the unit lose combat, but maybe we should kill the unit at the end of its turn if it won't make it back to base? That way, it can't scout or be a decoy or whatever.

Or, should we stick to the "combat radius" version of things, so the player isn't punished as harshly for accidentally getting out of range?

Personally, I think we remove the unit if it can't make it back to a base with a text box saying, "This [unit type] ran out of fuel and had to ditch."

At the moment, all units provide their full combat support all the time. I wonder if it is better to prorate based on HP?

It would probably be best to prorate it so that there's a benefit to breaking up formations or damaging certain units that you can't necessarily kill.

I forgot to mention that last time I added the "carrier" and "useCarrier" traits. I've added the "carrier" trait to the aircraft carrier, but I haven't added the "useCarrier" traits to any aircraft. I was thinking that since we have some extra unit slots, it might make sense to have separate units for carriers, since I'm pretty sure not every pilot could land on a carrier.

It makes a lot more sense for the Allies, who actually had interesting carrier aircraft that aren't yet in the scenario than the Germans, who never had a functional aircraft carrier (though they did at least have a "carrier worthy" Me109, the T...)

 

[Patine]

I've already gone to the trouble of adding a attackMoveCost for attacks, so that an attack by an airplane doesn't use up all its movement points in an attack. (But, by default, all points are used up.) So, we can have aircraft make multiple attacks same way as in the old version, and that was how I expected it to be done. My idea with speed was to give fast aircraft an advantage that wasn't strictly an increase in combat stats. For example, there was a bomber version of the Mosquito where they took off the guns to make it faster and able to outrun anything that could try to attack it. In this version, that aircraft would have no attack and low defense, but would be able to survive several attacks because each one would be short.

I pushed the changes to rules today that I made. The umlauts are showing up as weird symbols so I changed them. Not sure what's going on there.

(Take a gander and make sure I didn't screw this up. I note that in the github desktop I can see the changes in green so I think I did it right).

I will need to work on the speeds now.

Well, given it's Battle of Britain Day, I thought I would bump my question from a while ago if a remake of the incomplete Nemo scenario, or a whole new scenario, on the Battle of Britain using mechanics, and lessons learned, from this one as some base material, is likely to happen?

 

[Prof. Garfield]

Well, given it's Battle of Britain Day, I thought I would bump my question from a while ago if a remake of the incomplete Nemo scenario, or a whole new scenario, on the Battle of Britain using mechanics, and lessons learned, from this one as some base material, is likely to happen?

I don't know, but I haven't been writing code for this project with portability in mind. I asked JPetroski to revive this project because I wanted to write some code for a specific project. It provides a difference from the Template work, which involves a lot of guessing what functionality an unknown designer might need at some point. I'll think more about it when this project is done.

@JPetroski if you're up for it, I'm happy to work on this project some more.

 

[JPetroski]

I don't know, but I haven't been writing code for this project with portability in mind. I asked JPetroski to revive this project because I wanted to write some code for a specific project. It provides a difference from the Template work, which involves a lot of guessing what functionality an unknown designer might need at some point. I'll think more about it when this project is done.

@JPetroski if you're up for it, I'm happy to work on this project some more.

I'd love to continue the project, I'm just at a bit of a loss for what steps we need to do to get it up and operational. I believe I finished up the last stuff I was last working on it.

I almost feel like we need a Gannt chart or something for this lol.

This one was such a complicated MP experience mostly because we were both learning and playing that it's very challenging for me to consider what is needed to make it SP.

 

[techumseh]

If I may jump in here and offer some unsolicited comments? The issue for me when I tried OTR, was not really the multi-player aspect, although I'm sure that does limit the number of people who will try it. It was really the unlimited scope and the resulting complexity, which if I can be really frank, made it too much work and quite confusing. The scenario tackles too many things, imho. Daylight and night bombing, tactical air in France, air defense of Britain, anti-submarine operations and a land campaign in France. It's all a bit overwhelming, and I really just didn't know where to start.

I would definitely be interested in playing a single player version if it was more focused. Maybe just the daylight strategic bombing over Germany. And please try to keep it simple. I look forward to playing it. Let me know if I can be of any help.

 

[Patine]

If I may jump in here and offer some unsolicited comments? The issue for me when I tried OTR, was not really the multi-player aspect, although I'm sure that does limit the number of people who will try it. It was really the unlimited scope and the resulting complexity, which if I can be really frank, made it too much work and quite confusing. The scenario tackles too many things, imho. Daylight and night bombing, tactical air in France, air defense of Britain, anti-submarine operations and a land campaign in France. It's all a bit overwhelming, and I really just didn't know where to start.

I would definitely be interested in playing a single player version if it was more focused. Maybe just the daylight strategic bombing over Germany. And please try to keep it simple. I look forward to playing it. Let me know if I can be of any help.

I agree that is was a bit busy and overwhelming, with a lot of to keep track of, yes. I would think, by nature of the subject matter, the Battle of Britian I had discussed with @JPetroski awhile wouldn't be as involved.

 

[Prof. Garfield]

I wouldn't be against doing a Battle of Britain scenario first. From a programming perspective, it would probably be less complicated than OTR, so it would let us test out some ideas and solve some problems without having to build the entire OTR before playtesting. However, the non-programming work for OTR is done (except for 'data' to feed the program). What's the state of Nemo's Battle of Britain scenario? If it's mostly complete except for events, then it could make an attractive project.

 

[techumseh]

Nemo abandoned the project because he couldn't get the AI to co-operate in the way he needed. I think it was prior to ToT and its expanded events. I enlarged his map to make Operation Sea Lion, which includes a basic Battle of Britain sub-scenario prior to the invasion itself. It is only playable by the Germans, and it is limited to Macro events, but the British AI puts up a good fight. With lua, I'm confident that a good single player game could be produced for whichever side was chosen.

I had an ancient board wargame called (wait for it) "The Battle of Britain". It consisted of 5 weeks. In each turn, all aircraft would conduct their missions in a series of alternating turns and then return to base, ending the week. There were probably 15 or 20 turns in each week. At the end of the 5th week, the game was ended and the score calculated. This might be a possible framework for a scenario.