bugBattle for Wesnoth - Bugs: bug #15113, Units can talk in their own die...

 
 
Show feedback again

bug #15113: Units can talk in their own die events

Submitted by:  Dan Gerhards <beetlenaut>
Submitted on:  Tue Jan 12 16:48:59 2010  
 
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: WML
Status: NonePrivacy: Public
Assigned to: Iurii Chernyi <crab>Open/Closed: Open
Release: 1.7.11Operating System: Linux

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 Jan 25 22:06:57 2010, comment #10:

also,
--
shadowmaster: and, what do you think about "what should be the default behavior of [unit]x,y=1,1[/unit] when 1,1 is occupied by other unit" ? should it, by default, overwrite or find nearby vacant tile ? ( https://gna.org/bugs/?15113 ).
(11:51:09 PM) shadowmaster: find nearby vacant tile
(11:51:17 PM) Crab_: ok, thanks
(11:51:52 PM) shadowmaster: that has been the behavior since as far as I can recall (1.0)
...
(11:58:10 PM) shadowmaster: Crab_: confirmed that "find nearby vacant tile" was the normal behavior in 1.0 already with a [event]name=start in the test scenario spawning an Orcish Warrior and an Elvish Shaman at 10,10
(11:58:38 PM) shadowmaster: the shaman was spawned second and at 10,9
(01/26/2010 12:00:04 AM) shadowmaster: same behavior in 1.6's test scenario with the same sequence but in a prestart event

Iurii Chernyi <crab>
Project MemberIn charge of this item.
Mon Jan 25 21:48:29 2010, comment #9:

Got some negative feedack on aforementioned kind of solution on forum [ http://forums.wesnoth.org/viewtopic.php?f=21&t=28616 ], and asked zookeeper about "what should be the default behavior of [unit]x,y=1,1[/unit] when 1,1 is occupied by other unit"

--
(11:31:43 PM) zookeeper: Crab_, i'd say the default should be not overwrite but to put on nearest vacant
(11:32:15 PM) zookeeper: that's the "safe" default...if someone wants to potentially erase existing units then they ought to specify it
--

Iurii Chernyi <crab>
Project MemberIn charge of this item.
Wed Jan 20 21:10:00 2010, comment #8:

Making sure that [unit] spawns only on vacant hexes fully prevents 'accidential' overwrites such as https://gna.org/bugs/index.php?14384 , 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.

However, I agree with 'you are changing the behavior of a WML tag very late in the development cycle.' part and, therefore, propose 'I revert that part now, document, and reapply in 1.9' solution.

Iurii Chernyi <crab>
Project MemberIn charge of this item.
Wed Jan 20 06:41:47 2010, comment #7:

No, it isn't a feature, it's a bug; you are changing the behavior of a WML tag very late in the development cycle. And it isn't just an obscure behavior: designers do use the [unit] tag to overwrite units in events without killing them first (and nothing in the documentation says they shouldn't). Please revert this part of your patch.

Guillaume Melquiond <silene>
Tue Jan 19 21:47:57 2010, comment #6:

yes, silene is right, 'the fact that unit cannot be created in the proper location' is a consequence of my change. but, IMO, it's not a bug, it's a feature - a consequence of the fact that the original unit is still not dead ('A unit isn't erased yet') at this time, so it's square is occupied, so the ghost is spawned at nearest free square.

Iurii Chernyi <crab>
Project MemberIn charge of this item.
Sun Jan 17 06:40:53 2010, comment #5:

The filtering part can't be changed easily. However, the fact that unit cannot be created in the proper location may be a bug introduced by Crab_ when he rewrote the way units are created for 1.7.11.

Guillaume Melquiond <silene>
Sat Jan 16 11:13:12 2010, comment #4:

ai0867, you can go ahead and fix this before 1.8 without worrying about compatibility. wmllint has a test for units speaking in their die events and I have already used it to verify that mainline no longer has any of these cases in it. (I fixed several myself.)

Eric S. Raymond <esr>
Project Member
Fri Jan 15 12:45:19 2010, comment #3:

It sounds like this may be more trouble than its worth to change. Since the behavior seems counterintuitive, I added a note to the wiki.

Dan Gerhards <beetlenaut>
Project Member
Fri Jan 15 00:57:21 2010, comment #2:

My previous guess was incorrect. The current method of firing events requires that the unit still exists in order for it to be filtered on.

I'll see if this can be changed, but this will almost certainly have to wait for 1.9, so I'm marking this bug postponed for now.

Alexander van Gessel <ai0867>
Project Member
Fri Jan 15 00:48:39 2010, comment #1:

A unit isn't erased yet at that point because the die event can be used to revive the unit.
This can also be done from the last breath event however and probably only exists for backwards compatibility reasons.

I'm not sure if it's a good idea to change it this late in 1.7 though.

Alexander van Gessel <ai0867>
Project Member
Tue Jan 12 16:48:59 2010, original submission:

A die event fires after the unit's death animation plays, and the unit disappears. However, in the following code, the unit that triggered the event can be the one who talks. Also, the ghost won't appear in the right place:

As a workaround, you can add a [kill] tag to the die event:
But that isn't obvious, and if it's necessary, it should happen internally.

Dan Gerhards <beetlenaut>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

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 shadowmaster (Updated the item)
  • -unavailable- added by crab (Posted a comment)
  • -unavailable- added by silene (Posted a comment)
  • -unavailable- added by esr (Posted a comment)
  • -unavailable- added by ai0867 (Posted a comment)
  • -unavailable- added by beetlenaut (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

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Jan 29 21:34:49 2012shadowmasterStatusPostponed=>None
    Thu Jan 28 23:13:31 2010crabSeverity5 - Blocker=>3 - Normal
      StatusNone=>Postponed
    Wed Jan 20 06:41:47 2010sileneSeverity3 - Normal=>5 - Blocker
      Priority3 - Low=>5 - Normal
      StatusPostponed=>None
      Assigned toai0867=>crab
    Fri Jan 15 00:57:21 2010ai0867StatusConfirmed=>Postponed
    Fri Jan 15 00:48:39 2010ai0867Priority5 - Normal=>3 - Low
      StatusNone=>Confirmed
      Assigned toNone=>ai0867
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup