Allows passing arguments to gamemd.exe

[frg2089]

Allows passing arguments to gamemd.exe using something like clientdx.exe -- <options>.

clientdx.exe -MULTIPLEINSTANCE -- -SPAWN # Pass the -SPAWN argument to gamemd.exe

Close #471

[github-actions[bot]]

Nightly build for this pull request:

• artifacts-TS.zip
• artifacts-YR.zip
• artifacts-Ares.zip This comment is automatic and is meant to allow guests to get latest automatic builds without registering. It is updated on every successful build.

[SadPencil]

~Personally I am in favor of #535 as it is most straightforward to specify arguments to the same place where the executable name is specified~ (Different things)

[SadPencil]

Apologies for my last reply. But, I think it is still better to provide a separate .ini file to override this argument. I don't think modders as in #471 expects a command-line

[frg2089]

Apologies for my last reply. But, I think it is still better to provide a separate .ini file to override this argument. I don't think modders as in #471 expects a command-line

It's not always necessary to open it in the command line, but you can also add parameters to the target properties of the shortcut.

I designed it this way for this purpose as well

[SadPencil]

Apologies for my last reply. But, I think it is still better to provide a separate .ini file to override this argument. I don't think modders as in #471 expects a command-line

It's not always necessary to open it in the command line, but you can also add parameters to the target properties of the shortcut.

I designed it this way for this purpose as well

Another reason I am against it is that a client can only have one set of unnamed command-line arguments, and therefore it needs a strong reason to occupy it. I know in some designs like 'docker run' or something else all unnamed command-line arguments after '--' are passed to the program inside but I doubt whether it is also reasonable for this client. The difference is that xna-cncnet-client does not automatically runs the game executable like 'docker run': launching the game executable is not the only feature -- e.g, users could alternatively launch the game(md).exe file in CnCNet YR for a classic campaign, or launch the map editor. Through your design, it is not straightforward for users to tell whether the unnamed parameters be passed to all these executables or just the gaming executable. That's why I am opposing it.

[Metadorius]

What about anti-cheat? You should realize that passing different command args by different players can lead to cheating undetected by XNA client. Imagine passing -INCLUDE -INHERITANCE when it isn't on in a Phobos mod, and the map would have the code that only works with those tags. The anticheat won't go off but the cheats will be still on only for the people with those tags working.

[SadPencil]

I'll close this one for now. According to the conversation we need an INI configurable commandline argument.