event crashes Wesnoth

[Darker_Dreams]

ah... I take it capture events fire before moveto events?

[AI]

probably, which probably causes changing the unit inside a capture event to mess up the moveto and then proceed to crash the game.

[Darker_Dreams]

actually, it just flags the variable so the moveto never gets to activate.
blah.

So, every time I set up a location that doesn't run on the base "every village" event I have to set the "cleared" variable to yes in at start/prestart then use some other variable to track whether the special event for that location has triggered.

Huzzah.

[Darker_Dreams]

trying to clean up the wierdness AI noted about modifying unit-types;

the wiki says

Code: Select all

[set_variable]
name=unit_store.status.poisoned
value=yes
[/set_variable]

modifies the poisoned status of a unit stored in unit_store

therefore, logically, unit_store.modifications.XYZ will have the traits of a unit at XYZ.

Question; how/where do I find what that XYZ looks like and what is stored in it? (ie; Is it unit_store.modifications.trait with dexterous/strong/resilient stored? is it unit_store.modifications.dexterous with a yes/no/(no value)?)

[zookeeper]

Question; how/where do I find what that XYZ looks like and what is stored in it? (ie; Is it unit_store.modifications.trait with dexterous/strong/resilient stored? is it unit_store.modifications.dexterous with a yes/no/(no value)?)

Set binary/compressed saves off, save a game, open the save in an editor. You see the internals of the units best that way.

[Darker_Dreams]

okaaay....

according to everything I'm seeing (including this and the expanded save) feeding this unit;

{GENERIC_UNIT 1 (Peasant) 10 5}

into the this event;

Code: Select all

[event]
        name=moveto
        first_time_only=no
        
        
        [if]
            [have_unit]
                side=1
                type=Peasant
                x,y=10,7
                x,y=$x,$y|
            [/have_unit]

        [then]
[store_unit]
    [filter]
        x,y=10,7
    [/filter]
    variable=temp
    kill=no
    animate=no
[/store_unit]
{DEBUG_MSG $temp.[modifications].[trait].id}
        [/then]

        [else]
            [allow_undo][/allow_undo]
        [/else]
        [/if]
    [/event]

should spit out the ID's of its trait(s).

yea? or did I miss something. (obviously I missed *something* because the debug box was empty- any suggestions as to what it might be.)

[Rhuvaen]

Code: Select all

{DEBUG_MSG $temp.[modifications].[trait].id}

That's not right. What are the wml tag brackets doing in there?

[trait] is an array, so you need to reference an element by id.

Try it like this:

Code: Select all

{DEBUG_MSG $temp.modifications.trait[0].id}

[Darker_Dreams]

thank you.

As for the [] being there, I put it in the way it appeared in the wiki

When a unit is stored, the following values may be manipulated with [set_variable]
...
# [variables]
# [status]
# [modifications]

I wasn't sure from anything how that should be changed to make it work right (and certainly wouldn't have guessed to do the trait part as an array).


that spit out the trait ID perfectly.

but... you can't put an if or a switch inside an if, and I don't know how else to shift the lowercase intelligence (etc) to the uppercase INTELLIGENCE for {TRAIT_INTELLIGENCE}... much less to have it add the expanded wml.


edit; unless I just make copies of the relevant {TRAIT_ macros that use lowercase versions of the id's... wow, I can only imagine how bad that is.

[Darker_Dreams]

well, for now this is working for me, so I'm going to use it.

[Darker_Dreams]

apparently I wasn't watching quite close enough and it really isn't transferring the traits like I thought.
grr.

[Rhuvaen]

This cannot work, since Macros are expanded by the preprocessor, and that can't know what your variable value at execution time is...

The only way to get this to work is to:
1. check the unit trait ids
2. use an [if] around the whole [unit], similar to a case statement with each trait combination included
3. use the traits hard-coded into the [unit] tag

All this would be easier if the traits were standardized, with a certain effect order and those effects that aren't needed are just included in an empty version. Then you could simply copy the traits over using config object copying, but I'm not going to explain all this as it leads to extreme ugliness and wml-bloat, besides not being compatible with the way traits are defined by the game as-is.

[Darker_Dreams]

Then I'm not sure how to filter what traits get passed as it seems to require multiple nested Ifs regardless. Passing the traits to a macro doesn't help, because the macro needs one or more Ifs to sort it. Moving the unit creation out of the initial event doesn't help, because I'd need to use an If to filter that another event should recreate the saved unit...

I suppose I could have it create a "marker" unit with a set ID (or change the original unit's ID to "marker"?), then have another event pick up and destroy the marker unit and create the new unit with the stored information...
...wow that's just an ugly concept.

[Darker_Dreams]

yeah... aaaaand that blew up in my face thoroughly.