When using NML alongside other plugins, NML should not ruin the compatibility hash.

[zkxs]

The compatibility hash is normally altered for each loaded plugin. Imagine a function hash that takes a list of plugins. For vanilla, you'd have hash(). For NML, you'd have hash(nml). For someone running multiple plugins, you'd have hash(myCoolPlugin, otherPlugin, veryGoodPlugin).

Currently, if NML is the only loaded plugin it spoofs the hash to be hash(), enabling multiplayer compatibility with vanilla users. However, if there is another plugin being loaded as well, then NML completely disables its spoofing and uses hash(NML, otherPlugin). This means that a otherPlugin user not running NML will have hash(otherPlugin) and therefore be incompatible with the NML + otherPlugin user.

NML should fix this by removing itself from the hash, but leaving any other plugins.

[l-2-j]

.....Jank, but I guess I see the reasoning for it.

[DoubleStyx]

Would it be possible to patch a section of the Engine.Initialize() method to skip over the iteration where the NeosModLoader assembly name is added to the file stream, thereby excluding it from the hash?

[zkxs]

Would it be possible to patch a section of the Engine.Initialize() method to skip over the iteration where the NeosModLoader assembly name is added to the file stream, thereby excluding it from the hash?

Unfortunately no, as NML isn't loaded yet when that code runs.

[zkxs]

While looking into this I've found a "fun" little thing. Imagine you have two users both running FooPlugin and BarPlugin. But one of them stores their plugins like this:

<installdir>/Libraries/a/BarPlugin.dll
<installdir>/Libraries/b/FooPlugin.dll

And the other one stores their plugins like this:

<installdir>/Libraries/a/FooPlugin.dll
<installdir>/Libraries/b/BarPlugin.dll

They'll have different compatibility hashes, because the hash is sensitive to the load order and the load order is sensitive to how the file paths sort. Very cool.

[rampa3]

That means that even if I tried this without spoofing anything, just switching dirs around, it will make it incompatible with another person loading them in different order... FUN!!!

[l-2-j]

They'll have different compatibility hashes, because the hash is sensitive to the load order and the load order is sensitive to how the file paths sort. Very cool.

So this sounds like time to suggest that upstream changes the way they do compatibility hash and kindly ask to make it run later in the initialization so that NML can patch it easier ;'D

[zkxs]

BepinEx be looking awfully good right now, as it'd have sidestepped this whole can of worms.

To solve this, I need to get a list of the loaded plugins. Neos doesn't have that in a place I can just grab, though. I've brainstormed two ways of solving this issue:

1. Re-parse all the Neos arguments to grab the -LoadAssembly stuff, then assume that all those assemblies were successfully PostX'd and loaded.
2. Enumerate all loaded assemblies and use some sort of heuristic to guess if they're a plugin or not.

I'm currently investigating option 2, as I think a really accurate heuristic is viable, because plugin DLLs have some very consistent tells. Namely, they've been PostX'd.

[EIA485]

Re-parsing the -LoadAssembly args is a good idea!