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
0000815Zandronum[All Projects] Bugpublic2012-04-25 20:342018-09-30 19:52
ReporterHisymak 
Assigned ToDusk 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version98d 
Target VersionFixed in Version1.0 
Summary0000815: Sector with delayed poison damage (strife-like): your screen won't become green online
DescriptionWhen you stand in sector with Strife-like delayed poison damage (sector special 116), your screen will become green and will be more green the longer time you stay in the sector. The poison will become hurt you after some time and will still hurt you some time after leaving the sector.
But your screen won't become green when playing on server.
Steps To ReproduceTry the example wad offline and online.
Additional InformationNoticed when playing Jumpmaze map12.
Attached Files? file icon delayed_poison.wad [^] (858 bytes) 2012-04-25 20:34

- Relationships
parent of 0000816closedDusk 105 sDamage_Hellslime & 116 sDamage_SuperHellslime effect not cleared if turning into a spectator 

-  Notes
User avatar (0003431)
unknownna (updater)
2012-04-25 20:48
105 sDamage_Hellslime
116 sDamage_SuperHellslime

Quote from ZDoom Wiki
Strife's sector specials. These damage types don't start hurting the player immediately. Instead they accumulate a certain amount of 'poisoning' and when a certain threshold is reached they start hurting the player. Such damage infliction does not stop when the player leaves the sector. It will continue a little longer.
User avatar (0003434)
Dusk (developer)
2012-04-26 00:48
edited on: 2012-04-26 00:50

 'https://bitbucket.org/CrimsonDusk/notebola/changeset/c6aa69aa9232 [^]'

This should fix the problems. It's a bit extensive.. I added a new extended command SVC2_SETPLAYERHAZARDCOUNT. I added some mitigation its svcommand function so that it wouldn't send stuff every single tic. Bandwidth usage of this function is pretty much at least halved with this system in place.

Added a new bool bFeelingGreen to player_t to make the mitigation work properly. It only is of interest to the server.
User avatar (0003437)
Torr Samaho (administrator)
2012-04-26 02:58
edited on: 2012-04-26 11:23

 Why don't you let the client tic down the hazardcount on its own? At first glance I'd say only the P_DamageMobj call may not be done by the client. This needs far less bandwidth than letting the server update the client constantly.

EDIT: hazardcount should be set to zero in PLAYER_SetDefaultSpectatorValues unconditionally (that's also where for instance bonuscount is reset), instead of conditionally setting it to zero in PLAYER_SetSpectator.
User avatar (0003442)
Dusk (developer)
2012-04-26 12:17
edited on: 2012-04-26 12:17

 ... *facepalm*

Back to the drawing board, then.
User avatar (0003455)
Torr Samaho (administrator)
2012-04-26 23:17
edited on: 2012-04-26 23:18

 > Back to the drawing board, then.

I think the drawing board won't be necessary, it should be easy to adapt your fix. You pinpointed what's going on and the locations where to change things, so the bulk of the work is done :). If you want me to I can do this. Since I'll need to introduce another SVC2 command soon, I'd like to port your SVC2_SETPLAYERHAZARDCOUNT command beforehand to avoid conflicts.
User avatar (0004278)
Torr Samaho (administrator)
2012-08-05 21:10

 I revised and added your patch. Please test with the upcoming beta build.
User avatar (0004413)
Qent (updater)
2012-08-20 01:16

 It works now.

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
2012-04-25 20:34 Hisymak New Issue
2012-04-25 20:34 Hisymak File Added: delayed_poison.wad
2012-04-25 20:41 unknownna Status new => confirmed
2012-04-25 20:48 unknownna Note Added: 0003431
2012-04-25 20:52 unknownna Relationship added parent of 0000816
2012-04-25 22:08 Dusk Assigned To => Dusk
2012-04-25 22:08 Dusk Status confirmed => assigned
2012-04-26 00:48 Dusk Note Added: 0003434
2012-04-26 00:48 Dusk Status assigned => needs review
2012-04-26 00:50 Dusk Note Edited: 0003434 View Revisions
2012-04-26 02:58 Torr Samaho Note Added: 0003437
2012-04-26 02:59 Torr Samaho Status needs review => feedback
2012-04-26 11:23 Torr Samaho Note Edited: 0003437 View Revisions
2012-04-26 12:17 Dusk Note Added: 0003442
2012-04-26 12:17 Dusk Status feedback => assigned
2012-04-26 12:17 Dusk Note Edited: 0003442 View Revisions
2012-04-26 23:17 Torr Samaho Note Added: 0003455
2012-04-26 23:17 Torr Samaho Note Edited: 0003455
2012-04-26 23:18 Torr Samaho Note Edited: 0003455 View Revisions
2012-04-26 23:18 Torr Samaho Note Revision Dropped: 3455: 0001869
2012-04-26 23:18 Torr Samaho Note Revision Dropped: 3455: 0001870
2012-06-09 13:22 Torr Samaho Category General => Bug
2012-08-05 21:10 Torr Samaho Note Added: 0004278
2012-08-05 21:10 Torr Samaho Status assigned => needs testing
2012-08-20 01:16 Qent Note Added: 0004413
2012-08-20 10:35 Dusk Status needs testing => resolved
2012-08-20 10:35 Dusk Fixed in Version => 1.0-beta
2012-08-20 10:35 Dusk Resolution open => fixed
2012-08-23 01:56 Blzut3 Fixed in Version 1.0-beta => 1.0
2018-09-30 19:52 Blzut3 Status resolved => closed




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker