v15.18 [modify_unit] working as intended?

The place to post your WML questions and answers.

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.
Post Reply
User avatar
Spannerbag
Posts: 149
Joined: December 18th, 2016, 6:14 pm
Location: Yes

v15.18 [modify_unit] working as intended?

Post by Spannerbag »

Hi,
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]
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.
({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]:
recall12.PNG


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}
Here's a few screen snippets when using {RECALL_XY...;
Side 1:
MU1.PNG
Side 2:
MU2a.PNG
...and the units that were previously side 1recalls
MU2b.PNG

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
UMC Campaign: After EI
I suspect the universe is simpler than we think and stranger than we can know.
User avatar
octalot
Developer
Posts: 605
Joined: July 17th, 2010, 7:40 pm
Location: Austria

Re: v15.18 [modify_unit] working as intended?

Post by octalot »

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.
User avatar
Pentarctagon
Project Manager
Posts: 4852
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: v15.18 [modify_unit] working as intended?

Post by Pentarctagon »

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
User avatar
Spannerbag
Posts: 149
Joined: December 18th, 2016, 6:14 pm
Location: Yes

Re: v15.18 [modify_unit] working as intended?

Post by Spannerbag »

octalot wrote: October 13th, 2021, 7:21 pm 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.
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 :) ).

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.
Brilliant, thanks for the link.
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
UMC Campaign: After EI
I suspect the universe is simpler than we think and stranger than we can know.
User avatar
Ravana
Forum Moderator
Posts: 2537
Joined: January 29th, 2012, 12:49 am
Location: Estonia
Contact:

Re: v15.18 [modify_unit] working as intended?

Post by Ravana »

[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.
User avatar
octalot
Developer
Posts: 605
Joined: July 17th, 2010, 7:40 pm
Location: Austria

Re: v15.18 [modify_unit] working as intended?

Post by octalot »

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).
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.
Spannerbag wrote: October 13th, 2021, 4:32 pm Using {MODIFY_UNIT... works because (I guess) it deletes and reinstates the units.
That's exactly it, in 1.14, [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).
User avatar
Spannerbag
Posts: 149
Joined: December 18th, 2016, 6:14 pm
Location: Yes

Re: v15.18 [modify_unit] working as intended?

Post by Spannerbag »

octalot wrote: October 14th, 2021, 1:28 pm
Spannerbag wrote: October 13th, 2021, 4:32 pm Using {MODIFY_UNIT... works because (I guess) it deletes and reinstates the units.
That's exactly it, in 1.14, [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).
Thanks for all that. Much appreciated.
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
UMC Campaign: After EI
I suspect the universe is simpler than we think and stranger than we can know.
Post Reply