ghype's Problems:
Moderator: Forum Moderators
Forum rules
- Please use [code] BBCode tags in your posts for embedding WML snippets.
- To keep your code readable so that others can easily help you, make sure to indent it following our conventions.
Re: ghype's Problems: endless mp
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
Note: Shiki's x,y had a problem, maybe that is why it didn't work for you.
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]
Re: ghype's Problems: endless mp
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.stuff I worked on: Dunefolk Rework - ghype's Daily Art
Re: ghype's Problems: endless mp
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.
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.
Re: ghype's Problems: endless mp
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.vghetto wrote: ↑November 28th, 2020, 4:32 pm 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.
Thank you, I really do appreciate your time. Case closed.
stuff I worked on: Dunefolk Rework - ghype's Daily Art
- lhybrideur
- Posts: 369
- Joined: July 9th, 2019, 1:46 pm
Re: ghype's Problems
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.
You need to have the set_variable directly in prestart and not inside your event in prestart.
Re: ghype's Problems
Hello, thanks for your comment. I already figured that and it perfectly works.lhybrideur wrote: ↑November 30th, 2020, 2:53 pm 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.
stuff I worked on: Dunefolk Rework - ghype's Daily Art
Re: ghype's Problems: [time_area]
Hello again. I was looking into
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:
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
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?
[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]
[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?
stuff I worked on: Dunefolk Rework - ghype's Daily Art
Re: ghype's Problems: [time_area]
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)
This should work in a prestart event.
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]
Main UMC campaigns: The Ravagers - now for 1.16, with new bugs!
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Re: ghype's Problems: [time_area]
Got it, thanks!WhiteWolf wrote: ↑December 1st, 2020, 3:40 pmThis should work in a prestart event.Code: Select all
[time_area] id=indoor_area terrain=I*,I*^* {INDOORS} [/time_area]
stuff I worked on: Dunefolk Rework - ghype's Daily Art
Re: ghype's Problems: {DROP_GOLD_ON_KILL}
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?
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
stuff I worked on: Dunefolk Rework - ghype's Daily Art
Re: ghype's Problems: {DROP_GOLD_ON_KILL}
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:
EDIT2: I've edited the code to fill in the coin giving too since I realized it may not be trivial.
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]
Main UMC campaigns: The Ravagers - now for 1.16, with new bugs!
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Re: ghype's Problems: {DROP_GOLD_ON_KILL}
Interesting. I probably would've tried to make the slain unit do all the work, not the killing unit.
I probably would've used
And then the killing unit (or an ally) could walk over and pick up the gold, and then the item would be
It may not have worked, but that's what I would've tried!
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
remove
d.It may not have worked, but that's what I would've tried!
Author of:
DIY Campaign, Confederacy of Swamp Creatures: Big Battle 1, Confederacy of Swamp Creatures: Big Battle 2, Frogfolk Delivery Service, The Pool of Ek.
DIY Campaign, Confederacy of Swamp Creatures: Big Battle 1, Confederacy of Swamp Creatures: Big Battle 2, Frogfolk Delivery Service, The Pool of Ek.
Re: ghype's Problems: {DROP_GOLD_ON_KILL}
Yeah wiki at times can be misleading. I just have to learn by trial & error.
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
.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.
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
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.
stuff I worked on: Dunefolk Rework - ghype's Daily Art
Re: ghype's Problems: {DROP_GOLD_ON_KILL}
Oh, I missed the first_time_only there. Okay, that's probably good then.
Right, sorry my bad,Code: Select all
[gold] missing required amount=attribute
$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.
Main UMC campaigns: The Ravagers - now for 1.16, with new bugs!
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Re: ghype's Problems: {DROP_GOLD_ON_KILL}
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.WhiteWolf wrote: ↑December 2nd, 2020, 12:48 pm 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.
And it works! I will tinker around with this and see if I can build upon it.
stuff I worked on: Dunefolk Rework - ghype's Daily Art