I noticed there is an insane amount of events/tasks in the Hyperion source which contain things that probably don't need to be handled as "events" or "tasks"...... In fact, at least one of these "tasks" merely prints a string.

There are countless other similarities , here's some pseudo code:
World class -> new SessionLoginTask() -> World.getWorld().register(player);

Why?!?! What's wrong with simply doing it this way:
World class -> register(player);

There is no performance difference on the small scale tests I've run with a few mates.

I've got a copy of default Hyperion, using a single ScheduledExecutor which is called each 600ms to handle Player/Npc Update Tasks and it seems to run perfectly fine. Granted the server now uses a reactor based design for incoming packets, AND FOR ANY LOGIC/PROCESSING I am simply using ticks (controlled from the main thread which is handling npc/player updating)

Personally I want to continue my project using a single ScheduledExecutor , and tick based counters for the sake of simplicity. That, and I cannot see any benefits from an event which legitimately only prints a string or makes calls which could be done internally -_-

With the Hyperion framework is there some deep seeded purpose which I may not see negatively effecting stability in the short term..?


I am experienced with programming but not so much RSPS (yet) and overall just curious why things are so strung out and if this system is any better than running everything on a ScheduledExecutor

Feedback would be great. Cheers


Answered by Saifix , cheers. Conclusion: Going with scheduledexecutor as the main logic thread to mitigate the task system..