MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000259Zandronum[All Projects] Bugpublic2011-01-11 20:262013-07-21 18:01
ReporterBlzut3 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version98d 
Target VersionFixed in Version 
Summary0000259: Harvester skulls desync
DescriptionMod can be downloaded here:'http://www.doomworld.com/idgames/index.php?id=15498 [^]'

While playing the skulls spawned when a player dies desync over time. One theory is that touching skulls of your own color (in order to neutralize them) causes the skulls to turn into ghost pickups.

Decorate code should result in the Skull being always removed with Thing_Remove(0).
Pickup:
    BSKU A 0 Thing_Remove(0)
    stop


Reconnecting to the server causes the Skulltag to disappear so there's definitely some clientside desync involved.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-01-11 20:26Blzut3New Issue
2011-01-11 20:29Blzut3Description Updatedbug_revision_view_page.php?rev_id=374#r374
2011-01-19 02:55Torr SamahoNote Added: 0000832
2011-01-20 01:11Blzut3Note Added: 0000842
2011-01-22 16:47Torr SamahoNote Added: 0000849
2011-01-22 19:00Blzut3Note Added: 0000852
2011-01-22 20:30Edward-sanNote Added: 0000853
2012-06-09 13:22Torr SamahoCategoryGeneral => Bug
2013-07-21 18:01DuskStatusnew => closed
2013-07-21 18:01DuskResolutionopen => won't fix

Notes
(0000832)
Torr Samaho   
2011-01-19 02:55   
I'm not quite sure about the exact timings of the CustomInventory states. If the item removes itself in the Pickup state, is the Use state still supposed to be executed?
(0000842)
Blzut3   
2011-01-20 01:11   
Honestly I'm not sure if this is defined behavior (I'll probably change that if/when I release a new version of the mod), but I can confirm that ZDoom will execute the Use state when the Pickup state removes itself.
(0000849)
Torr Samaho   
2011-01-22 16:47   
Before debugging this I think we first need to know the defined behavior. I remember a bug report where a mod relied on an undefined behavior in ZDoom. The code worked in ZDoom by pure chance, but broke in Skulltag online.
(0000852)
Blzut3   
2011-01-22 19:00   
Then it's probably best if we just close this with "won't fix" and I'll just update the mod.

Though I should reiterate that the server seems to be handling the skulls fine, it's just the clients that are not updated about their removal. (As I said reconnecting to the server causes the "ghost skulls" to disappear.)
(0000853)
Edward-san   
2011-01-22 20:30   
Sorry for the intrusion, but, IMHO, isn't it better make an 'error' handling of that? I mean, if that code is used, Skulltag should place an 'Error:' during the loading of the game, with the explanation of the problem, so it prevents temporarily that desync... or a 'warning' message ...