MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000776Zandronum[All Projects] Bugpublic2012-04-15 03:212018-09-30 19:52
ReporterConflagratedCanine 
Assigned ToDusk 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version98d 
Target VersionFixed in Version1.0 
Summary0000776: Custom pain/wound states don't work online
Description
Quote from "Conflagrated"
When we were testing Island online, we found that PAIN was being run at the same time as PAIN.HEAT for the player classes; This was determined by the fact that PAIN.HEAT doesn't play any sounds.
Steps To Reproduce1. skulltag.exe -file damagetype_01.wad -host
2. Connect a client to the server and join the game.
3. Attack the zombiemen.
Additional Information
Quote from "Conflagrated"
This also seems to cause conflicts with death states as well.

The custom death states seem to be working as intended in my example WAD.
TagsNo tags attached.
Relationships
related to 0001121confirmed  "Goto Super::Death" causes death state to repeat itself for incoming clients + incoming clients dont know where to go in states 
Attached Files? damagetype_01.wad (1,061) 2012-04-15 03:21
/tracker/file_download.php?file_id=545&type=bug
Issue History
Date ModifiedUsernameFieldChange
2012-04-15 03:21unknownnaNew Issue
2012-04-15 03:21unknownnaFile Added: damagetype_01.wad
2012-04-15 03:22unknownnaReporterunknownna => ConflagratedCanine
2012-04-15 03:22unknownnaStatusnew => confirmed
2012-04-15 03:24unknownnaAdditional Information Updatedbug_revision_view_page.php?rev_id=1735#r1735
2012-04-15 03:24unknownnaAdditional Information Updatedbug_revision_view_page.php?rev_id=1736#r1736
2012-05-16 11:08DuskNote Added: 0003639
2012-05-16 11:08DuskAssigned To => Dusk
2012-05-16 11:08DuskSeverityminor => major
2012-05-16 11:09DuskStatusconfirmed => assigned
2012-05-16 11:09DuskNote Edited: 0003639bug_revision_view_page.php?bugnote_id=3639#r1998
2012-05-16 14:18Edward-sanNote Added: 0003641
2012-05-16 23:12DuskNote Added: 0003642
2012-05-16 23:12DuskStatusassigned => needs review
2012-05-16 23:18DuskNote Edited: 0003642bug_revision_view_page.php?bugnote_id=3642#r2000
2012-05-16 23:18DuskNote Edited: 0003642bug_revision_view_page.php?bugnote_id=3642#r2001
2012-05-17 18:56Torr SamahoNote Added: 0003644
2012-05-17 18:57Torr SamahoNote Edited: 0003644
2012-05-17 18:57Torr SamahoNote Edited: 0003644
2012-05-17 18:58Torr SamahoNote Edited: 0003644bug_revision_view_page.php?bugnote_id=3644#r2009
2012-05-17 18:58Torr SamahoNote Revision Dropped: 3644: 0002006
2012-05-17 18:58Torr SamahoNote Revision Dropped: 3644: 0002007
2012-05-17 18:58Torr SamahoNote Revision Dropped: 3644: 0002008
2012-05-17 18:59Torr SamahoStatusneeds review => feedback
2012-05-17 19:22DuskNote Added: 0003645
2012-05-17 19:23DuskNote Edited: 0003645bug_revision_view_page.php?bugnote_id=3645#r2011
2012-05-18 00:27Edward-sanNote Added: 0003646
2012-05-18 00:28Edward-sanNote Edited: 0003646bug_revision_view_page.php?bugnote_id=3646#r2013
2012-05-18 00:28Edward-sanNote Edited: 0003646bug_revision_view_page.php?bugnote_id=3646#r2014
2012-05-19 15:05DuskNote Added: 0003647
2012-05-20 08:17Torr SamahoNote Added: 0003648
2012-05-27 08:54Torr SamahoNote Added: 0003659
2012-05-27 09:01Torr SamahoStatusfeedback => needs testing
2012-06-09 13:22Torr SamahoCategoryGeneral => Bug
2012-08-02 01:03QentNote Added: 0004183
2012-08-02 05:21Torr SamahoStatusneeds testing => resolved
2012-08-02 05:21Torr SamahoFixed in Version => 1.0
2012-08-02 05:21Torr SamahoResolutionopen => fixed
2012-10-13 15:41unknownnaRelationship addedrelated to 0001121
2018-09-30 19:52Blzut3Statusresolved => closed

Notes
(0003639)
Dusk   
2012-05-16 11:08   
(edited on: 2012-05-16 11:09)
I've seen this happen in mods like Stronghold (clients think that monsters are still running after getting stunned) and I think that this isn't such a "minor" issue... this should definitely get fixed for 98e.
(0003641)
Edward-san   
2012-05-16 14:18   
uh... maybe there's a relation between this and a problem I saw in Zombie Horde in 98d:

if you're a zombie, when you're being hit you hear the zombie pain sound, but the other players hear also the normal player pain sound. I'm not sure if it happens also in 98e beta.
(0003642)
Dusk   
2012-05-16 23:12   
(edited on: 2012-05-16 23:18)
This was a tricky one, needed to pretty much rewrite FindStateLabelAndOffset to support for state children. I got it working flawlessly, Stronghold's stunner rifle and the example wad work flawlessly now. :)

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

EDIT: Whoops, contains a bit of junk...
(0003644)
Torr Samaho   
2012-05-17 18:56   
(edited on: 2012-05-17 18:58)
Can you elaborate why you need the construction
FState* modstate = target->FindState(NAME_Wound, mod);
                if (mod != NAME_None && modstate != target->FindState(NAME_Wound)) {
                    // Custom wound state
                    SERVERCOMMANDS_SetThingFrame( target, modstate );
                } else {
                    // Normal wound state
                    SERVERCOMMANDS_SetThingState( target, STATE_WOUND );
                }
instead of just
SERVERCOMMANDS_SetThingFrame( target, modstate );( target, woundstate );
?
(0003645)
Dusk   
2012-05-17 19:22   
(edited on: 2012-05-17 19:23)
Bandwidth reduction? SetThingState only sends a byte while SetThingFrame sends a whole string. It's done for other similar states, so I figured having a similar structure for Wound wouldn't be a bad idea...
(0003646)
Edward-san   
2012-05-18 00:27   
(edited on: 2012-05-18 00:28)
imho SERVERCOMMANDS_SetThingFrame should have an additive bool parameter, so the code could be reduced to:

SERVERCOMMANDS_SetThingFrame( target, modstate, (mod != NAME_None && modstate != target->FindState(NAME_Wound)));
(0003647)
Dusk   
2012-05-19 15:05   
Maybe go even further and add Wound checking into _SetThingFrame, in which case I don't think even that conditional clause wouldn't be needed, albiet might cause a teeny bit overhead..
(0003648)
Torr Samaho   
2012-05-20 08:17   
Quote from Dusk
Bandwidth reduction? SetThingState only sends a byte while SetThingFrame sends a whole string. It's done for other similar states, so I figured having a similar structure for Wound wouldn't be a bad idea...

In that case, you should put the corresponding check into SERVERCOMMANDS_SetThingFrame to the existing checks that are meant to save bandwidth (like you suggested further down). Even though this slightly increases CPU overhead, it will make sure that the bandwidth is saved no matter where SERVERCOMMANDS_SetThingFrame is called and only needs the code at one place.
(0003659)
Torr Samaho   
2012-05-27 08:54   
I added your patch, but split it into several commits (will make debugging problems that may arise from it easier) and made some modifications (see the log messages for details).
(0004183)
Qent   
2012-08-02 01:03   
This fix works.