Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
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.
Attached Files

- Relationships

-  Notes
User avatar (0000832)
Torr Samaho (administrator)
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?
User avatar (0000842)
Blzut3 (administrator)
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.
User avatar (0000849)
Torr Samaho (administrator)
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.
User avatar (0000852)
Blzut3 (administrator)
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.)
User avatar (0000853)
Edward-san (developer)
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 ...

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2011-01-11 20:26 Blzut3 New Issue
2011-01-11 20:29 Blzut3 Description Updated View Revisions
2011-01-19 02:55 Torr Samaho Note Added: 0000832
2011-01-20 01:11 Blzut3 Note Added: 0000842
2011-01-22 16:47 Torr Samaho Note Added: 0000849
2011-01-22 19:00 Blzut3 Note Added: 0000852
2011-01-22 20:30 Edward-san Note Added: 0000853
2012-06-09 13:22 Torr Samaho Category General => Bug
2013-07-21 18:01 Dusk Status new => closed
2013-07-21 18:01 Dusk Resolution open => won't fix




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker