Corrupt merge of mvds about qwdtools HOT 9 OPEN

Hi @dsvensson,

Please add those demos. they will help for sure...

from qwdtools.

I noticed now that one of the demos is not playing back correctly when viewed separately. Playing back in slomo, and the -fps parameter didn't help. Might be that one is a regular demo recording, and the other one is a qizmo recording. Maybe that's what causes flag carrier to drift out of sync.

I just googled some random file service, they should be available here for 7 days,

https://easyupload.io/m/1vxj05

from qwdtools.

@tcsabina did you manage to grab it or do I need to find some other place for it?

from qwdtools.

Hi @dsvensson ,

Sorry, I completely forgot about this issue, and the demo you have saved. Could you add it again somewhere please?
Or just zip it, and you should be able to attach it to the issue. Just drag and drop to the issue text.

Sorry for the inconvenience.
Toma

from qwdtools.

Nice, never seen that feature in GH before, here you go. iirc it's the final3.qwd that becomes slowed down when converting to mvd (before merge). Haven't measured exactly the ratio, but it can bee seen via show_speed 1. Might be that one of the demo sets (only one of 4 from 2x pov included here) is recorded with a proxy and one is not.

demos.zip

from qwdtools.

perfect!

from qwdtools.

Interesting. Both demos use the Pure CTF statusbar which shows the game clock. Comparing that game clock to wallclock shows that 1 minute of game clock is more than 1 minute wall clock in both demos - before converting. final3.qwd is about 70 seconds per 60 seconds game clock, and first3.qwd is 75 seconds per 60 seconds game clock modulo sloppy reactivity. Any idea why that might be?

from qwdtools.

No longer able to reproduce the slowdowns in ezquake master, still some slowdowns in FTE. This is however already in the qwd's. What is true is that merging multiple POV's seems to have trouble clearing flag carrier status. first3.qwd and first3.mvd - [c]space pov are both fine, but when combining with final3, and jumping to space pov at for example demo_jump 400 there's a flag carrier that's not a flag carrier. 1-Mesk should not have the red flag at that point, 1-Capten should. At 480 seconds from [c]space POV there are multiple spawns with flag status set after each other.

Comparing time with centerprint status bar written into the demo and wallclock produces the following result, when considering final3.qwd/first3.qwd, so at least not an issue here, unless the drift seen in FTE is related, but maybe that's how FTE behaves in other demos as well, haven't had time to check yet.

https://gist.github.com/dsvensson/a7d11ede880130bee40a2ccda145131c

Going to have a look what mvdparser says about the converted mvd's, but they ofc contained unimplemented messages, the yak shaving continues 🔪.

from qwdtools.

Ok, mvdparser shines a clear light on the problem, missing messages, and duplicated messages, inspection of first1.mvd, final3.mvd - both correct, and the combined mvd here:

https://gist.github.com/dsvensson/b1612eee74e95cec2832fbbcb5c15eed

It's very weird that the first 7 takes+drops for the observed player are lost, but it would be interesting to see if the merge algorithm works correctly if the drift was eliminated.

from qwdtools.