Notes |
|
(0002723)
|
TIHan
|
2012-03-01 06:04
(edited on: 2012-03-03 00:42) |
|
|
|
|
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?
|
|
|
|
> 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 |
|
|
|
> 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. |
|
|
|
|
|
(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. |
|
|
|
|