Bukkit

@Scorpion_vn

You were exactly correct. UUIDs in the event engine was always going to be the way to go. Just that never had a need to update them (the one user who commissioned adding them never got back to me when I reached out). Another user who does use them reached out via PM and said that having the EE switch to just UUIDs would be fine, no need for pretty GetPlayerName stuff.

So with MC 1.9 and the need to recompile (mumble about spigot compat here), decided to do that change over. If you are using older MC versions, please keep using the builds for those versions.

@KenDerGuru

I still use it for my own servers, so I would hope it still works! Although I never really used the EventEngine portion, and never had any one willing to step up and help maintain it (or even explain what it should work like). So I am probably going to strip out a decent amount of the EE that I know is broken-ish (basically any event that includes a player name) next time it needs updating (probably 1.9).

@uvbeenzaned

There are no real plans to add filtering like that for the CronEngine. Either they run or the don't. The solution is to in your backup script add logic that would query the server somehow to know if there are players online or not. Something like the bukkit JSONAPI (eg the method "players.online.count" sounds like what you want/need) is probably the way to go. Again SCC/SCE is meant for very rudimentary scheduling and any fancy filtering past that should be done by the program executed in the script.

For the most part I would personally recommend that unless you have very specifically good reasons you should *always* be running your backups. Players online or not.

Note for spigot 1.8: Tested working for the CronEngine perfectly. EventEngine is not UUID-aware and sometimes barfs if users change name or such and you are trying to filter users. (AKA: Version 1.2 still works just fine for everything I said it would)

For the future though, due to lack of other peoples interest I will only be supporting features I myself use. Contract work to update/support extended features beyond that is fine reach me via github, email or reddit. And due to the uncertanty of future minecraft servers I am not even 50% sure where this plugin will be in the future with respect to Sponge or whatever comes next, thus where my support of features I use comes in: I expect to basically always still want CronEngine and some of the basics of EventEngine (user logged in, teleported worlds, server (Not)Empty) but more than that I don't really know. Too much uncertainty.

@cyclo666

Well good news then for you, I should have free time to work on SCC sometime this week and the "at server start" event should be easy to add, although I would like a users perspective on how to handle reloading the whole plugin tree or even just restarting SCC:

https://github.com/RobertZenz/org.bonsaimind.bukkitplugins/issues/36#issuecomment-51023929

@cyclo666

Right, and to handle restarting instead of saying "after 24 hours uptime do $blah" think instead along the lines of "every day/week at such hour, do $blah" where here $blah is " do .reschedulerestart 10m". An example for running a "restart.scc" every day at 5 AM (server time):

#in "tab.scc"
  0    5    *    *    *     restart.scc

Also, does RT hook into the console so that typing ".$command" is listened to? SCC sends commands to the minecraft OP command handler via "server.dispatchCommand(server.getConsoleSender(), command);" If RT hooks in a different way, make sure to send its restart command in a way it understands as if you were OP inside minecraft. Otherwise you will have to use some form of external program to tell RT to restart (Like I have my "restart.sh" that hooks into GNU screen for me)

@cyclo666

Ah, two things then: One, it is generally a bad idea to have the server restart managed by the server itself (via plugin basically) this leads to issues such as what if the server crashes how would it manage that?

The other is that of course for a while I ignored that and ran some of my smaller servers using SCC to restart, here is the breakdown of that old code:

• restart.sh: shell script to talk to GNU screen for me and inject the restart commands.
• restart.scc: SCC script that executes the restart, nothing interesting. Biggest thing to note is use "exec" so that the restarter spawns in a background process and java won't wait for that new process to end before shutting down.
• tab.scc: example CronTab file, mostly to show stuff i guess? Included for completeness sake.

Now a note: if you are going to ever do anything like a "sleep" for more than a few minutes it would be better to just schedule a script for that time itself (or "exec" a new background process and handle all the timing there). Thus you just set up your restart script to run every day at say 5AM. Unless you have reasons you always want it as a "24 hours from server startup"?

Either way, opened a few issues for me to look at sometime this week that might interest you (but basically until they are done what you ask of "startup script" is not possible): SCC 1.3 tracker

@cyclo666

Currently there is no "run script at startup" event or trigger available. Mind if I ask what your use-case is? Should not be hard to add a new event if there is a good use case, but I would rather not add events that I have to test every update if at all feasible another way.

Heads up: due to mojang switching to UUIDs for player identification and such the EventEngine tab.sce is going to have to change a tad. I hope to be able to do a automatic conversion, but currently am not seeing a way to do so. The change will involve the "filters" part of the event scripting.

@mistermsk

Mind posting the tab.sce and event.sce file(s) and what your goal is? My automatic testing still shows its working, but I admit that the filtering is one that I don't test very well and you might have hit an edge case (or my docs need more explaining/examples)