[Suggestion] New Mod that follow this guideline

[yukieiji]

As a developer of ExR, ExS, and EvE, I agree with this guidelines

So how about creating a small premise mod that follows these guidelines? (I will help in the development).

By making it a small mod, it reduces the possibility of it not working due to updates to AmongUs, and makes it easier to apply it to each mod.

[Alexejhero]

My idea was to add a utility in Reactor for this.

void PingTrackerManager.RegisterMod(string modName, string version, bool isDevelopmentVersion, Func<bool> shouldBeVisible);

[yukieiji]

I think Reactor is fine, but I think it would be better to provide a new, smaller mod that isn't tied to Reactor. Being tied to Reactor means that when Reactor stops working, we have to wait for updates. For example, with ExR, the v2024.6.18 release was finished in a week, but the Reactor release took until this month.

If the mod can wait that long, then it should be fine, but it is up to the mod developer to decide if it can wait or not.

[yukieiji]

Lately, I've been thinking that the AmongUs mod should be implemented thinner and smaller (even Reactor is big), and that it should be possible to combine various mods without being tied to a mod (and I'm preparing for that).

[Alexejhero]

The game has major updates only 2 or 3 times per year, and usually reactor doesn't even need to be updated.

For this version it is true that it did take one month but the main developer was unavailable to update it, that's why it took so long.

I think this was a very rare occurrence and I have faith that it won't happen in the future.

[yukieiji]

It's true that Reactor updates only once a year or so. But when there is an update, on average it takes about a week.

I feel it's a slow release cycle for an API...

I also thought there is a way to develop it as a SourceGenerator and distribute it as Nuget (fast CI/CD, easy to provide beta versions, and integrated into the mod at build time, so it should be less likely to have dependencies)

[Alexejhero]

That problem could be solved by having more mod developers on board to update Reactor.

If I'm not mistaken reactor has CD both for nuget and for github releases, so updating it would be as easy as pushing the code to main.

In truth, 6pak contacted me before AU 2024.6.18 was released and asked if I could update Reactor whenever Among Us updated, however I declined because I did not want to take the responsibility of maintainer as I had other things going on at the time, and I also have a reputation for slow mod updates.

However, maybe I made a mistake. I was here and could have updated it if I had access,

I've asked 6pak to add me to the repo and at least the next time it happens, there will be one more person there that can update it.

[yukieiji]

Thank you, this solved the problem with the update.

Another reason is that Reactor is too big to adopt. Reactor is a great modding API, but there are several unnecessary ones for developers. For example, for RpcSystemand LocalizationSystem, there are several ways to do this, and Reactor's implementation isn’t always the best, for RpcSystem, Submerged isn't even used, and for LocalizationSystem, ExR has succeeded in fully integrating with Au's implementation.

Here is my proposed module split for Reactor

• Reactor.Core : Bug fixes, PingTrackerManager, Asset, Il2Cpp injection, Il2Cpp and Unity Extensions, standalone steam, etc
• Reactor.Localization : Localization system
• Reactor.Rpc : Rpc system
• Reactor.impostor : Integrated system with Impostor, no connection to vanilla servers, etc.
• Reactor.Gui : Gui system
• Reactor.Utility : Fast boot, freename,

If they were separated as modules like these, I would definitely adopt Reactor(Reactor.Core) (and there would be less updates to the core modules).

[Alexejhero]

Splitting Reactor into multiple modules does not solve the adoption problem because they would still all need to be updated at the same time.

The reason why Submerged doesn't use reactor rpcs is because we already had rpcs implemented before adding reactor as a dependency, so we didn't bother changing.

About the localization system, can you show me how you integrated with Among Us?

[yukieiji]

Splitting Reactor into multiple modules does not solve the adoption problem because they would still all need to be updated at the same time.

As is the case with this update, I have the impression that the recent updates of AmongUs have been refactoring the internal structure as well. Therefore, if we reduce the size of the mod, it is less likely that Reactor.Core will stop working, and there will be less need to quickly update other than Reactor.Core (since all but Reactor.Core are optional), resulting in lower maintenance costs.

About the localization system, can you show me how you integrated with Among Us?

The data of the AmongUs translation is stored in a dictionary in LanguageUnit, so I implemented it by adding it directly to the dictionary. There is only one patch, and a helper function is provided to translate from strings. patch : https://github.com/yukieiji/ExtremeRoles/blob/master/ExtremeRoles/Patches/LanguageUnitPatch.cs helper func : https://github.com/yukieiji/ExtremeRoles/blob/master/ExtremeRoles/Extension/TranslationControllerExtension.cs

The body data of the translation is managed by resx and embedded directly into the mod at compile time using SourceGenerator.

[TianMengLucky]

Reactor is indeed too bulky, and I personally don't think it's a good proposal to bind this functionality to Reactor