AMP
AMP copied to clipboard
Allow template config merging
Feature Request
Feature Information:
In the current state, template config automap overwrites the entire config file if one exists. It would be better if the template config was able to merge the lines based on template variables. This would allow users to enter custom lines in the config files, or for some games to use the built in editing tools alongside AMP's UI.
For lines with a variable name the merge is easier, match it based on anything that isn't the variable (before and after on same line). If a match isn't found in the config for other lines (Default values that aren't a variable), it should write the lines in order. This can be used for setting up the layout for a file if the section does not follow the kvp format defined.
I confirm:
- [x] that I have searched for an existing feature request matching the description.
This isn't really possible on template merges because the whole point is that AMP has zero understanding of the files structure or syntax, So it has no way to know what part is what - it's a dumb search-and-replace.
What could be done instead however is template includes. So you could have {{@include user.txt}} and any custom user settings would go in that file and would get merged into the final output.
Hmm... That might be an option. How would that work in instances where the user settings have to go under a specific heading?
Okay, I think I get it. So we could theoretically have an include for each section of the config file and possibly even list inputs that create those included files if we chose.
@Greelan and I discussed perhaps a better solution. Would it be possible for regular automap (no template config, just the game's existing config, either as supplied by the server or by AMP), and if it doesn't find the key it creates a line using the automap config format?
Adding it to the end? Possible - clunky though.
That’s fine, as long “the end” can accommodate ini sections?
Well... I'm not sure that would be fine. How would that work for ini files? I thought headers could only appear once. And for things like JSON or XML... Not sure that would be beneficial either.
Would it not be possible to add some logic that if it's not found, break out into a function that adds it at the end of the current section? Sure, it would require some finessing, but seems doable.
Didn’t my comment address ini sections? Lol
Extending to JSON/XML might be stretching it
Yes, I'm in agreement with you, not disagreeing. I was just elaborating on the point that the end of the file isn't going to work in most cases.
ARK generic will require this if we want to allow users to manually add settings or use mods that edit the config file. It seems the server removes certain settings from the config file if they are default values.
This isn't really possible on template merges because the whole point is that AMP has zero understanding of the files structure or syntax, So it has no way to know what part is what - it's a dumb search-and-replace.
What could be done instead however is template includes. So you could have {{@include user.txt}} and any custom user settings would go in that file and would get merged into the final output.
I think I want the opposite... Not a template include but a template exclude so I can choose to not have AMP manage my settings for a game. I created #630 for that. That would straight out solve @IceOfWraith problem too.
While I agree a merge is nice because we can still use AMP to manage the settings, if it is too complicated to implement due to the variety of formats, then a template exclude would solve the problem by having us manage that part ourselves.
In fact, even if there was a merge feature, it could still be nice to be able to exclude files and / or / templated settings management altogether so that whenever you get your server files from not AMP to AMP, you don't have to use the UI to set the settings that were perfectly fine.
Unfortunately, that doesn't relate to the issue stated here. This is in reference to managing how the merge is handled, not whether or not it is.