mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-06-07 23:31:38 +01:00
133d5b4a8564bb372bcffd3d403529de14b747cb
90 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 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> |
||
|
Tim
|
b2f4cc70e9 |
Add glasses and icons to preference menu for nearsighted (#75642)
## About The Pull Request This adds a few more regular glasses options to the nearsighted pref menu: - Random - Jamjar - Binoclard It also displays the icons for the TGUI dropdown menu. ## Why It's Good For The Game More variety and better visualization. (nearsighted... get it?) ## Changelog 🆑 qol: Add more glasses to the nearsighted pref menu with icons /🆑 --------- Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com> |
||
|
Jacquerel
|
2732e96cff |
Confine Elevator Music to Elevators (#75464)
Refactors elevator music to originate from an abstract object rather than the elevator control panel. Elevator music is applied while you are within a certain radius of this object and cuts off immediately upon exiting (largely because as far as I know you can't obtain playing sounds to fade them out in byond). As a side-effect of this refactor it also isn't audible to ghosts at all. |
||
|
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> |
||
|
Watermelon914
|
a98706ff8b |
Adds TTS to the game. Players can select their own voices in preferences. (#74775)
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
thgvr
|
08898964e6 |
Updates Lizard Sprites & New Digitigrade Sprites (#74549)
## About The Pull Request Hi. This pr contains work that is a collaborative effort between myself, Halcyon, Mqiib and `2cents#8442` for the original leg-work (Ha Ha, Get it?), ultimately finished by myself. Here's a preview!  And here's some side previews!  ## Why It's Good For The Game Lizard sprites have not been updated since their inception in 2016. They will now be updated and be much more consistent with everything else. Signed off by @optimumtact ## Changelog 🆑 imageadd: Lizards have been resprited, as well as Digitigrade sprites. Please remember to update your colors to account for this. /🆑 |
||
|
Bloop
|
1ee738c5d3 |
Fixes floating point inaccuracies in numeric preferences (#74384)
## About The Pull Request Floating point inaccuracy fun. Since it's possible to have a `minimum`,`maximum`, and `step` that are floats we need to round everything to `step` to ensure the comparison operations work. If we do not do this, there is no guarantee that `if(min <= number && number <= max)` will work correctly. For example, in the linked issues, this manifested as the minimum value (0.8) being considered invalid when the input was also 0.8. Fixes https://github.com/Skyrat-SS13/Skyrat-tg/issues/9507 Fixes https://github.com/Skyrat-SS13/Skyrat-tg/issues/14394 ## Why It's Good For The Game Fixes an obscure bug that has gone unnoticed for a couple years. ## Changelog 🆑 fix: fixes floating point inaccuracies in numeric prefs /🆑 |
||
|
lizardqueenlexi
|
95b810919e |
Adds preference for "Tagger" paint color. (#74281)
## About The Pull Request Per the title, this PR allows you to pick your starting paint color from the "Tagger" quirk on the character preferences menu.  This replaces the starting color being random; it does not prevent you from changing the color later as normal. ## Why It's Good For The Game It's a minor quality of life change. This will mostly be helpful to players who have some "signature" color they like to use, to prevent having to manually select it (and possibly input a color code) every round. It will be of less relevance to those who tend to select new colors every round anyway. Possible downsides are mainly adding another pref to the menu, although this shouldn't be too much of an annoyance since it only appears if you already have the relevant quirk. It does also remove the _ability_ to have a randomly-chosen paint color, though I'm not sure if that matters. ## Changelog 🆑 qol: you can choose your default paint color for the "Tagger" quirk from prefs. /🆑 |
||
|
Zephyr
|
ecbcef778d |
Refactors Regenerate Organs, and a few organ helpers (#74219)
## About The Pull Request Refactors regenerate organs to be slightly more intelligent in handling organ changes and replacements. Noteably: - We don't remove organs that were modified by the owner; such as changing out your heart for a cybernetic - We early break out of the for loop if they aren't supposed to have an organ there and remove it - We check for the organ already being correct, and just healing it and continuing if it is Also changes the names of some of the organ helpers into snake_case ### Mapping March Ckey to receive rewards: N/A ## Why It's Good For The Game ## Changelog --------- Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
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. /🆑 |
||
|
John Willard
|
c58cbb4dfb |
Reworked PDA menu & NtOS themes (#73070)
## About The Pull Request This is a port/rework of https://github.com/yogstation13/Yogstation/pull/15735 - I changed a lot of how it acted (some themes are locked behind maintenance apps). The original author allowed this port to happen, and I really liked how it looked there so I'd like to add it here. ### Applications Removes the hardware configurator application, as all it did was show you your space and battery now that all hardware was removed. These are things your PC does by default, so it was just a waste of space. Adds a Theme manager application instead, which allows you to change your PDA's theme at will. Adds a new Maintenance application that will give a new theme, however it will also increase the size of the theme manager app itself as it's bloatware. ### Menu There's now a bar at the top of the menu showing 'special' tablet apps which, for one reason or another, should stand out from the rest of the apps. Currently this is PDA messenger and the Theme manager Flashlight and Flashlight color is now only an icon, and is shown on the same line as Updating you ID https://cdn.discordapp.com/attachments/961874788706574386/1069621173693972551/2023-01-30_09-10-52.mov  ### Themes Adds a lot of themes to choose from, although SOME are hidden behind Maintenance applications, which will give you a random theme. These are bloatware however, so they come with some extra cost to the app's required space storage. Themes are now supported on ALL APPLICATIONS! If you have a computer theme, you will have that theme in EVERY app you enter, rather than just a select few. ALSO also, emagging the tablet will automatically set & unlock the Syndicate theme, which makes your PDA obvious but you can disguise it if you wish through just re-painting it to something else. https://cdn.discordapp.com/attachments/828923843829432340/1069565383155122266/2023-01-30_05-29-53.mov ### Preferences This also adds a pref for theme, reworking the ringtone code to work with it as well. I also removed 2 entirely unused PDA prefs just 'cause. Screenshot not up-to-date, they now have proper names.  ### Other stuff Made defines for device_themes Added support for special app-side checks to download files Fixed programs downloading themselves TWICE because defines all had the same definition Removes the Chemistry computer disk as it was empty due to chemistry app's removal Removes the 'run_emag' proc, since apps can directly refer to the computer to check for emag status instead. Moved over and added better documentation on data computer files, and moved the ordnance ones to the same file as the others. ## Why It's Good For The Game It makes PDAs a lot more customizable while adding more features to maintenance applications. I think the themes look cool and it fits with PDAs being "personal" anyways. I also explained most of my other arguments in the about section, such as the hardware configuration application. ## Changelog 🆑 Chubbygummibear & JohnFulpWillard add: A ton of new NtOS themes, which are accessible by the new Themify application that comes with all PCs. add: Emagging a PC now defaults it to the Syndicate option (and adds it to go back to it if you wish) add: There's a new maintenance app that gives you rarer themes qol: The NtOS Main menu was moved around, added "header" applications that are shown where the Flashlight is, such as your Theme manager and PDA messenger. code: Made defines for device_themes code: Added support for special app-side checks to download files code: Removes the 'run_emag' proc, since apps can directly refer to the computer to check for emag status instead. fix: Programs no longer download twice. del: Removes the Chemistry computer disk as it was empty due to chemistry app's removal /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
scriptis
|
898221e5ab |
Update tgui say keybindings when keybindings are updated (#73257)
Updating or resetting your preferences doesn't actually currently update the movement/tgui say keybindings. This fixes that, although there's still a weird heisenbug with NULL keybindings that we haven't been able to reproduce at all from #73247 |
||
|
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> |
||
|
tralezab
|
7795faec8a |
Memory Expansion! New memories, and prisoners are tattoo'd to the degree of their crime. (#72457)
## About The Pull Request ### New Memories - Added a memory for catching a fish - Added a memory of who turned you into a revolutionary, this might be very cool later on for mindreading purposes - Added a memory for infusing with something ### Prisoner Tats - Prisoner backgrounds now come with a certain amount of tattoos depending on what you did. Negligence? Zero tats. <details> <summary>Mass Murderer?</summary> BECOME https://youtu.be/7xUtZzLBV5c?t=73 </details> - Because I wanted someone covered head to toe in tats, there is now a "Mass Murderer" background that comes with 6 tattoos, one for each limb. ## Why It's Good For The Game ## Changelog 🆑 add: Some prisoner backgrounds have more or less tattoos. add: More Memories to collect involving fishing and getting converted /🆑 |
||
|
lessthanthree
|
ed5a6c4964 |
Admin alert for communications console messages (#72412)
Adds an audio alert when a CentCom or Syndicate communications console message is sent, for things such as ERT requests. It is optional and can be toggled in the Game Preferences menu. Also fixes an incorrect line in the prefs readme.md Less missing CentCom messages because you're busy doing other things, less complaining that you're ignoring them. |
||
|
MrMelbert
|
717e4f435c |
Quirks are passed an incoming client when applied, allowing quirks to read preferences in add and add_unique. Renders visual quirks on the preference menu dummy. (#72158)
## About The Pull Request Closes #72141 Roundstart humans weren't in control of their mob by the time `AssignQuirks` was called. The call chain for roundstart goes `create_characters` -> `equip_characters` -> `AssignQuirks` -> `transfer_characters`. For latejoin, `create_character` -> `transfer_character` -> `AssignQuirks`. I could simply move around the call chain, but that feels much more fragile and more liable to cause other issues to me. So instead, I simply allowed add quirk to be passed a client, so that a client's quirks can be applied to a mob they are not currently inhabiting. In doing this, it became possible to show visual quirks on the prefs dummy, like nearsighted glasses and heterochromia. So I put in a little work to accomplish that as well.  Along side, some refactoring and documentation for quirk datums. ## Why It's Good For The Game People get what they expect on roundstart. ## Changelog 🆑 Melbert qol: The preview dummy in the preferences menu now shows some visual quirks, like Heterochromia or nearsighted. fix: Fixed some quirks which read a preference roundstart not applying the preference. refactor: Refactored some bits of quirk datums and the quirk application process. /🆑 Co-authored-by: Time-Green <timkoster1@hotmail.com> |
||
|
iwishforducks
|
547177b135 |
Pride pin quirk + pins can be infinitely reskinned (v2) (#72143)
## About The Pull Request Neutral pride pin quirk added. Pride pins can be infinitely reskinned now. Changes "sexuality" to "pride" in description of pin. ## Why It's Good For The Game Pride pins are cute and having to buy them every round is a chore. Pride pins are purely cosmetic and have no reason to be locked into only being reskinned once. ## Changelog 🆑 add: Pride pin quirk! Start the shift off with a pride pin in-hand. qol: Pride pins can be infinitely reskinned now. /🆑 Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
MrMelbert
|
ecde5633bd |
Refactors bar drink icons into datum singletons / unit tests them (#71810)
## About The Pull Request - Refactors bar drink icons. - Juice boxes no longer have a hard-coded list of a bunch of reagent types in their update state, and use a system similar to bar drinks. - Glass and shot glass icon information are no longer stored on the drink. Instead, they are now stored in glass style datums. These datums store name, description, icon, and icon state of a certain container + reagent type. - Glass styles are applied via the `takes_reagent_appearance` component. Glasses, shot glasses, and juice boxes have this component. - This comes with support for being able to have drink icons from different files, rather than requiring the drinks DMI. - The britmug is now a subtype of mug. - 1 new icon: britmug filled. - Various small code clean-up around drink reagents. - Unit tests icon state setups for glass styles as well as all `/drink` reagent container subtypes. - Splits up the massive `drinks.dmi` into separate files. *Disclaimer: Much of the drinking glass datums were written via script automatically, so there may be errors present.* ## Why It's Good For The Game - Much easier to add new drink styles, much more modular. - It is no longer necessary for new drinks to be added to the massive `drinks.dmi`. People working with drinks in the future can simply add their glass style datum and point it to their file wherever it may be. - Expandable system. Adding a new type of reagent container that works similarly to bar drinks but for different types of icons is a breeze. - Ensures going forward no bar drinks have invisible sprites. ## Changelog 🆑 Melbert refactor: Refactored how bar drinks set their icons. Juice boxes now use the same system. /🆑 |
||
|
tralezab
|
86deadc9b1 |
Fixes DNA Infuser's brain swapping, a little bit of qol, ui reworked (#71605)
## About The Pull Request ### Fixes - Right now, the DNA infuser does not gracefully swap brains. With this, it will! - Fixes locked variable not working. **THIS DOES REMOVE BURNT WINGS, AS ORIGINALLY INTENDED** - Infuser now respects moving inside of it as exiting, it was never intended to get you stuck inside - Carp lungs work as intended - Carp jaws work as intended (200 hours of testing btw), via a new helper for changing no_equip_flags - Properly undefs all defines in carp file - fixes some missing args for the brain - infuser logic checks for edible components, not food subtype for GORE check ### QoL - Added a new sound to the DNA infuser - Dragging mobs into the dna infuser will place them as the subject if they're carbon ### UI New UI as well, with some instructions  ## Why It's Good For The Game Bugfix good! ## Changelog 🆑 fix: fixed getting kicked out of your body sometimes when pursuing the carp mutant fix: and carp lungs working incorrectly qol: better ui explanation on the infuser book qol: can drag people into the infuser chamber /🆑 Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
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> |
||
|
lizardqueenlexi
|
e9cc620e9f |
Splits mutant_bodyparts.dmi into several subfiles. (#71408)
## About The Pull Request Splits the `mutant_bodyparts.dmi` file up, as was suggested, but not implemented, in #69302. The following new files were created in the `icons\mob\species` folder, containing the listed sprites: - `lizard\lizard_misc.dmi`: Snouts, horns, frills, and body markings. Anything I didn't feel needed an entire file to itself. - `lizard\lizard_spines.dmi`: Lizard spines, both animated and not. - `lizard\lizard_tails.dmi`: Lizard tails, both animated and not. - `human\cat_features.dmi`: Felinid ears and tails. - `monkey\monkey_tail.dmi`: The monkey tail. - `mush_cap.dmi`: The lone mushperson cap, so easily forgotten. Additionally, I moved `wings.dmi` from `mob\clothing` to `mob\species`. I'm not sure what it was doing there. ## Why It's Good For The Game `mutant_bodyparts.dmi` was something of a mess, with parts from four different species thrown together haphazardly. It probably made sense in earlier days when "mutant humans" were few and far between, but splitting it up makes it more intuitive to find these sprites, and brings it in line with other species - namely, moths. It also means that any future sprites of these types added will not bloat an oversized file even more. Moving the wings file to the species folder just makes sense, because wings are not a type of clothing. ## Changelog 🆑 refactor: Removed mutant_bodyparts.dmi and distributed its sprites in a more sensible and granular manner. /🆑 |
||
|
Zephyr
|
47ba13033f |
JSON Savefiles | Player Saves use JSON (#70492)
<!-- 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> |
||
|
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>
|
||
|
Mothblocks
|
13a1939eee |
Crop moth wings to 32x32, saving about 0.18s in init time (yes really) (#71243)
Crops all moth wings to 32x32 and saves the very expensive Crop cost in the preference icon generation for moth wings. |
||
|
Thunder12345
|
762e9f06cf |
Refactors sound toggle prefs away from legacy toggles, introduces a new sound pref for jukeboxes (#71040)
## About The Pull Request Migrates sound toggle prefs away from legacy toggles, and changes all related preference checks to the modern form. Cleans up unnecessary defines linked to the old prefs. Increments the minimum save file version so a piece of old sound related code can be neatly removed. (The minimum version hasn't changed in two years anyone who hasn't played in at least that long probably doesn't even remember they had prefs saved) Splits off jukebox music into its own preference distinct from instruments. (This was actually the change that brought about this whole PR the rest of the igration just made sense to do at the same time) ## Why It's Good For The Game More granularity in sound preferences is good. It is quite reasonable for players to want to hear normal volume and largely unobtrusive instruments, without also being subjected to the aural torture of the jukebox. As implementing this wothout creating an unwelcome extra legacy toggle already required setting up a non-legacy sound toggle, it is most reasonable to migrate the other sounds at the same time. ## Changelog 🆑 qol: Jukebox music can be controlled by a new seperate preference, and is no longer linked to the instrument sound preference option. refactor: Sound related toggle preferences have been migrated away from the legacy system. Pre-existing preferences should be safely migrated but players are advised to check. /🆑 |
||
|
Tastyfish
|
c0840fc131 |
Adds a game option to toggle the MultiZ parallax effect for a player (#71005)
Adds a game option, similar to Ambient Occlusion, to toggle MultiZ scaling, ie the MultiZ parallax effect, which I'm calling it in the option since that's more clear. I mainly am curious if this is the cause of significant lag on icebox, or if it's just the use of a huge number of planes in general. I don't experience any client lag locally (I'm guessing lemon doesn't either) so **I mainly intend this to be Test Merged** for people to find out if the the actual plane.transform being set is the cause. |
||
|
itseasytosee
|
8e4bc80d92 |
Easy's Super Omega "unarmed strike based species var moved to limbs" refractor, unarmed strike striking with specific body parts rather than it just being flavor, and brain based attacking limb selection extra chunky edition. And also bodypart traits. (#70422)
<!-- 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. --> ## About The Pull Request Ok first if you don't want to read any further explanation you can watch these two videos and you will understand all of the mechanical depth of this change. https://user-images.githubusercontent.com/55666666/194788103-8019dad8-7e44-4cc8-bc8f-0a4f8f00a357.mp4 https://user-images.githubusercontent.com/55666666/194788109-345a3146-fb4b-4a2e-9c2a-e2ee786ba97d.mp4 ### **Disclaimer: Effect on gameplay extremely limited and niche read at your own risk** Starting at the top, regarding the species datum, the vars attack_type, punchdamagelow, punchdamagehigh, punchstunthreshold, attack_verb, attack_effect, attack_sound, and miss_sound have been removed. All bodyparts (not just arms) now have corresponding variables for how they should act if utilized in an unarmed attack. The bodyparts vars are correlated to their corresponding species. All arm type bodyparts have been repathed through a common parent for the purposes of keeping variables consistent. The same is true for the legs. When a carbon begins an unarmed attack, it will check the carbon's brain to see what limb should be used for the attack. If the brain has no answers it will default to the arm that corresponds to the active hand of the attacker. Currently in all brains except monkeys, it check to see if the attackers target target is laying down, and if so, call for a kick with the leg that corresponds with the attackers active hand. If the attacker has no useable legs, or the attacker does not have a corresponding leg to the active hand, or the target is not laying down, the brain will simply default for an attack with the active hand. Monkeys brains (take note the difference between having a monkey brain and being controlled by monkey AI) are the exception, they will simply always choose their heads, and by default an attack with the head is a bite attack. As an example: Previously ethereal would make attacks that used the verb "burn" and did burn damage despite what limbs they possessed. Now anybody with an ethereal limb will make an unarmed attack that does burn damage and has all the same verbs as an ethereal would. And finally, the chunky finger species trait has been moved over to the species arms. Effect on other sources like insuls remains unchanged. <!-- 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 The main motivation is moving direct mechanical elements off of species to, quoting tralezab here, "Make species like a blueprint." Opens more opportunities for coders to add specific elements to limbs, perhaps we could see a buff to unarmed strikes from robot arms, or a species that headbutts people to death. Also undeniably cool, and fixes some weirdness like fully auged ethereals still doing their normal ethereal attack. <!-- 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. --> 🆑 itseasytosee refactor: Elements of unarmed strikes are now limb dependent instead of species dependent. Go rip off an ethereal arm, sew it onto yourself, and burn some people. /🆑 <!-- 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: itseasytosee <noodlenymphftw@gmail.com@gmail.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com> Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> |
||
|
GoldenAlpharex
|
e613c875b7 |
PDA Ringtone Preference (#70485)
* Creates some new defines for constant values in the Messenger app * Created a new type of preference, text preferences, with a FeatureShortTextInput TGUI component * Uses said new preference to re-add a PDA ringtone preference. |
||
|
Gamer025
|
677827e87d |
Expands mob_tags logging (#70259)
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
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 |
||
|
LemonInTheDark
|
72a5b79555 |
Removes overlay queuing, saves 6/7 seconds of initialize. Lightly modifies stat tracking macros (#69696)
* Removes overlay queuing, saves 6/7 seconds of initialize. Lightly modifies stat tracking macros So we have this overlay queuing system right? It's build with the assumption that the "add to overlay list" operation is real expensive, and is thus useful to queue removals or additions. It turns out that it just isn't, at least during init. In my testing the operation of queuing took LONGER then the actual overlay add/remove did. That's ignoring the cost of the subsystem's work. I've also modified part of the stat tracking macro, since it took a good bit of cpu time, and didn't seem to well, do anything. So far as I can tell it always evaluates to 1 |
||
|
Profakos
|
ba0366210e | Sentience preference selection and antag datum (#69569) | ||
|
skylord-a52
|
be0e6efdf6 |
[IDB IGNORE] [MDB IGNORE] Makes the icons/mob folder sane (#69302)
About The Pull Request
Reorganizes the entire icons/mob folder.
Added the following new subfolders:
nonhuman-player (this was initially just called "antag", but then I realized guardians aren't technically antags)
simplemob
silicon
effects (for bloodstains, fire, etc)
simplemob/held-pets (for exactly that -- I wasn't sure if this should go in inhands instead)
species/monkey
Moves the following stuff:
All human parts moved into species, with moth, lizard, monkey, etc parts moved to corresponding subfolders. Previously, there were some moth parts in mob/species/moth, and others just loose in mob. Other species were similar.
icemoon, lavaland, and jungle folders made into subfolders of simplemob
All AI and silicon stuff, as well as Beepsky et al. into the silicon folder, simplemobs into the simplemob folder, aliens into the nonhuman-player folder, etc.
Split up animal_parts.dmi into two bodyparts.dmi which were put in their respective folders (species/alien and species/monkey)
Code changes:
Filepath changes to account for all of this
Adds a check when performing surgery on monkeys and xenos, because we can no longer assume their limbs are in the same file
Turns some hardcoded statues and showcases that were built into maps into objects instead
Things I'd like to do in the future but cant be assed right now:
Remove primarily-antag sprites from simplemob/mob.dmi (Revenant, Morph, etc.) and put them in the nonhuman-player folder
Split up mutant_bodyparts.dmi into different files for Tizirans, Felinids, monkeys, etc and put them in their own folders. Those may have once been meant primarily for mutated humans but that's now how they're being used right now.
|
||
|
LemonInTheDark
|
90eb757265 |
Adds lazyloading to the asset subsystems (#69454)
* Adds lazyloading to the asset subsystems This currently applies only to spritesheets because of how monumentally expensive they are. If an asset is requested it will immediately be fully loaded, but otherwise we slowly load them in with a separate subsystem. This allows us to not hold up initialize with hair stuff. Saves roughly 33% (16 seconds with LOW_MEMORY_MODE) of initialize on my machine My target is something closer to the 9 second init that had back in 2019, this is a good first step. Lets see how much more we can do yeah lads? Co-authored-by: san7890 <the@san7890.com> |
||
|
tralezab
|
97a5746969 |
"What are you in for?" Prisoners can now select their capital offense. (#69446)
New preference, like security department, but for prisoners. They can pick why they're in prison, and they'll get a record about it roundstart.
Classified and Other are for people who want to build their own background, that none of the options currently fit.
Current options:
Abhorrent Criminal Negligence = Incompetently risked numerous lives.
Attempted Development of Cloning = Attempted illegal research in the cloning sphere. Cloning, cloning construction, and cloning-related R&D was outlawed in 2560.
Attempted Murder = Attempted to maliciously kill someone.
Classified = Consult Legal.
Corporate Espionage = Conducted espionage against Nanotrasen for commercial purposes.
Counterfeiting = Engaged in widespread fraud.
Enemy of the Corporation = Acted as or knowingly aided an enemy of Nanotrasen.
Grand Sabotage = Engaged in malicious destructive actions seriously threatening Nanotrasen employees and or infrastructure.
Grand Theft = Stole items of high value or sensitive nature.
Identity Theft of High-Ranking Figure = Impersonated a high-ranking figure.
Murder = Maliciously killed someone.
Mutiny = Attempted to overthrow/subvert Chain of Command.
Other = Consult Legal.
Tampering of Artificial Intelligence = Uploaded malicious negligent or otherwise blacklisted directives to an Artificial Intelligence.
Worship of Blacklisted Deities = Practiced worship of blacklisted deities.
|
||
|
tattle
|
d91390a447 |
[IDB IGNORE] The Great Sweep: Moving dmis into subfolders (part 1) (#69416)
Moves singulo and supermatter dmis into obj/engine, renamed from obj/tesla_engine Moves Halloween, Christmas, and misc holiday items to obj/holiday Moves lollipops to obj/food Moves crates, closets, and storage to obj/storage Moves assemblies to obj/assemblies Renames decals.dmi to signs.dmi ...because they're signs and not decals Moves statues, cutouts, instruments, art supplies, and crayons to obj/art Moves balloons, plushes, toys, cards, dice, the hourglass, and TCG to obj/toys Moves guns, swords, shields to obj/weapons |
||
|
Kapu1178
|
dcd84e1bdc |
It's 2 am and im having a manic episode so i fixed hair (#69092)
* 2 am coding * lazylists like this are stupid * reviews |
||
|
Seth Scherer
|
caef4900b5 | Removes the Families gamemode (#68480) | ||
|
san7890
|
9c3f9101cb |
Adds Preferences To Suppress Ghost Role Rolls (#68102)
Hey there, Ever since November of 2021, I've wanted something where I could simply not get any ghost roles while adminned. Some people also do not want to get any ghost rolls whatsoever when they play, for it is their personal preference. This PR seeks to resolve both of these issues with two new preferences. The first preference will show up to everyone, Suppress All Ghost Rolls. It will return on the main proc that pops up the window, does the sound, all that. You will not hear a peep of a word out of your game. This is dangerous if you like playing as ghost roles, but if you abhor the thought of it... it's just for you. The second preference is for admins. You can selectively suppress ghost roles while adminned. This is useful because when you're running an event or doing stuff where you need to offer multiple ghost roles (or you need to focus on a ticket and someone is spamming Xenobiology mob spawns), this is absolutely perfect for suppressing. Same return as the player option, but it checks to see if you are currently adminned via the client.holder variable. This is just because some admins (i'm some admins) don't want to turn in on just in case they forget to turn it off down the line because they actually play the game (lying). There's probably a much cleaner way to do this code-wise, but I couldn't figure it out. Any help is appreciated. I tested it extensively on my local (even using a guest account), and everything seems to work rather nicely after about an hour of trial-and-error. Why It's Good For The Game Players who want to just alt-tab or maybe chill in deadchat (or have an extreme loathing of ghost roles) can just simply not get any of that. Admins who want to focus on tickets and not have windows pop up to interfere in good administrative work (and be the most annoying thing in the world) can also do that. Everyone is happy. Changelog cl qol: There is now a new preference in Game Preferences, Suppress All Ghost Rolls. If you tick this preference, you will not get a singular window pop-up whenever a Ghost Role is available. Intended for the few who really do need it. admin: Admins get another additional preference where Suppress All Ghost Roles only works while they are currently in an adminned state. They will still get ghost rolls normally when they are in a deadminned state. /cl |
||
|
Jeremiah
|
acfa5e4fdd |
TGUI Say: Upgrades chat input with modern features (#67116)
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> Co-authored-by: AnturK <AnturK@users.noreply.github.com> Co-authored-by: iamgoofball <iamgoofball@gmail.com> Co-authored-by: Aleksej Komarov <stylemistake@gmail.com> Co-authored-by: KubeRoot <6917698+KubeRoot@users.noreply.github.com> Co-authored-by: Kapu1178 <75460809+Kapu1178@users.noreply.github.com> Co-authored-by: Iamgoofball <4081722+Iamgoofball@users.noreply.github.com> Co-authored-by: DomitiusKnack <56321744+DomitiusKnack@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: Wallem <66052067+Wallemations@users.noreply.github.com> |
||
|
Mothblocks
|
7cab049dd1 |
Screenshot tests (#67679)
Adds screenshot visual testing workflow and scripts. |
||
|
Kapu1178
|
6d470992cb |
This tail refactor turned into an organ refactor. Funny how that works. (#67017)
* Fuck you (refactors ur tails) * Errors * Wow. Pain. * Fixes up probably everything * finish up here * Fixes hard del maybe * original owner hard del * garbage collection runtime * suck my peen byond * Mapped tails * motherfucker. * motherrfucker. again. * Whooopppppsie * yeah bad idea * Turns out external organs literally just sat in nullspace forever if their parent was deleted, and didnt Remove() themselves, causing harddels. * So anyways I repathed all organs * Fixes * really. * unit test... test * unit test-test but it passes linters this time because im a moh-ron * I've lost track of what im doing at this point * Hopefully fixes hard del? * meh * Update code/datums/dna.dm * things n stuff * repath from master pull |
||
|
SmArtKar
|
45b19cd314 |
Fixes most eye color effects not working (#67127)
* Fixes most eye color effects not working, adds eye refreshing to species' handle_body. |
||
|
Zephyr
|
87d2703af4 |
Splits eye color into two vars | Heterochromia Quirk (#66164)
* refactor it back to a single organ but with different eye vars * nOt In A LoOp * forgot emissive overlay * remove old obscured var * quirk * fine we do it like this, PAIN * add applying_preference paramter to is_accessible and check for it when applying * update dummy on quirk change * client might not exist if we are applying the preference, because unit tests * unique icon * lazy webedit review * revert is_accessible refactor * mild stupid * change the way heterochromia is applied * better handling * Apply suggestions from code review * add apply to human behaviour * hopefully fix that which the merge hooks broke * Update code/datums/quirks/neutral.dm * Web commit for shame * Update code/datums/quirks/neutral.dm * Update code/datums/quirks/neutral.dm Co-authored-by: Ryll Ryll <3589655+Ryll-Ryll@users.noreply.github.com> * Update basic.dm Co-authored-by: Ryll Ryll <3589655+Ryll-Ryll@users.noreply.github.com> |
||
|
Kyle Spier-Swenson
|
565319095f |
Adds MC initialization stages. Earlier stages can fire while later ones init. Fixes tgui chat reconnection banner showing during init. (#66473)
* Adds MC initialization stages. Earlier stages can fire while later ones init. Removes TICK_LIMIT_MC_INIT config for barely doing anything to speed up init and being inconvenient to work with if fires and inits can happen at the same time. |
||
|
magatsuchi
|
cd1b891d79 |
Modular Tablets: Converting PDAs to the NtOS System (#65755)
Converts PDA functions and applications over to modular tablets and devices, namely the messaging function. HREF data code is quite honestly clunky and difficult to work with, as I've definitely experienced whilst working on this. By moving from this system over the easier to read (and frankly, easier to add to) TGUI system, you get cleaner looking and more user friendly UIs and a greater degree of standardization amongst other UIs. Co-authored-by: Seth Scherer <supernovaa41@gmx.com> Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com> Co-authored-by: Aleksej Komarov <stylemistake@gmail.com> |
||
|
Kapu1178
|
3f2e753115 | Fixes some Kapulimbs bugs (#65923) | ||
|
Kapu1178
|
1d0eadcb12 |
Kapulimbs (#65523)
* 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 |
||
|
LemonInTheDark
|
50689f89a4 |
Action button refactor/rework: Enhanced Dragging (#65180)
About The Pull Request
I noticed a lot of strange and un-intuitive behavior in action buttons, and got stung by the bloat bug. Damn it hug #58027
I'll do my best to explain what I've changed and why, might get a bit long.
If you want a better idea, read the commits. Most of em are pretty solid, if long.
Whelp. Here we go.
How do action buttons currently work
All action buttons are draggable, to any place on the screen. They're held in an actions list on the player's mob.
Their location in this list determines their position on the top of the screen. If one is dragged away from the top, its position in the list is "saved". This looks really bad.
If two buttons are dragged over each other, their positions swap. (inside the actions list too)
If a button is shift clicked, it is brought back to the position it started at.
If the action collapse button that you likely just mentally edit out is alt clicked, it resets the position of all action buttons on the screen.
If an action is ctrl clicked, it is "locked". This prevents any future position changes, and also enables a saving feature. With this saving feature, locked button positions persist between rounds. So your first o2 canister will always start where you saved it, etc.
Actions and buttons are a one to one link. While there is functionality to share action buttons between two players, this means showing the same object to both. So one player can move a button on another's screen. Horrendous.
This also makes code that modifies properties of the screen object itself very clunky.
Why is this bad
A: None knew pretty much any of this information. It is actually documented, just in a horribly formatted screen tip on the collapse button, you know the one we all mentally delete from the hud.
B: None of this is intuitive. Dragging buttons makes the hud look much worse, and you get no feedback that you even can drag them. Depressing
C: We use actions to make new options clear to the player. This means players can have a lot of action buttons on the hud. This gets cluttery
D: The collapse button is useless. It lets you clear your screen if someone like me fucks up and gives you 2000 actions, but outside of that it just hides all information from you. You never want to see none of your action buttons, just a filtered list of them.
E: On a technical level, they're quite messy, and not fully functionally complete. This is depressing.
What I've done
Assuming the above to be true, how do we fix them?
Well first I'm going to go over everything I changed, including links to major commits. I'll then describe the finished product, and why I made the decisions I did.
Oh and I've moved some of the more niche or technical discussion to dropdowns. Hopefully this makes finding the major functional changes easier
Adds helper procs for turning screen_loc strings into more manageable arrays. This doesn't fully support all of the screen_loc spec, but it's enough for what I'm doing. (f54865f)
Uses these helper procs to improve existing code (6273b93)
Fixes an issue with tooltip code itself. If you tried to hold down a mouse button while dragging onto a tooltip enabled object, it would silently fail. The js made assumptions about the order args came in, which broke when buttons were held down (
|
