Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overhaul event/time management system #36

Open
1Rogue opened this issue Nov 27, 2013 · 0 comments
Open

Overhaul event/time management system #36

1Rogue opened this issue Nov 27, 2013 · 0 comments
Assignees
Milestone

Comments

@1Rogue
Copy link
Member

1Rogue commented Nov 27, 2013

The current system is buggy, and can be off, so it's going to be completely overhauled:

Time System

Previous time system:

  • A query would run every minute
  • Executed an update method that would insert players with 1 minute, and on dupe keys would append another minute
  • Expensive, depended on errors for input

New proposed time system:

  • Player times are grabbed from the table on login
  • Timestamps are compared between login/logoff
  • Login time is appended to total time, and re-submitted
  • Much less queries
  • A crash would lead to a loss in playtime (possible solution: hourly updates/fixes)

Event System

Previous event system:

SELECT * FROM `playTime` WHERE (`someTimer`%MINIMUM) <= (MINIMUM+INTERVAL) AND `someTimer` >= MINIMUM
  • A query would run every x pre-determined minutes to check the SQL database for times. (in the pseudo-query above, where MINIMUM is a constant for the trigger time, and INTERVAL is the time between checks)
  • All results from this would "fire" the event for the relevant players.
  • Each event would have an individual Runnable scheduled through the ScheduledExecutorService in the java.util.concurrent package.
  • This lead to a single query for each event every INTERVAL minutes

New proposed event system:

  • When a player logs on, a single query will grab all their times.
  • A new runnable will be scheduled to execute x minutes later, when they would "fire" the event normally
  • There will be a runnable per-event, per-player.
  • Events would be able to be "overridden" or bypassed via permissions
  • No future SQL queries would be needed, and times would be more accurate
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant