* Removes overlay queuing, saves 6/7 seconds of initialize. Lightly modifies stat tracking macros
So we have this overlay queuing system right? It's build with the assumption
that the "add to overlay list" operation is real expensive, and is
thus useful to queue removals or additions.
It turns out that it just isn't, at least during init. In my testing the
operation of queuing took LONGER then the actual overlay add/remove did.
That's ignoring the cost of the subsystem's work.
I've also modified part of the stat tracking macro, since it took a good
bit of cpu time, and didn't seem to well, do anything. So far as I can
tell it always evaluates to 1
We make the assumption that a turf's heat capacity will never be 0. This is safe because we've got an override of /datum/gas_mixture for turfs that overrides 0 heat cap with 7000 (SPACE)
This is done to make cold actually flow through empty tiles, because we are hacks.
I forgot to include type in my gas mixture creation logic, so this was being dropped. FIXXXX
About The Pull Request
Currently there are a bunch of snowflake checks on the mining shuttle console's attack_hand proc, including a check for TRAIT_ILLITERATE which is hardcoded to specific destinations and is causing issues with the public lavaland shuttle in #69641. When I started looking at that issue I realized that this should all probably be done in ui_interact() instead, and also that checking specifically for TRAIT_ILLITERATE when there's a proc for this (can_read) makes little sense. So I moved it all to ui_interact and cleaned up the TRAIT_ILLITERATE check. I also moved some code related to getting the list of destinations of shuttle consoles into a proc which is shared between the ui_data proc and the can_read check.
Now any illiterate mob which isn't otherwise blocked from interacting (such as monkies, ash lizards, and humans with a quirk) which interact with the shuttle console will spend 10 seconds "randomly mashing buttons" before sending it to a random valid destination. This is (essentially) the current behavior for humans with illiteracy and was (per @timothymtorres ) the intended behavior for ash lizards when he added the illiteracy quirk to begin with in #66648. I'm just making it less snowflakey and I guess technically adding it to monkies too since they could also use the shuttle before that PR and it doesn't make sense to exclude them arbitrarily.
Why It's Good For The Game
Fixes#69641
Generally makes the code more standardized, attack_hand checks are legacy from before ui interact was unified into can_interact and ui_interact. Making the code apply to all shuttle consoles and randomly pick a valid destination makes the more maintainable and less prone to random issues than a hardcoded list.
Also makes the other existing checks more consistent, for example the labor shuttle will now also warn rev heads, block free golems, and let illiterates move them just like the mining and public lavaland shuttles do.
Changelog
cl VexingRaven
fix: The illiteracy quirk will no longer break the mining shuttle
refactor: Refactored some checks on the shuttle console to apply to all consoles
/cl
* 'optimizes' space transitions by like 0.06 seconds, makes them easier to read tho, so that's an upside
* ''''optimizes'''' parsed map loading
I'm honestly not sure how big a difference this makes, looked like small
percentage points if anything
It's a bit more internally concistent at least, which is nice. Also I
understand the system now.
I'd like to think it helped but I think this is kinda a "do you think
it's easier to read" sort of situation. if it did help it was by the
skin of its teeth
* Saves 0.6 seconds off loading meta and lavaland's map files
This is just a lot of micro stuff.
1: Bound checks don't need to be inside for loops, we can instead bound the iteration counts
2: TGM and DMM are parsed differently. in dmm a grid_set is one z level,
in tgm it's one collumn. Realizing this allows you to skip copytexts and
other such silly in the tgm implemenentation, saving a good bit of time
3: Min/max bounds do not need to be checked inside for loops, and can
instead be handled outside of them, because we know the order of x
and y iteration. This saves 0.2 seconds
I may or may not have made the code harder to read, if so let me know
and I'll check it over.
* Micro ops key caching significantly. Fixes macros bug
inserting \ into a dmm with no valid target would just less then loop
the string. Dumb
Anyway, optimizations. I save a LOT of time by not needing to call
find_next_delimiter_position for every entry and var set. (like maybe 0.5
seconds, not totally sure)
I save this by using splittext, which is significantly faster. this
would cause parsing issues if you could embed \n into dmms, but you
can't, so I'm safe.
Lemme see uh, lots of little things, stuff that's suboptimal or could be
done cheaper. Some "hey you and I both know a \" is 2 chars long sort of
stuff
I removed trim_text because the quote trimming was never actually used,
and the space trimming was slower then using the code in trim. I also
micro'd trim to save a bit of time. this saves another maybe 0.5.
Few other things, I think that's the main of it. Gives me the fuzzy
feelings
* Saves 50% of build_coordinate's time
Micro optimizing go brrrrr
I made turf_blacklist an assoc list rather then just a normal one, so
lookups are O(log n) instead of O(n). Also it's faster for the base case
of loading mostly space.
Instead of toggling the map loader right before and right after New()
calls, we toggle at the start of mapload, and disable then reenable if
we check tick. This saves like 0.3 seconds
Rather then tracking an area cache ourselves, and needing to pass it
around, we use a locally static list to reference the global list of
area -> type. This is much faster, if slightly fragile.
Rather then checking for a null turf at every line, we do it at the
start of the proc and not after. Faster this way, tho it can in theory
drop area vvs.
Avoids calling world.preloader_setup unless we actually have a unique
set of attributes. We use another static list to make this comparison
cheap. This saves another 0.3
Rather then checking for area paths in the turf logic, or vis versa, we
assume we are creating the type implied by the index we're reading off.
So only the last type entry will be loaded like a turf, etc.
This is slightly unsafe but saves a good bit of time, and will properly
error on fucked maps.
Also, rather then using a datum to hold preloader vars, we use 2 global
variables. This is faster.
This marks the end of my optimizations for direct maploading. I've
reduced the cost of loading a map by more then 50% now. Get owned.
* Adds a define for maploading tick check
* makes shuttles load again, removes some of the hard limits I had on the reader for profiling
* Macro ops cave generation
Cave generation was insanely more expensive then it had any right to be.
Maybe 0.5 seconds was saved off not doing a range(12) for EVERY SPAWNED
MOB.
0.14 was saved off using expanded weighted lists (A new idea of mine)
This is useful because I can take a weighted list, and condense it into
weight * path count. This is more memory heavy, and costs more to
create, but is so much faster then the proc.
I also added a naive implementation of gcd to make this a bit less bad.
It's not great, but it'll do for this usecase.
Oh and I changed some ChangeTurfs into New()s. I'm still not entirely
sure what the core difference between the two is, but it seems to work
fine.
I believe it's safe because the turf below us hasn't init'd yet, there's
nothing to take from them. It's like 3 seconds faster too so I'll be sad
when it turns out I'm being dumb
* Micros river spawning
This uses the same sort of concepts as the last change, mostly New being
preferable to ChangeTurf at this level of code.
This bit isn't nearly as detailed as the last few, I honestly got a bit
tired. It's still like 0.4 seconds saved tho
* Micros ruin loading
Turns out it saves time if you don't check area type for every tile on a
ruin. Not a whole ton faster, like 0.03, but faster.
Saves even more time (0.1) to not iterate all your ruin's turfs 3 times
to clear away lavaland mobs, when you're IN SPACE who wrote this.
Oh it also saves time to only pull your turf list once, rather then 3
times
About The Pull Request
See title. The vote subsystem needs to load after the persistence subsystem so that the blocked_maps list can be properly populated with data from the RecentMaps.json in the data folder.
This fixes the maps constantly being metastation
Why It's Good For The Game
Same map over and over again = bad
Different maps each time = good
Changelog
cl
fix: Fixed map vote including maps that have already been played twice in the last 3 rounds.
/cl
* Object Window Niceties
Alright. I got bored and polished up the object/alt click window.
It had a few issues:
First, we generated all our images in bulk, as soon as requested
Second, the caching was global, despite only working on a client to
client basis
Third, we only generated up to 10 images. This could be fine, but the
javascript code will continuiously rerender assuming unrendered images
will come eventually, and they well, weren't. This caused MASSIVE
clientside lag
Fourth and finally, I did not like how moving away from the viewed turf
lagged behind, in sync with the stat tab update. Looked bad.
I've resolved all these.
I solved the first three issues by reworking how obj images were
generatated and managed.
Rather then storing a basic cache on the subsystem, and doing all the
image generation at once, we queue up image generation as we like, and
generate images inside a new processing subsystem fire.
This isn't the best solution, since it still eats cpu somewhat, but it's
a whole lot better then the other options, outside either removing the
need to getflat, or somehow predicting what items a client will want to
see
I've started storing three bits of info. First, a list of all the
objects we currently want to display.
Second, a list of atom -> image html
Third, a list of atoms to imageify.
This information is stored on a datum on /client, since I want this to
have a lifetime linked to well, clients.
I've used this datum to solve that fourth bit, using a component I made
for parallax a bit back. This lets me react to our client's mob, and
update the tab linked to that, rather then on a subsystem call by call
basis.
That's about it.
Co-authored-by: san7890 <the@san7890.com>
* Excited groups care about reactions.
Adds reacting var for open turfs. Reacting gets set to the return of react() inside the open turf's process_cell() proc.
Adds turf_reactions var for excited groups. turf_reactions gets set to the result of has_reactions OR reacting. Excited group processing will check if the excited group's has_reactions is REACTING or STOP_REACTIONS before dismantling the excited group. Excited group processing will set the excited group's has_reactions to NONE at the end before MC_TICK_CHECK.
Fixes water vapour not consuming water vapour when temperature is below WATER_VAPOR_DEPOSITION_POINT.
Changes water vapour reaction to have a consumed var, it gets set to MOLES_GAS_VISIBLE when it freezes a turf or makes it slippery. If consumed, then water vapour moles decrease by consumed, set reaction results and set return value to REACTING.
Fixes water_vapour reaction by making its mole count decrease by consumed instead of attempting to do arithmetic on the water vapour list, which somehow didn't runtime.
* Verbose Vote Initiation Feedback Tooltippery
Hey there,
So basically, the old implementation had it such that when a vote was disabled and you tried to trigger it, you could get a very nice message in your chat explaining why you could not trigger that vote in that moment. HOWEVER, there's a current fatal flaw in this logic:
You can't ever get that to_chat reason as to _why_ this vote is disabled since you can't click the button. I don't know if this ever worked, which is sad, because we had a lot of these nice messages that one would never see. So, let's leverage the power of TGUI and add messages.
The messages are applied per-datum singleton, and are a generic explanation of what the vote does when there is no specific reason assigned to it when the can_be_initiated() proc runs. If it can not be initiated, we change the message to reflect exactly why the player can not initiate the vote. It ends up looking something like this:
In order for this to work well for the restart vote and to lessen the amount of copy-pasting I might have to do, I created a new proc that checks to see if a valid admin is online, and uses that for both updating the message and restarting the server if the vote clears.
* fixes messages not resetting
* removes misleading section
the admin can always restart the server if they wish
Ok so in linda turfs use current_cycle to tell if they've been visited
by process_cell yet.
In a recent pr of mine, I expanded its use to init, so I could make sure
we don't double visit tiles.
However, I did this in such a way that it could in theory overrun into a
number that you might find in ssair. So I've changed the logic to make
it decrement, so it's safe in the worst case
When I moved asterioid stuff off /floor, I neglected some logic that
blacklists building on non floors.
Given that this USED to work on you know, asteroid tiles, I think this
is build to catch space and such
So I replaced it with a closed check, and a turfs_without_ground
typecache use, which should serve the same intent
So you can like, you know, ash lizard again
I swear I was gonna do this earlier, just sorta forgot all about it
* Revert "Fixes some access issues in the Lavaland base (#69738)"
This reverts commit a2682d1089.
* renames mining and mining eva
Mining is now Mining Dock
Mining EVA is now Mining Outpost
* A lot of shuttle code improvements
* Makes use of ``as anything`` in many places
* Adds mapload to connect_to_shuttle()
* Renames many vars, including shuttle 'id' var to 'shuttle_id' and engine 'state' to 'engine_state'.
* Engines now weakref their attached ship, and disconnect when unwrenched from it.
* Removes check for force when deleting a mobile docking port, being deleted should still clear your stuff, regardless of being forced.
Because of all the above, I was able to remove a few pointless checks scattered around, like engine's alter_engine_power()
* better comment for port_id
* Fixes Cargo, Arrivals, and Pirate ships.
* Merge branch 'master' into shuttlecode-oh-no
* last few
* fixes the CI
* fixes
* Fixes infinite engines
* Revert "Merge branch 'master' into shuttlecode-oh-no"
This reverts commit 94eba37de9fe3f4a01dc40bb064771b764f379e3.
* trammies
* whiteship tram
* Makes use of ?. instead
apparently this is what weakrefs use, so 🤷
* i hate supernovaa41
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* removes lateinit that I never implemented
* adds _ref to weakref var name
* small change to weld time define
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* Micro optimizes ssair's turf init, saving 2 seconds
Most of this is making existing operations do more legwork, or cheaper.
I did add cycle checking to ONLY init turf linking, which required
creating a new proc.
Did some horrible horrible things in said proc to save like 0.8 seconds.
I think it was worth it.
* Rocking The Boat, er, Map Vote
Hey there,
A while ago, I spooke (typo intentional) to some other people. One frustration I heard was the fact that people would sometimes sneak through map votes during the very start of a shift, during a high-paced portion, or just as a meme. People in OOC would then flood the vote, putting in any given station. However, if a vote happens 10 minutes in- and the round goes for 70 minutes and not many of the original players are around, then it's not particularly fair to those who have to play next shift on a map they bemoan.
So, we can rock the vote! If a player isn't particularly chuffed with the hand they are given, they can poll the players to see if they want to change the map as well. If rocking the vote goes through, huzzah, you get the ability to vote for the map again. If it doesn't go through: tough luck. You can rock the vote one time per shift by default, and server operators can change the amount of times you can call to rock the map vote at their discretion. Calling to rock the vote either successfully or non-successfully counts as a "call", and when that limit is exceeded: no more calls.
Does this mean that we will only rotate between two maps because pissants will keep rocking the vote until they get what they like? Maybe? I still see people bemoan getting Tram or shit the bed over IceBox, but I think enough people get sick of bread-on-butter to take the server where it need to go. If operators don't really like seeing only two maps play, they can always adjust the config to ensure it doesn't happen.
* makes the grammar grammar
it would be "Rock the Vote vote" otherwise
About The Pull Request
Avoids stringifying key unless its necessary. This was done redundantly twice, but I locked it to just the isnum path, as REF will always return a string, and the other path passes istext.
Use sortTim directly instead of sort_list. sort_list is just sortTim but it copies the list, so it's just wasted cost.
I still would like the bespoke element key option, as that's the only way to drastically cut down costs on things like item descriptions and decals, but this is good for the general use case, and makes it marginally less pressing.
I also want to test if we'd be better off inserting into the list in sorted order rather than sorting it all in the end, but I suspect not.
About The Pull Request
Closets now initialize their contents once in dump_contents(). This saves more than 1.6 seconds of init time (all /obj/structure/closet now initialize in 84ms).
Not sure what assumptions this will break, there's a lot of closets, so separate PR.
cl
del: You can no longer see maint spawners before the round starts (but your rounds start faster now :) )
/cl
About The Pull Request
Just to be clear, when I refer to time here, I am not talking about cpu time. I'm talking about real time.
This doesn't significantly reduce the amount of work we do, it just removes a lot of the waiting around we need to do for db calls to finish.
Adds queuing support to sql bans, so if an ongoing ban retrieval query is active any successive ban retrieval attempts will wait for the active query to finish
This uses the number/blocking_query_timeout config option, I hope it's still valid
This system will allow us to precache ban info, in parallel (or in batches)
With this, we can avoid needing to setup all uses of is_banned_from to support parallelization or eat the cost of in-series database requests
Clients who join after initialize will now build a ban cache automatically
Those who join before init is done will be gathered by a batch query sent by a new subsystem, SSban_cache.
This means that any post initalize uses of is_banned_from are worst case by NATURE parallel (since the request is already sent, and we're just waiting for the response)
This saves a lot of headache for implementers (users) of the proc, and saves ~0.9 second from roundstart setup for each client (on /tg/station)
There's a lot of in series is_banned_from calls in there, and this nukes them. This should bring down roundstart join times significantly.
It's hard to say exactly how much, since some cases generate the ban cache at other times.
At base tho, we save about 0.9 seconds of real time per client off doing this stuff in parallel.
Why It's Good For The Game
When I use percentages I'm speaking about cost per player
I don't like how slow roundstart feels, this kills about 66% of that. the rest is a lot of misc things. About 11% (it's actually 16%) is general mob placing which is hard to optimize. 22% is manifest generation, most of which is GetFlatIcons which REALLY do not need to be holding up the main thread of execution.
An additional 1 second is constant cost from a db query we make to tell the server we exist, which can be made async to avoid holding the proc chain.
That's it. I'm bullying someone into working on the manifest issue, so that should just leave 16% of mob placing, which is really not that bad compared to what we have now.
Changelog
cl
code: The time between the round starting and the game like, actually starting has been reduced by 66%
refactor: I've slightly changed how ban caches are generated, admins please let me know if anything goes fuckey
server: I'm using the blocking_query_timeout config. Make sure it's up to date and all.
/cl
About The Pull Request
Timers clamped their waits to >world.tick_lag and rounded it to multiples of the same, but this is invalid for clienttime timers. Clienttime timers have a resolution of one decisecond instead, so we now clamp and round it to that instead. (The stacktrace for negative waits is technically invalid but I didn't care enough to touch it.)
Thanks to LemonInTheDark and MrStonedOne for their help in tracking this issue down.
Why It's Good For The Game
These are effectively zero-wait timers, which can mess up the iteration of the clienttime timer queue by being inserted into the past or current tick's list and causing the head/index to desync, potentially leaving spent timers in the queue or firing them again.
* Adds lazyloading to the asset subsystems
This currently applies only to spritesheets because of how monumentally
expensive they are.
If an asset is requested it will immediately be fully loaded, but
otherwise we slowly load them in with a separate subsystem.
This allows us to not hold up initialize with hair stuff. Saves roughly
33% (16 seconds with LOW_MEMORY_MODE) of initialize on my machine
My target is something closer to the 9 second init that had back in
2019, this is a good first step. Lets see how much more we can do yeah
lads?
Co-authored-by: san7890 <the@san7890.com>
About The Pull Request
I DID NOT TEST THIS. I DO NOT KNOW DATABASE STUFF. I JUST NOTICED IT WHILE WORKING ON AN UNRELATED PR.
Title.
Why It's Good For The Game
Speeds up a hot proc substantially
* Minor QuerySelect improvements coded from the porcelain throne.
We don't handle bad values being given in the query list well enough. This normally won't matter, runtimes are runtimes, but if mixed with real queries, it can lead to inconsistent state where we have query datums that have been ran, and query datums that have not been ran.
pre-checking is also an option, so that it can just refuse to run any of them if one is bad by checking before, but my main goal was to prevent runtimes from bad inputs leading to undeleted queries spam while being more clear about where the bug is, not try to perfectly handle the side effects of bad code.
(To be clear, i started intending to just add codedoc but now it uses as anything and typechecks because that was just eating at me while typing up the codedoc.)
* Update code/controllers/subsystem/dbcore.dm
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Puts level traits and their associated z into a list and then uses it to make the z level trait procs less shit. They no longer need to loop through every z level to do what they aim to do.
* Also removes get_level from level_trait because it just does the same checks as already done above in the proc.
* Be less scary.
Changes radiation pulses so that they store the turfs they need to irradiate, iterate through them and remove them from the list of turfs to irradiate, then yield to MC if MC got angry, and put the radiation pulse with the remaining turfs to irradiate to the back of the radiation processing list.
Radiation pulses pulse information will no longer popleft the processing list. It will delete itself once there are no turfs to process, or if the source is null.
Caches the turfs to process to loop through, adds a counter for how many turfs it iterated through, and cuts the turfs to process by the turfs that got iterated.
thanks to Vallat for pointing this out
whoops turns out most verbs havent been queued since may 11th because I made /datum/controller/subsystem/verb_manager have the SS_NO_INIT flag, without also removing a check in verb_manager/proc/can_queue_verb() that stops the verb callback from being queued if the subsystem isnt initialized yet. since subsystems with SS_NO_INIT obviously never have initialized set to TRUE, this always failed for every verb manager subsystem except for SSinput (because it doesnt have SS_NO_INIT).
also adds a debug var to force a subsystem to always queue incoming verbs if possible.
now the default verb management subsystem, and speech_controller will successfully queue verbs again. SSinput always queued verbs so that shouldnt change.
When 65% or more of the station is revs, the shuttle will automatically call. This shuttle can be recalled.
Approved with majority vote from me and @ninjanomnom
Should probably be test merged first, I touched some core shuttle code.
Roughly 60% of rev victories I checked called the shuttle shortly after. That's a lot, but there's still a high amount that aren't, either because the population genuinely wants to stay, or the revolutionary victory was a surprise. The latter of which I had happen to me like, recently! Remember that was the core problem revs victories continuing the round was trying to fix.
With that in mind, this plays nicely with both some player grievances with post-revs while keeping in line with the core of the feature. Players are still, in part, controlling the end of the round, but with affordance given to the most likely scenario.
About The Pull Request
Ports yogstation13/Yogstation#13983
This pr effectively halves the damage of explosion epicenters by making them only affect mobs once. Specifically, it removes them from the list of things to explode created by the get_all_contents proc, originally meant to ensure stuff in bags and boxes will set off other bombs in the same bag or box. This had the un(?)intended side-effect of making any objects in the epicenter of the blast take damage a second time, resulting in heavy blasts instakilling and very small explosions doing way too much damage. This is half a balance change and half a bug fix.
Why It's Good For The Game
This allows for more explosion-based weaponry as they now won't all be complete one-shot-win weapons. It also stops things like X4 bolas or explosive holoparasite bolas (you guys have those right?) instantly killing people with no counterplay. Also fireball is now probably a little less meta as a spell since it ONLY PROBABLY immediately wins fights and won't two-shot-crit people, usually. If yall want stuff to still do the same amount of damage just add an extra single-tile explosion to things you want to be more powerful.
Changelog
cl Mqiib, ToasterBiome
balance: Explosion epicenters no longer explode mobs twice; Fireballs and other explosive projectiles are significantly less-damaging
/cl
About The Pull Request
replaces a ton of log_game with user.log_message so the log is added to individual and global logs.
adds a few logs for individual LOG_VICTIM, LOG_ATTACK etc logging.
adds logging for bluespace launchpad's tele coords being changed.
took the word "has" out of log_combat, as it's extra and just lengthens the log.
Why It's Good For The Admins
It's extremely laggy to open game.txt so an alternative is individual game logs
Changelog
cl
admin: A lot of game logs will now also be in individual game logs, for convenience in log diving.
admin: Added logging for bluespace launchpad x and y offset changes, which go to individual game logs.
admin: Attack logs will now be slightly shorter, one useless word was removed.
/cl
About The Pull Request
kép
This PR does the following:
Force event menu uses tgUI.
Arranged events into categories, and added a little description to each. The descriptions appear as tooltips when you hover over the Trigger button.
Rewrote how "Announce to crew?" works. It no longer pops up a panel after the event has been already announced. Instead, the admins select it via a checkbox, and the result is passed through an optional argument.
announceChance's comment is tweaked a bit to reflect how it actually works at the moment.
Moved rpgtitles to wizard events, where it belongs.
Fake Virus and Electric Storms show up to observers, as I believe they are not as common as Space Dust or Camera Failure, and should be cancelable.
Potential issues:
This only solves half of #68408, I don't think admin triggering having a timer and a cancel button is a big issue, as it allows other admins to overrule you if needed, but if i is, I will try to fix it within this PR.
Fixes#68408. Events now spawn immediately, and the the announceChance is overwritten before it begins.
My choices for categories and descriptions might not be the best, feedback would be appreciated.
Why It's Good For The Game
The old spawn menu was completely unorganized, and you could only search using the browser search tool. I believe a built in search bar helps with this issue a bit. I also believe that organizing the events into categories, and adding descriptions will help with newer admins who might not be familiar with all events.
Changelog
cl
refactor: The Force Event UI has been refactored
refactor: Events now have categories and descriptions
refactor: Admin triggered events happen immediately
balance: Fake Virus and Electric Storms are shown to admins, making them cancelable
/cl
This pr goes through: /client/Click(), /client/Topic(), /mob/living/verb/resist(), /mob/verb/quick_equip(), /mob/verb/examinate(), and /mob/verb/mode() and makes them queue their functionality to a subsystem to execute in the next tick if the server is overloaded. To do this a new subsystem is made to handle most verbs called SSverb_manager, if the server is overloaded the verb queues itself in the subsystem and returns, then near the start of the next tick that verb is resumed with the provided callback. The verbs are called directly after SSinput, and the subsystem does not yield until its queue is completely finished.
The exception are clicks from player input since they are extremely important for the feeling of responsiveness. I considered not queuing them but theyre too expensive not to, suffering from a death of a thousand cuts performance wise from many many things in the process adding up. Instead clicks are executed at the very start of the next tick, as the first action that SSinput completes, before player movement is processed even.
A few months ago, before I died I was trying to figure out why games at midpop (40-50 people) had non zero and consistent time dilation without maptick being consistently above 28% (which is when the MC stops yielding for maptick if its overloaded). I found it out, started working on this pr, then promptly died. luckily im a bit less dead now
the current MC has a problem: the cost of verbs is completely and totally invisible to it, it cannot account for them. Why is this bad? because verbs are the last thing to execute in the tick, after the MC and SendMaps have finished executing.
tick diagram2
If the MC is overloaded and uses 100% of the time it allots itself this means that if SendMaps uses the amount its expected to take, verbs have at most 2% of the tick to execute in before they are overtiming and thus delaying the start of the next tick. This is bad, and im 99% sure this is the majority of our overtime.
Take Click() for example. Click isnt listed as a verb but since its called as a result of client commands its executed at the end of the tick like other verbs. in this random 80 pop sybil round profile i had saved on my computer sybil 80 pop (2).txt /client/Click() has an overtime of only 1.8 seconds, which isnt that bad. however it has a self cpu of 2.5 seconds meaning 1.8/2.5 = 72% of its time is overtiming, and it also is calling 80.2 seconds worth of total cpu, which means that more than 57.7 seconds of overtime is attributed to just /client/Click() executing at the very end of a tick. the reason why this isnt obvious is just because the verbs themselves typically dont have high enough self cpu to get high enough on the rankings of overtiming procs to be noticed, all of their overtime is distributed among a ton of procs they call in the chain.
Since i cant guarantee the MC resumes at the very start of the next tick due to other sleeping procs almost always resuming first: I time the duration between clicks being queued up for the next tick and when theyre actually executed. if it exceeds 20 milliseconds of added latency (less than one tenth the average human reaction time) clicks will execute immediately instead of queuing, this should make instances where a player can notice the added latency a vanishingly small minority of cases. still, this should be tm'd
This PR fixes this issue by making sure every proc called in the stack of /proc/wrap_lua_print which could sleep is called using INVOKE_ASYNC, and to prevent such problems in the future, marks all the wrappers as SHOULD_NOT_SLEEP(TRUE). I also figured out how to fix the dumb overflowing problem of the lua editor ui.
Due to lag concerns regarding lua states with a large number of global variables (including fields within global tables), I have made it so the global table and state log are hidden by default - they can be shown using a toggle button in the editor ui.
A pretty heavy refactor for pAIs that just spilled into a rework.
Attempts to fully document and organize backend code.
Fixes a large number of bugs left untouched for a decade.
Breaks down the frontend into subcomponents.
Rebalances their software modules.
(should) fix pAI faces get removed if you activate them during alert #68242
LemonInTheDark