MantisBT - Zandronum
View Issue Details
0000313Zandronum[All Projects] Bugpublic2011-02-28 04:082018-09-30 19:55
unknownna 
Torr Samaho 
normalminoralways
closedfixed 
98d 
1.0 
0000313: NeoDoom plasma projectiles stuck in floors / ceilings / walls for newly connected clients
The title and the attached screenshot should explain this.
1) Start a normal server with the example WAD.
2) Connect a client to the server and join the game.
3) Start to fire.
4) Connect another client to the server while holding fire with the first client.
5) Once connected, stop firing.
The example WAD contains the plasma ball sprites (only the PLSS sprites were needed) and the DeHackEd patch found in NeoDoom.
missile, projectile
? neodoom_plasma_stuck_test.wad (48,675) 2011-02-28 04:08
/tracker/file_download.php?file_id=182&type=bug
png Screenshot_Doom_20110228_041910.png (41,664) 2011-02-28 04:09
/tracker/file_download.php?file_id=183&type=bug
png
Issue History
2011-02-28 04:08unknownnaNew Issue
2011-02-28 04:08unknownnaFile Added: neodoom_plasma_stuck_test.wad
2011-02-28 04:09unknownnaFile Added: Screenshot_Doom_20110228_041910.png
2012-03-01 06:04TIHanNote Added: 0002723
2012-03-03 00:42TIHanNote Edited: 0002723bug_revision_view_page.php?bugnote_id=2723#r1407
2012-03-03 17:45Torr SamahoNote Added: 0002743
2012-03-03 17:47Torr SamahoStatusnew => feedback
2012-03-03 18:00TIHanNote Added: 0002745
2012-03-03 18:00TIHanNote Edited: 0002745bug_revision_view_page.php?bugnote_id=2745#r1413
2012-03-03 18:28TIHanNote Edited: 0002745bug_revision_view_page.php?bugnote_id=2745#r1414
2012-03-03 18:35TIHanNote Edited: 0002745bug_revision_view_page.php?bugnote_id=2745#r1415
2012-03-06 00:42Torr SamahoNote Added: 0002756
2012-03-06 00:42Torr SamahoNote Edited: 0002756bug_revision_view_page.php?bugnote_id=2756#r1428
2012-03-06 06:57TIHanNote Added: 0002759
2012-03-09 01:54Torr SamahoNote Added: 0002768
2012-03-09 08:58TIHanNote Added: 0002769
2012-03-11 00:45Torr SamahoNote Added: 0002771
2012-03-11 00:46Torr SamahoNote Edited: 0002771bug_revision_view_page.php?bugnote_id=2771#r1436
2012-03-11 02:51TIHanNote Added: 0002779
2012-03-12 06:44TIHanNote Added: 0002803
2012-03-12 23:59Torr SamahoNote Added: 0002811
2012-03-24 16:37TIHanNote Added: 0002870
2012-03-24 16:39Torr SamahoNote Added: 0002871
2012-03-24 16:39Torr SamahoStatusfeedback => resolved
2012-03-24 16:39Torr SamahoFixed in Version => 1.0
2012-03-24 16:39Torr SamahoResolutionopen => fixed
2012-03-24 16:39Torr SamahoAssigned To => Torr Samaho
2012-06-09 13:22Torr SamahoCategoryGeneral => Bug
2018-09-30 19:55Blzut3Statusresolved => closed

Notes
(0002723)
TIHan   
2012-03-01 06:04   
(edited on: 2012-03-03 00:42)
Fixed in this changeset:'https://bitbucket.org/TIHan/tst/changesets/tip/branch(%22bug_313%22) [^]'

(0002743)
Torr Samaho   
2012-03-03 17:45   
Although this (possibly, didn't test) fixes the most apparent issue, I'd say the behavior still has to be wrong since the connecting client will always play the full explosion animation, no matter how much of the animation already passed on the server. I think to properly fix this one has to adapt the code below your change that calls SERVERCOMMANDS_SetThingFrame. When I wrote this I tried to be as conservative as possible, i.e. not to call this on more actors than necessary, but apparently missiles needs this treatment too.
(0002745)
TIHan   
2012-03-03 18:00   
(edited on: 2012-03-03 18:35)
The problem is that the client gets a thing that isn't a missile anymore and doesn't know that it actually exploded on the server.

I tried doing this when it knew the thing actually exploded on the server: SERVERCOMMANDS_SetThingFrame( pActor, pActor->state, ulClient, SVCF_ONLYTHISCLIENT, false ); - but I still get the original bug.

In that case, when the server sends that thing across to the client, it's not in its death/extreme/crash state; even though it actually exploded. That's why SetThingFrame doesn't fix it. Might be a timing issue in SetState?

(0002756)
Torr Samaho   
2012-03-06 00:42   
> I tried doing this when it knew the thing actually exploded on the server: SERVERCOMMANDS_SetThingFrame( pActor, pActor->state, ulClient, SVCF_ONLYTHISCLIENT, false ); - but I still get the original bug.

Does this command have any effect at all there for the exploded actor? For some complicated classes with custom states and/or complicated inheritance, SERVERCOMMANDS_SetThingFrame doesn't work (yet).

BTW: Instead of adding NETFL_EXPLODED you could try to check whether the actor had MF_MISSILE among its default flags but lost it now.

(0002759)
TIHan   
2012-03-06 06:57   
> Does this command have any effect at all there for the exploded actor?

Has no effect, unless I manually put in a state, such as NAME_Death; which is almost the same as P_MissileExplode.

If it helps, the plasma bullet has a dehacked mod to it:

Thing 35 (Plasma Bullet)
Death frame = 111
Death sound = 50
Speed = 1835008
Width = 524288
Height = 786432
Missile damage = 6

> BTW: Instead of adding NETFL_EXPLODED you could try to check whether the actor had MF_MISSILE among its default flags but lost it now.

This the proper way? " if ( pActor->GetDefault()->flags & MF_MISSILE ) " Since there was a check at beginning for the current actor's flag as a MF_MISSILE, I didn't have to recheck it here. Hm, really good to know all this! :D
(0002768)
Torr Samaho   
2012-03-09 01:54   
> Has no effect, unless I manually put in a state, such as NAME_Death; which is almost the same as P_MissileExplode.

Does SERVERCOMMANDS_SetThingFrame show a warning if you set sv_showwarnings to true? If so, we definitely should try to fix SERVERCOMMANDS_SetThingFrame.

> This the proper way? " if ( pActor->GetDefault()->flags & MF_MISSILE ) "

Yes :).
(0002769)
TIHan   
2012-03-09 08:58   
> Does SERVERCOMMANDS_SetThingFrame show a warning if you set sv_showwarnings to true?

Yes. A fair bit of these.

"Warning: SERVERCOMMANDS_SetThingFrame failed to set the frame for actor PlasmaBall."

I don't know enough about SetThingFrame. What is currently wrong with it?
(0002771)
Torr Samaho   
2012-03-11 00:45   
(edited on: 2012-03-11 00:46)
> I don't know enough about SetThingFrame.

The challenge in this function is to find a way to identify a state such that we can tell it to the clients. The current state of an actor is just a pointer whose address of course is useless for the clients. The idea behind the current implementation is to find a state label and an offset that identify the current state. Unfortunately this is not trivial (at least I don't know of any trivial solution).

> What is currently wrong with it?

It doesn't manage to find a state label and an offset for some states (depends on the actor definition).

I just revised how SERVERCOMMANDS_SetThingFrame works though and this seems to fix the Neodoom issues (https://bitbucket.org/Torr_Samaho/skulltag/changeset/235c909a5f2f). This needs very thorough testing.

(0002779)
TIHan   
2012-03-11 02:51   
I'll be testing this today.
(0002803)
TIHan   
2012-03-12 06:44   
So far, I haven't experienced any issues with your fix.
(0002811)
Torr Samaho   
2012-03-12 23:59   
Thanks for checking!
(0002870)
TIHan   
2012-03-24 16:37   
This should be resolved as the issue doesn't occur anymore and there haven't been any bugs caused by the fix.
(0002871)
Torr Samaho   
2012-03-24 16:39   
Good point -> resolved.