BUG: Illegible server message on map change with in-built MVDSV and cl_delay_packet

[paddern]

ezQuake version:
3.6-dev-alpha6 r6964~4fa83bcd, 64-bit win build; the bug is older though

Describe the bug
I use KTX locally with ezQuake's in-built MVDSV. Works great unless you set cl_delay_packet and try to change the map.

To Reproduce
Steps to reproduce the behavior:

1. gamedir ktx; exec port1.cfg; etc. (I can pack the cfgs, if needed)
2. set, e.g. cl_delay_packet 15
3. change map
4. results in error msg (screenshot)

Expected behavior
Map changes should be possible with cl_delay_packet set

Screenshots

Additional context
Doesn't happen with the new cl_delay_packet_target

[meag]

Can you confirm if this works for you in ezQuake/ktx 32-bit?

[paddern]

It happens in the 32-bit version as well.

[meag]

Does it happen every time? Can you confirm where you got the KTX dll from?

[paddern]

Yes, can reproduce it every time.

The builds are from https://builds.quakeworld.nu/ktx/

[meag]

Thanks - I can confirm that I can't reproduce it using builds in Visual Studio, haven't tried 64-bit KTX yet though.

The 32-bit version of KTX on that site is bugged and on my machine, goes into an infinite loop on bot maps due to floating point rounding - it was built on 1st September and the fix was applied in January but I'm not sure why that builds page hasn't updated.

Will try the 64-bit version tomorrow.

[meag]

Hi

Tried various versions of the client etc yesterday and couldn't make this happen unfortunately.

Can you send me your normal client config please, and also the mvdsv/ktx configs?

Thanks,

[paddern]

Config files: quake.zip

[meag]

Hi

Sorry, still can't reproduce this, using your config from startup and then executing the commands specified.

Is there anything else you can think of that I could try? This is directory you supplied with just the ktx .dll added.

• meag

[paddern]

This is the complete folder with the 64bit dll ktx.zip

I then just press F7, which is the bind for gamedir ktx; exec port1.cfg in my cfg, after I started the client.

The 32-bit version of KTX on that site is bugged and on my machine, goes into an infinite loop on bot maps due to floating point rounding - it was built on 1st September and the fix was applied in January but I'm not sure why that builds page hasn't updated.

Tried with with non-bot maps and the map change works for me then.

[meag]

[23:02]HangTime:i get this error sometimes as well
[23:03]HangTime:if it's causing others problems i'll maybe try and come up with steps to reproduce next time it happens
[23:03]HangTime:don't think i'm using delaypacket though
[23:04]HangTime:ok literally just had it
[23:04]HangTime:watching qtv stream then typed map dm3 in console
[23:06]HangTime:seems to happen every time

Might be related, might not

[meag]

@paddern "Tried with with non-bot maps and the map change works for me then." < you mean it works in 32-bit mode but not 64-bit, or in both?

[paddern]

No, works when I change to non-bot maps but crashes, if it is a bot-map. Architecture doesn't seem to matter. Might have something to do with bots then (k_fb_enabled 1 and k_fb_autoadd_limit 2 are set)?

[meag]

Woop it finally happened here...

And now I can't make it happen again :(

What worked for me (once):

gamedir paddernktx
exec port1
aerowalk
cl_delay_packet 10
povdmm4

:(

[meag]

Okay perhaps some progress at last - it happened again (seems much more random here though) and I managed to capture the packet, which is basically:

svc_print("meag suggests map ztndm4")
svc_print("Majority votes for mapchange.")
svc_print("\n")
svc_playerinfo
svc_playerinfo
svc_deltapacketentities
END OF PACKET

But I got that using badplace's demo/packet parser. ezQuake client has a read error somewhere in the middle of the svc_playerinfo messages. I'm thinking/suspecting maybe it has lost its record of which protocol extensions are enabled (by the server calling client functions directly when it is built-in) by the time the packet arrives, due to cl_delay_packet.

Will keep digging...

[meag]

Hi @paddern

Can you try the latest build and see if it's improved at all?

Thanks,
meag

[paddern]

No crashes for me with 3.6-dev-alpha7 r7028~e876f0f8 :)