Of timers, and regenerating attributes.

[iprice]

This has long been an omission from GPHUD, the ability to run something after a set period of time, the closest so far are Effects, Events, VisitXP and use of the at-logon / character creation script to trigger events that are not the result of a user interaction directly.

Currently almost everything GPHUD does happens off the back of a user interaction, clicking on the HUD, an object, etc, and this effectively "limits" the ammount of events generated, while automatically generated events like timers create a constant demand that isn't reliant on the user even being at the keyboard yet alone engaged/interacting with anything/caring about the results of the timer.

This is not an oversight, this has long been a deliberate decision, because I quickly see the idea of instances writing "every second" timers to recalculate things, for all their players, and this spreading across all the sims, and suddenly I have 500 events per second to handle and distribute the results of to SL if necessary.

As such some kind of "control" is necessary to force sim administrators to consider efficiency in their implementations while still providing flexibility.

Options:

• Restrict the resolution of timers ; e.g. no character may proc a timer more than once every 5 minutes when logged in and hourly when not logged in. This is kinda lame since it means health regen etc would have to be a special case, and there's nothing fundamentally wrong with a couple of users here and there having 10sec regen health loops that turn off once health is full, however if the resolution is 10 seconds, then worst case is a sim misusing timers to proc every player every 10 seconds ; however when you multiply this up by say 50 connected regions with 20 players on each then this still becomes 10 requests per second to process.
• Assign a "quota" formula for timers on an instance or on a player, that is, permit some kind of "bursty pool", like how e.g. (i think) IMs work in second life. Start with a pool of '100 timer events' max, and permit one more event every minute (TBC), that way you can run 100 timer events in that first minute if you like and deplete your pool entirely, but then you'll be "low" on timer events for the next hour, and timer events would end up queueing up. This is actually a nicer solution as it allows careful use of fast timers and a lot more slow timers, and would need some tuning on the regeneration rates of those timer calls, however, it does mean if a user does something that "uses up" their personal allocation then suddenly their health regen will slow down etc - (NOTE encourage users to write interval-independant code rather than assuming interval, that is, if you intend to regen 1 HP every second but because the user ran out of timers it actually took 30 seconds between calls to regen-health then you should 'work out' that 30 seconds = 30 hp to regenerate, not slow down the process to generating 1 hp per 30 seconds/whatever)
• Provide a strictly limited infrastructure ; e.g. allow 1 timer event per minute per character that always fires or something ; fairly constant linearly scaling workload but pretty inflexible and the timer events themselves could contain various loops or something
• On a completely different approach, simply dont allow scripted timer calls, instead have a "timers" module that allows things like per attribute regen rates which can be efficiently 'run' in bulk (? can they, the HUD text updates to SL will generally suck, though 'disseminate' mode for batch updates works better than per HUD runs), and then some other niche setup for other types of timer event people might want
• Hybrid approach - have limited 'tight' timers, and allow longer term (minutes) per character 'freely' (or quotaed with very relaxed quotas)

Please note, this discussion is just to get ideas, not just from my own brain but to invite discussion about uses cases that sims may have and what best suits their needs, or even more usefully, what of the options above present undesirable or potentially problematic limitations versus what suits any expected use cases best.

Also note that this discussion should not be taken to imply that I'm going to implement this any time soon, it's just one of those design decisions I've been pondering for a few months and have concluded that I don't really have enough information to figure the best approach because it's rather use-case dependant; most of the approaches above cover off the safety of the system in terms of workload but they offer different options in terms of what they can achieve.

Also open to any other ideas.

[Nix-Starlight]

I like the idea of HP being able to regenerate on it's own with a timer. That being said I'm not well versed enough in code to understand this. If we could make this simple to code and understand while being flexible, that'd be fantastic. Limited systems are frustrating to deal with. If I'm reading this options B and D might be the more flexible options?

[Kesslan]

Having some form of timer that can be tied to things like energy, hp and various other pools would be very useful for RPGs. That said I agree that the number of timers that could be run per character should be limited. The most I could see cause for is perhaps... 6 if one were to implement something like survival mechanics. (Timer based/affected Health, Energy, Hunger, Thirst, Stamina, Other(