[modify_unit] disappearances/bug
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.
[modify_unit] disappearances/bug
This is what I suspect to be an error in the Battle for Wesnoth 1.12.0.
I have the following code set inside an event every side turn in a scenario. The purpose it to add traits to a side when its leader begins a turn on a variable hex.
When the the extra traits are given to the side (during the [modify_unit] tag), all other leaders in the game disappear at the time of the [modify_unit].
Advice, insights, and correction would be helpful and welcome.
I have the following code set inside an event every side turn in a scenario. The purpose it to add traits to a side when its leader begins a turn on a variable hex.
When the the extra traits are given to the side (during the [modify_unit] tag), all other leaders in the game disappear at the time of the [modify_unit].
Code: Select all
#define UPGRADEIFON SIDE
first_time_only=no
[if]
[have_unit]
canrecruit=yes
x,y=$currdest[{SIDE}].x,$currdest[{SIDE}].y
side={SIDE}
[/have_unit]
[then]
[message]
message="premodify"
[/message]
[modify_unit]
[filter]
side={SIDE}
[/filter]
{TRAIT_RESILIENT}
{TRAIT_INTELLIGENT}
{TRAIT_DEXTROUS}
{TRAIT_STRONG}
{TRAIT_QUICK}
[/modify_unit]
[message]
message="postmodify"
[/message]
[/then]
[/if]
#enddef
Re: [modify_unit] disappearances/bug
I don't see what exactly is causing it, I suspect it's something outside the snippet you posted. It would be pretty strange if [modify_unit] tag killed all leaders. Three suggestions:
1. Try adding just one trait, see if that still causes problems
2. Check the indices on the $currdest[{SIDE}].x stuff. Should SIDE=1 reference the second element in that "currdest" array?
3. Post the entire thing, including all the event and everywhere currdest array is defined and called upon. That way we don't have to guess as much.
1. Try adding just one trait, see if that still causes problems
2. Check the indices on the $currdest[{SIDE}].x stuff. Should SIDE=1 reference the second element in that "currdest" array?
3. Post the entire thing, including all the event and everywhere currdest array is defined and called upon. That way we don't have to guess as much.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: [modify_unit] disappearances/bug
I would suggest use :debug command and then :inspect command. take a look to units and check they were really killed after [modify_unit] (it could be just a image display bug). If they are beign really killed by [modify_unit] then I would suggest check if it also kills undead leaders with no traits, just to discard some weird behavior with them.
Be aware English is not my first language and I could have explained bad myself using wrong or just invented words.
World Conquest II
World Conquest II
- Elvish_Hunter
- Posts: 1575
- Joined: September 4th, 2009, 2:39 pm
- Location: Lintanir Forest...
Re: [modify_unit] disappearances/bug
Yes, it should, because in WML (and almost any other programming language except Lua) arrays start with index 0.doofus-01 wrote:2. Check the indices on the $currdest[{SIDE}].x stuff. Should SIDE=1 reference the second element in that "currdest" array?
By the way...
Traits don't work like that. You'll have to wrap them inside a [modifications] tag (see this wiki page).Ghite wrote:Code: Select all
{TRAIT_RESILIENT} {TRAIT_INTELLIGENT} {TRAIT_DEXTROUS} {TRAIT_STRONG} {TRAIT_QUICK}
Current maintainer of these add-ons, all on 1.16:
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
Re: [modify_unit] disappearances/bug
Reason I asked is because SIDE=0 is strange, I don't think there is a side zero. How do you know what he intended?Elvish_Hunter wrote:Yes, it should, because in WML (and almost any other programming language except Lua) arrays start with index 0.doofus-01 wrote:2. Check the indices on the $currdest[{SIDE}].x stuff. Should SIDE=1 reference the second element in that "currdest" array?
No, you don't need the [modifications] tag, unless something changed in the last few 1.11/1.12 releases, in which case the wiki needs to be updated ( http://wiki.wesnoth.org/DirectActionsWM ... fy_unit.5D )Elvish_Hunter wrote: By the way...Traits don't work like that. You'll have to wrap them inside a [modifications] tag (see this wiki page).Ghite wrote:Code: Select all
{TRAIT_RESILIENT} {TRAIT_INTELLIGENT} {TRAIT_DEXTROUS} {TRAIT_STRONG} {TRAIT_QUICK}
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
- Elvish_Hunter
- Posts: 1575
- Joined: September 4th, 2009, 2:39 pm
- Location: Lintanir Forest...
Re: [modify_unit] disappearances/bug
OK, perhaps my answer was unclear. I was attempting to explain this behaviour, so: SIDE=1 should reference the second element in "currdest", because in WML (and almost any other programming language except Lua) arrays start with index 0. This means that, in order to access the array element corresponding to side's number, one should subtract 1 from that value, and this can be done either by using an intermediate variable (easier for beginners), or by using the FormulaAI syntax.doofus-01 wrote:Reason I asked is because SIDE=0 is strange, I don't think there is a side zero. How do you know what he intended?
Huh, so that's what "Can add traits with immediate effect" means . It's quite unclear, and also incomplete: I just checked the Lua source code for that tag, and found out that the same could be said for [object]s:doofus-01 wrote:No, you don't need the [modifications] tag, unless something changed in the last few 1.11/1.12 releases, in which case the wiki needs to be updated ( http://wiki.wesnoth.org/DirectActionsWM ... fy_unit.5D )
Code: Select all
elseif current_tag == "object" or current_tag == "trait" then
...
wesnoth.add_modification(unit, current_tag, current_table[2])
EDIT: done. I replaced that phrase with It can add [trait]s and [object]s without needing to wrap them inside a [modifications] tag.
Current maintainer of these add-ons, all on 1.16:
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: [modify_unit] disappearances/bug
No.Elvish_Hunter wrote:Huh, so that's what "Can add traits with immediate effect" means
Back when [modify_unit] didn't exist yet, things, traits especially, often came into effect only once the unit leveled into itself for instance, and people were frequently asking about this in the wml workshop. The wesnoth.add_modification lua function used by modify_unit doesn't suffer from that. Please don't delete this.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: [modify_unit] disappearances/bug
2. Check the indices on the $currdest[{SIDE}].x stuff. Should SIDE=1 reference the second element in that "currdest" array?
Yes, it should, because in WML (and almost any other programming language except Lua) arrays start with index 0.
Ehem... {SIDE} is a macro argument, and there is no reason why it could be zero unless coder call macro with such a value, no matter he uses that argument in an array. From my point of view, it is not helpfull for bug reports, burden reporter with out of point questions that require "extra work" to answer, when the fact is that any of us (me included) took a minute to test [modify_unit] with lot of traits in an scenario, just to be sure bug is not pretty easy to reproduce.Reason I asked is because SIDE=0 is strange, I don't think there is a side zero. How do you know what he intended?
He introduced in his code [message] tags that works as debuging tags, so he deserves some respect in his efforts to report the issue (he could be wrong, but he took quite effort trying to avoid it).
edit: Even if he calls macro with zero as argument for {SIDE}, it should be harmless in a [have_unit] tag, and I would see as a bug that...
Code: Select all
[modify_unit]
[filter]
side=0
[/filter]
[/mofify_unit]
Be aware English is not my first language and I could have explained bad myself using wrong or just invented words.
World Conquest II
World Conquest II
Re: [modify_unit] disappearances/bug
Ehem, yourself, chief. He said side={SIDE}, so there will be a side=0 if he tries to access the currdest[0]. And spare us the lectures please.tekelili wrote:2. Check the indices on the $currdest[{SIDE}].x stuff. Should SIDE=1 reference the second element in that "currdest" array?Yes, it should, because in WML (and almost any other programming language except Lua) arrays start with index 0.Ehem... {SIDE} is a macro argument, and there is no reason why it could be zero unless coder call macro with such a value, no matter he uses that argument in an array. From my point of view, it is not helpfull for bug reports, burden reporter with out of point questions that require "extra work" to answer, when the fact is that any of us (me included) took a minute to test [modify_unit] with lot of traits in an scenario, just to be sure bug is not pretty easy to reproduce.Reason I asked is because SIDE=0 is strange, I don't think there is a side zero. How do you know what he intended?
He introduced in his code [message] tags that works as debuging tags, so he deserves some respect in his efforts to report the issue (he could be wrong, but he took quite effort trying to avoid it).
Elvish_Hunter is right that the [modify_unit] tag and documentation was confusing though. By the way, when would someone want to use [object] inside [modify_unit]?Anonymissimus wrote:No.Elvish_Hunter wrote:Huh, so that's what "Can add traits with immediate effect" means
Back when [modify_unit] didn't exist yet, things, traits especially, often came into effect only once the unit leveled into itself for instance, and people were frequently asking about this in the wml workshop. The wesnoth.add_modification lua function used by modify_unit doesn't suffer from that. Please don't delete this.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: [modify_unit] disappearances/bug
I still dont see why side=0 could cause behavior he described.doofus-01 wrote:Ehem, yourself, chief. He said side={SIDE}, so there will be a side=0 if he tries to access the currdest[0].
Sure.doofus-01 wrote: And spare us the lectures please.
Be aware English is not my first language and I could have explained bad myself using wrong or just invented words.
World Conquest II
World Conquest II
Re: [modify_unit] disappearances/bug
Ghite: I tested these events in a 2p mainline map and couldnt reproduce bug you described. What else in your scenario do you think could be causing it?
Code: Select all
[event]
name=turn 1
[modify_unit]
[filter]
side=0
[/filter]
{TRAIT_RESILIENT}
{TRAIT_INTELLIGENT}
{TRAIT_DEXTROUS}
{TRAIT_STRONG}
{TRAIT_QUICK}
[/modify_unit]
[/event]
Code: Select all
[event]
name=turn 1
[modify_unit]
[filter]
side=1
[/filter]
{TRAIT_RESILIENT}
{TRAIT_INTELLIGENT}
{TRAIT_DEXTROUS}
{TRAIT_STRONG}
{TRAIT_QUICK}
[/modify_unit]
[/event]
Be aware English is not my first language and I could have explained bad myself using wrong or just invented words.
World Conquest II
World Conquest II
- Elvish_Hunter
- Posts: 1575
- Joined: September 4th, 2009, 2:39 pm
- Location: Lintanir Forest...
Re: [modify_unit] disappearances/bug
Fine, I'll correct it again. No big deal.Anonymissimus wrote:Please don't delete this.
EDIT: Fixed in this way: "It can add [trait]s and [object]s without needing to wrap them inside a [modifications] tag, and their effects are applied immediately".
Beats me But it's possible, so it should (and it is, now) be documented nevertheless.doofus-01 wrote:By the way, when would someone want to use [object] inside [modify_unit]?
SIDE=0 shouldn't cause anything, because in that case the filter won't match any unit. But the point is, the lowest possible value for sides is 1. So that makes the currdest array our prime suspect: what's its content? How is it created? How is it modified?tekelili wrote:I still dont see why side=0 could cause behavior he described.
But it's also possible that another event happens in the same moment and causes this problem: Ghite, can you post the whole scenario?
Current maintainer of these add-ons, all on 1.16:
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
Re: [modify_unit] disappearances/bug
currdest array is only used inside a [have_unit] tag, so I dont see how any wrong value could cause anything but be fired/not fired at wrong moment the [modify_unit] tag. And if it were fired at wrong moments it would have probably been easyly detected by coder. I would really look for a better suspect.Elvish_Hunter wrote:SIDE=0 shouldn't cause anything, because in that case the filter won't match any unit. But the point is, the lowest possible value for sides is 1. So that makes the currdest array our prime suspect: what's its content? How is it created? How is it modified?tekelili wrote:I still dont see why side=0 could cause behavior he described.
But it's also possible that another event happens in the same moment and causes this problem: Ghite, can you post the whole scenario?
Be aware English is not my first language and I could have explained bad myself using wrong or just invented words.
World Conquest II
World Conquest II
Re: [modify_unit] disappearances/bug
I think I don't agree with this, as a general statement. It should only be documented if we intend to support it indefinitely. Not every undocumented aspect of the program's behavior is going to be the same in future versions.Elvish_Hunter wrote:Beats me But it's possible, so it should (and it is, now) be documented nevertheless.
If someone chose not document something, it might be that they just forgot to do this, but it might also be that they weren't happy with the feature, or had future plans that were abandoned, or forgot to remove it or something... just something to keep in mind.