v15.18 [modify_unit] behaviour/possible bug
Moderator: Forum Moderators
Forum rules
Before reporting issues in this section, you must read the following topic:
Before reporting issues in this section, you must read the following topic:
- Spannerbag
- Posts: 505
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
v15.18 [modify_unit] behaviour/possible bug
Hello,
[modify_unit] seems to work differently compared to v14.
My original post is here https://forums.wesnoth.org/viewtopic.php?f=21&t=54977.
Essentially when units on recall flip sides
However
Here's the Wesnoth build info:
To replicate the difference here's a code block, it should work with any scenario that has 2+ sides and is set to use turns 1 and 2 to setup and allow examination of this issue/behaviour.
Attached are a couple of saves with recalls using
and
The logfile doesn't mention anything obviously relevant but does issue other errors, mostly to do with custom terrain (which work fine in game and editor) and occasional system errors such as these:But these do not correspond with running a particular scenario or campaign; they seem to appear at random.
(Fwiw, quick check: the scenario code doesn't contain the word
No idea if these are related or not to this issue...
Edit:
Here's another one (seen before):
Feel free to get back to me if you need more details - PM best if you want a quick reply!
Cheers,
--Spannerbag
[modify_unit] seems to work differently compared to v14.
My original post is here https://forums.wesnoth.org/viewtopic.php?f=21&t=54977.
Essentially when units on recall flip sides
MODIFY_UNIT
works as I'd expect: the units are moved to the new side recall list.However
[modify_unit]
leaves the units as recalls in the old side (i.e. the old side can recall units of another - possibly enemy - side).Here's the Wesnoth build info:
Code: Select all
The Battle for Wesnoth version 1.15.18 x86_64
Running on Microsoft Windows 7 Service Pack 1 (6.1.7601) x86_64
Distribution channel: SourceForge
Game paths
==========
Data dir: C:\Program Files\Battle for Wesnoth 1.15.18
User config dir: C:\Users\USER\Documents\My Games\Wesnoth1.15
User data dir: C:\Users\USER\Documents\My Games\Wesnoth1.15
Saves dir: C:\Users\USER\Documents\My Games\Wesnoth1.15\saves
Add-ons dir: C:\Users\USER\Documents\My Games\Wesnoth1.15\data\add-ons
Cache dir: C:\Users\USER\Documents\My Games\Wesnoth1.15\cache
Libraries
=========
Boost: 1.74
Lua: 5.4.2
OpenSSL/libcrypto: 1.1.1i (runtime 1.1.1i)
Cairo: 1.17.4 (runtime 1.17.4)
Pango: 1.48.0 (runtime 1.48.0)
SDL: 2.0.12 (runtime 2.0.12)
SDL_image: 2.0.5 (runtime 2.0.5)
SDL_mixer: 2.0.4 (runtime 2.0.4)
Features
========
Lua console completion: yes
Win32 notifications back end: yes
Current video settings
======================
SDL video drivers: [windows] dummy
Window size: 1366x768
Screen refresh rate: 60
Screen dots per inch: 96.000000x96.000000
Screen dpi scale factor: 1.000000x1.000000
Current audio settings
======================
SDL audio drivers: [wasapi] directsound
Number of channels: 2
Output rate: 44100 Hz
Sample format: signed 16 bit little-endian
Sample size: 4096 bytes
Installed add-ons
=================
AfterEIMusic1: 1.0.0
AfterEIMusic2: 1.0.0
LSB: Unknown
Tale_of_a_Mage: 1.1.0
stub15: Unknown
To replicate the difference here's a code block, it should work with any scenario that has 2+ sides and is set to use turns 1 and 2 to setup and allow examination of this issue/behaviour.
Code: Select all
# ------------------------------------------------------------
# --- Test code block to demo [modify_unit] vs MODIFY_UNIT ---
#
# Requires any scenario with 2+ sides.
# Uses turns 1 and 2 (but trivial to change if needed)
#
# --- Cut/paste from line below to just before end comments further below
# Not translator friendly...
#define MSGSTB MESSAGE
[message]
speaker=narrator
image=wesnoth-icon.png
message= _"{MESSAGE}"
[/message]
#enddef
#define RUNIT TYPE
#arg SIDE
1#endarg
[unit]
side={SIDE}
type={TYPE}
x,y=recall,recall
generate_name=yes
random_traits=yes
random_gender=yes
upkeep=full
[/unit]
#enddef
#define HAVER
#arg COUNT
4#endarg
[have_unit]
side=1
x,y=recall,recall
count={COUNT}
search_recall_list=yes
[/have_unit]
#enddef
# Turn 1
[event]
name=turn 1
{MSGSTB (About to populate side 1 recall list with Goblin Spearman, Goblin Impaler, Bowman and Spearman)}
{RUNIT (Goblin Spearman)}
{RUNIT (Goblin Impaler)}
{RUNIT (Bowman)}
{RUNIT (Spearman)}
[if]
{HAVER}
[then]
{MSGSTB (Done OK: side 1 has 4 units in recall list. About to use modify_unit to flip the goblins to side 2)}
[modify_unit]
[filter]
side=1
x,y=recall,recall
race=goblin
[/filter]
side=2
[/modify_unit]
[/then]
[else]
[if]
{HAVER}
[then]
{MSGSTB (Side 1 still has 4 units in recall list.)}
[/then]
[else]
{MSGSTB (Side 1 does not have 4 units in recall list.)}
[/else]
[/if]
[/else]
[/if]
{MSGSTB (Play this turn to check recalls etc. - testing will resume next turn)}
[/event]
# Turn 2
[event]
name=turn 2
{MSGSTB (Welcome back. Clearing all recall lists.
Re-populating side 1 recall list with Goblin Spearman, Goblin Impaler, Bowman and Spearman)}
[kill]
side=1,2
x,y=recall,recall
[/kill]
{RUNIT (Goblin Spearman)}
{RUNIT (Goblin Impaler)}
{RUNIT (Bowman)}
{RUNIT (Spearman)}
[if]
{HAVER}
[then]
{MSGSTB (Done OK: side 1 has 4 units in recall list. About to use MODIFY_UNIT macro to flip the goblins to side 2)}
{MODIFY_UNIT (x,y=recall,recall
race=goblin) side 2}
[/then]
[else]
[if]
{HAVER}
[then]
{MSGSTB (Side 1 still has 4 units in recall list.)}
[/then]
[else]
{MSGSTB (Side 1 does not have 4 units in recall list.)}
[/else]
[/if]
[/else]
[/if]
{MSGSTB (Play this turn to check recalls etc. Done.)}
[/event]
#undef MSGSTB
#undef IFHAVER
# --- End cut/paste line above ---
# --- End test code block to demo [modify_unit] vs MODIFY_UNIT ---
# ----------------------------------------------------------------
[modify_unit]
(turn 1, with recalled enemy unit)
and
MODIFY_UNIT
(turn 2).
The logfile doesn't mention anything obviously relevant but does issue other errors, mostly to do with custom terrain (which work fine in game and editor) and occasional system errors such as these:
Code: Select all
20211014 13:49:02 error display: Tile at 11,6 isn't on the map, can't scroll to the tile.
20211014 13:49:11 error display: Tile at 11,6 isn't on the map, can't scroll to the tile.
(Fwiw, quick check: the scenario code doesn't contain the word
scroll
)No idea if these are related or not to this issue...
Edit:
Here's another one (seen before):
Code: Select all
20211014 14:04:42 error gui/layout: grid [] place: Failed to place a grid, we have 296,64 space but we need 348,64 space. This happened at a grid with the id '' in a 'N4gui214tree_view_nodeE' with the id '' in a 'N4gui29tree_viewE' with the id 'stuff_list' in a 'N4gui24gridE' with the id '' in a 'N4gui29generatorINS_6policy17minimum_selection7no_itemENS1_17maximum_selection10many_itemsENS1_9placement11independentENS1_13select_action4showEEE' with the id '_content_grid' in a 'N4gui24gridE' with the id '' in a 'N4gui214stacked_widgetE' with the id '' in a 'N4gui24gridE' with the id '' in a 'N4gui24gridE' with the id '_window_content_grid' in a 'N4gui24gridE' with the id '_content_grid' in a 'N4gui215scrollbar_panelE' with the id '' in a 'N4gui24gridE' with the id '' in a 'N4gui26windowE' with the id 'gamestate_inspector'.
Cheers,
--Spannerbag
Re: v15.18 [modify_unit] behaviour/possible bug
Thanks for the detailed bug report. This isn't a response yet, just a quick explanation and linking some Github issues. In the 1.16 branch, a fast-path was added to
[modify_unit]
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).That's #5976, a cosmetic bug in code that's meant to save the screen location when saving the game.error display: Tile at 11,6 isn't on the map, can't scroll to the tile.
- Spannerbag
- Posts: 505
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: v15.18 [modify_unit] behaviour/possible bug
You're welcome, thanks for replying so promptly
Whilst I have your attention, I've another bit of weirdness if I may?
I've already posted the question at viewtopic.php?f=21&t=54946 - so apologies if you've already seen this.
Code: Select all
20211002 00:04:35 error config: Error while loading the map: Unknown tile in map: (Wwf^Soys) 'Wwf^Soys'
20211002 00:04:37 error config: Error while loading the map: Unknown tile in map: (Wwf^Soys) 'Wwf^Soys'
20211002 00:05:44 error gui/layout: grid [] place: Failed to place a grid, we have 296,64 space but we need 370,64 space. This happened at a grid with the id '' in a 'N4gui214tree_view_nodeE' with the id '' in a 'N4gui29tree_viewE' with the id 'stuff_list' in a 'N4gui24gridE' with the id '' in a 'N4gui29generatorINS_6policy17minimum_selection7no_itemENS1_17maximum_selection10many_itemsENS1_9placement11independentENS1_13select_action4showEEE' with the id '_content_grid' in a 'N4gui24gridE' with the id '' in a 'N4gui214stacked_widgetE' with the id '' in a 'N4gui24gridE' with the id '' in a 'N4gui24gridE' with the id '_window_content_grid' in a 'N4gui24gridE' with the id '_content_grid' in a 'N4gui215scrollbar_panelE' with the id '' in a 'N4gui24gridE' with the id '' in a 'N4gui26windowE' with the id 'gamestate_inspector'.
Is this a harmless warning or is some fix in the pipeline? Just curious.
Also, (and I've not fully bottomed this out yet) the top two messages used to appear at random intervals even though the terrains in question all (seemed) to work absolutely fine in both editor and game.
It may have been a binary path conflict because fixing that also seems to have got rid of the
Unknown tile
messages... or maybe they're just biding their time I also had problems using
[terrain_mask]
- I'd used it fine in my previous campaign but here I ended up changing the whole map (every turn in some scenarios!). That too may be OK now that the binary path conflict is resolved but I'm not keen on retro-fixing the campaign as it works as is and many map changes are quite extensive - but maybe if/when I need to implement similar changes later I might experiment (I've spent ages porting my UMC from v14 to v15 already and want to finish it this century).(If my clapped out Win7 PC can cope with repeated map changes, I'm sure other players will be fine too.)
Please don't spend any time on this; if you happen to know any answers that's great, if not, no worries
Cheers!
--Spannerbag
Re: v15.18 [modify_unit] behaviour/possible bug
I think the "Unknown tile" errors are generated by the map preview in the "Load Game" dialog.
The "failed to place a grid ... gamestate_inspector" is probably harmless, at least if the GUI that
The "failed to place a grid ... gamestate_inspector" is probably harmless, at least if the GUI that
:inspect
triggers works for you.- Spannerbag
- Posts: 505
- Joined: December 18th, 2016, 6:14 pm
- Location: Yes
Re: v15.18 [modify_unit] behaviour/possible bug
Thanks for that.
:inspect
always works - or did, until by saying that I jinxed it! I'll also ignore the "Unknown tile" errors as your comment fits with the behaviour I see in logfiles (the errors don't appear until the relevant terrain is actually referenced/displayed) and I have no idea how to fix this (if it even needs fixing) in WML/lua. Not tried running any other UMC campaigns with custom terrain (yet) so have no basis for comparison.
Anyway, thanks again for your time and trouble, it's appreciated!
Cheers!
--Spannerbag