Use relative paths for files to make configuration easier

[kus]

Update Config.cs to utilise Server.GameDirectory so it's not required to hardcode the absolute paths to everything as a fallback. You can still use an absolute path, which it checks first, if that check fails it checks for a relative path so it should be backwards compatible.

This makes the plugin a lot easier to install and use across environments setup in different ways.

When I integrated your plugin into my Modded CS2 Repo all my Windows users had issues. I'm using this fix on my test Windows server and it works great now and with no modification from the default config.

Great work on the plugin by the way!

[nickj609]

Hey @kus, thanks for providing this code. I made a recent commit that should include this fix and will be testing it tomorrow. I will also be giving you credit in the release so be on the lookout!

Also, I see you have integrated the CS2-CustomVotes plugin pretty nicely in your build. However, I noticed that most of those changes you have to make manually to the JSON for the plugin. For example, when adding a new game mode or setting. My recent commit should address this by automatically registering votes for new game modes and game settings.

However, I am using a different naming convention for my settings, which have been adapted from an older version of your CS2 Modded Server. It is the following:

enable_settingname.cfg
disable_settingname.cfg

Although, I know not all settings are as easy as enable/disable so there are some limitations, but that is where I think the CS2-CustomVotes JSON file might be a perfect fit. Feel free to let me know if you have any other thoughts!

[kus]

No problem @nickj609 your work is a godsend for servers that have multiple mods.

Yes my integration on CS2-CustomVotes is a manual process - definately welcome the update if you automate it and I will update my repo.

One thing to look out, which doesn't seem to be an issue from my integration, but would be good to check on your end is !prefire to change to prefire is the same command that the OpenPrefirePrac uses to open up the menu when in the mod.

I will have a look through your enable_settingname.cfg logic to see if it makes sense for my server. Also if you have a good idea how it should work feel free to do a PR on my repo and I'll accept it.

One request I have, is when you push a new build can you please do a release with the version number. That way I know it's something you have tested and I should update to. I have a script that checks all the plugins I use and flags if I need to do any updates.

[nickj609]

Hey @kus , thanks for the tip! I am fairly positive based on your statement that my plugin will conflict with !prefire, in which case I could build some logic around it haha.

You can see a list of my enable_settingname config files in the /lib/csgo/cfg folder in my repo for reference as well. Right now, I am using enable/disable so that I can differentiate between them and have separate menus for enabling settings and disabling settings. I could however create a third bucket called misc for miscellaneous settings that do not follow that same trend.

Regarding your statement of releases, that is exactly my intentions. I was planning on creating separate branches for each future release and then merging them into main and creating an official release. However, I was occasionally commiting changes to main and not realizing it and had to do some data recovery/manual merging resulting in the main branch being out of sync with the latest releases.

I currently recommend using the latest release (v1.0.3) until I can thoroughly test my latest commits to main, in which case a new release (v1.0.4) will be created. Be on the lookout!