Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

is_cstrike_dir is never set for checkpoint go to #525

Closed
khanghugo opened this issue Apr 19, 2024 · 1 comment · Fixed by #526
Closed

is_cstrike_dir is never set for checkpoint go to #525

khanghugo opened this issue Apr 19, 2024 · 1 comment · Fixed by #526

Comments

@khanghugo
Copy link
Contributor

// for CS 1.6 stamina reset
if (hw.is_cstrike_dir)
pl->v.fuser2 = 0;

The variable is only set when loading a TAS file, not upon starting the game or starting a map.

is_cstrike_dir = cl.DoesGameDirMatch("cstrike") || cl.DoesGameDirMatch("czero");

Maybe we should have a way to know the current game dir as soon as the game starts so stuffs like this don't scatter around.

@SmileyAG
Copy link
Collaborator

SmileyAG commented May 7, 2024

I would say that in general the game directory search code is poorly designed in terms of performance and this is definitely my fault (but at the time I did it I didn't really think about optimization at all), since at the moment every time the function is called to get the game directory, a large number of different operations take place (allocating and freeing of 1024 bytes for local variable [max game directory length in engine code is 260, so that 1024 size is even incorrect], strlen / while loops / strncpy from COM_FileBase to convert from absolute to relative path, and we also convert it all to lowercase at the end) as a result of which we will have the same result throughout the entire process (since the initial data, i.e. the game directory can only change when restarting or exiting the game, the rest of the time it will be the same)

This means that we need initialize only once, store the result globally in memory, and simply return that for all subsequent calls to that function

This also includes setting boolean variables that serve to identify some of the games; we can set them once in the same function in which we initialize the process of finding and processing the game directory and use this

This is what I did in #516 request:
https://github.com/SmileyAG/BunnymodXT/blob/b1082da20599e1da86e1daeb34537c49fa8cf02b/BunnymodXT/modules/ClientDLL.cpp#L1183-L1211
https://github.com/SmileyAG/BunnymodXT/blob/b1082da20599e1da86e1daeb34537c49fa8cf02b/BunnymodXT/helper_functions.hpp#L34-L52
https://github.com/SmileyAG/BunnymodXT/blob/b1082da20599e1da86e1daeb34537c49fa8cf02b/BunnymodXT/helper_functions.cpp#L268-L284
https://github.com/SmileyAG/BunnymodXT/blob/b1082da20599e1da86e1daeb34537c49fa8cf02b/BunnymodXT/helper_functions.cpp#L485-L512

Another question is that it is not particularly clear where exactly it is best to call in the game functions, because we prefer to call immediately after the game directory has already been initialized, preferably this should use the hooks we already have (it would great if it would be exported ones such as HUD_Init)
So, as a temporary and alternative solution, macros were placed to initialize the game directory in those places where they are used if the directory has not yet been initialized

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants