How does the recruit event really work?

[Atreides]

The following snippet was written by someone a long time ago and I discovered that it does not work as expected. The recruits are not each given the parameters that are included in their unit_types but instead are taking the ones from the last unit recruited. So on turn 1 if you recruit 5 units all 5 have the variables meant for unit 5.

The event is loaded from the unit_type as part of the ability.

I would expect that the last recruit event added would only affect the current recruit.

So how does it really work?

By the way I don't need this code fixed, I wrote a hack that takes its place, I'm just curious about how things work.

Code: Select all

# Canned definition of the corruption ability to be included in an abilities clause.
# requires the chance to turn into a different unit as an input
# requires the unit type to spawn when the corruption occurs
# example:
# use {ABILITY_CORRUPTION 5 Spawn} inside an abilities tag
# for the unit to have 5% chance to turn into a Spawn every turn

#define ABILITY_CORRUPTION CORRUPT_PROBABILITY UNIT_TYPE
    [dummy]
        name=_ "corruption"
        id=corruption
        description=_ "This unit has a "+{CORRUPT_PROBABILITY}+"% chance to turn into a "+{UNIT_TYPE}+" at the beginning of each of its turns."
    [/dummy]
[/abilities]
[event]
    name=recruit
    first_time_only=no
    [filter]
        ability=corruption
    [/filter]
    [set_variable]
        name=unit.variables.corrupt_proba
        value={CORRUPT_PROBABILITY}
    [/set_variable]
    [set_variable]
        name=unit.variables.corrupt_unit_type
        value={UNIT_TYPE}
    [/set_variable]
    [set_variable]
        name=unit.variables.corrupt_check
        value=no
    [/set_variable]
    [unstore_unit]
        variable=unit
    [/unstore_unit]
[/event]

after this comes the corruption code which does work fine.

[Ravana]

[unit_type][event] is required to have id. Otherwise you see multiple versions of event acting together.

[Atreides]

[unit_type][event] is required to have id. Otherwise you see multiple versions of event acting together.

Yep, one per unique unit type loaded containing the event.

I've also had to fix other code that was broken due to multiple events. (quite noticeable if the event harms a unit!)

On the whole I prefer to load events in the era rather than the unit type. The latter really has limited use, best reserved for a case where you want to delay the event until the appearance of a particular unit. A lot of extant code however seems to be based on templates of abilities with events crowbar-ed into them. Causes unbalanced code as well for wmllint, indent and gettext!

Speculation: These era creators are probably taking templates from ubiquitous campaign code that would have more need for unit embedded events than an era ever would but didn't realize it. I doubt an era actually ever needs an event in a unit... Yep, in future I'm ripping them all out and stuffing them were they belong, an events directory loaded from the era tag.

Interestingly I almost made that code above work by using nested events and remove event but then I ran into the limit of the event not being loaded for subsequent duplicate unit types.

I think the problem is that trying to pass parameters via the event in this way isn't really workable. I was just curious if in fact it was doable, but I suspect that this code was just a fantasy by its original creator.

Oh well my version works nicely so I'm happy. : )

[Ravana]

Main reason to have events like this is for folder structure. Not having parts of ability in different file.

You could pass parameters like this, but it should be with unique ids depending on the parameters.

[Celtic_Minstrel]

On the whole I prefer to load events in the era rather than the unit type. The latter really has limited use, best reserved for a case where you want to delay the event until the appearance of a particular unit. A lot of extant code however seems to be based on templates of abilities with events crowbar-ed into them. Causes unbalanced code as well for wmllint, indent and gettext!

Speculation: These era creators are probably taking templates from ubiquitous campaign code that would have more need for unit embedded events than an era ever would but didn't realize it. I doubt an era actually ever needs an event in a unit... Yep, in future I'm ripping them all out and stuffing them were they belong, an events directory loaded from the era tag.

Putting events in the era wasn't possible until recently, so the only alternative to placing them in the unit type was to add them to every single scenario. So, there are presumably many, many things that haven't yet been updated to the recommended method.

That said, even then, there's a slight advantage to putting the event in the unit. It means that no matter how that unit is placed, it definitely has the event associated with it, so if your addon is a modification that just adds a bunch of units for everyone to use, placing the event in the unit would probably still be the safest solution.

[Atreides]

Thanks for the replies, I agree with the points you make. I had kinda anticipated that there were reasons I'd overlooked. : )

Most interesting to me is to learn that era events are new. Since I am a newcomer (1.12+) who has for some reason specialized in updating old code this is pure gold for me to know.

[Ravana]

Eras have supported events for last 14 years at least.

[Celtic_Minstrel]

I'm sure there could easily be add-ons that haven't been fully updated in that long.