Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000586Zandronum[All Projects] Bugpublic2011-09-17 20:592018-09-30 22:49
Reportercq75 
Assigned ToTorr Samaho 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionsuspended 
PlatformLinuxOSUbuntuOS Version10.04 x86-64
Product Version98d 
Target VersionFixed in Version 
Summary0000586: Weapons disappear if your health is greater than approx. 30000
DescriptionI noticed that my weapons disappeared when my health was at 31585, it may have been earlier since I was giving health in large increments

When my weapons disappeared, the classic HUD showed me as having -99 health, and my mugshot showed me as dead.

I could still fire my weapon, but the ammo counter was not updated. When I ran out of ammmo, I did not switch to another weapon, not even the fist, I just stopped firing.

Steps To Reproduce1. give yourself 30-32K health
2. shoot your weapon, and notice what happens to both the minimal HUD and the classic HUD.
Additional InformationThis was discovered in 98E-r3299
Attached Files

- Relationships

-  Notes
User avatar (0002166)
cq75 (reporter)
2011-09-17 21:00

Also, when this bug happens, you can't switch to another weapon.
User avatar (0002270)
Minigunner (reporter)
2011-11-01 00:29
edited on: 2011-11-01 00:30

NEVER give yourself more than 32,767 of anything in one command while online. If you do, the count resets to -32,767 and goes up from there. At that point, if you do this to your health, the game considers you as dead, or rather undead, since you haven't literally died by passing zero.

User avatar (0002282)
Gez (reporter)
2011-11-06 13:50

Pretty much not a bug. The weapons go away when you're dead. If your health is 0 or less, you are dead and your weapons go away. A 16-bit value above 32767 is negative, so a health value above 32767 is negative and you are dead and your weapons go away.

In fact, the bug would be if it didn't happen.

Oh, and yeah it can be pushed away by writing the value on 32-bit instead of 16, but then you'll get the same effect at 2 147 483 647. And if 30000 health isn't enough for you, 2 0000 000 000 won't be enough either.
User avatar (0002283)
cq75 (reporter)
2011-11-06 19:03
edited on: 2011-11-06 19:22

It is a bug, anything that causes strange behavior is a bug. What you're saying is, it's not serious, and I agree, that is why I listed it as "minor".

I'll let the developer(s) decide whether it's worth adding a check to stop this from happening.

EDIT - also, it was not in one command

User avatar (0002284)
Gez (reporter)
2011-11-07 08:58

Okay, if anything that causes strange behavior is a bug, then I have another to submit: use noclip and go outside the level: everything becomes a huge HOM! :p
User avatar (0002295)
cq75 (reporter)
2011-11-08 13:53
edited on: 2011-11-08 22:55

By strange I mean *un-handled* behavior. You can turn off noclip mode, go back into the level, and keep playing normally, because the game engine was designed to handle people going outside of the borders of the map.

The game engine doesn't expect you to go over 32766 health, so it does bizarre things. You can make the case that this is a tiny bug, but *anything the player can do to break the engine is a bug*, no matter how unlikely it is to happen.

Also, you aren't dead when that happens.

It would be better to just have it stop at the integer maximum and possibly report some sort of error from giveinventory(). If a mod was complicated, the current behavior could make it hard to debug what really went wrong.

EDIT - Gez, if you want to have a discussion about the definition of "bug", I'll read and consider what you have to say, but this bug tracker is not the place to do it. Send me a PM explaining your case on the ST forums.

User avatar (0002314)
Torr Samaho (administrator)
2011-12-04 01:29

Alright, I'd say the fact that the engine doesn't cap the player's life at SHRT_MAX can be seen as a bug. Since ZDoom seems to handle this exactly like Skulltag does, it's a ZDoom problem though and should be fixed there first (or decided not to be fixed).
User avatar (0002375)
Torr Samaho (administrator)
2012-01-14 16:45

Suspended till a decision about how this should be handled is made at ZDoom.

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-09-17 20:59 cq75 New Issue
2011-09-17 21:00 cq75 Note Added: 0002166
2011-11-01 00:29 Minigunner Note Added: 0002270
2011-11-01 00:30 Minigunner Note Edited: 0002270 View Revisions
2011-11-06 13:50 Gez Note Added: 0002282
2011-11-06 19:03 cq75 Note Added: 0002283
2011-11-06 19:22 cq75 Note Edited: 0002283 View Revisions
2011-11-07 08:58 Gez Note Added: 0002284
2011-11-08 13:53 cq75 Note Added: 0002295
2011-11-08 13:54 cq75 Note Edited: 0002295 View Revisions
2011-11-08 22:52 cq75 Note Edited: 0002295 View Revisions
2011-11-08 22:55 cq75 Note Edited: 0002295 View Revisions
2011-12-04 01:29 Torr Samaho Note Added: 0002314
2012-01-14 16:45 Torr Samaho Note Added: 0002375
2012-01-14 16:45 Torr Samaho Status new => resolved
2012-01-14 16:45 Torr Samaho Resolution open => suspended
2012-01-14 16:45 Torr Samaho Assigned To => Torr Samaho
2012-06-09 13:22 Torr Samaho Category General => Bug
2018-09-30 22:49 Blzut3 Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker