mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-06-06 06:40:42 +01:00
ed94de4ddf7edad8694badefc577392e0f762bf5
16 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
f1c6d9d15e |
Fix bileworm runtime targeting non-living mobs (#76201)
## About The Pull Request Targeting datums will target non-living movables which have livings inside, such as mechas. So this casting to living as a bad assumption. ## Changelog 🆑 Melbert fix: Fix runtimes from Bileworms targeting mechas (or other objects people are hiding in) /🆑 |
||
|
|
ed2f04f486 |
Experiment with replacing weakrefs in AI blackboard with deleting signals, ideally making it easier to work with and harder to cause hard deletes (#74791)
## About The Pull Request Replaces weakref usage in AI blackboards with deleting signals All blackboard var setting must go through setters rather than directly ## Why It's Good For The Game This both makes it a ton easier to develop AI for, and also makes it harder for hard deletes to sneak in, as has been seen with recent 515 prs showing hard deletes in AI blackboards (To quantify "making it easier to develop AI", I found multiple bugs in existing AI code due to the usage of weakrefs.) I'm looking for `@Jacquerel` `@tralezab` 's opinions on the matter, also maybe `@LemonInTheDark` if they're interested ## Changelog 🆑 Melbert refactor: Mob ai refactored once again /🆑 |
||
|
|
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' |
||
|
|
bf6f81a9b5 |
Implements AddTraits and RemoveTraits procs for adding/removing multiple traits + swag unit test (#74037)
On the tin, doing it like this means we can reduce our overall line fingerprint whenever we have to add two or more traits from the same source on the same target. Especially helps when we get to the 4+ range of traits, a breath of fresh air even. Doesn't mean we have to do for loops, as that's already handled within the define as well. I replaced some of the checks with `length()` checks, let me know if I should switch it over to something else (maybe `islist()`)? We stack_trace whenever we're not passed a list reference on purpose, and sometimes var/lists are null by default (or just empty, making this redundant). ## Why It's Good For The Game I commonly feel the urge to write "use `AddTraits()`" or something in reviews, then am sad when I remember it doesn't exist. I will no longer be sad. Can ensure a lot more trait safety as well by using static lists- when both ADD_TRAIT_LIST and REMOVE_TRAIT_LIST re-use the same list, you are confident (from a static point of view) that everything that you want to be adding/removing works. I may have missed a few things where this could be used, but both macros implemented in this PR still use the same framework that was being used in the last four years- so stuff won't break if left untouched. Just a nifty new tool for developers. also fixed up some code in the area, numerous bugs were found and exploded |
||
|
|
3bc0c13b54 |
Fixes some incorrect uses of rand() (#74032)
## About The Pull Request `Rand` only takes integers   ## Why It's Good For The Game Less misleading code ## Changelog 🆑 Melbert fix: Lead batteries now start partially drained as intended. /🆑 |
||
|
|
50b37c8c7f |
Faction defines (#73681)
## About The Pull Request Quite a lot of mobs had faction defines as a string, which always has a chance for error. For example, the clown mob spawner had their faction written as "clown", when the official faction name was "clowns", and a define existed for it anyways! This PR moves every single string based factions over here. No references or special role factions. Hopefully I didn't miss anything. I also moved a global define used for picking your uplink provider's flavour to the only file that used it, datum_traitor.dm, and renamed them a bit to avoid confusion. I have also noticed that the mimic faction was assigned to the petrified player with += instead of |=. |= would ensure no duplicate factions, so I have changed it. Future improvement: I have noticed that there is a lot of bloat with factions that contain only one or two entries (examples: gnomes, floating eyeballs, penguins, the pet lizards), and some always appear in pairs (vines and plants, the rare exceptions being killer tomatoes and strange reagent spawned pine trees), but trimming consolidating them is a matter for a different time. ## Why It's Good For The Game Makes assigning factions a bit less error prone. I can finally remove the ```/// Later all mob factions will be moved here and their current factions replaced with faction defines.``` comment. Later is NOW. ## Changelog Nothing player facing |
||
|
|
ab307032ed |
Nightvision Rework (In the name of color) (#73094)
## About The Pull Request Relies on #72886 for some render relay expansion I use for light_mask stuff. Hello bestie! Night vision pissed me off, so I've come to burn this place to the ground. Two sections to discuss here. First we'll talk about see_in_dark and why I hate it, second we'll discuss the lighting plane and how we brighten it, plus introducing color to the party. ### `see_in_dark` and why it kinda sucks https://www.byond.com/docs/ref/#/mob/var/see_in_dark See in dark lets us control how far away from us a turf can be before we hide it/its contents if it's dark (not got luminosity set) We currently set it semi inconsistently to provide nightvision to mobs. The trouble is stuff that produces light != stuff that sets luminosity. The worst case of this can be seen by walking out of escape on icebox, where you'll see this  Snow draws above the lighting plane, so the snow will intermittently draw, depending on see_in_dark and the luminosity from tracking lights. This would in theory be solvable by modifying the area, but the same problem applies across many things in the codebase. As things currently stand, to be emissive you NEED to have a light on your tile. People are bad at this, and honestly it's a bit much to expect of them. An emissive overlay on a canister shouldn't need an element or something and a list on turfs to manage it. This gets worse when you factor in the patterns I'm using to avoid drawing lights above nothing, which leads to lights that should show, but are misoffset because their parent pixel offsets. It's silly. We do it so we can have things like mesons without just handing out night vision, but even there the effect of just hiding objects and mobs looks baddddddd when moving. It's always bothered me. I'll complain about mesons more later, but really just like, they're too bright as it is. I'm proposing here that rather then manually hiding stuff based off distance from the player, we can instead show/hide using just the lighting plane. This means things like mesons are gonna get dimmer, but that's fine because they suck. It does have some side effects, things like view() on mobs won't hide stuff in darkness, but that's fine because none actually thinks about view like that, I think. Oh and I added a case to prevent examining stuff that's in darkness, and not right next to you when you don't have enough nightvision, to match the old behavior `see_in_dark` gave us. Now I'd like to go on a mild tangent about color, please bare with me ### Color and why `lighting_alpha` REALLY sucks You ever walk around with mesons on when there's a fire going, or an ethereal or firelocks down. You notice how there isn't really much color to our lights? Doesn't that suck? It's because the way we go about brighting lighting is by making everything on the lighting plane transparent. This is fine for brightening things, but it ends up looking kinda crummy in the end and leads to really washed out colors that should be bright. Playing engineer or miner gets fucking depressing. The central idea of this pr, that everything else falls out of, is instead of making the plane more transparent, we can use color matrixes to make things AT LEAST x bright. https://www.byond.com/docs/ref/#/{notes}/color-matrix Brief recap for color matrixes, fully expanded they're a set of 20 different values in a list Units generally scale 0-1 as multipliers, though since it's multiplication in order to make an rgb(1,1,1) pixel fullbright you would need to use 255s. A "unit matrix" for color looks like this: ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 ) ``` The first four rows are how much each r, g, b and a impact r, g, b and well a. So a first row of `(1, 0, 0, 0)` means 1 unit of r results in 1 unit of r. and 0 units of green, blue and alpha, and so on. A first row of `(0, 1, 0, 0)` would make 1 red component into 1 green component, and leave red, blue and alpha alone, shifting any red of whatever it's applied to a green. Using these we can essentially color transform our world. It's a fun tool. But there's more. That last row there doesn't take a variable input like the others. Instead, it ADDS some fraction of 255 to red, green, blue and alpha. So a fifth row of `(1, 0, 0, 0)` would make every pixel as red as it could possibly be. This is what we're going to exploit here. You see all these values accept negative multipliers, so we can lower colors down instead of raising them up! The key idea is using color matrix filters https://www.byond.com/docs/ref/#/{notes}/filters/color to chain these operations together. Pulling alllll the way back, we want to brighten darkness without affecting brighter colors. Lower rgb values are darker, higher ones are brighter. This relationship isn't really linear because of suffering reasons, but it's good enough for this. Let's try chaining some matrixes on the lighting plane, which is bright where fullbright, and dark where dark. Take a list like this ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, -0.2, -0.2, -0.2, 0 ) ``` That would darken the lighting a bit, but negative values will get rounded to 0 A subsequent raising by the same amount ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0.2, 0.2, 0.2, 0 ) ``` Will essentially threshold our brightness at that value. This ensures we aren't washing out colors when we make things brighter, while leaving higher values unaffected since they basically just had a constant subtracted and then readded. ### But wait, there's more You may have noticed, we gain access to individual color components here. This means not only can we darken and lighten by thresholds, we can COLOR those thresholds. ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0.1, 0.2, 0.1, 0 ) ``` Something like the above, if applied with its inverse, would tint the darkness green. The delta between the different scalars will determine how vivid the color is, and the actual value will impact the brightness. Something that's always bothered me about nightvision is it's just greyscale for the most part, there isn't any color to it. There was an old idea of coloring the game plane to match their lenses, but if you've ever played with the colorblind quirk you know that gets headachey really fast. So instead of that, lets color just the darkness that these glasses produce. It provides some reminder that you're wearing them, instead of just being something you forget about while playing, and provides a reason to use flashlights and such since they can give you a clearer, less tinted view of things while retaining the ability to look around things. I've so far applied this pattern to JUST headwear for humans (also those mining wisps) I'm planning on furthering it to mobs that use nightvision, but I wanted to get this up cause I don't wanna pr it the day before the freeze. Mesons are green, sec night vision is red, thermals orange, etc. I think the effect this gives is really really nice. I've tuned most things to work for the station, though mesons works for lavaland for obvious reasons. I've tuned things significantly darker then we have them set currently, since I really hate flat lighting and this system suffers when interacting with it. My goal with these is to give you a rough idea of what's around you, without a good eye for detail. That's the difference between say, mesons, and night vision. One helps you see outlines, the other gives you detail and prevents missing someone in the darkness. It's hard to balance this precisely because of different colored backgrounds (looking at you icebox) More can be done on this front in future but I'm quite happy with things as of now ### **EDIT** I have since expanded to all uses of nightvision, coloring most all of them. Along the way I turned some toggleable nightvision into just one level. Fullbright sucks, and I'd rather just have one "good" value. I've kept it for a few cases, mostly eyes you rip out of mobs. Impacted mobs are nightmares, aliens, zombies, revenants, states and sort of stands. I've done a pass on all mobs and items that impact nightvision and added what I thought was the right level of color to them. This includes stuff like blobs and shuttle control consoles As with glasses much of this was around reducing vision, though I kept it stronger here, since many of these mobs rely on it for engaging with the game <details> <summary> Technical Changes </summary> #### Adds filter proc (the ones that act like templates) support to filter transitions. Found this when testing this pr, seemed silly. #### Makes our emissive mask mask all light instead This avoids dumbass overlay lighting lighting up wallmounts. We switch modes if some turfflags are set, to accomplish the same thing with more overhead, and support showing things through the darkness. Also fixes a bug where you'd only get one fullscreen object per mob, so opening and closing a submap would take it away Also also fixes the lighting backdrop not actually spanning the screen. It doesn't actually do anything anymore because of the fullscreen light we have, but just in case that's unsued. Needs cleanup in future. #### Moves openspace to its own plane that doesn't draw, maxing its color with a sprite This is to support the above We relay this plane to lighting mask so openspace can like, have lighting #### Changes our definition of nightvision to the light cutoff of night vision goggles and such Side affect of removing see_in_dark. This logic is a bit weak atm, needs some work. #### Removes the nightvision spell It's a dupe of the nightvision action button, and newly redundant since I've removed all uses of it #### Cleans up existing plane master critical defines, ensures trasnparent won't render These sucked Also transparent stuff should never render, if it does you'll get white blobs which suck </details> ## Why It's Good For The Game Videos! (Github doesn't like using a summary here I'm sorry) <details> Demonstration of ghost lighting, and color https://user-images.githubusercontent.com/58055496/215693983-99e00f9e-7214-4cf4-a76a-6e669a8a1103.mp4 Engi-glass mesons and walking in maint (Potentially overtuned, yellow is hard) https://user-images.githubusercontent.com/58055496/215695978-26e7dc45-28aa-4285-ae95-62ea3d79860f.mp4 Diagnostic nightvision goggles and see_in_dark not hiding emissives https://user-images.githubusercontent.com/58055496/215692233-115b4094-1099-4393-9e94-db2088d834f3.mp4 Sec nightvision (I just think it looks neat) https://user-images.githubusercontent.com/58055496/215692269-bc08335e-0223-49c3-9faf-d2d7b22fe2d2.mp4 Medical nightvision goggles and other colors https://user-images.githubusercontent.com/58055496/215692286-0ba3de6a-b1d5-4aed-a6eb-c32794ea45da.mp4 Miner mesons and mobs hiding in lavaland (This is basically the darkest possible environment) https://user-images.githubusercontent.com/58055496/215696327-26958b69-0e1c-4412-9298-4e9e68b3df68.mp4 Thermal goggles and coloring displayed mobs https://user-images.githubusercontent.com/58055496/215692710-d2b101f3-7922-498c-918c-9b528d181430.mp4 </details> I think it's pretty, and see_in_dark sucks butt. ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and it's effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 add: The darkness that glasses and hud goggles that impact your nightvision (think mesons, nightvision goggles, etc) lighten is now tinted to match the glasses. S pretty IMO, and hopefully it helps with forgetting you're wearing X. balance: Nightvision is darker. I think bright looks bad, and things like mesons do way too much balance: Mesons (and mobs in general) no longer have a static distance you can see stuff in the dark. If a tile is lit, you can now see it. fix: Nightvision no longer dims colored lights, instead simply thresholding off bits of darkness that are dimmer then some level. /🆑 |
||
|
|
7c30d9d746 |
Basic Wumborian Fugu & Fugu Gland (#73415)
## About The Pull Request Fixes #72677 and also converted the "Wumborian Fugu" mob to a basic mob rather than a simple one. I will be totally honest: I didn't need to do that in order to fix the bug. I just didn't like looking at the rest of the code in that file. Also I have some kind of sickness which makes me do this. This ended up being one of those "see something related and fix it as well" ones so there's a couple of only tangentially related changes in here. If you want me to split it up I will but I think this one is _probably_ fine because the wide-ranging changes are pretty simple ones? So what this PR does is: - Refactors simple mob into basic mob. - Cleans up its really ugly ability to work in a hopefully nicer way. - A one line fix to the linked issue above. - Modifies the default cooldown on `basic_melee_attack` and `attack_obstructions` to be a widely used cooldown rather than a random value used by no mob that we have. - Renamed behaviour "try_mob_ability" to "targeted_mob_ability" and added a new AI behaviour called "use_mob_ability", the difference between the two being that the former requires a target and the latter does not. I... don't actually use this because I realised after adding it that I still want a target for this mob, but someone will need it eventually. - Change everywhere that is passing references to abilities to actions to pass weak references instead. - Adds an element to handle "spawn this stuff when a related mob dies". - Found a few places where people were setting `environment_smash ` as if it did anything (including me) and replaced them with the proper ai_controller implementation instead, updated the comment to make it clearer although that won't prevent copy/paste errors. - Registered to the "movement speed updated" signal to ensure that basic mobs actually notice that you have applied a movement speed modifier. ## Why It's Good For The Game Fixes a linked issue. Refactors some code which made me sad whenever I saw it. Restores some mob behaviour which nobody noticed was missing, but was. Fixes some apparently unreliable code I added in a recent PR reliant on basic mobs using movespeed modifiers. Adds element we will definitely need again in the future. ## Changelog 🆑 fix: The Fugu Gland can once more be used on Ian, Carp, Giant Spiders, or other basic mobs. fix: Syndicate mobs will once again attack windows to try to reach you, and space ruin spiders won't. fix: Netherworld-themed mobs will correctly adjust their speed as they take damage. refactor: Made the Wumborian Fugu into a basic mob, which should act largely the same way but may have slightly different speed and reaction times. /🆑 |
||
|
|
0818d6ae4c |
Crafting/Cooking menu update (#71779)
## About The Pull Request Updated crafting menu, adding a lot of new functions and recipes that were not in the crafting menu before. <img alt="cult" src="https://user-images.githubusercontent.com/3625094/206009533-aec3a1dd-cbe5-45eb-8515-1b75fabb65c5.PNG"> <img alt="nH77dLyyGx" src="https://user-images.githubusercontent.com/3625094/206009786-b6706f70-0599-40bf-b051-8f499de43abd.png">  https://user-images.githubusercontent.com/3625094/206009841-738e4a03-0660-45b7-8d83-15eeb6501967.mp4 ## Why It's Good For The Game It is easier to use, and it has a lot of recipes that were spread throughout the game, some of which weren't even on the wiki. Crafting and cooking now count about 1200 recipes in total, including conditionally available ones. ## Changelog 🆑 qol: Rewrote the crafting/cooking menu UI qol: Split crafting and cooking menus in two different menus qol: Crafting is no longer blocking the entire UI, only the "Make" buttons are disabled qol: Added stack crafting recipes to the crafting menu qol: Added cooking recipes that were absent in the crafting menu before (tool recipes, machine recipes, reactions) qol: Added option to search recipes by title qol: Added option to filter recipes by required materials/ingredients qol: Added food types to the cooking menu, highlighting diet of your species (liked, disliked foods) qol: Added total nutrition value of the result to the cooking menu qol: Added option to filter cooking recipes by the food type of the resulting food qol: Added "Can make" category that lists all currently craftable recipes throughout all categories refactor: changed categories and reshuffled some items in them code: Reagents now have default container to get an icon from the reagent datum code: Objects now have `desc_controls` var for OOC information about mouse controls that are visible on examine, but not in the description fix: Fixed alignment on many food icons fix: Fixed missing icon for beef stroganoff /🆑 Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> |
||
|
|
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 /🆑 |
||
|
|
1ac2779ef8 |
Bileworm Health Patch: Evolutionary Leap, Vileworms, Proximity Spawning Rules, Better Loot (#70321)
* bileworm health patch - bileworms start off easier - vileworms are how they are now + a little tougher - fixes bileworms breaking proximity spawn rules - adds gold to bileworm loot * ssticker * diagonals readded to attacks\, map fix * d-delete this * Update evolutionary_leap.dm * DONE |
||
|
|
1a32f60cf4 |
[ready] adds unit test for missing inhand icons. fixes a bunch of missing inhand icons (#70037)
fix: Fixed a bunch of missing inhand icons. fix: Fixed cables in electrical toolboxes not randomizing their colors. fix: Fixed the wrong colored icon showing when trying to make cable cuffs out of cables. fix: The collectable SWAT helmet is now using the proper icon again! refactor: Pipecleaners and power cables now share a unified color system, so they're once again available in ALL the same colors. imageadd: Updated the screwdriver belt overlay to represent the newer sprite. imageadd: Added a bunch of new inhand icons. Special thanks to Twaticus for doing the helmets! <3 fix: Wirecutters now have an icon when inside a belt again! admin: Added a new omnitool subtype that allows you to spawn all items in a typepath! fix: Explorer gaskmasks now properly reflect their adjusted state when held. fix: Fixed balaclavas having the wrong icon when pulled up. fix: Fixed the base energy sword (admin spawn only) being invisible. fix: The rainbow energy sword is now a little bit more rainbowy! fix: Fixed an tk exploit with orange handcuffed shoes. fix: The traitor outfit in the select equipment panel is now actually functional! |
||
|
|
974a56b720 |
Fixes bileworms being unable to act (#69874)
* Makes bileworm AI use weakrefs for targets * Apply suggestions from code review * Update code/datums/ai/basic_mobs/basic_ai_behaviors/try_mob_ability.dm * question mark Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com> |
||
|
|
be0e6efdf6 |
[IDB IGNORE] [MDB IGNORE] Makes the icons/mob folder sane (#69302)
About The Pull Request
Reorganizes the entire icons/mob folder.
Added the following new subfolders:
nonhuman-player (this was initially just called "antag", but then I realized guardians aren't technically antags)
simplemob
silicon
effects (for bloodstains, fire, etc)
simplemob/held-pets (for exactly that -- I wasn't sure if this should go in inhands instead)
species/monkey
Moves the following stuff:
All human parts moved into species, with moth, lizard, monkey, etc parts moved to corresponding subfolders. Previously, there were some moth parts in mob/species/moth, and others just loose in mob. Other species were similar.
icemoon, lavaland, and jungle folders made into subfolders of simplemob
All AI and silicon stuff, as well as Beepsky et al. into the silicon folder, simplemobs into the simplemob folder, aliens into the nonhuman-player folder, etc.
Split up animal_parts.dmi into two bodyparts.dmi which were put in their respective folders (species/alien and species/monkey)
Code changes:
Filepath changes to account for all of this
Adds a check when performing surgery on monkeys and xenos, because we can no longer assume their limbs are in the same file
Turns some hardcoded statues and showcases that were built into maps into objects instead
Things I'd like to do in the future but cant be assed right now:
Remove primarily-antag sprites from simplemob/mob.dmi (Revenant, Morph, etc.) and put them in the nonhuman-player folder
Split up mutant_bodyparts.dmi into different files for Tizirans, Felinids, monkeys, etc and put them in their own folders. Those may have once been meant primarily for mutated humans but that's now how they're being used right now.
|
||
|
|
4e97d03657 |
Bileworm post-merge feedback and qol (#69007)
* Bileworm now has a deathsound, and deathsounds now properly play on simplemobs. * AI-controlled Bileworms now have night vision abilities |
||
|
|
0728fb3840 |
New Lavaland Monster: Bileworms (#68967)
Bileworms are a new lavaland monster, that has unique AI that should prove them. Instead of moving normally, it periodically burrows underground and resurfaces nearby. Its attack is an AOE acid spit. |