mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-20 20:45:28 +01:00
privacy-policy-sql
18 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 SmArtKar
|
5f3c85eee0 | Unifies mob, megafauna and boss crusher loot and achievements (#93068) | ||
|
Jacquerel
|
e3dee6810e | Most hostile mobs can no longer be trapped by closets, chairs, and aggro grabs (#91652) | ||
|
Bloop
|
cb51a652a9 |
Adds automatic GAGS icon generation for mapping and the loadout menu (#90940)
## About The Pull Request Revival of https://github.com/tgstation/tgstation/pull/86482, which is even more doable now that we have rustg iconforge generation. What this PR does: - Sets up every single GAGS icon in the game to have their own preview icon autogenerated during compile. This is configurable to not run during live. The icons are created in `icons/map_icons/..` - This also has the side effect of providing accurate GAGS icons for things like the loadout menu. No more having to create your own previews.  <details><summary>Mappers rejoice!</summary>   </details> <details><summary>Uses iconforge so it does not take up much time during init</summary>  </details> --- ### Copied from https://github.com/tgstation/tgstation/pull/86482 as this still applies: Note for Spriters: After you've assigned the correct values to vars, you must run the game through init on your local machine and commit the changes to the map icon dmi files. Unit tests should catch all cases of forgetting to assign the correct vars, or not running through init. Note for Server Operators: In order to not generate these icons on live I've added a new config entry which should be disabled on live called GENERATE_ASSETS_IN_INIT in the config.txt ## Why It's Good For The Game No more error icons in SDMM and loadout. ## Changelog 🆑 refactor: preview icons for greyscale items are now automatically generated, meaning you can see GAGS as they actually appear ingame while mapping or viewing the loadout menu. /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
Jacquerel
|
d19b8de989 |
Most fleshy mobs are vulnerable to stamina and stuns (#90675)
## About The Pull Request This PR enables most mobs to take stamina damage, become slowed as a result of taking stamina damage. It also gives most mobs CANSTUN which not only allows them to enter stamcrit from taking stamina damage but also makes them vulnerable to mechanics like stun batons. Mobs which already took stamina damage (Spiders and Space Dragons) still work the same way. Mechanical or artificial mobs, mining mobs, simple xenomorphs, ghosts, and most kinds of mob closely associated with antagonists still don't take stamina damage. ## Why It's Good For The Game A new player armed with a disabler will probably try and use it on aggressive animals and be disappointed, but I don't think there is any _reason_ for them to be disappointed when it's already something they are doing merely to delay being attacked rather than to kill the target. It's not intuitive for these mechanics not to function against simple mobs when they do against humans, _especially_ the kinds of mobs which look like humans, and there isn't any technical reason why it _couldn't_ work against most mobs which it looks like they should work against. While this reduces the threat level of some mobs against Security players I think the greater interaction with the sandbox is beneficial. I'm hopeful it doesn't have that much effect on many of the most common places you encounter dangerous mobs like Space Ruins or Gateways as they are also places where you can't reliably recharge your energy-based stamina weapons as most that don't require energy do require getting into melee and endangering yourself. ## Changelog 🆑 balance: Most biological mobs are now slowed by taking stamina damage, and can be stunned. Mechanical mobs, mining mobs, and several other special kinds (chiefly those invoked by antagonists) are unaffected. If this seems to effect any mob it probably shouldn't, please report it as a bug. /🆑 |
||
|
grungussuss
|
58501dce77 |
Reorganizes the sound folder (#86726)
## About The Pull Request <details> - renamed ai folder to announcer -- announcer -- - moved vox_fem to announcer - moved approachingTG to announcer - separated the ambience folder into ambience and instrumental -- ambience -- - created holy folder moved all related sounds there - created engineering folder and moved all related sounds there - created security folder and moved ambidet there - created general folder and moved ambigen there - created icemoon folder and moved all icebox-related ambience there - created medical folder and moved all medbay-related ambi there - created ruin folder and moves all ruins ambi there - created beach folder and moved seag and shore there - created lavaland folder and moved related ambi there - created aurora_caelus folder and placed its ambi there - created misc folder and moved the rest of the files that don't have a specific category into it -- instrumental -- - moved traitor folder here - created lobby_music folder and placed our songs there (title0 not used anywhere? - server-side modification?) -- items -- - moved secdeath to hailer - moved surgery to handling -- effects -- - moved chemistry into effects - moved hallucinations into effects - moved health into effects - moved magic into effects -- vehicles -- - moved mecha into vehicles created mobs folder -- mobs -- - moved creatures folder into mobs - moved voice into mobs renamed creatures to non-humanoids renamed voice to humanoids -- non-humanoids-- created cyborg folder created hiss folder moved harmalarm.ogg to cyborg -- humanoids -- -- misc -- moved ghostwhisper to misc moved insane_low_laugh to misc I give up trying to document this. </details> - [X] ambience - [x] announcer - [x] effects - [X] instrumental - [x] items - [x] machines - [x] misc - [X] mobs - [X] runtime - [X] vehicles - [ ] attributions ## Why It's Good For The Game This folder is so disorganized that it's vomit inducing, will make it easier to find and add new sounds, providng a minor structure to the sound folder. ## Changelog 🆑 grungussuss refactor: the sound folder in the source code has been reorganized, please report any oddities with sounds playing or not playing server: lobby music has been repathed to sound/music/lobby_music /🆑 |
||
|
LemonInTheDark
|
1e78db8471 | Refactors how basic ais do their success/failures (#82643) | ||
|
MrMelbert
|
47dc38fee2 |
Let's you talk through action figures, plushies, and toy mechs with .l and .r. Also a big clean up of say because its support for non-mobs was lackluster. (#81848)
|
||
|
jimmyl
|
fbe6e2ebba |
museum away mission (#81208)
## About The Pull Request adds a new gateway map, the Nanotrasen Museum it is filled with """"Mannequins"""" and Common Core lore im not putting the preview here because you really should explore it yourself but if youre that curious i think the Checks tab in mapdiffbot would have it this gateway map contains no combat unless you count falling into chasms because you did not carry a light or going into the boarded room with no loot or any incentive with obvious signs that there is the sole enemy on the map in there the loot is the lore ok thanks also makes mines detonate if theyre detonated by a non-mob im pretty sure this couldnt have been intentional trams stop chasms and also the relevant items <details> <summary>on second thought if you want spoilers check this</summary>  </details> ## Why It's Good For The Game more gateway maps = good ## Changelog 🆑 add: nanotrasen museum gateway map /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
Ben10Omintrix
|
566c353d63 |
fix a hard delete in basic statues (#80696)
## About The Pull Request if the creator of the statue got deleted, it might cause a hard delete. also i noticed this variable wasnt being used so i removed it and instead directly added the ref of the creator to the mob's faction list. also i noticed the proc that was setting it had alot of nested typechecks so i split it into child procs ## Why It's Good For The Game fixes a hard delete ## Changelog not player facing |
||
|
LemonInTheDark
|
9696dd1a1d |
Targeting Datums Renamed (and global) (#79513)
## About The Pull Request [Implements the backend required to make targeting datums global](https://github.com/tgstation/tgstation/commit/6901ead12e419530b7f646ea21094d4432d7385e) It's inconsistent with the rest of basic ai for these to have a high degree of state, plus like, such a waste yaknow? [Implements GET_TARGETING_STRATEGY](https://github.com/tgstation/tgstation/commit/d79c29134d03424a9f8bacd64c08cb41775fe8c0) Regexes used: new.*(/datum/targetting_datum[^,(]*)\(*\)* -> GET_TARGETING_STRATEGY($1) Renamed all instances of targetting to targeting (also targetting datum -> targeting strategy) I've used GET_TARGETING_STRATEGY at the source where the keys are actually used, rather then in the listing. This works out just fine. ## Why It's Good For The Game Not a misspelled name through the whole codebase, very slightly less memory load for basically no downside (slight cpu cost maybe but not a significant one. --------- Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> |
||
|
san7890
|
e03822fe1d |
Standardizes Adding Datum Actions into a proc/define (Bonus AI Support) (Bonus Useless Code Cleanup) (#79389)
## About The Pull Request The way we add multiple actions has been very unstandardized, with several implementations of this code doing certain things wrongly (i.e. not nullchecking `ai_controller`), so let's do something in the vein of #74037 and just make one nice big ol' proc that catches a lot of these cases. There are still a few things that simply can't be done here, but this gets the most generic "give my mob some actions and also maybe tell the AI about it" stuff done. This is only useful in cases where we don't ever need to reference the ability ever again when it's added. In an ideal world we would never need to reference the ability again and it would all be self-contained, but this is not an ideal world. However, a lot of the latticework has been built around certain implementations of this behavior making refactoring it just a bit easier. I also did a lot of auditing on `Destroy()` stuff, because `/datum/action`s listen to signals when their parent is `qdel`ing, so we don't need to neither hold nor clear references on our mob's `Destroy()`. This was all cleaned up now because even if we couldn't use `grant_multiple_actions()` (the new proc I add in this PR), it's just not useful at all and will further hinder efforts to implement this new proc. Also also, I noticed in some places (such as megafauna) that we were initializing a lot of datum actions _in nullspace_. We didn't pass the `src` argument to `New()`. I quickly fixed that, as well as got rid of the useless types we had going on. Also also also, I added a define macro to handle some of the cases that melbert was speaking about in his review down below. All you need to do is invoke the define on the typepath, and you should be good to go from there. There's probably a better way to do it, lmk though. we do the whole `do while` thing in order to prevent code leakages. ## Why It's Good For The Game * Very easy to change the implementation. In case we need to do something different in how we add actions or anything like that, we can simply just edit instances where this proc is located. * Standardizes addition behavior. There's a lot of cases like the aforementioned not-null-checking `ai_controller` that we really need to look out for, so having it all in one accessible proc ensures standard behavior. * Reduces copy-pasta. A lot of mobs had their own individual implementation of this, so let's just clean up all those lines of code. ## Changelog 🆑 refactor: The way mobs get specialized actions (like revenants shocking lights or regal rats summoning rats to their side when you slap them) have been modified, please report any bugs. /🆑 This doesn't touch the following case FTR: * Instances where we need to do work on the `/datum/action` after we `Grant()` it, like if we were to edit some variable on the action or if we need to call procs on said action. I don't like how the current code is so reliant on storing a variable to it, but that's a windmill to attack another time. |
||
|
Profakos
|
c3446fa542 |
Frosty's factions are now defines (#78792)
## About The Pull Request Saw that Frosty the Snowman's factions were strings instead of defines, so I have made them use defines. ## Why It's Good For The Game Defines are much safer and cleaner than using strings. ## Changelog Nothing player facing |
||
|
Jacquerel
|
257923e090 |
Synchronise AI and Player basic mob melee behaviours (#78337)
## About The Pull Request I like for things that mobs do to be consistent regardless of whether they are controlled by a player or by the AI. One big offender of this is the melee behaviour cooldown. Basic mobs piloted by AI have arbitrary melee attack cooldowns which are not reflected when they are controlled by players who can generally attack much faster (but in _two_ instances, slower). To remedy this I added `melee_attack_cooldown` as a var on `living/basic` (sinful) and the ai now uses NextMove to not click too often, meaning that players can only bite things as often as the AI can and also that if you VV the cooldown it can speed the AI up (or slow it down) as well as a player. This also gets rid of a lot of subtypes of that datum, as we mostly made them to change the cooldown. I also hunted down a few places where there was behaviour placed inside an AI behaviour which wasn't easily replicable by a player piloting the same mob, preferably a player should be able to do everything that the AI can. Fixing this was largely a simple case of moving code from `ai_behaviour/melee_attack/perform` to `basic/mob_subtype/melee_attack` and also adding an element for one thing shared by three different mobs. Strictly speaking I didn't need the element that much because a player is perfectly capable of clicking on something they attack to drag it, but it's nice for it to be automatic? ## Why It's Good For The Game If you see a mob do something then you should also be able to do it. Mobs shouldn't have significantly different capabilities when controlled by a player (aside from usually being smarter). ## Changelog 🆑 balance: Player-controlled basic mobs attack as fast as those mobs can when controlled by the AI balance: Player-controlled Faithless can paralyse people they attack, like the AI does balance: Player-controlled Star Gazers (if an admin felt like making one) apply the star mark on attack and deal damage to everything around them, like the AI does /🆑 |
||
|
Ghom
|
6f862d107f |
Adds a unit test to stop elements from using identical lists for their arguments. (#76322)
## About The Pull Request Ok, so a few days ago I made an issue report about multiple instances of identical elements being generated because of uncached lists. ninjanomnom (the mind being the element datums) cleared it up and said an implementation of GetIdFromArguments() that also checks the list contents wouldn't be worth the performance cost, while adding that a unit test should be written to check that it doesn't happen at least during init, which should catch a good chunk of cases. Also, i'm stopping RemoveElement() from initializing new elements whenever a cached element is not found. Ideally, there should be a focus only unit test for that too, but that's something we should tackle on a different PR. Some of the code comments may be a tad inaccurate, as much as I'd like to blame drowsiness for it. Regardless, the unit test takes less than 0.2 seconds to complete on my potato so it's fairly lite. ## Why It's Good For The Game This will close #76279. ## Changelog No player-facing change to be logged. |
||
|
Profakos
|
50b37c8c7f |
Faction defines (#73681)
## About The Pull Request Quite a lot of mobs had faction defines as a string, which always has a chance for error. For example, the clown mob spawner had their faction written as "clown", when the official faction name was "clowns", and a define existed for it anyways! This PR moves every single string based factions over here. No references or special role factions. Hopefully I didn't miss anything. I also moved a global define used for picking your uplink provider's flavour to the only file that used it, datum_traitor.dm, and renamed them a bit to avoid confusion. I have also noticed that the mimic faction was assigned to the petrified player with += instead of |=. |= would ensure no duplicate factions, so I have changed it. Future improvement: I have noticed that there is a lot of bloat with factions that contain only one or two entries (examples: gnomes, floating eyeballs, penguins, the pet lizards), and some always appear in pairs (vines and plants, the rare exceptions being killer tomatoes and strange reagent spawned pine trees), but trimming consolidating them is a matter for a different time. ## Why It's Good For The Game Makes assigning factions a bit less error prone. I can finally remove the ```/// Later all mob factions will be moved here and their current factions replaced with faction defines.``` comment. Later is NOW. ## Changelog Nothing player facing |
||
|
Jacquerel
|
705f7a419c |
Refactor Statue & Creature unobserved behaviour (#73630)
## About The Pull Request While I was touching the Creature file for another PR (#73629) I noticed that an identical proc was implemented here and on Statue. I moved it into a component and managed to hook it into signals which have return flags. This required a bit of a refactor of their abilities too, but that was for the best because one of them had a reimplementation of Jaunt which could have just been a subtype of Jaunt, and none of their abilities had icons. I also made `spell` send `COMSIG_MOB_ABILITY_STARTED` in `PreActivate` because it completely overrides the parent and doesn't do that as a result. ## Why It's Good For The Game I'll be honest this is mostly because I was looking at the code and didn't like it, I don't think there were any bugs related to this but it does reduce chat spam a little bit? It should make this behaviour more maintainable and useful in the future, as we're not copying and pasting multiple procs between different files (for both this behaviour and jaunting). ## Changelog 🆑 refactor: The actions of Statues and Creatures which can't be used while seen now share logic, and will not spam chat with feedback. /🆑 |
||
|
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. /🆑 |
||
|
Comxy
|
7e41cd3c0b |
Netherworld Mobs Refractor (#73086)
## About The Pull Request This PR refactors netherworld mobs into basic mobs as best as possible. Also makes some of them run faster when they are getting damaged or deal more damage. Now the mobs might be able to keep up a little with the players. ## Why It's Good For The Game Makes the mobs have better movement and more dynamic movement. Makes the quality of these mobs better. ## Changelog 🆑 add: Added new damage buffs for netherworld mobs refactor: Refactors netherworld mobs into basic mobs /🆑 |
