event crashes Wesnoth

[Darker_Dreams]

you posted while I was putting my thoughts together and checking some last stuff... so, double-post

After some testing I can safely tell you it spits out crapload of garbage. And don't tell me it works, because it doesn't, I'm quite sure that event would not survive a stress-test of capturig/recapturing of a cluster of nine villages. My careful guess at the moment is that it checks x coord only and nobody noticed because the villlages are on different x axis each.

That's between you and the descent into darkness maintainer. I do find it amusing however.

edit; column 4 has 3 villages (y= 1, 4 and 7), and column 12 has 2 (y= 3 and 7).

If you want to see for yourself what's happening place an
{DEBUG_MSG $village_$x1,$y1|_cleared} inside the if block
Place
{VARIABLE foo $village_$x1,$y1|_cleared}
{DEBUG_MSG $foo}
as well, if village_$x1,$y1|_cleared was a proper variable name effect should spit out yes|no

I will check this in a moment.

My advice for now is to replace the comma with an underscore

Code: Select all

village_$x1|_$y1|_cleared

will be much more predictable if you really need such form.

I already tried that exact form, and still got the crash. if you're sure it'll be more stable and reliable I'll stick with it. but the fencer thing (above) is making me a little skittish.

EDIT
If you checked with {DEBUG_MSG village_$x1,$y1|_cleared} you got misleading output, since it throws out a proper string but not proper variable name. Not all strings can be used as a variable name

honestly, I've got no idea how to use the debug stuff. this is all trial and error with standard output. I'll be trying it by copy-pasting your suggested method into my wml, and then figuring out what the change did when I see what happens.

[AI]

In my own experience, changing a unit's type is generally a bad idea, as it tends to keep (some) old animations (any that aren't overwritten). I've had cavalrymen that looked like blood bats (cos the animation was constantly playing) and other strange things.

You probably want to kill the peasant and drop in a fresh Fencer w/ same name instead. You'll lose the traits though, as I haven't found a way to reliably copy those.

[Darker_Dreams]

In my own experience, changing a unit's type is generally a bad idea, as it tends to keep (some) old animations (any that aren't overwritten). I've had cavalrymen that looked like blood bats (cos the animation was constantly playing) and other strange things.

You probably want to kill the peasant and drop in a fresh Fencer w/ same name instead. You'll lose the traits though, as I haven't found a way to reliably copy those.

That's generally aggravating.

I don't know how to go about accessing the various pieces of a stored unit, but the wiki says that [modifications] are readable... so, I would imagine that you could get all the data... but how is beyond me.

anyone want to point out where I can find what the parts of a stored-unit-variable mean?

[Mist]

Replace your event with this :

Code: Select all

[event]
    name=capture
    first_time_only=no

    [if]
        [variable]
            name=village_$x1|_$y1|_cleared
            equals=no
        [/variable]
        [variable]
            name=unit.type
            equals=Peasant
        [/variable]
        [then]
            {DEBUG_MSG "Passed check"}
            {LOYAL_UNIT 2 (Master at Arms) 10 7 (Morwin) (_ "Morwin")}
            {VARIABLE village_$x1|_$y1|_cleared yes}
            {DEBUG_MSG "Set flag"}
            [message]
                description=Morwin
                message=_ "I'm too old now to get involved with such craziness. My friends and I came to this quiet valley to retire. I'll tell you what; I can give you some training which will help you be able to deal with it."
                [option]
                    message=_ "Sure!"
                    [command]
                          {MODIFY_UNIT $unit.id type Fencer}
                    [/command]
                [/option]
                [option]
                    message=_ "We don't have time for that!"
                [/option]
                {DEBUG_MSG "Changed type"}
            [/message]            
           [kill]
            description=Morwin
            animate=no
            fire_event=no
            [/kill]
        [/then]
    [/if]
[/event]

And tell me what you get. If everything works you'll get three popups with content as in {DEBUG_MSG}. If not tell me which popups displayed properly

[Darker_Dreams]

Replace your event with this :

Code: Select all

And tell me what you get. If everything works you'll get three popups with content as in {DEBUG_MSG}. If not tell me which popups displayed properly

I get an error from the line {MODIFY_UNIT $unit.id type Fencer}

changing that out for the x,y= I was using and it just doesn't do anything.
My assumption is unit.type isn't doing the trick for some reason.


I put the other debug message at the end of the event and it still shows up if that's what you're looking for.

[Mist]

Argh, sorry, there was a syntax change in 1.5 and still get confused at times. Replace $unit.id with $unit.description.

[Darker_Dreams]

1.5? :-p showoff.


reverted to what you sent and made that change- it still errors on that line.

[Mist]

Eh? Did I tell you that I hate macros? I hate macros
The hard way then

Code: Select all

[store_unit]
   [filter]
      description=$unit.description
   [/filter]
   kill=yes
   fire_event=no
   variable=tmp_var
[/store_unit]
{VARIABLE tmp_var.type Fencer}
[unstore_unit]
    variable=tmp_var
[/unstore_unit]
{CLEAR_VARIABLE tmp_var}

That needs to replace {MODIFY_UNIT ... }

[AI]

the macro in 1.4:

Code: Select all

#define MODIFY_UNIT FILTER VAR VALUE
    # Alters a unit variable (such as unit.x, unit.type,
    # unit.side), handling all the storing and unstoring.
    #
    # Example that flips all spearmen to side 2:
    #! {MODIFY_UNIT type=Spearman side 2}

In other words, what you just posted (that is, before the last un-macro'd version) could never have worked anyway. (where is $unit even defined?)

so, how about this:

Code: Select all

[store_unit]
    [filter]
        x,y=10,7
    [/filter]
    variable=temp
    kill=no
    animate=no
[/store_unit]
[kill]
    x,y=10,7
[/kill]
[unit]
    side=$temp.side
    type=Fencer
    description=$temp.description
    user_description=$temp.user_description
    canrecruit=$temp.canrecruit
    facing=$temp.facing
    x=10
    y=7
    moves=$temp.moves
[/unit]
{CLEAR_VARIABLE temp}

unfortunately, "modifications=$temp.modifications" does NOT work...

[Mist]

In other words, what you just posted (that is, before the last un-macro'd version) could never have worked anyway. (where is $unit even defined?)

Automaticaly when firing capture event As with any other event triggering on an unit related stuff
Anyway, true, it should be {MODIFY_UNIT (description=$unit.description) type Fencer} but I usualy do such stuff explicitely for clarity of code.

[Darker_Dreams]

Eh? Did I tell you that I hate macros? I hate macros
The hard way then

Code: Select all

...

That needs to replace {MODIFY_UNIT ... }

macros make things cleaner for me, and provide convenient snippits of code for me to crib the way things are used from.

regardless;
it runs now, but the peasant captures the village without any event or message.

I'll try AI's in a moment...


you gent's do realize that I posted a copy of the stripped out scenario I'm testing this in on the first page- so you could try this out yourself...


edit; AI's didn't do anything either. Somehow the filter that's being used isn't triggering the if statement.

[Mist]

Well comment them out one by one and see which one fails, but my guess is that village_$x1|_$y1|_cleared is not set before the event, so it can't be equal to 'no'. Either do {VARIABLE village_10_7_cleared no} at the start event or replace first [variable] clause with

Code: Select all

    [variable]
        name=village_$x1|_$y1|_cleared
        not_equals=yes
    [/variable]

And no, I can't test stuff, I'm at work

[Darker_Dreams]

ok, I went back to my own code. I plugged the {debug...foo} macro Mist was talking about earlier in, and it's output seems to show up regardless of where I put it (including right before [/event]} I tried both Mist and AI's expanded replacements for the {modify_unit...}, and both crashed as soon as the debug message was cleared from the screen.

[AI]

in other words, wesnoth can't handle unit-changes in capture events? we encountered it before in attacks....

[Darker_Dreams]

hah.

apparently it works just fine as a moveto.