API to query list of other active mods

[levitation]

I have observed a couple of times already, that sometimes the mods may interfere with each other.

The problem happens when one of the mods modifies some API, on which the other mod directly or indirectly depends on. Then the other mod needs to compensate or adjust some of its behaviour or configuration.

(Clarification: Here I have in mind interaction between such mods that are generally supposed to do different things. And this motive obviously does not contain situations where the user installs two mods that are fork of each other or otherwise solving same problem in such a way that it is reasonable to have only one of them installed.)

It would be nice if one mod might query Windhawk about the existence of particular other mods. Or if it could just query Windhawk of the list of all active mods. Then the mod could adapt their behaviour or configuration accordingly.

I guess it would be nice to have the following features.

Essential:

• Querying the list of active mods in the system, OR Querying the list of active mods in the current process.

Optional:

• Each list entry has mod version in addition to mod id.
• Each list entry has an indicator whether this other mod was loaded before or after the querying mod.

[m417z]

I understand that it can be useful as a quick workaround in some cases, but I'm not sure I like having such an API, and having mods querying each other. I don't know what use cases you encountered for it, but as with web development, perhaps you can detect the effect that the other mod does instead of looking for the mod itself. This will make the detection more universal in case the mod is changed, forked, etc.

[levitation]

Thank you for responding! Behaviour detection seems interesting idea. I need to think about it further. It would definitely be a sufficient solution in some cases.

For a general case, initially I suspect with Javascript, the behaviour testing would be somewhat simpler:

• If something crashes, you can just do try-catch in a couple of lines and be done with it.
• The data structures one may need to pass to the Windows API-s are more complex, or have hard to find documentation. Neither of the mods might know these structures, only the modded application does.
• The interfering modification might affect something that the user sees, not something that the mod can see with reasonable effort.
• The interference may cause the program to hang or do nothing, instead of triggering a convenient exception.
• The test may involve showing visible artefacts to the user.

In summary, the code to detect another mod's interference would be longer than the code to rewrite that interfering mod on your own.

I will later document the cases I have encountered and you then can decide on your own.

[levitation]

Regarding the query API, I guess one could do registry query and see the presence of the interfering mod. Then the Windhawk code does not need to have a special API for that purpose.

[m417z]

Well, yes, of course writing Windhawk mods is more challenging than writing JavaScript :) but some of the challenges you mentioned, such as understanding the data structures and avoiding crashes, are relevant even if no other mods are involved.

I will later document the cases I have encountered and you then can decide on your own.

Sure, let me know and let's try to find the best solution for this.

I guess one could do registry query and see the presence of the interfering mod

It will only work for the non-portable Windhawk version. The portable Windhawk version keeps the data in .ini files.