Unit Vanishes Between 1.8.b2 and 1.8.b5

[Nova]

I recently updated from 1.8.b2 to 1.8.b5, and somehow that made a unit stop appearing.

Here's what I've got for defining the side:

Code: Select all

    [side]
        type=Drake Chieftain
        name= _ "Malakar"
        id=Malakar
        {IS_HERO}
        side=4
        canrecruit=1
        controller=human
        recruit=Drake Hatchling,Drake Burner,Drake Glider,Drake Fighter,Drake Clasher
#ifdef EASY
        gold=260
#endif
#ifdef NORMAL
        gold=175
#endif
#ifdef HARD
        gold=145
#endif
        team_name=good
        user_team_name= _ "Kakatar Tribe"
        unrenameable=yes
        profile=portraits/malakar.png
        colour=1
        random_traits=no
        fog=no
        [unit]
            type=Drake Burner
            side=4
            gender=male
            find_vacant=yes
            name=Theracar
            id=Theracar0
            unrenamable=yes
            {IS_HERO}
            random_traits=no
            [modifications]
                {TRAIT_LOYAL}
            [/modifications]
            upkeep=loyal
        [/unit]
    [/side]

Previously, this made a unit named Theracar appear next to the leader. Now, he doesn't appear. I copied the scenario file back to 1.8.b2, to make sure I hadn't accidentally changed anything, and it works properly there.

I've poked around the forums some, and the best lead I've found was in the expanded release notes for 1.8.b4, which says:

* WML Engine:
* Rework of semantics of [unit] tags. Added 'placement' attribute.

But I can't find a further explanation than that, and "placement" isn't listed under SingleUnitWML: http://wiki.wesnoth.org/SingleUnitWML, nor under the sticky Important v1.8 Syntax Changes. This is my best guess for what's wrong, but I'm grasping at straws.

I don't know where else to look for information. Any help would be appreciated.

[Nova]

So I tried starting the campaign a few more times, shutting Wesnoth down completely in-between attempts, with the same problem each time. Eventually I gave up and walked away from it for the evening.

Now, unable to sleep, I decided to play through it anyways and see if anything else was obviously wrong. This time -- keeping in mind that I've made <i>no</i> changes to <i>anything</i> today -- it won't start the campaign at all and crashes back to the main menu.

Is consistency too much to ask for? Immediately after switching to b5, I had a separate problem in which it displayed an error message once, then never again -- replacing it afterward with a mere Scenario Unknown crash. I'd suspect something is wrong with the new release -- except that the forums aren't full of complaints about it. I can't be the only one noticing two separate major issues (failure of [unit], lack of consistency). I feel like it must be something more... my fault, but I'm out of guesses.


Also, I have no idea what this error message means, nor does Search turn up a src/map.cpp file.

[silene]

I had a separate problem in which it displayed an error message once, then never again -- replacing it afterward with a mere Scenario Unknown crash.

Files are preprocessed only once (since it can take several minutes on slower computers). So if you encounter an error during preprocessing, the corresponding message will be displayed only once. If this error causes some WML to be broken, then you will get a different error later when the WML is used.

[Crab]

Sorry for the delay in documenting, the syntax is still not final (default value of 'placement' will be changed a bit in the next release in order to maintain backward compatability).
I've updated the wiki with the description of the current behavior.
What is needed here is placement=leader - this is what places the unit next to leader (if no leader - next to start location)

[Nova]

It looks like this solved it; everything loads properly now. Thank you.

So, "find_vacant" is depreciated, and been replaced with "placement=leader." Why hasn't this caused dozens of problems already? Can I have been the first person to notice?

[Anonymissimus]

Is it correct that in 1.7.13, when creating a unit at the position of another unit ($unit.x $unit.y from a die event, or some other current unit coordinates),
placement=map
is needed to prevent overwriting the existing unit ?
If yes, this also breaks compatibility. I'm used to that e.g. when using {CLEAR_FOG ...} at the position of a fog-covered unit, the fog clearer does not overwrite the existing unit. This case happens frequently I believe, although probably not as often as creating units at positions of dying units. However, I'd prefer the behavior proposed by Crab:

Making sure that [unit] spawns only on vacant hexes fully prevents 'accidental' overwrites such as https://gna.org/bugs/index.php?1438... , which are annoying bugs and are far more harder to spot than mis-placings and duplications. I would prefer [unit] to work this way, requiring explicit authorization before replacing the unit with another.

Either way, compatibility will be broken.

/edit
1.7.10:

Code: Select all

   [event]
      name=turn 2
      [unit]
         type=Troll
         x,y=37,5
         side=2
      [/unit]
      {DEBUG_MSG _"hehe"}
      {CLEAR_FOG 1 37 5 1}#fog cleared; Troll at (37,5); fog clearer at (36,4)
   [/event]


/edit2
The problem that the unit created at the dying unit's coordinates is created 1 hex beside these coordinates was already present in 1.7.10.
This thread has become a parallel discussion
to http://gna.org/bugs/?15113

[Crab]

It looks like this solved it; everything loads properly now. Thank you.

So, "find_vacant" is depreciated, and been replaced with "placement=leader." Why hasn't this caused dozens of problems already? Can I have been the first person to notice?

Because only find_vacant in [unit] is depreciated, and that find_vacant in [unit] was added only during this autumn, so it wasn't used much. also, placement=leader is not a direct replacement for find_vacant. Rather, placement=map impiles find_vacant="yes" near specified map location, placement=leader implies find_vacant="yes" near leader or start location.

[Crab]

Is it correct that in 1.7.13, when creating a unit at the position of another unit ($unit.x $unit.y from a die event, or some other current unit coordinates),
placement=map
is needed to prevent overwriting the existing unit ?
If yes, this also breaks compatibility. I'm used to that e.g. when using {CLEAR_FOG ...} at the position of a fog-covered unit, the fog clearer does not overwrite the existing unit. This case happens frequently I believe, although probably not as often as creating units at positions of dying units. However, I'd prefer the behavior proposed by Crab:

Right now, if no placement is given, it'll result in placement='map,recall' for [unit]. And, placement=map will not overwrite. So, right now, there'll be no overwrite in this case.

Big thanks for bringing the CLEAR_FOG use case to my attention.
What I'm going to do to make both use cases work as expected for 1.8 :
1) introduce placement=map_overwrite as a additional value for placement, which will place the unit on map if x,y are given, overwriting the unit there, if any.
2) use 'map_overwrite' in default values of placement instead of 'map'
3) change CLEAR_FOG macro to use explicit 'placement=map,recall', so that macro will not ever overwrite.
4) in 1.9, I'll revert (2) to current behavior.

[Anonymissimus]

What I'm going to do to make both use cases work as expected for 1.8 :
1) introduce placement=map_overwrite as a additional value for placement, which will place the unit on map if x,y are given, overwriting the unit there, if any.
2) use 'map_overwrite' in default values of placement instead of 'map'
3) change CLEAR_FOG macro to use explicit 'placement=map,recall', so that macro will not ever overwrite.
4) in 1.9, I'll revert (2) to current behavior.

So this requires inserting
placement=map
whenever units are created at the positions of other units, with the existing unit supposed to stay, for BfW 1.8 ? There are at least several places where this happens in my campaign, although I can't tell for mainline. This should certainly be mentioned among the important syntax changes then.
And then for 1.9 it requires inserting
placement=map_overwrite
whenever units are created at the positions of dying units, or in general in case that the existing unit is supposed to vanish ?!

/edit
I do think that placement=map must be the default one. CLEAR_FOG isn't the only situation where unit overwrites could happen. Think about underground scenarios (with few hexes where units can be) where some units are created at roughly the same position (sometimes they are actually created at the same position, using the current non-overwriting behaviour). Other units (human, AI) could stand at those positions...

[Crab]

as you know, I'm in favor of placement='map' being the default over 'map_overwrite', exactly to prevent such situations as the undeground one you've mentioned.

and, I've just asked zookeeper, he says ", i'd say the default should be not overwrite but to put on nearest vacant. that's the "safe" default...if someone wants to potentially erase existing units then they ought to specify it".

[Crab]

and, it seems that there was a misunderstanding on what was the default value was before (see bug #15113), so placement=map will stay as default.