mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-16 10:35:41 +01:00
observer_fix_tm
27 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
0b0c5ea91e |
Unit test material checks are now performed on all crafting recipes by default. All stack recipes now transfer mats to the results (#92620)
## About The Pull Request Extends the part of the crafting unit test that ensures consistency between the total mats of the components of a recipe (or rather, the result of said recipe) and a generic instance of the same type as its result, previously only implemented on food recipes. ## Why It's Good For The Game This ensures a degree of consistency with the material composition of various objects in the game. I couldn't do it in the original PR as that one was too big already and it took months to get it merged, and have the relative bugs fixed. Currently a WIP as I slowly deal with the unit test reports. ## Changelog 🆑 refactor: Follow-up to the crafting/material refactor from months ago. All objects crafted with stacks now inherit their mat composition (not necessarily the effects and color) by default, while previously only a few things like chair, sinks and toilets did. Report any object looking or behaving weirdly as a result. fix: The material composition of ammo boxes is no longer a 1/10 of what it's supposed to be. It was a shitty hack to make it harder to recycle empty ammo boxes. Instead, they lose materials as they're emptied now. /🆑 |
||
|
|
4f6727024d |
Crafting refactor, implementing materials (#89465)
## About The Pull Request My original plan was to just implement materials into crafting so that items would inherit the materials of their components, allowing for some interesting stuff if the material flags of the item allow it. However to my dismay crafting is a pile of old tech debt, starting from the old `del_reqs` and `CheckParts` which still contain lines about old janky bandaids that are no longer in use nor reachable, up to the `customizable_reagent_holder` component which has some harddel issues when your custom food is sliced, and items used in food recipes not being deleted and instead stored inside the result with no purpose as well as other inconsistencies like stack recipes that transfer materials having counterparts in the UI that don't do that. EDIT: Several things have come up while working on this, so I apologise that it ended up changing over 100+ files. I managed to atomize some of the changes, but it's a bit tedious. EDIT: TLDR because I was told this section is too vague and there's too much going on. This PR: - Improves the dated crafting code (not the UI). - replaced `atom/CheckParts` and `crafting_recipe/on_craft_completion` with `atom/on_craft_completion`. - Reqs used in food recipes are now deleted by default and not stored inside the result (they did nothing). - Renames the customizable_reagent_holder comp and improves it (No harddels/ref issues). - Adds a unit test that tries to craft all recipes to see what's wrong (it skips some of the much more specific reqs for now). - In the unit test is also the code to make sure materials of the crafted item and a non-crafted item of the same type are roughly the same, so far only applied to food. - Some mild material/food refactoring around the fact that food item code has been changed to support materials. ## Why It's Good For The Game Improving the backbone of the crafting system. Also materials and food code. ## Changelog 🆑 refactor: Refactored crafting backend. Report possible pesky bugs. balance: the MEAT backpack (from the MEAT cargo pack) may be a smidge different because of code standardization. /🆑 |
||
|
|
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> |
||
|
|
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
|
fec946e9c0 |
/Icon/ Folder cleansing crusade part, I think 4; post-wallening clean-up. (#85823)
Hello everybuddy, your number three rated coder-failure here to clean up some mess. This PR accomplishes some of the more major structural clean up changes I wanted to do with /obj/ folder, but decided to wait on until wallening gets merged, and so, time has come. Several things to still be done, although I know these cleaning PR's are quite a load, so will wait for this one to get done with first. ## Why It's Good For The Game Saner spriters, better sprites, less annoyance. Also deleted a whole load of redundancy this time around, a lot of sprites which existed simultaniously in two places now got exit their quantum superposition. |
||
|
|
0cc5cfb178 |
Random Name Generation refactor, generate random names based on languages (for species without name lists, like Felinids and Podpeople) (#83021)
## About The Pull Request This PR moves random name generation for species onto their languages. What does this mean? - For species with a predefined name list, such as Lizards and Moths, nothing. - For species without predefined name lists, such as Felinids, their names will now be randomly generated from their language's syllables.   (In the prefs menu:)  Why? - Well, we actually had some dead code that did this. All I did was fix it up and re-enable it. - Generates some pretty believable in-universe names for various languages that are lacking name lists. Obviously defined lists would be preferred, but until they are added, at least. - Moves some stuff off of species, which is always nice. - Also hopefully makes it a tad easier to work with name generation. There's now a standard framework for getting a random name for a mob, and for getting a random name based on a species. Misc: - Adds a generic `species_prototype` global, uses it in a lot of places in prefs code. - Makes `GLOB.species_list` init via the global defines - Deletes Language SS - Alphabetizes some instances of admin tooling using the list of all species IDs - Docs language stuff - Deletes random_skin_tone, it does pretty much nothin ## Changelog 🆑 Melbert refactor: Random Name Generation has been refactored. Report any instances of people having weird (or "Unknown") names. qol: Felinids, Slimepeople, Podpeople, and some other species without defined namelists now automatically generate names based on their primary language(s). qol: More non-human names can be generated in codewords (and other misc. areas) than just lizard names. /🆑 |
||
|
|
b5fa92d691 |
Adds Medieval Pirates (and small assault_pod change) (#82392)
## About The Pull Request (short, slightly outdated video compilation of the pirates) https://youtu.be/j9BNFzcUSjc Adds the **MEDIEVAL WARMONGERS** pirate gang, these pirates are focused on causing chaos directly on the station with the use of melee weaponry and swarming tactics. they are not very smart when it comes to using technology, so they crash in the station in an attempt to dock. the pirates spawn with the NOGUN trait as they have never used guns before but have access to dashing and the unbreakable component(small heal burst upon reaching crit). Warlord spawns with a better version of hulk(isnt removed upon crit and can still do stuff while critted) and gigantism mutation by default because ~~Chad Maximus~~ the other pirates require someone to run to when stuff like flashbangs, batons or lasers are present. The warlord spawns with a boarding axe which is a better axe that is good at destroying things and a meat hook. **there's a total of 5 pirates.** the pirate shuttle has: - thermite barrel and 3 large beakers - single weak claymore - 3 extra military spears - 3 kite shields - 3 heavy bolas - 4 regular bolas - a stack of wood - 2 stacks of mourning poultice (15 uses each) - one burn medkit **shuttle was made by striders18, big thanks to him**  things added: - the new pirate gang - a gamberson jumpsuit - crude armor (good melee and wound protection but lacks on the rest) - warlord armor (extreme protection at the cost of slowdown) - a shortsword(bootleg claymore with 30 block chance and goes on belt instead of back) - military spear (better at throwing, better wounding, deals blunt wounds instead of sharp) - axe with better damage and demolition mod for the warlord - a var to specify the name of the landing zone destination for the assaultpod - an assault pod targeting device item for the medieval shuttle - a thermite barrel - kite shields - new hulk variant that doesnt go away when crit and has tenacity ## Why It's Good For The Game I always liked the chaotic nature of the russian bounty hunters that would come from their extra numbers and lack of tools. i thought something of a similar idea on pirates would be good, a very direct and scary militia rushing in with sword and faith would create some awesome scenarios ## Changelog 🆑 add: New heavy weight pirates, medieval warmongers add: Adds military spear, shortsword, boarding axe, kite shields add: Adds warlord and crude armor add: Adds medieval shuttle (made by striders18) /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
|
6dc40ca522 |
Standardizes object deconstruction throughout the codebase. (#82280)
## About The Pull Request When it comes to deconstructing an object we have `proc/deconstruct()` & `NO_DECONSTRUCT` Lets talk about the flag first. **Problems with `NO_DECONSTRUCTION`** I know what the comment says on what it should do https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/__DEFINES/obj_flags.dm#L18 But everywhere people have decided to give their own meaning/definition to this flag. Here are some examples on how this flag is used **1. Make the object just disappear(not drop anything) when deconstructed** This is by far the largest use case everywhere. If an object is deconstructed(either via tools or smashed apart) then if it has this flag it should not drop any of its contents but just disappear. You have seen this code pattern used everywhere https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/game/machinery/constructable_frame.dm#L26-L31 This behaviour is then leveraged by 2 important components. When an object is frozen, if it is deconstructed it should just disappear without leaving any traces behind https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/datums/elements/frozen.dm#L66-L67 By hologram objects. Obviously if you destroy an hologram nothing real should drop out https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/modules/holodeck/computer.dm#L301-L304 And there are other use cases as well but we won't go into them as they aren't as significant as these. **2. To stop an object from being wrenched ??** Yeah this one is weird. Like why? I understand in some instances (chair, table, rack etc) a wrench can be used to deconstruct a object so using the flag there to stop it from happening makes sense but why can't we even anchor an object just because of this flag? https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/game/objects/objs.dm#L368-L369 This is one of those instances where somebody just decided this behaviour for their own convenience just like the above example with no explanation as to why **3. To stop using tools to deconstruct the object** This was the original intent of the flag but it is enforced in few places far & between. One example is when deconstructing the a machine via crowbar. https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/game/machinery/_machinery.dm#L811 But machines are a special dual use case for this flag. Because if you look at its deconstruct proc the flag also prevents the machine from spawning a frame. https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/game/machinery/_machinery.dm#L820-L822 How can 1 flag serve 2 purposes within the same type? **4. Simply forget to check for this flag altogether** Yup if you find this flag not doing its job for some objects don't be surprised. People & sometimes even maintainers just forget that it even exists https://github.com/tgstation/tgstation/blob/b5593bc6930cb60803214869a7b94c84e7baa02c/code/game/objects/items/piggy_bank.dm#L66-L67 **Solution** These are the main examples i found. As you can see the same flag can perform 2 different functions within the same type and do something else in a different object & in some instances don't even work cause people just forget, etc. In order to bring consistency to this flag we need to move it to the atom level where it means the same thing everywhere. Where in the atom you may ask? .Well, I'll just post what MrMelbert said in https://github.com/tgstation/tgstation/pull/81656#discussion_r1503086862 > ...Ideally the .deconstruct call would handle NO_DECONSTRUCTION handling as it wants, Yup that's the ideal case now. This flag is checked directly in `deconstruct()`. Now like i said we want to give a universal definition to this flag and as you have seen from my examples it is used in 3 cases 1) Make an object disappear(doesn't dropping anything) when deconstructed 2) Stop it from being wrenched 3) Stop it from being deconstructed via tools We can't enforce points 2 & 3 inside `deconstruct()` which leaves us with only case 1) i.e. make the object disappear. And that's what i have done. Therefore after more than a decade or since this flag got introduced `NO_DECONSTRUCT` now has a new definition as of 2024 _"Make an object disappear(don't dropping anything) when deconstructed either via tools or forcefully smashed apart"_ Now i very well understand this will open up bugs in places where cases 2 & 3 are required but its worth it. In fact they could even be qol changes for all we know so who knows it might even benefit us but for now we need to give a universal definition to this flag to bring some consistency & that's what this PR does. **Problem with deconstruct()** This proc actually sends out a signal which is currently used by the material container but could be used by other objects later on. https://github.com/tgstation/tgstation/blob/3e84c3e6dad33c831ac259f52f2f023680e4899b/code/game/objects/obj_defense.dm#L160 So objects that override this proc should call its parent. Sadly that isn't the case in many instances like such https://github.com/tgstation/tgstation/blob/3e84c3e6dad33c831ac259f52f2f023680e4899b/code/game/machinery/deployable.dm#L20-L23 Instead of `return ..()` which would delete the object & send the signal it deletes the object directly thus the signal never gets sent. **Solution** Make this proc non overridable. For objects to add their own custom deconstruction behaviour a new proc has been introduced `atom_deconstruct()` Subtypes should now override this proc to handle object deconstruction. If objects have certain important stuff inside them (like mobs in machines for example) they want to drop by handling `NO_DECONSTRUCT` flag in a more carefully customized way they can do this by overriding `handle_deconstruct()` which by default delegates to `atom_deconstruct()` if the `NO_DECONSTRUCT` flag is absent. This proc will allow you to handle the flag in a more customized way if you ever need to. ## Why It's Good For The Game 1) I'm goanna post the full comment from MrMelbert https://github.com/tgstation/tgstation/pull/81656#discussion_r1503086862 > ...Ideally the .deconstruct call would handle NO_DECONSTRUCTION handling as it wants, but there's a shocking lack of consistency around NO_DECONSTRUCTION, where some objects treat it as "allow deconstruction, but make it drop no parts" and others simply "disallow deconstruction at all" This PR now makes `NO_DECONSTRUCTION` handled by `deconstruct()` & gives this flag the consistency it deserves. Not to mention as shown in case 4 there are objects that simply forgot to check for this flag. Now it applies for those missing instances as well. 2) No more copying pasting the most overused code pattern in this code base history `if(obj_flags & NO_DECONSTRUCTION)`. Just makes code cleaner everywhere 3) All objects now send the `COMSIG_OBJ_DECONSTRUCT` signal on object deconstruction which is now available for use should you need it ## Changelog 🆑 refactor: refactors how objects are deconstructed in relation to the `NO_DECONSTRUCTION` flag. Certain objects & machinery may display different tool interactions & behaviours when destroyed/deconstructed. Report these changes if you feel like they are bugs /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
|
5627e3f1e9 |
Makes heads on pikes render correctly. (#79863)
## About The Pull Request Fixes #59037. This PR makes heads on pikes actually appear properly offset so that they're impaled on the spike instead of halfway down the shaft. In addition, the heads will actually appear on the correct layer, rather than sometimes being rendered on the _UI layer._ This means they will not inexplicably be visible to blind players.  ## Why It's Good For The Game Judging from the screenshots in the PR that added these six years ago, this has actually _never_ looked correct. For the first time, this makes heads on pikes actually look like they're meant to, rather than having way too much of the spear shoved out the top of the head. Also, fixes a fairly egregious rendering error that makes blind people see mysterious heads in the void. ## Changelog 🆑 fix: Heads impaled on spears now render in the correct place on the tip, instead of halfway down the shaft. fix: Blind personnel are no longer able to magically see heads impaled on spears from a distance. /🆑 |
||
|
|
1be27a4ffe |
Dunking handle_atom_del() in the trash bin. (#77339)
Whatever you do, if it warrants the use of something like `handle_atom_del`, chances are `Exited` can do it better, as most of these cases involve movables that shouldn't be moved out of their loc (`Destroy` forcefully moves movables to nullspace) without calling specific procs, and for the remaining few, `handle_atom_del` doesn't even cover the eventuality of a movable being deleted outside the source atom, so it's quite garbage. Beside, I feel confident in saying `handle_atom_del()` is older than the DCS, an echo on the workarounds done at the time. |
||
|
|
5725bd4967 |
Headpikes now use proper grammar when referencing their spear type (#72626)
## About The Pull Request When creating a name for the headpike structure, the spear name is now used, rather than just a reference to the spear itself. This led to funky grammar and ruined immersion etc etc. ## Why It's Good For The Game Closes #72583. ## Changelog 🆑 spellcheck: Head-spears are now named properly when using alternate spear types. /🆑 |
||
|
|
6a447bc3a0 |
Head pikes now drop their mounted heads upon destruction (#70720)
* wow this doesnt look right * better idea |
||
|
|
6f72388da1 |
fixes headspike runtime error and bug (#68040)
* fixes headspike runtime error and bug * requested change * Revert "requested change" This reverts commit ab3aefa180ff32cee00c16b8baed3db1fe1b1fb0. * Revert "fixes headspike runtime error and bug" This reverts commit ed1f76e88b709064df0dbde655ca618ddbb78b3d. * actual fix |
||
|
|
16729429ab |
Bamboo Overhaul (Port of Beestation Hornet #5703) (#64027)
Adds several new bamboo items + sprites |
||
|
|
861bf808bc |
Fixes a few hard deletes and runtimes I either caused, or ran into when trying to fix hard deletes (#61953)
Please don't try and send chat messages if you have nothing to say Fixes a spurious runtime. Fixes a runtime caused by my lack of understanding of huds. remove_hud_from is intended for hud watchers, remove_from_hud is intended for hud items. Doesn't really make sense most of the time, and just runtimes out the ass Fixes a runtime in shapeshifting, restore should not run if the object is not restoring, or if it's deleting. it should run if it's not restoring, and it's not deleted. 4head Fun fact, if there's two turret control boards they'll override each other. Use weakrefs. Oh also removes a var called cp, nothing good will come of that Today in: Good lord the stacking machine is an afront to god, we discover that the labor claims console was attempting to act as a console, which of course fails when it comes time to clear it's improperly named var. Disgusting Attempts to fix potential wound ref hangs in surgeries? maybe? Fixes a runtime in luminescent stuff I created in my big harddel crusade. owner is a mob, not a species Fixes a runtime related to headspikes deleting themselves twice. Pain Fixes hard deletes sourced from the prophet trauma. Good fucking lord this is awful Offhand item is somehow hard deleting. I have no idea how. Here's hoping signals fixes it, because if it doesn't I'm stumped. It's not a common scenario, but it does happen in spurts that suggest repeated usage |
||
|
|
375a20e49b |
Refactors most spans into span procs (#59645)
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs. Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines. Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing. Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc. (Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such) |
||
|
|
e4079c87b8 |
update_appearance (#55468)
Creates update_name and update_desc Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together Less non-icon handling code in update_icon and friends Signal hooks for things that want to change names and descriptions 99%+ of the changes in this are just from switching everything over to update_appearance from update_icon |
||
|
|
5c22a0cfc1 |
Converts many proc overrides to properly use list/modifiers, lots of other smaller things (#56847)
Converts many proc overrides to properly use list/modifiers, fixes some spots where modifiers should have been passed, calls modifiers what it is, a lazy list, and cleans up some improper arg names like L, M, C, and N. Oh and I think there was a spot where someone was trying to pass M.name in as a string, but forgot to wrap it in []. I fixed that too. |
||
|
|
9977571adc |
fixed it (#55615)
headspikes don't give you a random head when you deconstruct them (except when maploaded) also they look like they were supposed to with the head impaled |
||
|
|
ef6fc627a6 | Fixes mapspawned headpikes | ||
|
|
15452cac44 |
[READY] Two Handed Component (#49422)
About The Pull Request For an item to be two handed just add this handy component. All existing two handed items have been converted to use this component. Why It's Good For The Game It has components and signals, and now you can make items two handed so simply. /obj/item/shockpaddles/ComponentInitialize() . = ..() AddComponent(/datum/component/two_handed) |
||
|
|
26093e5ac2 |
Further update_icon splitup (#48784)
* Further update_icon splitup After this there'll be just under 100 old update_icon() calls that need fixing. * Thanks Travis |
||
|
|
bca492823a |
Runtime fixes: Episode 113 (#48814)
* Fixes mood nanite settings * Fixes yet another quirk runtime. * Ugly paperplane fix * Abductor armor runtime. * cablecutting runtime * Nukeop death runtime (were those spec deaths meant to fire on gibbing too ? ) * headpike runtime fix * ERT outfit runtime * bonfire oxygen runtime * Rest of nanite updates |
||
|
|
259ebdcc5d |
makes bonespear a child of spear and MAKES THE DAMAGE MORE CONSISTENT (#46467)
* who did this * boner * a * a * hhhhhhhhhhhhhhhhhhhhh * a * a * Update recipes.dm * hhhh |
||
|
|
74c8498c08 |
[Ready]Gives ashwalkers an antag datum (#44396)
* welp * Savages, savages, barely even human. * Savages, savages, barely even human * You didn't see this * h * bee gone * FFS, I mixed up my... ugh * savage * removed test line * Turns ashwalkers into antags * fuck * hjjg * fixes stupid * g * h2 * Damn... * There we go? * If it compiles, we can ship it * Forgot the actually remove the thingy |
||
|
|
f300a5c155 | Interaction/Attack Hand Refactor (#36405) | ||
|
|
5b9eeb8935 |
Adds adorning spears with heads (#33955)
* get spiked, son * bonespear variant * cyberboss changes + pixel shifting * Move 👏 overlay 👏 calls 👏 to 👏 update 👏 icon * git yer head on a pike here, 25 cents * ignore that .gitignore * variable change * changes n stuff * may of forgotten that bit * moved vars up + drop_location() * null the nulls |