mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-06-13 10:14:15 +01:00
ed94de4ddf7edad8694badefc577392e0f762bf5
21 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
9904335a37 |
Mobs can die loudly again (#76580)
## About The Pull Request Mobs would never emote or make sounds upon death because they set themselves to "dead" before trying to run the emote and the emote can't run while you are dead. Also basic mobs didn't have the "it's dead" examine text, and should. ## Why It's Good For The Game It's good for mobs to tell you when they have died. Multiple basic mobs were implemented with this feature and apparently never tested? Maybe we just broke it recently. ## Changelog 🆑 fix: Mobs can once again emote (with sound) when they die. fix: Basic mobs will tell you whether they are alive if you examine them. /🆑 |
||
|
|
4c48966ff8 |
Renames delta time to be a more obvious name (#74654)
This tracks the seconds per tick of a subsystem, however note that it is not completely accurate, as subsystems can be delayed, however it's useful to have this number as a multiplier or ratio, so that if in future someone changes the subsystem wait time code correctly adjusts how fast it applies effects regexes used git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i 's/DT_PROB/SPT_PROB/g' git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i 's/delta_time/seconds_per_tick/g' |
||
|
|
b7da743e7d |
[no GBP] Corrects the speed at which spiders stop being on fire (#73601)
## About The Pull Request As noted in #73584 spiders stopped being on fire faster when they were simple mobs than they do now, and I have restored this behaviour. While I was there I noticed that spiders were the only simple mobs which could catch fire so I just remove that behaviour. I also changed the boolean "flammable" into a flag, not sure if that's actually better but maybe it is? I tried a little to see if I could make this into a component but there's basically no way as all of this behaviour is inside a status effect. ## Why It's Good For The Game Restores original behaviour. Maybe in the future I'll (or someone else will) use this to make some other basic mobs able to be set on fire, no obvious reason they shouldn't be able to be. ## Changelog 🆑 fix: Spiders will stop being on fire marginally faster, as they used to. /🆑 |
||
|
|
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. /🆑 |
||
|
|
7c30d9d746 |
Basic Wumborian Fugu & Fugu Gland (#73415)
## About The Pull Request Fixes #72677 and also converted the "Wumborian Fugu" mob to a basic mob rather than a simple one. I will be totally honest: I didn't need to do that in order to fix the bug. I just didn't like looking at the rest of the code in that file. Also I have some kind of sickness which makes me do this. This ended up being one of those "see something related and fix it as well" ones so there's a couple of only tangentially related changes in here. If you want me to split it up I will but I think this one is _probably_ fine because the wide-ranging changes are pretty simple ones? So what this PR does is: - Refactors simple mob into basic mob. - Cleans up its really ugly ability to work in a hopefully nicer way. - A one line fix to the linked issue above. - Modifies the default cooldown on `basic_melee_attack` and `attack_obstructions` to be a widely used cooldown rather than a random value used by no mob that we have. - Renamed behaviour "try_mob_ability" to "targeted_mob_ability" and added a new AI behaviour called "use_mob_ability", the difference between the two being that the former requires a target and the latter does not. I... don't actually use this because I realised after adding it that I still want a target for this mob, but someone will need it eventually. - Change everywhere that is passing references to abilities to actions to pass weak references instead. - Adds an element to handle "spawn this stuff when a related mob dies". - Found a few places where people were setting `environment_smash ` as if it did anything (including me) and replaced them with the proper ai_controller implementation instead, updated the comment to make it clearer although that won't prevent copy/paste errors. - Registered to the "movement speed updated" signal to ensure that basic mobs actually notice that you have applied a movement speed modifier. ## Why It's Good For The Game Fixes a linked issue. Refactors some code which made me sad whenever I saw it. Restores some mob behaviour which nobody noticed was missing, but was. Fixes some apparently unreliable code I added in a recent PR reliant on basic mobs using movespeed modifiers. Adds element we will definitely need again in the future. ## Changelog 🆑 fix: The Fugu Gland can once more be used on Ian, Carp, Giant Spiders, or other basic mobs. fix: Syndicate mobs will once again attack windows to try to reach you, and space ruin spiders won't. fix: Netherworld-themed mobs will correctly adjust their speed as they take damage. refactor: Made the Wumborian Fugu into a basic mob, which should act largely the same way but may have slightly different speed and reaction times. /🆑 |
||
|
|
a99c163d7b |
Mice and Regal Rats won't spawn in the icebox solar panels (#73388)
## About The Pull Request Fixes #73238 This adds a temperature check to the turf locator in the mice migration event. Also it refactors the check a bit because its loop seemed... odd? If there was some reason the old version was more efficient let me know but I can't see a purpose to do it that way around. Also then the same numbers were being used in 3 separate files so I moved it into a define. _Finally_ I removed a redundant element from the cockroach while I was looking at the files. There was a moment when I started looking at this where I thought "I should add a generic helper proc which is given a turf and a mob and can tell you if it would die if it spawned on that turf". Then I looked at lungs and immediately decided that was going to be a massive amount of work for this trivial bug fix... maybe one day. ## Why It's Good For The Game This was sparing mappers from the punishment whoever added this feature surely intended for them to suffer. Also it's just a bit sad to notify ghosts to join a ghost role which will die instantly 😢 ## Changelog 🆑 fix: Mice and Regal Rats will no longer spawn in icebox's solar panels and die of cold. /🆑 |
||
|
|
cbbf7b3613 |
Basic Mob Spiders III: Sgt. Araneus is no longer a bat (#73350)
## About The Pull Request This PR converts giant spiders into basic mobs and resultingly fixes #37793 They _should_ have the same behaviour as their simple mob versions although I can't verify that their movement speeds are _exactly_ the same. It should at least be pretty close. A quirk of spiders is that they had a pretty large `move_to_delay` which made them slow in the hands of AI (because it would just pause for ages between taking steps) and faster in the hands of players, and they often appear in both forms so I had to implement this as a speed modifier based on player control. Additionally this is the first basic mob which can be set on fire. This is currently implemented as a var on `mob/living/basic` but I know there was some annoyance at adding the environment tolerances as vars on there so if desired I can try and extract it out, I'm just not sure how easy it will be. Something else I noticed is that spiders seem to take stamina damage from bug spray... but stamina damage does nothing to either simple _or_ basic mobs. I have left it in for now in case I am missing something, and rebalancing it to do something else would be more like a balance change. Oh also I killed the `mob/basic/retaliate` folder because that isn't a classification that needs to exist or makes sense. ## Why It's Good For The Game We don't want to use simple mobs any more. Sergeant Araneus can finally actually be a spider, instead of being a bat. ## Changelog 🆑 refactor: Spider code has been refactored and AI-controlled spiders may have slightly different movement or reaction times. fix: Basic mobs can now be slowed when they take stamina damage, however currently only spiders actually _can_ take stamina damage. fix: Spiders should now more reliably disable their AI when controlled by a player. fix: Araneus is no longer considered to be a bat and so cannot fly. fix: Araneus is no longer considered to be a bat and so is no longer frightening to people who are scared of the supernatural. /🆑 |
||
|
|
66cb9133c4 |
Dominate & Lazarus Inject basic mobs. Lazarus Injected mobs don't fight each other. (#72440)
## About The Pull Request Fixes #72404 The Lazarus Injector doesn't currently work on basic mobs, but should. Problem: The EMPed state of the Lazarus Injector is intended to make a revived mob hostile to everyone except you, including other mobs you have revived wtih an EMPed Lazarus Injector. This is trivial to achieve for Simple Mobs which essentially all share the same AI, but I could not think of a single workable solution for Basic Mobs which don't, or at least any which didn't come with a tedious requirement to closely consider this niche item when programming any additional AI. Solution: Change the default behaviour of the Lazarus Injector so this is not a problem. If all it does it make the mob loyal to you _and_ friendly to other mobs which are loyal to you, then it's pretty easy because we can just use the existing faction flags. This is unambiguously a buff to using the item for nefarious purposes as now if you revive four ice drakes and fulton them onto the station they won't kill each other until only one is left, but is the only workable solution I could really think of. A lot of the very dangerous mining fauna can't be dragged so transporting your army to the station still poses a question. The alternate solution was just to replace the AI controller of any emp-revived basic mob with a "zombie" AI controller, but this has the problem that A- It would now make things like cows and dogs into hostile creatures when they previously weren't. B- It loses any interesting behaviour the mob previously had and for cases like Bileworms doesn't even make any sense (they'd try to walk and just get stuck in place). This ultimately leads to needing to make bespoke versions for various mobs, which doesn't seem desirable from a maintainability standpoint. As a side note it's still not a great idea to revive Bileworms _anyway_ as, their ability to move is tied to their ability to attack so once they don't have a target they will just kind of sit there and if they _do_ get a target their attempts to help you fight are difficult to distinguish from attempts to kill you... but at least being able to revive them makes it easier to make one sapient if you really want to trap a player's mind inside a body which is incapable of leaving lavaland. Additional edit: At Fikou's suggestion I've also added a sentience comparison proc to `mob/living` and removed some code duplication which dealt with this problem in the sentience/mind transfer potions, as well as added it to the Dominate spell. ## Why It's Good For The Game This device is meant to revive mobs and it shouldn't be required for players to memorise an arbitrary list of which mobs it does and doesn't work on. Especially as the goal is eventually that all simple mobs should be basic mobs. This way of working is more intuitive, even if it is also stronger. I was surprised when I used EMPed injectors and my "new minions" just killed each other. ## Changelog 🆑 fix: You can now revive 'basic mobs' with a Lazarus Injector, such as dogs, cows, axolotls, or carp. fix: The same category of mobs can also now be effected by the Runic Golem Dominate spell. fix: Basic Mobs will switch target if they can no longer attack their current target; meaning that if you become a Bileworm's friend it will stop attacking you. balance: Mobs injected with the Lazarus Injector while it is EMPed will no longer attack other mobs revived by EMPed Lazarus Injectors. /🆑 |
||
|
|
d650a1a7cb |
Basic mobs don't become dense upon death (#72554)
## About The Pull Request In #72260 what was previously a var became a flag, which was a sensible change, however this inverted the default behaviour. In virtually all cases we want dead mobs to _stop_ being dense, this added a requirement for the flag to be present for that to happen and then didn't add the flag to any mobs. Rather than add this to every mob I inverted the function of the flag. My reasoning here is that _simple_ mobs seemingly never required this behaviour, basic mobs are probably going to need it rarely if ever, and including it in `basic_mob_flags` by default seems messy and easy to leave off when setting other flags (plus #72524 implies to me we want to avoid adding more default values). Setting this manually on each mob seems kind of silly as a requirement going forward and I can't think of a way we'd unit test for people forgetting. For the same reason I did the same thing with the `STOP_ACTING_WHILE_DEAD` flag I added to the AI controller in a recent PR, the flag should denote unusual behaviour not the default. ## Why It's Good For The Game It looks really odd when you're constantly shuffling places with dead mobs, they're not supposed to do that. It's tedious to add `STOP_ACTING_WHILE_DEAD` to every AI controller when that should be an obvious default assumption. ## Changelog 🆑 fix: Dead basic mobs are no longer "dense" objects and can be stepped on. /🆑 |
||
|
|
eb6c0eb37c |
Dogs use the Pet Command system (#72045)
About The Pull Request Chiefly this refactors dogs to use the newer component/datum system for "pet which follows instructions". It also refactors it a little bit because I had better ideas while working on this than I had last week. Specifically, instead of passing around keys we just stick a weakref to our currently active behaviour in the blackboard. Basically the same but skipping an unecessary step. Additionally it adds a component for the previous "befriending a mob by clicking it repeatedly" behaviour which hopefully we won't use too much because it's not very exciting (I am planning on replacing it for dogs some time after Christmas). The biggest effort in here was making the Fetch command more generic, which includes multiple behaviours (which might be used on their own?) and another component (for holding an item without hands). Additionally I noticed that dogs would keep following my instructions after they died. This seems unideal, and would be unideal for virtually any AI controller, so I added it as an AI_flag just in case there's some circumstance where you do want to process AI on a dead mob. Finally this should replicate all behaviour Ian already had plus "follow" (from rats) and a new bonus easter egg reaction, however I noticed that the fetch command is supposed to have Ian eat any food that you try to get him to fetch. This has been broken for some time and I will be away from my desk for a couple weeks pretty soon, so I wrote the behaviour for this but left it unused. I will come back to this in the future, once I figure out a way to implement it which does not require adding the "you can hit this" flag to every edible item. Also I had to refit the recent addition of dogs barking at felinids to fit into this, with a side effect that now dogs won't get mad at a Felinid they are friends with. This... feels like intended behaviour anyway? Why It's Good For The Game It's good for these to work the same way instead of reimplementing the same behaviour in multiple files. Being able to have Ian (or other dogs) follow you around the station is both fun and cute, and also makes him significantly more vulnerable to being murdered. Changelog cl add: Ian has learned some new tricks, tell him what a good boy he is! add: Ian will come on a walk with you, if you are his friend. refactor: Ian's tricks work the same way as some other mobs' tricks and should be extendable to future mobs. fix: Dogs no longer run at the maximum possible speed for a mob at all times. add: When Ian gets old, he also slows down. Poor little guy. add: Dogs will no longer dislike the presence of Felinids who have taken the time to befriend them. /cl |
||
|
|
3daf3b0643 |
fixes silly stuff about basic mobs (#72260)
## About The Pull Request makes basic mob attacks call their default attacks when done by a player, rather than calling simple mob attacks makes basic mob attacks call simple animal attacks by default, until we remove simplemobs moves some stuff off to procs and flags, fixes some stuff ## Why It's Good For The Game im moving holoparasites to basic mobs and i literally cant give them secondary click attacks ## Changelog 🆑 fix: fixes moonicorns not applying pax /🆑 |
||
|
|
febdb61e01 |
makes status tab use signals, thirds the delay between updates (#72002)
## About The Pull Request status panel for carbons and humans instead of hardcoding stuff, uses signals (borg material storage too) removes combat mode indicator in status tab from xenomorphs which have a button for it, but adds it to simplemobs, since they dont have a visual indicator adds status tab stuff to basic mobs, i think they were missing everything by accident offsets unique status tab stuff for all mobs by a single line the delay between updates is a third of what it was before, mainly to make shuttle timers more accurate (approved by kyler) ## Why It's Good For The Game much cleaner code, makes future implementations easy ## Changelog 🆑 qol: you can see your combat mode status as a simple or basic mob, and you can see your health as a basic mob qol: status panel updates three times as fast /🆑 |
||
|
|
81012494d1 |
Fixes many basic mobs not being vulnerable to extreme atmospheres and temperatures by making it the default (#71817)
## About The Pull Request **In short:** This PR causes cows, pigs, rabbits, sheep, cockroaches, mothroaches and mice to take damage in dangerous atmospheres and temperatures. **In long:** So simple mobs take damage from extreme atmospheres and temperatures by default, this is not the case with basic mobs however. Basic mobs can be given the `atmos_requirements` and `basic_body_temp_sensitive` elements to accomplish this, but these are missing on a number of basic mobs that probably shouldn't be able to survive in space. This PR gives basic mobs the `atmos_requirements` and `basic_body_temp_sensitive` elements by default, using the same values as default simple mobs do. These values have been overridden in the cases where this was done by the original simple mob (cockroaches and lavaland mobs) or where the basic mob already had one of the elements with different values (space bunnies and void puppies). Not every mob is vulnerable to temperature or atmosphere though. Setting `unsuitable_atmos_damage` to 0 will make it so the mob isn't given the `atmos_requirements` element. Setting both `minimum_survivable_temperature` and `maximum_survivable_temperature` to 0 will make it so the mob isn't given the `basic_body_temp_sensitive` element. I'm not sure if this is the best way of doing this. I don't know if mobs dying to extreme atmos/temp by default was left behind with simple mobs for a reason or if it was just forgotten about. ## Why It's Good For The Game Cows, pigs, rabbits, sheep, cockroaches, mothroaches and mice are probably not intended to be space-faring animals. Basic mobs matching the same default atmosphere and temperature vulnerabilities as simple mobs makes it harder to overlook that when porting them to basic mobs. ## Changelog 🆑 fix: cows, pigs, rabbits, sheep, cockroaches, mothroaches and mice now take damage in hazardous atmospheres and temperatures /🆑 |
||
|
|
ddc3e57310 |
[NO GBP] Rabbits won't become dense when they die (#71499)
## About The Pull Request Made a last minute suggestion change to a PR which was just merged and then like a couple minutes after that we decided it was a bad idea actually. This implements the _actual_ default behaviour we expect mobs to have. Dense mobs become undense when they die. Mobs which already aren't dense continue not being dense. They return to their original state when they're alive. ## Why It's Good For The Game This is largely how you expect corpses to work, ## Changelog 🆑 fix: Rabbits don't suddenly become more dense when killed than they were in life. /🆑 |
||
|
|
d74e84adda |
Basic Mob Carp Part IV: Revived Basic Mobs Look Alive (#71482)
## About The Pull Request Fourth atomisation of #71421 Pretty basic fix, if you revived basic mobs they'd retain their dead appearance forever (as well as losing density if they had it). Now they don't do that. There's still some work to do to get the Lazarus Injector to work with Basic Mobs because of how it changes behaviour, and we don't really have support for that yet. Probably important once it covers more pets because once Basic Mob Dogs is merged Ian will be temporarily impossible to revive with the injector (although strange reagent, wands, etc will still work fine). I'll get to that eventually. ## Why It's Good For The Game If something is alive it should look alive. ## Changelog 🆑 fix: A revived basic mob will stand up again rather than inching around as a living corpse. /🆑 |
||
|
|
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.
|
||
|
|
684eab3d31 |
Converts SFX keys into DEFINES (#65146)
About The Pull Request Simply converts all instances of soundkeys that use get_sfx from strings into defines. E.g. "sparks" is now SFX_SPARKS Why It's Good For The Game It makes life a lot easier when you're looking for a sound effect. You just type SFX_ and you get suggestions in VSC. Plus, it looks better. image Changelog Not player facing. |
||
|
|
d602967641 |
Fixes the riding component not working with basic mobs (#63884)
basic mobs were missing behavior on relaying movement |
||
|
|
dc38af86c9 |
Basic mobs can be vareditted again (#62046)
Readds the missing parent call. |
||
|
|
b6dafef8e8 | converts cows to basic mobs and ADDS MOONICORNS (#61446) | ||
|
|
46cb925af0 |
Basic Mobs: the cooler simple mobs that run on datum AI. (With reworked cockroach AI as proof of concept) (#60694)
Simple_animals / mobs are the biggest lie in this code-base. They're far from simple and have an extreme god-object problem. Especially when you get to /hostile, where there is so many procs, vars, and what not, that you can't make any interesting additions without snowflaking the hell out of the code. This PR hopes to help kill this problem by introducing a new /living subtype, /living/basic. The idea of this refactor is to slowly start moving all old simple_animals to this new system, moving over behaviors like charging and more extravagant mobs like megafauna over bit by bit similar to how newfood was implemented. One of the other big goals of this refactor is to move many of the fringe simple animal behaviors into either AI datums, or components/elements. (Some of which still needs to be done in this PR). As a proof of concept, I created the base mob/living/basic, and moved cockroaches over to the system. Since cockroaches have both a passive, melee and ranged mob. This PR does slightly affect balance as the behavior isn't 1-on-1 due to it no longer running on the janky /hostile behavior, but I tried to keep the effects to a minimum, and the glockroach and hauberoach are not spawnable through many means as far as I know. |