bugBattle for Wesnoth - Bugs: bug #21512, Units hidden with [hide_unit] can...

Show feedback again

bug #21512: Units hidden with [hide_unit] can be selected

Submitted by:  Ignacio R. Morelle <shadowmaster>
Submitted on:  Sun Jan 19 00:53:46 2014  
Category: BugSeverity: 2 - Minor
Priority: 5 - NormalItem Group: User Interface
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Release: 1.10.x - 1.11.8+devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Mon Feb 3 00:41:17 2014, comment #6:

[hide_unit]: Takes SUF.
[unhide_unit]: Takes SUF.

So how would reimplementing those in terms of [store_unit] and [unstore_unit] be any help in this case? What would [unhide_unit] do with its SUF when the units in question aren't expected to exist on map or recall lists at that point?

I really don't think the current implementation needs to be replaced; improved, maybe, but not replaced.

Ignacio R. Morelle <shadowmaster>
Project Administrator
Sun Feb 2 23:59:03 2014, comment #5:

I don't think performance is particularly important here. Even if you want to hide an entire map full of units, it just needs to be fast enough that humans won't notice. I don't see any usecase where you would repeat this hundred of times.
We could simply reimplement [hide_unit]/[unhide_unit] using [store_unit]/[unstore_unit], though the variable it's stored in would be visible to the WML author.

Alexander van Gessel <ai0867>
Project Member
Sun Feb 2 22:53:50 2014, comment #4:

I haven't done any benchmarks myself, but I would expect a mass [hide_unit] operation to be faster than the [store_unit] equivalent given that [store_unit] has to perform additional tasks such as WML serialization (into the WML variables store) and removal of the matched units from the unit_map.

Other than the specific border case that prompted this bug report, I use [hide_unit] a lot in the implementation of cutscenes in one of my campaigns. With that in mind, replacing [hide_unit]/[unhide_unit] sequences with [store_unit]/{FOREACH}/[unstore_unit]/{NEXT}/[clear_variable] doesn't seem like an improvement to me from a design pattern perspective.

Ignacio R. Morelle <shadowmaster>
Project Administrator
Sun Feb 2 14:11:57 2014, comment #3:

The question raised here is if [hide_unit] is needed any longer at all. The event functionality should be possible using store and unstore, so it might be preferable to just get rid of it. If we want to use it outside of events, it should have the same interface effects as ambush.

Alexander van Gessel <ai0867>
Project Member
Sun Jan 19 22:29:50 2014, comment #2:

The assumption here is that the scenario coder wouldn't place a unit that will remain hidden beyond the duration of an event handling sequence where it may be reached by other units during normal gameplay.

However, as I said before, in reality the player is able to select units even during events.

Ignacio R. Morelle <shadowmaster>
Project Administrator
Sun Jan 19 20:50:26 2014, comment #1:

My understanding of [hide_unit] is that it is intended to hide units in the middle of a single event, and that it is not intended to hide units while the user has access to the game controls.

If you want to extend the functionality of [hide_unit] so it works over an extended period of time, my first question would be: what should happen if a player tries to move a unit to a hex occupied by a unit that was hidden via [hide_unit]?

J Tyne <jamit>
Project Member
Sun Jan 19 00:53:46 2014, original submission:

Units hidden by the [hide_unit] WML actions are fully invisible in-game, but their presence is revealed to the player when hovering or selecting the hex they are standing on -- the usual movement stats are displayed on the map, and the unit description appears on the sidebar.

This makes [hide_unit] somewhat inferior to normal ambush/concealment abilities for hiding units for extended periods of time while the user has access to the game controls (i.e. pretty much all of the time, even during events), so it's probably a bug.

It can be reproduced on 1.10.7+dev and 1.11.8+dev, so I presume it's existed for the entirety of the 1.11.x development cycle, and all stable versions.

Ignacio R. Morelle <shadowmaster>
Project Administrator


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by ai0867 (Posted a comment)
  • -unavailable- added by jamit (Posted a comment)
  • -unavailable- added by shadowmaster (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Jan 19 00:56:28 2014shadowmasterSeverity3 - Normal=>2 - Minor
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup