Unit Vanishes Between 1.8.b2 and 1.8.b5
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.
Unit Vanishes Between 1.8.b2 and 1.8.b5
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:
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:
I don't know where else to look for information. Any help would be appreciated.
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]
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:
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.* WML Engine:
* Rework of semantics of [unit] tags. Added 'placement' attribute.
I don't know where else to look for information. Any help would be appreciated.
"Never underestimate the power of the fish rush." "I don't think nagas are fish." "Fish Rush!"
---
Flight to Freedom: http://forums.wesnoth.org/viewtopic.php ... &start=690
Co-Author, Maintainer
---
Flight to Freedom: http://forums.wesnoth.org/viewtopic.php ... &start=690
Co-Author, Maintainer
Re: Unit Vanishes Between 1.8.b2 and 1.8.b5
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.
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.
"Never underestimate the power of the fish rush." "I don't think nagas are fish." "Fish Rush!"
---
Flight to Freedom: http://forums.wesnoth.org/viewtopic.php ... &start=690
Co-Author, Maintainer
---
Flight to Freedom: http://forums.wesnoth.org/viewtopic.php ... &start=690
Co-Author, Maintainer
Re: Unit Vanishes Between 1.8.b2 and 1.8.b5
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.Nova wrote: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.
Re: Unit Vanishes Between 1.8.b2 and 1.8.b5
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)
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)
Re: Unit Vanishes Between 1.8.b2 and 1.8.b5
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?
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?
"Never underestimate the power of the fish rush." "I don't think nagas are fish." "Fish Rush!"
---
Flight to Freedom: http://forums.wesnoth.org/viewtopic.php ... &start=690
Co-Author, Maintainer
---
Flight to Freedom: http://forums.wesnoth.org/viewtopic.php ... &start=690
Co-Author, Maintainer
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: Unit Vanishes Between 1.8.b2 and 1.8.b5
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:
/edit
1.7.10:
/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
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:
Either way, compatibility will be broken.Crab wrote: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.
/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]
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
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: Unit Vanishes Between 1.8.b2 and 1.8.b5
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.Nova wrote: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?
Re: Unit Vanishes Between 1.8.b2 and 1.8.b5
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.Anonymissimus wrote: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:
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.
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: Unit Vanishes Between 1.8.b2 and 1.8.b5
So this requires insertingCrab wrote: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.
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...
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: Unit Vanishes Between 1.8.b2 and 1.8.b5
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".
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".
Re: Unit Vanishes Between 1.8.b2 and 1.8.b5
and, it seems that there was a misunderstanding on what was the default value was before (see bug #15113 [Gna.org]), so placement=map will stay as default.