ec- / Quake3e

Improved Quake III Arena engine

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

All bot models replaced by player selected model

volatilezzz opened this issue · comments

Broken commit: 51b6ae4
Working commit: d90d628

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

Nothing in the former should be related here.

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 51b6ae4 that doesn't work.

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

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

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:
51b6ae4

d90d628:
d90d628

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.

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.

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!

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.

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!

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)