mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-28 23:58:07 +01:00
master
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
d3d3a12540 |
The big fix for pixel_x and pixel_y use cases. (#90124)
## About The Pull Request 516 requires float layered overlays to be using pixel_w and pixel_z instead of pixel_x and pixel_y respectively, unless we want visual/layering errors. This makes sense, as w,z are for visual effects only. Sadly seems we were not entirely consistent in this, and many things seem to have been using x,y incorrectly. This hopefully fixes that, and thus also fixes layering issues. Complete 1:1 compatibility not guaranteed. I did the lazy way suggested to me by SmArtKar to speed it up (Runtiming inside apply_overlays), and this is still included in the PR to flash out possible issues in a TM (Plus I will need someone to grep the runtimes for me after the TM period to make sure nothing was missed). After this is done I'll remove all these extra checks. Lints will probably be failing for a bit, got to wait for [this update](https://github.com/SpaceManiac/SpacemanDMM/commit/4b77cd487d0a7b6a069df20356b701af5b20489d) to them to make it into release. Or just unlint the lines, though that's probably gonna produce code debt ## Why It's Good For The Game Fixes this massive 516 mess, hopefully. closes #90281 ## Changelog 🆑 refactor: Changed many of our use cases for pixel_x and pixel_y correctly into pixel_w and pixel_z, fixing layering issues in the process. /🆑 --------- Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: SmArtKar <master.of.bagets@gmail.com> |
||
|
MrMelbertandGitHub
|
eb0e842320 |
Hallucination revamps and additions (#89865)
## About The Pull Request 1. Hallucination effects are now tiered Hallucinations now all have tiers, ranging from common to special. If you are just hallucinating a teeny bit, you will not experience the more extreme hallucinations, like bubblegum or your mom. But if you're hallucinating off your butt, you will be a bit more likely to experience them. 2. Hallucination rate has been tweaked Default hallucination cooldown is now 20-80 seconds, up from 10-60 seconds. However the cooldown will *also* vary depending on just how much you're hallucinating, going down to 10-40 seconds. 3. RDS is now capped a bit lower (meaning you don't see the higher tiers like bubblegum). But I added a preference to uncap it. For the people who actually like bubblegum visits. 4. If a hallucination fails to trigger, the cooldown will partially reset. (by 75%) 5. "Fake chat" hallucination will pick more viable subjects. Fake chat will try to find someone who can actually speak your language, rather than make a monkey speak mothic or something. (I may revisit this so if you're super-hallucinating it reverts to old behavior though.) 6. Adds a hallucination: Fake blood You hallucinate that you start bleeding, very simple. 7. Adds a hallucination: Fake telepathy You hallucinate a random telepathic message, similar to fake chat. 8. Adds a hallucination: Eyes in the Dark A nearby dark turf will have a set of glowing red eyes shine through the dark. A classic. 9. Adds some new sub-hallucination: PDA ringtone (fake sound), summon guns/magic (fake item) Funny prank. 10. Makes mindbreaker a bit more effective at combating RDS. Pretty much does nothing right now unless you gulp like 50u. ## Why It's Good For The Game Hallucinations are pretty one note if you experience them for longer than 10 minutes. This is due to two fold: - Many hallucinations are goofy, and not subtle - Hallucinations trigger very rapidly You will never fall for a hallucination because in between "You see John Greytide put the blueprints away", you get your mom yelling at you, everyone looking like syndies (again), and bubblegum This pr addresses it by - Limiting the wacky hallucinations for when you're really off your gourd - Reducing the period between triggers - Adding a few hallucinations If the wackier hallucinations are reserved for when you're really off your rocker, this lets the more subtle ones sink in over time, leaves more room for second guessing ## Changelog 🆑 Melbert add: Adds 4-5 new hallucinations. Collect them all. balance: If you are only hallucinating a little bit, the game will prefer to pick more subtle hallucinations. If you are hallucinating a ton, it will prefer the more wacky hallucinations. balance: If you are only hallucinating a little bit, the cooldown between hallucinations is longer. If you are hallucinating a ton, it will be shorter. balance: If a hallucination fails to trigger (such as a deaf person getting a sound hallucination) the next one will be a lot sooner. balance: RDS hallucination amount is capped at mid tier hallucinations. This means bubblegum and co. will be a lot rarer, or will even never show. HOWEVER, there is now a preference allowing you to uncap your RDS hallucinations. balance: Mindbreaker toxin is more effective at suppressing RDS. balance: Some hallucinations effects have been tweaked up or down according to the new thresholds. Madness mask as an example. fix: "Fake Fire" Hallucination works again, and now has a unique message for if you stop-drop-roll that other people see. /🆑 |
||
|
|
cbc3350224 |
Custom Shuttles Redux: Allows for the construction of custom shuttles. (#88493)
## About The Pull Request This incredibly detailed PR adds the ability to construct custom shuttles, which function similarly to whiteships. To construct a custom shuttle, you need the following items: - Shuttle frame rods These rods can be hand-crafted by using 5 rods on 1 sheet of titanium, or printed at a sci/engi/cargo lathe after researching the Shuttle Engineering techweb node. Lattices built with these rods, and catwalks/floors built on top of these lattices, are valid for shuttle construction. - Shuttle engines Did you know shuttle engines have boards that weren't normally obtainable? Well the board for one specific engine type is now available from the sci/engi/cargo lathe after researching Shuttle Engineering. Of course, the old options remain. You can steal engines from other shuttles, including escape pods (it's not like engines are strictly necessary for *those* shuttles anyways). Alternatively, the shuttle engine supply pack is no longer locked behind the purchase of the BYOS. - Flight Control & Navigation Console boards These boards are printed at the sci/engi/cargo lathe after researching the Shuttle Engineering techweb node. If built on a custom shuttle, it will automatically link to it, unless the shuttle already has such a console. If built on a turf that is valid for custom shuttle construction, it will automatically link to any shuttle constructed from or expanded with that turf. - Shuttle blueprints Standard shuttle blueprints can be printed at the sci/engi/cargo lathe after researching the Shuttle Engineering techweb node. A cyborg upgrade granting access to a shuttle blueprint database can be printed at the exofab after researching the aforementioned node. Crude shuttle blueprints can be crafted by hand with a sheet of paper and either a rainbow crayon or 10 uses of a blue crayon or spraycan. If Science won't research the tech, you can also buy a goody pack containing a flight control board, a docker board, two engine boards, and a set of shuttle blueprints for 1200 credits, if you have aux base access. A shuttle can be constructed atop any continuous region of turfs containing a shuttle rod lattice or a catwalk/tile built upon such. Currently, this region cannot intersect any area other than space, lavaland, the icemoon, or the station asteroid. Preexisting custom areas can be included in the construction of the shuttle, but only if every turf in the custom area is valid for shuttle construction. In the shuttle blueprint UI, you can toggle a visualizer to display which turfs fulfill all of the aforementioned conditions. The following video goes through the basic process of shuttle construction. https://github.com/user-attachments/assets/3283422e-a201-4978-972d-67527b5df4ee The blueprint used to construct the shuttle will be its master blueprint. The master blueprint can be copied to other blank shuttle blueprints (or to engiborgs with the shuttle database upgrade), and allows the holder to perform a christening ritual on the shuttle to rename it. If a shuttle's master blueprint ceases to exist, a blank blueprint can be linked to the shuttle to become the new master blueprint, or an existing blueprint associated with that shuttle can be promoted to the master blueprint. Once constructed, the following options are available from the blueprint UI to modify it: - Create Area Convert a continuous open area of the shuttle into a new area with the name written in the above text input. This operates very similarly to regular area construction. - Rename Area Change the name of the area you're currently in to the name written in the above text input. - Expand Area Add a continuous open area of the shuttle to the neighboring area selected from the dropdown to the left. This operates like regular area expansion. - Expand Shuttle Expand a shuttle with valid frame turfs as defined above. These turfs must be physically connected to the shuttle. - Remove Area Remove an area, giving its tiles to the default shuttle area. - Cleanup Empty Space (implemented after the above video was recorded) Removes all completely empty turfs from the shuttle. If all the turfs in one of the shuttle's areas were removed, that area is deleted. If absolutely no turfs of the shuttle remain, the shuttle itself is deleted. Due to the ability for this action to delete the shuttle, only the master blueprint can do it. As mentioned above, the shuttle's master blueprint can be used to christen its associated shuttle. To do this, fill a glass drink bottle with some amount of reagents, then hit it against one of the shuttle's walls from outside while holding the master blueprint. You will be prompted to enter a new name for the shuttle. The variety of things that can happen while inputting a new name can cause the christening rite to fail in one of several humorous ways. ### Optional (Unless specifically requested by a maintainer) Todo's - [x] A way for shuttle circuits to be obtainable without techweb nodes - [x] A more convenient way to carry around shuttle engines or the means to deploy them - [ ] A shuttle construction guide available as a reference book - [ ] Allow boards to be linked to shuttles before construction so they can be used outside the shuttle ## Why It's Good For The Game Shuttles have been part of the sandbox for an incredibly long time, but their limited accessibility has rendered them the exclusive territory of lucky space explorers or the few antagonists who get one off the bat (nukies and pirates). Giving players the means to construct shuttles to their liking opens up a variety of possibilities for gimmicks for antags and non-antags alike. Besides the applications for antaggery and crew-sided gimmicks, this provides side content for several departments to engage with during the relatively-frequent periods of time where they have little else to do as part of their intended roles. With respect to engineering, if the station isn't actively being damaged, the supermatter is in perfect working order, and nobody is clamoring for machine upgrades, engineers have little else to resort to other than construction projects. While the BSA station goal provides an incentive for engineers to construct dedicated rooms for the cannon, it will not necessarily be available every round. Custom shuttles not only provide such a construction project to pursue, but provide the rare opportunity, as well as a very good reason, to set up an independent power network, complete with its own power source. While atmos techs have a lot to do with gas mixing and the crystallizer, they rarely get the opportunity to set up working life support systems outside of repairing the ones that get blown up. Custom shuttles will frequently start with no air, and unless the design settled upon is an open floor plan, it will have several independent chambers that cannot so easily be profused with a proper airmix by just opening a canister. Furthermore, if the air in a custom shuttle gets messed up, a proper scrubber and distro network is a significantly less tedious method of rectifying the problem than cleaning the air manually with portable scrubbers and pumps. Scientists, it can be argued, with their access to RPDs through ordnance, have similar opportunities to atmos techs, even though the act in and of itself is not exactly part of their duties. But compared to the other job content they could be working with after they've completed most of their gameplay loop, custom shuttle construction is a substantially more active endeavor. And I know how much people complain about late-game science content just being sitting around at a console and making gamer gear. Roboticists can have a part to play in this too. They can put their mech RCDs to a use other than 2D topdown Fortnite, and with the shuttle database upgrade, they can help interested cyborgs get in on the action. Cargo is yet another department known for having significant amounts of downtime during a considerable number of rounds. If every other department has gone through their initial rounds of departmental orders, and there isn't an active need for cargo to order lots of one thing or another, cargo techs have little to do besides mail (at least on the days where there **is** mail to deliver). Usually, if cargo techs do, in fact, do something as a department when not presented with more pressing duties, they order guns and other contraband. As funny as this is, there's not a lot of variety in how this behavior manifests. With custom shuttles, cargo can use their free time to plan, and execute, a unique collective expression of design sensibilities, not limited by the size and shape constraints of the cargo bay itself. ## Changelog 🆑 Y0SH1_M4S73R (with special thanks to Vect0r, whose original PR inspired the implementation of these changes) add: Shuttle blueprints, the tool used to construct and modify custom shuttles. Print a set at a science, engineering, or cargo techfab after researching Shuttle Engineering, or craft a crude set from the crafting menu. add: Shuttle blueprint database upgrade for engineering cyborgs, printable from the Exosuit Fabricator after researching Shuttle Engineering. A version of shuttle blueprints designed for use by cyborgs. add: Shuttle frame rods, usable to construct custom shuttles. Hand-craft by using 5 rods on 1 titanium sheet, or by printing them at a science, engineering, or cargo techfab after researching Shuttle Engineering. add: Custom shuttle flight control and navigation boards, printable from a science, engineering, or cargo techfab after researching Shuttle Engineering. add: Shuttle engine boards can be printed from a science, engineering, or cargo techfab after researching shuttle engineering. add: The shuttle engine supply pack is no longer locked behind the purchase of the Build Your Own Shuttle kit. add: Shuttle Construction Starter Kit goodie pack, containing a set of shuttle blueprints, flight control and navigation console boards, and two engine boards, can be purchased from cargo for 1200 credits. Requires aux base access to purchase. refactor: Shuttles now keep track of what areas are underneath each of their individual turfs, so that the areas left behind on movement are consistent with what they were beforehand. refactor: Shuttle ceilings now place themselves down as baseturfs, instead of only appearing if the turf above is open space. /🆑 --------- Co-authored-by: vect0r <71346830+Vect0r2@users.noreply.github.com> Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> Co-authored-by: necromanceranne <40847847+necromanceranne@users.noreply.github.com> |
||
|
larentounandGitHub
|
692540a7b9 |
Singularity_pull() standartize (#87304)
## About The Pull Request Previous attempt - https://github.com/tgstation/tgstation/pull/87227 `/atom/proc/singularity_pull(obj/singularity/singularity, current_size)` has first arg typed, but other procs were just referencing it as a un-typed variable. Since args are not standartized AND `atom/proc/singularity_pull(obj/singularity/singularity, current_size)` is out-dated, since it can be called by things that has `/datum/component/singularity` - not just by `obj/singularity/singularity` - This PR just adds args to every `proc/singularity_pull()` as follows: `proc/singularity_pull(atom/singularity, current_size)` ## Why It's Good For The Game Standartization ## Changelog No changelog needed |
||
|
LemonInTheDarkandGitHub
|
ae5a4f955d |
Pulls apart the vestiges of components still hanging onto signals (#75914)
## About The Pull Request Signals were initially only usable with component listeners, which while no longer the case has lead to outdated documentation, names, and a similar location in code. This pr pulls the two apart. Partially because mso thinks we should, but also because they really aren't directly linked anymore, and having them in this midstate just confuses people. [Renames comp_lookup to listen_lookup, since that's what it does](https://github.com/tgstation/tgstation/commit/102b79694fa8eb57ecf7b36032616a9e368ccced) [Moves signal procs over to their own file](https://github.com/tgstation/tgstation/commit/33d07d01fd336726b4f6f6f1b61bb0b3f11a00dc) [Renames the PREQDELETING and QDELETING comsigs to drop the parent bit since they can hook to more then just comps now](https://github.com/tgstation/tgstation/commit/335ea4ad081ec63c42cfa05856e582cca833af6e) [Does something similar to the attackby comsigs (PARENT -> ATOM)](https://github.com/tgstation/tgstation/commit/210e57051df63f88dac3dd83321236da825aae5e) [And finally passes over the examine signals](https://github.com/tgstation/tgstation/commit/65917658fb8a1e7d28ae23c9437a583d646f0302) ## Why It's Good For The Game Code makes more sense, things are better teased apart, s just good imo ## Changelog 🆑 refactor: Pulled apart the last vestiges of names/docs directly linking signals to components /🆑 |
||
|
|
4d6a8bc537 |
515 Compatibility (#71161)
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
|
||
|
ShizCalevandGitHub
|
7d47ca37ce | Fixes hallucination destroy runtime (#70512) | ||
|
LemonInTheDarkandGitHub
|
23bfdec8f4 |
Multiz Rework: Human Suffering Edition (Contains PLANE CUBE) (#69115)
About The Pull Request I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.) This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering. I'll do my best to keep this compact, but there's only so much I can do. Sorry brother. Core idea OK: first thing. vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc. This is bad. But how to do better? It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly. We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed. But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect. Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on). That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly. Everything else is just gravy. About the Plane Cube Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane. We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live. As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well. Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you. About Plane Master Groups BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc) Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc. So we need to maintain a mirror of each plane for every map we have open. This was quite messy, so I've refactored it (and maps too) to be a bit more modular. Rather then storing a list of plane masters, we store a list of plane master group datums. Each datum is in charge of the plane masters for its particular map, both creating them, and managing them. Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to. Much better then the hardcoded pattern we used to use. So much duplicated code man. Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers. image In addition, I've added a debug ui for plane masters. It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays. It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live. In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc. It also comes with an info dump about the ui, and plane masters/relays in general. Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible. See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md. "Landing" planes Ok so I've explained the backend, but how do we actually land planes properly? Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use. This is just a lot of gruntwork, but it's occasionally more complex. Sometimes we need to cache a list of z layer -> effect, and then use that. Also a LOT of updating on z move. So much z move shit. Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags. This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday I also need to update mob overlays on move. I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order. The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet. It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point. Behavior changes We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it. So instead we display the other side as a ui element. It's worse, but not that bad. Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior. The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane. I don't really care, but it should be fixable, I think, given elbow grease. Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think. Why It's Good For The Game <visual candy> Fixes #65800 Fixes #68461 Changelog cl refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb /cl |
||
|
MrMelbertandGitHub
|
6baebf47a1 |
Completely refactors hallucinations, and also adds a few (#69706)
* Refactors hallucinations slightly, organizes them * Refactors hallucination into a status effect * Further hallucination proper refactoring * Refactors battle hallucinations * Refactors "fake item other" hallucination * Gets it a bit closer to working state * Refactors screwydoll and fake alerts * Refactors fake inhand items * Refactors a few more. - Fake death - Fake messages - Fake sounds - Projectiles * Refactoring delusions, hallucination effects * Furthering the hallucination status effect - removes copypaste of hallucination pulses * Almost finalizes the changeover to status effect * Last staus effect stuff * Delusion business * Airlocks, fire, and more delusion stuff * Finishes screwyhud. It compiles now! * Swaps screwyhud over to a grouped status effect * Removes hal_screwyhud * Comment * Bugfixing * image cleaning * Get rid of this it came back * What if I finished this branch? * Oops * Messing with the randomness * Mass hallucination tweaks * + * Some more mass tweaks * Review * Updates * Unit tests hallucination icons * More tweaks * Move folder * Another re-name * Minor tweaks * Anomaly unity * Mass hallucination buffs * t * Sig * Merge * Lints * Unit test already coming in clutch * Another failure * Use named args for cause_hallucination via some define trickery * Some cleanup * This is better * adds some hallucinations * Oops * More sounds * Tweaks * Some additional documentation * Flash * Fixes mass hallucination * Json changes * Updates documentation * Json conflicts * Makes it work * Missed that one too * Helpers * More signalization (WIP) * Fixes bump * Missed a helper use * Dumb |
||
|
skylord-a52andGitHub
|
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.
|
||
|
KyleraceandGitHub
|
fe7513d282 | addresses reviews on the tram pr made after merge, fixes diagonal movement bugs (#68033) | ||
|
TimandGitHub
|
7f92d9a0de |
Move and split hallucination code to module (#67642)
* Move hallucination code to module * Remove Hallucination.dm |