v15.18 [modify_unit] working as intended?
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.
- Spannerbag
- Posts: 535
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
v15.18 [modify_unit] working as intended?
Hi,
Stumbled across the following which seems to me to be a change in the way
In v14 I used
As this worked in v14 I didn't look into the details, but side 2 was able to recall units OK.
In v15.18 the units have their side changed but stay in side 1's recall list.
So side 1 recall has units that have side=2 and side 2 leader has no recalls.
(
Here's a screen snippet from side 1 recall list when using
However if instead
Here's a few screen snippets when using
Side 1: Side 2: ...and the units that were previously side 1recalls
Using {MODIFY_UNIT... works because (I guess) it deletes and reinstates the units.
There's no problem, I was just wondering if this behaviour is as intended?
Cheers,
--Spannerbag
Stumbled across the following which seems to me to be a change in the way
[modify_unit]
works compared to v14.In v14 I used
[modify_unit]
to flip units from side 1 to (an empty) side 2.
Code: Select all
[modify_unit]
[filter]
x,y=recall,recall
[and]
race=drake,dwarf
[or]
id=Caravan
[/or]
[/and]
[/filter]
side=2
[/modify_unit]
In v15.18 the units have their side changed but stay in side 1's recall list.
So side 1 recall has units that have side=2 and side 2 leader has no recalls.
(
{RECALL_XY...
works OK so the leader can be placed on the map.)Here's a screen snippet from side 1 recall list when using
[modify_unit]
:
However if instead
{MODIFY_UNIT...
is used, everything works OK.
Code: Select all
{MODIFY_UNIT (x,y=recall,recall
[and]
race=drake,dwarf
[or]
id=Caravan
[/or]
[/and]) side 2}
{RECALL_XY...
;Side 1: Side 2: ...and the units that were previously side 1recalls
Using {MODIFY_UNIT... works because (I guess) it deletes and reinstates the units.
There's no problem, I was just wondering if this behaviour is as intended?
Cheers,
--Spannerbag
Re: v15.18 [modify_unit] working as intended?
Recall lists act differently to sides on the map, but I'm not sure if that's documented anywhere.
OTOH, this is definitely something that needs to be in the "how to port to 1.16" list.
OTOH, this is definitely something that needs to be in the "how to port to 1.16" list.
- Pentarctagon
- Project Manager
- Posts: 5565
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: v15.18 [modify_unit] working as intended?
I've gone ahead and posted a previously created draft of the 1.14 -> 1.16 compatibility changes here, so feel free to post/add anything that's not mentioned there.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
- Spannerbag
- Posts: 535
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: v15.18 [modify_unit] working as intended?
Sorry to be dim, but not sure what you mean?
I presume you mean
[modify_unit]
is working as expected but that recall lists are "decoupled" from the side they belong to?To me, it seems like the internal workings have changed because in v14 the code allowed me to recall side 2 units whereas in v15 it didn't.
I'm more than happy to forward my post to the compatibility changes - if it would help/is appropriate, just let me know (or forward it yourself if you like ).
Brilliant, thanks for the link.Pentarctagon wrote: ↑October 13th, 2021, 8:45 pm I've gone ahead and posted a previously created draft of the 1.14 -> 1.16 compatibility changes here, so feel free to post/add anything that's not mentioned there.
Got most things right but didn't know about [advancefrom], I'll need to amend a few unittypes, but no problem
I'm finding various (what seem to me anyway) slightly odd behaviours in v15 but until I have my code fully clean I'll leave it and see what goes away.
Out of interest, are odd numbers development versions and even numbers stable?
Just struck me that I've played on 1.12 and 1.14 but not 1.13...
If so, will v16 be basically be a final version of v15?
(I only ask because if not I'll have to make sure I migrate to v16 if there are any WML changes/incompatibilities).
Thanks both for your time and trouble.
Cheers,
--Spannerbag
Re: v15.18 [modify_unit] working as intended?
[put_to_recall_list] doesnt allow you specify to which side recall list unit should go to. Therefore I would say [modify_unit] should follow same rule, and therefore report it as bug instead of compatibility change.
Re: v15.18 [modify_unit] working as intended?
The "how to port to 1.16" list has been posted in https://r.wesnoth.org/t54979, so I've linked this from there.
The even release numbers are the stable branch, and v1.16.0 is going to be the basically v1.15.19 (unless we find an absolutely has-to-be-fixed bug in v1.15.18).
The recall lists are coupled more tightly to the side that they belong to than the units on the map. Side 1 has a list, side 2 has a list, and changing a unit that's on side 1's list doesn't make the game check which list it should be on.
The even release numbers are the stable branch, and v1.16.0 is going to be the basically v1.15.19 (unless we find an absolutely has-to-be-fixed bug in v1.15.18).
Spannerbag wrote: ↑October 14th, 2021, 12:13 am I presume you mean[modify_unit]
is working as expected but that recall lists are "decoupled" from the side they belong to?
To me, it seems like the internal workings have changed because in v14 the code allowed me to recall side 2 units whereas in v15 it didn't.
The recall lists are coupled more tightly to the side that they belong to than the units on the map. Side 1 has a list, side 2 has a list, and changing a unit that's on side 1's list doesn't make the game check which list it should be on.
That's exactly it, in 1.14,Spannerbag wrote: ↑October 13th, 2021, 4:32 pm Using {MODIFY_UNIT... works because (I guess) it deletes and reinstates the units.
[modify_unit]
deleted and reinstated the unit as the macro does. In 1.16 a fast-path was added with a list of "simple" attributes that don't get the full store-and-unstore sequence; but until now we thought the only side-effect that could cause problems was a UI bug (#4978).- Spannerbag
- Posts: 535
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: v15.18 [modify_unit] working as intended?
Thanks for all that. Much appreciated.octalot wrote: ↑October 14th, 2021, 1:28 pmThat's exactly it, in 1.14,Spannerbag wrote: ↑October 13th, 2021, 4:32 pm Using {MODIFY_UNIT... works because (I guess) it deletes and reinstates the units.[modify_unit]
deleted and reinstated the unit as the macro does. In 1.16 a fast-path was added with a list of "simple" attributes that don't get the full store-and-unstore sequence; but until now we thought the only side-effect that could cause problems was a UI bug (#4978).
Hmmm... if I understand correctly then off the top of my head, I can see one pitfall for the unwary:
If you have to use
MODIFY_UNIT
(rather than [modify_unit]
) to change the facing of unit,then if that unit is a leader and the loss of said leader=defeat then I suppose you'd need to bracket
MODIFY_UNIT
with [modify_side]..defeat_condition=never
?Of course, me being me, that's exactly what I was doing in scenario 5 of my campaign. When I looked at how others had done this I researched
MODIFY_UNIT
and realised it would probably cause the scenario to end abruptly. I didn't consider [modify_side]..defeat_condition=never
but instead amended starting positions and avoided changing facing. The result isn't quite as good but I can live with it.IMHO I feel it's a bit consufing to have a tag and macro of the same name that do similar - but not exactly the same - things.
But that said I can live with it
Thanks for taking the trouble to explain, your patience is appreciated.
Cheers!
--Spannerbag