mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-10 23:54:14 +01:00
master
58 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 SmArtKar
|
8eed335b94 |
Refactors inventory UI to be completely datum and vis_contents-based (#95998)
## About The Pull Request Completely removes individual inventory UI handling from mob and HUD code and moves it to slot datums. ``/datum/inventory_slot`` now is responsible for displaying items on the player UI and does so through vis_contests as opposed to screen_loc - which ensures that wide items will display properly rather than be offset to the right. Centralized, slot_id based handling allows us to significantly simplify inventory and HUD code (see how many lines were removed) as you no longer need to individually track all items for both the HUD owner and the observer, and makes it easier for us to fully datumize inventory handling in the future. Also fixes a bug where observers would see players' storage UI and have the items linger on-screen after its closed. ## Why It's Good For The Game Makes working with inventories and HUDs easier, fixes visual issues with wide items, I need this for human rendering refactors. ## Changelog 🆑 refactor: Refactors inventory UI to be completely datum and vis_contents-based fix: Observers should no longer see doubled up inventory UIs /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
CabinetOnFire
|
2ede6af8bc |
Fix basic mobs triggering click cooldown erroneously. (#95906)
## About The Pull Request Basic Mobs used to always trigger cooldown on clicks. This resulted in missed attacks causing you to have a delay before you could attack again, this makes it really punishing to play as a basic mob. To resolve this I did a mini-refactor on basic mob's attack chain to allow for the return values to determine whether we go on cooldown or not. Preventing attacks that did nothing (due to not passing checks, or simply not having any behavior) from causing cooldown. This fixes #95605 ## Why It's Good For The Game being able to perform melee with the same rules as /human is only fair ## Changelog 🆑 DresserOnFire fix: Fixes a bug where player-controlled basic mobs would get a cooldown when their attacks miss refactor: basic mob attack chain can now decided whether an attack resulted in a cooldown or not. /🆑 |
||
|
John Willard
|
774c07cd9b |
Basic mob stat panel gutting (#95543)
## About The Pull Request Changes Guardian HUD to use action buttons instead of HUD elements, which means their buttons 1. Can now be moved 2. Can be binded Other Holoparasite HUD changes: 1- Moves some special buttons like explosive's explosion ability to be where the "Toggle Mode" button typically is, to be consistent with some other modes (assassin, gas) that also works like their unique ability. 2- Gives non-dextrous holoparasites the ability to move floors, since they float. 3- Fixes dextrous holoparasites having 2 health HUDs 4- Moves "Check Guardian Type" verb to a new action button meant to mimick the Antag UI Info button. Gives Soulscythes a Combat mode indicator Locks Revenant's combat mode indicator (cause it does nothing) Adds another hoverable HUD element, basic mobs can now hover over their healthdoll to see their Health % <img width="85" height="123" alt="image" src="https://github.com/user-attachments/assets/ad660ba4-296c-4699-9ec4-03a6e7b97880" /> <img width="95" height="101" alt="image" src="https://github.com/user-attachments/assets/12d4d9d3-cf2c-4c52-81aa-17ce538b9d48" /> Adds a Unit Test to ensure all basic mobs have a HUD that shows some form of health & combat mode (unless unnecessary like Revenants), to not lose any information from basic mob conversion now that they lose the stat panel. ## Why It's Good For The Game This is yet another supplement of https://github.com/tgstation/tgstation/pull/95383 - Removing stat panel entries for all basic mobs is a great move towards lessening the reliance of mobs on the stat panel. This is also just good QoL for Holoparasites, especially since their stat panel had 2 entries for "Master HP" and your "Own" HP, despite Holoparasites not even having their own HP at all. ## Changelog 🆑 qol: Holoparasites' abilities are now action buttons, so you can rebind or move them. qol: Holoparasites now have floor change buttons. fix: Holoparasites and Soulscythes now have a combat mode indicator. fix: Dextrous holoparasites now have their inventory slot again while non-dextrous had it taken away (not that they could use it). /🆑 |
||
|
MrMelbert
|
0ec110a053 |
Update mob fire vfx a bit (#95199)
## About The Pull Request 1. Removes the particle effects from mob fire. 2. Fire lighting now scales with how "on fire" you are. 3. Adds an emissive effect to mob fire. 4. Slightly increased the number of firestacks needed for the more intense effect (by 10%) (3->5) 5. Fixes the singular broken frame in monkey fire sprite. 6. Xenomorphs now use the generic fire sprite, adjusting the offset for larger xenos. Closes #12605 . ## Why It's Good For The Game 1. The effect just doesn't look good as mobs move and rotate unfortunately. We could probably revisit it in the future when particle frameworks are more developed, but in the meanwhile watching all of a mob's embers just twist 90 degrees as they flop to the ground looks jarring. 2. Produces a neat effect of the light dying out as you get closer to extinguishing a fire. 3. Adds some bloom to fire, and keeps fire visible as the light dies out (as the firestacks decrease). I think it looks neat, though I'm not sure how... realistic? It is in practice? 4. You scarcely see the "low stack" fire vfx due to the low threshold it was set to. This change is intended to make it slightly more common. 5. Bugfix. It was not offset correctly. 6. Bugfix. I didn't sprite anything unique for them - I just made them use the generic fire overlay. <img width="336" height="142" alt="image" src="https://github.com/user-attachments/assets/ceeac35d-912c-4ad1-9d3b-4384ffdb905b" /> ## Changelog 🆑 Melbert del: Removed ember particle effects from mob fire add: Mob fire brightness now scales with how "on fire" it is - the more fire, the brighter the light add: Mob fire now has a bloom effect and glows a bit add: The threshold that human fire sprites update from "small" to "big" has been increased (by 10%) fix: Fixed broken frame in monkey fire animation fix: All Xenomorphs now use the generic fire sprite fix: All Xenomorphs no longer lose their fire sprites when resting fix: Large Xenomorphs now offset their fire overlay to the middle of their sprite /🆑 |
||
|
Bloop
|
53ed83bb9d |
Makes some more lists lazy (#94388)
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
SyncIt21
|
7c5ef1cfb8 |
Removes unused parameter times_fired from mob procs (#94590)
## About The Pull Request What it says on the tin. `times_fired` is the most unused parameter in all mob procs. I say most because there were just 2 cases where it was used - handling breathing - handling heartbeat Besides these 2 cases this parameter did nothing in every proc. Removing it does 2 things - Makes those procs more readable as it now has 1 less parameter that was documented poorly and did nothing - Makes those procs slightly faster as we are passing 1 less variable to its parameter call stack It can easily be substituted with `SSmobs.times_fired` which was its original value anyways ## Changelog 🆑 code: removes an unused parameter `times_fired` from mob life procs. Making them function slightly faster /🆑 |
||
|
Joshua Kidder
|
7a3ad79506 |
All camelCase (Brute|Burn|Fire|Tox|Oxy|Organ|Stamina)(Loss) procs now use snake_case. UNDERSCORES RULE! (#94111)
## About The Pull Request It's just a partial cleanup of anti-[STYLE](https://github.com/tgstation/tgstation/blob/master/.github/guides/STYLE.md) code from /tg/'s ancient history. I compiled & tested with my helpful assistant and damage is still working. <img width="1920" height="1040" alt="image" src="https://github.com/user-attachments/assets/26dabc17-088f-4008-b299-3ff4c27142c3" /> I'll upload the .cs script I used to do it shortly. ## Why It's Good For The Game Just minor code cleanup. Script used is located at https://metek.tech/camelTo-Snake.7z EDIT 11/23/25: Updated the script to use multithreading and sequential scan so it works a hell of a lot faster ``` /* // Copyright 2025 Joshua 'Joan Metekillot' Kidder This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>. // */ using System.Text.RegularExpressions; class Program { static async Task Main(string[] args) { var readFile = new FileStreamOptions { Access = FileAccess.Read, Share = FileShare.ReadWrite, Options = FileOptions.Asynchronous | FileOptions.SequentialScan }; FileStreamOptions writeFile = new FileStreamOptions { Share = FileShare.ReadWrite, Access = FileAccess.ReadWrite, Mode = FileMode.Truncate, Options = FileOptions.Asynchronous }; RegexOptions regexOptions = RegexOptions.Multiline | RegexOptions.Compiled; Dictionary<string, int> changedProcs = new(); string regexPattern = @"(?<=\P{L})([a-z]+)([A-Z]{1,2}[a-z]+)*(Brute|Burn|Fire|Tox|Oxy|Organ|Stamina)(Loss)([A-Z]{1,2}[a-z]+)*"; Regex camelCaseProcRegex = new(regexPattern, regexOptions); string snakeify(Match matchingRegex) { var vals = matchingRegex.Groups.Cast<Group>().SelectMany(_ => _.Captures).Select(_ => _.Value).ToArray(); var newVal = string.Join("_", vals.Skip(1).ToArray()).ToLower(); string logString = $"{vals[0]} => {newVal}"; if (changedProcs.TryGetValue(logString, out int value)) { changedProcs[logString] = value + 1; } else { changedProcs.Add(logString, 1); } return newVal; } var dmFiles = Directory.EnumerateFiles(".", "*.dm", SearchOption.AllDirectories).ToAsyncEnumerable<string>(); // uses default ParallelOptions // https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.paralleloptions?view=net-10.0#main await Parallel.ForEachAsync(dmFiles, async (filePath, UnusedCancellationToken) => { var reader = new StreamReader(filePath, readFile); string oldContent = await reader.ReadToEndAsync(); string newContent = camelCaseProcRegex.Replace(oldContent, new MatchEvaluator((Func<Match, string>)snakeify)); if (oldContent != newContent) { var writer = new StreamWriter(filePath, writeFile); await writer.WriteAsync(newContent); await writer.DisposeAsync(); } reader.Dispose(); }); var logToList = changedProcs.Cast<KeyValuePair<string, int>>().ToList(); foreach (var pair in logToList) { Console.WriteLine($"{pair.Key}: {pair.Value} locations"); } } } ``` ## Changelog 🆑 Bisar code: All (Brute|Burn|Fire|Tox|Oxy|Organ|Stamina)(Loss) procs now use snake_case, in-line with the STYLE guide. Underscores rule! /🆑 |
||
|
FalloutFalcon
|
d2f34e33be |
moves abstract_type up to datum, spawners wont spawn them (#92909)
## About The Pull Request moves all implementations (im aware of) for "Im a parent type dont spawn me please" to the datum layer to standardized behavior adds a standerized proc for filtering out "bad" items that we dont want spawning. applies to it the subtype vendor, gifts, and a new spawner and mystery box for a random gun (neither playerfacing) "port" of https://github.com/shiptest-ss13/Shiptest/pull/4621 https://github.com/user-attachments/assets/22f6f0b2-b44e-411a-b3dc-6b97dc0287aa small warning: I dont have EVERY abstract type defined right now but, ive done a good enough job for now. Im tired of data entry rn ## Why It's Good For The Game standardizing behavior. Might be a micro hit to performance however having this lets us not rely on icon state to determine whether something is a parent type and makes it much easier to tell something is a parent type (could be applied further to things like admin spawning menus and things like that). need feedback on if this is actually good for the game. ## Changelog 🆑 add: Soda cans show up in the silver slime drink table. add: Examine tag for items that are not mean to show up ingame. refactor: Standardizes how gifts rule out abstract types. fix: gifts no longer check if something has an inhand, massively expanding the list of potential items. /🆑 |
||
|
Krysonism
|
c5f1b7f8c3 |
Da blobmob update! Indepedent strains, new sprites, egglike spores, fixes, sounds and buffs! #Cytology2025 (#91368)
## About The Pull Request This PR makes a number of changes focusing on improving the blob minions, spores, nauts, zombies and their associated component. ## New sprites The blob spore, blob zombie and blobbernaut has been resprited. The spore and zombie have been lightly touched to preserve the most of the original characteristics while given a cleaner look. The spore and zombie have a partially desaturated version used to let more of the strain colour through instead of them all ending up dark brown. The blobbernaut has been reshaded and the side sprite has been made coherent with the front state, I made decided how the front state was shaded should be the "canon" one (this might be a bit controversial but the wild inconsistency was bugging me.) The blobbernaut is a bit less veiny, but the veins look more natural and use the strain complementary colour. Many combinations are cool, some are a bit lacking due to the weird choices of complementary colour.   ## New Cytology Related Features Blob mobs can now have strains independently of an overmind. The 15% mutation chance of vat grown creatures causes a spore or blobbernaut to get a random strain. When I first added the blob spore cell line, ghosts could click on cyto blob spores to posses them, they would then presumably(?) but not explicitly be free antags. This ability was lost when the blob spore code was modernised. Very few people knew about this, and no one grew blob spores anyway. This feature is coming back in a big way, vat grown blob spores present a new unique job hazard, they are automatically offered to ghost as an extremely shitty, but free antag. I have tested spawning like 15 antag pre-buff blob spores in a live round and they failed completely to antagonise the crew effectively, hopefully these buffed spores won't present too much of an issue to our great administration team, if that ends up being the case, there are many levers to pull to tone them down. ## Blob Spore Buffs Blob spores prior to this PR were almost completely useless. The main cause of this was the extremely dilute reagent smoke reaction; 10u divided over 20 seconds. This resulted the smoke clouds dealing 0.15 - 0.6 DPS, a completely negligible and useless amount. The smoke reagent concentration has been massively increased(10u -> 40u) and the smoke duration has been reduced(20s -> 8s). The result of this is that blob spore clouds are something you want to avoid standing in, but they provide less smoke cover for the blob and nauts. Blob spores have also gained the ability to vent crawl. Simple mobs that can't either open doors or vent crawl feel super bad to play. They also deal a little more melee damage, but this is still pathetically low on account of their low attack speed. I have adjusted their supplementary reagents and reduced the amounts of spores produced per cycle(2 -> 1) to make them a bit harder to mass produce. ## Blob Strain Buffs I have not made this PR with the goal of buffing any particular strain, but some changes have affected blob strain balance: ### Debris Devourer This was the only strain that was strongly mechanically tied to the core. In order to allow for independent debris devourer mobs, they can now eat trash(or any item really), they are independent, they store these items inside their mob, and use these for the debris devourer reactions. If they have an overmind, the item gets sent to the core. This should result in a nice buff to the strain, which I've been told is one of the bad ones. ### Regenerative Materia & Cryogenic Poison 5 years back another contributor removed the ability of blobs and blobbernauts to transfer reagents with their attacks(as their expose method is vapour). This was a completely undocumented change and possibly unintentional, so I am reverting it by giving blob reagents penetrates_skin = VAPOR again. This only really affects these two strains. It makes regenerative materia much stronger, while barely having any effect on cryogenic poison, because temperature normalisation changes has made it completely ineffective even with much more reagent applied. ### Electromagnetic Web The spore reagent cloud buff might also give a boost to some strains with good expose effects, like electromagnetic web. ## Blob Cooking Blob spores now drop spore sacks, they can be ground for spore toxin, or cracked on a griddle to create an egg-like treat! I also added a detoxification reaction to reduce the amount of toxin when cooked, might not work yet because I think griddles may not actually heat the food? ## Sound Effects Blob spores bursting and blobbernauts dying have sound effects. ## Why It's Good For The Game level 5 biohazard ## Changelog 🆑 image: blob mobs have been respectfully resprited. add: vat grown blob mobs can sometimes get born with a blob strain. add: blob spores drop spore sacks, crack them on the griddle. add: debris devourer mobs can now eat trash, sending it to the core, if there is one. add: vat grown blob spores are now sentient and evil. balance: blob spores now have much more concentrated smoke. balance: blob spores can ventcrawl. fix: regenerative materia and cryogenic poison strain blob tiles & nauts now inject chems again. sound: blob spores & blobbernaut now have death sound effects. /🆑 |
||
|
necromanceranne
|
57624ca1e2 |
Rebalances wound determination values, wounding escalation and wound armor to hopefully be less explosive (#91099)
## About The Pull Request This is a big one so please bear with me, wounds are complicated ### Max Potential Wound Rolls We've decreased the max contributed damage to wound rolls from 35 to 25. This results, after the exponent, a max possible wound roll of 1 to 91 before any modifiers (assuming the attack, after armor, is 25 or above). The minimum value to wound is still 5. ### Wound Escalation Penalties Most wounds were contributing significant numbers per wound type to the potential for a new wound to occur. Getting wounded once meant you were getting wound a lot, but actually getting past that first wounding may be the tricky part. We have significantly reigned in the wound penalty that having a wound contributes, and instead utilize the series wound penalty to allow same type wounds to escalate themselves faster as a priority. Having wounds still makes you more wound vulnerable, just not to such an extreme degree. The priority here for what wounds matter most for contributing to overall wounding vulnerability is ``Infected BURNS > BURNS > SLASH|PIERCE > BLUNT.`` ### Wound Armor Wound armor, unlike all other kinds of armor, was used as a additive value to the wound roll modifiers rather than a multiplicative value. We have reworked how wound armor is determined by changing how wound modifiers are calculated. Firstly, we're passing our entire injury roll into the ``check_woundings_mod()`` proc, as we're not treating this as a proc that just adds values anymore. Secondly, bare wound bonus only applies if there is no potential wound protection from any source, as expected. But it comes last in the calculations. Thirdly, wound protection is applied to the injury roll last, after wound bonuses from the attack, wound bonuses from other wounds and wound bonuses from a disabled limb are applied. This does not include serial wound bonuses, which are determined outside of this proc. Wound protection comes from two sources. Clothing and limb wound resistance. Your chest and head have an amount of wound resistance so long as they are not mangled in any fashion. Being mangled means having either a hairline fracture or a weeping avulsion wound. Wound protection reduces the final injury roll by a percentage. Say our roll is 50, and we have effectively 50% wound protection. The final roll would be 25. ### ~~Wound Armor on Clothing~~ Reverted ~~Most clothing have had their wound armor values changed. As a loose rule, I used the highest of melee or bomb armor, except where that value was 100, in which case I used the lowest instead. I'm basing this decision on how embeds are calculated, which is attack type agnostic.~~ ~~Some armor have inconsistent values because they are alternative armors to an existing armor type or are hyperspecialized armor. Ablative, bulletproof and security vests all share a value of 35, despite the former two not having decent melee or bomb armor.~~ ~~Some clothing missing wound armor that should have had them now have wound armor.~~ ~~This may need a bit of scrutiny in case one or two seem weirdly high. Some have maybe become too low. Its a bit hard to say.~~ ### The ``bare_wound_bonus`` variable I changed it to ``exposed_wound_bonus`` to better represent when it applies. You can be naked and still not be affected by this bonus if the limb has wound resistance. ## Why It's Good For The Game I'm not promising anything with this PR, but this is an attempt to sanity check the values on wounds so that we're not seeing what the data that determined the removal of beheading presented. An extreme over-representation of tier 3 wounds. ~~And, from that, maybe I can argue for beheadings coming back. That's my goal. I think beheadings happened so much because the numbers were in need of work.~~ Well okay I just wanna make wounds a bit more workable actually more than I want beheadings. Why is it that tier 3 wounds were so over-represented? Because wounds will often force more severe wounds of other types by merit of any wounds existing at all on a limb. Having **_a_** wound makes you more wound prone for any kind of wound, and not just making you more likely to suffer a more severe type of the same wound. The threshold mechanic was intended to simulate making a wound worse, but oddly just made a limb broadly more prone to getting worse from any kind of attack to such a degree that future wound rolls of different types were often going to start at the threshold necessary to be a tier 3 wound. Dismemberment, mind you, requires you to suffer a flesh wound while you have a bone wound of tier 2 or higher (with tier 3 giving a bonus to this). You can do this readily via just a sharp weapon, because having a mangled limb causes the wound to turn into a bone wound. Technically, this is meant to be less likely as the effective damage for this wound is halved. But the wound bonus from having a flesh wound was almost always significant enough to kick your new bone wound up to a tier 3. In other words; its not surprising that you saw so many beheadings, because the system wanted to behead you as fast as it possibly can thanks to all these escalating values. Wound armor was only applied as a flat reduction on the roll. The average for wound armor was 10. After receiving a single wound, you can expect wound rolls to reach upwards of 100, even if the actual damage roll was not particularly high, due to wound stacking bonuses form being wounded. This meant that wounds, if they happened, came thick and fast after the first, regardless of what your protection might be to wounds. It was just a matter of getting past the initial bump. This is why effects that forced wounds were so powerful. They basically made a given limb more prone to taking a wound without having to deal with the protection problem first. Finally, this is just a broad flaw with the system that is not its fault. It is actually a problem that isn't a problem. Most people in the game are not wearing helmets that protect their head. So most people are going to suffer from a higher proclivity of being wounded if people are aiming for the head. There is this...kind of cargo cult belief that aiming for the head means you do more damage, or can stun someone if you're lucky or what have you. It's entirely nonsense, but it has a grain of truth in that people rarely wear, or even have access too, headwear that provides wound protection or any protection at all. People have jumpsuits, which are universally wound protected, but that isn't true of the head. Look, the point is, they're not aiming at the head because it is usually less armored, its for other reasons but it just so happens to become true due to wounds and how wounds roll their type. To soften this issue, I've decided to treat wound resistance as armor until the limb suffers a tier 3 wound. This way, hits to the head MAY not necessarily escalate to tier 3 instantly as they would on live even from relatively low power weapons. Some weapons have very low force, but have extreme bare wound bonuses. This should be less likely after this change. I doubt this will necessarily make high damage high wound weapons like energy swords any less prone to cutting you clean open, but it might thanks to the reduction to contributed damage to the injury roll. The system is now _a bit more random_. ## Changelog 🆑 balance: Wounds do not make you as vulnerable to suffering wounds of all types as before. Instead, wounds make you more vulnerable to suffering worse versions of themselves as a priority. balance: Wound armor is now more impactful when protecting you from wounds when you have already been wounded. balance: Your head and chest are more difficult to wound until they have been mangled; either from suffering from a weeping avulsion or a hairline fracture. code: Changed the variable for bare_wound_bonus to exposed_wound_bonus to better explain what that variable is doing. /🆑 --------- Co-authored-by: Jeremiah <42397676+jlsnow301@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. /🆑 |
||
|
Jacquerel
|
a658fe8ee8 |
Fix guardian basic attacks (#90911)
## About The Pull Request Fixes #90902 There were a couple of problems: - The check `if (!isliving(attacked_atom) || !isclosedturf(attacked_atom))` would obviously always early return before performing the war cry because we don't have any walls in the game which are also living mobs. I fixed it. - Attack chain refactoring meant that attacking nonliving targets as a basic mob would reset the attack cooldown to the default rather than the mob one. Maybe when we kill simple mobs we can remove that code and let basic mobs handle it themselves? - For some reason we were playing a sound on the loc of an attacked atom instead of the atom, which is an area if you are punching a wall, which runtimes. Now we just play it on the atom, IDK why we weren't doing that. ## Changelog 🆑 fix: Standard Holoparasites will once again yell their battlecry and can rapidly punch windows. /🆑 |
||
|
SmArtKar
|
431bf75d53 |
Color Code Audition: Human rendering hates me (#89702)
## About The Pull Request This trainwreck of a PR is (hopefully) a final solution to all rendering jank stemming from the new filter-based coloring system. I went over every single instance of RESET_COLOR, either adding KEEP_APART or rewriting them entirely so they render properly. I've also fixed blood rendering issues by utilizing alpha filters and adding an abstract "holder" appearance for worn items, which holds blood overlays on worn clothing as to avoid coloring it. I've also fixed horrible inconsistencies with atmos pipe coloring as a result (of getting sucked down that rabbit hole) and converted all uses of COLOR_VERY_LIGHT_GRAY in atmos code to ATMOS_COLOR_OMNI to avoid confusion. MODsuit modules still get colored into MOD unit's color, need to refactor their rendering for this. Closes #88989 Closes #87526 Closes #89837 ## Changelog 🆑 refactor: Audited all remaining coloring code - among noticeable changes, blood should no longer get colored or "leak out" of item bounds, atmos pipes no longer color weirdly and repairbots are white again. /🆑 |
||
|
Ben10Omintrix
|
2438ff0213 |
removes alot of click-related self registering signals on basic mobs (#87220)
## About The Pull Request there was no real benefit of using signals over proc overrides for many of these cases. ## Why It's Good For The Game registering signals on self when we can just override the proc is un-necessary, im responsible for most of these so im just confronting the sins of my past ## Changelog 🆑 /🆑 |
||
|
Ben10Omintrix
|
91baa94ac5 |
event based incapicated and able_to_run (#86031)
## About The Pull Request this is a revival of #82635 . i got permission from potato to reopen this, he did almost all the work. i only just solved the conflicts and fixed all the bugs that were preventing the original from being merged (but it should be TMed first) ## Why It's Good For The Game slightly improves the performance of basic mob AI ## Changelog 🆑 LemonInTheDark refactor: able_to_run and incapacitated have been refactored to be event based /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: ZephyrTFA <matthew@tfaluc.com> |
||
|
tgstation-ci[bot]
|
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
Jacquerel
|
2016156d6f |
Shift certain flying mob positions upon death (#85942)
## About The Pull Request Chasing more side effects of offsetting mobs and giving them shadows.  Some mobs are "flying" while they are alive, but not while they are dead. Some mobs (like Watchers) offset their death sprites in the dmi to make it look like they have dropped to the ground, others do not bother. For the ones which don't, we want to shift them down ourselves so it doesn't look like the corpse is levitating. I'm willing to accept better suggestions for how to implement this but this seemed like the most obvious. ## Why It's Good For The Game No more levitating corpses ## Changelog 🆑 fix: Carp, bat, parrot, and dragon corpses no longer float in the air. /🆑 |
||
|
Ghom
|
36ca9a8559 |
Raising lobstrosities from chrabs is now a component. Adds in tadpoles which become frogs. (#85346)
## About The Pull Request I've componentized part of the code that manages raising lobstrosities from chrabs so that it can be added to other fish too. As proof of concept, I've added tadpoles. Tadpoles are not fished like the rest, instead you merely right-click a puddle and after 5 seconds you'll get one. Tadpoles are fairly fragile, cannot be butchered, don't reproduce, require lukewarm freshwater, need to be feed frequently, and become frogs after about 3 minutes. ## Why It's Good For The Game A small needed refactor for the chrab code, plus another small fish to make it easier to complete the first fish scanning experiment. ## Changelog 🆑 add: Added tadpoles, which can be scooped from puddles with right-click. Functionally they're like most fish, which require an aquarium to survive, and also need to be fed fairly frequently, however they quickly become frogs after about 3 minutes of care. add: Every station now has a couple puddles. One at the public garden and the other in prison. qol: Changed the name of an aquarium UI button from "Reproduction Prevention" to "Reproduction and Growth", as it controls both fish breeding and growth. /🆑 |
||
|
Jacquerel
|
4019835b3e |
Living Limb fixes (feat: Basic mobs attack random body zones again) (#82556)
## About The Pull Request Reworks Living Limb code to fix a bunch of runtimes and issues I saw while testing Bioscrambler. Specifically, the contained mobs are now initialised via element following attachment so that signal registration can occur at the correct time. This allows limbs to function correctly when added from nullspace via admin panel or bioscrambler. Secondarily (and more wide-ranging) at some point (probably #79563) we inadvertently made basic mobs only attack the target's chest instead of spreading damage. This is problematic for Living Flesh which can only attach itself to damaged limbs but was left unable to attack damaged limbs. I've fixed this in a way which is maybe stupid: adding an element which randomises attack zone pre-attack. Living limbs also limit this to _only_ limbs (although it will fall back to chest if you have no limbs at all). This is _technically_ still different, the previous behaviour used `adjustBruteLoss` and `adjustFireLoss` and would spread the damage across your entire body, but there isn't a route to that via the new interface and this seems close enough. ## Changelog 🆑 fix: Living Limbs created by Bioscrambler will be alive. fix: Living Limbs can once more attach themselves to your body. balance: Living Limbs will prioritise attacking your limbs. fix: Basic Mobs will once again spread their damage across body zones instead of only attacking your chest. /🆑 |
||
|
Ghom
|
95b7fa1fb7 |
Add a unit test to check that maploaded simple/basic mobs are in an environment they can survive in. (#82180)
## About The Pull Request I've recently noticed that the maploaded penguins from the snowdin away mission were dying from unsafe atmos/temperature. This sparked the idea of making a (focus only) unit test that would prevent this sort of issues from happening. This PR also implements the usage of the `atmos_requirements` and `body_temp_sensitive` elements for simple animals too, cutting down the copypaste. ## Why It's Good For The Game More unit tests to make sure things are done correctly. ## Changelog 🆑 fix: Made sure that mapped critters (i.e. penguins on the snow cabin away mission) can survive in the environment they're spawned in. /🆑 |
||
|
MrMelbert
|
d9243d1016 |
Refactors fire overlays once again to make it not get stuck so often (#81367)
## About The Pull Request Maybe finally fixes #77701 A big reason why this kept happening is because fire uses standing overlays. But fire isn't managed by mobs anymore. Meaning in some situations, fire can cease to exist but the overlay can still be on the mob. So it gets stuck. So like, why use standing overlays anymore? We can just hook `update_overlays` signal. Isn't that neat. ## Changelog 🆑 Melbert refactor: Fire effects get added to mobs in a different way now. Maybe it will get stuck less. Report any oddities. /🆑 |
||
|
_0Steven
|
d131e74095 |
Minor say code refactor, fixes signers sometimes using the wrong verbs over radio (#80092)
## About The Pull Request Alternative title: "Baby's third pr: surprise say code refactor" While testing sign language I worked out that if the first message sent after toggling sign language involves speaking directly into a radio, it proceeds to use the wrong verb. After several hours of digging through say and telecomms code, I worked out the cause: the `verb_say` on humans is primarily updated to match tongue data during the verb _selection_ method `say_mod()` in `human_say.dm`, and as a consequence this meant the verb wasn't updated to the correct one until far after it had been copied to a virtualspeaker, leading to the incorrect verb being used for the radio message. This pr fixes this by refactoring this verb updating behaviour to be in a new method `update_verbs()`, which we then call _before_ attempting to call `radio()` to avoid wrongful copying and thus fixing the bug. There's theoretically also cases where the previous behaviour would use the wrong verb if one lost or gained a tongue between radio messages, or the wrong verb from those picked from a list for some simple/basic animals, but those are significantly less common. To note, I gave the new `update_verbs()` method the same arguments as the `say_mod()` method it got split out of, but having gone through all instances of it being used for this I don't feel it actually *needs* those arguments. So I'm unsure whether it should keep them or not. Opened as a draft for now for sanity's sake, and also cause, y'know, it touches say code. ## Why It's Good For The Game It was _really_ annoying. ## Changelog 🆑 fix: Signers no longer use the wrong verb when speaking directly into a radio for the first message after toggling sign language. refactor: Moved the updating of verb variables into a new method which is called earlier in living's say, which should avoid this happening for other things which updated their verbs the same way. /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
distributivgesetz
|
274eb2a52e |
Removes Clone Damage (#80109)
<!-- 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 Does what it says on the tin. We don't have any "special" sources of clone damage left in the game, most of them are rather trivial so I bunched them together into this PR. Notable things removed: - Clonexadone, because its entire thing was centered around clone damage - Decloner gun, it's also centered around cloning damage, I couldn't think of a replacement mechanic and nobody uses it anyways - Everything else already dealt clone damage as a side (rainbow knife deals a random damage type for example), so these sources were removed <!-- 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 Consider the four sources of normal damage that you can get: Brute, Burn, Toxins and Oxygen. These four horsemen of the apocalypse are very well put together and it's no surprise that they are in the game, as you can fit any way of damaging a mob into them. Getting beaten to death by a security officer? Brute damage. Running around on fire? Burn damage. Poisoned or irradiated? Toxin damage. Suffocating in space? Brute, burn and oxygen damage. Technically there's also stamina damage but that's its own ballpark and it also makes sense why we have a damage number for it. Picture this now: We have this cool mechanic called "clone pods" where you can magically revive dead people with absolute ease. We don't want it to be for free though, it comes at a cost. This cost is clone damage, and it serves to restrain people from abusing cloning. Fast forward time a bit and cloning is now removed from the game. What stays with us is a damage number that is intrinsically tied to the context of a removed feature. It was a good idea that we had it for that feature at the time, but now it just sits there. It's the odd one out from all the other damage types. You can easily explain why your blade dealt brute damage, but how are you going to fit clone damage into any context without also becoming extremely specific? My point is: **clone damage is conceptually a flawed mechanic because it is too specific**. That is the major issue why no one uses it, and why that makes it unworthy of being a damage stat. Don't take my word for it though, because a while ago we only had a handful of sources for this damage type in the game. And in most of the rounds where you saw this damage, it came from only one department. It's not worthwhile to keep it around as a damage number. People also didn't know what to do with this damage type, so we currently have two ways of healing clone damage: Cryotubes as a roundstart way of healing clone damage and Rezadone, which instantly sets your clone damage to 0 on the first tick. As a medical doctor, when was the last time you saw someone come in with clone damage and thought to yourself, "Oh, this person has clone damage, I cannot wait to heal them!" ? Now we have replacements for these clone damage sources. Slimes? Slime status effect that deals brute instead of clone. Cosmic heretics? Random organ damage, because their mechanics are already pretty fleshed out. Decloning virus? The virus operated as a "ticking timebomb" which used cloning damage as the timer, so it has been reworked to not use clone damage. What remains after all this is now a basically unused damage type. Every specific situation that used clone damage is now relying on another damage type. Now it's time to put clone damage to rest once and for all. Sure, you can technically add some form of cellular degradation in the future, but it shouldn't be a damage number. The idea of your cells being degraded is a cool concept, don't get me wrong, but make it a status effect or maybe even a wound for that matter. <!-- 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. --> 🆑 del: Removed clone damage. del: Removed the decloner gun. del: Removed clonexadone. /🆑 <!-- 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. --> |
||
|
MrMelbert
|
365e50bbce |
Mob attackedby / check_block refactor, plus some minor cleanup of attack_x procs (#79563)
## About The Pull Request - Deletes `spec_attacked_by` - Elements simple/basic mob attack threshold - There was a skeleton mob that "mimics armor" but didn't use the actual mimicing armor thing we have, so I changed that. - Moves `check_shields` down to the living level, renames it to `check_block` - Martial art blocking is now signalized (only CQC uses it anyways) - Cleaned up a bit of `attack_x` procs, but not a lot. Should have an entire PR dedicated to this .... mess. - Deprecates `/obj/item/melee` ## Why It's Good For The Game Second verse, same as the first. - Less bad species related procs. - Largely brings a lot of code in line, making combat more consistent across types. - Makes it a lot easier to add new code relating to blocking or taking damage. ## Changelog 🆑 Melbert refactor: Refactored another large chuck of attack code, primarily involving melee item attacks and non-human mob attacks. Report if you see anything weird fix: Pacifists clicking on simple robots or silicons no longer causes sparks fix: Blocked thrown batons are now properly... blocked /🆑 |
||
|
Jacquerel
|
a1e46c5d31 |
Basic Guardians/Holoparasites (#79473)
## About The Pull Request Fixes #79485 Fixes #77552 Converts Guardians (aka Holoparasites) into Basic Mobs. Changes a bunch of their behaviours into actions or components which we can reuse. Replaces some verbs it would give to you and hide in the status panel with action buttons that you may be able to find more quickly. They _**should**_ work basically like they did before but a bit smoother. It is not unlikely that I made some changes by accident or just by changing framework though. My one creative touch was adding random name suggestions. The Wizard federation have a convention of naming their arcane spirit guardians by combining a colour and a major arcana of the tarot. The Syndicate of course won't truck with any of that mystical claptrap and for their codenames use the much more sensible construction of a colour and a gamepiece. This lets you be randomly assigned such creative names as "Sparkling Hermit", "Bloody Queen", "Blue World", or "Purple Diamond". You can of course still ignore this entirely and type "The Brapmaster" into the box if so desired. I made _one_ other intentional change, which is to swap to Mothblocks' nice leash component instead of instantly teleporting guardians back to you when they are pulled out of the edge of their range. They should now be "dragged" along behind you until they can't path, at which point they will teleport. This should make the experience a bit less disorienting, you have the recall button if you _want_ to instantly catch up. This is unfortunately a bumper-sized PR because it did not seem plausible to not do all of it at once, but I can make a project branch for atomisation if people think this is too much of a pain in the ass to review. Other changes: - Some refactoring to how the charge action works so I could individually override "what you can hit" and "what happens when you hit" instead of those being the same proc - Lightning Guardian damage chain is now a component - Explosive Guardian explosive trap is now a component - Added even more arguments to the Healing Touch component to allow it to heal tox/oxy damage and require a specific click modifier - Life Link component which implements the Guardian behaviour of using another mob as your health bar - Moved some stuff about deciding what guardians look and are described like into a theming datum - Added a generic proc which can return whether your mob is meant to apply some kind of damage multiplier to a certain damage type. It's not perfect because I couldn't figure out how ot cram limb modifiers in there, which is where most of it is on carbons. Oh well. - Riders of vehicles now inherit all movement traits of those vehicles, so riding a charging holoparasite will let you cross chasms. Also works if you piggyback someone with wings, probably. ## Changelog 🆑 refactor: Guardians/Powerminers/Holoparasites now use the basic mob framework. Please report any unexpected changes or behaviour. qol: The verbs used to communicate with, recall, or banish your Guardian are now action buttons. balance: If (as a Guardian) your host moves slightly out of range you will now be dragged back into range if possible, rather than being instantly teleported to them. balance: Protectors now have a shorter leash range rather than a longer one, in order to more easily take advantage of their ability to drag their charge out of danger. balance: Ranged Guardians can now hold down the mouse button to fire automatically. balance: People riding vehicles or other mobs now inherit all of their movement traits, so riding a flying mob (or vehicle, if we have any of those) will allow you to cross chasms and lava safely. /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
jimmyl
|
9644fcbc08 |
basicmobs that qdel on death ghost before qdel (#78931)
## About The Pull Request  ## Why It's Good For The Game its faster i think ## Changelog 🆑 code: basicmobs that delete on death, ghost before dying /🆑 |
||
|
Jacquerel
|
eb28d04f08 |
Watcher Nest Lavaland Ruin (#78790)
## About The Pull Request Adds a small new lavaland ruin, the Watchers' Grave.   You will need to figure out yourself how to find a way through the walls surrounding it (it's not very hard). This is mostly just atmospheric but also serves as a delivery vehicle for a unique item; an orphaned Watcher egg. (That's kind of it in terms of loot, unless you count a handful of lavaland mob corpses and mushrooms). You can either eat this (it's an egg), throw it at someone to spawn an angry watcher, or keep hold of it for a while and see what happens. <details>  That's right it's your very own baby watcher. It orbits your head and shoots at lavaland creatures for unimpressive damage. It won't ever intentionally shoot a player but they might walk in front of it, as it doesn't hurt very much they will probably forgive you. If you die it will continue circling your corpse to guard it against predation. </details> In creating this ruin I also added a new component called "corpse description". It provides some extra examine text to a corpse which is removed permanently if the mob is revived. There's a field you can varedit on corpse spawners (or make a subtype) which will automatically apply it to spawned corpses. You can use it for environmental storytelling. Or admins can use it to make fun of how you died. Also I fixed basic mobs runtiming when examined by ghosts. ## Why It's Good For The Game More variety in map generation. It's cute. Adds a tool that mappers might like. ## Changelog 🆑 add: Adds a new lavaland ruin where you can find a unique egg. /🆑 |
||
|
Jacquerel
|
504e6acfa3 |
Basic Mob Gorillas (#78918)
## About The Pull Request Now we can make basic mobs with hands easily so I did, they don't actually use their hands for anything with AI. In the future we can come back and share the monkey AI where they pick up items to hit people with, but frankly few weapons are more deadly than a gorilla's fists. IIRC I didn't really change their behaviour much, this is mostly just a straight conversion. Main difference is that they will prioritise eating nearby bananas and fruit salads over punching people. When I make these conversions nowadays I need to decide between "does this attack at the speed that it did as an NPC mob or the speed it did as a player?" I am arbitrarily deciding that gorillas are usually not players and electing for the former, but tell me if you disagree. I also made "show basic inhand sprites" into a component shared by Gorillas, Drones, and Dextrous Guardians (all also now available to become basic, once I get around to it), And I added an AI behaviour to run a basic emote. This is similar but different to "random speech", which kind of sucks and needs rewriting anyway. Gorillas don't speak, only ooga. ## Why It's Good For The Game https://www.youtube.com/watch?v=npuuTBlEb1U ## Changelog 🆑 refactor: Gorillas now use the basic mob framework. Please report any unusual side effects. /🆑 |
||
|
Jacquerel
|
6d59d8eb91 |
Hands management element (#78887)
## About The Pull Request Places "setting up being able to use hands" into an element so it can be easily applied to non-carbon mobs. ## Why It's Good For The Game This is one of the last roadblocks for basic mob implementation and people were intimidated by it but it turns out this shit is easy, 90% of this code is already just on `living` and I put a little bit more there. The element _really_ only handles stuff like dropping items on death, picking things up rather than biting them, and adding examine text. This also removes some copy/pasted code between `simple_animal` and `carbon` and unifies some behaviours which were implemented for some dextrous simple animals but not others. Changes to give Ian a single hand representing his mouth will come at a later date. ## Changelog 🆑 qol: You can now see what drones and gorillas are holding by examining them. admin: It's now easier to give handless mobs hands by applying the "dextrous" element. balance: Spiders and Bears can now climb railings (you know if... they'd rather do that than destroy them). /🆑 |
||
|
Jacquerel
|
389cdd6716 |
Replaces the changeling spacesuit with a passive ability (#78763)
## About The Pull Request Fixes #74168 I was going to make changes to the changeling spacesuit so that it works on Icebox but then I thought, why not _not_ do that. This isn't a commonly picked adaption so why don't we make it a little better. What's more spooky, hearing a knock on the window and seeing a fat suit outside? Or this?  Picking Void Adaption will now make you immune to low temperature and pressure (but not high temperature and pressure) and you will stop breathing. If you enter an area with low temperature or pressure then your chemical regeneration rate will decrease until you leave that area. Because it doesn't put a suit on you, it now also works during Lesser Form. While testing this I noticed that we weren't calling `Grant` on passive changeling abilities for some reason, I replaced that with the already-written interface for making "an action which doesn't give you a button". If people really _really_ miss the fat suit I guess I'll rework that instead, but I think I like this more. ## Why It's Good For The Game Makes a niche-pick ability more useful and easier to use. Meteor Changelings who land on Icebox now don't roll a dice to see if they get instantly knocked out by the atmosphere there. ## Changelog 🆑 balance: The Changeling Space Suit has been replaced by a new ability which makes you passively spaceproof without replacing your clothing. admin: Editing the atmos sensitivity variables on a basic mob during the game will now actually do something. /🆑 |
||
|
jimmyl
|
5db7992b09 |
basicmob clowns (#78448)
## About The Pull Request this is a mostly 1 to 1 port of simpleanimal clowns to basicmob clowns this means they have 1 more brain cell and they waddle https://github.com/tgstation/tgstation/assets/70376633/0c5f01c7-fea2-4d8c-9fc1-764c1557e1b8 ## Why It's Good For The Game  ## Changelog 🆑 refactor: clowns are basicmobs now /🆑 --------- Co-authored-by: san7890 <the@san7890.com> Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
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 /🆑 |
||
|
Sealed101
|
94d427aa48 |
Basic mobs drop their butcher results when gibbed (#78091)
## About The Pull Request Title. ## Why It's Good For The Game Fixes #78089 Simple mobs drop their meats when gibbed but basic mobs don't which is weird and inconsistent. ## Changelog 🆑 fix: fixed basic mobs not dropping their butcher results when gibbed /🆑 |
||
|
Jacquerel
|
72174845f5 |
Basic Watchers & Basilisks (#77630)
## About The Pull Request This one is a double feature because Watchers and Basilisks share the same typepath. You might see a couple more of those. As is tradition I decided to fuck with them rather than just port them. Here's what's up. **Basilisks**   - Have a new soulless sprite which looks less like a living blue hedge. - Walk at you and shoot you while you are not in range (just like before). - Become supercharged if they become "heated" by lava, lasers, or temperature weapons. This was a feature they also previously had but they would never encounter lava, so now it also works if you use the wrong gun on them. - Lose their supercharge if you cool them down. - Otherwise pretty normal mobs. **Watchers** https://www.youtube.com/watch?v=kOq_Bf78k5A Here's a traditional video of me intentionally getting hit by mechanics (trust me its definitely on purpose) - They glow emmissively a little bit so you can see them from further away. - Their eyes light up about 0.5 seconds before they are able to shoot at you. - No longer melee attack, instead try to stay out of melee. - Will occasionally put you into "Overwatch", meaning they will shoot you rapidly if you move or act while they're staring at you for a brief time period (after which you become immune for 12 seconds, and during which other watchers will play fair and stop shooting at you). - If they start taking damage they will also start using their "Gaze" attack, look away or suffer some kind of negative effect! - - Normal watcher gaze flashes and confuses you. - - Magmawing watcher gaze obviously burns (and briefly stuns) you. - - Icewing watcher gaze freezes you and throws you backwards. - Magnetically attract and eat diamonds. They also used to do this, but just if they happened to coincidentally walk past some. **Other accompanying changes** All basic mobs will now adopt the "stop gliding" trait if they get slowed down too much. I moved behaviour for "fire a projectile from this atom" into a helper proc because I was using it in three places and I will probably use it in more places. There are probably other places in the existing code which could be using this. I think I made the basic mob melee attack forecast default a little more forgiving, they were fucking me up too much and I am the playtester. ## Why It's Good For The Game Another one off the list. New tricks for old dogs. Framework for making mobs with ranged attacks "fairer" (you can see when they are ready to shoot you). More (hopefully) versatile AI behaviours which we will reuse later (I hope I'm not duplicating one someone already made). If our players "enjoy" them enough we can give more mobs "don't look at me" mechanics. Removes some soul sprites. ## Changelog 🆑 refactor: Basilisks and Watchers now use the basic mob framework. Please bug report any unusual behaviour. sprite: Basilisks have new sprites. add: Basilisks will go into a frenzy if heated by energy weapons or temperature beams as well as by lava. add: Watcher eyes will be illuminated briefly when they are ready to fire at you. add: Watchers can now briefly put you into "Overwatch" and penalise you for moving while they can see you. add: Wounded watchers will occasionally punish players who look at them. balance: Unusual watcher variants are more likely to appear. /🆑 |
||
|
MrMelbert
|
eea20b83e3 |
Kills seconds_per_tick from status effect tick, replaces it with seconds_between_ticks to clarify some things (#77219)
## About The Pull Request https://github.com/tgstation/tgstation/pull/66573#discussion_r861157216 `status_effect/proc/tick(seconds_per_tick)` is wildly misleading and I feel like I should address it For a majority of status effects, they process on fast processing but do not tick every fastprocessing tick This means that using `seconds_per_tick` here is not giving you the seconds between status effect ticks, it's giving you seconds between processing ticks (`0.2`) This is how it's misleading - If you have a tick interval of `1 SECONDS`, you'd think `seconds_per_tick` is, well, one. But it's actually one-fifth. So all of your effects are now 80% weaker. I have replaced the use of `seconds_per_tick` in tick with `seconds_between_ticks`. This number is, quite simply, the initial tick interval of the status effect divided by ten. An effect with the tick interval of `1 SECONDS` has a `seconds_between_ticks` of 1. As a consequence, some things which were inadvertently made weaker, such as fire and some heretic things (at a glance), are now a little stronger. ## Why It's Good For The Game See above. Makes it more clear what you're doing when working with effects. ## Changelog 🆑 Melbert code: Updated some status effect tick code to be more clear of how long is elapsing between ticks. Some effects that were inadvertently weakened are now stronger as a result (fire and some heretic effects). /🆑 |
||
|
Sealed101
|
cc57581b73 |
Dog wit the butter (feat. a bunch of dog-related code improvements) (#77039)
## About The Pull Request Adds a `dog_fashion` for the stick of butter.(screenshot is outdated as Lisa won't have butter no more)  Also cleans up dog.dm because it was SHIT and FUCK and MY FUCKING GOD TWO INITIALIZE()s TWO TIMES IN A SINGLE FILE WHAT IN THE GODDAMN Most noticeably, Lisa properly won't wear any hats, and puppies properly can't wear head/back items (by just removing those item slots from the strip/equip menu. if some admeme wants to fumble around they may still equip shit there. but otherwise for a normal player those slots are inaccessible). Basic mobs now also send signals when they run `appear_dead`/`appear_alive` procs, which corgis hook into to update their dead fashion overlays. The side-effect of getting that to work is that dogs (and any basic mob that uses `play_dead` ai behavior) are so good at feigning death, that they fool medical HUDs and other related things. They're just that good. There's a bunch of other things involved and I was mostly just being angry at the state of the file so I'll check back when I gather all things changed.  ## Why It's Good For The Game https://github.com/tgstation/tgstation/assets/75863639/b34589cb-94d6-4b80-bf0f-1814c08da100 ## Changelog 🆑 add: dog with a butter on 'em add: dead dog with da butter on 'em (dogs feigning death are so good at it, they appear dead to medical HUDs and other things) add: Nars-Ian now can revive from the dead if he consumes a pet fix: fixes dog fashion items with no speech modifiers set making dressed up corgis unable to perform their speech or emote behaviors fix: fixes old Ian losing his mobility ride when shaved with a razor fix: fixes pets not dropping their collar when gibbed fix: butter don't go on Lisa and corgi puppies (Lisa won't wear hats and corgi puppies can't wear hats and back slot items) /🆑 |
||
|
itseasytosee
|
88f259980b |
The Leaning Update (and Density Refractor) (#76704)
## About The Pull Request WHAT HAS CHANGED MECHANICALLY You can now lean up against walls. https://github.com/tgstation/tgstation/assets/55666666/bf81b7b5-6cab-4fc3-9887-075351511505 To lean against a wall, simply face opposite to it and drag your sprite onto it. Doing so makes you non-dense, just like if you were laying down. This means people can walk through you, but you are still susceptible to melee and ranged attacks. Leaning up against a wall also mitigates your FOV loss by 30 degrees, as you can have a better look at your surrounding when you put more of your surroundings infront of you. Because it seemed thematic to lean up against the wall while smoking and then flick a cigarette away, cigarettes will now say they where "flicked" instead of thrown when you toss them, I also took the time to add a bit of variation into the throw text. A few bugs where you could become non dense and then run straight through people has been patched. NOT PLAYER FACING So basically I've implemented a system that keeps effects that manage a mob's density consistent with eachother. An example of some of the situations that could occur Effect A would render a spaceman undense and turn the player dense again once it was concluded Effect B would render a spaceman undense and then after a timer revert the spaceman to whatever state the spaceman was in before effect B started. Thus if you enabled effect A and then Effect B, setting your previous state of denseness to undense, and then concluded effect A, when Effect B would finish it would put you back into the state of density you were in when you started. This would render the spaceman permanently undense. To solve this, the system has been updated so that all instances of density adjustment to mobs are handled by traits from unique sources (with the exception undensity gained by laying down due to its prevalence.) All effects that handle density will no longer step on each others toes and can now be rain simultaneously without fear. ## Why It's Good For The Game Leaning is cool. Bugs are bad. ## Changelog 🆑 itseasytosee add: You can now lean against walls! Simply turn your back to the wall and clickdrag yourself onto it. fix: There should no longer be any instances of spacemen being able to run straight through eachother as if they weren't even there. spellcheck: Added more variance to item throwing text. refactor: Mob density has been refactored /🆑 |
||
|
Jacquerel
|
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. /🆑 |
||
|
oranges
|
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' |
||
|
Jacquerel
|
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. /🆑 |
||
|
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. /🆑 |
||
|
Jacquerel
|
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. /🆑 |
||
|
Jacquerel
|
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. /🆑 |
||
|
Jacquerel
|
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. /🆑 |
||
|
Jacquerel
|
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. /🆑 |
||
|
Jacquerel
|
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. /🆑 |
||
|
Jacquerel
|
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 |
||
|
Fikou
|
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 /🆑 |
||
|
Fikou
|
febdb61e01 |
makes status tab use signals, thirds the delay between updates (#72002)
## About The Pull Request status panel for carbons and humans instead of hardcoding stuff, uses signals (borg material storage too) removes combat mode indicator in status tab from xenomorphs which have a button for it, but adds it to simplemobs, since they dont have a visual indicator adds status tab stuff to basic mobs, i think they were missing everything by accident offsets unique status tab stuff for all mobs by a single line the delay between updates is a third of what it was before, mainly to make shuttle timers more accurate (approved by kyler) ## Why It's Good For The Game much cleaner code, makes future implementations easy ## Changelog 🆑 qol: you can see your combat mode status as a simple or basic mob, and you can see your health as a basic mob qol: status panel updates three times as fast /🆑 |
||
|
kawoppi
|
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 /🆑 |
