[event] and [trigger] (new tag)

[Haravikk]

This is something that has come up from my forays into WML, basically it's a solution to my massive amounts of code duplication just to get a few custom villages. Yes I've defined the code as macros and am using that to reduce the amount of WML, but the duplication is still there!

So, the solution is a relatively simple addition to WML:

Custom event names
Not exaclty a big leap here, you give your event a name that isn't predefined, like:

Code: Select all

[event]
name=jim
[/event]

If there is fear of this causing issues further along (such as new pre-defined event names clashing with someone's custom name) then this could be added via another attribute (e.g id). For this idea name will suffice for now. However, as noted later, predefined events are used too, in which case trigger would have this new attribute as well (ie it can trigger on name, or id).

The [trigger] tag
This tag has but a single attribute, name, and you can probably see where it's going. The name attribute would quite happily point to an event, such as the aforementioned custom [event] tag called jim:

Code: Select all

[trigger]
name=jim
[/trigger]

This instantly triggers the event pointed to by the name attribute (or does nothing if no event exists).
It takes into account an event's trigger state (ie if it's first_time_only then trigger will fail if used to try and trigger an event twice).

[trigger] is useable only within an event tag, and with it passes any [filter] or [filter_second] information that it's parent [event] found. This allows you to trigger moveto events, or attack events or whatever using the information you have found. ie consider the following code:

Code: Select all

[event] #Custom village event
name=moveto
    [filter]
    side=1
    x,y=12,14
    [/filter]

    [trigger]
    name=jim
    [/trigger]
[/event]

[event]
name=jim
    [message]
    speaker=unit
    message= _ "Argh! I am in a village!"
    [/message]
[/event]

Now if a unit lands on the space 12,14, they will trigger the appropriate moveto event, which can then in turn trigger the 'jim' event.

Conclusion
This would be a significant (and not particularly complex) addition that would allow for code re-use. So now if I wanted 20 houses triggering code identical to that in the 'jim' event, then all I have to do is trigger it appropriately, rather than duplicating 'jim'. Admittedly the example doesn't so much warrant it, but imagine the jim event is a 50 line set up for calculating a number of units to produce as a result of the action, what type they should be and what messages should accompany them, and it becomes a huge advantage to do this rather than having 1000 lines of WML!

The mentioned element of the [trigger] event passing [filter] data isn't really required, though it would be nice if you have filtered already and don't want to do so again in the called event (custom events would still be able to filter if you need them to).
The alternative of course is to use [set_variable] to pass data into an event you are calling, just like a proper function call.

I'm not sure how [event] tags are handled, but it doesn't seem like a hugely complicated thing to have a [trigger] event setting them off as the user wishes.

Would also be AWESOME for testing as well

[Ranger M]

The [trigger] tag
This tag has but a single attribute, name, and you can probably see where it is going. The name attribute would quite happily point to an event, such as the aforementioned custom [event] tag called jim:

Code: Select all

[trigger]
name=jim
[/trigger]

This instantly triggers the event pointed to by the name attribute (or does nothing if no event exists).
It takes into account an event's trigger state (ie if it is first_time_only then trigger will fail if used to try and trigger an event twice).

[trigger] is useable only within an event tag, and with it passes any [filter] or [filter_second] information that it is parent [event] found. This allows you to trigger moveto events, or attack events or whatever using the information you have found. ie consider the following code:

Code: Select all

[event] #Custom village event
name=moveto
    [filter]
    side=1
    x,y=12,14
    [/filter]

    [trigger]
    name=jim
    [/trigger]
[/event]

[event]
name=jim
    [message]
    speaker=unit
    message= _ "Argh! I am in a village!"
    [/message]
[/event]

Now if a unit lands on the space 12,14, they will trigger the appropriate moveto event, which can then in turn trigger the 'jim' event.

Or you could do this:

Code: Select all

#define JIM
[message]
description=Jim
message= _ "Argh! I am in a village!"
[/message]
#enddef

[scenario]

Blah
Blah
....


[event]#Custom village event
name=moveto
    [filter]
    side=1
    x,y=12,14
    [/filter]

{JIM}

[/event]

Blah
Blah
...

[/scenario]

or, even better:

Code: Select all

[event]
name=capture
[filter]
description=Jim
[/filter]
[message]
description=Jim
message= _ "Argh! I am in a village!"
[/message]
[/event]

I'm pretty sure that the filter in there could involve x and y coordinates too.


Basically that example can be done in WML, and the trigger thing can be done in a macro (within the actual scenrio file, defined before the [scenario] tag)

[Haravikk]

Erm, I'm aware of this, it's an example

The point is, MACROS are pre-processing definitions, they essentially tell the game "copy/paste this chunk anywhere you see {MACRONAME}", meaning that for my 20 events of 50 lines each, BfW ends up with 1000 lines of WML. The .cfg file for my map may very well be shorter due to the macro, but that doesn't change the fact that it's going to end up with 1000 lines either way.

If you can define only a function, then instead you have lots of little events, say my events only contain a trigger command, they are now only 8 lines each, and point to the 50 line event that I want to trigger.

For 20 events you now have 50 + (20 * = 210, a far-cry from 1000 lines of stuff.

But as I say, my example is just that, an example, suppose I'm not using the name=capture event type because I already control a number of the houses I want to perform custom actions, then the capture type event is of no use as it won't trigger.

[Ranger M]

But as I say, my example is just that, an example, suppose I'm not using the name=capture event type because I already control a number of the houses I want to perform custom actions, then the capture type event is of no use as it won't trigger.

then do this:

Code: Select all

[event] 
name=moveto
[filter] 
description=Jim
x=8,12,23,29
y=15,8,27,14
[/filter] 
[message] 
description=Jim 
message= _ "Argh! I am in a village!" 
[/message] 
[/event]

at which point if Jim moves to those villages then the event triggers.



there are probably examples which couldn't be shortened in WML, but please choose one that can't, because I have never found one which couldn't be (although my WML is probably full of them)

[zookeeper]

Code: Select all

[event] 
name=moveto
[filter] 
description=Jim
x=8,12,23,29
y=15,8,27,14
[/filter] 
[message] 
description=Jim 
message= _ "Argh! I am in a village!" 
[/message] 
[/event]

at which point if Jim moves to those villages then the event triggers.

That works? Wow. Cool.

[toms]

Erm, I'm aware of this, it is an example

The point is, MACROS are pre-processing definitions, they essentially tell the game "copy/paste this chunk anywhere you see {MACRONAME}", meaning that for my 20 events of 50 lines each, BfW ends up with 1000 lines of WML. The .cfg file for my map may very well be shorter due to the macro, but that doesn't change the fact that it is going to end up with 1000 lines either way.

If you can define only a function, then instead you have lots of little events, say my events only contain a trigger command, they are now only 8 lines each, and point to the 50 line event that I want to trigger.

For 20 events you now have 50 + (20 * = 210, a far-cry from 1000 lines of stuff.

But as I say, my example is just that, an example, suppose I'm not using the name=capture event type because I already control a number of the houses I want to perform custom actions, then the capture type event is of no use as it won't trigger.

Deep in the eternals of the computer, it turns always to the same length and eats the same amount of power.

[Haravikk]

there are probably examples which couldn't be shortened in WML, but please choose one that can't, because I have never found one which couldn't be (although my WML is probably full of them)

My most recent example was this:

Code: Select all

[event]
name=sighted
    [filter]
    side=1
    [/filter]
    [filter_second]
    side=2
    [/filter_second]

    #Some actions
[/event]

[event]
name=sighted
    [filter]
    side=2
    [/filter]
    [filter_second]
    side=1
    [/filter_second]

    #Some actions
[/event]

If there were loads of these (perhaps so that similar things can be done for multiple teams) then they eat up memory as well.

Deep in the eternals of the computer, it turns always to the same length and eats the same amount of power.

Not really, the more WML you need to make your map work, the longer it takes to load. Even relatively simple things, just because you duplicate the task cause map loading times to get higher and higher as BfW parses everything. If it only has to deal with something once then it's quicker than dealing with it multiple times.

[toms]

This was not what I meant. I meant, there are ways to save filespace, but when it´s executed, the part takes the same power again, not related to the size of the file.

[deonjo]

but i think what he's trying to get at is, that when you go back and want to change something, you won't have to see the same thing over and over again, all you see is the macro thing. that way it is less confusing for the coder to adjust anything, because he can see more of the essential code, and less of the repetive code. and if this can be done, and not have it harder for the computer to process, then by all means, why don't you use it?

[scott]

Are you sure the problem you're trying to solve even exists? What is the performance difference?

[Elvish_Pillager]

If you try to expand a macro for every hex for every side for every turn from 1 to 100, performance goes straight to hell. I actually have done this; I should know...

Anything within reason, though, displays no noticable problems.

Anyway, WICOT. You can simply have a name=die event filtered by description=jim, and then create and kill with fire_event=yes a unit by that description. (If this sounds complex, you can make macros to do it for you. )