143 Commits

Author	SHA1	Message	Date
SmArtKar	16015775ff	ORM now displays your mining point balance instead of your bank account balance (#93557) ... ## About The Pull Request I don't think that the payout is in credits, chief. ## Why It's Good For The Game This is pretty clearly an oversight, as it only makes sense if its meant to display the balance to which your payout will be added ## Changelog 🆑 fix: ORM now displays your mining point balance instead of your bank account balance /🆑	2025-10-23 00:36:19 +02:00
SyncIt21	5d6982bb08	ORM's smelt ores correctly when inserted by hand/bag (#92991) ... ## About The Pull Request - Fixes #92989 ## Changelog 🆑 fix: ORM's smelt ores correctly when inserted by hand/bag /🆑	2025-09-17 00:58:58 +02:00
Ghom	c274677cfd	glass ore (aka sand) is now actually made of sand (#92889) ... ## About The Pull Request sand blocks existed for the only purpose of making sand available as a material. However, the only method to get them was pretty whimsical and the existence of the feature wasn't really conveyed to the player, which involves rinsing regular sand in a sink... and before you ask, we also have sandstone, which can be crafted just by using the sand in hands, no water involved. In fact, the sand blocks use the same sprites for regular sandstone, except they have no recipes associated to them, nothing! Nada! Let's address the elephant in the room: We already have sand, however said sand already has the glass material attached to it even before being smelted, so if you put sand into the Autolathe, you get glass, yay. Sand blocks really only existed to make up for the shortcoming of whoever coded the sand material at the time. But enough ranting. As the title says, sand is now made of sand, sand blocks are kill. I've been careful enough to give the ORM the ability to smelt gathered sand into glass beforehand, so miners won't curse me for making them _actually_ use the smelter for once, "I will rather die to a goliath than have anything to do with that". However, this still means you cannot shove sand directly into lathes and expect glass out of it. Get a welder. ## Why It's Good For The Game ## Changelog 🆑 balance: sand is now made of sand and not glass. Get a welder if you plan to shove it into a protolathe. del: Removed now useless sand blocks. /🆑	2025-09-09 15:08:45 -04:00
mcbalaam	ab1136909c	Improves the ore silo UI (#92460) ... ## About The Pull Request Improves the ore silo UI, continuing https://github.com/tgstation/tgstation/pull/91142 Before: <img width="760" height="336" alt="image" src="https://github.com/user-attachments/assets/06c2f628-ea05-49be-88ed-9947ffc55254" /> After: <img width="626" height="604" alt="image" src="https://github.com/user-attachments/assets/d6a501be-425f-44ba-b75a-c238e20b06fe" /> All sources of silo material withdrawal are now consistent with naming to get properly color coded, which helps with looking for stuff. ## Why It's Good For The Game Better UI readability, more consistent logs ## Changelog 🆑 qol: Color coded and consistent material silo logs /🆑 --------- Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>	2025-09-02 18:55:12 -07:00
Joshua Kidder	988ca0b482	Ore silo logging & access refactor; UI updates, single-target bans, more robust logging information, more robust access control (#91142) ... ## About The Pull Request # More robust logging ## Ore silo logs have now been refactored in the UI to display: - Number of sheets is now the relative unit when displaying a given log. - Instead of `100 iron` being displayed when removing one sheet, it just says `1 iron` - Instead of `25 iron` being displayed when using a quarter sheet, it just says `0.25 iron` - All information from ID_DATA(log_user) now sent to tgui backend - The items rendered to ore silo users are: - Name on ID, job on ID - If the ID's bank account (if one is registered) is one of the ore silo's banned users - If the user for a given entry was wearing a chameleon card, they will always appear unbanned - NOTE: The bank account ID # is (currently) not shown to players using the ore silo. - Full log information is rendered within a dropdown; the dropdown one-liner shows - Action (deposit, eject, item created) - Amount (deposit/eject? amount of material used. item created? number of items created.) - Either name of material (if deposit/eject) or the name of items crafted - The name of the user who performed a given operation (if wearing an unbanned ID) or ID_READ_FAILURE (if ore silo ID requirement has been disabled and the person is not wearing an ID) - As name, but instead, the job of the ID (or ID_READ_FAILURE)  # Access control improvements ## Single-user bans - Anyone with QM access (not silicons) can now ban/unban a user from a given log from using the ore silo - Bans are associated to bank account IDs. - Wearers of chameleon cards bypass any ban restrictions. - Anyone with QM access on their worn card bypasses ban restrictions. - Silicons bypass ban restrictions. - QM access requirement is removed if the ore silo is emagged. - Silicons can ban/unban people if the ore silo is emagged. ## Worn ID requirement - Enabled at roundstart, can be disabled by anyone with QM access (not silicons) - If enabled, you must be wearing an ID with a bank account associated to it to use ore silo materials. - Wearers of chameleon cards bypass this restriction (so-called ID requirement free thinkers wearing chameleon ID cards) - QM access requirement to toggle removed if emagged. - Silicons can toggle this on/off if the ore silo is emagged. # Access control radio notifications ## Access control operations reported on the radio - Any operations for access control are reported on radio channels. - Currently, the policy is always the default. - In the future, the ore silo UI will allow the quartermaster to modify what operations are reported on what channels (petty QM broadcasting ban reports on Common) - Current default policy: - Reported on COMMON channel: - Anyone but the Captain attempts to ban someone with QM access from the ore silo (nice try dumbass) - Ore silo ID requirement toggling - Reported on COMMAND channel: - Common channel reports. - Per-user banning/unbanning. - Anyone without QM access attempts to ban/unban someone. - Anyone without QM access attempts to toggle the restriction for ID. - Silicons attempting to tamper with the ID requirement restriction - Silicons attempting to tamper with the ban/unbanned user list - A ban attempt failing because a given log entry had a user with no bank ID. - Reported on SECURITY channel: - Common channel reports. - Per-user banning/unbanning. - Anyone without QM access tampering with the silo. - Reported on SUPPLY channel: - Command channel reports. - Reporting to the radio is disabled if the ore silo is emagged. ## Modifications to the remote_materials component - Strictly encompass the behavior for connecting/disconnecting ore silos to material receptacles (RCDs, machines, etc) into procs on the component, instead of handling it all over the place ## Why It's Good For The Game Gives people with ore silo access more fine grained control over ore silo use without having to resort to heavy-handed fabricator lockouts Makes the logging on the ore silo more robust so we can make sure we kill the right Roboticist for using all the materials Offers an avenue for sidestepping all of this with a chameleon card or emag if a given traitor (organic or otherwise) is particularly opposed to DRM mats. https://github.com/user-attachments/assets/effd2c63-509c-4d33-992f-837a0d62b935 ## Changelog 🆑 Bisar add: The ore silo has had a significant expansion to its logging capabilities. add: The ore silo now allows any ID with Quartermaster access (NOT SILICONS!) to ban/unban specific users from the silo. add: The ore silo now has a toggle (on by default) that a user of ore silo materials has an ID with an associated bank account. This can be toggled by anyone with Quartermaster access (NOT SILICONS!) add: NanoTrasen discounts any reports that Syndicate contraband (cryptographic sequencer, agent card) can be used to circumvent any protocols instituted on the ore silo access control routines. add: The ore silo now announces operations to ban/unban users and enable/disable ID requirements on radio channels (check the Github for actions reported to what channels.) add: The tgui interface for ore silo log entries has been reworked. refactor: The code for logging a given access to ore silo materials has been significantly refactored. qol: Ore silo log entries now display materials spent in terms of sheets rather than the obfuscated absolute-units previously display (1 iron ejected instead of -100 iron, 0.25 used in a craft instead of -25 iron) /🆑	2025-07-26 22:17:51 -07:00
Waterpig	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>	2025-03-28 14:18:45 +00:00
Lucy	f4a077c6fe	Refactors some more UIs to use DmIcon (#87886) ... ## About The Pull Request Upstream port of https://github.com/Monkestation/Monkestation2.0/pull/4215 This changes some tgui UIs that used icon2base64/getFlatIcon to display items to instead use DmIcon, just passing the icon/icon_state instead. To be specific: the ORM, the "ore container", and the order console (produce, mining, and bitrunning vendors) <details> <summary><h3>UI screenshots / proof of testing</h3></summary>      </details> ## Why It's Good For The Game gfi bad, especially in ui(_static)_data, dmicon good. ## Changelog 🆑 refactor: The ORM, "ore container", and order console UIs (produce, mining, bitrunner vendors) now load icons in a more efficient manner. /🆑	2024-11-14 19:10:22 +01:00
John Willard	1880003270	Reworks silicon/ai access checking & fixes some ui_act's (#84964) ... ## About The Pull Request Currently to check for Silicon access, we do: ``if is silicon or is admin ghost or has unlimited silicon privileges or has machine remote in hand`` What has unlimited silicon privileges? Bots, Drones, and admin ghosts. To check for AI access, it just checks for AI instead of silicon, and doesnt check for unlimited silicon privileges. This was kinda silly, so I thought I should make this a little easier to understand. Now all silicon/ai traits come from ``AI_ACCESS_TRAIT`` or ``SILICON_ACCESS_TRAIT``. I made a single exception to keep Admin ghost, since now instead of being a var on the client, we moved it to using the same trait but giving it to the client instead, but since we have to keep parity with previous functionality (admins can spawn in and not have this on, it only works while as a ghost), I kept previous checks as well. No more type checks, removes a silly var on the mob level and another on the client. Now while I was doing this, I found a lot of tgui's ``ui_act`` still uses ``usr`` and the wrong args, so I fixed those wherever I saw them, and used a mass replace for the args. Other changes: - machinery's ``ui_act`` from https://github.com/tgstation/tgstation/pull/81250 had ``isAI`` replaced with ``HAS_AI_ACCESS``, this has been reverted. Machine wands and admin ghosts no longer get kicked off things not on cameras. This was my fault, I overlooked this when adding Human AI. - Human AI's wand gives AI control as long as it's in your hand, you can swap to your offhand. I hope this doesn't end up going horribly, otherwise I'll revert this part. It should let human AIs not have their UI closed on them when swapping to eat food or use their door wand or whatnot. - Bots previously had special checks to scan reagents and be unobservant, I replaced this with giving them the trait. I also fixed an instance of unobservant not being used, so now statues don't affect the basic creature, whatever that is. ## Why It's Good For The Game This is an easier to understand way of handling silicon access and makes these mobs more consistent between eachother. Other than what I've mentioned above, this should have no impact on gameplay itself. ## Changelog 🆑 fix: Statues don't count as eyes to creatures. fix: Human AIs and Admin ghosts no longer get kicked off of machines that aren't on cameranets. /🆑	2024-08-19 10:43:45 +00:00
Jeremiah	8e3f635b98	Alt click refactor (#82656) ... ## About The Pull Request Rewrites how alt click works. Based heavily on #82625. What a cool concept, it flows nicely with #82533. Fixes #81242 (tm bugs fixed) Fixes #82668 <details><summary>More info for devs</summary> Handy regex used for alt click s&r: `AltClick\((.*).*\)(\n\t.*\.\.\(\))?` `click_alt($1)` (yes I am aware this only copies the first arg. there are no other args!) ### Obj reskins No reason for obj reskin to check on every single alt click for every object. It applies to only a few items. - Moved to obj/item - Made into signal - Added screentips ### Ventcrawling Every single atmospherics machine checked for ventcrawling capability on alt click despite only 3 objects needing that functionality. This has been moved down to those individual items. </details> ## Why It's Good For The Game For players: - Alt clicking should work more logically, not causing double actions like eject disk and open item window - Added context menus for reskinnable items - Removed adjacency restriction on loot panel For devs: - Makes alt click interactions easier to work with, no more click chain nonsense and redundant guard clauses. - OOP hell reduced - Pascal Case reduced - Glorious snake case ## Changelog 🆑 add: The lootpanel now works at range. add: Screentips for reskinnable items. fix: Alt click interactions have been refactored, which may lead to unintentional changes to gameplay. Report any issues, please. /🆑	2024-04-16 17:48:03 -06:00
ArcaneMusic	002051a3d5	ArcMining Pr Beta: Version 1.2 (#78524) ... This one's not like the last one, so much so that I'm not even going to outsource the PR description to a robot this time! Basically, **You should read the PR body before assuming that everything is the same as last time. It's not.** ## Video Summary Click the link below to see a video summary of the main features of this pull request. https://youtu.be/Aho2omR0mjY?feature=shared ## About The Pull Request This pull request serves as a large rework of minerals produced by mining, and by extension mining itself. I'll try and list each change and it's associated nuance here. ### Ore Vents The biggest addition to the game with ArcMining is **Ore Vents**. Ore vents spawn as a ruin on the map, placing a randomized ore vent onto map generation. Ore vents spawn in 3 different sizes, **Small, Medium, and Large**. These vents will pick from a pool of materials they can generate, and will hang out across the map. A player can use a mining scanner to discover an ore vent, granting a small quantity of **mining points** to begin with. Once scanned, ore vents will show what minerals that ore vent will generate after they're fully tapped. Scanning the vent again will trigger the extraction process. A small drone will fly down, called the NODE drone, and buckle onto the vent. Your job during wave defense is to protect the drone and to defeat waves of randomly spawning mobs (dependent on if you're on lavaland or on icebox). The quantity, duration, and time between waves is scaled to the size of the vent you're protecting. Starting by scanning and protecting lower tier vents earlier in the shift is a safer bet than doing a large vent in the first few minutes. The drone has 500 health, and can take a good few hits, but leaving it alone will cause it to meet an unfortunate end quite quickly. Cooperation can be your best asset, as mining with allies can greatly help with wave defense, and mineral points are granted to anyone who helps with defending the ore vent equally (So 500 * size tier, regardless of how much help you receive). Once complete, the ore vent will have a mining machine constructed on top of it, and will start to dredge up **Boulders** from the earth automatically. More on boulders later. Ore vents can be located based on your mining scanner, and will provide an appropriate audio cue based on if the ore vent has been discovered or not, and once processed will no longer alert you to it's presence. **Each station comes with a free vent that produces exclusively iron and glass, free of charge.** This is to help with shifts where the station may not have shaft miners to produce minerals, and to provide the station with a baseline amount of minerals where none may exist otherwise. ### Mineral Generation Mineral generation has been completely reworked. Previously, Mineral Generation had a flat 13% spawn rate in-game. Once minerals spawned, they would also have a chance to propagate their minerals to nearby tiles, resulting in a rather massive pool of minerals that could spawn throughout lavaland on the whole. This tweaks that, by making minerals in walls spawn based on their proximity to ore vents on maps that use cave generation. Both the probability, and quantity of ores spawning in walls is scaled based on distance, with ore vents looking like large caches of ores found in walls. This makes following ores found in walls and checking their quantity of minerals spawned a good indicator of how close you are to a nearby vent in-round. This means you can collect some points form both discovering ore vents first, as well as collecting their surrounding ores, turn those in for mining points, and then trading them in for gear upgrades to more effectively take on ore vents. As a result of tweaking the balance of this, the total amount of ores spawned in walls overall has been decreased. However, by making more of the process time based, we still result in a mostly balanced finished product. ### Boulder Processing On station, there are now three new machines. These are the BRM, the Refinery, and the Smelter. - The BRM acts as a teleporter. Instead of needing to carry boulders back to the station, you can activate the BRM, and it will automatically pick boulders to teleport back to itself. You can use this to teleport boulders dredged up from lavaland onto the station for processing. **The BRM will only lock on to boulders that are resting on an ore vent.** Moving boulders back by hand will mean you'll have to haul it back by hand. - The refinery processes the non-metallic materials out of boulders. This process sends the materials straight to the ORM, and collects mining points from the ores smelted in the machine. Swiping with an ID card lets you withdraw those points for your own personal account, but remember that these points are for your whole team to share from. The **Mining points obtained from this process is only 75% of the amount an equivalent amount of ores would provide.** - The smelter works nearly identically, however the smelter produces metallic materials out of boulders instead. - Once a boulder has had all of it's materials extracted, it's broken down and deleted from the line. Otherwise, the boulder is spat out for the next machine to process it (either the refinery or smelter). - Once there's no minerals left in a boulder of any type, the refinery or smelter will break the boulder down. - Boulders **do not stack onto tiles with each other**, so they'll block each other when pulled or when moving on a conveyor belt. Boulders can also be processed by hand. Using a mining tool on a boulder with right click will allow you to break down a boulder into it's composite ores, but limits you to a maximum of 10 ore per boulder, where the full amount can be extracted using the proper processing machines. Also, processing by hand does deal small amounts of stamina damage over time, do breaking a full large boulder can be particularly taxing. Additional Boulder Processing Machines can be built, with the BRM board being obtained from the Protolathe, while the Smelter and Refinery boards being obtainable from the Autolathe instead. A _boulder processing beacon_ can also be obtained from the mining points vendor as a reward to assist with boulder processing. Boulder processing beacons can be used to spawn in a new BRM, refinery, and smelter on the tile the user is standing on, however **you'll still need to link them to the ORM**! All three machines can be upgraded with Stock Parts, allowing for **more boulders to be processed at a time**. It does not, however, increase the amount of minerals received from boulders, or points earned. ### Mining Borg Tweaks Mining borgs have been given some minor adjustments to compensate for the changes to mining. Their mineral scanner, which now has an active component to gameplay, is now a module as opposed to built into the mob. This module allows for the same ability to discover and start waves of monsters to fight. Mining modules will find that their PKA now has a total of 90% mod capacity as compared to the 80% they had before, to allow for more robust defense of ore vents. In addition, all borgs and AIs can interact with the BRM for boulder collection. ### Mining Mech Tweaks Mining Mechs have had their utility tweaked as a result of these changes as well. Mineral scanners to be used on mining mechs now have a larger radius by comparison to their handheld cousins. Similarly, it now has an active scanning button, which will actively discovery nearby ore vents. To begin wave defense, you will need to hop out and scan a second time however, so that you can properly accept the risks of drawing a horde of bloodthirsty wildlife towards you and your companions. Mechs can also manually process boulders, similar to mining tools using their drill. ### Golem Tweaks Golems, being more gentle and less aggressive than humans, while being made out of LITERAL ROCKS, have a greater need to secure access to ores and minerals to eat. As such, they have adapted to be able to do two new things: - Golems may now right click ore vents to be able to manually haul a boulder out of the vent. This costs a hefty amount of stamina, but it allows for golems to avoid combat during regular gameplay. - Golems may now left click a boulder with an open hand in order to manually process a boulder like a pickaxe. While not faster, it is consistent and prevents golems from starving if they have access to a vent, but no ores, somehow. ### Gulag Tweaks The labor camp, being a camp for rehabilitation and ~~excessive manual labor~~ has been tweaked. Boulders now replace the random minerals located on their island, and to acquire their prizes inside, much be excavated and then broken out of the rock. Now YOU TOO can excavate minerals and become a true mineral hero by working your way to freedom. ### Mining Point Changes As a result of fewer mining points being available across the map due to the new ore spawning mechanics, and the shift in how and when ores will be coming in, almost every progress based mining point cost has been reduced by around 10-20%. Many numbers are still subject to change at present, but the idea is that core progress unlocks should be made a bit more available earlier in the round before players can start to solo or duo larger or more difficult ore vents, after which they'll be rolling in ores. ### Rarities Every once in awhile, an unusual boulder will get hauled up from the mineral rich depths of lavaland. These **Artifact boulders** can occasionally produce rare items, but for now they've mostly just been pulling up **Strange objects** for science. Nanotrasen Natural Sciences department will reward you extra points to be collected by boulder processing machines for successfully extracting one. In the future, this opens up a passive reward space that mining can reward to the station, like providing cytology DNA samples, ancient seeds, or other artifacts. ### Misc notes - Boulders can be stored in all varieties of ore boxes (ground, mech) should you choose, however as mentioned it's best to leave them where they spawn and teleport them to the station for convenience. - Maps that are not subject to cave generation will find that they are largely untouched in terms of mineral balance. - Future or existing ruins can now be tweaked to have a mineral balance cost, as the ore vent ruin does. This will allow us to spawn in more interesting ruins for pre-made combat challenges. - There are unique ore vents that spawn across the map, that will summon a boss mob relevant to that map. If the boss mob is defeated, that vent will spawn large boulders pulling from every possible ore type that can spawn. Not for the faint of heart! - Similarly, the number of ore vents and mineral budget is now adjustable in the cave generation procs, so maps may spawn with more or less ore vents as desired for balance. - Artifact boulders opens up a LOT of room for possible future content like archaeology, xenoarch, artisci, and other design spaces! - Megafauna STILL SPAWN ON THE MAP. They just happen to spawn in addition to boss ore vents. - **I'll add more to this as I get asked questions and remember things, this is a huge PR and I'm confident I've missed at least something** ## Why It's Good For The Game I outlined a lot of this in #78040, so I'll try and keep this relatively snappy this time, while noting that I've made some concessions to make the whole system a lot more playable while not trying to break out design decisions that are at the end of the day, better for the game and the overall resource balance in round. Minerals are a very poorly balanced system, and have been since their inception many years ago. We heavily rely on mineral balance in round, and yet we've really only balanced it by introducing so much supply that there's no equivalent exchange for materials that doesn't just heavily flood the exchanged material. For example, items printed from materials that are otherwise considered "rare" on master exist in such quantities and they'll never practically run out in our allotted 90 minute time slot design. This PR adjusts how ores spawn to a point where we can minimize the amount of ores that need to exist on the map for mining to be able to progress, while still providing enough resources for the station that it covers the needs of the station adequately. Miners will need to be more strategic about what resources they've collected, and be able to make decisions about which vents are worth the risk of attempting to fight, how to prepare for a wave defense, and when to head back up for upgrades, while finally giving them at least some kind of incentive to work together and use different equipment. Resonators make cleaning up the caves around vent easy, sandbags set up easy defenses for your vent, mechs can serve as a wider range radar while mining, all while still providing a new gameplay loop to mining. By limiting the amount of ores that can enter the round from the massive, massive amounts that were coming into the round beforehand (see #78346 ), we can make ore processing more meaningful by adding more gameplay to the processing of minerals. I have some plans for that, however this PR already got bloated really REALLY badly due to scope creep and the number of intersecting systems that rammed into each other to make this PR possible. So that'll be next. Plus, as I've mentioned, we open up places for ore processing to find fossils, relics, and other things that can implemented down the line. Overall, I don't expect this PR to save or kill ore balance, but we gain a LOT more control over it through the use of our mining defines attached to this PR, and at the end of the day, that's a great place to start off of. ## Changelog 🆑 add: Added ore vents. Scanning them with mining scanners shows what minerals they contain. Scan again to fight off a horde of beasts as your drone assistant excavates the vent, so the ore vent will produce mineral boulders! bal: Ores that spawn in walls now spawn based on their proximity to ore vents, with their chance to spawn and their minerals contained scaling from low to high. add: Added the BRM, Refinery, and Smelter. These pieces of equipment are used to process ore boulders into minerals for the station. Stock Part upgrades allow more boulders to be processed at one time. They collect mining points as well, to be redeemed with an ID card swipe. add: Boulders are teleported to the station via the BRM if left untouched. Boulders can also be cracked open for a reduced amount of ore using pickaxes or golems hands. add: All stations come equipt with a pre-excavated ore vent, which produces a basic supply of iron and glass only. Scan other vents for your critical resources! add: Look there's a shit ton of changes on mining, for more detail check out the Pull Request: https://github.com/tgstation/tgstation/pull/78524. sound: New sounds and noises for your high octane factorio-like gameplay! image: All new boulder sprites for the new minerals and rocks added to the mining gameplay loop, as well as mining machines! image: Overlays appear over vents when scanned to let you know their contents at a glance when actively scanned with any mining scanners. /🆑 --------- Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: Jacquerel <hnevard@gmail.com> Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>	2024-01-21 11:32:05 -05:00
SyncIt21	527ebc3451	Fixes for mat container & ORM (#80573) ... ## About The Pull Request - Fixes #80559 1) The ORM now hooks onto the local container only if off station. The ui act if statement was also messed up but that's fixed now too. 2) Creates a dedicated signal for items inserted into the silo for clarity & uses the helper proc defined inside remote materials for inserting items so we don't have to specify the `context` manually. 3) Properly updates the auto Doc for the container signal defines ## Changelog 🆑 fix: Off station ORM's can redeem points again. /🆑	2023-12-28 14:58:22 +01:00
SyncIt21	d36a5af64f	Removes material breakdown flags, traits & miscellaneous fixes. (#80389) ... ## About The Pull Request 1. Removes material breakdown flags i.e. all flags with the format `BREAKDOWN_XXX`. These flags do nothing, there are no special checks to transform materials based on these flags, they are passed around just because certain procs require them for syntax purposes only. Apparently there were plans to make these flags do something special from the comment https://github.com/tgstation/tgstation/blob/302247c0d1e980478f59d9c497169290ee259887/code/__DEFINES/construction/material.dm#L43 But nobody got any ideas for years now. The only special thing we can do with them now is remove them and reduce code clutter, so let's do that The only flag that ever did something was the `BREAKDOWN_INCLUDE_ALCHEMY` flag. This only worked when coupled together with `TRAIT_MAT_TRANSMUTED` trait(which is only used by the reagent metalgen) and when both this trait & flag are combined together... they still do nothing https://github.com/tgstation/tgstation/blob/302247c0d1e980478f59d9c497169290ee259887/code/game/atom/atom_materials.dm#L41-L42 Yup they cancel out each other to prevent returning an empty list, the traits only job was to prevent materials from being recycled (like why? what's the benefit of that? nothing) and the flag was meant to bypass this restriction so both the trait & the flag cancel out each other therefore doing nothing meaningful. Best remove them both and call it a day. 2. Fixes an error in displaying number of sheets inserted into a mat container when that sheet is made up of alloy materials. it would count as 2 or more because it would take the sum of total material amount inserted and not the actual sheets. That's fixed now. 3. Remote materials now properly respect the `MATCONTAINER_NO_INSERT` flag 4. Adds helper proc to insert materials via the remote material component with proper context ## Changelog 🆑 fix: mat container displays correct number of sheets inserted for alloy materials. fix: remote materials now properly respect the `MATCONTAINER_NO_INSERT` flag. code: removes material breakdown flags and related traits. code: adds helper proc to insert materials via the remote material component with proper context. /🆑	2023-12-25 02:29:26 +01:00
SyncIt21	27635e7640	Mat container related refactors & patches (#80164) ... ## About The Pull Request **1. Mat container `user_insert()` tweaks** - Mat container will now skip over an item & its contents if that item cannot be processed (not suitable for redemption or not an allowed type) this is not only realistic(if an item has an tough outer shell you can't crush it to access its contents) but also saves us computation time as we can skip over contents quickly - Mat container now properly respects the `MATCONTAINER_SILENT` flag - You can now hit machines like autolathe, protolathe etc with iron sheets (or any other material item type those machines accept) when in combat mode rather than inserting them because it makes sense - Mat container now has much reduced chat spam as it will sum up all the items inserted, and the material collected rather than displaying them individually.  Much improved readability and overall faster as we do much less `to_chat()` calls **2. ORM Tweaks** - Fixes https://github.com/Skyrat-SS13/Skyrat-tg/issues/25329 . ORM now generates points correctly always, regardless of how the ore is inserted be it - Via hand - Thrown at the ORM - Ore Box - Some other bag containing ore Points will always be generated at a common proc so no more checking every inlet on how the ore enters the machine. Once the silo receives the material it will inform the ORM about it, so it does not have to check itself therefore reducing code bloat. ## Changelog 🆑 fix: ORM will generate points regardless of how the ore enters it. fix: Machines like autolathe, techfab etc can now be hit with iron sheets (or any other material item type those machines accept) when in combat mode rather than inserting them because it makes sense. fix: Mat container won't display chats fully if the `MATCONTAINER_SILENT` flag is passed. refactor: Machines like autolathe, techfab etc now display summed up material inserts to chats rather than each item individually. Also, will skip items & its contents if it cannot be processed thus saving time /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>	2023-12-14 15:12:04 +01:00
MrMelbert	1e76fd70b4	Attack chain refactoring: Broadening tool_act into item_interact, moving some item interactions to... atom/item_interact / item/interact_with_atom (#79968) ... ## About The Pull Request Implements half of this (with some minor changes):  The ultimate goal of this is to split our attack chain in two: - One for non-combat item interactions - Health analyzer scanning - using tools on stuff - surgery - Niche other interactions - One for combat attacking - Item hit thing, item deal damage. - Special effects on attack would go here. This PR begins this by broadining tool act into item interact. Item interact is a catch-all proc ran at the beginning of attack chain, before `pre_attack` and such, that handles the first part of the chain. This allows us to easily catch item interaction and cancel the attack part of the chain by using deliberate bitflag return values, rather than `TRUE` / `FALSE`*. *Because right now, `TRUE` = `cancel attack`, no matter what, which is unclear to people. Instead of moving as much as possible to the new proc in this PR, I started by doing some easy, obvious things. More things can be moved in the future, or technically they don't even need to move in a lot of cases. ## Changelog 🆑 Melbert refactor: Refactored some methods of items interacting with other objects or mobs, such as surgery and health analzyers. Report if anything seems wrong /🆑	2023-12-08 23:50:19 -07:00
Jeremiah	ed947dbdf9	Adds withdrawal multiplier to ORM (#78404) ... ## About The Pull Request Pulling an alloy stack from the ORM always counted as 1. No matter the stack size ## Why It's Good For The Game Sadly, no more infinite resources	2023-09-17 06:58:25 +00:00
SyncIt21	9aed3b6a8f	General code maintenance for Mat container related stuff (#77671) ... 1. Removes `/obj/machinery/ore_silo/proc/remote_attackby()`. This proc calls `datum/component/material_container/user_insert()` anyway which performs all the checks necessary for inserting stuff into the ore silo and `/obj/machinery/ore_silo/proc/remote_attackby()` was just repeating its code & checks. So now inserting into the ore silo is directly handled by the mat container without this proxy proc making the operation slightly faster 2. Removed silo `attackby` code. Same operations can be done via `screwdriver_act` & `crowbar_act` procs much cleaner 3. The ore silo now hooks onto signals `COMSIG_MATCONTAINER_ITEM_CONSUMED` and `COMSIG_MATCONTAINER_SHEETS_RETRIVED` and logs into silo when they are triggered. This means when you insert/eject sheets from the silo the connected machine performing the operation no longer has to do the logging manually thus the proc `silo_log` has been removed from a lot of places ,reducing overall code size 4. A lot of stuff that use materials from the ore silo follow this pattern. i.e. They first use the materials from the silo and then log it via `silo_log` proc. This code pattern is repeated in a lot of places so let's just merge these 2 lines with some extra sanity checks into a single proc inside `remote_materials` itself. That's what was done and the number of places where you log manually into the silo has been removed further reducing code size everywhere. 5. Added auto doc & cleaned up some procs Since logging is now done by the ore silo directly, we need a way to pass the machine that is inserting items into the silo to the signal handlers of the ore silo [via the `context` var]. So other code changes elsewhere is because of this var	2023-08-21 22:23:01 +00:00
Ghom	5d5492e111	Implements usage of the REVERSE_DIR macro throughout the code. (#77122) ... ## About The Pull Request Replaces a ton of `turn(dir, 180)` calls with the aforementioned macro. ## Why It's Good For The Game Afaik, `REVERSE_DIR` was coded to be faster than the classic `turn(dir, 180)` call, being a simple set of binary operations. To sum it up, micro optimization. ## Changelog N/A	2023-07-28 15:16:09 +02:00
SyncIt21	e92ae5b75b	Material container & related stuff ui refactors & clean-up (#76220) ... ## About The Pull Request **1. Material container clean-up & refactor** - Replaced `total_amount` var with `total_amount()` proc, this var can be easily computed by summing up all material amounts rather than storing it as a var which is tedious to update & keep track of when materials are added/removed - Removed unused procs `transer_amt_to()`, `can_insert_amount_mat()`, and `get_categories()`. These procs are not used anywhere in the codebase so let's remove them & make some space. - Callbacks are replaced with signals, the callbacks don't need to be explicitly garbage collected & having macros & procs marked with `SIGNAL_HANDLER` makes your intentions more readable & explicit. - Fixes #76151 All material adding, removal, checking operations are "Integer" operations, i.e. the final value is rounded & them made 1 if the final value is 0 using the macro `OPTIMIZE_COST`[coudn't come up with a better name]. No more dealing with decimal value materials The problem was after the protolathe was upgraded with better parts all the design costs were multiplied with a decimal `efficiency_coeff` value, this means even though in the UI the cost was displayed as 60 bluespace crystals its actual cost was `60.0001` something in the backend causing this check for materials to fail & print the error message. - Replaced `GetComponent(/datum/component_material_container)` with just a simple ref to the material container when adding the component, so we can save some overhead from calling this proc - Gave all procs a ton of documentation with documentation having documentation - Fixes #76506 RCD and other devices that uses the silo link upgrade now have the correct material usages - Fixes #72096. It wasn't just a problem with ancient protolathe but with all machines that used `datum/component/remote_materials` the problem was remote materials would add an instance of `datum/remote/material_container` if it wanted to use local storage but this component would get added before `datum/component/remote_materials` could be registered i.e. it comes before remote_materials in the component list. So when the machine is destroyed it will first destroy `material_container` & then `remote_materials` therefore destroying the materials before they could get ejected - Silo link is established when parent is registered with remote materials raher than adding an external timer which is faster - Everything that uses a material container will auto eject their sheets when destroyed - Moved this & remote materials into its own folder for better organization **2. Material UI Changes** - Removed the x25 & x50 print buttons from the autolathe, now they just have x5 & x10 buttons like the protolathe, These buttons were of no use since you could just type the exact amount you want to print in the `[Max: <some amount>]` side bar. The code to compute these buttons was just plain right nasty & some of it unused in the UI. - The material eject button in the material bar does not gray out when you can eject exactly one sheet - All material cost are integer values rounded - Fixes #76253 Exosuit Fabricator sends the material container static data to the UI so its material bar is not greyed out when there are sufficient materials to eject - Component printer material bar sends the material container static data to the UI so its material bar is not greyed out when there are sufficient materials to eject - Autolathe Material bars now display number of sheets available - Max printable amount of items are now computed & updated correctly in the UI. They were displaying wrong values & now get updated when items are printed, materials are removed - Silo hold actually works now. When a machine is put on hold it calls this proc https://github.com/tgstation/tgstation/blob/e929cf39cded5207d63df1fa8521f41f2816b383/code/datums/components/remote_materials.dm#L78-L87 Notice how the key is `src` so we should be consistent during checking if a machine is on hold using the same `src` var. But for some reason we did dumb shit like this https://github.com/tgstation/tgstation/blob/e929cf39cded5207d63df1fa8521f41f2816b383/code/datums/components/remote_materials.dm#L150-L153 What is category? Why do we care for the area the machine is in? None of it made sense so i removed all that junk and just made it check for `src` like it should - Removed redundant `removable` & `sheets` var from the material container ui_data. These vars are unused in the UI - If an item does not have the required materials then upon clicking that item you will not get any error message but instead nothing happens ## Changelog 🆑 fix: items can be printed from autolathe & protolathe when the exact material amounts are present in them after upgrading fix: max printable amount now shows the correct value & updates when items are printed, materials are removed in the autolathe & protolathe fix: component printer material bar is not greyed out when there are sufficient materials to eject fix: rcd and other devices that uses the silo link upgrade now have the correct material usages fix: silo hold actually works fix: machines using local storage to hold materials will eject it's materials as sheets when deconstructed/destroyed refactor: Autolathe Material bars now display number of sheets available refactor: printing an item that does not have enough materials will fail silently with no error messages refactor: Drone dispenser will eject sheets upon deconstruction refactor: all things that store materials will auto ejects its sheets(if there is sufficient material) when destroyed refactor: inserting an item into the material container will display the units consumed as sheets not absolute units refactor: removed x25 & x50 print buttons from the autolathe	2023-07-24 19:47:14 -04:00
Vekter	d27203f2f9	Fixes the ORM not correcty granting mining points if adding ore by hand (#76447) ... ## About The Pull Request This was an oversight from back when material datums were redone. Ideally you should still be dumping your ore on the floor so the ORM can slurp it up, but if for some reason you just want to add it by hand, this works fine. ## Why It's Good For The Game Consistency good. Fixes #76409 ## Changelog 🆑 Vekter fix: Fixed the ORM not granting mining points if you added ore by hand instead of dumping it on the floor. /🆑	2023-07-01 15:30:59 +01:00
SyncIt21	2922d36500	Refactors for material container, ammo box & recycler (#75422) ... **1. Material Container Refactors** a. `/datum/component/material_container/proc/insert_item()` - Will now do stack spliting i.e. it will consume as many sheets from a stack as possible and leave out the rest, It was moved from a player interaction feature in `user_insert()` to this low level allowing many things to take advantage of it - Will now delete the item for you if it could salvage any materials from it, you don't have to do it explicitly anymore if insertion was successfull (i.e. this proc returns an non zero value) If you inserted a stack and not all of it's sheets were inserted from the above point then you still have to check it explicitly - Will now invoke `after_insert` if any materials were salvaged b. `datum/component/material_container/proc/user_insert() ` - Will now split the stack by the requested amount making precise insertion work again & Fixes #72288 - will now consume all contents inside of the object reccursively, this means items like ammo boxes will no longer have to adjust their custom materials based on how much ammo they contain because `user_insert()` will loop through all its contents and salvage the metal of every bullet inside the box contents so this means https://github.com/tgstation/tgstation/blob/9686971c76fb6300939c9c191c635d2a852a143c/code/modules/projectiles/boxes_magazines/_box_magazine.dm#L206 has been removed. **The Problem with this proc** take `/obj/item/ammo_box/foambox/riot` for example. it has 40 darts each having 1125 worth of iron, this proc will add the total iron of all the bullets to the box custom material so the box custom materials would become `5000(base iron of box. see the definition of /obj/item/ammo_box/foambox/riot) + 45000(40 bullets each having 1125 worth of iron) = 50000 iron` What happens when you throw this ammo box in an recycler? The recycler will recycle this box(Now 50000 worth of iron) AND the iron of each of it's 40 bullets thus yielding `50000(iron from box because of update_custom_materials()) + 45000(40 bullets each having 1125 worth of iron) = 95000 iron` ` because of this single proc we got `95000 - 50000 = 45000 extra iron` from thin air **The Solution?** Remove this proc and set a constant custom material value for the ammo box(it's now 5000 computed see code) AND allow the material container to loop through every bullet in the box and salvage iron from them. This would yield `5000(base iron of box. see the definition of /obj/item/ammo_box/foambox/riot) + 45000(40 bullets each having 1125 worth of iron) = 50000 iron` From both box & bullets combined and not just from the box alone Fixes #43570 Fixes #57548 This also allows you to do cool stuff like fill your bag with iron, glass, whatever and dump them in the autolathe/ore silo by attacking the machine with your bag rather than pulling out & inserting each item individually so hey convinience **2. Recycler patches** - Recycler will stop consuming items when it runs out of power mid recycling(which can happen if it recycles a large amount of items). It used to previously run through the list of items without breaking so even when power was lost, it still did it's job - Recycler will now Properly recycle all the contents inside an atom. **The Problem** Say we have 2 Items - Backpack - Glass sheet inside Backpack If we process the items in the following order while deleting each item that is processed first "Backpack" then "Glass Sheet" then when "Backpack" is fully recycled and "Deleted" since the "Glass Sheet" is inside the "Backpack" it get's deleted as well, so when we actually try to recycle the "Glass Sheet" next, nothing happens because it was deleted when we deleted the "Backpack". **The Solution** Recycle the items in the reverse order first recycle the "Glass Sheet" delete it & then the "Back Pack" so we don't deal with deleted items. So you should see more materials come out when you put stuff inside storage mediums & throw them in the recycler - Recycler will consume only half the power when it's deleting items that can't be recycled(no material was salvaged). just for convinience	2023-05-29 20:30:16 +00:00
Profakos	dde5785f82	Request Console refactor (#75067) ... ## About The Pull Request This PR changes the request consoles in the folowing ways: - The request console's had some very old UI, so I decided to convert it to tgUI. - Cleans up and changes various variable names. Also removes a historical comment (desouls the file) - Sending an announcement now has a cooldown of 30 seconds like the message console priority announcement - Audio feedback on successful and erroneous message give a little audio feedback - Reply is now Quick Reply, which you do in a popup I have half a mind to remove the long material list from the ORM, as some people told me I should, but for now it stays. <details> <summary>Screenshots of the new UI</summary>    </details> I originally planned to add mapping helpers, but decided to delay it until a future PR. ## Why It's Good For The Game TgUI is good and powerful. ## Changelog 🆑 refactor: converts the request console to tgui /🆑	2023-05-06 18:07:24 -07:00
ArcaneMusic	f2fd69a49a	Minerals have been refactored so costs and minerals in items are now in terms of mineral defines. (#75052) ... Ladies, Gentlemen, Gamers. You're probably wondering why I've called you all here (through the automatic reviewer request system). So, mineral balance! Mineral balance is less a balance and more of a nervous white dude juggling spinning plates on a high-wire on his first day. The fact it hasn't failed after going on this long is a miracle in and of itself. This PR does not change mineral balance. What this does is moves over every individual cost, both in crafting recipes attached to an object over to a define based system. We have 3 defines: `sheet_material_amount=2000` . Stock standard mineral sheet. This being our central mineral unit, this is used for all costs 2000+. `half_sheet_material_amount=1000` . Same as above, but using iron rods as our inbetween for costs of 1000-1999. `small_material_amount=100` . This hits 1-999. This covers... a startlingly large amount of the codebase. It's feast or famine out here in terms of mineral costs as a result, items are either sheets upon sheets, or some fraction of small mats. Shout out to riot darts for being the worst material cost in the game. I will not elaborate. Regardless, this has no functional change, but it sets the groundwork for making future changes to material costs much, MUCH easier, and moves over to a single, standardized set of units to help enforce coding standards on new items, and will bring up lots of uncomfortable balance questions down the line. For now though, this serves as some rough boundaries on how items costs are related, and will make adjusting these values easier going forward. Except for foam darts. I did round up foam darts. Adjusting mineral balance on the macro scale will be as simple as changing the aforementioned mineral defines, where the alternative is a rats nest of magic number defines. ~~No seriously, 11.25 iron for a foam dart are you kidding me what is the POINT WHY NOT JUST MAKE IT 11~~ Items individual numbers have not been adjusted yet, but we can standardize how the conversation can be held and actually GET SOMEWHERE on material balance as opposed to throwing our hands up or ignoring it for another 10 years.	2023-05-03 14:44:51 +00:00
John Willard	722f1c7f90	Golems can now redeem points from their ORM (#75083) ... Golems can now redeem points from their ORM. There's a check for bank job, so only the blank ID cards golems get will work. Miners theoretically can use one of the cards to get points themselves, but then they need to carry that card around and get all points through it, because their starting ID cannot claim it.	2023-05-02 14:28:59 -05:00
John Willard	ba24aa3404	Ore silo will put machines off its level on hold, instead of disconnecting (#74990) ... ## About The Pull Request There's a problem where people would try to rebuild a whiteship and use an Ore Silo for it. However, it would automatically unlink everything when moving, because it's checking for z level as soon as it changes z level itself, before the Ore silo has 'moved' as well. ~~To fix this, I'm now only disconnecting ore silos when a shuttle moves. This mostly does the same as before, but technically you can sync an unwrenchable connected machine and bring it to space with you (without using a shuttle) to stay connected, but I don't see this as a problem, and my original point of the PR was to prevent Lavaland ORMs.~~ I decided against this, instead I've made it so machines that aren't on a valid level (either both on the same z level or both on the station level) will be considered 'on-hold', much like if the QM has set it to hold through the silo directly. This means that machines no longer disconnect from the Ore silo on moving, they just can't access the materials in it. This affects gameplay in 2 ways: 1. You no longer need to resync when you bring the machine back 2. It won't unsync itself every time you move station z-level with its silo (such as on a whiteship). I also made disconnecting from an ore silo actually remove them from the ore silo's list of connected machines. ## Why It's Good For The Game Closes https://github.com/tgstation/tgstation/issues/69863 ## Changelog 🆑 balance: Machines (such as ORM and Techfabs) will no longer unsync from Ore silos when it moves Z-level, instead it will prevent materials from being used, as if it was on hold. /🆑	2023-04-30 16:06:12 -06:00
Gamer025	a8457b91f3	Fixes silo logging + add log file based logging to silo (#74806) ... ## About The Pull Request Fixes deposit logs not working for the silo because they passed in the mats argument in the wrong format. Also adds log file based logging to the silo with a new log file: silo.log. This log should contain every deposit and withdraw action performed on the silo and from which machine and location inluding material amounts. ## Why It's Good For The Game Fixes broken ingame logs + adds better external logs for potential stat tracking. ## Changelog 🆑 Gamer025 fix: Ingame ore silo logs should now log deposit actions correctly config: New config for silo logs /🆑	2023-04-24 13:47:12 -07:00
Jacquerel	153c1818e5	Reworks sabotage progression traitor objective (#73750) ... ## About The Pull Request This one is a little bit of a more abstract change than my last traitor objective rebalancing PR. The idea here is that I think that the objectives which have you sabotage a frequently used machine (lathes or the ORM, but we can maybe expand it to others following this?) are potentially pretty good but limitations in how the objective are tracked mean that people go about them in a boring way which rarely inconveniences anyone. I have reworked these objectives so that you can choose to apply a provided item to the machine over 10 seconds. The next interaction following this (clicking on it, or in the case of the ORM loading any ore into it) will cause the machine to explode, destroying itself and lightly damaging people nearby (explosion damage is... variable, but it's a light explosion so it won't instantly kill anyone). There is a 0.5 second grace period between the bomb triggering and the explosion actually happening, which players can use to perform some kind of tactical reaction or simply to feel regret. Here's a video: https://www.youtube.com/watch?v=xNIaHsA9YFE Trapped machines will intermittently beep, though at a volume which is hard to detect from more than two tiles away, and can be defused by using a screwdriver on the machine. If you choose to do this then you will get a little bonus to TC and reputation, but only if the trap is successfully sprung. This means that sabotaging a machine in an empty department is unlikely to lead to quick success. You can also still do it with screwdriver and crowbar way if you are boring but this means you will only get reputation and not any telecrystals. The two objectives to destroy a radio server or the research machine remain as they were. Also I refactored how we set which machines are targets for these objectives so it doesn't iterate over every machine in the world every time. ## Why It's Good For The Game Traitor objectives (and antagonist objectives in general) should: - Present you with a somewhat engaging task - Encourage you to interact with at least one other player (at least by "attempting to sneak past them") - Move the state of the round forward in some way, usually by creating inconvenience for at least one other person Prior to this change you could, and people often did, complete this objective by accessing a machine that you already _have_ access to, using a screwdriver and crowbar on it, and then reassembling it. This prompts interaction with nobody, and inconveniences nobody. Following this change people will be encouraged to: - Actually destroy the machine. - Probably harm somebody. - Potentially cause some collateral damage. - Make loud sounds and flashing lights to delight people of all ages. Even if you opt to set the device in a little-used department and then blow yourself up, that will prompt you to go and interact with someone in medbay and will also look pretty suspicious in a way that's much harder to track with the previous objective. Also I might reuse this component again in the future, you never know. ## Changelog 🆑 Jacquerel, sprite by J(Clearly Lying) balance: Traitor objectives which ask you to destroy lathes or the ORM provide an optional bonus if you _booby trap_ the machine using a provided tool. This causes the machine to explode the next time it is interacted with. balance: Performing the objective without rigging the machine to explode awards no TC, using it awards more TC than it did previously. /🆑	2023-03-10 22:58:11 +00:00
SMOSMOSMOSMOSMO	abacca05d6	[no gbp] orm correctly displays borg id data (#73808) ... ## About The Pull Request this is a minor thing i forgot to add in my last PR, now the borg's name will be displayed as well when interacting with the ORM rather than displaying "no id detected" ## Why It's Good For The Game ## Changelog 🆑 qol: Borgs are now acknowledged by the orm /🆑	2023-03-07 11:39:43 +00:00
SMOSMOSMOSMOSMO	1c91c24dfb	ORM ui qol (#73721) ... ## About The Pull Request seperates everything into tabs and allows u to search. ur credits are displayed on the ui and makes the buttons to print mats similar to fabricators  ## Why It's Good For The Game more fun to use the orm ## Changelog 🆑 qol: made ORM easier to use /🆑	2023-03-05 13:15:31 -08:00
Tim	a1ada2c9ef	Refactor, improve, and rename canUseTopic to be can_perform_action (#73434) ... This builds on what #69790 did and improved the code even further. Notable things: - `Topic()` is a deprecated proc in our codebase (replaced with Javascript tgui) so it makes sense to rename `canUseTopic` to `can_perform_action` which is more straightforward in what it does. - Positional and named arguments have been converted into a easier to use `action_bitflag` - The bitflags adds some new checks you can use like: `NEED_GRAVITY | NEED_LITERACY | NEED_LIGHT` when you want to perform an action. - Redundant, duplicate, or dead code has been removed. - Fixes several runtimes where `canUseTopic` was being called without a proper target (IV drips, gibber, food processor) - Better documentation for the proc and bitflags with examples	2023-02-16 20:22:14 -05:00
Profakos	796139c127	Fixes the ORM I/O lights (#72936) ... ## About The Pull Request The ORM's input lights have turned invisible, due to item state names that have not been updated. This PR fixes that. It also autodocs the various procs and vars. ## Why It's Good For The Game Fixes #72923 It is good to see which direction you have to place the ores. ## Changelog 🆑 fix: The ORM's input and output lights are once again visible /🆑	2023-01-28 18:17:47 -05:00
John Willard	ae9241beae	Moves mining points from the ID to the bank account (+credit type shown on order console) (#72726) ... ## About The Pull Request Mining points are now stored on the ID's bank accounts instead of the individual IDs, bringing them on-par with credits. This allows miners to safely replace their ID and keep their mining points just like they can for their credits. I also added the cost type on Produce Consoles, so people using them will know whether they're using mining points or credits. Because all IDs have a bank account by default, this won't be a problem to Golems or the like. ## Why It's Good For The Game 1. It's more clear to the player what type of credit is being used in the order console 2. Mining points being tied to the ID is no longer needed as all IDs have a bank account 3. Brings mining points up to the same standard as credits. ## Changelog 🆑 qol: Mining points is now tied to bank accounts instead of individual IDs, so they transfer over in cases of an ID replacement. /🆑	2023-01-25 12:04:26 -08:00
John Willard	6d757e8bec	Autounlock techwebs are shared between machines that use them. (#72515) ... ## About The Pull Request Did you know that for every Autolathe, Limbgrower, Biogenerator, ORM, and Smelter that was built, an entire new techweb was made? The average round has 2 ORMs (smelters count) if not more from ORM deconstruction objective, 2 biogenerators, several autolathes and generally 0-1 limbgrower, I think there's more techwebs being created than we need. Creating a whole techweb was a pretty terrible way to optimize this, so I made a global list that stores these techwebs. Created on demand, these autounlocking techwebs now share between the machines that use them. It also generate all hacked nodes which will be visible if the machine is hacked, instead of 'researching' them for each hacked individual machine. The 'specialized' techweb subtype was removed because its sole purpose was to allow autounlocking to be a subtype of it. Now autounlocking is just the direct subtype. I also removed mechfab autounlocking type because it wasn't used, mechfabs use techwebs directly. Autolathes and Limbgrowers now locally store 'imported designs' which are things uploaded from technology disks. Outside of this, the autounlocking techweb subtype now stores 'hacked designs' which unlocks when the machine is emagged. While doing this, I saw ORMs and Biogenerators had disks you can insert into them, but I did not find anything that can actually be uploaded to them (I saw Alien Alloys as a possibility, but there's no such disk to allow uploading this alloy to the machine, and I didn't think an entire system for 1 single alloy was worth keeping around), so I removed this unused feature from both machines. I merged 'Hacked' and 'Emagged' categories because they served the same purpose, 'hacked' being on hacked autolathes and 'emagged' being on hacked (emagged) limbgrowers. Tech disk techwebs (which is created every time a disk is made, however I hope to change this in the future) into it's own subtype, so admins understand where its from when looking in VV panel (because I was confused when I saw them at first). ``autolathe_crafted`` proc was removed because it was entirely unused too. Now it looks like this, which I consider an improvement:  ## Why It's Good For The Game We no longer initialize a brand new techweb for no reason whatsoever. Each techweb made is making entire lists of experiments and research papers, all of which is never to be seen in-game and is completely useless to the player. Cutting down on these techwebs is a good first step to this needless initializing. ## Changelog 🆑 qol: Removed the tech disk part of the ORM's UI as it was entirely unused, now it's a little more compact with less scrolling needed. refactor: Autolathes, Limb growers, Biogenerators, ORMs and Smelters now share techwebs with other machines of their types, rather than all make new techwebs each time. This means they only build their nodes once, including hacked ones. Instead of researching nodes on hacking the machine, they now show hacked ones depending on if it's hacked. /🆑 Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>	2023-01-14 17:54:46 -08:00
Andrew	fd1ea8d5b5	Biogen shows default reagent container icons instead of beakers (#72247) ... ## About The Pull Request With the new crafting menu some reagents now have default container assigned. I applied these to visualize reagents in biogen UI too. <img alt="060ybChTkI" src="https://user-images.githubusercontent.com/3625094/209483256-e4159a05-46ae-47b8-bc42-9d003cf6c303.png"> ## Why It's Good For The Game Better representation of a reagent. ## Changelog 🆑 qol: Biogenerator shows default reagent containers instead of beakers /🆑	2023-01-03 21:20:30 -08:00
AnturK	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>	2022-11-15 03:50:11 +00:00
private-tristan	8431707d01	removes orm upgrade text (#70904) ... ORM no longer tells you its bonus ore/points, as its upgrades were removed 2 years ago in #53073	2022-11-01 00:35:45 +01:00
John Willard	91f02f2a6b	canUseTopic now uses TRUE/FALSE instead of defines that just say TRUE (#69790) ... * canUseTopic now uses TRUE/FALSE instead of defines that just say TRUE The most idiotic thing I've seen is canUseTopic's defines, they literally just define TRUE, you can use it however you want, it doesn't matter, it just means TRUE. You can mix and match the args and it will set that arg to true, despite the name. It's so idiotic I decided to remove it, so now I can reclaim a little bit of my sanity.	2022-10-01 09:47:52 -07:00
LemonInTheDark	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	2022-09-27 20:11:04 +13:00
Wallem	c44dbece68	Gives the ORM a visual indicator showing which side is the input and which is the output (#69551) ... About The Pull Request Gives the ORM a light on either side showing which is the input and which is the output, blue for input, red for output. ORM 121212 233123123 Why It's Good For The Game Useful for if anyone decides to move the ORM. Changelog cl Wallem qol: The ORM now has color-coded lights showing which side is the input and output. Blue for input, red for output. /cl	2022-09-07 10:08:43 +12:00
robbertapir	4393879777	Prevents negative mats (#67582) ... * Prevents negative mats from the ore redemption machine. Co-authored-by: robbertapir <robbertapir@airmail.cc>	2022-06-08 10:11:17 -04:00
Arkatos1	b98d91c095	updateDialog and updateUsrDialog cleanup (#66494) ... This PR focuses on cleaning up two procs - updateDialog and updateUsrDialog. Both of which are/were used updating for old HTML UIs. As these UIs got converted to TGUI over time, these old code fragments started to pile up, often due to coders simply overlooking them. This resulted in them being dead code doing nothing when called, or randomly opening up windows when they shouldnt, for example when a vending machine is screwdrivered and UI cannot even be interacted with. However, there were also some desirable uses - like opening a window when an ID is inserted into civilian bounty console, which you are then gonna obviously use to pick a bounty. I kept these uses and replaced them with proper ui_interact, so they now always work, instead of them working only when you had them set as a currently used machine on mob. The list of these changes is: Civilian Bounty Console will now always bring up its UI when you insert the ID. Air Alarm and APC will now always bring up its UI when you unlock their controls. Portable Chem Mixer, Chem Dispenser, Chem Heater, Improvised Chem Heater, Chem Spectometer and Chem Master will now always bring up their UI when you add or replace beaker to them. Two old /Topic calls were cleaned up as well, as they were no longer relevant. Removes dead or outdated code, adds sensible UX when working with certain UIs.	2022-04-25 18:58:57 -07:00
John Willard	2db00c7dc5	standardizes default unfasten wrench (#65425) ... I'll do more in the future but I'll limit myself to this because I'm tired, bored, and don't want to make so many PRs touching the same things that I have to deal with conflicts each time one is merged. Just as an example, screwdriver's gotta be done as well, does the exact same thing wrenches do, I believe. Standardizes (and touches) each time default_unfasten_wrench is used. Fixes tool logs, since it relies on tool acts to exist, I'm trying to move as many tool acts to its proper proc. Like a spiritual successor to the tool superpack PRs. Co-authored-by: Luc <89928798+lewcc@users.noreply.github.com>	2022-04-04 12:44:14 -07:00
Jeremiah	30253cf6a8	Tgui input refresh (#64331)	2022-02-05 19:44:59 +02:00
Jeremiah	9c6fdb567d	TGUI list conversions + bug fixes (#63354) ... About The Pull Request Converts more inputs to TGUI. Possibly all user-facing input lists in the game. Did any surrounding text/number inputs as well Added null choice support so users can press cancel. Added some misc TGUI input fixes Fixed custom vendors while I was there I refactored a lot of code while just poking around. Primarily, usage of .len in files where I was already working on lists. Some code was just awful - look at guardian.dm and its non use of early returns If there are any disputes, I can revert it just fine, those changes are not integral to the PR. Why It's Good For The Game Fixes #63629 Fixes #63307 Fixes custom vendors /again/ Text input is more performant. Part of a long series of TGUI conversion to make the game more visually appealing Changelog cl refactor: The majority of user facing input lists have been converted to TGUI. refactor: Tgui text inputs now scale with entered input. fix: Many inputs now properly accept cancelling out of the menu. fix: Fixes an edge case where users could not press enter on number inputs. fix: Custom vendor bluescreen. fix: You can now press ENTER on text inputs without an entry to cancel. /cl	2021-12-31 11:07:28 +13:00
Jeremiah	dcab86ba2c	More standard tgui input conversions (#63464)	2021-12-24 13:04:18 +02:00
Rohesie	e03cd1aada	Refactors move procs to support multitle objects (#59658) ... Enter(), Entered(), Exit() and Exited() all passed the old loc forward, but everything except a single a case cared about the direction of the movement more than about the specific source. Since moving multi-tile objects will have multiple sources of movement but a single direction, this change makes it easier to track their movement. Cleaned up a lot of code around and made proc inputs compatible. I'll add opacity support for multi-tile objects in a different PR after this is merged, as this has grown large enough and I don't want to compromise the reviewability. Tested this locally and as expected it didn't impair movement nor produced any runtimes.	2021-06-20 14:55:37 -07:00
Watermelon914	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)	2021-06-14 13:03:53 -07:00
TemporalOroboros	fb488fdfff	Some explosions code cleanup (#57493) ... Clears out two deprecated explosions systems (explosion ids and explosion levels) Refactors a bunch of contents_explosions procs to be maybe slightly faster. Cleans up a bunch of ex_act code. Slightly cleaner code A few less unused vars on /atom and /turf	2021-03-20 16:03:59 -07:00
TemporalOroboros	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	2021-02-19 12:06:18 -03:00
Ghom	27d0e32b47	minor material_container args/vars refactor and Mk-honk shoes peeve. (#54863) ... My original intention was just fixing an issue with the Mk-honk banana shoes but, considering I didn't want to add two new variables to a component with already lot of args and lengthy AddComponent() calls in term of text, I had to merge some TRUE/FALSE variable/args into the breakdown_flags bitfield (now named mat_container_flags) in the process.	2020-11-21 04:37:07 -03:00
Ghommie	a74714c2ab	Moved these getters toward the upper end.	2020-10-29 16:02:13 +01:00