At this point, the new instance works (mostly) just like the classic LGSM scripts. As of right now, there is no "self-update" functionality for lgsm-core and deployed instances, but it's in the works.
At this point, the new instance works (mostly) just like the classic LGSM scripts. As of right now, there is no "self-update" functionality for lgsm-core and deployed instances, but it's in the works.
<h2>Benefits of the new fork</h2>
<h2>Benefits of the new fork</h2>
<ul>
<ul>
<li>One script to rule them all.
<li>One script to rule them all.
</li><li>Game server support provided via extensible gamedata system to reduce duplication and increase ability to support more games
</li><li>Game server support provided via extensible gamedata system to reduce duplication and increase ability to support more games
</li><li>Decent enough config backend that exposes most of what game server admins want in flat files
</li><li>Decent enough config backend that exposes most of what game server admins want in flat files
</li><li>Creates lgsm/cfg/servers directory to control the LGSM script. The files in this directory are:
</li><li>Creates separate directory for all LGSM files. Defaults to 'lgsm' in the same directory as the script. The structure of this directory is:
<ul>
<li><b>functions</b> Functions for LGSM. These are like modules, whatever functionality you need from LGSM is mostly handled by these scripts.
</li><li><b>gamedata</b> Data files that describe the games that can be installed. There is a README.md in this folder with more detail on how this system works. This is still very much a work in progress, and may have some serious changes made. In addition, a majority of the games have NOT been tested with the new lgsm-core and gamedata system, so I'd appreciate anyone that wants to help me sort out the remainder of the games.
</li><li><b>servers</b> Each game gets its own directory, for instance 'insserver' for the Insurgency LGSM
<ul>
<ul>
<li>_default.cfg - Generated regularly by the main script, this will always be overwritten so do not edit it if you want to keep your changes!
</li><li><b>cfg</b> Server configuration files. These files are split out from the script so that upgrading the script doesn't require manual editing, the data and code are being separated.
</li><li>_common.cfg - The config executed by all your instances. Put defaults for your deployment here, for example ip is a common setting.
<ul>
</li><li>$instance.cfg - These configs are created for each instance of LGSM. For example, if I install insserver and create another instance by symlinking to it with "inspvpserver", I will have insserver.cfg and inspvpserver.cfg files here. These files will never be overwritten by the LGSM.
<li><b>_default.cfg</b> Generated regularly by the main script, this will always be overwritten so do not edit it if you want to keep your changes!
</li><li><b>_common.cfg</b> The config executed by all your instances. Put defaults for your deployment here, for example ip is a common setting.
</li><li><b>$instance.cfg</b> These configs are created for each instance of LGSM. For example, if I install insserver and create another instance by symlinking to it with "inspvpserver", I will have insserver.cfg and inspvpserver.cfg files here. These files will never be overwritten by the LGSM.
</li>
</ul>
</li><li><b>log</b> Log files. Includes script, console, server by default. I am in the process of defining logging settings in gamedata and cfg files to add flexibility and intelligence here.
</li><li><b>tmp</b> These are "temp files" generated by the gamedata parser. Feel free to take a look at them, but they get regenerated every time the script is ran, so don't make any changes here that you want to keep. Make the changes in the cfg files.
</li>
</ul>
</li><li><b>tmp</b> General purpose temporary file storage.
</li>
</li>
</ul>
</ul>
</li><li>Better GitHub integration - Supports using Git hashes to check for updated files. Self-bootstrapping sort of works....
</li><li><b>Better GitHub integration</b> Supports using Git hashes to check for updated files. Self-bootstrapping sort of works....
</li><li>Config files for defaults are in a central location, but will be templated and moved to gamedata at some point.
</li><li><b>Config files</b> for defaults are in a central location, but will be templated and moved to gamedata at some point.
</li><li>Dependencies handled in standard way via gamedata files. Different versions of the files are referenced by MD5 hashes for a widely supported method of identifying binary content.
</li><li><b>Dependencies</b> handled in standard way via gamedata files. Different versions of the files are referenced by MD5 hashes for a widely supported method of identifying binary content.
</li><li>SteamCMD and server support for beta and workshop files
</li><li><b>SteamCMD and server support for beta and workshop files
</li><li><b>sourcemod</b> command to install latest MetaMod and SourceMod to your game server instance
</li><li><b>sourcemod</b> command to install latest MetaMod and SourceMod to your game server instance
Jared Ballou
10 years ago