Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

modify_unit doesn't apply the "loyal" effect #4137

Open
jostephd opened this issue Jun 28, 2019 · 6 comments

Comments

Projects
None yet
5 participants
@jostephd
Copy link
Member

commented Jun 28, 2019

[modify_unit][modifications][effect]apply_to=loyal doesn't set set the unit's upkeep to "loyal". Seen in EI S7a where Grug still has upkeep="full" after it joins Gweddry.

@jostephd jostephd added Bug WML labels Jun 28, 2019

@gfgtdf

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2019

[modify_unit][modifications][effect]

This is wrong syntax it's is supposed to be [modify_unit][object][effect] ( or [modify_unit][trait][effect] of course)

@jostephd

This comment has been minimized.

Copy link
Member Author

commented Jun 29, 2019

I checked again and EI S7a does [modify_unit][modifications][trait][effect]apply_to=loyal. I omitted the [trait] in the first post. Sorry about that.

https://wiki.wesnoth.org/DirectActionsWML#.5Bmodify_unit.5D says "Accepts generally the syntax inside of wml unit variables created by [store_unit] which can be viewed in a savefile or by using the inspect command." The :inspect command in S9 shows [modifications][object][effect]apply_to=loyal. That's not exactly what you wrote but I assume it would work too.

zookeeper and I spoke about this yesterday. If I understood correctly he said the WML code in the scenario used to work. @ln-zookeeper, is that right?

@ln-zookeeper

This comment has been minimized.

Copy link
Member

commented Jun 29, 2019

I don't know if that code actually used to work (IIRC it was added in 1.13). But yes, the wiki does specifically mention that [trait] should be added without [modifications], so if that solves the problem then the current WML is in fact mistaken; the documentation doesn't really explicitly say what the current WML should do, after all.

@jostephd jostephd added this to the 1.14.9 milestone Jun 29, 2019

@gfgtdf

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2019

EI S7a does [modify_unit][modifications][trait][effect]apply_to=loyal

I'm not 100% sure what this does, it probably does a config-merge on the [modifications] tag ( meging the apply_to loyal with the first tarit that the uni has) but that's just a guess, also does to the config based implementation of modufy_unit it will probably not effect the units upkeep= field since Thai will be oweritten with the original upkeep= value when in unit in unstored.

In any case I recommend not to use [modify_unit][modifications]

@jostephd jostephd added the Campaign label Jul 1, 2019

@jostephd jostephd referenced this issue Jul 1, 2019

Open

Eastern Invasion #4145

0 of 22 tasks complete
@CelticMinstrel

This comment has been minimized.

Copy link
Member

commented Jul 15, 2019

Yeah, that'll do a config merge on the modifications tag, but that does mean it should actually work, as the loyal trait is now in the modifications and [modify_unit] unstores the unit at the end, which if I recall correctly should trigger a rebuild.

That said, it's probably better to omit the [modifications] tag in this case.

(Actually, I'm not quite sure what the default behaviour is, but is there a chance that the existing code overwrites the first effect tag in the first trait of the unit?)

@sevu sevu added the Docs label Jul 15, 2019

@gfgtdf

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2019

Yeah, that'll do a config merge on the modifications tag, but that does mean it should actually work, as the loyal trait is now in the modifications and [modify_unit] unstores the unit at the end, which if I recall correctly should trigger a rebuild

Well.it first rebuilds and then overwrites everything with the data from the unstored unit, basically undoing the rebuild, except for data that is missing in the stored unit, in this case the 'stored unit' still has exlicitly upkeep=full because that's what the unit had when it was stored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.