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
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.
Attached Files? file icon damagetype_01.wad [^] (1,061 bytes) 2012-04-15 03:21

- 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 

-  Notes
User avatar (0003639)
Dusk (developer)
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.
User avatar (0003641)
Edward-san (developer)
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.
User avatar (0003642)
Dusk (developer)
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...
User avatar (0003644)
Torr Samaho (administrator)
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 );
?
User avatar (0003645)
Dusk (developer)
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...
User avatar (0003646)
Edward-san (developer)
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)));
User avatar (0003647)
Dusk (developer)
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..
User avatar (0003648)
Torr Samaho (administrator)
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.
User avatar (0003659)
Torr Samaho (administrator)
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).
User avatar (0004183)
Qent (updater)
2012-08-02 01:03

 This fix works.

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-15 03:21 unknownna New Issue
2012-04-15 03:21 unknownna File Added: damagetype_01.wad
2012-04-15 03:22 unknownna Reporter unknownna => ConflagratedCanine
2012-04-15 03:22 unknownna Status new => confirmed
2012-04-15 03:24 unknownna Additional Information Updated View Revisions
2012-04-15 03:24 unknownna Additional Information Updated View Revisions
2012-05-16 11:08 Dusk Note Added: 0003639
2012-05-16 11:08 Dusk Assigned To => Dusk
2012-05-16 11:08 Dusk Severity minor => major
2012-05-16 11:09 Dusk Status confirmed => assigned
2012-05-16 11:09 Dusk Note Edited: 0003639 View Revisions
2012-05-16 14:18 Edward-san Note Added: 0003641
2012-05-16 23:12 Dusk Note Added: 0003642
2012-05-16 23:12 Dusk Status assigned => needs review
2012-05-16 23:18 Dusk Note Edited: 0003642 View Revisions
2012-05-16 23:18 Dusk Note Edited: 0003642 View Revisions
2012-05-17 18:56 Torr Samaho Note Added: 0003644
2012-05-17 18:57 Torr Samaho Note Edited: 0003644
2012-05-17 18:57 Torr Samaho Note Edited: 0003644
2012-05-17 18:58 Torr Samaho Note Edited: 0003644 View Revisions
2012-05-17 18:58 Torr Samaho Note Revision Dropped: 3644: 0002006
2012-05-17 18:58 Torr Samaho Note Revision Dropped: 3644: 0002007
2012-05-17 18:58 Torr Samaho Note Revision Dropped: 3644: 0002008
2012-05-17 18:59 Torr Samaho Status needs review => feedback
2012-05-17 19:22 Dusk Note Added: 0003645
2012-05-17 19:23 Dusk Note Edited: 0003645 View Revisions
2012-05-18 00:27 Edward-san Note Added: 0003646
2012-05-18 00:28 Edward-san Note Edited: 0003646 View Revisions
2012-05-18 00:28 Edward-san Note Edited: 0003646 View Revisions
2012-05-19 15:05 Dusk Note Added: 0003647
2012-05-20 08:17 Torr Samaho Note Added: 0003648
2012-05-27 08:54 Torr Samaho Note Added: 0003659
2012-05-27 09:01 Torr Samaho Status feedback => needs testing
2012-06-09 13:22 Torr Samaho Category General => Bug
2012-08-02 01:03 Qent Note Added: 0004183
2012-08-02 05:21 Torr Samaho Status needs testing => resolved
2012-08-02 05:21 Torr Samaho Fixed in Version => 1.0
2012-08-02 05:21 Torr Samaho Resolution open => fixed
2012-10-13 15:41 unknownna Relationship added related to 0001121
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