All bot models replaced by player selected model

[volatilezzz]

Broken commit: 51b6ae414f4324e75cc5248e51803ea7fb0b4a09 Working commit: d90d628fda6fda861d63ddbeaa55882081ad9530

MSVC v143 (Visual Studio 2022) with Windows 10 SDK 10.0.20348.0, x64 build with Vulkan renderer.

[ensiform]

Nothing in the former should be related here.

[volatilezzz]

I don't know the codebase at all, so I can't make the same judgement. I've tried several previous commits as well, but it's only 51b6ae414f4324e75cc5248e51803ea7fb0b4a09 that doesn't work.

It would be nice to get the bug reproduced by someone else at least.

[ensiform]

Can you show video of it? What mod is running?

[volatilezzz]

There are no mods, and the config has been deleted so that the default one is generated. I've changed the player model to Bones so that it's easier to notice the bots. The map features Major, Doom and Sorlag.

EDIT: Annotated the screenshots.

51b6ae4:

d90d628:

[ensiform]

Are you by chance experiencing deferred loading of the other models? Are you using the baseq3a pak8a or pure vanilla? This behavior is controlled by the client cgame.qvm not the engine so this seems red herring or some other change is extremely messed up.

[The-Gig]

Seems like something related to cg_deferPlayers <0 or 1>: When it's set to 1 (the default), you may need to be killed or to push TAB key in order to view all player models updated correctly (rationale is that since loading character models can cause an hitch, doing that when you die shouldn't affect you too much). And/Or with cg_forcemodel <0 or 1>: When it's set to 1 (default is 0), all player models look the same as yours in non-team-based modes, and as Sarge in team-based modes (rationale was to save some memory in low spec 1999 computers). At least in original baseq3, I haven't tried them in baseq3a... However, that's gamecode stuff, it sounds a bit strange that the engine broke it...

This said, I don't have the expertise to know what this commit you mentioned https://github.com/ec-/Quake3e/commit/51b6ae414f4324e75cc5248e51803ea7fb0b4a09 exactly does, so maybe it somehow breaks some phase of client update or communication between client and server? I don't know.

[volatilezzz]

Seems like something related to cg_deferPlayers <0 or 1>: When it's set to 1 (the default), you may need to be killed or to push TAB key in order to view all player models updated correctly (rationale is that since loading character models can cause an hitch, doing that when you die shouldn't affect you too much). And/Or with cg_forcemodel <0 or 1>: When it's set to 1 (default is 0), all player models look the same as yours in non-team-based modes, and as Sarge in team-based modes (rationale was to save some memory in low spec 1999 computers). At least in original baseq3, I haven't tried them in baseq3a... However, that's gamecode stuff, it sounds a bit strange that the engine broke it...

This said, I don't have the expertise to know what this commit you mentioned 51b6ae4 exactly does, so maybe it somehow breaks some phase of client update or communication between client and server? I don't know.

That's it! I've now set seta cg_deferPlayers "0" and the models are correct. I've never encountered this issue in the 25 years of the game :) Thank you for this information!

Regarding the version of the game files, they are vanilla.

Since this issue is now solved for me, I (or you) can close it. I'm not sure if this is something that can be improved in Quake3e, or if it's up to everyone to correctly set that variable.

In any case, thank you both for the help and the pleasant conversation. Cheers!

[ensiform]

There's nothing to change or fix on this end, the cvar default is 1 in cgame.qvm shipped with baseq3 vanilla. While it does seem odd that it "worked" before that patch I don't see how it has any kind of relation to what is occuring, you maybe had leftover cvar differences from a mod loaded and you don't remember or something but otherwise I can't see it being changed by that commit at all.

[volatilezzz]

I don't think I made a mistake, as I tested builds one after another with clean game files and the default config. The only thing that was changing was the executable. Well, the thing works now and I'm happy, so I'll be closing the issue. Thanks again for your time!

[ec-]

Recent changes fixes a few things:

• resets any pending wait during initial (- at filesystem startup) config loading
• properly hadles multiple wait commands in sequence e.g. echo 1; wait 125; echo 2; wait 125; echo 3
• makes wait command 1-frame precise
• corrects nested commands

So it may introduce some config compatibility issues (p.1 and p2. - most likely)

[NoiseByNorthwest]

@volatilezzz same issue for me. Same identified commit, and commenting out this line "fixes" it. So it has something to do with the behavior change around "wait" command handling which causes in this case the "addbot" commands to be executed later. I also confirm that seta cg_deferPlayers "0" fixes it.

[The-Gig]

@volatilezzz same issue for me. Same identified commit, and commenting out this line "fixes" it. So it has something to do with the behavior change around "wait" command handling which causes in this case the "addbot" commands to be executed later. I also confirm that seta cg_deferPlayers "0" fixes it.

Excuse me, I don't understand. What's the difference in behavior before/after that commit? I know cg_deferplayers 1 updates the player models when the score table is shown (then you die or when you press TAB key), in order to avoid you "hitches" during actual gameplay. So you may see others look like you for a while, but that's intended.

[ensiform]

I think because of the wait processing change it delays them loading at start of match.

[NoiseByNorthwest]

So you may see others look like you for a while, bu that's intended.

But it was not the case before that commit. The difference in behavior may be that bots added before start are not "starting players" anymore but rather "new players" due to the now delayed "addbot" commands.

[The-Gig]

Thank you, now I understand.