Changes in maps vs demo desyncing

I've been wondering what kind of changes in a map can lead to demo desyncing. My intuition tells me that changes to the geometry of the map and different item placement (e.g. remove a medikit the player picked up in their playthrough) could potentially affect demos, while things like texture alignment changes should not.

That being said, back then when I used to record Duke Nukem 3D speedruns, the demo files were extremely sensitive to any kind of changes in the maps, to the point where removing sprites that were not even in the player's path would cause them to desync. I know that's a totally different engine, but I thought I might as well ask what's the case in Doom, just to be 100% sure.

Pretty much any change can do it, Doom's order of operations are highly susceptible to the butterfly effect. Even texture changes could as certain line actions rely on assigned texture height to determine their destination. Additionally making changes to a map will typically trigger a node rebuild in map editors, which will also trigger a dramatic desync even if the nodes are only slightly different or you use a different nodebuilder.

Floor texture changes won't as nothing ever refers to them but given the previously mentioned node builder issue you'd have to be surgical about the change.

38 minutes ago, Edward850 said:

Additionally making changes to a map will typically trigger a node rebuild in map editors, which will also trigger a dramatic desync even if the nodes are only slightly different or you use a different nodebuilder.

Reject table inaccuracies and blockmap misalignments are the more likely culprits in that case, but yes there are edge cases where the nodes themselves can cause desyncs.

33 minutes ago, Edward850 said:

Pretty much any change can do it, Doom's order of operations are highly susceptible to the butterfly effect. Even texture changes could as certain line actions rely on assigned texture height to determine their destination. Additionally making changes to a map will typically trigger a node rebuild in map editors, which will also trigger a dramatic desync even if the nodes are only slightly different or you use a different nodebuilder.

Floor texture changes won't as nothing ever refers to them but given the previously mentioned node builder issue you'd have to be surgical about the change.

Can confirm, I hand-modded the Icon of Sin to properly align his textures and ran a wr speedrun with it; they just so happened to shoot at the only wall that got altered and while they did beat the map, that was still enough to threw the random calls out of whack and a pain elemental appeared where it didn't when running the demo on the unmodded version of the map

Even if nothing happened to that bit of wall i suspect that it still would've changed due to the node rebuild stuff you mentioned

12 minutes ago, No-Man Baugh said:

and ran a wr speedrun with it

18 minutes ago, Dragonfly said:

 

 

Probably just means he played back the record demo with the modified map to check if it synced. Not doing a speedrun himself if that's what you assumed lol

I've gotten away with demos not desyncing once with

- lowering 1 sector which usually isnt touched by player or enemies (risky)

- retexturing walls and flat (modifying sidedefs offsets and flats in slade by directly editing the table is the safest since it wont cause any node rebuilds; if you do it in a normal editor like udb or slade's map editor then it will rebuild the node, and without the exact same node builder algorithm and settings it will probably change it and desync (forgot but actions using shortest lower texture might be affected by alignment))

- adding 2 new blocking sectors (very risky, but the demo i checked with didn't touch that area at all)

so note that changing the map might still sync a demo and desync on another.

apparently adding things specific to difficulties that arent the difficulty of the demo can still desync it. or coop/dm spawns (not sure) but rebuilding the nodes will likely desync stuff (d5da3).

I see... I guess then, given the nature of the changes I need to implement, demo desyncing would be rather difficult to avoid. It's not a big deal in any case. Thanks everyone for your input!

6 hours ago, Billa said:

Probably just means he played back the record demo with the modified map to check if it synced. Not doing a speedrun himself if that's what you assumed lol

...That makes a LOT more sense, thanks for clarifying!

A new competition: record a speedrun on an empty field in a single attempt and build a map that matches it xD

3 hours ago, Dimon12321 said:

A new competition: record a speedrun on an empty field in a single attempt and build a map that matches it xD

https://doomwiki.org/wiki/DemWAD01

On 5/22/2023 at 2:22 PM, Dimon12321 said:

A new competition: record a speedrun on an empty field in a single attempt and build a map that matches it xD

That reminds me of the little oddity I mentioned here:

Quote

As an aside, I noticed one really weird thing when doing this. If you play back hqr-4339 without loading hr.wad (i.e. so it starts playing in Doom2.wad and thus completely the wrong map), then the player actually exits map01 of Doom2. This happens about 6 minutes in. I wonder what the odds are against that, even considering that it is a small and simple map.

That in turn prompted this idea from Kristian Ronge (his demo file can be found here).