[Bittersweet]

Originally Posted by dubbeh Sorry for the double post - Looking for some feedback on a change I'm thinking about doing. How would server admins be if i changed the format to be more like the official UNIX cronjob scheduler? Looked over the Wikipedia article and thought it would be much better overall and create less confusion. # * * * * * command to execute # │ │ │ │ │ # │ │ │ │ │ # │ │ │ │ └───── day of week (0 - 6) (0 to 6 are Sunday to Saturday, or use names; 7 is Sunday, the same as 0) # │ │ │ └────────── month (1 - 12) # │ │ └─────────────── day of month (1 - 31) # │ └──────────────────── hour (0 - 23) # └───────────────────────── min (0 - 59) That's how the new format would be like - And potentially add macros for stuff like @startup, @mapchange - Only downside to this, is possibly more overhead on the server. Freel free to check out the wikipedia article here and give any potential feedback

Most of the confusion has been over the "stop" times. I think people take this to mean there is some sort of termination sent out to kill the process, rather than what is actually happening - the command is no longer sent. Removing the "stop" time might make it more clear that most common uses require at least 2 lines - one to change something at a certain time, and another to change it back. Most people seem to use this to change their mapcycles during peak periods, and they often think that the mapcycle will revert back somehow at the "stop" time, when in fact that is the sort of job where then stop time is not relevant, and the user would need a whole other config line to change the mapcycle back. There's also some other quirks with the current syntax. If "Start Time > Stop Time", whether "Time" is hour, minute, etc., the job will never run, and that may be >= instead of just >, I don't remember off hand and can't test it right now, but I know I've posted about it in this thread before.

On the other hand, you should probably add comments in the documentation somewhere clarifying the proposed new syntax because I can hear the questions now..."What day of week do I put if it's a monthly job?", or vice versa. There's a very large chunk of people that would post the question before they would run a simple test to find out.

[dubbeh]

Thanks for the feedback Bittersweet

I see exactly what you mean about syntax and how users will find it quite daunting. When I initially programmed this - I have no idea why i made it quite complex in the first place and avoided the simple crontab format (Didn't implement overlapping value checking - only if the input was in a valid range. Which is another potential problem without understanding the format). Think if I switched to the much more simple input with minute, hour and day, many users would find it easier.

100% agree about the documentation problems - Was a main thing for me to clean up next, after finishing the radio documentation yesterday.

Will get around to switching the input format without all the extra start and end times, and change the wildcard to "*". Only allow minute, hour and day for now then gradually extend if it's requested. Make sure all users know, that each job is a single task, unless you use a full set of wildcards in every input

[Bittersweet]

Originally Posted by dubbeh Thanks for the feedback Bittersweet I see exactly what you mean about syntax and how users will find it quite daunting. When I initially programmed this - I have no idea why i made it quite complex in the first place and avoided the simple crontab format (Didn't implement overlapping value checking - only if the input was in a valid range. Which is another potential problem without understanding the format). Think if I switched to the much more simple input with minute, hour and day, many users would find it easier. 100% agree about the documentation problems - Was a main thing for me to clean up next, after finishing the radio documentation yesterday. Will get around to switching the input format without all the extra start and end times, and change the wildcard to "*". Only allow minute, hour and day for now then gradually extend if it's requested. Make sure all users know, that each job is a single task, unless you use a full set of wildcards in every input

When you say "day", as long as you mean day of week, I think that's perfect for gameservers. There could be some stuff you'd want to run once a month on a particular day, like the 1st or 15th, but that's most database stuff and can usually be done another way. I think the majority of the current users of this plugin use it to change mapcycles during peak hours. I have used it in the past to run a job every couple of hours that changed some startup sound another plugin played to a new player whenever they joined the server.

The only downside I could see to simplifying things the way you so, is that a user may need more individual jobs, but once a user gets the syntax down, that's all copy and paste - like if you want something to run every hour during a certain 4 hour daily peak time, you'd need 4 lines rather than being able to do it in one.

[dubbeh]

Yep, day would mean day of the week, to stop any type of confusion on the format - Feel this is the easiest method to impliment and most efficient.

More i thought about it, more promising it was to add a months option, because of the jobs you could run at certain times of the year. Say for example, It's christmas season - You could run all the custom maps with a christmassy feel to them. Or Haloween - Run a mod that gives all the standard maps a dark gloomy feel.

Last potential option - Jobs based on events, like sc_addjob_event @startup, @shutdown, @mapstart, @mapend, @roundstart, @roundend then a delay option - Say for example "sc_addjob_event @startup delaytimer "job"".
Not too sure about the extra overhead from this though, and If It's really worth It.

[balonfx]

Amazing plugin overall, but I will agree the first thing I thought when opening the plugin was "I wish these reflected the UNIX crons". It was confusing the first time setting it up, being so used to how UNIX has crons already.

Regardless,
Many thanks!

[Bittersweet]

Originally Posted by dubbeh Yep, day would mean day of the week, to stop any type of confusion on the format - Feel this is the easiest method to impliment and most efficient. More i thought about it, more promising it was to add a months option, because of the jobs you could run at certain times of the year. Say for example, It's christmas season - You could run all the custom maps with a christmassy feel to them. Or Haloween - Run a mod that gives all the standard maps a dark gloomy feel. Last potential option - Jobs based on events, like sc_addjob_event @startup, @shutdown, @mapstart, @mapend, @roundstart, @roundend then a delay option - Say for example "sc_addjob_event @startup delaytimer "job"". Not too sure about the extra overhead from this though, and If It's really worth It.

That is an excellent point about the different holiday seasons. I had both Halloween and Thanksgiving/Christmas holiday themes on my server, but I had to do most of the changes manually. Having Crontab do it for you would be great.

[dubbeh]

Release should be ready for sunday at the latest. Using the official UNIX job formats and added a couple of little helper variable.

sc_module_hour_add - Adjust the hour value positively by this amount  - Minimum 0 and Maximum 12
sc_module_hour_sub - Adjust the hour value negatively by this amount  - Minimum 0 and  Maximum 12

Allows admins to make sure jobs always run in the timezone they want - Say for example your server timezone is 2 hours behind localtime (Your current location) and you want jobs to run at GMT or something. set "sc_module_hour_add 2.0" and "sc_module_hour_sub 0.0" to make the jobs run at your local timezone.

This will apply to the returned hour value directly in the main crontab timer - When checking if a task needs to be executed. Saves adding entries and working out the time difference inside the main jobs config.

Quick Edit:
Changed from hour_add and hour_sub to just use hour_adjust now - Two variables was unecessary with console variables being able to use negative values.

[dubbeh]

Removed.. Not using github for now at least.

[dubbeh]

v2.0.0.0 is now released, documentation is linked to my blog and still have to add documentation for the natives.

Changelog:
- Recoded the plugin to use new decals
- Crontabs are now based on the official UNIX format - Read up more about them here
- Added checks for a valid number of parameters - To avoid any potential problems

Have fun

[Trans_Am_00]

Am i doing it right?

/ Reboot the server everyday at 5am - Watch out with this resetting any changes you set inside crontab
sc_addjob 0 5 * * * "_restart"

//Server restart MSG
sc_addjob 55 4 * * * "say Server restarting in 5 mins"
//Server restart MSG
sc_addjob 56 4 * * * "say Server restarting in 4 mins"
//Server restart MSG
sc_addjob 57 4 * * * "say Server restarting in 3 mins"
//Server restart MSG
sc_addjob 58 4 * * * "say Server restarting in 2 mins"
//Server restart MSG
sc_addjob 59 4 * * * "say Server restarting in 1 mins"