Over the Reich - Creation Thread

[Prof. Garfield]

I was wondering if you could elaborate more on this particular post with regards uploading rules.txt file.

In my project, we are using the following code to switch the terrain.bmp graphic files when it’s November and April to reflect the changing seasons. But to our knowledge, we didn’t believe or know if it was possible to do the same with the rules text file as well.

I didn't mean to literally switch the rules files. The TOTPP Lua function reference https://forums.civfanatics.com/threads/totpp-lua-function-reference.557527/ has some places where you can change game fundamentals, most notably the unittype object. So, setting civ.getUnitType(0).defense = 5 is like loading a new rules.txt where the 0th unit type has 5 defense points instead of what it had before. So, we can achieve the same kinds of things that we could achieve by loading a new rules.txt file at an opportune time. So, we can increase the defense of, say, 88s against tanks, since that could be achieved by loading a new rules.txt when a tank activates (and a different one when any other unit activates), but we can't increase the defensive power of an 88 if it is on a particular terrain, since we have no way of knowing which particular 88 will be attacked, and the rules.txt doesn't have a means of customizing defensiveness of individual units based on terrain (only all units at once).

Everything that I've said, however, requires that there be a TOTPP Lua function that can make the change you want it to, and, unfortunately, TheNamelessOne didn't provide the functionality to change the terrain characteristics on the fly (maybe if you ask nicely and have a specific use case the next time he shows up, you might get it). You could get around this by changing the map terrain (i.e. having 'cold', 'cool', 'warm', and 'hot' terrain types that shift north and south depending on the season), but that would limit the total number of terrain types you have to work with. That could be some amount of work to store a map's worth of terrain types in a table, but there might be a way of writing lua code to generate that for you.

 

[JPetroski]

Tootall you may also want to take a look at the events for Gallic Wars as we did change the road multiplier in addition to the terrain graphics without needing a batch file. This was achieved through the use of "states" I believe.

As to your request for screenshots, I'm happy to oblige. What in particular are you seeking?

 

[Prof. Garfield]

OK so this might sound stupid but here's my issue: I really would prefer that the player continues to call up ammo for flak and fighters because I think there is something inherently satisfying about moving one unit into another, seeing a little attack animation, and hearing some sound. It's a tried and true concept that has worked all these years.

It's not stupid, your reasoning makes a lot of sense. If you want that, then I think that for the offense (not the 'reaction') the flak should just let you know on activation if there is something to fire at, then you can make the choice to fire or not if there is, and not fire 'just in case' something happens to be there.

On that note, can we eventually add the ability for me to play a soundfile when the reaction occurs? Because it is very abstract to press k and just see damage decrease. I'd like reacting flak to play the flak burst sound, reacting bombers to have a defensive fire sound, etc. I think this would go far towards immersion.

There is a 'play sound' function in TOTPP lua, but I haven't tried using it yet.

Now, as to the flak, I like your 'k fires the individual' vs. 'backspace fires everything' idea for a few reasons, but the main one is this:

1. It gives players choices. I might want to have "two units collide." You might want to fly through the turn. We both get our way and can play the game the way we want to play it. Maybe 'k' actually produces the flak burst unit and backspace just calculates the damage?

There's also the consideration that much of the gameplay is moving flak from one location to another where you need it, so players would probably want to do this before they ever hit backspace.

If we're creating an actual flak burst unit, then I don't see why we can't just have them be munitions as they are now. Unless you want the flak burst itself to do area damage (i.e. the flak fires in the general direction of the enemy, then hits everything nearby).

Does "night" stack with "all" or does "all" mean day high map / low map and night is different?

I ask because of the Wilde Sau units. Germany technically has the ability to deploy any aircraft to daylight or night time operations. It would be good to be able to make day fighters worse at night and night fighters worse at day.

I suppose I could get around it by having one damage set for high, one damage set for low, and one damage set for night. Because it's my understanding that this:

reactionDamage[unitAliases.FlakTrain.id] = {high = {triggerTypes = reactionGroups.allButJets, damageSchedule = ds.highFlak},
low = {triggerTypes = reactionGroups.allButJabo, damageSchedule = ds.lowFlak},
night = {triggerTypes = reactionGroups.allButJets, damageSchedule = ds.nightFlak}}

Is looking at three separate conditions (whether a unit is on the high map, low map, or night map and applying a separate distinction to each.

Is that accurate or is the night one (the last one here) actually adding to the low and high before it?

Anyway, I'm going through the table. This is pretty extensive stuff. If you need the events for some reason let me know and I'll post a copy/halt operations but otherwise I could see this work dragging in to the weekend.

Everything stacks with 'all', including night. All is applied to the trigger unit regardless of map it is on. Then, one of low, high, night is chosen depending on the map the trigger unit is on and applied (if there is anything in that table). Then, dive is applied on top of that if it is applicable (i.e. reactor on day high, target on day low). If you want different night and day effectiveness, leave all empty, and use low, high, and night to specify damage. If you want most of the damage to be the same, but have a 'bonus' in certain circumstances, use all and add the bonus in another entry as appropriate.

Something I should note is that a unit type should appear only once for each map type, i.e. at most once in all, at most once in low, at most once in high, etc. Once a match is found in a particular map category, the function will move on to the next. It won't keep looking to see if there is more damage to be done in that particular map. This is only likely to be an issue if you have overlapping target categories, and want to apply different damage to each of them.

 

[tootall_2012]

I didn't mean to literally switch the rules files. The TOTPP Lua function reference https://forums.civfanatics.com/threads/totpp-lua-function-reference.557527/ has some places where you can change game fundamentals, most notably the unittype object...

Ok, thanks for the clarification. This is what Knighttime explained to me as well.

Tootall you may also want to take a look at the events for Gallic Wars as we did change the road multiplier in addition to the terrain graphics without needing a batch file. This was achieved through the use of "states" I believe.

Thanks. We were aware of the changes you did for your Gallic scenario, but in my case it wasn’t just the road/RR multipliers I wanted to change but also to modify some terrain defense and movement cost values, as well as reduce the MP for the naval units.

Since TOTPP lua didn’t handle all these different requirements, or it demanded too much coding to handle something that could easily be done by a file swap, I decided it was much simpler to resort to the time honored practice of using the bat file.

Perhaps one day, TNO will include the ability to swap the rules file as well.

As to your request for screenshots, I'm happy to oblige. What in particular are you seeking?

One thing I was particularly interested in seeing was how the radar feature worked. Going over your development thread again today, I see I somehow missed your whole video on this very subject on post #206. Truly inspiring work!

 

[Patine]

One thing I was particularly interested in seeing was how the radar feature worked. Going over your development thread again today, I see I somehow missed your whole video on this very subject on post #206. Truly inspiring work!

So basically, until now, it went UNDER YOUR RADAR!

Sorry, couldn't resist...

 

[tootall_2012]

So basically, until now, it went UNDER YOUR RADAR!

Sorry, couldn't resist...

lol

 

[Prof. Garfield]

Since TOTPP lua didn’t handle all these different requirements, or it demanded too much coding to handle something that could easily be done by a file swap, I decided it was much simpler to resort to the time honored practice of using the bat file.

Perhaps one day, TNO will include the ability to swap the rules file as well.

It is probably possible to use Lua input output functions to do the equivalent work of the bat file. That way, you could put up a message saying to please re-load the game and the end user wouldn't have to manually run the batch file. I used io.write in a brief test of the feasibility of generating a new Events.lua template depending on what extra libraries were needed, and it worked (though I didn't try overwriting anything). There area a couple of caveats to this. One is that we don't currently have a way to get the current working directory (we can only get the ToT directory), and the other is that there is a security risk to writing events that do things outside of the civ 2 engine, especially overwriting existing files.

 

[tootall_2012]

It is probably possible to use Lua input output functions to do the equivalent work of the bat file. That way, you could put up a message saying to please re-load the game and the end user wouldn't have to manually run the batch file. I used io.write in a brief test of the feasibility of generating a new Events.lua template depending on what extra libraries were needed, and it worked (though I didn't try overwriting anything). There area a couple of caveats to this. One is that we don't currently have a way to get the current working directory (we can only get the ToT directory), and the other is that there is a security risk to writing events that do things outside of the civ 2 engine, especially overwriting existing files.

In this day and age I wouldn't want to expose players to security risks. Unless and until a viable risk free solution is implemented, I find it's a very minor inconvenience to have the players use the bat file (it probably takes less than 15 seconds to go through the whole switching process).

 

[JPetroski]

How is Napoleon coming along anyway? I'm very hopeful that having it and OTR operational will get some other designers on board with lua.

 

[Patine]

How is Napoleon coming along anyway? I'm very hopeful that having it and OTR operational will get some other designers on board with lua.

I'm certainly hoping that Lua can have significant application for my Pacific Rim scenario, as it's planned, and MP options are an ideal plan for it, if interest is there, because six of the seven civ's could be all be interesting as playable, especially together in the same game. It would also help to mitigate the randomness (or annoying AI tendencies, at least) of the use of nuclear weapons by AI players, as four civ's start with nuclear arsenals, but one other has a well-known and documented drive, program, and desire to develop them.

 

[Prof. Garfield]

In this day and age I wouldn't want to expose players to security risks. Unless and until a viable risk free solution is implemented, I find it's a very minor inconvenience to have the players use the bat file (it probably takes less than 15 seconds to go through the whole switching process).

It's essentially the same risk as a batch file, that a piece of code you're downloaded from an anonymous person on the internet is changing your computer. I agree, however, that the batch file is probably the way to go on the basis that checking that it does what it says it does is much easier, since there is much less code.

 

[tootall_2012]

How is Napoleon coming along anyway? I'm very hopeful that having it and OTR operational will get some other designers on board with lua.

Hi John,

The scenario is in a very advanced stage. Knighttime has done an amazing job at implementing all the core concepts I wanted to include in the scenario (winter attrition, leader attack bonuses and diplomacy to name just a few). Of course, we are re-using your concepts for munitions generation and leader administrative bonuses.

I would say, the most difficult part was implementing a full diplomatic framework to control all the war and peace relations between the different powers. As we know, Civilization’s AI can be quite temperamental in this regards, but Knighttime has done some incredible work to ensure that it’s all controlled by lua now.

Essentially, I’m in the testing phase now, which typically accounts for 30 to 40% of the time spent on my projects. As such, in addition to testing all the lua events, I’m also reviewing play balance and adding some minor events of my own to help address any issues in that regard.

It’s still a little too early to give an exact release date but I hope maybe in month or two.

 

[JPetroski]

This all is working as you would expect. It is going to take a little while as every Luftwaffe fighter will have 8 fields. The Allies have less since they can't place their day fighters on the night map and vice versa. Regardless, I used a simple ds.testing1, ds.testing2, ds.testing3, and ds.testing4 each with pretty obvious damage amounts and confirmed that this all works. Now that I have the first one done it should go quicker.

I'm trying not to make it completely likely that an interceptor will destroy or even significantly damage something because there is the possibility that more than one interceptor will react to units and players might find their air force getting chewed up too easily in those circumstances.

--Aircraft have multiple ds.  interceptors should be stronger against bombers, escorts stronger against fighters, day aircraft stronger at day than at night. 
--To simplify there will be a suffix: 1,2,3 or 4 which corresponds as follows:
-- 1 = high
-- 2 = low
-- 3 = night
-- 4 = dive

ds.Fw190A5interceptionBomb1 = {{.9, 3},{.4,5},{.05,7},{.01,5}}
ds.Fw190A5interceptionBomb2 = {{.9, 3},{.4,5},{.05,7},{.01,5}}
ds.Fw190A5interceptionBomb3 = {{.4, 3},{.2,5},{.01,12}}
ds.Fw190A5interceptionBomb4 = {{.7, 10}}
ds.Fw190A5interceptionFighter1 = {{.7, 1},{.4,4},{.05,5}}
ds.Fw190A5interceptionFighter2 = {{.7, 1},{.4,4},{.05,5}}
ds.Fw190A5interceptionFighter3 = {{.3, 1},{.1,4},{.05,5}}
ds.Fw190A5interceptionFighter4 = {{.7, 10}}

reactionDamage[unitAliases.Fw190A5.id] ={high = {{triggerTypes = reactionGroups.strategicBombers, damageSchedule = ds.Fw190A5interceptionBomb1},
{triggerTypes=reactionGroups.alliedFighters, damageSchedule = ds.Fw190A5interceptionFighter1}},
low = {{triggerTypes = reactionGroups.strategicBombers, damageSchedule = ds.Fw190A5interceptionBomb2},
{triggerTypes=reactionGroups.alliedFighters, damageSchedule = ds.Fw190A5interceptionFighter2}},
night = {{triggerTypes = reactionGroups.strategicBombers, damageSchedule = ds.Fw190A5interceptionBomb3},
{triggerTypes=reactionGroups.alliedFighters, damageSchedule = ds.Fw190A5interceptionFighter3}},
dive = {{triggerTypes = reactionGroups.strategicBombers, damageSchedule = ds.Fw190A5interceptionBomb4},
{triggerTypes=reactionGroups.alliedFighters, damageSchedule = ds.Fw190A5interceptionFighter4}} }

 

[JPetroski]

It's not stupid, your reasoning makes a lot of sense. If you want that, then I think that for the offense (not the 'reaction') the flak should just let you know on activation if there is something to fire at, then you can make the choice to fire or not if there is, and not fire 'just in case' something happens to be there.

Ok that works.

There is a 'play sound' function in TOTPP lua, but I haven't tried using it yet.

I used it in Gallic Wars. I think I even managed to write that one myself but I only had it for onTurn activation. If you can eventually add the sound file to the table in the last post so I can choose a different .wav for each unit/circumstance, I do have a pretty large collection of sounds that I can put together from a few old games (One actually named "Over the Reich.") I could probably make sound files that say "bandits! bandits! 12 o'clock high!" for attacks on bombers or "bandits! bandits! out of the sun!" for "dive." Then we don't need a text box that players need to close and it might not be as annoying. It actually might be pretty cool and immersive.

Something like this would be ideal:

dive = {{triggerTypes = reactionGroups.strategicBombers, damageSchedule = ds.Fw190A5interceptionBomb4, soundfile = twelveoclockhigh.wav}, {triggerTypes=reactionGroups.alliedFighters, damageSchedule = ds.Fw190A5interceptionFighter4, soundfile = outofthesun.wav}}

If we're creating an actual flak burst unit, then I don't see why we can't just have them be munitions as they are now. Unless you want the flak burst itself to do area damage (i.e. the flak fires in the general direction of the enemy, then hits everything nearby).

I think it's fine to just have the called up ammo only strike one target and have the defensive reaction ammo potentially strike more.

Something I should note is that a unit type should appear only once for each map type, i.e. at most once in all, at most once in low, at most once in high, etc. Once a match is found in a particular map category, the function will move on to the next. It won't keep looking to see if there is more damage to be done in that particular map. This is only likely to be an issue if you have overlapping target categories, and want to apply different damage to each of them.

What I posted above works so I think I am understanding you right, and I don't need anything other than what I posted to work, so that works for me!

 

[Prof. Garfield]

I used it in Gallic Wars. I think I even managed to write that one myself but I only had it for onTurn activation. If you can eventually add the sound file to the table in the last post so I can choose a different .wav for each unit/circumstance, I do have a pretty large collection of sounds that I can put together from a few old games (One actually named "Over the Reich.") I could probably make sound files that say "bandits! bandits! 12 o'clock high!" for attacks on bombers or "bandits! bandits! out of the sun!" for "dive." Then we don't need a text box that players need to close and it might not be as annoying. It actually might be pretty cool and immersive.

Something like this would be ideal:

dive = {{triggerTypes = reactionGroups.strategicBombers, damageSchedule = ds.Fw190A5interceptionBomb4, soundfile = twelveoclockhigh.wav}, {triggerTypes=reactionGroups.alliedFighters, damageSchedule = ds.Fw190A5interceptionFighter4, soundfile = outofthesun.wav}}

We can definitely do sounds, but we'll have to think about how to decide which sound will play. There may be multiple reacting units, so we probably don't want to play a sound for each unit. Maybe we can do an air raid siren if the flak activates within range of an enemy plane.

 

[JPetroski]

We can definitely do sounds, but we'll have to think about how to decide which sound will play. There may be multiple reacting units, so we probably don't want to play a sound for each unit. Maybe we can do an air raid siren if the flak activates within range of an enemy plane.

I'm not sure if sound doubles up but you're right that if we had 15 units all firing a sound at once that would be horrible. The air raid siren is a good idea for the flak, and should be the most commonly heard. Perhaps a situation where if certain things happen, they overrule the other? Only one sound to play in any situation.

If there is a choice between fighter, air raid, and diving fighter (no matter how many of each there are - we are only checking for one match):

A Fighter overrules air raid
Diving fighter overrules air raid and fighter

In most cases a bomber pressing 'k' will be next to a target so I think there is an expectation of flak. The fighters and especially diving fighters, being potentially 2-4 spaces away and out of visual range, are more obscure so I think the player needs the audio cue that they are being attacked by aircraft more than flak, and by diving aircraft (the 3D attack) more so than aircraft on their map.

Anyway, my work on the table continues and I remain impressed with the functionality you have given me. I've decided to group German aircraft into three fields: fighter, heavyFighter, and bomber. Allied fighters chew up the different groups with different success. The use of high, low, and dive means that each Allied fighter has 9 options, which is work, but it also means that I can make certain aircraft really good at high altitude or diving (P47s) and other aircraft that didn't do as well in the ETO like the P38 worse. It's also another way to represent ammo, so the P38s even though having less likelihood to intercept will do more damage when they do intercept. This combat system has dramatically increased the possibilities of this game.

I could see the concept being adapted eventually for "ambush" style units. Right now they are simply invisible until attack that players must stumble on but perhaps in the future they'll be "hive" units that are "paradropped" into the middle of nowhere, but they have a range of control with certain percentages that they'll react to other units. Until you locate and destroy the "hive," ambushes can continue in the area. This could be a really good way to represent the Resistance some day.

 

[JPetroski]

Here are the events - they are all yours.

I've completed the reaction damage tables. I believe that everything is working. That was quite the ordeal but I think I have everything where I want it for now.
I took a stab at the French Resistance / German freight train creation event but couldn't get it working and got spooked about messing around with the events too much. I've included it as "test bed" as perhaps it will be helpful.

I am glad that we are keeping this scenario easy to jump in and play but I think we've made it very difficult to master so I think a very good use of my time right now would be to focus on expanding the readme. It's getting to the point where it needs a full-fledged strategy guide! Anyway, easy to play, difficult to master is a pretty good formula for replayability. Also, at this point I need to start considering putting in a describe text for the advances too as we now have a few that give random bonuses / have special meaning.

 

[McMonkey]

Just got around to watchking the Radar video. A M A Z I N G! This will make the scenario a lot easier to play & allow the player to focus more on the fun stuff (IE moving their aircraft). I did find the old radar system a chore, though it was a good idea given the previous limitations. Keep up the good work chaps!

 

[Prof. Garfield]

Sdkfz is missing its reaction damage entry. You can have the events, I'm not planning on working on them tonight.

 

[JPetroski]

Sdkfz fix attached - I don't have anything else to do on events now - will continue to work on readme. I'm putting stuff in yellow highlight that we're planning but isn't in yet so it might be help us keep organized too. I'll share when it is more complete.