## About The Pull Request
This PR converts the native text/list input that pops up when the Spawn
verb is used into a TGUI panel with a dynamic search function. It now
displays atom names, as well if they are abstract (and probably
shouldn't be spawned).
You can still input a typepath after the spawn verb in the tab bar which
will open the menu with said path already in the input box. If only one
typepath matches the input, it will be spawned immediately without
opening the panel.
<img width="400" height="500" alt="Qs0t8xkGj7"
src="https://github.com/user-attachments/assets/d54a57d5-fc22-4f59-af18-45b4fab0b256"
/>
It features RegEx support which activates when the input starts with
``re:``, as well as toggles for searching in atom names and fancy
typepath display. They can be toggled via buttons, or Alt+R/N/F for
regex/names/fancy paths respectively. Invalid regex-es will highlight
the search bar red.
The list itself can be navigated using arrow keys, enter/double click
will spawn the atom, and escape will close the menu.
<img width="400" height="500" alt="xgK2vCd1ck"
src="https://github.com/user-attachments/assets/e621c6ba-ad6b-4a30-922f-eb863797c65a"
/>
<img width="400" height="500" alt="2DeOPBRqoC"
src="https://github.com/user-attachments/assets/18fbba32-17d7-4351-bbc2-bc8e66eb24ae"
/>
Old functionality of spawning multiple objects by leaving a colon +
number after the typepath has been preserved. Using ``*`` and``!`` to
signify final path/end of a path respectively also still works when
regex mode isn't active.
## Why It's Good For The Game
Spawn isn't a critical tool, and using TGUI allows it to have dynamic
search and shifts searching from serverside to clientside, making it
significantly more responsive. Because we don't need to build a fancy
list of atom types, using it the first time won't cause a lag spike on
weaker machines anymore, which should make debugging locally a bit less
annoying.
## Changelog
🆑
admin: Converted the Spawn verb into a TGUI input, featuring for dynamic
search and RegEx support
/🆑
## About The Pull Request
Allows users to edit color matrix filters and layered filters'
transforms through Filterrific, which were the two last unsupported
filter fields. The menus are pretty minimal, but you shouldn't be
touching them if you don't know what you're doing anyways.
https://github.com/user-attachments/assets/e87447f3-e5d6-4f6c-a8e4-bf50a1d5fa79
## Why It's Good For The Game
Makes our tooling actually work
## Changelog
🆑
admin: Implemented color matrix and transform modification support for
Filterrific
/🆑
## About The Pull Request
[cleans up poor namespacing on light debugging
tools](https://github.com/tgstation/tgstation/commit/93cc9070d56ee4dbeb600ebd4616b047adf9d648)
[Implements a pathfinding visualization
tool](https://github.com/tgstation/tgstation/commit/ed91f69ac42a92329c10ccdbba308d213fc8c759)
It holds a set of inputs from the client, and uses them to generate and
display paths from source/target. Left click sets the source, right
click sets the target.
Pathmap support too, if no target is set we display the paths from every
turf in the map to the source, if one is set we build a path TO it from
the source.
I had to add COMSIG_MOB_CLICKON to observers to make this work (tho idk
why it didn't exist already), I also removed the everpresent colorblind
datum from admin datums, only needs to exist if they're using it.
[Adds a mutable_appearance helper that dirlocks them, wallening port
which I thought might be useful here, and will likely be useful
elsewhere in
future](https://github.com/tgstation/tgstation/commit/87f752e7c361ff47d62452f2f1ea805458f71b66)
[Fixes an infinite loop in pathmaps if we tried to pull a cached path to
an unreachable target, && not ||
4head](https://github.com/tgstation/tgstation/commit/10086a655df817c9f4494f9aac879c85a6059719)
[Fixes JPS not dealing with border objects properly. They violate some
of the assumptions JPS makes, so we need to backfill them with checks.
These basically read as (if the thing that should normally take this
path can't reach this turf, can
we?)](https://github.com/tgstation/tgstation/commit/f56cc4dd434cecee89879aea500bd1c9d2f38ce6)
## Why It's Good For The Game
Maybe deals with #80619?
Adds more robust testing tools for pathfinding, should allow people to
better understand/debug these systems. I added this with the idea of
adding multiz support but I don't have the time for that rn.
JPS will work around thindows better, that's nice.
https://file.house/IrBiR0bGxoKw1jJJoxgMRQ==.mp4
## Changelog
🆑
fix: Fixed our pathfinding logic getting deeply confused by border
objects
admin: Added clientside displayed pathfinding debug tools, give em a go
/🆑
## About The Pull Request
We were nullchecking this instead of falsey checking it (TAKE THAT
ISNULL POSTERS) so it'd see FALSE, go "oh that's not null", and then try
and link clients to 0. Dumb
Admin verified connections now cache all verified connections for all
admins. (Rather then just the last connection data of the currently
connected admins)
Sync with the db now happens at admin load time, not at round end. (this
was causing annoyances because servers with long rounds could override
the admin db with old/stale data overwritting the fresher data that was
written by a server with a shorter round)
Fix backup verification not working if the db thinks it still connected
but its not actually still connected.
@Mothblocks @Jordie0608
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
This is basically only admins inside of the .txt and for /tg/station,
only includes heads like the headmins and headcoders
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Yeah, why would we delete the plane debugger while the admin is active?
## Why It's Good For The Game
Broken debugging tool.
## Changelog
N/A
## About The Pull Request
Turns this boilerplate message into a centralized macro because this
code is important, but not so important that every coder know the nitty
gritty details of it. In case someone wants to add more logging/handling
(or update the message), there's now a central macro to update for all
nine events in which we check.
This shouldn't break anything because it's the exact same thing we were
doing previously and the early return checks are still all there, but it
does work on my machine regardless ✔️
For the longest time, the only way admins could moderate the library was
by using statbus's external tool.
But a few months back statbus went down, and ever since then they've
been sitting lost. Shit sucks.
The whole external thing has been bugging me for a while, so let's fix
all that yeah?
This pr adds a new verb to the admin tab that allows admins to
ban/restore books from the library.
It includes expanded (ckey) search, faster response times, in tool book
viewing with and without markdown rendering, and viewing of deleted
books.
This is accomplished with a special subtype of library consoles, stored
on the admin datum.
It shouldn't let you do anything without +BAN, rip my live debugging or
whatever.
I've also hooked into (and fixed) Ned's existing library actions log,
and added viewing support to the ban/restore pages.
This logs banning admin, ban time, ban reason, etc.
As a part of this, I've fixed/expanded on the existing UIs.
I've added ID search to all existing consoles, and fixed an existing bug
with the visitor console not supporting category search (shows how many
people actually use the thing)
Changes to the library_action table were pretty minor. The ckey column
was too small, so longer keys just caused it to fail on ban. Bad.
That and the ip address column was signed, which wasted space and was
non standard with other tables.
Just some unnecessary costs. We create `/datum/admins` for every admin
in the txt and database. It might sound silly, but it ends up being
useful for things like the permissions panel. Anyway, admins are usually
given profiling access, but the SetConfig call is extremely slow. So
slow that we have it config'd off on Campbell, AFAIK. This defers that
cost to when an admin joins.
This could in theory cause issues with latejoining admins getting debug perms, but it appears to work in testing. noting for far future
## About The Pull Request
Basically, sometimes, very rarely, it was possible for this to happen,
when it shouldn't be happening. I was wondering for a little while what
it was about, and then I finally downloaded my chat logs for a round and
realized what was going on. It should no longer happen.
## Why It's Good For The Game
Clickable links that lead nowhere (and thus don't do anything) aren't
very good for the game.
## Changelog
🆑 GoldenAlpharex
fix: There shouldn't be clickable names in Adminwho that don't do
anything anymore.
/🆑
## 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>
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
* Removes redundant init_verb() call
* Fixes the MC tab not going away when you deadmin + runs Prettier on statbrowser.js
* Revert "Fixes the MC tab not going away when you deadmin + runs Prettier on statbrowser.js"
This reverts commit 2676d5f897cdc956b062f5d4785a7ebf2e1df8a9.
* Now prettier will only work inside of the tgui folder
* Actually makes the change for the MC tab sticking around forever
* Adminwho now caches feedback links until admins are reloaded
* Restore dbconfig
* Fix feedback links, make them query only if necessary, and not on load admins
* Wait longer before checking DB connection
* Back on my dbconfig shit
fixes (Adminwho is slower than it needs to be after feedback links) #67150.
also fixes (timber breaking feedback links totally by qdeling the datum too early) #67360.
This PR moves the in-game Newscaster over to TGUI, which is one the most bothersome html to tgui projects on the codebase being that it's gone untouched for like... over 4 years now after the introduction of tgui. Newscasters are widely used in-game by players wanting to be deranged whistleblowers, noir detectives, and journalists. They're flavorful, fun, and we still use an html window to make them run so it looks like it's from 2003.
* Adds a colorblind accessability testing tool
I keep finding myself worrying about if things I create will be parsable
for colorblind people. So I've made a debug tool for approximating
different extreme forms of colorblindness.
It's very very much a hack. We can't do the proper correction required
to actually deal directly with long medium and short wavelengths of
light, so we need to rely on approximations. Part of that means say,
bright things being brighter then they ought to be. S not how people
actually experience things, but it's not something we can do anything
about in byond.
Anyway uh, it works by taking color matrixes, and using the plane master
grouping system floyd added to apply them to most all parts of the game
you would want to color correct.
There's some slight fragility here, but I couldn't think of a better way
of handling it.
We also need to deal with planes that have BLEND_MULTIPLY as their
blendmode, since that fucks up the filter. I've come up with a hack for
it, since I wanted to avoid breaking anything.
Oh and since I want it to apply to huds too I added plane masters to
represent them. I think that's about it.
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
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.
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
Filter refactor + In Game Filter Editor
Accessed via VV in the dropdown of atoms. "Edit Filters.
Makes filters actually usable.
Co-authored-by: ghgh <hghgh>
Implements the ?. operator, replacing code like A && A.B with A?.B
BYOND Ref:
When reading A?.B, it's equivalent to A && A.B except that A is only evaluated once, even if it's a complex expression like a proc call.
Replaces like 70-80% of 0 and such, as a side effect cleaned up a bunch of returns
Edit: Most left out ones are in mecha which should be done in mecha refactor already
Oh my look how clean it is
Co-authored-by: TiviPlus <TiviPlus>
Co-authored-by: Couls <coul422@gmail.com>
* demos (ported from yogstation)
rustg update + write with no format
use external hook for logging
use proper log vars
fix + clarifying comment
don't start the log
release build of rust-g
fix something caught by the lint
Update code/__DEFINES/subsystems.dm
Co-Authored-By: Jordan Brown <Cyberboss@users.noreply.github.com>
Update code/controllers/subsystem/demo.dm
Co-Authored-By: JJRcop <jrubcop@gmail.com>
Update code/controllers/subsystem/demo.dm
Co-Authored-By: JJRcop <jrubcop@gmail.com>
moves hooks out of a dedicated file
len = 0 to Cut(), remove semicolons
untyped loop
* updated rust_g
* 513 updates
* updates sqladmins with excluded flags and tempminning
* rank, editing and permission protections; json backup
* fixes
* reverted the wrong file
* fix slidecolor cascading and disabled switches not being sent in form
* removes debug uncommenting
* whoops this too
* commas fix + versions for changelog entry headers since 3.0
* actually account for can_edit_flags and use of @ with - or *
* fixes and rearrangement of admin > localhost > autoadmin precedence
* in case you want to not have autologin autoadmins
* Deadmin tweaks, Admins without +ADMIN start deadmined.
Deadmining no longer destroys the admin datum.
Admins without +ADMIN start deadmined, reloading admins re-deadmins them.
Moved some code around to make it more sane
People with +PERMISSION can now deadmin or readmin other admins at will.
* Adds new flag for if the role should automatically log in, defaults to on, can be removed with -AUTOLOGIN
Also fixes a bug in permission panel not handling these cases gracefully
There's a certain issue of people spoofing real byond links to admins. Now all links should come with a generated key that is validated when the Topic is run.
Added DEBUG_ADMIN_HREFS to debug this system while we test it (Allows hrefs without tokens and complains about it in the logs)
Just add [HrefToken()] as a parameter to all admin hrefs. Anything that ends up running through VV or Holder will be verified
