|
Notes |
|
|
|
|
|
|
|
|
Same I think issue present in Zombie Horde: when you are shooting a fire grenade at barrel the grenade disappear and after a while you see only explosion sprite not fire which must be spawned by grenade after explosion. |
|
|
|
(0002652)
|
|
Torr Samaho
|
2012-02-20 01:44
(edited on: 2012-02-20 02:32) |
|
This should improve sync when a grenade bounces off another actor.
|
|
|
|
|
|
It works for grenades but I can't confirm does it fix fire grenades too lazy to start Zombie Horde server. Please fix URL in your post. |
|
|
|
(0002654)
|
|
Dusk
|
2012-02-20 11:02
(edited on: 2012-02-20 11:08) |
|
I and TIHan were on about this bug. The grenade was desynced in a couple of ways:
- The initial flight curve is off by a fraction of an unit. Changing A_FireCustomMissileHelper to use ShootMissileExact fixes this.
- The client isn't told about it when the grenade bounces off the barrel nor can it figure it by itself, even when the flight curve is corrected. When I made it to do so, bounces caused further desynchs related to Z-height:
if ( NETWORK_GetState( ) == NETSTATE_SERVER ) {
SERVERCOMMANDS_SetThingAngleExact( mo );
SERVERCOMMANDS_MoveThingExact( mo, CM_MOMX|CM_MOMY|CM_MOMZ|CM_X|CM_Y|CM_Z );
}
With these changes applied, the Z-height remains off by momz units:
Server's log:'http://pastebin.com/1ijdWQhn [^]'
Client's log:'http://pastebin.com/XyhmMp03 [^]'
Picture, with grenade trails:'http://i.imgur.com/fihrE.png [^]'
Red trail is client's, green trail is server's.
(I added the function names afterward, I wanted to note which function caused what log entry but didn't want to get the material all over again)
Granted, the desynch isn't very much and informing the clients about the bounce fixes the initial desynch and fixing the flight curve with SpawnMissileExact fixes further desynchs (where the client thought in some cases that the grenade hit the barrel while it actually flew over). The only problem left is that the bounce leaves no bounce sound as clients can't figure that. I'd believe that if clients were told about bounce sounds explicitly it should fix the issue.
Also, TIHan found out that the client thinks grenade seems to be fired twice - this causes the firing sound to be played twice.
I noticed that the debug build you have has the exact same issue of Z-height desynch and no bounce sound. I get the same grenade curve trails with the build and I believe the coordinates won't be very far off either.
|
|
|
|
|
> - The initial flight curve is off by a fraction of an unit. Changing A_FireCustomMissileHelper to use ShootMissileExact fixes this.
Sounds good, but I guess you mean SERVERCOMMANDS_SpawnMissileExact instead of ShootMissileExact, right?
> - The client isn't told about it when the grenade bounces off the barrel nor can it figure it by itself, even when the flight curve is corrected.
That's what I changed in my debug build (code is committed now that ZzZombo reported that it improves the situation for him). I still need to make the change in A_FireCustomMissileHelper though, I didn't notice that during my quick tests yesterday.
> Red trail is client's, green trail is server's.
That looks perfect for debugging. Is that an example wad? Can you send it to me?
> Also, TIHan found out that the client thinks grenade seems to be fired twice - this causes the firing sound to be played twice.
Can you elaborate this?
> I noticed that the debug build you have has the exact same issue of Z-height desynch and no bounce sound.
That's weird. I added new netcode for the bounce sound (contained in the build I posted above) and it worked in my tests. |
|
|
|
|
|
I remember I heard the bounce from barrel. Also it may have value I spawned the grenade with "summon grenade" in console because was lazy to cheat ammo for grenade launcher. |
|
|
|
(0002657)
|
|
Dusk
|
|
2012-02-20 13:28
|
|
>Sounds good, but I guess you mean SERVERCOMMANDS_SpawnMissileExact instead of ShootMissileExact, right?
Yeah. Remembered the name wrong there.
> That looks perfect for debugging. Is that an example wad? Can you send it to me?
Uploaded:'http://www.mediafire.com/?mvnceomn3rbiggw [^]'
> I added new netcode for the bounce sound (contained in the build I posted above) and it worked in my tests.
The bounce sound works, though the z-height desynch remains there. Again, it's neglegible, being only a few units. It happens right after the grenade hits the barrel, and is as if the client misses an application of momz on the grenade's Z position. X/Y coords remain perfectly in sync until further bounces cause minor X/Y desyncing due to the Z coordinate being off. |
|
|
|
(0002659)
|
|
TIHan
|
|
2012-02-20 14:18
|
|
What Nightfall said, the grenade gets fired twice. client_SpawnMissileExact gets called, then client_SpawnMissile.
In A_FireCustomMissileHelper, P_SpawnPlayerMissile calls SERVERCOMMANDS_SpawnMissileExact then at the end of A_FireCustomMissileHelper, SERVERCOMMANDS_SpawnMissile gets called. |
|
|
|
(0002660)
|
|
TIHan
|
|
2012-02-21 01:50
|
|
|
|
|
|
> In A_FireCustomMissileHelper, P_SpawnPlayerMissile calls SERVERCOMMANDS_SpawnMissileExact then at the end of A_FireCustomMissileHelper, SERVERCOMMANDS_SpawnMissile gets called.
Good finding! Your fix for this issue works, needs more nettraffic than necessary though. That's why I fixed this differently (see latest changeset).
I'll still need to check your changes in p_mobj.cpp.
BTW: I'm very happy to see that you and Dusk are so actively contributing source changes :). Greatly appreciated. |
|
|
|
(0002664)
|
|
TIHan
|
|
2012-02-22 01:12
|
|
No problem.
I see how you fixed it differently and it makes sense. Perhaps I'm afraid of adding extra parameters like that elsewhere if it hurts backporting zdoom stuff. We may need a discussion on what and what not to do.
Also in p_mobj, basically, at the end of the function P_ZMOVEMENT, you need to call an update on the actor to the client if the actor bounced. Dusk identified that there was something going on with the z momentum, that is where it was. There is some copy and pasted code there; not sure if I'm allowed to make a separate function to check if something bounced - again worried about hurting zdoom backporting. |
|
|
|
(0002668)
|
|
Torr Samaho
|
2012-02-22 12:50
(edited on: 2012-02-22 12:51) |
|
> We may need a discussion on what and what not to do.
Sure. And I totally agree that staying compatible with ZDoom is a very important goal. In particular, changes to ZDoom code should only be done if really necessary. Unfortunately saving nettraffic is also an important goal and for this fix a compromise was necessary. Since Skulltag already had altered the signature of P_SpawnPlayerMissile though, adding another argument there didn't make backporting stuff there any more difficult.
Avoiding copy and paste is also very important, i.e. the chunk of code you copied in p_mobj should be avoided. I still didn't have time to look at the effects of the change, so I can't really say more on this yet. One possible way to fix this would be to define a bool at the beginning of the function, set that bool to true if the actor bounced and then call the server code where you call it by only checking the bool instead of replicating all checks that were done before.
|
|
|
|
(0002669)
|
|
TIHan
|
|
2012-02-22 15:58
|
|
|
The original bounce checks are in P_XYMovement function, and I need the check to see if the actor bounced at the end of P_ZMovement function. Perhaps adding a bool to the AActor class, called, "bBounced", will get set to true if it bounced in P_XYMovement - thus bBouced will be used as a check at the end of P_ZMovement. I'm just thinking outloud here, but at least it reduces code duplication. |
|
|
|
|
|
Alright, I looked a bit closer into this and introduced a new net flag to handle this. Still a crutch, but it doesn't need any code duplication and is not invasive to ZDoom code. |
|
