HyperiumClient / Hyperium-Kotlin

Hyperium Client rewritten in Kotlin with good coding standards.
GNU Lesser General Public License v3.0
5 stars 3 forks source link

Custom Lifecycle for Mods #5

Open FalseHonesty opened 5 years ago

FalseHonesty commented 5 years ago

Some mods should only be active during a certain subset of the time the game is open. For these mods, I believe there should be an easy to use system available to control these "lifecycles," rather than each mod have to account for it themselves.

An example of one such mod is AutoGG. AutoGG should only be active when the player is logged on into Hypixel.

One possible idea I had for this was to use a CustomLifecycle annotation. In theory, the annotation would be used like this:

@CustomLifeCycle(creator = CreationEvent::class, destroyer = DestructionEvent::class)
class MyMod : Mod {
    ...
}

The creator and destroyer values would default to an event wrapping the normal mod creation and destruction actions to allow for the developer to specify only one custom lifecycle event.

To apply this to my previous example for AutoGG, the code would look similar to this:

@CustomLifeCycle(creator = HypixelJoinEvent::class, destroyer = HypixelDisconnectEvent::class)
class AutoGG : Mod {
    @Subscribe
    fun onChat(e: ChatEvent) {
        // We can now immediately write our handler code since we know
        // this event will only fire while we are on Hypixel.
        ...
    }
}

I am very open to discussion and other ideas for how this could be implemented, or if it even should be, so please feel free to comment or share your opinion!

FalseHonesty commented 5 years ago

With the addition of processes, it might make logical sense that mods can be attached to a custom process?