Calling Catfish!

[techumseh]

Would you mind reposting your comments on the "Delay" modifier? I can't find it on your site, and the new "advanced search" feature on 'poly is quite useless. Thanks.

[Catfish]

It's on the main page, an entry way back in 2004.

I'll run through it. You probably know most of this anyway.

1. Calculate the maximum number of concurrent Delay or DelayPerFlag events in your scenario. There's no simple formula for this; you'll just have to work through all the possible permutations and combinations in your head. If the events are uncomplicated, then your task is simpler. It's possible to have a single Delayed event triggered multiple times in one turn, each occasion loading 284 bytes into memory.
2. Multiply this number by 284. Delayed events require an additional 284 bytes of memory for each occurrence, regardless of size. Pre-loaded events require 284 bytes + strings (including null terminators) of memory (@AND events, double).
3. Run the scenario with @DEBUG enabled and obtain the remaining heap space from Report.txt. This number needs to be greater than or equal to the number you calculated in 2. If there is no memory available for Delayed events, your scenario will not crash; the Delayed events will simply never occur.

[techumseh]

That's helpful. My question had to do with single events triggered multiple times, and you answered it. Thanks.

[Catfish]

Obviously you want to avoid situations where it's impossible to calculate the maximum number of concurrent Delayed events. For example, you could easily blow out your events memory if Delayed UnitKilled events aren't tightly controlled.

[techumseh]

That's exactly what I'm trying to do. This is for American Civil War, and I want to resurrect the named leader units once each, eg. "Gen. Hood is wounded". I tried it without a delay and it seemed too unrealistic, so I'm adding a 6 turn delay while they recover from their wounds. There are 18 named leaders (9 each), plus 4 Union engineer units to be regenerated, for a total of 22 units. 22 X 284 = 6248. After some clean up of the events, I have 6604 kb left in the stack, so that should be fine.

It seems to me that I can squeeze some more events out of this, if I estimate probabilities. There is very little chance that over half the generals and engineers would be "in the hospital" on any given turn, so if I assume that only half the stack memory I've calculated for delays would be used at any time, it leaves me with 3124kb.

There are also some elite combat units that can't be built. The Union has the Iron Brigade (4 units) and the Irish Brigade (5 units), and the Confederates have Hampton's Legion (4 units), for a total of 13 units. I want these units to be replaced, but not endlessly, so I give them a 50% chance of being replaced using the RandomTurn trigger. If I use a 3 turn delay it should further reduce the potential demand on the stack. So, if all 13 were hors de combat at once, and half were being regenerated, that calculation would be: 13/2 X 284 = 1846kb. The final calculation would then be: 6604 - (3124 + 1846) = 1634kb as a margin.

I'm assuming from your post that the 284kb is only "borrowed" from the stack when the event is triggered and "repayed" when the event is completed. Is this correct? I'm also assuming that the use of the RandomTurn trigger in combination with the UnitKilled trigger means the 284kb is only borrowed when both triggers are true. Is that correct? And my riskiest assumption of all is that my arithmetic is right. Thanks for your help.

[Catfish]

There is very little chance that over half the generals and engineers would be "in the hospital" on any given turn, so if I assume that only half the stack memory I've calculated for delays would be used at any time, it leaves me with 3124kb.

With 3124 kb available, you shouldn't be having any problems with events memory: kb = kilobit (1000 bits), kB = kilobyte (1024 bytes). I want your version of ToT.

I want these units to be replaced, but not endlessly, so I give them a 50% chance of being replaced using the RandomTurn trigger.

You're using RandomTurn + UnitKilled as triggers. I'll offer an alternative method to spawn a unit with a 50% probability; one that avoids the @AND modifier. The game handles the @AND modifier very inefficiently: @AND events are stored in memory as two events, eg, RandomTurn/Action + UnitKilled/Action. (Try to avoid using big Text strings with @AND.) In WotR I use the Randomize modifier in conjunction with impossible spawn locations, eg, impassable terrain, ocean or even enemy-occupied cities - which may change during the course of the game. Example:

@IF
UnitKilled
unit=Iron Brigade
attacker=Anybody
defender=Union
@THEN
Delay
delay=3
CreateUnit
unit=Iron Brigade
owner=Union
veteran=true
homecity=none
randomize
locations
102,50  ;primary site, some risk of blocking
102,50
102,50
102,50
110,54  ;secondary site, safe from blocking
200,200 ;ocean
200,200
200,200
200,200
200,200
endlocations
@ENDIF

So what happens here? There is a 40% chance the unit will spawn at (102, 50). If this is blocked, the unit will spawn in (110,54). Excluding the probability that (102,50) is blocked, there is a 10% chance the unit will spawn in (110,54): some tile away from the front lines, considered safe from blocking. There is 50% chance that the unit will spawn in the ocean. Naturally, this is impossible. When a location proves impossible, the next location in the list is used. This is the case even when locations are Randomized. The event will continue to work down the list until a suitable location is found. If none is suitable, then the event aborts. Obviously, if there's a blocking risk to the last workable location, the spawn probability for the event will drop below 50%. If you're also using the Count modifier, the event will abort without processing any remaining units. The number and distribution of location types can easily be tweaked to yield different spawn rates.

Advantage:

• Frees up 284 (+ strings) bytes. In the example above, that's 284 + 24 (21 characters in the Action part of the event + 3 null terminators) = 308 bytes.

Disadvantages:

• The Delayed event resides in memory for 3 turns, no matter what the result. However, it's still a net gain over RandomTurn + UnitKilled.
• More difficult to control the ranking of spawn locations; they're randomised.
• All Actions within the event are executed, even if no units are created. That's a problem if you wish to include a text box to accompany the arrival of new units.

So, if all 13 were hors de combat at once, and half were being regenerated, that calculation would be: 13/2 X 284 = 1846kb.

Events don't come in halves, so you're better off rounding up to the nearest 284. Actually, it's more practical to simply divide your remaining heap space by 284 and figure out how many Delayed events you can accommodate vs how many you need.

Assuming that all 13 elites take a beating, at 50% each, there's still a reasonable chance that more than half will respawn at least once (50% for at least 7, 29% for at least 8, 12% for at least 9), but the chance of this happening within the time-frame is probably remote - you'd know better than I. With 6604 bytes, you've got space for 23 Delayed events. Erring on the side of caution, you could reserve 9 for the elites. That leaves you 14 for the leaders and engineers. You believe 11 is OK.

I'm assuming from your post that the 284kb is only "borrowed" from the stack when the event is triggered and "repayed" when the event is completed. Is this correct?

Yes.

I'm also assuming that the use of the RandomTurn trigger in combination with the UnitKilled trigger means the 284kb is only borrowed when both triggers are true. Is that correct?

Yes, as with any event, the Action will only execute if the triggers are true.

Edit: I guess they need to fix the code box for the light forum skin.

[techumseh]

There is 50% chance that the unit will spawn in the ocean. Naturally, this is impossible. When a location proves impossible, the next location in the list is used. This is the case even when locations are Randomized. The event will continue to work down the list until a suitable location is found. If none is suitable, then the event aborts

I'm confused. According to my understanding of the above, if the event has 50% spawning locations in the ocean, and 50% safe locations behind Union lines, then wouldn't the unit be created in a safe location 100% of the time?

On the other hand, I always thought that if you use the Randomize modifier and the unit was to appear in a blocked location, it didn't appear. If so, then your idea will work just fine. Am I not understanding something?

Edit: Never mind. I did a little experimenting and using "Randomize" and "Count" it works. Each elite unit has 6 existing spawning locations and I've added 4 locations at sea. So each time one is killed, it has a 60% chance of regeneration.

[Catfish]

I'll try to clarify anyway. If any of the 5 ocean locations is randomly selected, nothing will spawn. If a selected location is not legitimate, the next location down the list is checked; the random seed is not reset. A unit will fail to appear if the selected location and all those below it in the list are not legitimate. Therefore, order is important; the impossible locations need to occupy the slots at the bottom of the list. This method is used extensively in WotR to control AI tribe numbers and it saved me a massive amount of event space.

On using the Count modifier: the spawn probability will drop for each additional unit above one, because as soon as one unit fails to appear, the CreateUnit action will abort. Example: 6:4 ratio of good to impossible tiles, Count = 3, results in a 21.6% chance of 3 units, 14.4% chance of 2 units, 24% chance of 1 unit, and a 40% chance of no units. The mean number of units created by this event is 1.176, not .6 x 3 = 1.8 as one might expect.

[techumseh]

Got it. Thanks again.