displayTest option in mods.toml

[cpw]

• "DEFAULT" (or none) is existing match version string behaviour
• "CLIENTONLY" accepts anything and sends an empty string
• "SERVERONLY" accepts anything and sends special SERVERONLY string

Signed-off-by: cpw cpw+github@weeksfamily.ca

[cpw]

Oh hey look! The logical way to handle this for 99.99% of people finally made it only after it was shot down multiple times for "being the wrong way" and "that's not what the mods.toml file is for". Wasn't so hard after all either!

Gad to see Forge using some common sense on this one, even though it's like 3 years late.

I beg your pardon? Is that an appropriate comment? Is this useful feedback on this PR?

[MelanX]

I think it’d be good to also edit the MDK in this PR.

[cpw]

One thing I want to make sure to caution. This is the display test compatibility flag. It has nothing to do with where the mod can load.

Mods should always be loadable wherever they find themselves. There are a whole host of mechanisms to prevent unwanted code running on the wrong side (server vs client). This is 100% a utility for mods that tend to target one side or another and don't do network comms.

[TheCurle]

This PR is awaiting some documentation in the mods.toml file.
I have asked some team members to write this in an internal channel, so it should not be too long.

[Lupicus]

What about the case where the mod can be loaded on either side. I have a mod that has both server and client code and no network comms. I guess I could split into 2 mods, but having another option would be good to avoid people thinking a mod is only good for one side.

[gigaherz]

The names are a bit misleading:

• DEFAULT -> both required
• CLIENTONLY -> the client will show the green checkmark if the server is missing the mod, but the red mark would still show if the client is missing the mod
• SERVERONLY -> the client will show the green checkmark if the client is missing the mod, but also if the server is missing the mod.

Personally, I'd change the names to:

• DEFAULT
• SERVER_OPTIONAL
• EITHER_OPTIONAL

[Lupicus]

I guess if not changed, I could put a comment on that line saying that mod includes client code

[cpw]

What about the case where the mod can be loaded on either side. I have a mod that has both server and client code and no network comms. I guess I could split into 2 mods, but having another option would be good to avoid people thinking a mod is only good for one side.

If your mod works whatever version is on the other side, then it's truly two independent mods. But I very much doubt that's the case, and in fact, you want the standard network test, or some proper version checking.

[marchermans]

Principally this is fine, the removal of the extension points if not set is a bit of code smell to me.

But in general this if fine, as long as no mod code could have been run before this is executed (like the mod constructor).

[marchermans]

Personal opinion: Removing the extension point is not a great idea.

But I guess this runs before mod construction so no extension point could have been registered so it should not really matter.

[cpw]

Actually, it's absolutely fine. Removing it completely is a totally legitimate option, as demonstrated by the lowcode langprovider. It also means that you can replace it with your own, if you wish.

[marchermans]

But that is my question basically: if there was already an option for MO code to run, is it then not feasible that a modder could already have it set? Or has no mod code been invoked at all at this point?