KF2: Add CustomArgs support to CommandLineArgs
Description
This PR adds to the KF2 configuration additional startup arguments: CustomUrlArgs and CustomFlags.
Changes
- Added
CustomUrlArgsfor URL-style parameters (e.g.,?Mutator=KFMutator.MyMutator). - Added
CustomFlagsfor dash-prefixed flags (e.g.,-NoSteamClient). - Ensures AMP-defined flags always take precedence over user-defined ones.
- Improves flexibility and compatibility with mods, mutators, or other custom server configurations.
Question: if someone includes in CustomArgs a URL or dash style argument that AMP already sets, what happens? Error? First prevails? Second prevails? This is important to deciding where to place the variable in the command line
The other issue I have is that by combining both styles in the one variable, it presumably won't work if only a dash style argument is set, given there is no leading space
Hey @Greelan , sorry for the late reply.
Regarding your first question: I tested those scenarios on my local instance. If a user includes any command that's already defined by AMP (e.g., -Port or -QueryPort), the game will still run without errors. However, this will conflict with the ports defined by AMP, and it seems they effectively cancel each other out. So it's important that the user knows exactly what they’re doing in such cases.
As for your concern about leading spaces: It turns out that if you include a leading space, it will be reflected in the command line. So if a user wants to add just a single dash-style argument, they need to start with a space before the argument.
But let me know if you'd like me to add more clarification in the field description
I don't understand the first response - if the server doesn't error, usually one or other will prevail. That should then determine where the {{CustomArgs}} is placed in the command line, to ensure that AMP's settings always win
Requiring the user to add a space is too finicky. The arguments should be separated - one variable for URL args, one for dash args. There are various other templates that take this approach, such as Ark
You're absolutely right. I'll go ahead and push the changes using that approach—separating the arguments into two variables. That definitely makes things cleaner and more user-friendly. Thanks for the feedback!
@Greelan I just split the arguments into separate fields. AMP-defined flags will now always take precedence over user-defined ones.
I've made some changes for consistency with other templates, and also to reflect the ordering that my testing suggested is needed to ensure the custom options don't override AMP's settings
@arukaraz any further comments?
@Greelan all good 👍