ghype's Problems:

[vghetto]

Sorry for the confusion.

This will work. I copied Shiki's heal_unit and commented out modify_unit. Either of them will work.
All that is need is {VARIABLE exploration 1} somewhere, and delete it or make it 0 when you want to disable it.

Note: Shiki's x,y had a problem, maybe that is why it didn't work for you.

Code: Select all

    [event]
        name=moveto
        # ID is needed here, so that if two units with the ability exist
        # the event will only be inserted once
        id=no_mp
        first_time_only=no
        [filter]
            side=1
            x,y=$x1,$y1           # so it's only for that one unit, not every with the ability
        [/filter]
        [filter_condition]
            {VARIABLE_CONDITIONAL exploration numerical_equals 1}
        [/filter_condition]
        [heal_unit]
            [filter]
                id=$unit.id
            [/filter]
            amount=0
            restore_statuses=no
            moves=full
        [/heal_unit]
        {CLEAR_VARIABLE heal_amount} # [heal_unit] always sets this variable

#        [modify_unit]
#            [filter]
#                id=$unit.id
#            [/filter]
#            moves = 5
#        [/modify_unit]
    [/event]

[ghype]

This will work.

It does ! Thanks a lot. I learned a bit with this as well.

I am not too sure about the $ up to this point. Now that I read the wiki again it makes sense. So the the $-sign accesses a variables value directly. That's the info from the wiki.

but code like x,y=$x1,$y1 and $unit.id I've come across in many places. I want to make sense of it. Or does it work in this case like a wildcard - like * for terrain?

Also for x,y=$x1,$y1: your comment said that "so it's only for that one unit, not every with the ability" . In the case of my scenario, it actually works for every unit on side 1 - which is actually exactly what I wanted. But if it should work only for specific units, then this line doesn't seem to do what the comment says.

[vghetto]

Yeah, it takes time to get clear.
As I said, I copied the code from an earlier post. The comment was part of it.

Let me see if I can explain variables and events. Hope these make sense.

You can think of variables as containers, the values are the stuff inside those containers.
For example {VARIABLE exploration 1}, the container is something called exploration, the stuff inside it is 1.
Say I don't know what is inside exploration. Writing $exploration will tell me what is inside it.

Now, about events. When any unit moves, the game will try to run all events that have the name moveto. Meaning it will try to execute all moveto blocks, like the one we have here.

Usually we don't want to do that. For example if a unit from side 2 moves around, we don't want our moveto event to execute.
This is where filters come in. If a unit from side 2 moves to location 10,11, the x1,y1 variables are automatically filled in with the values 10,11.
The filter starts to check, is this event taking place at x,y=10,11? Remember $ accesses the stuff inside
The answer is yes. Now the other question, is this event taking place by a side=1? The answer is no. So the rest of this moveto block gets ignored.

Now if a side=1 unit moves around. This is what will happen.
x1,y1 get automatically filled in with the values of the location where the event is taking place. Say 10,11
The filter starts to check:
is this event at 10,11? yes.
Is this side=1? yes.
Is the exploration=1? yes.

Since all is yes, the unit container gets filled in with the information of whatever soldier is at that event, or at $x1,$y1.

So the id of that unit at 10,11 will be $unit.id, remember we don't know what is the stuff inside, to access it we put a $ infront of the container name.

Now the rest of the moveto events continues to execute [heal_unit] and again it will only apply it to the unit with id $unit.id

You will not be able to tell the difference, but that's what just happened. the heal_unit in that case was applied to only 1 unit from side 1 and not all units from side 1.

Once another unit from side 1 starts to move around, the same thing takes place, and the event only happens for that unit and not the rest of the units.

Edit: That might not have been the most accurate explanation of what the filter was doing, but the basic ideas should have been more or less correct.

[ghype]

Now if a side=1 unit moves around. This is what will happen.
x1,y1 get automatically filled in with the values of the location where the event is taking place. Say 10,11
The filter starts to check:
is this event at 10,11? yes.
Is this side=1? yes.
Is the exploration=1? yes.

Since all is yes, the unit container gets filled in with the information of whatever soldier is at that event, or at $x1,$y1.

So the id of that unit at 10,11 will be $unit.id, remember we don't know what is the stuff inside, to access it we put a $ infront of the container name.

Now the rest of the moveto events continues to execute [heal_unit] and again it will only apply it to the unit with id $unit.id

You will not be able to tell the difference, but that's what just happened. the heal_unit in that case was applied to only 1 unit from side 1 and not all units from side 1.

Once another unit from side 1 starts to move around, the same thing takes place, and the event only happens for that unit and not the rest of the units.

That was it. Big thumbs up! Not only do I know now what the $ sign in x,y=$x1,$y1 and $unit.id do, but I know now why they are mandatory in order to make it work that way.

Thank you, I really do appreciate your time. Case closed.

[lhybrideur]

The problem here is that you set exploration to 1 in your event. So each test it tests its value, it is equal to one.
You need to have the set_variable directly in prestart and not inside your event in prestart.

[ghype]

The problem here is that you set exploration to 1 in your event. So each test it tests its value, it is equal to one.
You need to have the set_variable directly in prestart and not inside your event in prestart.

Hello, thanks for your comment. I already figured that and it perfectly works.

[ghype]

Hello again. I was looking into [time_area] and trying to make a custom one.
It is pretty simple yet I doesn't do what I want. Basically, it should use the interior time schedule for every terrain that has basic wood floor. This is what I came up with:

Code: Select all

#sets time schedule for interrior
        [time_area]
            id=indoor_area
            [filter_location]
                terrain=I**,I**^**,I**^***,I**^****
            [/filter_location]
            {INDOORS}
        [/time_area]

I use so many wildcards in the terrain codes as I have many custom overlays and wanted to make sure that every basic wood floor tile and what ever is on top of it is included in the custom [time_area].

Initially I had this in the top level of my scenario and it didn't work. Then I read in the wiki that the top level [time_area] does not accept StandartLocationFilter - it is supposed to work only in events. So I moved that from the top level to the prestart event. Now the location filter does not seem to work properly as now every tile (except shrouded ones) show me the interior schedule.

What did I do wrong?

[WhiteWolf]

I see two problems:
1) There is no need for an explicit [filter_location] tag, you should use its keys directly, as shown in the wiki.
2) * already means any number of any character. No need for its multiples (it's not wrong probably, but there's just no point).

Code: Select all

       [time_area]
            id=indoor_area
            terrain=I*,I*^*
            {INDOORS}
        [/time_area]

This should work in a prestart event.

[ghype]

Code: Select all

       [time_area]
            id=indoor_area
            terrain=I*,I*^*
            {INDOORS}
        [/time_area]

This should work in a prestart event.

Got it, thanks!

[ghype]

so here is another one... I know there have been many abilities that give the player gold on death of an enemy.
What I am trying to do is to let the enemy drop coins in form of an item/object which then can be only picked up by player side 1. This is what I came up with:

The first event creates that item on the hex the enemy died. For now that object doesn't yet do anything. Thats why I have a second moveto event that checks if the current has such item as coins. The last part I was not yet able to test (took it from another similar ability).

Reason for that is that I can not get my units pick up the object ... what is wrong with my filter in the object tag?

Code: Select all

#define DROP_GOLD_ON_KILL
    [event]
        name=die
        first_time_only=no

        [filter]
            side=2
            x,y=$x1,$y1          
        [/filter]

        [item]
            image=items/gold-coins-small.png
            x,y=$x1,$y1 

            [object]
                id=gold_coins
                take_only_once=yes
                duration=forever
                [filter]
                    side=1
                    id=$unit.id
                [/filter]
            [/object]
        [/item]
    [/event]

    [event]
        name=moveto
        first_time_only=no

        {VARIABLE_OP coins rand (1,1,1,1,1,1,2,2,2,2,2,3,3,3,3,4,4,4,4,5,5,5,6)}

        [if]
            [found_item]
                id=gold_coins
            [/found_item]

            [then]
                [gold]
                    side=1
                    amount=$coins
                [/gold]
                [sound]
                    name=gold.ogg
                [/sound]
                [unstore_unit]
                    variable=second_unit
                    find_vacant=no
                    text=_ "+" + $coins + " Gold"
                    red,green,blue=255,255,0
                [/unstore_unit]
                {CLEAR_VARIABLE coins}

                [remove_item]
                    x=$unit.x1
                    y=$unit.y1
                [/remove_item]
            [/then]    
        [/if]    
    [/event]

#enddef

[WhiteWolf]

Umm... [found_item] is not looking for [item]'s, it's looking for [object]'s. Misleading name to be fair, but that's what the wiki says.
Also, [object] inside [item] is wrong.

(EDIT:
Other problems: your moveto event doesn't contain a filter so it's used up the first time a unit moves somewhere.
Also, you're giving the object to the dying unit ($unit), you should give it to the killing unit if I understand your code correctly (should be $second_unit).
-- edit end.)

While I'm sure this can be refined to work this way too, but I'd just so take a different approach to this. This is a perfect example to use a nested event:

Code: Select all

[event]
    name=last breath
    first_time_only=no
    [filter]
        side=2
        # note: $x1,$y1 doesn't do anything here
    [/filter]
    
    [item]
        image=items/gold-coins-small.png
        x,y=$x1,$y1
    [/item]

    [event]
        name=moveto
        delayed_variable_substitution=no # has to be explicitly set to no to substitute value of x y at creation time (not trigger time!)
        [filter]
            x,y=$x1,$y1
        [/filter]
        
        {VARIABLE_OP coins rand (1,1,1,1,1,1,2,2,2,2,2,3,3,3,3,4,4,4,4,5,5,5,6)}
        
        [gold]
              side=$|unit.side # the | is important after the $ sign, because this is substituted in trigger time.
              amount=$coins
        [/gold]
        [floating_text] # using floating_text instead of an unstore_unit might be a better idea
            x,y=$x1,$y1
            text=_ "<span color='yellow'>+ $coins Gold</span>" # it does require pango to get a red+green text though.
        [/floating_text]
        [sound]
              name=gold.ogg
        [/sound]
        
        {CLEAR_VARIABLE coins}

        [remove_item]
            x=$x1
            y=$y1
        [/remove_item]
     [/event]
 [/event]

EDIT2: I've edited the code to fill in the coin giving too since I realized it may not be trivial.

[Helmet]

Interesting. I probably would've tried to make the slain unit do all the work, not the killing unit.

I probably would've used name=die for the slain unit and filtered based on how the unit died. If it died by, say, a side=1 unit, or a certain type of unit, or a certain weapon or whatever, it would drop gold as an object where it died, and then an item image would appear on the same spot.

And then the killing unit (or an ally) could walk over and pick up the gold, and then the item would be removed.

It may not have worked, but that's what I would've tried!

[ghype]

Umm... [found_item] is not looking for [item]'s, it's looking for [object]'s. Misleading name to be fair, but that's what the wiki says.

Yeah wiki at times can be misleading. I just have to learn by trial & error.

Other problems: your moveto event doesn't contain a filter so it's used up the first time a unit moves somewhere.

Well that was the idea, to check on every movement wether there is an item or not. That's why it was first_time_only=no.

Also, you're giving the object to the dying unit ($unit), you should give it to the killing unit if I understand your code correctly (should be $second_unit).
-- edit end.)

Ahhh now I get it. so $unit and $second_unit refers depends on the events perspective. I thought $unit is always player side and $second_unit is not player side. But now writing it down it doesn't seem to make a lot of sense this ways. Thanks for clearing that up.

EDIT2: I've edited the code to fill in the coin giving too since I realized it may not be trivial.

I tried your version yesterday and I am glad that the unit now drop the coin item. In the couple of times I tested this (maybe 5-10 times) the first coin that drop give me an error saying that the attribute has no value as if $coins was cleared before even used:

Code: Select all

 [gold] missing required amount=attribute 

Something in your code makes that the variable is cleared before it can be used. That's my guess. What is yours?
Most of the times it really happens only with the first time it should drop coins. But I also encountered once or twice where more then just the first drop didn't worked.

[WhiteWolf]

Well that was the idea, to check on every movement wether there is an item or not. That's why it was first_time_only=no.

Oh, I missed the first_time_only there. Okay, that's probably good then.

Code: Select all

 [gold] missing required amount=attribute 

Right, sorry my bad, $coins should instead be $|coins everywhere.
Currently it's trying to substitute it at creation time because of the delayed variable substitution set to no, but it doesn't exist at creation time, it will only be created at trigger time.
After the first trigger it will exist though, so if it's not picked up and cleared before dropping an another one, that will "work" (will still reference a bad variable). That's why usually only the first instances were giving the error message.

[ghype]

Right, sorry my bad, $coins should instead be $|coins everywhere.
Currently it's trying to substitute it at creation time because of the delayed variable substitution set to no, but it doesn't exist at creation time, it will only be created at trigger time.

Oh I see. Now I understand the "delayed variable substitution". That was something I planned to research but now you explained. So thanks for that.

And it works! I will tinker around with this and see if I can build upon it.