Support AMCI in v18.0

[HayashiUme]

A new matchmaker way in v18.0, this Pr implementate and a improvement with multiple mods support

[FangkuaiYa]

Adding the following code can fix the issue where, when launching the game, the filter conditions are selected by default, and searching shows all rooms, but the issue resolves after clearing the conditions.

[HarmonyPatch(typeof(CurrentModRegistration), nameof(CurrentModRegistration.UpdateFilterSetWithModRegistrationSettings))]
public static class EnsureGuidPatch
{
    public static void Prefix(GameFilterSet filterSet)
    {
        for (int i = filterSet.Filters.Count - 1; i >= 0; i--)
        {
            if (filterSet.Filters[i].Key == "mod")
            {
                filterSet.Filters.RemoveAt(i);
            }
        }
    }
}

[HayashiUme]

I see, I am kunle, will fix tomorrow.

[FangkuaiYa]

I see, I am kunle, will fix tomorrow.

Pull Request created, remember look it when you xingle :)

[miniduikboot]

I'm in favor of making AMCI an implementation detail of the Reactor Handshake, requiring no further configuration from mod devs. I'll create a competing PR tomorrow, let's discuss together then on a way forward.

I do like the composite GUID calculation, I'll be copying that

[miniduikboot]

I get why you're normalizing this to UUIDv4, but wouldn't it be better to set it to a different UUID type to indicate it's a composite UUID? Either V5 which is used for SHA1 hashed namespaces or V8 for "Custom"

[HayashiUme]

I think they’re pretty much the same in terms of functionality, but it’s certainly better

[miniduikboot]

I believe this is the wrong approach. There are currently 3 types of mods:

1. All client mods, which should use AMCI
2. Host-only mods, which use +25 instead. In some cases they register for AMCI as well as the server does not check AMCI on join.
3. Client-only utility mods, which don't require any registration as they should not interact with the network at all (think UnityExplorer)

#3 can't change their registration as they usually cannot depend on Reactor as they're targeting multiple games. And their presence shouldn't influence matchmaking anyway

For #1 and #2 you can get their names from their existing ModFlags declaration and use that as the input for the composite calculation, and this attibute is therefore obsolete as I don't see why a mod should need to opt out of AMCI once Reactor handles it.

That leaves the question: what to do if nobody registers ModFlags, but Reactor is loaded. I'm not sure yet, I'm thinking right now that it's best for Reactor to be invisible then, and not affect the public lobby menu

[HayashiUme]

You’re right, can easily achieve the same functionality without registering AMCI at all.
I’m not entirely sure why this was written either; perhaps it was intended specifically for the API mods at the time. However, after the composite GUID calculation feature was added later on, I forgot to remove it.

[miniduikboot]

How about concatenating the plugin names together (gg.reactor.api, auavengers.tou.mira, etc etc)
Every mod has these already, no need to manually configure a GUID for each mod

[HayashiUme]

Of course can, but do you intend to automatically register the mod name as a GUID, or do you need to register it manually via an attribute declaration? If choose the automatic option, there may be mod creators with specific requirements who do not wish for their mods to be registered by AMCI.

[miniduikboot]

If the AmciModGuidAttribute is not defined, the plugin is always ignored. So this is another reason why this attribute is not needed