starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-25 22:25:59 +03:00

[GH-ISSUE #637] Whole buncha new stuff #508

New issue

Closed

opened 2026-02-27 02:01:58 +03:00 by kerem · 7 comments

kerem commented

2026-02-27 02:01:58 +03:00

Owner

Originally created by @jaredballou on GitHub (Jan 19, 2016).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/637

Hey guys,

So I've been hacking away on LGSM and came to a few realizations.

Almost all the individual game scripts are mostly duplicated.
There isn't a good way to update files from GitHub.
Keeping the server configs up to date is sort of a pain, there are a lot of variables that do the same thing in two games named different things.
I am making a big mess of my home directory.

So, what to do? Naturally, a major refactor of the whole script.

Gamedata: This is the meat of what I wanted to do, and it actually turned out pretty nice. Rather than have an individual script for every single game, there is only one main script. So, what I did was create a hierarchy of settings that LGSM reads to know what games it supports, and what the sane defaults are. So, to use the script download my Insurgency/insserver script, and name the actual file after whatever server you want to use (csgoserver, tf2server should probably work). What then happens is the script downloads the gamedata files tied to that server type from https://github.com/jaredballou/linuxgsm/tree/master/gamedata - so, insurgency pulls like this:

'''
insurgency -> _source -> [_parms_plusminus _halflife_shared] -> _default
'''

What happens is, the main script loads, but it pulls in the other configs in the tree, so since all Source games need "game" and "ip" for instance, we declare those in the hierarchy, and then we don't have to keep putting all the same values in every script. The inheritance is fairly smart, so if _source sets defaultmap to ctf_2fort but insurgency sets it to "buhriz_coop checkpoint", the higher priority value overwrites the lower one. There are some other little tricks in the parser to allow you to unset, blank out, or delete a value that you don't need. So if every Source game uses a parameter except one game, just set it in _source and unset it in the game that doesn't have it.

The gamedata files are still pretty rough, there are a lot of games that need some TLC to get the data files right. I also intend to have functions specific to each game in the gamedata files, right now I have fn_parms defined in them. There is also a fairly neat srcds parameter processor that tries to order the "-" parameters before the "+" parameters in a sane way. This will be a lot better down the road if you guys like it, I split up engines and games so that we can add support for additional mods and games pretty easily by just plugging into this architecture and setting the required values. Should make adding games a lot easier, I'm sure there are some residual things I missed like dependency downloads but I figured I'd show it off before I waste any more time.

If this is a go, I'll be looking at making a schema for the data from all the games, and standardize the names of the variables. I'll keep in deprecation links to transform old configs to new, having the names standard will make this a lot easier.

Every time the script version is updated, the cfg/servers/_default.cfg file is regenerated. I actually want to tie this to the updater, so when a gamedata file is updated the configs get rebuilt. I also want to put in something to put the key/values commented into the _common.cfg and instance configs, so that users can see what the defaults are and can uncomment and edit as they wish. For a few hours mucking about though, it works pretty well.

GitHub Updater: This is another neat one. The script has a value "git_update", set it to 1 and it will update from GitHub. It will actually use the GitHub API to find the latest commit hash. It caches that result for an hour right now, and then it will either download or use the existing manifest of SHA1 hashes for all files inside the repo at that commit. This means that any files you want to update will only update if the file itself has different content, no more need to delete all function files or blow them away blindly. It uses a binary jq-linux64 which lets me handle JSON on the command line, but I just did that because I was too lazy to make a sed expression to parse it. Bear in mind this will overwrite any local changes on a file that is being managed, while I was developing I bit myself a few times and overwrote local changes so that I'd have the right contents. Which is actually kind of cool, since it now enforces consistency on the files, but it ought to be tested and validated a lot more before we start having users do it.

File Organization: By default, the new insserver script creates an "lgsm" directory in the same path as the script file.This is where it stashes the logs, cfg, gamedata, temp files, settings parser files, and functions. I edited all the function files to respect the $lgsmdir variable as the "base" for these files, and updated the GitHub downloader to handle arbitrary paths fairly gracefully. You can skip this feature and do it the old way by just setting $lgsmdir=$rootdir to make it use the home directory as before. I was getting a lot of cruft in my home dir, and I like being able to cordon that stuff off. I didn't touch Steam or steamcmd since I know anything that gets moved will break some stuff, so I left that be for now.

Let me know what you guys think, looking forward to some feedback.

Originally created by @jaredballou on GitHub (Jan 19, 2016). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/637 Hey guys, So I've been hacking away on LGSM and came to a few realizations. 1. Almost all the individual game scripts are mostly duplicated. 2. There isn't a good way to update files from GitHub. 3. Keeping the server configs up to date is sort of a pain, there are a lot of variables that do the same thing in two games named different things. 4. I am making a big mess of my home directory. So, what to do? Naturally, a major refactor of the whole script. Gamedata: This is the meat of what I wanted to do, and it actually turned out pretty nice. Rather than have an individual script for every single game, there is only one main script. So, what I did was create a hierarchy of settings that LGSM reads to know what games it supports, and what the sane defaults are. So, to use the script download my Insurgency/insserver script, and name the actual file after whatever server you want to use (csgoserver, tf2server should probably work). What then happens is the script downloads the gamedata files tied to that server type from https://github.com/jaredballou/linuxgsm/tree/master/gamedata - so, insurgency pulls like this: ''' insurgency -> _source -> [_parms_plusminus _halflife_shared] -> _default ''' What happens is, the main script loads, but it pulls in the other configs in the tree, so since all Source games need "game" and "ip" for instance, we declare those in the hierarchy, and then we don't have to keep putting all the same values in every script. The inheritance is fairly smart, so if _source sets defaultmap to ctf_2fort but insurgency sets it to "buhriz_coop checkpoint", the higher priority value overwrites the lower one. There are some other little tricks in the parser to allow you to unset, blank out, or delete a value that you don't need. So if every Source game uses a parameter except one game, just set it in _source and unset it in the game that doesn't have it. The gamedata files are still pretty rough, there are a lot of games that need some TLC to get the data files right. I also intend to have functions specific to each game in the gamedata files, right now I have fn_parms defined in them. There is also a fairly neat srcds parameter processor that tries to order the "-" parameters before the "+" parameters in a sane way. This will be a lot better down the road if you guys like it, I split up engines and games so that we can add support for additional mods and games pretty easily by just plugging into this architecture and setting the required values. Should make adding games a lot easier, I'm sure there are some residual things I missed like dependency downloads but I figured I'd show it off before I waste any more time. If this is a go, I'll be looking at making a schema for the data from all the games, and standardize the names of the variables. I'll keep in deprecation links to transform old configs to new, having the names standard will make this a lot easier. Every time the script version is updated, the cfg/servers/_default.cfg file is regenerated. I actually want to tie this to the updater, so when a gamedata file is updated the configs get rebuilt. I also want to put in something to put the key/values commented into the _common.cfg and instance configs, so that users can see what the defaults are and can uncomment and edit as they wish. For a few hours mucking about though, it works pretty well. GitHub Updater: This is another neat one. The script has a value "git_update", set it to 1 and it will update from GitHub. It will actually use the GitHub API to find the latest commit hash. It caches that result for an hour right now, and then it will either download or use the existing manifest of SHA1 hashes for all files inside the repo at that commit. This means that any files you want to update will only update if the file itself has different content, no more need to delete all function files or blow them away blindly. It uses a binary jq-linux64 which lets me handle JSON on the command line, but I just did that because I was too lazy to make a sed expression to parse it. Bear in mind this will overwrite any local changes on a file that is being managed, while I was developing I bit myself a few times and overwrote local changes so that I'd have the right contents. Which is actually kind of cool, since it now enforces consistency on the files, but it ought to be tested and validated a lot more before we start having users do it. File Organization: By default, the new insserver script creates an "lgsm" directory in the same path as the script file.This is where it stashes the logs, cfg, gamedata, temp files, settings parser files, and functions. I edited all the function files to respect the $lgsmdir variable as the "base" for these files, and updated the GitHub downloader to handle arbitrary paths fairly gracefully. You can skip this feature and do it the old way by just setting $lgsmdir=$rootdir to make it use the home directory as before. I was getting a lot of cruft in my home dir, and I like being able to cordon that stuff off. I didn't touch Steam or steamcmd since I know anything that gets moved will break some stuff, so I left that be for now. Let me know what you guys think, looking forward to some feedback.

kerem

2026-02-27 02:01:58 +03:00

closed this issue
added the
type: feature
label

kerem commented

2026-02-27 02:01:59 +03:00

Author

Owner

@UltimateByte commented on GitHub (Jan 19, 2016):

I don't know what to say dude, your work is amazing, and i see no objection to your propositions.
@dgibbs64 What do you think about it ?

@UltimateByte commented on GitHub (Jan 19, 2016): I don't know what to say dude, your work is amazing, and i see no objection to your propositions. @dgibbs64 What do you think about it ?

kerem commented

2026-02-27 02:01:59 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Jan 20, 2016):

I agree @jaredballou work is amazing. The main issue for me is that is going to take some time and effort on my part to implement these ideas in to existing LGSM (which is a pain because they look really good).

The reasons for this are because I am an amateur developer some of these concepts are currently alien to me. Secondly my family and work commitments severely limit my time currently (hopefully will get more time soon). This is greatly frustrating for me as I love working on this more than anything.

There are many core changes to how LGSM works by the looks of it so I will be using your ideas to slowly implement improvements

So please bare with me while I process your ideas and sort out my other life commitments (damn you life getting in the way!)

@dgibbs64 commented on GitHub (Jan 20, 2016): I agree @jaredballou work is amazing. The main issue for me is that is going to take some time and effort on my part to implement these ideas in to existing LGSM (which is a pain because they look really good). The reasons for this are because I am an amateur developer some of these concepts are currently alien to me. Secondly my family and work commitments severely limit my time currently (hopefully will get more time soon). This is greatly frustrating for me as I love working on this more than anything. There are many core changes to how LGSM works by the looks of it so I will be using your ideas to slowly implement improvements So please bare with me while I process your ideas and sort out my other life commitments (damn you life getting in the way!)

kerem commented

2026-02-27 02:01:59 +03:00

Author

Owner

@jaredballou commented on GitHub (Jan 21, 2016):

So, I'd be happy to help merge it with the current codebase and send a PR your way. Really, if we could get people to try it out and make sure it actually works as advertised, I can start breaking out small pieces for ingestion into the core tool. I have finished the first crack at the gamedata, it is pretty close to what it needs to be.

I have another change that I committed a few minutes ago which makes the script installable using the master script. Download https://github.com/jaredballou/linuxgsm/blob/master/_MasterScript/lgsm-core from my repo, and run it. It will download a list of available games, have the user select one via a menu (uses dialog/whiptail if available, with bash builtin fallback), and copy the lgsm-core script to the selected location and make it executable.

Also added a fn_print_center function to print text centered in the screen, and and fn_print_horizontal to print a horizontal line, to core_messages.sh.

I still think I need to find a better format for these files, having converted everything I am seeing some more optimization and processing options. That said, it'd be nice if we can get some people to try out these new features, I have tested it myself but some other perspective would be nice.

@jaredballou commented on GitHub (Jan 21, 2016): So, I'd be happy to help merge it with the current codebase and send a PR your way. Really, if we could get people to try it out and make sure it actually works as advertised, I can start breaking out small pieces for ingestion into the core tool. I have finished the first crack at the gamedata, it is pretty close to what it needs to be. I have another change that I committed a few minutes ago which makes the script installable using the master script. Download https://github.com/jaredballou/linuxgsm/blob/master/_MasterScript/lgsm-core from my repo, and run it. It will download a list of available games, have the user select one via a menu (uses dialog/whiptail if available, with bash builtin fallback), and copy the lgsm-core script to the selected location and make it executable. Also added a fn_print_center function to print text centered in the screen, and and fn_print_horizontal to print a horizontal line, to core_messages.sh. I still think I need to find a better format for these files, having converted everything I am seeing some more optimization and processing options. That said, it'd be nice if we can get some people to try out these new features, I have tested it myself but some other perspective would be nice.

kerem commented

2026-02-27 02:01:59 +03:00

Author

Owner

@AzaZPPL commented on GitHub (Jan 21, 2016):

lgsm 2.0?

@AzaZPPL commented on GitHub (Jan 21, 2016): lgsm 2.0?

kerem commented

2026-02-27 02:01:59 +03:00

Author

Owner

@jaredballou commented on GitHub (Jan 21, 2016):

Yeah the further I get the more I am hitting walls with Bash when it comes to inheritance and object handling. I'm starting to warm up more to the idea of a new platform in Python to just do the core functions and then have "plugins" for everything else.

@jaredballou commented on GitHub (Jan 21, 2016): Yeah the further I get the more I am hitting walls with Bash when it comes to inheritance and object handling. I'm starting to warm up more to the idea of a new platform in Python to just do the core functions and then have "plugins" for everything else.

kerem commented

2026-02-27 02:01:59 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Sep 19, 2017):

Some of these ideas have been implemented and are not used in the current version of LinuxGSM

@dgibbs64 commented on GitHub (Sep 19, 2017): Some of these ideas have been implemented and are not used in the current version of LinuxGSM

kerem commented

2026-02-27 02:01:59 +03:00

Author

Owner

@lock[bot] commented on GitHub (Sep 20, 2018):

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock[bot] commented on GitHub (Sep 20, 2018): This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.