Crons

[Guest]

Evening,

I was just curious on everyones opinions on crons? Specifically in open source software such as MCC (Version 1). Is it really that bad to use crons? I like them, they are easy to schedule, and there is a less overhead on checks on stuff that would have to be done on every page load.

Is there any reason as to why a game would not use them?

[jcvenom]

I prefer to use crons because its easy and crons are mostly needed in games some games run on server time so it really depends on the game, engine, person really

[Mint Berry Crunch]

I have asked similar questions on other forums and I have been advised to not use them. Some people say it's a sign of bad website design; I don't really know what that means and is probably just a web development standardisation. Others say it's inefficient to update every single user's stat and I don't have a large userbase myself to test whether this is true. Either way, I don't see why I can't do it on page load so I have just gone for that.

[Guest]

Hmm good points, however I would love a diffinative answer, especially if as js says the game is run off server time so every x minutes a user gets x items/stats or whatever,

[Dave]

Depends on what you're using the crons for, if you're doing something like counting down time I'd suggest against using crons in the favor of using the actual time/time stamps.

If you were conducting a clean up that you wanted to run every midnight then that is what a cron is designed for. I wouldn't really expect to see a cron running under an hour though.

[Guest]

Depends on what you're using the crons for, if you're doing something like counting down time I'd suggest against using crons in the favor of using the actual time/time stamps.

If you were conducting a clean up that you wanted to run every midnight then that is what a cron is designed for. I wouldn't really expect to see a cron running under an hour though.

What happens then if the user needs there will updating for instance mccodes? Would that be better on page load to update just that specific user? Or to run a cron every x minutes? I have never used a cron system as my games have never run on system time like that.

[sniko]

What happens then if the user needs there will updating for instance mccodes? Would that be better on page load to update just that specific user? Or to run a cron every x minutes? I have never used a cron system as my games have never run on system time like that.

If you're running such a system on timestamps and requesting approval on each page load, we know that the page needs to be requested from somebody (or something). If you've got no active users on in a said time period, the update won't be called (as no pages will be requested). However, with little math, you can overcome this by;

• User logs in
  
• Timestamp of last update it fetched from the database of said cron file
  
• That timestamp is analyzed with the current timestamp
  
• The cron file iterates through the update process for said amount of times
  
  • Cron file updates every 15 minutes
    
  • No site activity in 45 minutes
    
  • User logs on
    
  • Math works out that the cron missed 3 scheduled updates
    
  • Cron file is run 3 times
    

   

This would - in theory - overcome the situation you've posed.

[Guest]

If you're running such a system on timestamps and requesting approval on each page load, we know that the page needs to be requested from somebody (or something). If you've got no active users on in a said time period, the update won't be called (as no pages will be requested). However, with little math, you can overcome this by;

• User logs in
  
• Timestamp of last update it fetched from the database of said cron file
  
• That timestamp is analyzed with the current timestamp
  
• The cron file iterates through the update process for said amount of times
  
  • Cron file updates every 15 minutes
    
  • No site activity in 45 minutes
    
  • User logs on
    
  • Math works out that the cron missed 3 scheduled updates
    
  • Cron file is run 3 times
    

   

This would - in theory - overcome the situation you've posed.

 

Something of this nature did cross my mind however you explanation made it make more sense to me (mind****?). Anyhow cheers, though a cron would be easier for someone to just use right? Though I do like the logic there :)

[KyleMassacre]

lately when I have been developing particularly small stuff I tend to stay away from crons and use timestamps. But I only use timestamps if its a simple check and maybe delete or update a row based on a user at a time. but I can go both ways on it I guess, it just all depends.

[sniko]

Something of this nature did cross my mind however you explanation made it make more sense to me (mind****?). Anyhow cheers, though a cron would be easier for someone to just use right? Though I do like the logic there :)

It would be all the same (using my logic), apart from not going through a cron scheduler via your host, but a feature to add cron files via ingame staff panel.

The question "a cron would be easier for someone to just use" it open to interpretation. "Use" how?

If done 'correctly', both methods (time stamp and crons) are easy to use. "Every problem is easy to solve if you know how". Regardless, perhaps evaluate your users (I assume this question relates to "Ian-and-Daves-RPG-engine.com" ;)) skill levels, and their needs and requirements, and work around that. Alternatively, provide both solutions.

[Dave]

If you're running such a system on timestamps and requesting approval on each page load, we know that the page needs to be requested from somebody (or something). If you've got no active users on in a said time period, the update won't be called (as no pages will be requested). However, with little math, you can overcome this by;

• User logs in
  
• Timestamp of last update it fetched from the database of said cron file
  
• That timestamp is analyzed with the current timestamp
  
• The cron file iterates through the update process for said amount of times
  
  • Cron file updates every 15 minutes
    
  • No site activity in 45 minutes
    
  • User logs on
    
  • Math works out that the cron missed 3 scheduled updates
    
  • Cron file is run 3 times
    

This would - in theory - overcome the situation you've posed.

This method could potentially make that users page load incredibly high, which you'd want to minimize at all costs.

Unless you got that request from the user to open a process and run the script?

Do you have any examples of what sort of things you can't decide to run through a cron? There maybe other solutions!

[sniko]

This method could potentially make that users page load incredibly high, which you'd want to minimize at all costs.

Unless you got that request from the user to open a process and run the script?

Do you have any examples of what sort of things you can't decide to run through a cron? There maybe other solutions!

I was merely providing an alternative (and the solution) to a problem he had - updating someone's "will" stat every 15 minutes. Granted, the page load would be high, therefore, I guess the developer would have to come to a compromise (loosing some updates, to faster page load)

[Dave]

I was merely providing an alternative (and the solution) to a problem he had - updating someone's "will" stat every 15 minutes. Granted, the page load would be high, therefore, I guess the developer would have to come to a compromise (loosing some updates, to faster page load)

Yeah the page load would be a big issue, especially with browser based games you need instant page loads.

I still think an easy solution would be for the users request to be used to work out how many times the script needs to run then run a server side script to call a cron file that many times. Not entirely sure how you could set this up but wouldn't be to hard.

[Alan]

Clue: The script needs to be called once. Doesn't matter if it's 1 second, 86,400 seconds or 31,536,000 seconds since it was last called.

- - - Updated - - -

Clue: The script needs to be called once. Doesn't matter if it's 1 second, 86,400 seconds or 31,536,000 seconds since it was last called.

[a_bertrand]

To add a bit more... cheating to Alan clues: You can simply store when this part of the code last run, and unless X sec passed, you skip. That should not take too much time. The only issue here is 2 pages calling the code at the exact same time, you may actually run the code twice. I will let you find a work around for it ;)

[Mint Berry Crunch]

If you're running such a system on timestamps and requesting approval on each page load, we know that the page needs to be requested from somebody (or something). If you've got no active users on in a said time period, the update won't be called (as no pages will be requested).

But why is this a problem?

[sniko]

But why is this a problem?

Some users may come online to spend their will points, and go AFK for an hour or so (waiting for it to be refilled). As no pages are being requested, updates are not happening, therefore, it will update once when they log in. They soon realise they cannot go AFK and come back to train at full will points, and eventually, may quit.

- - - Updated - - -

 

But why is this a problem?

Some users may come online to spend their will points, and go AFK for an hour or so (waiting for it to be refilled). As no pages are being requested, updates are not happening, therefore, it will update once when they log in. They soon realise they cannot go AFK and come back to train at full will points, and eventually, may quit.

[Mint Berry Crunch]

Some users may come online to spend their will points, and go AFK for an hour or so (waiting for it to be refilled). As no pages are being requested, updates are not happening, therefore, it will update once when they log in. They soon realise they cannot go AFK and come back to train at full will points, and eventually, may quit.

Will players not figure out that it isn't javascripted and therefore they have to refresh?

Edited June 20, 2013 by Mint Berry Crunch
typo

[sniko]

Will players not figure out that it isn't javascripted and therefore they have to refresh?

I'm not sure we fully understand eachother. For example, if someone is quite an AFK member, and trains their stats up, thinking "energy" will be refilled to maximum after x timeframe, and it hasn't - it may cause them to quit the game entirely, as they would think it's a glitch in the game mechanics (needing to be active to allow regains of stats).

[Mint Berry Crunch]

I'm not sure we fully understand eachother. For example, if someone is quite an AFK member, and trains their stats up, thinking "energy" will be refilled to maximum after x timeframe, and it hasn't - it may cause them to quit the game entirely, as they would think it's a glitch in the game mechanics (needing to be active to allow regains of stats).

I'll admit I'm a bit confused here. So we have a hypothetical game where players spend energy on stuff. Energy is refilled over time, let's say every hour, but needs a page refresh or something from the user. They leave the webpage on for an hour, come back and find nothing has changed. This is what we're saying right? Surely if the player is any right mind they will at least refresh or click on another page to realise their energy has refilled? Let alone closing their browser and logging back in.