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

fs_basegame and fs_forcegame default values #96

Closed
TomArrow opened this issue Jan 15, 2024 · 2 comments
Closed

fs_basegame and fs_forcegame default values #96

TomArrow opened this issue Jan 15, 2024 · 2 comments

Comments

@TomArrow
Copy link

I sorta understand why these are set to "EternalJK" by default for the client, but is there a reason to have these set that way by default on dedicated servers? Currently, to run a dedicated server with expected behavior with a mod, you have to run it from the commandline with +set fs_basegame whatever +set fs_forcegame whatever. Otherwise if the mod does any writing of files, they will go into the EternalJK subfolder instead of the whatever (mod name) folder. This can be quite a headache if you're not aware of it.

Also, I'm not sure if this is intended but fs_basegame overrides fs_game as well when it comes to file writing. This is because whichever folder is initialized last ends up being written into the global variable that controls where files are written and fs_basegame is initialized after fs_game. But maybe that's intentional.

Anyway, any reason not to #ifdef the cvar definitions and make dedicated servers have default/empty values so that servers behave normally and are interchangeable with the classic engine?

I'm asking because there might be a genuine reason not to change it that I don't know of. Otherwise I'd just make a PR.

@taysta
Copy link
Owner

taysta commented Jan 16, 2024

Yes, this should be disabled for the dedicated server engine, good point. It was set as fs_forcegame EternalJK to retain the previous behavior of fs_globalcfg when merging #52.

@taysta
Copy link
Owner

taysta commented Jan 17, 2024

This is closed by #98

@taysta taysta closed this as completed Jan 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants