About The Pull Request
I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.)
This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering.
I'll do my best to keep this compact, but there's only so much I can do. Sorry brother.
Core idea
OK: first thing.
vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc.
This is bad. But how to do better?
It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly.
We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed.
But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect.
Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on).
That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly.
Everything else is just gravy.
About the Plane Cube
Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane.
We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live.
As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well.
Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you.
About Plane Master Groups
BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc)
Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc.
So we need to maintain a mirror of each plane for every map we have open.
This was quite messy, so I've refactored it (and maps too) to be a bit more modular.
Rather then storing a list of plane masters, we store a list of plane master group datums.
Each datum is in charge of the plane masters for its particular map, both creating them, and managing them.
Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to.
Much better then the hardcoded pattern we used to use. So much duplicated code man.
Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers.
image
In addition, I've added a debug ui for plane masters.
It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays.
It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live.
In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc.
It also comes with an info dump about the ui, and plane masters/relays in general.
Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible.
See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md.
"Landing" planes
Ok so I've explained the backend, but how do we actually land planes properly?
Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use.
This is just a lot of gruntwork, but it's occasionally more complex.
Sometimes we need to cache a list of z layer -> effect, and then use that.
Also a LOT of updating on z move. So much z move shit.
Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags.
This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday
I also need to update mob overlays on move.
I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order.
The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet.
It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point.
Behavior changes
We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it.
So instead we display the other side as a ui element. It's worse, but not that bad.
Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior.
The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane.
I don't really care, but it should be fixable, I think, given elbow grease.
Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think.
Why It's Good For The Game
<visual candy>
Fixes#65800Fixes#68461
Changelog
cl
refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it
admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb
/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>
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
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
About The Pull Request
adds the Refresh TGUI verb to the debug category OOC category, but it isn't locked behind any permissions. i'd put it in OOC, but.. eeeeeeh? there's not real much use for this verb other for debuggers. i put it in the OOC category
Why It's Good For The Game
debug purposes mostly
not player facing lole
* Ports the player ticket panel from skyrat
Adds a player side panel to view active admin tickets, this will make it
easier for players to find previous admin messages, remember what they
said previously etc. This is especially good for the cases that TGchat
drops messages
refactors the status panel to utilize the tgui/byond communication APIs instead of passing along href data, as well as converts the entirety of it into a datum/tgui_window
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
* Alright, so I'm optimizing parallax code so I can justify making it do a
bit more work
To that end, lets make the checks it does each process event based.
There's two. One is for a difference in view, which is an easy fix since
I added a view setter like a year back now.
The second is something planets do when you change your z level.
This gets more complicated, because we're "owned" by a client.
So the only real pattern we can use to hook into the client's mob's
movement is something like connect_loc_behalf.
So, I've made connect_mob_behalf. Fuck you.
This saves a proc call and some redundant logic
* Fixes random parallax stuttering
Ok so this is kinda a weird one but hear me out.
Parallax has this concept of "direction" that some areas use, mostly
the shuttle transit ones. Set when you move into a new area.
So of course it has a setter. If you pass it a direction that it doesn't
already have, it'll start up the movement animation, and disable normal
parallax for a bit to give it some time to get going.
This var is typically set to 0.
The problem is we were setting /area/space's direction to null in
shuttle movement code, because of a forgotten proc arg.
Null is of course different then 0, so this would trigger a halt in
parallax processing.
This causes a lot of strange stutters in parallax, mostly when you're
moving between nearspace and space. It looks really bad, and I'm a bit
suprised none noticed.
I've fixed it, and added a default arg to the setter to prevent this
class of issue in future. Things look a good bit nicer this way
* Adds animation back to parallax
Ok so like, I know this was removed and "none could tell" and whatever,
and in fairness this animation method is a bit crummy.
What we really want to do is eliminate "halts" and "jumps" in the
parallax moveemnt. So it should be smooth.
As it is on live now, this just isn't what happens, you get jumping
between offsets. Looks frankly, horrible. Especially on the station.
Just what I've done won't be enough however, because what we need to do
is match our parallax scroll speed with our current glide speed. I need
to figure out how to do this well, and I have a feeling it will involve
some system of managing glide sources.
Anyway for now the animation looks really nice for ghosts with default
(high) settings, since they share the same delay.
I've done some refactoring to how old animation code worked pre (4b04f9012d). Two major
changes tho.
First, instead of doing all the animate checks each time we loop over a
layer, we only do the layer dependant ones. This saves a good bit of
time.
Second, we animate movement on absolute layers too. They're staying in
the same position, but they still move on the screen, so we do the same
gental leaning. This has a very nice visual effect.
Oh and I cleaned up some of the code slightly.
* makes hud images only apply by z level
* makes some of the atom_hud procs have better names
* fixes warning with the hud_user list and adds better documentation
* better docs for hud_images
* removes TODOs
* docs for hud_list
* adds support for linked z levels so mobs can see lower ones
* fixes merge conflict and shittily makes only shocked airlocks get added
* adds support for setting images in the hud as active and inactive
* gets rid of unatomic spatial grid change
* maybe i should actually try COMPILING my changes
* fixes merge skew and makes it compile again
* fixes huds refusing to remove from users who changed z level
* improves z level and registration logic
* fixes antag huds not appearing
* Fixes antag huds not properly setting. We now use hud_list in init, so it needs to be set before the new call, not after. Not sure why the use of appearance key was split like this, but none else knows either so none can stop me
* Ensures that hiding a basic appearance also hides the atom's active list too
* Fixes antag huds going poof
Ensures that remove_atom_from_hud will return false if the passed atom
isn't managed by it
This fixes antag huds disappearing randomly, since they assumed that if
the parent call of remove_atom_from_hud returned true, we should delete
ourselves. This is a safe assumption for them to make, since they should
only ever have one atom.
Does kinda bork if we call remove_atom_from_hud in a way that is unsure
if the passed atom is actually in that list. We were forced into doing
this by how atom huds use the qdeleting signal.
* makes basic alternate_appearance's only update themselves when setting their hud image to active and makes them not add themselves to the global huds_by_category list
* fixes mistake with hud_users list being set non associatively (bad)
* as anything in bot path loops
* Fixes merge skew problems
* Makes bot paths non global
This way they can show themselves to only the bot that "owns" them, ya
feel me?
* Fixes huds not showing up sometimes, cleans up some code
Post Kapu's limb refactor, we were calling prepare_huds twice in a human
init call chain. What was happening was this:
call prepare_huds() // Human
I gained a new hud image
I set active hud icons to mirror it
call prepare_huds() // Living
I overwrote the new hud image
I attempted to set active hud icons, which failed because it assumes
this can never happen
*cries*
* Renames add_hud_to_atom to show_to
My hope is this will make understanding hud code a bit easier, by tying
the behavior to a "verb" more closely. Also renamed a few vars
* remove_hud_from_mob -> hide_from
* Nitpicks a few comments
* Whoops/fuck/shit/damn it all/hhhhhhhhhhhh
* Moves check down, improves stack trace a bit
Co-authored-by: KylerAce <kylerlumpkin1@gmail.com>
About The Pull Request
Moves the Help menu to the end of the menu bar, like every app that has ever had a Help menu.
image
Makes Hotkeys Help actually do something, given the verb that menu item calls was removed 3 years ago.
It now show all of your hotkeys, as set in preferences, in a TGUI table. They're in Binding sort order, as opposed to the preferences window, which may be of use to people.
image
Why It's Good For The Game
halp how do i standup
Changelog
cl
add: Re-added the Hotkeys-Help verb, and linked the Hotkeys menu item to it.
qol: Move Help menu to the end of the menu bar.
/cl
About The Pull Request
I noticed a lot of strange and un-intuitive behavior in action buttons, and got stung by the bloat bug. Damn it hug #58027
I'll do my best to explain what I've changed and why, might get a bit long.
If you want a better idea, read the commits. Most of em are pretty solid, if long.
Whelp. Here we go.
How do action buttons currently work
All action buttons are draggable, to any place on the screen. They're held in an actions list on the player's mob.
Their location in this list determines their position on the top of the screen. If one is dragged away from the top, its position in the list is "saved". This looks really bad.
If two buttons are dragged over each other, their positions swap. (inside the actions list too)
If a button is shift clicked, it is brought back to the position it started at.
If the action collapse button that you likely just mentally edit out is alt clicked, it resets the position of all action buttons on the screen.
If an action is ctrl clicked, it is "locked". This prevents any future position changes, and also enables a saving feature. With this saving feature, locked button positions persist between rounds. So your first o2 canister will always start where you saved it, etc.
Actions and buttons are a one to one link. While there is functionality to share action buttons between two players, this means showing the same object to both. So one player can move a button on another's screen. Horrendous.
This also makes code that modifies properties of the screen object itself very clunky.
Why is this bad
A: None knew pretty much any of this information. It is actually documented, just in a horribly formatted screen tip on the collapse button, you know the one we all mentally delete from the hud.
B: None of this is intuitive. Dragging buttons makes the hud look much worse, and you get no feedback that you even can drag them. Depressing
C: We use actions to make new options clear to the player. This means players can have a lot of action buttons on the hud. This gets cluttery
D: The collapse button is useless. It lets you clear your screen if someone like me fucks up and gives you 2000 actions, but outside of that it just hides all information from you. You never want to see none of your action buttons, just a filtered list of them.
E: On a technical level, they're quite messy, and not fully functionally complete. This is depressing.
What I've done
Assuming the above to be true, how do we fix them?
Well first I'm going to go over everything I changed, including links to major commits. I'll then describe the finished product, and why I made the decisions I did.
Oh and I've moved some of the more niche or technical discussion to dropdowns. Hopefully this makes finding the major functional changes easier
Adds helper procs for turning screen_loc strings into more manageable arrays. This doesn't fully support all of the screen_loc spec, but it's enough for what I'm doing. (f54865f)
Uses these helper procs to improve existing code (6273b93)
Fixes an issue with tooltip code itself. If you tried to hold down a mouse button while dragging onto a tooltip enabled object, it would silently fail. The js made assumptions about the order args came in, which broke when buttons were held down (e0e42f6)
Adds a signal linked to /client/Click(). Surprised we didn't have this before honestly (c491a4a)
Makes /client/MouseDrag() return parent. If we don't do this, any overrides of MouseDrag will never actually be called (2190b2a)
Refactors how action buttons work under the hood (53ccce2)
Basically, rather then generating one button per action, we generate one button per viewer
Starts to change button behavior, more cleanup
Changes the mouse cursor when an action button is dragged. Hopefully
this makes moving things feel less like an accident, and makes you doing
it more clear
Removes the moved and locked vars. This will be more relevant later, but
for now:
Moved exists as a sort of budget "We've been dragged" variable. We can
handle this more cleanly, and the movable type doesn't care about it
Locked is a very old variable that is also not something that the
movable type "owns". It's more an action button thing that's been moved
down.
It exists so an action can be locked in place, and in that locking, be
treated as a "saved location"
(21e20fc)
Because I've nuked move, we don't need to directly set our button's
position. We can use the default_button_position var instead. This is
quite handy.
Please ignore position_action, I will explain that later
(83e265e)
Removes the buttons locked pref
It was another obscure part of action buttons, basically do buttons
start "locked" or not. See previous discussion of locked
(b58b1bd)
Major rework starts here
Alright. Sorry for this, this is where me not commiting regularly starts
to suck. I'll do my best though.
Rather then figuring out an action button's position via a combination
of the moved and ordered vars, we use a separate location var to store
one of a few defines. This makes life later much easier.
Adds tooltip support for dragging action buttons. The way the tooltip
just froze in place when dragging really bugged me, and lead to some
nasty visual artifacts.
This is a bit messy because the drag procs are horrible, but it's
workable
Dropping a button on another button will no longer swap their positions
Behavior instead depends on the target button.
If it's a part of a group (A concept I will explain later) the dragged
button is simply inserted before it in the group's list.
If it's floating on the general hud, we instead position the dragged
button to its right. There's extra logic here to ensure buttons will
never overflow the screen, but I'll get into that later.
Alright. That's most of the refactoring. Time for the larger behavior
changes.
Adds a button palette. This is a separate dropdown that renders
underneath buttons.
image
The idea is to allow for a conceptual separation between "important"
buttons and the ones that end up cluttering the screen.
You can click on the dropdown to open it, then any later clicks that
don't involve actions in some way will autoclose it.
My goal is to come up with an alternative for the action button that
just acted as a way to hide all buttons on screen. Not convinced it saw
much use.
As a side effect of removing that, I've moved its tooltip stuff to the
palette. I've properly formatted it, so hopefully it's easier to read
then the jumble that we used to have.
(You can alt click the palette button to reset all button positions)
Oh and the palette can scroll, since as you'll see later it has a
limited size.
image
Moving on from that, I've added what amounts to action landing buttons.
These allow buttons to rejoin groups, or be positioned at the end of a
line of buttons.
image
They've got a 32x32 hitbox, and only show up when dragging. Hopefully
this makes the system more clear just by dragging an action.
Oh and I've changed how button position updating works. The old system
of calling update_action_buttons on mob every time an action button
changes position is gone, mostly because I've setup more robust
grouping. Will discuss when I get to huds
(0d1e93f)
Adds the backbone behind action button position changes (94133bd)
Moves hud defines to the global folder, safer this way (7260117)
Adds color changing to the palette button, giving some heads up for buttons being inserted into the palette automatically
image
image
Ensures a landing button is always shown, even if it needs to break the
max row rule
Makes palettes auto contract if they have no buttons inside them
Prevents palettes from being opened if they have no buttons inside them
(f9417f3)
How it looks
2022-02-26.02-30-10.mp4
Why It's Good For The Game
Players have more control over the clutter on their screen.
Buttons are available, but not in the way,
Since any player move of a button saves it, any lack of clarity in the way buttons work will be forced out by buttons not just resetting when a new game starts.
We don't overlap any existing screen elements, unless the upper button list gets really long.
The code is much less crummy (I think, may have made it worse it's hard for me to judge my own work)
If it ends up not being as usable as I'd like, I'll rip out the existing changes and just implement the qol and backend stuff. I think it's worth doing though.
Changelog
cl
add: Expanded heavily on action buttons
add: Adds an action button dropdown that sits just under the normal list in the top left. You can drag new buttons onto it to insert them. Click on it to show its contents, do what you want to do, then click again anywhere to contract it. Alt click it to reset all button positions
add: Action buttons will now remember their position between rounds. So if you really like your flashlight right next to your player for some reason, we support that now
add: When you start to drag an action button, docking ports will appear in places that it can be inserted into. (Outside of just floating somewhere on your screen of course)
del: Removed action button locking, and the associated preference. I'm reasonably sure literally none uses this, but if you do hit me up
qol: Dragging an action button will now give you an outline of its size around your cursor
fix: You can no longer cause the screen to expand by putting an action button on the edge of widescreen, and then resizing to standard.
refactor: Refactors action and button code significantly. lots of little things.
/cl
* Fit Viewport cleanup
Changes how Fit Viewport works slightly.
From what I understand, the verb was created with the goal of
eliminating the pixel hunting required to get rid of letterboxing.
This works fine for stretch to fit, but ever since the command bar got
nuked it's ended up creating a lot of blackspace for targeted zoom
modes.
I've changed how it decides on its optimal width slightly, if the client
has a non stretch to fit zoom mode, we use it, the world icon size and
the clients view size to figure out the exact width we want.
The bars on the left and right have been bugging me forever. Want them
gone.
In light of this, I'm also making changing your zoom amount attempt to
fit the viewport, if you have the pref enabled.
Oh and I'm trying something with auto fit viewport stuff.
It currently waits a second between view change and fitting. The comment
implies this is to avoid winget strangeness from Login calls. When I
blamed it, I found a commit from antruk talking about client dropping,
and this being a potential fix.
Unfortunately none wrote down what dropping means, and anturk's
forgotten.
I'm making the assumption that it's related to attempting the related
winsets before an inital login is over.
I might be wrong about this, if I am we'll know what went wrong I
suppose.
* Whoops, this needs to be invoke async
* Ensures client safety, autodocs code, adds proper cleanup
* Makes deadchat control inputs bypass automute.
It's slightly annoying when you get muted because you spent a minute trying to get the supermatter to move down.
makes most updating stat panel tabs update once every 4 seconds instead of 4 deciseconds, but switching tabs instantly updates statpanel data for you. also makes examining a turf make flat icons for a maximum of 10 contents instead of 30 because its ridiculous to call getFuckingFlatIcon() wrappers that many times. also makes SSfluids not have SS_TICKER and updates its wait accordingly because theres no reason for it to be a ticker subsystem
the mc tab updates every 2 seconds unless someone has the pref enabled to refresh it quickly because SOME UNILLUMINATED LEMONS absolutely must watch overtime spikes in real time
statpanels can take between 1-3% of masters total processing time at very high pop, which is silly considering theres no need for someone to know any of the data updated accurate to less than half of a second. The only reason it needed to update so fast was because it looked awful when switching tabs, which will only be updated on the next fire. now switching tabs updates data instantly so theres no need to update the rest of the data quickly.
also makes each stat tab update into its own proc so we can tell how much each tab update costs
bout The Pull Request
MouseEntered currently fires multiple (multiple) times per frame, presumably over every atom that was hovered in some timeframe (though it appears to be much worse than that).
This makes MouseEntered only add to a queue, while a per-tick subsystem ensures only the most recent MouseEntered gets the screentip work done on it, through a generic on_mouse_enter proc call.
Contextual screen tips are coming and are going to make the screen tip code more computationally expensive, so slimming it down is going to be a must.
Would like to hear from @LemonInTheDark if this makes any obvious difference in time dilation, since it of course won't be as easy as just checking MouseEntered overtime anymore.
a month or two ago i realized that on master the reason why get_hearers_in_view() overtimes so much (ie one of our highest overtiming procs at highpop) is because when you transmit a radio signal over the common channel, it can take ~20 MILLISECONDS, which isnt good when 1. player verbs and commands usually execute after SendMaps processes for that tick, meaning they can execute AFTER the tick was supposed to start if master is overloaded and theres a lot of maptick 2. each of our server ticks are only 50 ms, so i started on optimizing this.
the main optimization was SSspatial_grid which allows searching through 15x15 spatial_grid_cell datums (one set for each z level) far faster than iterating over movables in view() to look for what you want. now all hearing sensitive movables in the 5x5 areas associated with each spatial_grid_cell datum are stored in the datum (so are client mobs). when you search for one of the stored "types" (hearable or client mob) in a radius around a center, it just needs to
iterate over the cell datums in range
add the content type you want from the datums to a list
subtract contents that arent in range, then contents not in line of sight
return the list
from benchmarks, this makes short range searches like what is used with radio code (it goes over every radio connected to a radio channel that can hear the signal then calls get_hearers_in_view() to search in the radios canhear_range which is at most 3) about 3-10 times faster depending on workload. the line of sight algorithm scales well with range but not very well if it has to check LOS to > 100 objects, which seems incredibly rare for this workload, the largest range any radio in the game searches through is only 3 tiles
the second optimization is to enforce complex setter vars for radios that removes them from the global radio list if they couldnt actually receive any radio transmissions from a given frequency in the first place.
the third optimization i did was massively reduce the number of hearables on the station by making hologram projectors not hear if dont have an active call/anything that would make them need hearing. so one of hte most common non player hearables that require view iteration to find is crossed out.
also implements a variation of an idea oranges had on how to speed up get_hearers_in_view() now that ive realized that view() cant be replicated by a raycasting algorithm. it distributes pregenerated abstract /mob/oranges_ear instances to all hearables in range such that theres at max one per turf and then iterates through only those mobs to take advantage of type-specific view() optimizations and just adds up the references in each one to create the list of hearing atoms, then puts the oranges_ear mobs back into nullspace. this is about 2x as fast as the get_hearers_in_view() on master
holy FUCK its fast. like really fucking fast. the only costly part of the radio transmission pipeline i dont touch is mob/living/Hear() which takes ~100 microseconds on live but searching through every radio in the world with get_hearers_in_radio_ranges() -> get_hearers_in_view() is much faster, as well as the filtering radios step
the spatial grid searching proc is about 36 microseconds/call at 10 range and 16 microseconds at 3 range in the captains office (relatively many hearables in view), the new get_hearers_in_view() was 4.16 times faster than get_hearers_in_view_old() at 10 range and 4.59 times faster at 3 range
SSspatial_grid could be used for a lot more things other than just radio and say code, i just didnt implement it. for example since the cells are datums you could get all cells in a radius then register for new objects entering them then activate when a player enters your radius. this is something that would require either very expensive view() calls or iterating over every player in the global list and calling get_dist() on them which isnt that expensive but is still worse than it needs to be
on normal get_hearers_in_view cost the new version that uses /mob/oranges_ear instances is about 2x faster than the old version, especially since the number of hearing sensitive movables has been brought down dramatically.
with get_hearers_in_view_oranges_ear() being the benchmark proc that implements this system and get_hearers_in_view() being a slightly optimized version of the version we have on master, get_hearers_in_view_as() being a more optimized version of the one we have on master, and get_hearers_in_LOS() being the raycasting version currently only used for radios because it cant replicate view()'s behavior perfectly.
bring code up to latest standards, move many procs to named files inside _HELPERS
no idea where to put some of these procs, help is appreciated
made more files to contain some unique code, deleted unsorted.dm, we can rest now
This pr (maybe) fixes#61383 . Testing it is difficult as I don't know how to set up a DB on local - I suggest a testmerge on Manuel?
If panic bunker interviews are enabled, everyone should be able to connect - either they have enough hours and don't need an interview or are a new player and will enter an interview.
If panic bunker interviews are disabled, we then check panic_bunker_living.
If 0, we only check for whether the client has a database entry.
If a set number, we check for the client's playtime vs that number. (Players underneath the living playtime, will be prompted to fill out an interview)
#60289 made it so people who should bypass the panic bunker to enter an interview were wrongfully rejected.
Since the default value for living time was 0, and the time we use on the game servers was 0, it ALWAYS rejected new players from entering the game, even if interviews was enabled.
Fixes#61515. Preferences were only applied on load_preferences(), which only fires when the preferences datum is created. Preferences datums are cached, and so load_preferences is only called the once.
About The Pull Request
Rewrites the entire preferences menu in tgui. Rewrites the entire backend to be built upon datumized preferences, rather than constant additions to the preferences base datum.
Splits game preferences into its own window.
Antagonists are now split into their individual rulesets. You can now be a roundstart heretic without signing up for latejoin heretic, as an example.
This iteration matches parity, and provides very little new functionality, but adding anything new will be much easier.
Fixes#60823Fixes#28907Fixes#44887Fixes#59912Fixes#58458Fixes#59181
Major TODOs
Quirk icons, from @Fikou (with some slight adjustments from me)
Lore text, from @EOBGames (4/6, need moths and then ethereal lore from @AMonkeyThatCodes)
Heavy documentation on how one would add new preferences, species, jobs, etc
A lot of specialized testing so that people's real data don't get corrupted
Changelog
cl Mothblocks, Floyd on lots of the design
refactor: The preferences menu has been completely rewritten in tgui.
refactor: The "Stop Sounds" verb has been moved to OOC.
/cl
Implements the Requests Manager, a new admin tool used to view all prayers, Centcom/Syndicate requests, and nuke code requests within the span of a round.
The verb can be found under Admin.Game, or alternatively just use the verb directly Requests Manager. The requests can be filtered by type (using the type filter button), or using a text search which searches both the message text as well as the request owner's name.
It will now check any disconnected player who was once inside the round (round start or late join) on top of the existing connected players check.
It will now omit an extra notice to admins when players match both cid and ip, as well as make the existing one stand out.
It will now inform admins when one of the pairs is active in the round.
If panic bunker is enabled, interviews disabled, and living bunker disabled, and a player whitelisted previously by only observing connects, you will get the message
"ADMIN LOG: Failed Login: [Ckey attempting to join] - Account attempting to connect during panic bunker, but they do not have the required living time 0/0."
Instead what should happen is the living time is ignored as it should be
(This also fixes when it's set to say 5 minutes and someone with 5 minutes connect but is rejected anyway)
Requested by oranges and inspired by the upcoming event. A new subsyetem, non-processing (for now), aimed at providing some toggle switches that can be flipped as a last ditch effort to save some CPU cycles by sacrificing some non-critical mechanics. Below you can see each individual toggle.
Screenshot of the admin panel:
image
Surely there are more opportunities for toggles I missed, but adding new ones is not very difficult at all.
Why It's Good For The Game
Better performance during extreme pop, I hope.
Changelog
cl
code: Introduces the Lag Switch subsystem for when a smoother experience is worth trading a few bells and whistles for. Performance enhancement measures can be togged by admins with the Show Lag Switches admin verb or enabled automatically at a pop amount set via config.
config: Added a new config var: number/auto_lag_switch_pop
* Catch null text sent to to_chat
* Brain traumas no longer send empty to_chat gain strings
* Make to_chat_immediate changes and clean up args list formatting
* Fix empty to_chat message where there is no memo for admins
* Fix additional edge case where there are no messages for the ckey.
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs.
Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines.
Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing.
Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc.
(Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such)
Adds a 2FA system for admins. When a config is enabled, a database storing your last CID and IP will be checked to see if you have connected through there before. If not, you will not be able to admin until you are verified. Verification is done by opening a website (decided by config), which is tasked with updating the database entry, which will then let you reverify.
MSO wants to implement this as a forum page, but the DM-side is completely agnostic to whatever the implementation is, just that it updates the database. This means that it could potentially be some TOTP stuff, even.
If the database is down, a backup file is checked for your most recent verified connection (IP + CID). If you are on this connection, you will be able to connect fine. If the database is down and you are on a new connection, someone with +PERMISSIONS can manually verify you through the Permissions Panel.
We've had repeated attacks of admins getting their accounts stolen, it's time.
Removes all /datum/game_mode except dynamic. Eventually, all of mode and game_mode will be removed, and Dynamic will become an ingrained system. Every single other gamemode was unmaintained at best and poisoned other code at worst. Currently all tg servers run 24/7 Dynamic, so the time to act is now.
* Remove gamemode references from age checks
* Monkey
* Remove heretics
* Remove BBs
* Refactor uplinks and remove clown ops
* Remove nuke ops
* Removes and refactors cult
* Remove extended
* Remove and move out meteors
* Removes wizard
* Remove sandbox
* Remove changelings
* Remove traitors
* Remove revs
* Remove gangs
* Remove changing mode and voting for new gamemodes
* get_candidates signature fix
* Summon ERT and NERD in their own panel
* Remove some old unneeded age_check stuff
* Fix old signatures of get_uplink_items
* Use Extended like config for dynamic.json
* Fix discounted gear
About The Pull Request
Currently admins can't access the ticket logs for Resolved, Disconnected, Closed and Active tickets due to an early return that will block these from being opened in 100% of circumstances.
Clicking on the Active/Disconnected/Closed/Resolved tickets would have behaviour handled by /datum/admin_help_tickets/proc/BrowseTickets() which was reached through Click() calls.
image
When we call .Click() from topic calls, we provide a null var for the control parameter.
This then leads through to /client/Click() where #57084 added a bunch of if(!control) checks supposedly ported from TGMC (or at least Fikou couldn't explain why we changed that).
I can't find a single instance of us using this locally, it appears it's always passed through to Byond. Byond docs at http://www.byond.com/docs/ref/#/client/proc/Click describe it as control - the name of the skin control involved
I can't see any reason to early return if control is a FALSE-y value. This check is what was blocking access to the admin_help_tickets datum.
In testing, removing these checks restored previous functionality.
Why It's Good For The Game
Admins less triggered.
Changelog
🆑
fix: Admins can once again open the stat panels to look at active, disconnected, closed and resolved tickets.
/🆑
* fullauto component
* eh
* h
* brap
* it works!
* FUCK SHITUP
* dumbass
* l6
* oops
* GOD
* THE LAST 10% OF A PROJECT IS 90% OF THE WORK
* slopwer projecitles, replaces the tesla gun
* heavy
* minigun
* minigun stuff
* runtime fixes, pointer icon
* nuh uh
* makes modifeirs things
* nerf this
* yes
* aghh
* agh
* real high intensity changes here
Co-authored-by: Ryll-Ryll <3589655+Ryll-Ryll@users.noreply.github.com>
LemonInTheDark