mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-06-15 11:14:42 +01:00
ed94de4ddf7edad8694badefc577392e0f762bf5
894 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 MrMelbert
|
8c1e35e1c0 |
Refactors mind language holders into non-existent, fixes new languages being deleted on species swap + tests (#76612)
## About The Pull Request This PR refactors mind language holders into non-existence As a result, `update_atom_languages` is no longer necessary Mind-bound languages are transferred via `/mind/proc/transfer_to` Species changing no longer deletes and re-creates the mob's language holder, allowing them to keep any languages they have. Species languages are sourced from `LANGUAGE_SPECIES` now, meaning they are removed when they change species. If the mob is not a human with a species datum, these are effectively just atom level languages. Makes a bunch of unit tests to ensure language transfer over certain events works as intended ## Why It's Good For The Game Mobs with minds having two independent language holders results in a good few bugs, and simply doesn't make sense when we have sources (`LANGUAGE_MIND`). Instead of tracking two language holders, we can simply use sources better and only track one. This means that the language holder you start with is your language holder, period. It doesn't get deleted or re-instantiated or whatever. ## Changelog 🆑 Melbert refactor: Refactored language holders, making species changes not delete all of your known languages /🆑 |
||
|
Ghom
|
3b44a8b15c |
Adds cardboard IDs to the game: The broke man's agent ID. (#76682)
## About The Pull Request This PR adds a new craftable item to the game that, in a way, works somewhat like ID cards, as in it gives the wearer an identity of some sort, and that can be modified similardly to the agent ID, but... It doesn't provide access. It doesn't trick security bots and turrets. It doesn't work with chameleon masks. It doesn't have a bank account. It doesn't fit inside wallets or PDAs. It doesn't show a trim (it's just cosmetic) on the security HUD. It doesn't look like an ID card. (It does however, synergizes well with sign language and face-covering mask, but in the face of all the things id doesn't do, should I change that? idk) Basically, it's not an ID, it's just a piece of cardboard with name and job written on it.   ## Why It's Good For The Game Often, player shenanigeans rely on ID cards with gimmicky names and jobs to advertise themselves or provide a (feeble) disguise for it. The idea is to provide players a cheap tool for their tomfoolery, that doesn't get much in the way of balance. Compared to actual IDs, cardboard IDs' only advantage is the fact they're more easily produceable. Also this PR converts a bit of snowflakey code into signals, and fixes the name part in hallucination messages being shown "Unknown" while the speaker is wearing a mask but also an ID. ## Changelog 🆑 add: Added cardboard IDs to the game. They can be crafted with a cardboard sheet and wirecutters and modified with a writing tool. While worn, these will modify the visible name of the wearer just like actual IDs, though they aren't real IDs and won't work as such. /🆑 |
||
|
ChungusGamer666
|
4f2227baf3 |
Implements a macro for checking mind traits (#76548)
## About The Pull Request  Seeing this pattern repeated over various sections of code was starting to piss me off ## Why It's Good For The Game Lessens chance to cause errors with mind traits, ensures consistent behavior, makes it easier to change how mind traits work if necessary. ## Changelog hopefully not player facing --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
LemonInTheDark
|
8c2c72b0ed |
Duiffel Spotfix (#76442)
## About The Pull Request Gives duffelbags their proper slot count They inherited this from backpacks, but I sorta just forgot about that [Creates "levels" of locked objects, uses that to make locked duffels work](https://github.com/tgstation/tgstation/pull/76442/commits/c613c00f62fa3ff03bb33737d24da9acbf2050e3) [c613c00](https://github.com/tgstation/tgstation/pull/76442/commits/c613c00f62fa3ff03bb33737d24da9acbf2050e3) Turns locked into something that holds defines, this makes life a lot easier. Requires a lot of boilerplate because of how many uses of these procs there are and all the passthrough and shit. Adds a few outfit subtypes to avoid this class of failure in future. Renames the args in a few but not all touched procs, one thing at a time Closes #76407 Closes #76430 Had the lock check in the wrong place Closes #76441 GOD I HATE TK SO MUCH Wrote half the pr without glasses so if it's weird gimme some grace yeah? ## Changelog 🆑 fix: Fixes some fuck with duffelbags, them not holding enough + issues with spawning gear in them (job shit and all) /🆑 |
||
|
ChungusGamer666
|
6da96bef84 |
SPECIES NUKING 2023: Mein leber! Allows livers to handle reagents in special ways, instead of the species datum doing it (#76184)
## About The Pull Request Refactors livers so special chemical handling can be done by them, instead of the species datum. Plasmamen, skeletons and golems all use the liver for all their species specific chem handling now. ## Why It's Good For The Game SPECIES DATUM I HATE YOU! Also, being able to handle reagents like any species if you have their liver is REALLY FREAKING COOL and allows for emergent gameplay by mixing various organs from various sources. ## Changelog 🆑 refactor: Mutant livers can now handle chemicals in special ways. Currently, only plasmaman, skeleton and golem livers do it. Every other species is the same. /🆑 --------- Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> |
||
|
larentoun
|
036cfc84c8 |
feat: Respawn delay (optional) (#75544)
## About The Pull Request Adds optional (disabled by default) respawn delay. If the player is observer and have a body, it will firstly check the body. If the body is destroyed or if there was none, then it will check observer's login time. ## Why It's Good For The Game Optional respawn delay is good, when you want players to comeback not only as a midround event, but don't want them to not care about their life. Also, if respawn is enabled, removes "money dupe" and other problems with 0 respawn delay. This proc can also be used for ghost-roles or anything else, where we need to check how much time has elapsed since their death, but is not implemented here. ## Changelog 🆑 add: Added optional respawn delay (disabled by default), which prevents returning to lobby while dead. /🆑 |
||
|
tattle
|
9f70308931 |
Restores mob tags to mob tag logging (#75850)
## About The Why It's Good For The Game Pull Request Why It's Good For The Game These were accidentally removed from the log ## Changelog 🆑 Tattle admin: mob tags are now part of the mob tag log again /🆑 --------- Co-authored-by: tattle <article.disaster@gmail.com> Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com> |
||
|
LemonInTheDark
|
cb4a836d41 |
Removes all uses of text() (#75766)
## About The Pull Request Apperantly it's deprecated. Also people misunderstand how to use it, which leads to silly looking code and redundant wraps. It is potentially useful to do a sort of format style string embedding, but we don't have anything that really warrents it IMO. ## Why It's Good For The Game Maybe byond will break on version upgrade slightly less now. Also the code's less cluttered, and boomer posting has been excised.    |
||
|
Watermelon914
|
569d8f5a72 |
Refactored the TTS subsystem to more properly handle message garbling. Added a volume preference for TTS. (#75559)
TTS subsystem refactor. --------- Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> |
||
|
Zephyr
|
fbec9c14e9 |
JSON Logging Take Two (#73604)
## About The Pull Request Converts all logging, excluding perf and investigate, to json. I focused on making the system as easy to use and as easy to add new categories as possible. Due to issues related to logging to world at global creation logger is now a byond real, which is created directly before Master Log categories support versioning, secret flagging, and sub-category filtering. Although all of this is entirely optional for coders. If you ever want to add a new category and use it, all you need to do is make the barebones category datum and the define. I've kept existing procs such as log_game, and simply turned them into a wrapper for Logger.Log(xxx, ...) ## Why It's Good For The Game Makes processing and filtering logs much easier in the future, while only minimally downgrading log crawling experience. I am also working on a log viewer frontend for admin usage however that will take a little bit longer to finish up. Also makes special logging and data tracking much easier thanks to a data list processing implementation and handling ## Changelog 🆑 server: All logs are now formatted in json, excluding perf and investigations /🆑 --------- Signed-off-by: GitHub <noreply@github.com> Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com> |
||
|
John Willard
|
c8c977989a |
Mimes can no longer write without breaking their vow. (#74674)
## About The Pull Request I feel this is gonna be unpopular with the lazy mime players. Also, this is an idea I had in my backlog for a while now  This removes the Mime's ability to write on paper while they're on their vow of silence. This can be compared to hand language, which doesn't let you speak despite not being considered "talking", and PDA messaging, which does the same. Mimes can still write with their pen, which is a nice invisible white color. I thought I would keep it in as I find that interaction funny to have a Mime give someone just a blank paper, unknowing that there's text on it. Spraycans/Telekinesis/Circuits are also left unaffected because they require actual effort to obtain (doing genetics, doing circuits, or printing spraycans which take a lot of inventory space and is limited), compared to paper which you can carry hundreds of papers around and is bountiful across the station. I thought this was attempted at least once, but I can't find any PR that mentions it, so I'm shooting my shot to see if this is something we'd want. ## Why It's Good For The Game Mimes using paper is a lazy way to bypass their one job gimmick: Emoting over talking. If they get a job change, they can simply break their vow to access paper writing abilities, so this doesn't affect that really. It more-so hits the Mimes who uses the job for the free spells/healing abilities/etc, and bypasses the downsides (im aware its harder to get people to read paper than it is to talk to them, but you can literally get the mute quirk and itll have the same effect without being the whole job). The point is, you don't get invisible walls for free; it comes at a cost of not being able to talk to people. If you want to talk, then break your vow, lose access to your Mime abilities, and remake it later when the cooldown is over. You're not meant to do both. ## Changelog 🆑 balance: Mimes can no longer write on paper without breaking their vow. /🆑 |
||
|
Tim
|
b779460d89 |
Fix not being able to read in full bright areas (#73843)
## About The Pull Request Fixes #73830 Fixes #74107 There seems to be a problem when the map template reloads for full bright areas, but only for thunderdome specifically. Very strange and my fix feels like a band-aid but it's a niche bug report. Also deleted an area that was not used anywhere in the codebase. ## Why It's Good For The Game Silly bug go bye bye. ## Changelog 🆑 fix: Fix not being able to read in full bright areas /🆑 |
||
|
LemonInTheDark
|
33d9a0338f |
Reworks trashbags slightly (#73761)
## About The Pull Request I'm a bit sad about the state of trashbags. They're very clunky to use, so they almost never get touched. S depressing. Let's try and fix that. Let's make em fit in the belt slot (again), but as a tradeoff we'll make it harder to pull one thing from your bag. We'll give it a say, 1.5 second delay, so you can't quickdraw from em. If you try and dump them out into something else, we'll throw any spillover on the ground below you I'm also doing some general code cleanup here. Making procs more readable, vars more direct, removing some old legacy stuff. I've added a remove_single proc to hook into via subtype, which takes a mob as input. this has required placing extra requirement on some helper procs, but fortunately it's not something they're unable to meet. My hope is this will make garbage bags usable without being stupid. ## Why It's Good For The Game I don't see these get used at all, cause they're a pain to carry around. They got gimped because people were using them as infinite storage for shotgun shells and other small items. I've made using them for this sort of thing hard and slow, so I think we oughta be fine. If not I'll do some more touching, maybe give the autodrop a delay. ## Changelog 🆑 balance: The janitor's trashbag now fits on his belt. In exchange, taking something out of it sends a visible message, and has a delay. /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
LemonInTheDark
|
db7534d6da |
Lowers nightvision threshold to work for mesons, fixes not being able to examine stuff lit by overlay lights (#73712)
## About The Pull Request Might be a bit low, but part of that is because it's kinda bad at figuring color, rgb isn't really balanced in that respect Fixes not being able to see stuff under the light of a lamp Overlay lights don't set lumen, which leads to stupid when you try and check with ONLY it It worked before because the mob has THEIR luminosity set, which then "glowed" out That doesn't work here cause yaknow I removed our uses of byond lighting (except for errant view() calls) so this is the best I've got ## Why It's Good For The Game Closes #73548 ## Changelog 🆑 fix: Examining in the dark is less wonk now, sorry bout that /🆑 |
||
|
LemonInTheDark
|
dde3477830 |
Fixes another case of broken huds on z level work (Also a runtime for ghosts) (#73520)
## About The Pull Request [Fixes another case of broken huds on z level work](https://github.com/tgstation/tgstation/commit/eed4336c715769f26c4fac844cc5b302014e5ab8) This is I think new, but returning inside these loops is stupid and breaks shit bad. [Fixes a runtime in nightvision checking](https://github.com/tgstation/tgstation/commit/c183fef185b66e65ae059a958a68881af7db1b25) That list defaults to null, it can be null, be nice to it 📰 ## Why It's Good For The Game Huds are more stable, less runtimes ## Changelog 🆑 fix: Moving up and down z levels will break hud stuff slightly less often /🆑 |
||
|
LemonInTheDark
|
ab307032ed |
Nightvision Rework (In the name of color) (#73094)
## About The Pull Request Relies on #72886 for some render relay expansion I use for light_mask stuff. Hello bestie! Night vision pissed me off, so I've come to burn this place to the ground. Two sections to discuss here. First we'll talk about see_in_dark and why I hate it, second we'll discuss the lighting plane and how we brighten it, plus introducing color to the party. ### `see_in_dark` and why it kinda sucks https://www.byond.com/docs/ref/#/mob/var/see_in_dark See in dark lets us control how far away from us a turf can be before we hide it/its contents if it's dark (not got luminosity set) We currently set it semi inconsistently to provide nightvision to mobs. The trouble is stuff that produces light != stuff that sets luminosity. The worst case of this can be seen by walking out of escape on icebox, where you'll see this  Snow draws above the lighting plane, so the snow will intermittently draw, depending on see_in_dark and the luminosity from tracking lights. This would in theory be solvable by modifying the area, but the same problem applies across many things in the codebase. As things currently stand, to be emissive you NEED to have a light on your tile. People are bad at this, and honestly it's a bit much to expect of them. An emissive overlay on a canister shouldn't need an element or something and a list on turfs to manage it. This gets worse when you factor in the patterns I'm using to avoid drawing lights above nothing, which leads to lights that should show, but are misoffset because their parent pixel offsets. It's silly. We do it so we can have things like mesons without just handing out night vision, but even there the effect of just hiding objects and mobs looks baddddddd when moving. It's always bothered me. I'll complain about mesons more later, but really just like, they're too bright as it is. I'm proposing here that rather then manually hiding stuff based off distance from the player, we can instead show/hide using just the lighting plane. This means things like mesons are gonna get dimmer, but that's fine because they suck. It does have some side effects, things like view() on mobs won't hide stuff in darkness, but that's fine because none actually thinks about view like that, I think. Oh and I added a case to prevent examining stuff that's in darkness, and not right next to you when you don't have enough nightvision, to match the old behavior `see_in_dark` gave us. Now I'd like to go on a mild tangent about color, please bare with me ### Color and why `lighting_alpha` REALLY sucks You ever walk around with mesons on when there's a fire going, or an ethereal or firelocks down. You notice how there isn't really much color to our lights? Doesn't that suck? It's because the way we go about brighting lighting is by making everything on the lighting plane transparent. This is fine for brightening things, but it ends up looking kinda crummy in the end and leads to really washed out colors that should be bright. Playing engineer or miner gets fucking depressing. The central idea of this pr, that everything else falls out of, is instead of making the plane more transparent, we can use color matrixes to make things AT LEAST x bright. https://www.byond.com/docs/ref/#/{notes}/color-matrix Brief recap for color matrixes, fully expanded they're a set of 20 different values in a list Units generally scale 0-1 as multipliers, though since it's multiplication in order to make an rgb(1,1,1) pixel fullbright you would need to use 255s. A "unit matrix" for color looks like this: ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 ) ``` The first four rows are how much each r, g, b and a impact r, g, b and well a. So a first row of `(1, 0, 0, 0)` means 1 unit of r results in 1 unit of r. and 0 units of green, blue and alpha, and so on. A first row of `(0, 1, 0, 0)` would make 1 red component into 1 green component, and leave red, blue and alpha alone, shifting any red of whatever it's applied to a green. Using these we can essentially color transform our world. It's a fun tool. But there's more. That last row there doesn't take a variable input like the others. Instead, it ADDS some fraction of 255 to red, green, blue and alpha. So a fifth row of `(1, 0, 0, 0)` would make every pixel as red as it could possibly be. This is what we're going to exploit here. You see all these values accept negative multipliers, so we can lower colors down instead of raising them up! The key idea is using color matrix filters https://www.byond.com/docs/ref/#/{notes}/filters/color to chain these operations together. Pulling alllll the way back, we want to brighten darkness without affecting brighter colors. Lower rgb values are darker, higher ones are brighter. This relationship isn't really linear because of suffering reasons, but it's good enough for this. Let's try chaining some matrixes on the lighting plane, which is bright where fullbright, and dark where dark. Take a list like this ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, -0.2, -0.2, -0.2, 0 ) ``` That would darken the lighting a bit, but negative values will get rounded to 0 A subsequent raising by the same amount ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0.2, 0.2, 0.2, 0 ) ``` Will essentially threshold our brightness at that value. This ensures we aren't washing out colors when we make things brighter, while leaving higher values unaffected since they basically just had a constant subtracted and then readded. ### But wait, there's more You may have noticed, we gain access to individual color components here. This means not only can we darken and lighten by thresholds, we can COLOR those thresholds. ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0.1, 0.2, 0.1, 0 ) ``` Something like the above, if applied with its inverse, would tint the darkness green. The delta between the different scalars will determine how vivid the color is, and the actual value will impact the brightness. Something that's always bothered me about nightvision is it's just greyscale for the most part, there isn't any color to it. There was an old idea of coloring the game plane to match their lenses, but if you've ever played with the colorblind quirk you know that gets headachey really fast. So instead of that, lets color just the darkness that these glasses produce. It provides some reminder that you're wearing them, instead of just being something you forget about while playing, and provides a reason to use flashlights and such since they can give you a clearer, less tinted view of things while retaining the ability to look around things. I've so far applied this pattern to JUST headwear for humans (also those mining wisps) I'm planning on furthering it to mobs that use nightvision, but I wanted to get this up cause I don't wanna pr it the day before the freeze. Mesons are green, sec night vision is red, thermals orange, etc. I think the effect this gives is really really nice. I've tuned most things to work for the station, though mesons works for lavaland for obvious reasons. I've tuned things significantly darker then we have them set currently, since I really hate flat lighting and this system suffers when interacting with it. My goal with these is to give you a rough idea of what's around you, without a good eye for detail. That's the difference between say, mesons, and night vision. One helps you see outlines, the other gives you detail and prevents missing someone in the darkness. It's hard to balance this precisely because of different colored backgrounds (looking at you icebox) More can be done on this front in future but I'm quite happy with things as of now ### **EDIT** I have since expanded to all uses of nightvision, coloring most all of them. Along the way I turned some toggleable nightvision into just one level. Fullbright sucks, and I'd rather just have one "good" value. I've kept it for a few cases, mostly eyes you rip out of mobs. Impacted mobs are nightmares, aliens, zombies, revenants, states and sort of stands. I've done a pass on all mobs and items that impact nightvision and added what I thought was the right level of color to them. This includes stuff like blobs and shuttle control consoles As with glasses much of this was around reducing vision, though I kept it stronger here, since many of these mobs rely on it for engaging with the game <details> <summary> Technical Changes </summary> #### Adds filter proc (the ones that act like templates) support to filter transitions. Found this when testing this pr, seemed silly. #### Makes our emissive mask mask all light instead This avoids dumbass overlay lighting lighting up wallmounts. We switch modes if some turfflags are set, to accomplish the same thing with more overhead, and support showing things through the darkness. Also fixes a bug where you'd only get one fullscreen object per mob, so opening and closing a submap would take it away Also also fixes the lighting backdrop not actually spanning the screen. It doesn't actually do anything anymore because of the fullscreen light we have, but just in case that's unsued. Needs cleanup in future. #### Moves openspace to its own plane that doesn't draw, maxing its color with a sprite This is to support the above We relay this plane to lighting mask so openspace can like, have lighting #### Changes our definition of nightvision to the light cutoff of night vision goggles and such Side affect of removing see_in_dark. This logic is a bit weak atm, needs some work. #### Removes the nightvision spell It's a dupe of the nightvision action button, and newly redundant since I've removed all uses of it #### Cleans up existing plane master critical defines, ensures trasnparent won't render These sucked Also transparent stuff should never render, if it does you'll get white blobs which suck </details> ## Why It's Good For The Game Videos! (Github doesn't like using a summary here I'm sorry) <details> Demonstration of ghost lighting, and color https://user-images.githubusercontent.com/58055496/215693983-99e00f9e-7214-4cf4-a76a-6e669a8a1103.mp4 Engi-glass mesons and walking in maint (Potentially overtuned, yellow is hard) https://user-images.githubusercontent.com/58055496/215695978-26e7dc45-28aa-4285-ae95-62ea3d79860f.mp4 Diagnostic nightvision goggles and see_in_dark not hiding emissives https://user-images.githubusercontent.com/58055496/215692233-115b4094-1099-4393-9e94-db2088d834f3.mp4 Sec nightvision (I just think it looks neat) https://user-images.githubusercontent.com/58055496/215692269-bc08335e-0223-49c3-9faf-d2d7b22fe2d2.mp4 Medical nightvision goggles and other colors https://user-images.githubusercontent.com/58055496/215692286-0ba3de6a-b1d5-4aed-a6eb-c32794ea45da.mp4 Miner mesons and mobs hiding in lavaland (This is basically the darkest possible environment) https://user-images.githubusercontent.com/58055496/215696327-26958b69-0e1c-4412-9298-4e9e68b3df68.mp4 Thermal goggles and coloring displayed mobs https://user-images.githubusercontent.com/58055496/215692710-d2b101f3-7922-498c-918c-9b528d181430.mp4 </details> I think it's pretty, and see_in_dark sucks butt. ## 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. --> 🆑 add: The darkness that glasses and hud goggles that impact your nightvision (think mesons, nightvision goggles, etc) lighten is now tinted to match the glasses. S pretty IMO, and hopefully it helps with forgetting you're wearing X. balance: Nightvision is darker. I think bright looks bad, and things like mesons do way too much balance: Mesons (and mobs in general) no longer have a static distance you can see stuff in the dark. If a tile is lit, you can now see it. fix: Nightvision no longer dims colored lights, instead simply thresholding off bits of darkness that are dimmer then some level. /🆑 |
||
|
Tim
|
a1ada2c9ef |
Refactor, improve, and rename canUseTopic to be can_perform_action (#73434)
This builds on what #69790 did and improved the code even further. Notable things: - `Topic()` is a deprecated proc in our codebase (replaced with Javascript tgui) so it makes sense to rename `canUseTopic` to `can_perform_action` which is more straightforward in what it does. - Positional and named arguments have been converted into a easier to use `action_bitflag` - The bitflags adds some new checks you can use like: `NEED_GRAVITY | NEED_LITERACY | NEED_LIGHT` when you want to perform an action. - Redundant, duplicate, or dead code has been removed. - Fixes several runtimes where `canUseTopic` was being called without a proper target (IV drips, gibber, food processor) - Better documentation for the proc and bitflags with examples |
||
|
Mothblocks
|
d67555a0b5 |
the inevitable Revert "Refactors admin verbs from giant ass lists into datums" in case stuff breaks (#73206)
Reverts tgstation/tgstation#72407 |
||
|
Zephyr
|
7f25d7f17b |
Refactors admin verbs from giant ass lists into datums (#72407)
## About The Pull Request See title. ## Why It's Good For The Game Makes it easier for people to add new admin buttons, and also removes the giant ass ugly lists that are an affront to my eyes. Yes you are still able to call them manually via the verb bar   ## Changelog 🆑 refactor: Admin verbs are now datums with a dedicated panel handler admin: Admin verbs now come with a handy description when you hover over them! /🆑 --------- Signed-off-by: GitHub <noreply@github.com> |
||
|
Timberpoes
|
882e7db58f |
Stack traces when a cliented or ckeyed mob is Destroy()ed. (#72797)
## About The Pull Request One thing that repeatedly pops up in admin channels is investigating causes of death when a player just vanishes from the game. These are almost universally qdeletion issues. 9 years ago `/mob/Destroy()` was commented with: `//This makes sure that mobs with clients/keys are not just deleted from the game.` Whatever code may have existed back then has long since been replaced. **I consider that Destroy()ing a cliented or ckeyed mob is a runtime error case.** Code which may result in deleting a mob should handle removing and/or reassigning any client or ckey - or call generic procs that do so - prior to destruction. This should ideally result in a clear log trail that allows admins to see what happened. Where this isn't the case, a stack trace will now be available to help narrow down the cause of qdeletion so an issue report can be made, and so admins have SOME info to investigate on. An example of where this would help catch bugs is #72782 - It was clearly unintended behaviour to qdel the mob in the first place and this stack trace would have immediately highlighted exactly where the death came from. ``` [2023-01-18 12:44:40.415] runtime error: Mob with client has been deleted. (code/modules/mob/mob.dm:29) - proc name: stack trace (/proc/_stack_trace) - source file: stack_trace.dm,4 - usr: Julia Watson (/mob/living/carbon/human) - src: null - usr.loc: the floor (111,143,2) (/turf/open/floor/iron) - call stack: - stack trace("Mob with client has been delet...", "code/modules/mob/mob.dm", 29) - Julia Watson (/mob/living/carbon/human): Destroy(0) - Julia Watson (/mob/living/carbon/human): Destroy(0) - Julia Watson (/mob/living/carbon/human): Destroy(0) - Julia Watson (/mob/living/carbon/human): Destroy(0) - qdel(Julia Watson (/mob/living/carbon/human), 0) - the mouse (/mob/living/basic/mouse): try consume cheese(Julia Watson (/mob/living/carbon/human)) - the mouse (/mob/living/basic/mouse): tamed(the mouse (/mob/living/basic/mouse), Julia Watson (/mob/living/carbon/human)) - /datum/callback (/datum/callback): Invoke(the mouse (/mob/living/basic/mouse), Julia Watson (/mob/living/carbon/human)) - /datum/component/tameable (/datum/component/tameable): on tame(the mouse (/mob/living/basic/mouse), Julia Watson (/mob/living/carbon/human)) - the mouse (/mob/living/basic/mouse): SendSignal("simplemob_sentiencepotion", /list (/list)) - the intelligence potion (/obj/item/slimepotion/slime/sentience): attack(the mouse (/mob/living/basic/mouse), Julia Watson (/mob/living/carbon/human), "icon-x=16;icon-y=7;left=1;butt...") - the mouse (/mob/living/basic/mouse): attackby(the intelligence potion (/obj/item/slimepotion/slime/sentience), Julia Watson (/mob/living/carbon/human), "icon-x=16;icon-y=7;left=1;butt...") - the intelligence potion (/obj/item/slimepotion/slime/sentience): melee attack chain(Julia Watson (/mob/living/carbon/human), the mouse (/mob/living/basic/mouse), "icon-x=16;icon-y=7;left=1;butt...") - Julia Watson (/mob/living/carbon/human): ClickOn(the mouse (/mob/living/basic/mouse), "icon-x=16;icon-y=7;left=1;butt...") - the mouse (/mob/living/basic/mouse): Click(the floor (112,143,2) (/turf/open/floor/iron), "mapwindow.map", "icon-x=16;icon-y=7;left=1;butt...") - ``` See also #67300. An example of where this would help identify causes of death where previously there were none - Scenarios that were fixed by #62949 and #66104 caused administrative headaches figuring out causes of death when players in exploding crates just got literally fucking qdeleted. Which was pretty trivial for players to do to other players. Issue reports can be made and bugs can be fixed as we go along. There are examples of quote "false positives" unquote. Right click -> Delete, which can be used on any atom. ``` [2023-01-18 11:40:54.597] runtime error: Mob without client but with associated ckey has been deleted. (code/modules/mob/mob.dm:32) - proc name: stack trace (/proc/_stack_trace) - source file: stack_trace.dm,4 - usr: Norah Rader (/mob/dead/observer) - src: null - usr.loc: the floor (109,143,2) (/turf/open/floor/iron) - call stack: - stack trace("Mob without client but with as...", "code/modules/mob/mob.dm", 32) - Fulton Enderly (/mob/dead/observer): Destroy(0) - Fulton Enderly (/mob/dead/observer): Destroy(0) - qdel(Fulton Enderly (/mob/dead/observer), 0) - Timberpoes (/client): admin delete(Fulton Enderly (/mob/dead/observer)) - Timberpoes (/client): Delete(Fulton Enderly (/mob/dead/observer)) ``` Admin gibself ``` [2023-01-18 11:41:17.635] runtime error: Mob with client has been deleted. (code/modules/mob/mob.dm:29) - proc name: stack trace (/proc/_stack_trace) - source file: stack_trace.dm,4 - usr: Norah Rader (/mob/living/carbon/human) - src: null - usr.loc: the floor (109,145,2) (/turf/open/floor/iron) - call stack: - stack trace("Mob with client has been delet...", "code/modules/mob/mob.dm", 29) - Norah Rader (/mob/living/carbon/human): Destroy(0) - Norah Rader (/mob/living/carbon/human): Destroy(0) - Norah Rader (/mob/living/carbon/human): Destroy(0) - Norah Rader (/mob/living/carbon/human): Destroy(0) - qdel(Norah Rader (/mob/living/carbon/human), 0) - Norah Rader (/mob/living/carbon/human): gib(1, 1, 1, 0) - Norah Rader (/mob/living/carbon/human): gib(1, 1, 1, 0) - Timberpoes (/client): Gibself() ``` Over time these stack traces can be checked for how well the true cause of death is logged, and whether there is a better procedure for deleting cliented/ckeyed mobs than just qdel(target). ## Why It's Good For The Game qdeletion of cliented or ckeyed mobs is death and often lacks any specific logging. This obfuscates bugs and hinders admin investigation. stack_tracing highlights where this happens, revealing the previously obfuscated bugs more clearly. It also provides relevant information on a cause of death that can allow admin investigation to take place despite the absence of logging. ## Changelog 🆑 admin: When a player-owned mob is deleted from the game world, a stack trace is now dropped in the runtime logs. This allows admins and coders to investigate these issues easier. /🆑 |
||
|
Jeremiah
|
5e80257423 |
Refactors crew records (#72725)
## About The Pull Request I have attempted or otherwise started this project at least 4 times. I am sick of it being on my calendar. The code needs it. I need it. - This makes crew records a proper datum rather than assigning properties record.fields. - General, medical, and security records are merged. - Did some slight refactoring here and there for things that looked obvious. - Wanted states are now defined (and you can suspect someone through sechud) - pAI (unrelated but annoying) had some poorly named exported types that i made more specific - Job icons are moved back to the JS side (I wanted to get icons for initial rank without passing trim) <details> <summary>previews</summary> Editable fields & security console  Medical records  Look and feel of the more current version  </details> ## Why It's Good For The Game TGUI'd some of the worst UIs in the game. Creating new records is made much simpler. Manifest_inject is made readable. Probably bug fixes ## Changelog 🆑 refactor: Crew records have been refactored. refactor: Medical records -> TGUI refactor: Security records -> TGUI refactor: Warrants console -> TGUI qol: Players are now alerted when their fines are paid off. qol: Cleaned up sec hud examination text. qol: Adding and deleting crimes is easier. qol: Writing crimes in the console sets players to arrest. qol: You can now mark someone as a suspect through sec hud. /🆑 Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
Jeremiah
|
872e64fb05 |
Adds spaces around logical operators (#72603)
## About The Pull Request Part of a prior PR that was closed (#72562). This version does not add the check in CI. ## Why It's Good For The Game The work is already done, so I figured why not. ## Changelog N/A Nothing player facing Co-authored-by: Jeremiah Snow <jlsnow301@pm.me> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
MrMelbert
|
c3a1f21c1a |
Converts blindness and nearsightedness to status effects, scratches some VERY dumb blindness handling that resulted in mobs becoming "incurably" blind (#72267)
## About The Pull Request - Nearsighted is now a grouped status effect. - Blindness is now a grouped status effect. - Eye handling of blindness has improved. - When eyes are removed, they now cause you to become blind, rather than handling it in `update_tint`. - Being ahealed no longer blinds you for one tick, meaning that black overlay on aheal is gone. - Temporary Blindness is now a status effect. - Both Nearsightedness and Blindness have been exorcised from mob vars and life chains. This means that we've finally cut 2 procs from life, `handle_status_effect` and `handle_traits`, and moved both to event based processing. Wooo optimizations. - Swapped pacifism status effect to use apply and set helpers. - Removed an unused admin toggle that disabled welding helmet tint but also tint from every clothing item and also blindness from losing your eyes. - Clothes now generally all blind their mob more consistently. - Oculine, eye surgery, and sensory restoration are now no longer the only way to fix blindness from eye damage. If your eyes are healed through any other means, it will also heal your blindness. - Some things that made you blind, such as ling blind sting, no longer just flat made you blind from eye damage forever. They now cause eye damage directly, which in turn makes you blind from eye damage, as expected. - Pacifists can't eyestab anymore. Eyestabs now have a limit on the amount of blur applied. - Refactored some `is_x_covered` procs to accept flags rather than have a lot of arguments for some silly reason. - Unit tests for blindness. ## Why It's Good For The Game Blindness was exceptionally poorly handled prior, primarily due to the fact that it was tied to the mob instead of separated out On top of that the system put a LOT of faith in proper handling of blindness on the coder's end which was misplaced evidently. Many places didn't update or handle blindness correctly, or just let people perma-blind. Deferring it to a status effect improves this a lot ## Changelog 🆑 Melbert refactor: Refactored blindness and nearsightedness. Important to note is that all mobs are naturally blind until their eyes are actually created. refactor: Refactored "is covered" procs fix: Less sources of blindness now cause permanent blindness. Includes the "Blind" Spell and "Blind Sting" from changelings. admin: Ahealing someone no longer flashes the blind overlay for 1 tick. admin: I removed an unused (sort of) inaccessible admin verb that allowed you to toggle the tint from all welding helmets (and clothing) (and lack of eyes) in existence, let me know if you want similar back balance: Changeling "Blind Sting" now causes eye damage (enough to blind) rather than arbitrarily forcing blindness. balance: Visionloss virus symptom now causes eye damage (enough to blind) rather than arbitrarily forcing blindness. balance: Oculine has been reworked slightly. Prior, Oculine arbitrarily healed blindness and nearsightedness from eye damage reagrdless of how damaged the eyes were, and applied blur on success. Now, Oculine just heals eye damage, and blindness / nearsightedness is restored in the process. There is now a probability every tick that eye blur is applied based on how pure the oculine is while healing very damaged eyes. balance: Pacifists can no longer eyestab. balance: Any clothing item that covers your eyes contributes to getting the bonus while sleeping, and to removing temporary blindness faster /🆑 |
||
|
Mothblocks
|
9740f104d0 |
Contextual tutorials for swapping hands and dropping items (#72292)
# Requires https://github.com/tgstation/tgstation/pull/72320 ## About The Pull Request https://user-images.githubusercontent.com/35135081/209700892-e54be6cf-d18c-4d12-acd1-e5eb46e9d82d.mp4 https://user-images.githubusercontent.com/35135081/209700911-751b8a0e-d770-49fa-a6eb-ce50aa0fa670.mp4 --- Adds a system for tutorials that: - Are contextually given - Are not given again after completion - Can optionally not trigger for anyone who first played before a certain date Uses this system for a tutorial for switching hands/dropping items. This tutorial is triggered when you try to click on an item with another item, and `afterattack` return FALSE. In order for this to work as smoothly as possible, I'm going to open a separate PR that cleans up the `afterattack` on everything to either return TRUE/FALSE. ## Why It's Good For The Game SS13 is an extremely confusing game, being able to do tutorials in a non-intrusive way (like a separate tutorial mode) is nice. The system in place is going to be perfectly usable for introducing mechanics to both fresh players and experienced players alike (such as for future content). ## Changelog 🆑 qol: New players will now get a contextual tutorial for how to switch hands and drop items. /🆑 Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> |
||
|
MrMelbert
|
0d4b56435b |
Converts drowsy and eye blur to status effects, striking yet another two carbon level status vars (#71950)
## About The Pull Request You know the deal by now. - Drowsiness is now tracked via status effect. - Eye blue is now tracked via status effect. In converting these over, cleaned up a bit of code relating to some other effects. Attempts to unify behavior between some of them, namely certain biotypes or mob types shouldn't be experiencing certain effects. ## Why It's Good For The Game More stuff moved to status effects, slightly more cleaner and better to work with code. Allows for all mobs that can sleep to be able to get drowsy, too. ## Changelog 🆑 Melbert refactor: Drowsiness and Blurred Eyes are now tracked via status effect. /🆑 |
||
|
Fikou
|
febdb61e01 |
makes status tab use signals, thirds the delay between updates (#72002)
## About The Pull Request status panel for carbons and humans instead of hardcoding stuff, uses signals (borg material storage too) removes combat mode indicator in status tab from xenomorphs which have a button for it, but adds it to simplemobs, since they dont have a visual indicator adds status tab stuff to basic mobs, i think they were missing everything by accident offsets unique status tab stuff for all mobs by a single line the delay between updates is a third of what it was before, mainly to make shuttle timers more accurate (approved by kyler) ## Why It's Good For The Game much cleaner code, makes future implementations easy ## Changelog 🆑 qol: you can see your combat mode status as a simple or basic mob, and you can see your health as a basic mob qol: status panel updates three times as fast /🆑 |
||
|
DragonTrance
|
82d825c3cd |
Respawn Verb now alerts if respawning is disabled (#71874)
I'm not sure how it was before, but pressing the respawn verb if it's disabled will now alert non-admins if it's disabled. I suggested for the verb to be unavailable completely if you can't respawn like this to avoid confusion with new players, but it was shrugged off. Also fixes the grammorr a bit with admins trying to use it instead to bypass the config. |
||
|
John Willard
|
2425531eb2 |
Removes tablets (not PDAs) entirely. (#71507)
## About The Pull Request **Comes with an UpdatePaths!** Removes the tablet subtype, PDAs now replaces them entirely. Nukie and Silicon tablets are now subtypes of the PDA instead, while contractor ones were removed entirely as they didn't do anything and were unused (though it wouldn't be hard to re-add). Nukie PDAs are now the only type of PDA that uses modular_tablets.dmi, which is just larger icons of modular_pda. Each application requires an icon state in both of these, for 2 different sizes, which makes it annoying to make new applications, especially if it can also run on computers/laptops. ### Icons Because Silicon tablets are now a subtype of PDA, they use PDA icons instead of tablet ones. Luckily for us, they already exist in code.  AI's don't use a tablet icon though, so they aren't affected. ## Why It's Good For The Game There's very little difference between tablets and PDAs, PDAs overshadow them in every single way, so at this point I don't see why we should have both of these, and if you compare the two in usefulness and actual in-game use by players, it's a no-brainer than the item all players get roundstart and comes with a messenger should be the one we go with. Also as said in the about section, when making an app you would need to make icon states for the program running for all hardware it can run on, which is Computer, Laptop, PDA, and Tablet. Laptop is just a smaller computer icon PDA is just a smaller tablet icon However, you can't simply shrink the size of the icon, instead you have to completely resprite the same app icon FOUR TIMES for it to not bluescreen on all these different devices. <details> <summary> Here's examples of it </summary> Computer (NOTE: *They share the same icon file as regular computers*) <img src="https://user-images.githubusercontent.com/53777086/203876801-486a8054-489a-4983-bdad-a2599b4dc379.png"/> Laptop <img src="https://user-images.githubusercontent.com/53777086/203876333-58e5d135-f4c6-4a02-8948-1df771e294a4.png"/> Tablet <img src="https://user-images.githubusercontent.com/53777086/203876352-816c7fb1-c681-40b9-99e0-052f49632c7f.png"/> PDA <img src="https://user-images.githubusercontent.com/53777086/203876358-1cf7253d-3c6a-456a-8133-ebf7f0351637.png"/> </details> If we wish to help in simplifying this, we should remove tablet icons entirely, which means 1 less icon to worry about. To do this, we'd need to resprite nukie PDAs, however I am very much not a spriter and never tried GAGS, so I'll leave it to someone else to do. ## Changelog 🆑 del: Tablets are now removed, PDAs are now the base 'tablet'. Silicon and nukie tablets are now PDAs. /🆑 |
||
|
LemonInTheDark
|
24d795b354 |
Adds a preference that disables intensive rendering on different multiz layers (#71218)
## About The Pull Request It's kinda hacky, but it is nearly the same as just rendering one z layer. We allow people to ENTIRELY REMOVE most plane masters from their screen. This has the side effect of disabling most visual effects (AO is a big one) which saves a LOT of gpu. We rely on planes being essentially layers to ensure things render in the proper order. (outside of some hackyness required to make parallax work) I've kept parallax and lighting enabled, so visuals will still look better then multiz pre plane cube. It does also mean that things like FOV don't work, but honestly they didn't work PRE plane cube, and FOV's implementation makes me mad so I have a hard time caring. Reduces gpu usage on my machine on tram from 47% to 32%, just above the 27% I get on meta. I'm happy with this. Oh also turns out the parallaxing had almost no cost. Need to remove it as a side effect of what I'm doing but if I could keep it I would. There's still room for in between performance options, like disabling things like AO on lower z layers, but I didn't expect it to make a huge impact, so I left things as is Also fixes a bug with paper bins not respecting z layer. It came up in testing and annoyed me ## Why It's Good For The Game Ensures we can make multiz maps without running into client performance issues, allows users to customize performance and visual quality. ## Changelog 🆑 add: Adds a new rendering option to the gameplay preferences. You can now limit the rendering intensity of multiz levels. This will make things look a bit worse, but run a LOT better. Try it out if your machine chokes on icebox or somethin. /🆑 Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
AnturK
|
84f69359a0 |
More horrible 515 proc compatibility. (#71333)
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. |
||
|
AnturK
|
4d6a8bc537 |
515 Compatibility (#71161)
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
|
||
|
Gamer025
|
677827e87d |
Expands mob_tags logging (#70259)
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
John Willard
|
91f02f2a6b |
canUseTopic now uses TRUE/FALSE instead of defines that just say TRUE (#69790)
* canUseTopic now uses TRUE/FALSE instead of defines that just say TRUE The most idiotic thing I've seen is canUseTopic's defines, they literally just define TRUE, you can use it however you want, it doesn't matter, it just means TRUE. You can mix and match the args and it will set that arg to true, despite the name. It's so idiotic I decided to remove it, so now I can reclaim a little bit of my sanity. |
||
|
LemonInTheDark
|
23bfdec8f4 |
Multiz Rework: Human Suffering Edition (Contains PLANE CUBE) (#69115)
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 #65800 Fixes #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 |
||
|
ShizCalev
|
5c9d863998 |
Demoralization fixes (#69924)
* Demoralization fixes Blind mobs will no longer be demoralized by posters and graffiti. Illiterate mobs will no longer be demoralized by the words on posters. Mobs will no longer be demoralized by posters & graffiti if it's too dark to see them. Also makes can_read use reading check flags, one for literacy and one for light. |
||
|
John Willard
|
a0442ee002 |
Removes persistence of items through changing species when not allowed to (#70008)
* Removes persistence of species-restricted items through changing Makes use of item's mob_can_equip instead of mob's can_equip, making it take the item's restrictions into account. Also, fixes the inventory's color, so it's properly red when you can't equip such an item, by making it also use mob_can_equip. Finally, expands the species clothing unit test to take that into account, to prevent it breaking in the future. |
||
|
LemonInTheDark
|
930c5e635e |
Moves "catch this var/flag" code from obj/init and datum/new into the types that use it (#69634)
* Optimizes away /obj/Initialize We were spending like 0.15 seconds just checking for blueprints, obj flags and network ids All these things can just be applied where they're wanted, saves time Oh and I replaced object flags with an emag injector. I'll give it a sprite and name later I promise * Requires a GenerateTag() call to set DF_USE_TAG, rather then doing a check in atom New This is technically harder to use, but I don't really want people using tags, and it saves 0.15 seconds * Moves generatetag to /datum * I am dumb * Saves 0.5 seconds, makes init emissive blockers actually work Ok so background. If an overlay is added with add_overlay, and not "managed" somehow, it will effectively never be removed, because nothing's tracking it. Update_overlays uses the managed_overlays list/var (one of those) to do this. I'm gonna piggyback off this to make emissive overlays actually like, respect overlay updates. Oh and uh, I've saved maybe 0.5 seconds by caching the new emissive, and not using add_overlay. There's a chance this will lead to overlay corruption, but since we never readd the flattened, I think we'll be safe * Fixes plane not being set right, changes color logic too, since alpha will override past color sets * Makes it actually work. also makes rand posters update appearance to clear away the overlay, since it shows on right click and looks bad * Fixes blockers showing as emissives. It turns out alpha sets override the color list we use. Not sure why we pretend to support them * Makes the injector support traits, adds an amazing sprite |
||
|
Seth Scherer
|
f1a363c825 |
Converts a shitload of istypes to their more concise macros (#69260)
* Converts a lot of istypes() to use their istype macro helpers. |
||
|
Kapu1178
|
2eccf3cea0 |
Cleans up update_icons, makes the update_icon_updates_onmob element bespoke, updates CODEOWNERS (#69179)
* I just realised this is all one commit. * hail marry * fix. * FIXES IT FOR REAL * Update code/datums/elements/update_icon_updates_onmob.dm |
||
|
Mooshimi
|
b09f3868f8 |
individual LOG_GAME (#68683)
About The Pull Request
replaces a ton of log_game with user.log_message so the log is added to individual and global logs.
adds a few logs for individual LOG_VICTIM, LOG_ATTACK etc logging.
adds logging for bluespace launchpad's tele coords being changed.
took the word "has" out of log_combat, as it's extra and just lengthens the log.
Why It's Good For The Admins
It's extremely laggy to open game.txt so an alternative is individual game logs
Changelog
cl
admin: A lot of game logs will now also be in individual game logs, for convenience in log diving.
admin: Added logging for bluespace launchpad x and y offset changes, which go to individual game logs.
admin: Attack logs will now be slightly shorter, one useless word was removed.
/cl
|
||
|
Timberpoes
|
786ac5c855 |
[MDB Ignore][Bounty][Complete Refactor] Papercode Redux: Too Many Damn Files <Map Conflict Edition> (#68612)
Papercode refactor |
||
|
Kylerace
|
77c2b7f50c |
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 |
||
|
Matt
|
53cee6635f | Fix: #41250 You can't use a tablet while inside a locker (#68171) | ||
|
Mothblocks
|
99fb15a462 |
Pointing at something on yourself now shows the item (#68642)
Why It's Good For The Game Further reducing reliance on reading the chat box. Previously it wasn't obvious someone pointing at themselves was pointing at something on them, and not just, them. Changelog cl qol: Pointing at something on yourself now shows the item. /cl |
||
|
zxaber
|
c2a029a6f2 |
Fixes airlock shock indicators not being removed when the airlock is unshocked (#68112)
shocking development |
||
|
MrMelbert
|
f8f3dbed98 |
Completely removes proc_holders from existence. Refactors all wizard, xeno, spider, and genetics powers to be actions. Also refactors and sorts ton of accompanying code. (#67083)
* destroy proc holder pt1 - change proc_holder/spell to action/cooldown/spell - docs all the spell vars, renames some of them - removes some useless vars - start with pointed spells, as they're easy * kill proc_holder pt2 - kill a buncha vars and replace it with flags - convert a ton over - general code improvements * kill proc_holders pt3 - convert a good few more spells - rename some signals - handle statpanel - better docs * kiill proc_holder pt4: - restructure the file system of action.dm, separating a good amount of item actions and miscellaneous garbage into files where they belong slightly better. Also splits off item actions, cooldown actions, innate actions, etc. into their own files, overlal making it much better to work with - converts touch attacks to actions - converts blood crawl, jaunt subtype * kills proc_holder pt5 - clears up some icon issues so all the currently converted pages don't have errors - shapeshift - some more action cleanup * kills proc_holder pt5.5: - some documentation - reworks feedback to prevent oversight with teleports and stuff * kills proc_holder pt6: - converted cult spells - converted magic missile - converted mime spells - chipped away at the errors - removed some vars which were too general, replaced them with more locally applicable vars. for example "range" which could mean "projectile range" or "aoe radius" or whatever - instead of having a broad net which everyone applies to in a confusing matter, instead lets each spell delegate on their own. - merged magic/spell and magic/aoe, as the comment intended - more unified behavior for spell levelling * kill proc_holders pt 6.5: - replacing a buncha old proc_holders that have been updated to reduce some errors. sub 900 baby * kills proc_holder pt 6.75: - minor fixes * kills proc_holder pt7: - cuts down on some errors - refactors some wiz events * kills proc_holder pt 7.5: - malf ranged modules - some minor errors * kills proc_holder pt 7.75: - mor eminor error handling, cleaning up changes * kill proc_holder pt8: - refactors spell book - refactors spell implant - some more minor error fixing * kill proc_holder pt 8.5: - scan ability * Adds some robust documentation * kill proc_holder pt9: - converts some / most mutations over * kill proc_holder pt10: - sort out all the granters - refactor them slightly - fix some compile errors * Some set-unset sanity - going to need to test removing Share() * Removes transfer actions. It doesn't seem to do anything. - Transfer_actions was called when current = new_character so locially speaking the early return in Grant() should cause it to NOOP. Test this in the future though * Removes sharing from actions, docs actions better * Some better documentation for spell and spell components * Kills proc_holder pt11: - Finally finishes ALL THE SPELLS IN THE SPELL FOLDER - Fixes some more errors * kills proc_holder pt11.5: - minor error fixing and sanity * Method of sharing actions. Can be improved in the future, needs testing * Implements a way to update the stat panel entry for a spell. Also gets rid of VV stuff, as you can update the bigflags directly in VV now. * Curse of madness bug I put in. * kills proc_holder pt12: - sub 500 errors! - converts cytology mobs - converts and refactors spiders slightly - some minor fixing around the place as usual * kill proc_holder pt13 - Finishes heretic spells - Sub 300 errors! - some touch refactoring to account for mansus grasp * kills proc_holder pt14: - revenant - minor bugfixing for heretic stuff * kills proc_holder pt14.5: - some missed stuff for revenant + heretic * kills proc_holder pt15: - alien abilities - more minor fixing - sub 100 errors. The end is nigh * kill proc_holder pt16? 17: - Finishes cult spells - sub 50 errors! - refactors the way charge works - renames / moves some signals * kills proc_holder pt final: - sdql spells - no more errors! * Bugfixes round 1 * Various bugfixing - documentation done - give spell works - can cast spell gives feedback conditionally - is available takes into account casting ability * Some accidental reversions + fixes * Unit tests * Completely refactors jaunting - All bloodcrawling is now handled on the action itself instead of across various living procs - slaughter demons have their own blood crawls - jaunting dummies don't have side effects on destroy() anymore * Wizard spell logging and even more refactoring |
||
|
13spacemen
|
b864589522 |
Examine Blocks (#67937)
* adds examine_block class and a define for it made some outputs in chat use examine_block * add examine block to tip of the round clean up some ------ and ***** seperators added <hr> tags to divide sections cleaned up botany plant analyzer text outputs * bullet points for reagents * removes <hr> from mobs examines fixes AIs and borgs having a double "That's Default Cyborg!" removed some \n newlines minor code edits * removes all <hr> bold names in get_examine_name() cleaned up plant analyzer output formatting adjust colors and margins of examine_block class remove \a from borg examine() * remove max-width from css * changed margin and padding units from px to em * minor edit |
||
|
ArcaneMusic
|
9d826a5e7f | Fixes the white cane sounds, and blind mob's examine. (#67941) | ||
|
Kylerace
|
8f0df7816b |
(code bounty) The tram is now unstoppably powerful. it cannot be stopped, it cannot be slowed, it cannot be reasoned with. YOU HAVE NO IDEA HOW READY YOU ARE (#66657)
ever see the tram take 10 milliseconds per movement to move 2100 objects? now you have https://user-images.githubusercontent.com/15794172/166198184-8bab93bd-f584-4269-9ed1-6aee746f8f3c.mp4 About The Pull Request fixes #66887 done for the code bounty posted by @MMMiracles to optimize the tram so that it can be sped up. the tram is now twice as fast, firing every tick instead of every 2 ticks. and is now around 10x cheaper to move. also adds support for multiz trams, as in trams that span multiple z levels. the tram on master takes around 10-15 milliseconds per movement with nothing on it other than its starting contents. why is this? because the tram is the canary in the coal mines when it comes to movement code, which is normally expensive as fuck. the tram does way more work than it needs to, and even finds new ways to slow the game down. I'll walk you through a few of the dumber things the tram currently does and how i fixed them. the tram, at absolute minimum, has to move 55 separate industrial_lift platforms once per movement. this means that the tram has to unregister its entered/exited signals 55 times when "the tram" as a singular object is only entering 5 new turfs and exiting 5 old turfs every movement, this means that each of the 55 platforms calculates their own destination turfs and checks their contents every movement. The biggest single optimization in this pr was that I made the tram into a single 5x11 multitile object and made it only do entering/exiting checks on the 5 new and 5 old turfs in each movement. way too many of the default tram contents are expensive to move for something that has to move a lot. fun fact, did you know that the walls on the tram have opacity? do you know what opacity does for movables? it makes them recalculate static lighting every time they move. did you know that the tram, this entire time, was taking JUST as much time spamming SSlighting updates as it was spending time in SStramprocess? well it is! now it doesnt do that, the walls are transparent. also, every window and every grille on the tram had the atmos_sensitive element applied to them which then added connect_loc to them, causing them to update signals every movement. that is also dumb and i got rid of that with snowflake overrides. Now we must take care to not add things that sneakily register to Moved() or the moved signal to the roundstart tram, because that is dumb, and the relative utility of simulating objects that should normally shatter due to heat and conduct heat from the atmosphere is far less than the cost of moving them, for this one object. all tram contents physically Entered() and Exited() their destination and old turfs every movement, even though because they are on a tram they literally do not interact with the turf, the tram does. also, any objects that use connect_loc or connect_loc behalf that are on the same point on the tram also interact with each other because of this. now all contents of the tram act as if theyre being abstract_move()'d to their destination so that (almost) nothing thats in the destination turf or the exit turf can react to the event of "something laying on the tram is moving over you". the rare things that DO need to know what is physically entering or exiting their turf regardless of whether theyre interacting with the ground can register to the abstract entered and exited signals which are now always sent. many of the things hooked into Moved(), whether it be overrides of Moved() itself, or handlers for the moved signal, add up to a LOT of processing time. especially for humans. now ive gotten rid of a lot of it, mostly for the tram but also for normal movement. i made footsteps (a significant portion of human movement cost) not do any work if the human themselves didnt do the movement. i optimized has_gravity() a fair amount, and then realized that since everything on the tram isnt changing momentum, i didnt actually need to check gravity for the purposes of drifting (newtonian_move() was taking a significant portion of the cost of movement at some points along the development process). so now it simply doesnt call newtonian_move() for movements that dont represent a change in momentum (by default all movements do). also i put effort into 1. better organizing tram/lift code so that most of it is inside of a dedicated modules folder instead of scattered around 5 generic folders and 2. moved a lot of behavior from lift platforms themselves into their lift_master_datum since ideally the platforms would just handle moving themselves, while any behavior involving the entire lift such as "move to destination" and "blow up" would be handled by the lift_master_datum. also https://user-images.githubusercontent.com/15794172/166220129-ff2ea344-442f-4e3e-94f0-ec58ab438563.mp4 multiz tram (this just adds the capability to map it like this, no tram does this) Actual Performance Differences to benchmark this, i added a world.Profile(PROFILER_START) and world.Profile(PROFILER_START) to the tram moving, so that it generates a profiler output of all tram movement without any unrelated procs being recorded (except for world.Profile() overhead). this made it a lot easier to quantify what was slowing down both the tram and movement in general. and i did 3 types of tests on both master and my branch. also i should note that i sped up the "master" tram test to move once per tick as well, simply because the normal movement speed seems unbearably slow now. so all recorded videos are done at twice the speed of the real tram on master. this doesnt affect the main thing i was trying to measure: cost for each movement. the first test was the base tram, containing only my player mob and the movables starting on the tram roundstart. on master, this takes around 13 milliseconds or so on my computer (which is pretty close to what it takes on the servers), on this branch, it takes between 0.9-1.3 milliseconds. ALSO in these benchmarks youll see that tram/proc/travel() will vary significantly between the master and optimized branches. this is 100% because there are 55 times more platforms moving on master compared to the master branch, and thus 55x more calls to this proc. every test was recorded with the exact same amount of distance moved here are the master and optimized benchmark text files: master master base tram.txt https://user-images.githubusercontent.com/15794172/166210149-f118683d-6f6d-4dfb-b9e4-14f17b26aad8.mp4 also this shows the increased SSlighting usage resulting from the tram on master spamming updates, which doesnt happen on the optimized branch optimized optimization base tram.txt https://user-images.githubusercontent.com/15794172/166206280-cd849aaa-ed3b-4e2f-b741-b8a5726091a9.mp4 the second test is meant to benchmark the best case scaling cost of moving objects, where nothing extra is registered to movement besides the bare minimum stuff on the /atom/movable level. Each of the open tiles of the tram had 1 bluespace rped filled with parts dumped onto it, to the point that the tram in total was moving 2100 objects. the vast majority of these objects did nothing special in movement so they serve as a good base case. only slightly off due to the rped's registering to movement. on master, this test takes over 100 milliseconds per movement master 2000 obj's.txt https://user-images.githubusercontent.com/15794172/166210560-f4de620d-7dc6-4dbd-8b61-4a48149af707.mp4 when optimized, about 10 milliseconds per movement https://user-images.githubusercontent.com/15794172/166208654-bc10086b-bbfc-49fa-9987-d7558109cc1d.mp4 optimization 2000 obj's.txt the third test is 300 humans spawned onto the tram, meant to test all the shit added on to movement cost for humans/carbons. in retrospect this test is actually way too biased in favor of my optimizations since the humans are all in only 3 tiles, so all 100 humans on a tile are reacting to the other 99 humans movements, which wouldnt be as bad if they were distributed across 20 tiles like in the second test. so dont read into this one too hard. on master, this test takes 200 milliseconds master 300 catgirls.txt when optimized, this takes about 13-14 milliseconds. optimization 300 catgirls on ram ranch.txt Why It's Good For The Game the tram is literally 10x cheaper to move. and the code is better organized. currently on master the tram is as fast as running speed, meaning it has no real relative utility compared to just running the tracks (except for the added safety of not having to risk being ran over by the tram). now the tram of which we have an entire map based around can be used to its full potential. also, has some fixes to things on the tram reacting to movement. for example on master if you are standing on a tram tile that contains a banana and the TRAM moves, you will slip if the banana was in that spot before you (not if you were there first however). this is because the banana has no concept of relative movement, you and it are in the same reference frame but the banana, which failed highschool physics, believes you to have moved onto it and thus subjected you to the humiliation of an unjust slipping. now since tram contents that dont register to abstract entered/exited cannot know about other tram contents on the same tile during a movement, this cannot happen. also, you no longer make footstep sounds when the tram moves you over a floor TODO mainly opened it now so i can create a stopping point and attend to my other now staling prs, we're at a state of functionality far enough to start testmerging it anyways. add a better way for admins to be notified of the tram overloading the server if someone purposefully stuffs it with as much shit as they can, and for admins to clear said shit. automatically slow down the tram if SStramprocess takes over like, 10 milliseconds complete. the tram still cant really check tick and yield without introducing logic holes, so making sure it doesnt take half of the tick every tick is important go over my code to catch dumb shit i forgot about, there always is for these kinds of refactors because im very messy remove the area based forced_gravity optimization its not worth figuring out why it doesnt work fix the inevitable merge conflict with master lol create an icon for the tram_tunnel area type i made so that objects on the tram dont have to enter and exit areas twice in a cross-station traversal add an easy way to vv tram lethality for mobs/things being hit by it. its an easy target in another thing i already wanted to do: a reinforced concept of shared variables from any particular tram platform and the entire tram itself. admins should be able to slow down the tram by vv'ing one platform and have it apply to the entire tram for example. Changelog cl balance: the tram is now twice as fast, pray it doesnt get any faster (it cant without raising world fps) performance: the tram is now about 10 times cheaper to move for the server add: mappers can now create trams with multiple z levels code: industrial_lift's now have more of their behavior pertaining to "the entire lift" being handled by their lift_master_datum as opposed to belonging to a random platform on the lift. /cl |
||
|
ArcaneMusic
|
1eaca674f0 |
Adds the white cane. (Bounty Code) (#67801)
This PR adds the white cane. It can be crafted using 3 iron rods. Additionally, white canes can be purchased from the medical vendor, differentiating them from the costume canes. White canes are transforming items that can be folded down from a small size to their fully extended versions, which are too large to store in a bag. |
