Over the Reich - Creation Thread

Will sameTime allow a day fighter to attack an enemy at lower altitude or do I need to choose between sameTime or lowerAltitude?

Yes, it means what you would expect. Same time (should -- if it doesn't I'll have to correct it) allow a unit on map 0 or 1 to react to the trigger unit on map 0 or 1. If the unit is on map 2, it can only react to a trigger unit on map 2.

The canReactFunction will search all the possible map combinations (all, sameTime, lowerAltitude, etc.) trying to find a match, and return true when it finds one.

I am loving this by the way. It allows for such differentiation between types of units. For example I believe the below means (given that I've created the table for alliedFighters) that the 190s will "react to" or intercept Allied bombers while the 109s will react to or intercept Allied fighters, giving each another reason to be built. The Ta152 will react to everything. Is this understanding correct?

Yes, that is correct. Keep in mind that allAir is every single air unit (any unit with domain 1), including munitions. That doesn't necessarily matter (since munitions aren't k-units and can't therefore trigger a reaction), but just something to keep in mind, since I mostly made it as a quick and easy way to get a large set of units. Incidentally, making an 'area' reaction against munitions only could be an indirect way to increase survivability of a certain unit.

Also, by changing "range" it would change how far away a triggering unit could be for the unit to react - so if I wanted to, the 109G6 might have a range of 1, the 109G14 a range of 2, and the K4 a range of 3 - making each unit much more useful despite having the same ammo?

Yes, that is correct. You probably want any air unit that can defend a strategic target against bombers to have a range of at least 2, since our air-protected stack 'fix' will be moving air units off those targets when a munition is created.

You will find that you have a good deal of customization of damage ability, when you get to setting up that part of the table (at least if you want to put a lot of work into making the tables). You could have a unit be really good at reacting to one kind of trigger unit, and do only little damage to another kind.
 
Very cool. I do appreciate the allAir ramifications, but built a few more tables because I didn't want jets to be able to be intercepted by most aircraft. Now the Tempest and Ta152 shine a bit more as the only aircraft fast enough to intercept them.

I'm putting the kid to sleep now but plan on working into the night with this very cool stuff.
 
I'm doing an area reaction damage test. The Fw190A5 is a reacting enemy unit that should take 10 damage when a B-17 calls up ammo next to it and a flak train. The Me109G6 is a non-reacting unit (because it would only react to fighters). When the B-17 calls up ammo, I get the message "no entry in ractionDamage table for Fw190A5"

However, the Fw190A5 does take the damage expected.

This same issue works in reverse if a P-51 calls up ammo ("no entry in ractionDamage table for Me109G6" even though it does take the expected damage).

So the event seems to work but it seems to be triggering text that isn't true/necessary?

Edit - perhaps this is because I haven't added the 190A5 to local reactionDamage = {} yet. I'll see if it still pops up when it is in there.

EDIT - YES, THAT CLEAR THIS UP
 
Last edited:
How would I go about adding different trigger types for one unit? For example, I have an "allButJabo" table and a "jabo" table. I want the light flak to do heavy damage to the "allButJabo" but only light damage to the "jabo" group.

Code:
ds.lightFlak = {{1, 7},{.4,7},{.2,7},{.05,10}}
ds.lightFlakJabo = {{1, 1},{.4,2},{.2,3},{.05,4}}

reactionGroups.allButJabo = {unitAliases.B17F,unitAliases.B17G,unitAliases.B24J,unitAliases.Stirling,unitAliases.Halifax,unitAliases.Lancaster,unitAliases.MedBombers,
unitAliases.SpitfireIX,unitAliases.SpitfireXII,unitAliases.SpitfireXIV,
unitAliases.P38H,unitAliases.P38J,unitAliases.P38L,unitAliases.P51B,unitAliases.P51D,unitAliases.Beaufighter,unitAliases.MosquitoII,unitAliases.MosquitoXIII,unitAliases.RedTails,unitAliases.Yak3,
unitAliases.Me109G6,unitAliases.Me109G14,unitAliases.Me109K4,unitAliases.Fw190A5,unitAliases.Fw190A8,unitAliases.Fw190D9,unitAliases.Ta152,
unitAliases.Ju88C,unitAliases.Ju88G,unitAliases.He219,unitAliases.Me110,unitAliases.Me410,unitAliases.Do217,unitAliases.He277,unitAliases.He111,unitAliases.Fw200,unitAliases.Sunderland}

reactionGroups.jabo = {unitAliases.Ju87G,unitAliases.Fw190F,unitAliases.Do335,unitAliases.HurricaneIV,unitAliases.Typhoon,unitAliases.Tempest,unitAliases.P47D11,unitAliases.P47D25,
unitAliases.P47D40}


Code:
reactionDamage[unitAliases.GermanLightFlak.id] ={low = {triggerTypes = reactionGroups.allButJabo, damageSchedule = ds.lightFlak}} --This works
reactionDamage[unitAliases.GermanLightFlak.id] ={low = {triggerTypes = reactionGroups.allButJabo, damageSchedule = ds.lightFlak}, {triggerTypes = reactionGroups.jabo, damageSchedule = ds.lightFlakJabo}} -- This does not work.  No error, but no damage to jabo.
reactionDamage[unitAliases.GermanLightFlak.id] ={low = {{triggerTypes = reactionGroups.allButJabo, damageSchedule = ds.lightFlak}, {triggerTypes = reactionGroups.jabo, damageSchedule = ds.lightFlakJabo}}} -- This also does not work.  No error, but no damage to jabo.
 
Finally if you could please help me understand how to edit this to get a dive bonus - that isn't totally clear to me. Let's say there's a 50/50 chance that 190A5 can successfully bounce a lower strategic bomber and inflict an additional 10 points of damage. What would I add to this?

Code:
ds.Fw190A5interception = {{1, 6},{.4,10},{.2,10}}

reactionDamage[unitAliases.Fw190A5.id] ={all = {triggerTypes = reactionGroups.strategicBombers, damageSchedule = ds.Fw190A5interception},}

Thanks!
 
CHANGELOG
-Have added tables for interceptions and defensive fire. I have not yet added any dive bonus. Everything seems to be working as intended...
-Changed political support money to $4,000 from $2,000
-made minor text change for freighters as they no longer use fuel

STUFF TO DO
-We should now get rid of defensive fire as the bombers have reactions instead. I have not done this as I am leery to remove that much code without being totally sure what I am doing. Can you do this when you take over the events?
-I very strongly feel that we need a text pop up when an interception occurs and potentially even for defensive fire:

"Bandits! Bandits! Out of the sun! Break! Break!" - if the dive bonus (not yet implemented by me) is triggered
"[string: German/Allied] fighters intercept our [string: type of unit]!" - standard interception
"[string: German/Allied] flak explodes across the sky near our attack!" - flak is triggered
"Our [string: type of unit] comes under withering ground fire! We would be wise to send dedicated jabo aircraft next time!" - low alt flak (other than infantry, tanks, etc.) is triggered
"Our [string: type of strategic bomber] presents a large target at low altitude. While we can use our strategic bomber fleet for such missions, they are fraught with danger." - for when strategic bomber attacked at low alt. Might be best to be a "justOnce"
"[string: German/Allied] [string: type of unit] gunners fire back at our interceptors!" - defensive fire is triggered.
 

Attachments

So the event seems to work but it seems to be triggering text that isn't true/necessary?

That was a debugging message. I ended up moving them to print statements (which I haven't removed yet), so I forgot to remove the text box. You don't have to fill up every entry in the table, the events aren't supposed to break when a unit is missing (just not do anything for that unit). You can search for the message string (at least the first part) and remove/comment out the associated text box. Since you have the events, I won't make the change myself.

How would I go about adding different trigger types for one unit? For example, I have an "allButJabo" table and a "jabo" table. I want the light flak to do heavy damage to the "allButJabo" but only light damage to the "jabo" group.

This results in 3.7cm flak (that is the light flak isn't it) doing damage to an attacking Hurricane IV.
Code:
reactionDamage[unitAliases.GermanLightFlak.id] ={low = {{triggerTypes = reactionGroups.allButJabo, damageSchedule = ds.lightFlak},{triggerTypes=reactionGroups.jabo, damageSchedule = ds.lightFlakJabo}} }

I think this was your third try for code. Maybe you didn't notice the 1 damage done to the aircraft you tried it on (I missed that once or twice, which is why I set a lot of my testing damage quite high ).

Finally if you could please help me understand how to edit this to get a dive bonus - that isn't totally clear to me. Let's say there's a 50/50 chance that 190A5 can successfully bounce a lower strategic bomber and inflict an additional 10 points of damage. What would I add to this?

Code:
reactionDamage[unitAliases.Fw190A5.id] ={all = {triggerTypes = reactionGroups.strategicBombers, damageSchedule = ds.Fw190A5interception},
                                        dive = {triggerTypes = reactionGroups.strategicBombers, damageSchedule = {{.5,10}}}}
Easiest way to see this is to make ds.FW190A5Interception = {{1,3}} temporarily so you can see the extra damage without worrying if it came from the dive bonus or just a good hit.

Note:
Code:
ds.lightFlak = {{1, 7},{.4,7},{.2,7},{.05,10}}

The maximum unit hitpoints is 20, correct? This already has a .2 chance of dealing 21, which will kill anything, even without the .05 chance of doing 31. At the moment, a single reaction will not "roll over" onto the damaged B17, although the damaged B17 will take reaction damage from other units. I could probably "roll over" the damage if you want that. Let me know.

-We should now get rid of defensive fire as the bombers have reactions instead. I have not done this as I am leery to remove that much code without being totally sure what I am doing. Can you do this when you take over the events?

I commented out the code already in the unitKilled trigger.

-I very strongly feel that we need a text pop up when an interception occurs and potentially even for defensive fire:

That could be wise, but I'll make sure to include "don't warn me again" functionality so that the text boxes don't get annoying.
 
That was a debugging message. I ended up moving them to print statements (which I haven't removed yet), so I forgot to remove the text box. You don't have to fill up every entry in the table, the events aren't supposed to break when a unit is missing (just not do anything for that unit). You can search for the message string (at least the first part) and remove/comment out the associated text box. Since you have the events, I won't make the change myself.
Will do.

This results in 3.7cm flak (that is the light flak isn't it) doing damage to an attacking Hurricane IV.
Code:
reactionDamage[unitAliases.GermanLightFlak.id] ={low = {{triggerTypes = reactionGroups.allButJabo, damageSchedule = ds.lightFlak},{triggerTypes=reactionGroups.jabo, damageSchedule = ds.lightFlakJabo}} }

I think this was your third try for code. Maybe you didn't notice the 1 damage done to the aircraft you tried it on (I missed that once or twice, which is why I set a lot of my testing damage quite high ).

I'll take another look at it tonight and see if I can get it to work. It was quite late so very possible I did miss something.


Code:
reactionDamage[unitAliases.Fw190A5.id] ={all = {triggerTypes = reactionGroups.strategicBombers, damageSchedule = ds.Fw190A5interception},
                                        dive = {triggerTypes = reactionGroups.strategicBombers, damageSchedule = {{.5,10}}}}
Easiest way to see this is to make ds.FW190A5Interception = {{1,3}} temporarily so you can see the extra damage without worrying if it came from the dive bonus or just a good hit.

Awesome. I'll add these in too. I'm very impressed with how you've made combat 3D in Civ2. That's not even possible in Civ6. I hope some people are paying attention to all this because this is some crazy cool stuff.

Note:
Code:
ds.lightFlak = {{1, 7},{.4,7},{.2,7},{.05,10}}

The maximum unit hitpoints is 20, correct? This already has a .2 chance of dealing 21, which will kill anything, even without the .05 chance of doing 31. At the moment, a single reaction will not "roll over" onto the damaged B17, although the damaged B17 will take reaction damage from other units. I could probably "roll over" the damage if you want that. Let me know.
This is just a case of me being an idiot (as you may have noticed, this happens with some regularity). I misread your instructions.

So this :
{1, 7},{.4,7},{.2,7},{.05,10}

Actually means

100% chance of doing 7 hitpoints of damage
40% chance of doing 14 hitpoints of damage
20% chance of doing 21 hitpoints of damage
5% chance of doing 31 hitpoints of damage

Correct?

And by extension, if I wanted a unit to have a chance of doing NO damage, I could start with .9 rather than 1: {.9, 7}

Which would mean that there is a 90% chance of doing 7 hitpoints of damage, but also a 10% chance of doing no damage - correct?

I'll have to look at the ds. table again with all of this in mind but it makes sense now (assuming I got both of the above correct).

That could be wise, but I'll make sure to include "don't warn me again" functionality so that the text boxes don't get annoying.

Can we annoy the player once per load to prevent them from removing this warning forever by accident? The gunners are probably likely to be annoying quickly but with interception range varying from 2-4 spaces and no good visual way to show an aircraft zooming in/diving in for attack, we might want to annoy the player constantly about the fighter interceptions.[/QUOTE][/QUOTE]
 
Also - I am attempting to see if I can modify your Battle of Atlantic system and apply it to Revolt Risk in France. If you happen to be working on this now, I will stop, but if you aren't, I'd like to take a shot at it.

One thing I am concerned with is that if the German player gets 5-6 freight trains in a certain place in France the best move would be for them to build 2-3 airfields right next to where these spawn so that they can immediately build 2-3 planes per turn by exploiting this system. I don't want that to happen. I'm wondering what options there are to delete cities (probably onActivation of any unit) if they are in a certain coordinate box, and not on a specific terrain type (in this case the city type). This seems like a pretty simple/straight forward thing. I might try to see if I can get this to work as well.

This way we can have freight trains spawn in mid-southern France, if the Germans have a large military presence in France, and not allow new airbases to be built in the region. This will require the trains to be brought up to the north or east or wherever they are wanted. As Germany really is starved for production, there's real incentive to move them along. There will also be real incentive for the Allies to target them (I don't think you attacked a single freight train last turn), and a true incentive for the Germans to keep (and expand) their military capabilities in France throughout the game rather than disbanding everything and only rebuilding when the Allies get enough points to make D-Day imminent.
 
So this :
{1, 7},{.4,7},{.2,7},{.05,10}

Actually means

100% chance of doing 7 hitpoints of damage
40% chance of doing 14 hitpoints of damage
20% chance of doing 21 hitpoints of damage
5% chance of doing 31 hitpoints of damage

Correct?

And by extension, if I wanted a unit to have a chance of doing NO damage, I could start with .9 rather than 1: {.9, 7}

Which would mean that there is a 90% chance of doing 7 hitpoints of damage, but also a 10% chance of doing no damage - correct?

I'll have to look at the ds. table again with all of this in mind but it makes sense now (assuming I got both of the above correct).

Yes, this is correct.

Can we annoy the player once per load to prevent them from removing this warning forever by accident? The gunners are probably likely to be annoying quickly but with interception range varying from 2-4 spaces and no good visual way to show an aircraft zooming in/diving in for attack, we might want to annoy the player constantly about the fighter interceptions.

Yes, once per load will be possible. We'll work out those options after we're sure the 'fundamentals' are working.

I'll take another look at it tonight and see if I can get it to work. It was quite late so very possible I did miss something.

For testing purposes, I would recommend turning off the maxAttacks setting. Easiest way to do that is to search for the 'postReactionFunction' and comment out

Code:
 state.reactions[reactingUnit.id] = state.reactions[reactingUnit.id] + 1
(2nd instruction of the function)

On that topic, I forgot to clear state.reactions every turn, so I'll make a note of that in the to-do list.

Awesome. I'll add these in too. I'm very impressed with how you've made combat 3D in Civ2. That's not even possible in Civ6. I hope some people are paying attention to all this because this is some crazy cool stuff.

Pretty soon, our combat system will be "press k, and see the combat results". We're going to introduce that functionality for Flak soon. A lot of interesting possibilities in that. Won't work for the AI of course, but we just have to wait for TNO to fix the onCombat trigger.

Also - I am attempting to see if I can modify your Battle of Atlantic system and apply it to Revolt Risk in France. If you happen to be working on this now, I will stop, but if you aren't, I'd like to take a shot at it.

My plan was to work on fixing radar and moving veteran status around, mostly since I can do a lot of work on those without needing to modify the events file. Go ahead and try to make the modification.

One thing I am concerned with is that if the German player gets 5-6 freight trains in a certain place in France the best move would be for them to build 2-3 airfields right next to where these spawn so that they can immediately build 2-3 planes per turn by exploiting this system. I don't want that to happen. I'm wondering what options there are to delete cities (probably onActivation of any unit) if they are in a certain coordinate box, and not on a specific terrain type (in this case the city type). This seems like a pretty simple/straight forward thing. I might try to see if I can get this to work as well.

That could work, but you could just refuse to spawn a freight train too close to an airfield (or spawn it somewhere else instead). Maybe make the location random (i.e. production comes from different parts of France each turn).
 
At the moment, aircraft can react even if in an airfield. That can be turned off if you like, or made dependent on the unit (i.e. maybe certain interceptors could react directly from an Airfield). Now that I think about it, the area damage function will also have to take into account that units might be on the ground in an airfield (and probably shouldn't be damaged by flak). Will make corrections once I have the events again.
 
For the purposes of this scenario, any aircraft in an airfield should be presumed to be landed/refueling/stationary sitting ducks. No aircraft should react.

Now that we have the ability for interceptors to react from several tiles away, I'd even ask that you figure out a way to cut all air units' defense in half when they are on an airfield terrain.

Thus, instead of "stacking" 109s in airfields to defend 262s, you'd instead want them to patrol outside of the airfield. Also, the 3.7cm would be all the more important as it would be the only unit that could stand in the way.

One of the main things the Allies did, especially towards the end of the war, was to send their fighters off to roam at will near known Luftwaffe airfields and attack aircraft on the ground. I'd like to see that happen more here and given that I can control how effective light flak is against certain targets, this might be something that jabo aircraft like the P47 do exceptionally well.

Also, I am fine with pressing k and firing all flak I suppose, so long as we are clear as to what happened (although it is satisfying to press k and send the flak bursts off yourself). This is better than going through 80+ units manually each turn. I don't want to do that for fighters or bombers though. I still want their ammo to get called up. I think it would be too foreign a concept to completely go abstract combat here.
 
On the other hand with the flak - the Germans have a few units (flak train), sdkfz 7/2 that are meant to move and fire. I'm concerned that going to a "one keypress initiates all" approach wouldn't work well. It would work much better with "fixed" flak like the 88s and 3.7inch.
 
Now that we have the ability for interceptors to react from several tiles away, I'd even ask that you figure out a way to cut all air units' defense in half when they are on an airfield terrain.

That could be tricky. In some sense, we have the power to load a new rules.txt whenever we have a trigger option. This means, we could give 88s really good defense against tanks by using the onActivation event. A tank must be the most recent unit activated in order for it to attack, so we set 88 defense high when a tank is activated, and 'normal' when another unit is activated. This, unfortunately, doesn't allow us to change the defensive value of a unit based on the terrain it is currently sitting on. If we do it based on if the munition activates on a tile next to an airfield, that puts nearby patrolling units at risk of the same debuff. Probably the closest thing to what you want is to reduce aircraft defensiveness against bombs (or any unit without the fighter flag). Since bombs can't attack units in flight, the aircraft can only be damaged by a bomb if it is in an airfield. Strafing fighters wouldn't get a bonus in this case, but it might be good enough.

Unfortunately, a quick test with onResolveCombat suggests that you can't change the defensive value of a unit during a round of combat. You can do other things, like give one unit or the other extra damage, but it seems like you can't stop each round of combat from progressing. In theory, we could do 'most' of the combat during the first round of 'game engine combat' and revert to only 'game engine combat' once one unit is below 10% hp or something. However, I'd be cautious about using onResolveCombat. Nighttime asked TNO about it, but TNO had left by that point. If TNO decides to make a change the next time he appears, we run the risk of breaking our event, and it wouldn't necessarily do what we want very well anyway.

Also, I am fine with pressing k and firing all flak I suppose, so long as we are clear as to what happened (although it is satisfying to press k and send the flak bursts off yourself). This is better than going through 80+ units manually each turn. I don't want to do that for fighters or bombers though. I still want their ammo to get called up. I think it would be too foreign a concept to completely go abstract combat here.

I wasn't really suggesting that we do fully abstract combat, just that we're already getting pretty close. My comment about doing all combat after a k press was more along the lines of 'press k to start a dogfight within 3 squares of this unit' not 'do combat everywhere on the map with one key press.' My plan for k-press flak is that 'k' means fire the flak unit currently active, and backspace means fire all flak of this type. It doesn't have to be this way. If you really like using flak bursts as ammo, we can do the following: when a heavy flak unit is activated with enemy aircraft within range, an 'air raid warning' message is presented to the player, so he knows that there is something to fire at. If no message appears, the player knows in half a second that he can press space bar or move the flak and not miss an opportunity for damage. No need to scroll through maps or fly planes around looking for targets, or shooting into the darkness just in case. This would be less work than programming in the 'offensive key press damage'. All you lose is 'area damage' on the offense, which isn't a huge loss.

I could even program in an event that wakes up and unfortifies all flak in an 'air raid' city/installation, so the player doesn't have to check those units either.
 
Finally if you could please help me understand how to edit this to get a dive bonus - that isn't totally clear to me. Let's say there's a 50/50 chance that 190A5 can successfully bounce a lower strategic bomber and inflict an additional 10 points of damage. What would I add to this?

Code:
ds.Fw190A5interception = {{1, 6},{.4,10},{.2,10}}

reactionDamage[unitAliases.Fw190A5.id] ={all = {triggerTypes = reactionGroups.strategicBombers, damageSchedule = ds.Fw190A5interception},}

Thanks!

Code:
reactionDamage[unitAliases.Fw190A5.id] ={all = {triggerTypes = reactionGroups.strategicBombers, damageSchedule = ds.Fw190A5interception}, dive = {triggerTypes = reactionGroups.strategicBombers, damageSchedule = {{.5,10}}}}

The code I provided may not be what you want. This will simply add {.5,10} to the existing damage schedule. Given the 'all' damage schedule of {{1, 6},{.4,10},{.2,10}}, this would yield the following damage probability to a unit subject to the dive attack:

50% 6 damage (.5-1 'rolled')
10% 16 damage (.4-.5 'rolled')
20% 26 damage (.2-.4 'rolled')
20% 36 damage(0-.2 'rolled')

Maybe what you want to do is make the two schedules 'independent', that is, apply

60% 6 damage
20% 16 damage
20% 26 damage

Then, 'roll again' for a 50-50 chance to do 10 extra damage. The probabilities would become

30% 6 damage
30% 16 damage
10% 16 damage
10% 26 damage
10% 26 damage
10% 36 damage

Which you would have to write into the table, taking into account that the other table was already applied. Easiest way would be to use{{1,-6},{.4,-10},{.2,-10}, } to start off with a 'clean slate'.

We can discuss this more tomorrow (and possible solutions), but I just realized that I may have given you incorrect information and wanted to write this now before I forgot. I can make a new roll for each damage table, but then you can't have correlated damage if you want it in other contexts.
 
That could be tricky. In some sense, we have the power to load a new rules.txt whenever we have a trigger option. This means, we could give 88s really good defense against tanks by using the onActivation event. A tank must be the most recent unit activated in order for it to attack, so we set 88 defense high when a tank is activated, and 'normal' when another unit is activated. This, unfortunately, doesn't allow us to change the defensive value of a unit based on the terrain it is currently sitting on. If we do it based on if the munition activates on a tile next to an airfield, that puts nearby patrolling units at risk of the same debuff. Probably the closest thing to what you want is to reduce aircraft defensiveness against bombs (or any unit without the fighter flag). Since bombs can't attack units in flight, the aircraft can only be damaged by a bomb if it is in an airfield. Strafing fighters wouldn't get a bonus in this case, but it might be good enough.

Unfortunately, a quick test with onResolveCombat suggests that you can't change the defensive value of a unit during a round of combat. You can do other things, like give one unit or the other extra damage, but it seems like you can't stop each round of combat from progressing. In theory, we could do 'most' of the combat during the first round of 'game engine combat' and revert to only 'game engine combat' once one unit is below 10% hp or something. However, I'd be cautious about using onResolveCombat. Nighttime asked TNO about it, but TNO had left by that point. If TNO decides to make a change the next time he appears, we run the risk of breaking our event, and it wouldn't necessarily do what we want very well anyway.

Ok - well - let's start by just making sure they don't react. If it's too much trouble to implement the other thing now, that's fine. We can always revisit it if TNO shows up again.

I wasn't really suggesting that we do fully abstract combat, just that we're already getting pretty close. My comment about doing all combat after a k press was more along the lines of 'press k to start a dogfight within 3 squares of this unit' not 'do combat everywhere on the map with one key press.' My plan for k-press flak is that 'k' means fire the flak unit currently active, and backspace means fire all flak of this type. It doesn't have to be this way. If you really like using flak bursts as ammo, we can do the following: when a heavy flak unit is activated with enemy aircraft within range, an 'air raid warning' message is presented to the player, so he knows that there is something to fire at. If no message appears, the player knows in half a second that he can press space bar or move the flak and not miss an opportunity for damage. No need to scroll through maps or fly planes around looking for targets, or shooting into the darkness just in case. This would be less work than programming in the 'offensive key press damage'. All you lose is 'area damage' on the offense, which isn't a huge loss.

I could even program in an event that wakes up and unfortifies all flak in an 'air raid' city/installation, so the player doesn't have to check those units either.

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. Indeed one of the major complaints about TOT (and actually a major reason it took me so long to come to it) was that they did away with the attack animation. It made combat seem so... "meh." I don't want to go back to full-blown "meh" here. I think the interception/reaction system is a great system for units on the defense because it makes the attacker consider the depth of defense and prevents them from targeting a single unit. It also allows me the ability to represent speed better because some air units can do precisely that - pick out the weak without fear of the strong intercepting them because of their speed (jets). But I don't know that it's good for game play or the experience to just press k and see all the possible damage that your unit might do as well as all the damage that other units do to you. I'm perfectly fine with it triggering the defensive reactions but I think on offense at least, we should still have munitions. Otherwise it's just too abstract.

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.

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.
 
The code I provided may not be what you want. This will simply add {.5,10} to the existing damage schedule. Given the 'all' damage schedule of {{1, 6},{.4,10},{.2,10}}, this would yield the following damage probability to a unit subject to the dive attack:

50% 6 damage (.5-1 'rolled')
10% 16 damage (.4-.5 'rolled')
20% 26 damage (.2-.4 'rolled')
20% 36 damage(0-.2 'rolled')

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:

Code:
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.
 
Hi John and Prof. Garfield,

I’m following your development thread with much interest. The concepts you seem to be developing are quite revolutionary and it will be very interesting to see the end product, even though it is geared primarily for multiplayer. It would be nice, if you could add an occasional screen shot to be able to visualize your concepts to help us better understand what you are trying to implement.

I’d like to thank Prof. Garfield, in particular, for his new “[TOTPP] Get Started With Lua Events” thread, which is proving to be very informative. As you may already know, I’ve been working very closely with our colleague Knighttime on my own lua project, and though I believe I’ve already learned a lot from him (he’s been extremely patient in answering all my novice questions :)), it’s also good to get a course on the basics of lua, especially in regards to TOTPP.

That could be tricky. In some sense, we have the power to load a new rules.txt whenever we have a trigger option. This means, ...

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.

Code:
local function updateSeason (initialLoad)

              local monthNumber = getMonthNumber(civ.getTurn())
              -- ==== 10. WINTER ====

              if monthNumber >= 11 or monthNumber <= 3 then
                            -- Note: November through March are the winter months; set winter graphics at the *beginning* of those months
                            state.winter = true
              else
                            state.winter = false
              end

              if state.winter == true then
                            civ.ui.loadTerrain(0, 'Terrain/wTerrain1.bmp', 'Terrain/wTerrain2.bmp')
                            civ.playSound("Winter.wav")
                            print("Loaded winter terrain")
                            if monthNumber == 11 and initialLoad == false then
                                           if state.frenchForcedMarchAbility == true then
                                                         civ.ui.text(func.splitlines(winterOneText))
                                           else
                                                         civ.ui.text(func.splitlines(winterTwoText))
                                           end
                            end
              else
                            civ.ui.loadTerrain(0, 'Terrain/sTerrain1.bmp', 'Terrain/sTerrain2.bmp')
                            print("Loaded normal (summer) terrain")
                            civ.playSound("Spring.wav")
                            if monthNumber == 4 and initialLoad == false then
                                           if state.frenchForcedMarchAbility == true then
                                                         civ.ui.text(func.splitlines(summerOneText))
                                           else
                                                         civ.ui.text(func.splitlines(summerTwoText))
                                           end
                            end
              end
              -- ====================
end

So for now, we are using winterOneText and summerOneTex messages to advise the client that they need to run a bat file as well to switch the rules files.

Is it possible to have the rules.txt file switched in the lua code as well?
 
Back
Top Bottom