Fixed DayZ mod loading, removed quote marks around additional params

[Moondarker]

Description

DayZ Experimental had a classic mistake in -mod and -serverMod launch options. Quotes must be placed before and after the entire argument, not just its value. See ArmA 3 documentation - while not documented for DayZ, the argument parser is the same for both games. If you need further proofs, see what DayZ Launcher itself passes to the game when launched with mods. Same goes for additional startup params, there's no sense in adding quotes right here as it will break once there's more than 1 additional parameter.

In it's current state, given multiple mods like @Mod 1, @Mod 2 and @Mod 3 as mod list, server will interpret these mods as "@Mod 1, @Mod 2, @Mod 3 and "

Fixes #1768

Checklist for all submissions

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you tested and reviewed your changes with confidence that everything works?
  • While I'm 146% confident this will work, I haven't tested it personally yet because I'm not the one who has this problem (I don't even have Pterodactyl installed yet), I merely fixed it for a user of my mod and looks like it worked for them. Will pull this PR out of draft state once I do test it. Tested, it works and I was unable to escape arguments list and execute any commands - please try to do so in case I missed something tho.
• Did you branch your changes and PR from that branch and not from your master branch?

[Moondarker]

Note: this will break BattlEye RCON for those who had battleye config in server root... Should BEpath be moved to variables or just rolled back to hard-coded /?

[lilkingjr1]

this will break BattlEye RCON for those who had battleye config in server root

How so? How does moving the quotation marks affect BattlEye? Or are you just saying it's broken in the first place?

Should BEpath be moved to variables or just rolled back to hard-coded /?

So I just read the documentation and found something interesting, though I don't know if it's been updated since I made the egg or if there was a specific reason why I deviated from it. It states:

By default BattlEye will create BattlEye folder inside server profile folder.

I'm assuming that's the -profiles folder. For -profiles it states:

Does not work on Linux, no profile will be created or used; instead, remove this parameter and the profile will be created in ~/.local/share/Arma 3 - Other Profiles.

This is funny, because specifying it does actually work, but that's besides the point. ~ should resolve to /home/container/, which means (if it works) we could just remove the -profiles and -bepath flags to be clean and default. My only concern at the time of writing the egg was to ensure both the profile folder and BE folder resided within /home/container/ where the end-user could actually reach it if desired.

[Moondarker]

How so? How does moving the quotation marks affect BattlEye? Or are you just saying it's broken in the first place?

I meant that if somebody were to update the egg version on existing server, their BattlEye config wouldn't load, but that's not a concern anymore as I rolled that back in c328485

So I just read the documentation and found something interesting, though I don't know if it's been updated since I made the egg or if there was a specific reason why I deviated from it. It states:

By default BattlEye will create BattlEye folder inside server profile folder.

I'm assuming that's the -profiles folder. For -profiles it states:

Does not work on Linux, no profile will be created or used; instead, remove this parameter and the profile will be created in ~/.local/share/Arma 3 - Other Profiles.

This is funny, because specifying it does actually work, but that's besides the point. ~ should resolve to /home/container/, which means (if it works) we could just remove the -profiles and -bepath flags to be clean and default. My only concern at the time of writing the egg was to ensure both the profile folder and BE folder resided within /home/container/ where the end-user could actually reach it if desired.

That's a typical BI documentation moment ;D

UPD: Damn, I can't make the server load any mods - with original and forked egg, with quote symbols in any position or without these. Gotta be a problem on my end, but I can't find it ;D

[Moondarker]

Alright, I've managed to test everything, and it looks like quotes placement doesn't matter at all on Linux, unlike Windows

The reason why mods are not loading e.g. in #1768 seems to be a decades old bug in DayZ itself - it only works fine when filesystem is case-insensitive. As soon as you introduce an upper-case letter anywhere past the mod name it breaks (e.g. @CF\addons\gui.pbo is fine, @CF\Addons\GUI.pbo is not)

Which is a known thing looking at MODS_LOWERCASE, but making it more obvious in description of Additional Mods might be a good idea 🤔

UPD: Quotes placement does appear to matter:
"-mod=@CF;@ZomBerry;" - mods don't load at all. Seems like DayZ reads argument name as "-mod instead of -mod
-mod="@CF;@ZomBerry; - CF doesn't load because it's parsed as "@CF. ZomBerry does load, but crashes the server as it relies on @CF (classic situation, same happens on Windows)
-mod=@CF;@ZomBerry; - works fine