Current implementation uses isobserver for checking if we should send to
the player but dead players (who are still in their body) are not
observers and will fail that check.
## About The Pull Request
This PR adds a bunch of sanity checking to the `prefs.chat_toggles` var
accesses.
Prefs can be null when client is creating/deleting and this causes a
runtime where you might not be able to use emotes.
EDIT: as per suggestion I stopped masking the issue and added stack
traces instead. And made them into helper procs to avoid code
duplication.
For some of these procs it is important that we are able to continue
running to get to the end. **A ghost having null prefs should not stop
everyone else from hearing/seeing the emote.**
So now they will put the stack trace and keep on trucking if that issue
occurs. This is the main 'point' of the PR, which has seemingly gotten
bogged down in the creation of the two helper procs--apologies.
See https://github.com/tgstation/tgstation/pull/70404 for essentially
the same issue but applied to chat messages. I have gone back and
replaced the duplicated code from that to use the new helper procs
instead.
## Why It's Good For The Game
Anything chat related is a bad place to runtime. Some messages can take
a while to type out and to have it not display is frustrating at worst,
possibly detrimental if you have to communicate something urgently.
## Changelog
🆑
fix: fixes a bug that can cause emotes to stop working if a client is
being created or deleted
/🆑
## About The Pull Request
Makes it to where if you connect as a guest preferences don't error out
the ass
Resolves https://github.com/tgstation/tgstation/issues/72268
## Why It's Good For The Game
Easier local debugging, and for servers that let guests join
## Changelog
🆑
server: Preferences now support guests
/🆑
So i left over some basic `/whatever/proc/format` uses in the original
PR this fixes it.
Notable exceptions to the rule:
- Paths in add_verb/remove_verb, we need full path instead of a name
there to access verb metadata so we can't use proc ref macros there.
- regex.Replace, found out that it does not accept call by name. Instead
i added new REGEX_REPLACE_HANDLER so we can at least try to mark these.
There's still leftover global procs that do not use GLOBAL_PROC_REF but
they functionally equivalent so that's for later.
I don't see any reasonable way to grep for this. But if you got any
ideas please share.
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
TODO:
- [x] DOCUMENT SHIT
- [x] UPDATE DOCUMENTATION
## About The Pull Request
Adds a new datum, which is intended to be a replacement for the stock
savefile type, json_savefile
As you can imagine, this is essentially just a wrapper around a json
file for reading/writing/manipulation that is intended to be a dropin
replacement for savefiles
It also have the ability to import stock savefiles and parse them into a
json tree
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
Permission obtained from MSO and Mothblocks.
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
Not player facing, tested locally exhaustively to ensure it doesnt break
shit
🆑
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: san7890 <the@san7890.com>
I know this doesn't actually change behavior, but it's confusing, and
adds a potential point of failure if someone doesn't realize it can
happen. Let's be consistent
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
* i wanna go to bed so im pushing this
* It compiles but doesn't work yet
* It works!
* I WANT TO DIE
* Appease linters
* some CI fixes
* Address reviews + oversight
* Limb grower fix
* more icon fixes
* forgot to hit save
* I'm a dumbass
* Removes bodypart parent from unit test
* Fixes monkeys and CI
* Grammar pass
* I hate zombie code so much
* General code cleanup
* THE SHITCODERS ARE COMING FOR MY VARS
* THE UNIT TESTS ARE COMING FOR MY SHITCODE
* Reviews + skirts
* Removes an unused DMI
* Why didn't I do this in the first place?
* HAIR REFACTOR
* Haha whoops
* How did I miss this
* Admin spawned creatures now have their features
* Optimize me harder
* minor fix i need to push to merge master
* Fixes hair (maybe) and a runtime
* Maybe fixes mirrors
* Attempts to fix women
* Fixes hair on dismembered heads and a grammar change
* Caps lock did me dirty
* address reviews
* icon failures fix + missed reviews
* Fixes: Facehuggers and Regenerate_limb
* Fixes ethereal color pref appearance
* How the fuck did this not break everything else horribly?
* JESUS FUCKING CHRIST IM A MORON
* Fixes compile
* I'm not high I swear
* Im a dipshiiiit
* grumble grumble
* Fixes a visual bug with digitigrade legs. Adds \improper to roundstart species names. Added two new clothing-related helper procs. Renamed a couple procs to be more accurate. Adds SHOULD_CALL_PARENT(TRUE) to examine_more. Addresses reviews.
* Forgot this little readability thing.
* Updates CODEOWNERS
* Me when I forget how github works
* mapload me harder
* Last second fixes
* Restores the Persistant Scars preference
I also had to remove some raw READ_FILE()s because that was now useless. I was thus able to remove the persistent_scars variable from the prefs, as it is now a standalone preference.
* I forgor...
* Removes like 50% of the cost of using the ui, it turns out that the storage component is fucking moronic. Likely significantly reduces the overtime of typecacheof
* Reduces the cost of reloading the dummy by ~50%
Turns out just initializing and deleting organs was like half the cost of reloading a default dummy.
It occured to me (Mothblocks) that we don't actually care about any organs we can't see or that don't effect visuals. So almost all of our organ loading can just be skipped.
This saves a significant chunk of cpu time, items next!
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
Bring _HELPERS/_lists.dm to latest standards by:
-Adding proper documentation and fixing existing one
-Giving vars proper names
-Procs now use snake case as per standard (many files that use those procs will be affected)
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
What does the PR do
This reworks how our rendering is handled, specifically moves away from plane masters as the end solution:
Instead we replace plane masters rendering directly to client with planes that render multiple planes onto them as objects in order to be able to affect multiple planes while treating them as a single object. This is done by relaying the plane using a "render relay" onto a "render plate" which acts as a plane master of plane masters of sorts, and since planes are rendered onto it as single objects any filters we apply to them will render over the planes, treating them as a single unit
image
Also cleaned up unused plane masters and render targets to reduce clutter, as well as removing a useless filter that was resulting from confusion due to said clutter.
Clientside performance testing showed no significant change, no effect on serverside performance as this is clientside.
Also added the blackness plane master so it can be relayed, side effect is that it can now be used to adjust how blackness is rendered
P2 should introduce rendering one plane to multiple render_plates, but i want to get this done before I finish that, though testing shows its feasible
Why It's Good For The Game
Allows more advanced effects.
As an example i made a grav anomaly effect in like 30 seconds for this video i will improve it once im awake properly:
https://streamable.com/lu98dz
Documentation images should be merged here after this pr is done
tgstation/documentation-assets#2
Changelog
cl
qol: grav anomalies now have a pretty effect
refactor: Rendering has been refactored, remember to report bugs
/cl
So I started with fixing some timing stuff in #61540, decided to look into foam harddels since I've known about them for a while, got bored, tried to figure out the plane master failures I've seen, and well uh, did.
I'm sure there'll be more, but for now:
Fixes foam darts sticking around post qdel due to dumb guncode, adds a stack trace to handle it.
Makes map popups actually clear the screen they're effecting of their objects, preventing plane master harddels, most commonly sourced from admin pod memes. Not clearing from the screen WAS SOMEHOW AN INTENDED FEATURE!?!@ because "clients log out often anyway and that clears screen so it's fine" I am having a meltdown
Changes examine timers from a ref + signal to a ref(), the timer's 1 second, it's not gonna cause any collisions for the love of christ
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
Simply puts species IDs into defines ("lizard" turns into #define SPECIES_LIZARD "lizard"). This does not affect any gameplay, and is purely for making sure future code doesn't go all fucked up because someone accidentally misspells something
I only changed code that was spelt correctly, so if there actually is a typo somewhere, it isn't changed
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)
Allows all custom names in Character Settings to be reverted to either the default name or a random one, instead of only cyborg and bible names.
Allows picking a random religion in Character Settings. Changing your religion updates your bible and deity if applicable. It uses the religions and bible names that were already in chaplain spawning code. I've added deities to most of them, to save players having to figure them out themselves. I wasn't familiar with a lot of these religions and references so let me know if I've gotten something wrong.
Makes hair (which already was, I think?), underwear, facial hair, and undershirts all available to all genders.
Random character generation is not changed. Eventually, I want to remake random characters to look more believable, but that is out of scope.
Gender-specific preferences are an outdated trope that make the code harder to work with.
This change is also important as a total makeover of the preferences menu and the preference internals are going underway. It is significantly easier to work with when a preference can simply be a list of things you can choose, rather than having to depend on another preference to decide what they can show. While I could make this change at that time, it is also important that the new preferences menu keep parity, and avoid bikeshed on a trifling detail.
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
* Improve code in statpanel.dm
* Improve phrasing in preferences_toggles.dm
* Move "Interviews" under the "Tickets" tab
Co-authored-by: celotajstg <celotajstg@users.noreply.github.com>
Changed column height from 17 to 15 and changed the order to a more sensible and aesthetic one.
Co-authored-by: celotajstg <celotajstg@users.noreply.github.com>
Security officers will now be paired up together in the same department, across departments. This means that, instead of 4 officers being split across 4 departments, there'll now be 2 groups of 2.
Late-join officers will be put into any department with only 1 officer. If none exist, the least populous department will be chosen, with their preference having priority.
Updates the maps to have more spawns for departmental officers. Delta previously had none, and now has some. Fixed a bug where MetaStation's security departmental officer was a supply one instead.
Removes the "random" departmental preference. All security officers are now given a department. The "none" preference still exists, but just to show that you don't care which department you're put into.
Updates the config to comment out SEC_START_BRIG. This is what the configuration was already on live servers.
This is something that should likely be test merged, but it mucks with savefiles. Luckily, the only damage it does is changing random departments to none, so if a TM is reverted, only that will have to be changed.
I was dumb in #56345 and committed a suggestion from a maintainer without actually checking what it did, leading to the part where you select what outfit you want in your preferences to not actually let you select an outfit.
This also removes the can_be_admin_equipped var from outfit datums, apparently it was supposed to be used for outfits that were only supposed to be spawned in certain ways or some nonsense, but nothing actually used it so bye bye
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>
About The Pull Request
This PR removes intents and replaces them with a combat mode. An explanation of what this means can be found below
Major changes:
Disarm and Grab intents have been removed.
Harm/Help is now combat mode, toggled by F or 4 by default
The context/verb/popup menu now only works when you do shift+right-click
Right click is now disarm, both in and out of combat mode.
Grabbing is now on ctrl-click.
If you're in combat mode, and are currently grabbing/pulling someone, and ctrl-click somewhere else, it will not release the grab (To prevent misclicks)
Minor interaction changes:
Right click to dissasemble tables, racks, filing cabinets (When holding the right tool to do so)
Left click to stunbaton, right click to harmbaton
Right click to tip cows
Right click to malpractice surgery
Right click to hold people at gunpoint (if youre holding a gun)
Why It's Good For The Game
Intents heavily cripple both the code and the UI design of interactions. While I understand that a lot of people will dislike this PR as they are used to intents, they are one of our weakest links in terms of explaining to players how to do specific things, and require a lot more keypresses to do compared to this.
As an example, martial arts can now be done without having to juggle 1 2 3 and 4 to switch intents quickly.
As some of you who saw the first combat mode PR, the context menu used to be disabled in combat mode. In this version it is instead on shift-right click ensuring that you can always use it in the same way.
In this version, combat mode also no longer prevents you from attacking with items when you would so before, as this was something that was commonly complained about.
The full intention of this shift in control scheme is that right click will become "secondary interaction" for items, which prevents some of the awkward juggling we have now with item modes etcetera.
Changelog
cl Qustinnus
add: Intents have been replaced with a combat mode. For more info find the PR here: #56601
/cl
negative quirks were impossible to create because there was zero nuance between how bad traits were, for example if you got light drinker and family heirloom, two relatively easy quirks to manage, you can get freerunner. This meant a ton of neutral quirks had to be neutral quirks because giving them even -1 points would make it too easy to get good traits. I've bumped up most quirks by x4 to allow for more nuance between what quirks are actually worth. With some of them being lowered (Like family heirloom and light drinker) as theyre not really supposed to be worth so much for so little.
quick log of changes for CB:
- Every quirk not mentioned had it's point value increased x4 (e.g. 1 -> 4, 4 -> 16)
- mime / clown fan is 2 points (change of -50% with this pr)
- musician is 2 points (change of -50% with this pr)
- depression goes from -1 to -3 points (change of -25% with this pr)
- nyctophobiagoes from -1 to -3 points (change of -25% with this pr)
- junkie from -2 to -6 points (change of 25% with this pr)
- frail from -2 to -6 points (change of 25% with this pr)
- smoker from -2 to -6 points (change of 25% with this pr)
- unstable -2 to -10 points (change of 25% with this pr)
About The Pull Request
Honestly, I'm not sure this is the... Correct solution? But people more familiar with this will likely show me da wae.
Prohibits creating names that can't actually be spoken in-character due to chat filters by adding CHAT_FILTER_CHECKs to the procs that handle sanitising them.
For admin-utilised renaming procs, they'll be given a simple alert box to warn them their chosen name contains words prohibited by the IC chat filter and be allowed to confirm or cancel out.
Why It's Good For The Game
If you can't speak the name IC, chances are the name shouldn't be allowed at all. Players may occasionally be forced to ahelp certain names because they contain words prohibited in chat filters.
Adds TGUI-based alerts to replace the old tgalert system. Replaces all uses of tgalert with tgui_alert except for one, the 'Report Issue' button, as people were (understandably) concerned that this button using tgui will prevent a tgui bug from being easily reported.
These windows have a nice little progress bar indicator of how much time they have left, and will automatically close themselves after this time elapses.
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
A new option has been added to the AI display radial menu alongside random, "Portrait"
It opens a small menu that lets you peruse all of the portraits and select one as your display.
This can let avid artists draw exactly what they want their AI to be like, and not-so-avid artists to bring tears to my eyes.
