starred/LinuxGSM

Fork 0

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

[GH-ISSUE #3074] Easier way to override launch parameters #2172

New issue

Closed

opened 2026-02-27 03:01:18 +03:00 by kerem · 5 comments

kerem commented

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

Owner

Originally created by @mvaessen on GitHub (Oct 8, 2020).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/3074

Originally assigned to: @dgibbs64 on GitHub.

User Story

As a server hosting company, I want an easier method to setup custom launch parameters so that I can rely on the original LGSM files without having to make manual changes to support easy launch param overrides.

Further Information

In most cases people host a couple servers and it all works fine. But when using automated systems to generate the config.json file to override the _default.json settings you can not override the launch parameters without hacking into files.

Current situation:

fn_parms(){
parms="\"${defaultmap}?AltSaveDirectoryName=${defaultmap}?listen?MultiHome=${ip}?MaxPlayers=${maxplayers}?QueryPort=${queryport}?RCONPort=${rconport}?Port=${port}\""
}

Suggested outcome:

launchparameters="\"${defaultmap}?AltSaveDirectoryName=${defaultmap}?listen?MultiHome=${ip}?MaxPlayers=${maxplayers}?QueryPort=${queryport}?RCONPort=${rconport}?Port=${port}\""

fn_parms(){
parms="${launchparameters}"
}

Originally created by @mvaessen on GitHub (Oct 8, 2020). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/3074 Originally assigned to: @dgibbs64 on GitHub. ## User Story As a server hosting company, I want an easier method to setup custom launch parameters so that I can rely on the original LGSM files without having to make manual changes to support easy launch param overrides. ## Further Information In most cases people host a couple servers and it all works fine. But when using automated systems to generate the `config.json` file to override the `_default.json` settings you can not override the launch parameters without hacking into files. Current situation: ``` fn_parms(){ parms="\"${defaultmap}?AltSaveDirectoryName=${defaultmap}?listen?MultiHome=${ip}?MaxPlayers=${maxplayers}?QueryPort=${queryport}?RCONPort=${rconport}?Port=${port}\"" } ``` Suggested outcome: ``` launchparameters="\"${defaultmap}?AltSaveDirectoryName=${defaultmap}?listen?MultiHome=${ip}?MaxPlayers=${maxplayers}?QueryPort=${queryport}?RCONPort=${rconport}?Port=${port}\"" fn_parms(){ parms="${launchparameters}" } ```

kerem

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

closed this issue
added the
type: feature

Atomic
labels

kerem commented

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

Author

Owner

@issue-label-bot[bot] commented on GitHub (Oct 8, 2020):

Issue-Label Bot is automatically applying the label type: feature request to this issue, with a confidence of 0.93. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

@issue-label-bot[bot] commented on GitHub (Oct 8, 2020): Issue-Label Bot is automatically applying the label `type: feature request` to this issue, with a confidence of 0.93. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback! Links: [app homepage](https://github.com/marketplace/issue-label-bot), [dashboard](https://mlbot.net/data/GameServerManagers/LinuxGSM) and [code](https://github.com/hamelsmu/MLapp) for this bot.

kerem commented

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

Author

Owner

@dgibbs64 commented on GitHub (Dec 29, 2020):

I'm looking at how best to implement this and the change might break existing installs with custom parameters. So I will have to figure out a way to make sure the "legacy" fn_parms in common.cfg still works if needed. would be easy if I didn't need to think about existing installs XD

@dgibbs64 commented on GitHub (Dec 29, 2020): I'm looking at how best to implement this and the change might break existing installs with custom parameters. So I will have to figure out a way to make sure the "legacy" fn_parms in common.cfg still works if needed. would be easy if I didn't need to think about existing installs XD

kerem commented

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

Author

Owner

@mvaessen commented on GitHub (Dec 29, 2020):

Perhaps you can introduce a new function. If the legacy function's response is empty, and the new one exists and has a string you can be sure you are dealing with the new system.

If the legacy function returns a string and/or if the new function is missing you can be sure it's an old install.

@mvaessen commented on GitHub (Dec 29, 2020): Perhaps you can introduce a new function. If the legacy function's response is empty, and the new one exists and has a string you can be sure you are dealing with the new system. If the legacy function returns a string and/or if the new function is missing you can be sure it's an old install.

kerem commented

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

Author

Owner

@dgibbs64 commented on GitHub (Dec 29, 2020):

yeah, I have a core_legacy.sh module for backwards compatibility issues. I will create something it will just need a bit of testing extra care to make sure I don't break installs accidently.

@dgibbs64 commented on GitHub (Dec 29, 2020): yeah, I have a core_legacy.sh module for backwards compatibility issues. I will create something it will just need a bit of testing extra care to make sure I don't break installs accidently.

kerem commented

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

Author

Owner

@github-actions[bot] commented on GitHub (Jan 29, 2022):

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

@github-actions[bot] commented on GitHub (Jan 29, 2022): This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

kerem referenced this issue

2026-02-27 03:54:48 +03:00

[PR #2172] [MERGED] New details info #3520

kerem referenced this issue

2026-02-27 03:54:50 +03:00

[PR #2197] [MERGED] Release/190217 #3529