Before we only warned if the wait was 1 or higher to solve issues with objects settings timers on themselves while getting qdeleted, a common enough usecase to support (even if it is annoying), but then I remembered we could check for qdestroying directly.
Also fixes it so such `destory()` time timers actually run consistantly. before they would only work if called after the `..()` in `destroy()`
Because sstimer tracks timers internally in the terms of what "byond tick" they are suppose to run at; float wait values are now rounded *up* to the next Byond Tick rather then have byond round the resulting list index *down* at access time.
0 wait timers are now rounded *up* to `world.tick_lag` to avoid incompabilities with editing the current tick's bucket while it was being processed.
* Timer queuing tweaks: binary sorted inserts and rolling buckets.
Client time timers now uses a binary search algorithm for its sorted inserts.
Processing now uses a binary sorted insert, rather then sorting it with sortTim during bucket_shifts.
Buckets now automatically wrap around rather then get regenerated every minute. (Rolling queue)
* Fixes some queue management bugs.
* Fixes a Order of Operations goof up in the ticks<->ds macros.
@ninjanomnom your pain is my success
* Remove debug line
* Fixes some binary insert bugs, fixes client time timers, moved id over to GUID
* Fixes initialization-time timers fucking everything up
* More timer debugging for the debug gods.
* Its times like this I wish I could amend commit from the web interface
* git commit -a -amend&&git push --force
The list of active timers timer_id_dict identifies timers by their numerical id as a string. However this was done using embedded expressions inside the string, which calls num2text with a default of 6 significant figures. This means anything at or above 1 million is expressed in scientific notation.
"timer[1000000]" -> "timer1e+06"
"timer[1000001]" -> "timer1e+06"
Calling num2text manually with 8 significant figures kicks the collision problem down the road to 2^24 (16 million).
nextid is now selectively incremented and is looped back to 1 when reaching the 2^24 threshold.
Also now includes collision checking.
* Makes qdeleted and qdestroying macros
* Makes QDELETED and QDESTROYING uppercase
* Swap qdel checks istype's for != null's
* Fix it
* How was this missed?
* Fixes freon causing lag
Yes, these were stacking. so a turf would have a bunch of "handle wet" timers running on it, every 1.5 seconds, all checking the same shit.
* Fixes unique timers
Making timers run thru qdel will be a cost a pretty fair chunk of resources, and will very likely flood the qdel controller, but it should do for now until i figure out why they randomly decide to stop qdeling.
Also, changes the only thing i think could be an issue causing references to not get cleaned up to be less lean and more forgiving.
I'll revisit this at some point and see if i can't figure this out.
* Fixes timers being left around, Makes addtimer() sanic fast.
This adds a new flag, TIMER_STOPPABLE. Most(80%) of the overhead for addtimer() was in adding the timer to the associated lookup list for deltimer() to use. Moving that functionality to a flag so it wouldn't slow down the 70% of things calling timers puts the final nail in the coffin of byond's sleep/spawn().
spawn: 324 seconds across 5,948,372 calls
addtimer: 67 seconds across 5,953,220 calls
The testing setup for profiling was included in this commit, it will be removed in a later commit. @Fox-McCloud
* Remove profiling procs.
* fix runtime
luckly when this happened, we were about to resume anyways.
hashlist was designed to ensure that timers on different objects with the same name didn't get detected as the same timer, but when I added it, i forgot to make this line actually use the hashlist.
