ZDoom

Matt wrote:Knox mentioned a desync when bleeding but I have not been able to reproduce it.

Well uh, seems it's linked to mostly bleeding, pain and death atm.

Adding to that, we just tried taking down a cybie with a plasma rifle and a vulcan, after 4 attempts I decided to switch on godmode and hold a chainsaw to the guy's junk for a good 5 minutes before the lag of the missiles exploding in my face decided to crash the game.
Eventually I ended up unloading an entire cell into the twat before he decided to keel over.

What's up with the shield? How does it work? Any hints and insights ? I'd rather not look at the code too much.

I am aware of the godmode crash and have no idea how to fix it. I've seen this problem with imps previously (not the current Decorate ones but each of several aborted attempts to scriptify them). It seems to be a segfault related to monster AI and I don't know if I even can fix it on the mod side (since I don't even know what causes it besides "a lot of shit going on with a monster present").

bleeding, pain and death... when Knox was testing they weren't able to replicate the desync with nobleed on, but there might be something else going on in the player's damagemobj() that that cvar doesn't disable. I'll take a look at that part of the code again.
(I had not been able to replicate this desync at all when Knox reported it)

The shield is a constantly regenerating 2000hp that blocks the first ~500hp of damage on any single attack until it runs out.
The cyberdemon is also inherently resistant to radius damage, which includes grenades and plasma.

Your most efficient options therefore are the Brontornis and HEAT, though the Vulcanette tends to do a fairly good job.

Matt wrote:(I had not been able to replicate this desync at all when Knox reported it)

Hmm, was that on LAN or over the internet? Any specific netmode, network settings or dup settings used?

It really shouldn't make any difference as far as I'm aware - if it were actual data corruption in the network it would be happening with everything not just HD.

The only thing that can be going wrong is that some clients are processing things differently before they are reflected in the playsim.


Is there a prior release where this desync does not happen?

Matt wrote:It really shouldn't make any difference as far as I'm aware - if it were actual data corruption in the network it would be happening with everything not just HD.

The only thing that can be going wrong is that some clients are processing things differently before they are reflected in the playsim.


Is there a prior release where this desync does not happen?

Honestly, the last version I had of this game that we still played together with no problems was the version of 2015-11-16 according to the attached readme.

If you want I can set up a closed network and skim through the main branches as to pinpoint a more exact version.


By the way, I just noticed that the mancubi don't appear to be able to shoot upwards, only straight forward and down.

Before I even look at the mancubi, which version are you using? I had specifically fixed this when I scriptified them...

EDIT: CheckLiquidTexture() might theoretically cause a desync if two players have different wads loaded that have different flats defined. This would explain why I'm completely unable to replicate this desync, since if I run 2 instances on the same computer I can't help but have both read from the same IWAD. What are the byte sizes of each player's DOOM2.WAD?

Matt wrote:Before I even look at the mancubi, which version are you using? I had specifically fixed this when I scriptified them...

Latest available.

Matt wrote:What are the byte sizes of each player's DOOM2.WAD?

Identical, the files come prepackaged from an easy to extract pack for our lan parties.
I like to make sure every single file is identical so nobody can change anything or cause any desyncs.
Yes, I'm that boring.

Our current file size is 14.604.584 bytes, from the original doom 2's latest installation disk, circa the beginning of 1995. Not to be confused with the windows 95 version.

Mancubi are fine, they just can't aim quite as high as might sometimes be needed for shots to connect at steeper angles. I will address that in due course.

In the meantime, I can't get the bleeding desync even with one instance loading Plutonia and the other loading Doom2...

Matt wrote:Mancubi are fine, they just can't aim quite as high as might sometimes be needed for shots to connect at steeper angles. I will address that in due course.

In the meantime, I can't get the bleeding desync even with one instance loading Plutonia and the other loading Doom2...

Have you tried hosting it on a virtual machine or even a laptop rather than the same instances on the same computer?


Just simulated a lan match, tried netmode 0/1, extratic 0/1, 3 movementspeed 0/1... nothing,

Most of the times it seems it takes place straight after the player dies.

edit
Okay, so I can definitely confirm that the desync happens when the player is bleeding, death is just a certain desync if bleeding is on.


Edit 2:
After setting ticbalance to 1 and extratic to 2, the desync on death seems to have been phased out. delayed, or rather randomized than certain.

Test case:
Standard settings- Penetration 0/1 - extratic 0/1/2 - ticbalance 0/1 - Dup 1- - 3speed 0/1 - Bleeding 0


Player 1 - stationary (AFK)
Player 2 - Sprinting in circles until loss of consciousness
Result: Desync after death towards Player 1, player 2 still registers player 1. Desync autosolves after respawn, does not reoccur.

Player 1 - Shoots player 2, actively controlling.
Player 2 - Sprinting in circles until loss of consciousness
Result: No desync.


Bleeding 1
Player 1 -All instances
Player 2 - All instances
Result: Player 1/2 takes damage, game is desynced after a few blooddrops. No direct relation to level of bloodloss or health, wether the player is running or standing still, being shot by friendly or enemies.

Edit 2:
After setting ticbalance to 1 and extratic to 2, the desync on death seems to have been phased out.

Does it affect the bleeding desync?

Matt wrote:

Edit 2:
After setting ticbalance to 1 and extratic to 2, the desync on death seems to have been phased out.

Does it affect the bleeding desync?

See post.

Strange thing is, it doesn't affect 2 instances on one (non virtual) machine.

Edit:

Here's something I noticed.
1 host, 1 simulated player (Same PC), 1 client on LAN network

Player 1 shoots player 2. player 3- Client Desynchronizes when bleeding has been going for a while.

Player 1 appears dead to client 3, but player 1 and player 2 are both still alive to eachother.

This would make it seem as if a different client, with a different set of hardware, has calculated -something- differently.
Perhaps this is due to the use of random integers/floats/doubles? Something else? Simply the CPU clock speed?

Well met, Vaecrius.

After having played Hideous Destructor on and off for a couple of years now, I felt the need to tell you that I consider it to be the best DooM gameplay modification out there. I've played it mostly on my own, but I had a E1 co-op session last summer which was really fun. I enjoy the attention to detail and how well thought out everything is - even though some parts are hideous (as in ugly). The videos by Knox and Co. are also fun to watch.

No bugs submitted - I thought you might need a break from that just this once!

Thanks, Olroda!


David:

This would make it seem as if a different client, with a different set of hardware, has calculated -something- differently.
Perhaps this is due to the use of random integers/floats/doubles? Something else? Simply the CPU clock speed?

This might be it! (notwithstanding the potential other problem you mentioned in your PM)

I will go through some of these things and try to keep the ints and doubles consistent as they may be treated differently. Seems unlikely since I can't be the only modder who gets sloppy with this stuff, but it seems as likely as anything else.

Alright, latest github release fixed all the desync issues, did a clean install of the latest gzdoom (for some reason my version was an older incarnation of 3.2.5???). Bleeding works online as far as I can tell, now I'll just get a control group to test it on squad based coop.

As per usual, amazingly fast work. I'm perplexed.


Edit:
Just cleared a run of the first 5 maps of doom 2 with HD on and all the settings cranked, no issues whatsoever, smooth gameplay, nothing out of the ordinary.

Only things of note:
It seems that burning (and possibly bleeding) persists after the player has respawned.
For some reason, Coop weapons and enemies seem to spawn, but I doubt this has anything to do with HD, and is more a GZDoom problem.
Sprinting too much will now cause the player to shake and scream in pain rather than the usual silent damage.

Coop weapons and enemies will always spawn in a coop game, there's no way around it that I'm aware of.

I'll take a look at the other things tonight or tomorrow.


And it turns out 2 different builds might cause a desync, depending on the specific compiler. It's probably much more noticeable in HD than other mods or vanilla because of all the frandom() calls.


EDIT:

Sprinting too much will now cause the player to shake and scream in pain rather than the usual silent damage.

Do you mean once, or constantly? It should be:

Sprint until you reach the abrupt hard limit
A_Pain
Can't sprint for a few seconds