|
Notes |
|
|
|
This should fix the issue. Unfortunately it required a change in some very basic client side code. Let's hope that it doesn't break anything else. I only tested this in thing_z_misprediction_test_01.wad though.
|
|
|
|
|
* The chaingun still respawns into the wrong position. But this also happens offline and in GZDoom 323. If you reconnect, it corrects itself. Most servers have sv_weaponstay set to 1 anyway.
* I noticed some issues in KDiZD. It seems that the bug in 0000479: Thing Z-height misprediction after map resets online is back. The items are desynced both before and after map resets. But they aren't physically desynced. You can still pick up the battery in KDiZD without cheats. |
|
|
|
|
|
Some items are physically desynced. I noticed it in Z1M8. There are some SOLID barrels that you can jump on. The movement will start to lag on some of the barrels. |
|
|
|
|
Looks like the fix does more harm than good, so I removed it. Can you check if KDiZD works properly again in this build?
> The chaingun still respawns into the wrong position. But this also happens offline and in GZDoom 323.
This sounds like there is an underlying ZDoom problem that needs to be fixed (or at least understood) first. I'm not even sure if the behavior of items that are exactly on a linedef is defined, i.e. in which of the two adjacent sectors is the item supposed to be? |
|
|
|
(0001867)
|
|
unknownna
|
2011-07-10 23:01
(edited on: 2011-07-11 02:07) |
|
> Can you check if KDiZD works properly again in this build?
Some of the barrels are still desynced (former behavior), but it seems to work properly now.
> This sounds like there is an underlying ZDoom problem that needs to be fixed (or at least understood) first. I'm not even sure if the behavior of items that are exactly on a linedef is defined, i.e. in which of the two adjacent sectors is the item supposed to be?
In the example WAD, the thing's map z-position is 16. If you flip the linedef, the z-position changes to 0.
Offline:
* When the z-position is 16, the thing uses the higher floor value as its base.
* When the z-position is 0, the thing uses the higher floor value as its base.
Online:
* When the z-position is 16, the thing uses the lower floor value as its base.
* When the z-position is 0, the thing uses the higher floor value as its base.
> Looks like the fix does more harm than good, so I removed it.
I understand, but don't underestimate the importance of having this fixed. There's a classic duel map in Duel32 (DWELLER 2: MAP11) where you can see this bug. According to the duelers that I've spoken with, it would be great to have this issue resolved before 98e.
|
|
|
|
|
First let me say that as far as I can say the only difference between the online and offline behavior is where the client displays the weapon. The actual position on the server should be the same online and offline. Actually, the client even spawns the weapon at the correct position, but it thinks that it is in the lower sector and thus on the client the weapon falls down to the lower sector's height.
Furthermore, the offline behavior for the initial spawn and respawning is different even in ZDoom and I'm pretty sure that this ZDoom problem also causes the client side display problem. So it's not really a good idea to find a solution for the client side display problem without resolving the ZDoom issue first.
> I understand, but don't underestimate the importance of having this fixed.
Well, isn't this broken since forever? |
|
|
|
|
> First let me say that as far as I can say the only difference between the online and offline behavior is where the client displays the weapon.
Exactly. Depending on which z-position the thing uses, the thing is displayed either on the higher floor, or on the lower floor.
> Well, isn't this broken since forever?
Probably. FYI, it works as expected online in ZDaemon. |
|
|
|
|
> The chaingun still respawns into the wrong position. But this also happens offline and in GZDoom 323.
Can somebody check if this also happens in the latest ZDoom version and if so, make a bug report over there? |
|
|
|
(0001874)
|
|
unknownna
|
2011-07-10 23:53
(edited on: 2012-04-08 05:57) |
|
> Can somebody check if this also happens in the latest ZDoom version
* The chaingun doesn't respawn into the floor in ZDaemon 1.08.08b.
* The chaingun doesn't respawn into the floor in Odamex 0.5.3.
* The chaingun respawns into the floor in GZDoom 323.
* The chaingun respawns into the floor in ZDoom 2.5.0.
* The chaingun respawns into the floor in ZDoom SVN build 3263.
* The chaingun doesn't respawn into the floor in Chocolate Doom 1.6.0.
|
|
|
|
|
|
|
|
|
|
ZDoom fixed this in revision 3484. Unfortunately, even with the fix (just backported it to test), the item is still at the wrong position for newly connecting clients (actually it is spawned at the correct position but then falls down). I'll investigate this further. |
|
|
|
(0002912)
|
|
TIHan
|
|
2012-03-27 02:30
|
|
|
You can also notice this in Doom 2 map01 at the very beginning, the right zombieman is a little in the ground. I remember trying to do this, I sent the floorz over - which it is almost correct! Sadly, it was still off a bit. Hope this helps though. |
|
|
|
(0002913)
|
|
Torr Samaho
|
2012-03-27 02:33
(edited on: 2012-03-27 02:57) |
|
I think I found a way to fix this, but have no idea if it breaks anything else. Would be nice if somebody can test this binary and see if things spawn / respawn at the proper position. In particular, it's interesting if there are any problems with 3D floors.
EDIT: The change I made doesn't seem to have any effect on the Zombieman in Doom 2 MAP01.
|
|
|
|
(0002915)
|
|
TIHan
|
|
2012-03-27 05:33
|
|
> The change I made doesn't seem to have any effect on the Zombieman in Doom 2 MAP01.
Darn. Do you think it is a similar issue? The zombieman does sink into the ground near the edge of that linedef..
Also, I haven't noticed anything unusual with your binary, yet. I'll give you another update on it soon. |
|
|
|
|
> Would be nice if somebody can test this binary and see if things spawn / respawn at the proper position.
I just did a quick test with this and can tell that the issues in KDiZD are back. However, this time the pre- and post-map reset heights are consistent with one another. It's only a visual desync. But the example WAD seems to be working as intended now.
> The change I made doesn't seem to have any effect on the Zombieman in Doom 2 MAP01
It's probably a ZDoom issue since the zombieman respawns into the floor offline if sv_monsterrespawn is 1. |
|
|
|
|
|
Since there is still a problem with the zombieman in ZDoom, I reverted the changes for the time being and wait for ZDoom to fix this. |
|
|
|
|
|
|
|
|
|
Hmm, does anybody know whether he intentionally commented out pr_nightmarerespawn? |
|
|
|
|
|
|
|
|
|
I think I managed to fix the thing_z_misprediction_test_01.wad issues and the initial Zombieman spawn position now (Randy's monster respawn fix is not in yet, so don't test respawning monsters yet). Here is a new testing binary. I didn't test the KDiZD issues. If anything is broken there (or elsewhere), can you please make a minimal example wad? |
|
|
|
|
|
|
|
(0003112)
|
|
Torr Samaho
|
2012-04-02 11:30
(edited on: 2012-04-02 12:52) |
|
3DFloorDesyncTest.wad now also seems to be broken offline, so I guess this is a ZDoom bug. Can you check the latest ZDoom version?
> Does A_Respawn also use Doom's buggy PointOnSide behavior? It seems that it doesn't, which in turn causes it to desync online when the ExplosiveBarrel actors respawn if sv_barrelrespawn is 1.
A_Respawn works differently, you only get desyncs when server and client use different spawn methods.
EDIT: ItemRespawnDesynchTest2.wad seems to be consistently broken online and offline. So it's possibly the same problem.
EDIT2: I suspect that the nightmare monster respawning on 3D floors has the same problems in ZDoom as the items have (didn't test this though) and that this possibly needs to be fixed separately (like it needed two separate fixes in ZDoom before).
|
|
|
|
|
|
|
|
|
> I suspect that the nightmare monster respawning on 3D floors has the same problems in ZDoom as the items have (didn't test this though) and that this possibly needs to be fixed separately (like it needed two separate fixes in ZDoom before).
It seems that monsters on 3D floors don't respawn at all.
[3504] Monsters on 3D floors don't respawn at all |
|
|
|
|
|
There's also a new ST desync: Clients think that things fall through 3D floors. I noticed it in Zombie Horde. I created a new example WAD. It has 2 barrels. One of them (red barrel) uses A_Chase + Speed 0 to correct itself, but the other one (brown barrel) simply falls through the 3D floor locally. |
|
|
|
(0003116)
|
|
Torr Samaho
|
2012-04-02 23:28
(edited on: 2012-04-02 23:29) |
|
I'm pretty sure the zhbarrel_desync_test_01.wad problem is caused by the fact that I used ZDoom's 3D floor incompatible monster respawn fix to fix the spawn problems on the client. We'll have to wait for the ZDoom issues to fixed before we can continue to work on this.
BTW: A joint example wad that combines the different spawn problems in a single area would be very helpful to check all known issues at once.
|
|
|
|
|
All the bugs reported by unknownna are fixed by randy in zdoom.
affected revisions: 3509, 3510, 3514. |
|
|
|
|
|
Since all the fixes are separate let's try to fix this stuff step by step. This should hopefully fix the initially spawning positions and the respawning for items (not for monsters or barrels). |
|
|
|
|
> This should hopefully fix the initially spawning positions and the respawning for items (not for monsters or barrels).
* Items desync after "changemap" map changes online.
* It seems that if you pick up any items before a map reset, they'll desync. This also happens offline.
* If you pick up the health bonus in the new example WAD, it'll respawn into the wrong position. This also happens offline.
> A joint example wad that combines the different spawn problems in a single area would be very helpful to check all known issues at once.
I agree. I created a new example WAD.
BTW:'http://zdoom.org/Changelog/3513/files [^]'
* Make DF2_BARRELS_RESPAWN work in all game modes without the need for alwaysapplydmflags. |
|
|
|
(0003128)
|
|
Torr Samaho
|
2012-04-04 00:25
(edited on: 2012-04-04 00:27) |
|
> It seems that if you pick up any items before a map reset, they'll desync. This also happens offline.
What do you mean by desyncing offline? When I talk about desyncing I mean a situation where clients and server disagree on something, i.e. the position of a thing on client and server is different. Offline there is nobody to disagree with.
> If you pick up the health bonus in the new example WAD, it'll respawn into the wrong position. This also happens offline.
Can you test if this works in ZDoom?
|
|
|
|
(0003131)
|
|
unknownna
|
2012-04-04 01:35
(edited on: 2012-04-04 01:58) |
|
> What do you mean by desyncing offline? When I talk about desyncing I mean a situation where clients and server disagree on something, i.e. the position of a thing on client and server is different. Offline there is nobody to disagree with.
I should have been more clear. What I mean is that the things' initial spawn position changes after map resets if you pick them up just before the map reset takes place. It seems to happen if you destroy the barrels too. Monsters seem to be affected too.
> Can you test if this works in ZDoom?
I'll have to wait till a new SVN build is available for testing (FYI, it works fine in build 3504).
|
|
|
|
(0003132)
|
|
Edward-san
|
2012-04-04 10:07
(edited on: 2012-04-04 10:52) |
|
> If you pick up the health bonus in the new example WAD, it'll respawn into the wrong position. This also happens offline.
It's still not working in zdoom with latest svn. I'll report there.
[edit]Done.
|
|
|
|
|
> Done.
Thanks.
'http://zdoom.org/Changelog/3518/files [^]'
* Fixed: A_Respawn and P_NightmareRespawn() should not check for collision with world geometry. The initial spawn did not, so this can prevent respawns of things that were initially spawned if they happen to intersect a wall.
* Fixed: Don't respawn actors inside the floor.
* Fixed: The final calls to P_FindFloorCeiling() in P_NightmareRespawn() and A_RestoreSpecialPosition also need to pass true as the second parameter. (Because this parameter is onlyspawnpos, not onlymidtex.) |
|
|
|
|
|
Did somebody confirm that all the problems are really fixed in ZDoom now? I backported the fixes (except for A_Respawn, needs to be done later) and offline the invisibility sphere falls into the 3D floor after respawning. Can somebody check this in ZDoom? |
|
|
|
|
|
It happens also in zdoom. Reported there. |
|
|
|
|
'http://zdoom.org/Changelog/3542/files [^]'
* Added another flag to P_FindFloorCeiling() to get it to do its standard processing but without resetting the actor's sector. The 3D floor checks in P_NightmareRespawn() and A_RestoreSpecialPosition now use this.
* Fixed: P_NightmareRespawn() did its Z clamping before checking for 3D floors.
* Fixed: Respawning actors were not clamped to the ceiling. |
|
|
|
|
|
Found another problem in zdoom with that change. I posted it in the same thread. |
|
|
|
|
|
One wonders if Randy ever tested that example wad... |
|
|
|
|
> One wonders if Randy ever tested that example wad...
The example wad had too long respawn times so he used another example wad.
'http://zdoom.org/Changelog/3545/files [^]'
* Fixed: Do not interpolate from an actor's despawned position to its spawned position when it respawns.
* Use doubles instead of floats, as appropriate, in PIT_FindFloorCeiling().
* Fixed: The second call to P_FindFloorCeiling() in A_RestoreSpecialPosition and P_NightmareRespawn() must only consider 3D floors and midtexes.
Apparently there were some crashes related to the new changes.
'http://zdoom.org/Changelog/3543/files [^]'
* Fixed crash when teleporting. P_TeleportMove() must not pass FFCF_ONLYSPAWNPOS to P_GetFloorCeilingZ(). I got confused because its bool parameter's meaning had been the opposite of P_FindFloorCeiling()'s bool parameter before they got changed to flags. |
|
|
|
|
|
is it working the respawn for 3d midtextures? |
|
|
|
(0003187)
|
|
unknownna
|
2012-04-08 23:17
(edited on: 2012-04-08 23:33) |
|
> Is it working the respawn for 3d midtextures?
Not in SVN build 3542.
Edit:
It crashes in SVN build 3545.
|
|
|
|
|
|
Except for the A_Respawn changes (still need to work on this), I backported all the ZDoom z fixes up to revision 3547. I think there are still z problems with 3d midtextures. Here is a new binary. Ignore the barrel problems, that's because the A_Respawn changes are still missing. |
|
|
|
|
> Here is a new binary.
It seems to be working as intended. The changemap and map reset desyncs are gone it seems.
> I think there are still z problems with 3d midtextures.
You're right. I created a new bug report. |
|
|
|
(0003195)
|
|
unknownna
|
2012-04-10 03:43
(edited on: 2012-04-10 04:25) |
|
|
|
|
(0003200)
|
|
Torr Samaho
|
2012-04-11 01:23
(edited on: 2012-04-11 01:24) |
|
Unfortunately we are reaching the limits of what is feasible to backport. Some of the previous patches were already very cumbersome to backport, but 3548 is more or less infeasible. It is intertwined with 3490 which itself is intertwined with the merging of ZDoom's polyobj branch into the main trunk. Since I really don't want to backport the polyobj branch to 98e, I consider removing all the recent z-fix backports and postponing all of this till 98e is finished.
|
|
|
|
|
> Since I really don't want to backport the polyobj branch to 98e, I consider removing all the recent z-fix backports and postponing all of this till 98e is finished.
Fair enough, we can postpone this, but don't remove the current fixes. They don't break anything and the chaingun respawn problem is gone. So things look more polished and professional now compared to 98d. We can consider complex spawn/respawn situations on 3D floors/midtextures to be unsupported in ST for the time being since they weren't supported in ZDoom even until now.
As for the barrel issues: The most important thing is to avoid physical desyncs since they screw up the client prediction in terms of player movement.
BTW: I found some new issues in ZDoom with the latest example wad. I created a new bug report. |
|
|
|
|
> Fair enough, we can postpone this, but don't remove the current fixes. They don't break anything and the chaingun respawn problem is gone.
Well, they don't seem to break anything for now, but I'm not too sure if they break things we don't know yet. The necessary client side change is in a very basic function and can affect every spawn the server instructs the clients to do. Not to mention the effects all of Randy's fixes may have. How thoroughly did you test this binary? |
|
|
|
(0003216)
|
|
unknownna
|
2012-04-12 00:33
(edited on: 2012-04-13 00:16) |
|
> How thoroughly did you test this binary?
I tested it with the example wad, Duel32, KDiZD, IDL2012, AOW2 (found a separate weapon issue), WhoDunIt (the client crashed after a map change, but I couldn't reproduce the crash) and Zombie Horde.
|
|
|
|
|
'http://www.zdoom.org/Changelog/3562/files [^]'
* In P_SpawnMapThing(), pass the same flags to P_FindFloorCeiling() as the respawn functions do.
* Rename FFCF_3DMIDTEXRESTRICT to FF_3DRESTRICT and make it work with 3D floors too. |
|
|
|
|
The example WAD is now broken in the latest beta build. The zombieman, chaingun and barrel actors spawn into the wrong positions on the client online. And they also respawn incorrectly, but when they respawn, the client and server are in sync with one another. And this bug has returned as well:
Quote from unknownna
What I mean is that the things' initial spawn position changes after map resets if you pick them up just before the map reset takes place. It seems to happen if you destroy the barrels too. Monsters seem to be affected too.
It worked fine in 120409-1130M. The only thing that didn't work properly there was the barrel respawn. The client didn't respawn the barrels with the same z height as the server.
|
|
|
|
|
|
The partial fixes I made are not included in the new build (they are in the repository under a bookmark, but I'm still hesitant to include them since they may have far reaching consequences). |
|
|
|
(0015072)
|
|
Edward-san
|
2016-06-11 15:44
(edited on: 2016-06-11 17:02) |
|
|
|
|
|
|
|
|
|
That build fixed an issue online where items too close to a wall would float in the sky as noted here: 'http://zandronum.com/tracker/view.php?id=2753 [^]'
I noticed this bug on map02 online and the build did fix it. There's still a few more things needing testing though. |
|
|
|
|
Alright, going off of the example wad, I used the above build.
*Everything spawned at the correct height when the map first loads.
*Using the switch to reset the map correctly spawned everything at the right height.
*Everything spawned correctly through changemap and survival countdown.
*With itemrespawn on and weaponstay off, the chainguns, health bonus and sphere respawned at the correct z-height.
*Actor heights were correct, I could jump over and stand on various actors.
However,
The only issue was the barrels. After setting them to respawn, some would spawn and fall to the ground. Here are the only instances:
'http://i.imgur.com/jRQFUwE.png [^]'
'http://i.imgur.com/CKN2cES.png [^]'
I haven't taken a look at the testmap in Doombuilder, but by looks of the screenshots, the barrels have problems spawning on or too close to ledges regardless if the ledge is a 3D floor or not. |
|
|
|
|
|
Once, the barrels are fixed, it is safe to bet that all issues related to Z-Height would be resolved. |
|
|
|
(0015474)
|
|
Edward-san
|
2016-08-18 09:03
(edited on: 2016-08-18 09:04) |
|
Urgh, the barrel respawn is handled quite differently by zandronum online. The fix requires a bit of rewrite..
p.s. can you make a new ticket with the barrel issue? That would help with organizing the needed work for the fix.
|
|
|
|
|
|
|
|
|
|
I attached two example wads from Zalewa's recent pull requests. |
|
|
|
|
|
|
|
(0017752)
|
|
Ru5tK1ng
|
2017-05-23 04:12
(edited on: 2017-05-23 04:14) |
|
I had tested the child tickets long ago and they were fine. However, I tried the most current versions of both example wads provided above and I found some weird z height handling.
In the following gallery, the 1st picture for each spot in the map is how the items first spawn when the map loads. The 2nd picture is after the floor changes height as designed in the map. The 3rd image is when the item respawns.
The chainguns are the randomspawner issue unknownna reported in this topic:'https://forum.zdoom.org/viewtopic.php?f=2&t=53861 [^]'
Gallery: Imgur Link
The question is, is this good enough? As Graf said, you can only do so much for something as screwy as these example wads before the positioning behavior gives up. Honestly, putting things that close and awkwardly placed to ledges is just bad mapping anyway. These instances were all the issues I found throughout the child tickets and test wads. I would call this ticket a day since unless someone else disagrees.
The barrels are their own separate issue/ticket btw.
|
|
|
|
|
Ahh, it seems after double checking as Torr suggested, I found out the highlighted issues are also different for other newly connected clients.
In the gallery:'http://imgur.com/a/HcJon [^]'
If client 1 hits the switches, it sees the 2nd placement for each spot. But newly connected clients see the 3rd placement for each spot after the switch press. I modified the lift heights and it seems client 1's placement is the correct one on the server while client 2's is wrong. |
|
Screenshot_Doom_20110426_043327.png (96,459) 2011-04-26 02:44
thingz_spawnrespawn_08.wad (55,698) 2012-04-10 08:12
