* update blacklisted client byond versions (#80523)
Also cleans up old ones that don't matter. Since we use 514 client
features so byond forces 514 clients anyways.
Resolves#80504
* update blacklisted client byond versions
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* reload savefile on pref assosciation (#78984)
## About The Pull Request
Tells the preferences datum to reload the savefile when we associate to
an already existing one
## Why It's Good For The Game
This trolled me locally for a good hour wondering "why aren't my prefs
updating when I swap out the file"
## Changelog
* reload savefile on pref assosciation
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* Culls client/mouse code only used by beam rifles in favor of signals. (#78113)
* Culls client/mouse code only used by beam rifles in favor of signals.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Adds sanity checking to prefs checks, fixing a bug that can cause emotes to stop displaying intermittently
* Update vox_procs.dm
---------
Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com>
* Alert a Discord role when a new player joins (#77432)
## About Why It's Good For The Game The Pull Request
What it says on the tin. A requested feature for people who like to keep
an eye on swaths of new players. A config that is off by default, but a
Discord role ID can be added to have TGS ping that role.
Also sends alerts to Discord if a player with sketchy telemetry joins.
## Changelog
🆑 Tattle
admin: Pings an admin role on discord when a new player joins (when
enabled by config)
/🆑
---------
Co-authored-by: tattle <article.disaster@ gmail.com>
* Alert a Discord role when a new player joins
---------
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: tattle <article.disaster@ gmail.com>
* Update client click handling for 514 (#77316)
Hey! its 515 time, so i thought we should close up the last compability
change from 514 that slipped thru the cracks.
under 514 the LEFT/RIGHT/MIDDLE mouse button keys to the mouse param
list are set if they are pressed at all, while the `button` param says
which mouse button being clicked triggered that action.
More mouse code likely needs to be changed to account for this, but this
is the most critical path that cared about the distinction between which
buttons are being held and which button triggered the current mouse
action.
Fixes#76836 maybe?
* Update client click handling for 514
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* Removes redundant CID randomizer check (#76396)
## About The Pull Request
This check is redundant because 512 fixed the exploit it was designed to
check. Randomizers still exist, but this code doesn't apply to them
since they use a different method.
Someone else tried this before but got his shit slapped for it being his
first PR and there being a possibility he was removing it so he could
bypass it. I'm not banned and have no possible ulterior motives; I just
want to get rid of dead code.
## Why It's Good For The Game
I'd make an Old Yeller joke, but the code's already dead, so.
Fixes#43227
## Changelog
This is not a player-facing change.
* Removes redundant CID randomizer check
---------
Co-authored-by: Vekter <TheVekter@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Mark client as QDELING (#75576)
Clients will now be marked QDELING while in the process of deleting.
Necessary for #75445
* Mark client as QDELING
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Makes chat helper procs async (#75414)
As they are and fixes some SHOULD_NOT_SLEEP hits
See #75232
* Makes chat helper procs async
---------
Co-authored-by: Jordan Dominion <Cyberboss@users.noreply.github.com>
* Fix SHOULD_NOT_SLEEP hit in /client/Destroy() (#75241)
See #75232
* Fix SHOULD_NOT_SLEEP hit in /client/Destroy()
---------
Co-authored-by: Jordan Dominion <Cyberboss@users.noreply.github.com>
* Allows Export of your Preferences JSON File (#75014)
## About The Pull Request
Hey there,
This was spoken about in #70492 (specifically
https://github.com/tgstation/tgstation/pull/70492#issuecomment-1278069607),
and I have been waiting for this to be implemented for some time. It
never got implemented, so I decided to code it myself.
Basically, **if the server host doesn't disable it**, you are free to
export your JSONs as a player, right from the stat-panel. It's a pretty
JSON on 515 versions, too!
It's right here:
Here's what the prettified JSON looks like on 515.
There's a cooldown (default to 10 seconds) between exporting your
preferences.
#### Why is this config?
It's because in the past, a server host could always just file-share the
.sav or .json or whatever to the player, but they would have to do the
explicit option of actually bothering to make the files accessible to
the player. In that same line of logic, the server operator will have to
explicitly make the files accessible. This is mostly because I'm not
sure how good `ftp()` is at being a player function and wanted to have
some sort of cap/control somehow in case an exploit vector is detected
or it's just plain spammed by bots, so we'll just leave it up to the
direct providers of this data to elect if they wish to provide the data
or not.
## Why It's Good For The Game
Players don't have to log into Server A to remember what hairstyle they
loved using when they want to swap to Server B! That's amazing actually.
I always forget what ponytail my character has, and it'll be nice to
have the hairstyle in a readily accessible place (after I prettify the
JSON for myself).
It's also more convenient for server hosts to make player data like this
accessible if they really want to, too.
If we ever add an _import_ feature in the future (which would have to be
done with a LOT of care), this will also be useful. I wouldn't advise it
though having taken a precursory look at how much goes into it while
trying to ascertain the scope of this PR.
## Changelog
🆑
qol: The game now supports export of your preferences into a JSON file!
The verb (export-preferences) should now be available in the OOC tab of
your stat-panel if enabled by server operators.
server: Exporting player preferences is controlled by a configuration
option, 'FORBID_PREFERENCES_EXPORT'. If you do not wish to let clients
access the ftp() function to their own preferences file (probably for
bandwidth reasons?) you should uncomment this or add it to your config
somehow.
config: Server operators are also able to set the cooldown between
requests to download the JSON Preferences file via the
'SECONDS_COOLDOWN_FOR_PREFERENCES_EXPORT' config option.
/🆑
* Allows Export of your Preferences JSON File
---------
Co-authored-by: san7890 <the@san7890.com>
* Fix code not compiling on prod. (#74589)
(at)Mothblocks idea: make alt_tests a yml file and allow more generic alt
tests, like defines and shit. or we can put this on integration tests
and let windows build cover the normal/dev build case of preload_rsc = 1
* Fix code not compiling on prod.
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* Increase first connect responsiveness by delaying vox sound preload (#74559)
These were getting sent too early and clogged up the queue of resources
to send the client, delaying chat load if the client had no byond rsc
cache and the cdn was not enabled.
Also this way if the cdn rsc download happens quick enough than these
calls can become noops. (if byond isn't smart enough to do that now, it
will be.)
* Increase first connect responsiveness by delaying vox sound preload
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* Clients can't OOC until they have fully gone through `New()` (#74493)
People are able to send OOC messages before `client/New()` is able to
fully set itself up. Let's guard against this by re-using the variable
we set at the end of New() and blocking any usage of the OOC verb if
they aren't set up. I made it a define so we can use it in other spots
as well if the occasion should call for it.
Define included in this PR can be (and probably should be when someone
has time) replicated in other spots where we need it.
* Clients can't OOC until they have fully gone through `New()`
---------
Co-authored-by: san7890 <the@san7890.com>
* Fix lack of to_chat_immediate in client code that disconnects clients. (#73575)
these clients are about to be disconnected, they can't wait for the mc
to tick next
* Fix lack of to_chat_immediate in client code that disconnects clients.
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* Adds a config option for warning clients about older builds (not just older versions) (#73549)
## About The Pull Request
MSO was being tsundere about this and it seemed useful, so here we go
## Changelog
🆑
config: Added a warning build config setting, you can now lightly
repremand but not block clients with older builds but fine major
versions
/🆑
* Adds a config option for warning clients about older builds (not just older versions)
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* literally just hook asay into tgui say (#73212)
## About The Pull Request
pressing f3 now opens asay in tgui say
## Why It's Good For The Game
also fixes double-escaped special characters caused by #72407 and
finally gets rid of the gross regular tgui input popup
## Changelog
🆑
fix: asays are no longer double-escaped
admin: asay now uses tgui say
/🆑
---------
Co-authored-by: Scriptis <scriptis@ duck.com>
* literally just hook asay into tgui say
---------
Co-authored-by: scriptis <scriptif@gmail.com>
Co-authored-by: Scriptis <scriptis@ duck.com>
* Particle editor (#71110)
## About The Pull Request
Demo: https://streamable.com/wnj3mf
Features:
- Full support for most gradients/vectors/numbers/generators/transforms
( I might have forgotten some of the more esoteric ones)
- A "tutorial" section that explains the different rand/generation types
and how physics works with pictures
- Button for viewing what each var does
- Selecting a particle type to set immediately
- The generator types use defines now
Not included:
Color matrix support for color generators (I'm sorry but hell no)
Special thanks to @ jlsnow301 for explaining js things to me
## Why It's Good For The Game
Making cool stuf
## Changelog
🆑
refactor: Added a particle editor to VV dropdown which can be used by
coders and admins to edit particle values on the fly easily.
/🆑
Co-authored-by: TiviPlus <572233640+TiviPlus@ users.noreply.com>
* Particle editor
Co-authored-by: TiviPlus <57223640+TiviPlus@users.noreply.github.com>
Co-authored-by: TiviPlus <572233640+TiviPlus@ users.noreply.com>
* Ensures bunkering someone doesn't runtime due to a divide by 0 error (#71081)
## About The Pull Request
HAHHHHHHHHHHHHHHHH
* Ensures bunkering someone doesn't runtime due to a divide by 0 error
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Object Window Niceties (#69825)
* 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>
* Object Window Niceties
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
* Resolves is_banned_from headaches and lag (Speeds up roundstart significantly) (#69376)
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
* Resolves is_banned_from headaches and lag (Speeds up roundstart significantly)
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Fixes click catcher failing to be reapplied onto the screen when show_hud is called (#68853)
Done stuff
Co-authored-by: Watermelon914 <hidden@ hidden.com>
* Fixes click catcher failing to be reapplied onto the screen when show_hud is called
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <hidden@ hidden.com>
* Biddle Verbs: Queues the Most Expensive Verbs for the Next Tick if the Server Is Overloaded (#65589)
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
* Biddle Verbs: Queues the Most Expensive Verbs for the Next Tick if the Server Is Overloaded
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Fullscreen, status bar hiding, chat input following the theme (#67987)
* Initial commit
* input is colored according to the theme
* removed unused setting
* Fullscreen, status bar hiding, chat input following the theme
Co-authored-by: Andrew <mt.forspam@gmail.com>
* adds the "refresh TGUI" debug verb (#67265)
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
* adds the "refresh TGUI" debug verb
Co-authored-by: magatsuchi <88991542+magatsuchi@users.noreply.github.com>
* Refactors firestacks into status effects (#66573)
This PR refactors firestacks into two status effects: fire_stacks, which behave like normal firestacks you have right now, and wet_stacks, which are your negative fire stacks right now. This allows for custom fires with custom behaviors and icons to be made.
Some fire related is moved away from species(what the fuck was it even doing there) into these as well.
Oh and I fixed the bug where monkeys on fire had a human fire overlay, why wasn't this fixed already, it's like ancient.
Also changed some related proc names to be snake_case like everything should be.
This allows for custom fire types with custom behaviours, like freezing freon fire or radioactive tritium fire. Removing vars from living and moving them to status effects for modularity is also good.
Nothing to argue about since there's nothing player-facing
* Hud Image Culling By Z Level: Theft edition (#65189)
* 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>
* small touch-up
* this should do it
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: KylerAce <kylerlumpkin1@gmail.com>
* Parallax but better: Smooth movement cleanup (#66567)
* 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.
* Parallax but better: Smooth movement cleanup
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Revert "Revert "[MIRROR] Moves help menu to end, fixes Hotkeys Help [MDB IGNORE] (#12425)" (#12479)"
This reverts commit 6d44a08156.
* capitalization fix for linux server
