mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-12 08:36:00 +01:00
docker-container
382 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 SkyratBot
|
4a2a4829b8 |
[MIRROR] Make spritesheets cacheable by default, killing a lot of overtime in the round start spike [MDB IGNORE] (#25820)
* Make spritesheets cacheable by default, killing a lot of overtime in the round start spike (#80522) ## About The Pull Request Makes all spritesheets cache by default. This wasn't the case originally because some spritesheets like vending machines relied on in world state, but none of them do anymore because that's whack. Also fixes a bug that would cause half completed caches to break other stuff. This didn't happen in real gameplay, but would've happened if you tried to change cachable on anything while you already had a tmp folder. ## Changelog 🆑 fix: Cut down a significant amount of time that caused the start of rounds to lag. /🆑 * Make spritesheets cacheable by default, killing a lot of overtime in the round start spike --------- Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
SkyratBot
|
7a297ca36d |
[MIRROR] Track time to queuedInsert in feedback [MDB IGNORE] (#25813)
* Track time to queuedInsert in feedback (#80521) Investigating large lag spikes in round start and noticed a large amount of overtime (3s worth) to queuedInsert. It's vending machines and R&D, but let's keep an eye on this. * Track time to queuedInsert in feedback --------- Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
Mothblocks
|
723ced5d7b |
Make spritesheets cacheable by default, killing a lot of overtime in the round start spike (#80522)
## About The Pull Request Makes all spritesheets cache by default. This wasn't the case originally because some spritesheets like vending machines relied on in world state, but none of them do anymore because that's whack. Also fixes a bug that would cause half completed caches to break other stuff. This didn't happen in real gameplay, but would've happened if you tried to change cachable on anything while you already had a tmp folder. ## Changelog 🆑 fix: Cut down a significant amount of time that caused the start of rounds to lag. /🆑 |
||
|
Mothblocks
|
60ce61b29d |
Track time to queuedInsert in feedback (#80521)
Investigating large lag spikes in round start and noticed a large amount of overtime (3s worth) to queuedInsert. It's vending machines and R&D, but let's keep an eye on this. |
||
|
StrangeWeirdKitten
|
5e950115a6 | Merge remote-tracking branch 'skyrat/master' into upstream-12/19/2023 | ||
|
SkyratBot
|
3658c80e57 |
[MIRROR] Explodes device.dmi [MDB IGNORE] (#25523)
* Explodes device.dmi * Demodularize these * Update traitordevices.dm * Update traitordevices.dm * Modularizes hypnotic flash * Modular dmi repath * Modular dmi repath --------- Co-authored-by: YesterdaysPromise <122572637+YesterdaysPromise@users.noreply.github.com> Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com> |
||
|
YesterdaysPromise
|
71a1fee2f1 |
Explodes device.dmi (#80025)
## About The Pull Request I woke up today and thought 'what would be easy thing to do today so I can say I've done something?'. Then I remembered I saw several gangtool usages the time I split radio up, and I could remedy those. 7 hours later, device.dmi is split in a folder of its own, and I've also given unique sprites to door remotes and landing desginators. ## Why It's Good For The Game The device.dmi was kind of a mess. ## Changelog 🆑 /🆑 |
||
|
BurgerLUA
|
e5a678f874 |
Adds "Merged" and "Closed" stamps (#820)
## About The Pull Request Adds "Merged" and "Closed" stamps, along with fluff paper containing a random amount of randomly generated pull requests. They can be found in a briefcase in the RD's locker, or rarely in maint.  ## Why It's Good For The Game That damn griefer george melons came to me in a dream and asked me to make funny stamps. They can be found in the research director's locker, and also in maint. ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and it's effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 BurgerBB add: Adds "Merged" and "Closed" stamps. They can be found in the research director's locker. /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> <!-- By opening a pull request. You have read and understood the repository rules located on the main README.md on this project. --> |
||
|
SkyratBot
|
20fa5e6e2c |
[MIRROR] Removes some done todos (and ones that I think are dumb) [MDB IGNORE] (#25362)
* Removes some done todos (and ones that I think are dumb) (#80017) ## About The Pull Request Most of these are mine that I just forgot about, only one I think anyone cares about is the one in mobs.dm about making delta time match subsystem yielding, but I think it's a bad idea so it's gone Oh also, replaces an old comment of mine with an actual explanation (it's about the icon cache and shit) * Removes some done todos (and ones that I think are dumb) --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
LemonInTheDark
|
96f19b962a |
Removes some done todos (and ones that I think are dumb) (#80017)
## About The Pull Request Most of these are mine that I just forgot about, only one I think anyone cares about is the one in mobs.dm about making delta time match subsystem yielding, but I think it's a bad idea so it's gone Oh also, replaces an old comment of mine with an actual explanation (it's about the icon cache and shit) |
||
|
SkyratBot
|
69ea3c81ad |
[MIRROR] Mafia can be played on your PDA [MDB IGNORE] (#24485)
* Mafia can be played on your PDA (#78576) ## About The Pull Request Mafia is now friggin playable from the PDA, I also changed other stuff too - You can't use abilities on dead people if you're not supposed to (cant kill the same person over and over) - Changelings cant kill other Changelings - Changelings can now only talk to eachother at night, rather than using :j - Everyone starts spawned in the center of the map, since people playing on PDA can't move their characters. This is so everyone can hear PDA users in person, as I don't want the chat log to be mandatory. To do this, all messages you are meant to be able to see, is now logged for you to see in your Mafia panel. This essentially means that people playing through the PDA get a downgraded version of it, but I don't know how much larger I want this UI to be. Playing Mafia through the PDA will not tell you of other players ahead of time when signing up (as it shows ckeys + pdas), but they can see the names in-game. Unfortunately this means we'll have to remove your customization coming with you, to prevent using it to tell who is dead in round. Things I am missing - Program overlays on PDA/Laptop/Computer - Icon for the app's header while a game is active I'm not a spriter and can't make either of these This is the new UI  I also fixed alert calls for PDAs and stuff  and removed the X at the top on computers since they had no battery  Looks a little better now hopefully 👍 ## Why It's Good For The Game - The current Arcade app sucks, and is a solo game. This is much more entertaining and you can talk to others in it, which is swag as fuck. - There's a larger potential playerbase for the Minigame making it more likely to be played. - Sets groundwork for a better version of https://github.com/tgstation/tgstation/pull/75879 - Adds more suspense and teamwork in the minigame. ## Changelog 🆑 JohnFulpWillard, sprites by CoiledLamb add: You can now play Mafia on your PDA. balance: Mafia changelings can now only talk to eachother during the night. fix: Mafia abilities can't be repeatedly used on people. /🆑 * Mafia can be played on your PDA --------- Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> |
||
|
John Willard
|
26e3ea1e0d |
Mafia can be played on your PDA (#78576)
## About The Pull Request Mafia is now friggin playable from the PDA, I also changed other stuff too - You can't use abilities on dead people if you're not supposed to (cant kill the same person over and over) - Changelings cant kill other Changelings - Changelings can now only talk to eachother at night, rather than using :j - Everyone starts spawned in the center of the map, since people playing on PDA can't move their characters. This is so everyone can hear PDA users in person, as I don't want the chat log to be mandatory. To do this, all messages you are meant to be able to see, is now logged for you to see in your Mafia panel. This essentially means that people playing through the PDA get a downgraded version of it, but I don't know how much larger I want this UI to be. Playing Mafia through the PDA will not tell you of other players ahead of time when signing up (as it shows ckeys + pdas), but they can see the names in-game. Unfortunately this means we'll have to remove your customization coming with you, to prevent using it to tell who is dead in round. Things I am missing - Program overlays on PDA/Laptop/Computer - Icon for the app's header while a game is active I'm not a spriter and can't make either of these This is the new UI  I also fixed alert calls for PDAs and stuff  and removed the X at the top on computers since they had no battery  Looks a little better now hopefully 👍 ## Why It's Good For The Game - The current Arcade app sucks, and is a solo game. This is much more entertaining and you can talk to others in it, which is swag as fuck. - There's a larger potential playerbase for the Minigame making it more likely to be played. - Sets groundwork for a better version of https://github.com/tgstation/tgstation/pull/75879 - Adds more suspense and teamwork in the minigame. ## Changelog 🆑 JohnFulpWillard, sprites by CoiledLamb add: You can now play Mafia on your PDA. balance: Mafia changelings can now only talk to eachother during the night. fix: Mafia abilities can't be repeatedly used on people. /🆑 |
||
|
SkyratBot
|
b5f3de6ebd |
[MIRROR] More Plumbing Fixes & Pill Press UI Changes [MDB IGNORE] (#24458)
* More Plumbing Fixes & Pill Press UI Changes * Fixing diffs/ modular stuff * Modular * Update reagents.dm * Update pill_press.dm * Update pill_press.dm * Update pill_press.dm --------- Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com> |
||
|
SyncIt21
|
df508a51b2 |
More Plumbing Fixes & Pill Press UI Changes (#79059)
## About The Pull Request 1. Fixes #79051 It's a consequence of floating-point math. We round it to 2 decimal places to display results like 50 but in fact its actual value is something like 49.999... something. So, we also shift up our expectations and call it a day. 2. Made a lot of variables defines and lists static to save memory for plumbing pill press and moved global lists to it's global list folder 3. Copied over chem master patch & pill designs over too plumbing press and removed the old designs & resized the UI ## Changelog 🆑 fix: plumbing pill press & bottler won't stop when processing 50 unit bottles code: made a lot of variables defines and lists static to save memory for plumbing pill press. Moved global lists to it's rightful place code: copied over chem master pill & patch designs over to plumbing pill press and removed the old designs. resized UI /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
SkyratBot
|
e6d08225d2 |
[MIRROR] General code maintenance for rcd devices and their DEFINE file [MDB IGNORE] (#24300)
* General code maintenance for rcd devices and their DEFINE file * Update window.dm * Update window.dm * Update window.dm --------- Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
SyncIt21
|
66f726dfe3 |
General code maintenance for rcd devices and their DEFINE file (#78443)
## About The Pull Request The changes made can be best summarized into points **1. Cleans up `code/_DEFINES/construction.dm`** Looking at the top comment of this file https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/__DEFINES/construction.dm#L1 One would expect stuff related to materials, rcd, and other construction related stuff. Well this file is anything but Why is there stuff related to food & crafting over here then? https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/__DEFINES/construction.dm#L91-L94 It gets worse why are global lists declared here? https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/__DEFINES/construction.dm#L115 There is a dedicated folder to store global lists i.e. `code/_globalvars/lists` for lists like these. These clearly don't belong here On top of that a lot of construction related defines has been just dumped here making it too large for it's purposes. which is why this file has been scraped and it's 1. crafting related stuff have been moved to its `code/_DEFINES/crafting.dm` 2. global lists for crafting moved to `code/_globalvars/lists/crafting.dm` 3. Finally remaining construction related defines split apart into 4 file types under the new `code/_DEFINES/construction` folder - `code/_DEFINES/construction/actions.dm` -> for wrench act or other construction related actions - `code/_DEFINES/construction/material.dm` -> contains your sheet defines and cable & stack related values. Also merged `code/_DEFINES/material.dm` with this file so it belongs in one place - `code/_DEFINES/construction/rcd.dm` -> dedicated file for everything rcd related - `code/_DEFINES/construction/structures.dm` -> contains the construction states for various stuff like walls, girders, floodlight etc By splitting this file into multiple meaningful define file names will help in reducing merge conflicts and will aid in faster navigation so this is the 1st part of this PR **2. Debloats the `RCD.dm` file(Part 1)** This uses the same concepts as above. i.e. moving defines into their appropriate files for e.g. https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/game/objects/items/rcd/RCD.dm#L170 1. Global vars belong in the `code/_globalvars` folder so these vars and their related functions to initialize them are moved into the `code/_globalvars/rcd.dm` file 2. See this proc https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/game/objects/items/rcd/RCD.dm#L200 This proc does not belong to the `obj/item/construction/rcd` type it's a global "helper function" this is an effect proc as it creates rcd holograms so it has been moved to the `code/game/objects/effects/rcd.dm` file which is a global effect that can be used by anyone And with that we have moved these vars & procs into their correct places & reduced the size of this file . We can go even further **3. Debloats the `RCD.dm` file(Part 2)** This deals with the large list which contains all the designs supported by the RCD https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/game/objects/items/rcd/RCD.dm#L42 This list contains a lot of local defines. We can scrape some of them and reduce the overall bulkiness & memory requirements of this list and so the following defines ``` #define WINDOW_TYPE "window_type" #define COMPUTER_DIR "computer_dir" #define WALLFRAME_TYPE "wallframe_type" #define FURNISH_TYPE "furnish_type" #define AIRLOCK_TYPE "airlock_type" #define TITLE "title" #define ICON "icon" #define CATEGORY_ICON_STATE "category_icon_state" #define CATEGORY_ICON_SUFFIX "category_icon_suffix" #define TITLE_ICON "ICON=TITLE" ``` Have all been removed making this list a lot more cleaner. Why? because a lot of these are just semantic sugar, we can infer the value of a lot of these defines if we just know the type path of the structure the rcd is trying to build for e.g. take these 2 defines https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/game/objects/items/rcd/RCD.dm#L13-L15 These defines tell the rcd UI the name and the icon it should display. Rather than specifying these manually in the design we can infer them like this ``` var/obj/design = /obj/structure/window //let's say the rcd is trying to build an window var/name = initial(design.name) //we have inferred the name of the design without requiring TITLE define var/icon = initial(design.icon_state) //we have inferred the icon of the design without requiring ICON define ``` And so by using similar logic to the remaining defines we can eliminate a lot of these local defines and reduce the overall size of this list. The same logic applies to the different modes of construction, the following defines https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/__DEFINES/construction.dm#L186-L192 Have all been removed and replaced with a single value `RCD_STRUCTURE` All these modes follow the same principle when building them 1. First check the turf if the structure exists. If it does early return 2. If not create a new structure there and that's it So rather than creating a new construction mode every time you want to add a new design we can use this mode to apply this general approach every time The design list has also now been made into a global list rather than a private static list. The big advantage to this is that the rcd asset cache can now access this list and load the correct icons from the list directly. This means you no longer have to manually specify what icons you want to load which is the case currently. https://github.com/tgstation/tgstation/blob/0fb8b8b218400b3f1805ae81e9bb0364d7a4e9c6/code/modules/asset_cache/assets/rcd.dm#L8-L9 This has lead to the UI icons breaking twice now in the past - #74194 - #77217 Hopefully this should never repeat itself again **4. Other RCD like device changes** - Fixed the broken silo link icon when the radial menu of the RLD was opened - replaced a lot of vars inside RLD with defines to save memory - Small changes to `ui_act` across RCD, Plumbing RCD and RTD - Removed unused vars in RCD and snowflaked code - Moved a large majority of `ui_data()` to `ui_static_data()` making the experience much faster Just some general clean up going on here **5. The Large majority of other code changes** These are actually small code changes spread across multiple files. These effect the `rcd_act()` & the `rcd_vals()` procs across all items. Basically it - Removes a large majority of `to_chat()` & `visible_message()` calls. This was done because we already have enough visual feedback of what's going on. When we construct a wall we don't need a `to_chat()` to tell us you have a built a wall, we can clearly see that - replaces the static string `"mode"` with a predefined constant `RCD_DESIGN_MODE` to bring some standard to use across all cases Should reduce chat spam and improve readability of code. **6. Airlock & Window names** The rcd asset cache relies on the design name to be unique. So i filled in the missing names for some airlocks & windows which are subjective and open to change but must have some value **7 Removes Microwave PDA upgrade** The RCD should not be allowed to build this microwave considering how quickly it can spawn multiple structures and more importantly as it's a special multipurpose machine so you should spend some effort in printing it's parts and acquiring tools to complete it. This upgrade makes obsolete the need to carry an - A RPED to install the parts - A screwdriver to complete the frame - The circuit board for the microwave The most important point to note here is that whenever an RPED/circuit board is printed at an lathe it charges you "Lathe Tax". The RCD with this upgrade would essentially bypass the need to "Pay Taxes" at these lathes as you are just creating a circuit board from thin air. This causes economy imbalance(10 cr per print) which scales up the more of these machines you make so to avoid this let's end the problem here Not to mention people would not find the need to print the circuit board for a regular microwave now if they have an RCD because they can just make this microwave type making the need for a regular microwave completely pointless. Just build a machine frame with the RCD and complete the microwave from there ## Changelog 🆑 code: moved global vars, lists and helper procs for construction related stuff to their appropriate files code: reduced overall code size & memory of rcd design list and removed unused defines refactor: removed a ton of chat alerts for rcd related actions to help reduce chat spam refactor: some airlock & window default names have changed fix: broken icon in radial menu of rld silo link remove: removes microwave pda upgrade from RCD. It's a special machine so spend some time in building it rather than shitting them out for free with the RCD. Use the RCD upgrade to spawn a machine frame instead & go from there /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
SkyratBot
|
981503afc6 |
[MIRROR] Microwave upgrades: Microwave PDA charging, power cells [MDB IGNORE] (#24283)
* Microwave upgrades: Microwave PDA charging, power cells * skyrat edit --------- Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com> |
||
|
lessthanthree
|
c2fb08407a |
Microwave upgrades: Microwave PDA charging, power cells (#78717)
## About The Pull Request For the hard-working tradesperson who's in the middle of nowhere and just wants to warm up their pastry-based savoury item purchased from an overpriced vending machine, introduces the engineer themed wireless microwave. No more going hungry in a pinch, this variant uses changeable power cells instead of APC power. Can be built normally or printed with a furnishings-upgraded RCD. The other upgrade now available: PDA charging. Upgrade the capacitors in the microwave to add a Charge mode for your portable device! Also cleans up microwave code a bit and adds much needed context hints for when it's broken, dirty, etc. Swaps a few break room microwaves to upgraded variants on mapload, adds a microwave/donks to Birdshot, donks to Tramstation. ## Why It's Good For The Game Slap together a semi-portable microwave with your components on hand, have an engineering picnic in space or wherever else the day takes you. With increased PDA drain, adding another option to charge your PDA in common areas is useful. Microwaves are already strategically placed around the station. Please ensure the model you're using has the charging feature before operating.   ## Changelog 🆑 LT3 add: Introducing Nanotrasen Wave! A Nanotrasen exclusive, Waveallows your PDA to be charged wirelessly through microwave frequencies. You can Wave-charge your device by placing it inside a compatible microwave and selecting the charge mode. add: Microwaves can be upgraded to add wireless charging add: Cell-swappable microwave for the engineer on-the-go add: Microwave now has a wire to swap charge/cook modes add: Furnishings RCD upgrade now includes wireless microwave add: Tramstation and Birdshot engineering break rooms now have microwave and donk pockets. Some microwaves come pre-equipped with wireless charging and an upgraded cell. fix: The microwave in the snowdin ruin is now real, not a fluff prop /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
SkyratBot
|
9557d7c8b7 |
[MIRROR] Reworks the fishing minigame into a game screen object from a TGUI interface [MDB IGNORE] (#23772)
* Reworks the fishing minigame into a game screen object from a TGUI interface (#78052) Refactors fishing minigame from tgui window to dm screen objects * Reworks the fishing minigame into a game screen object from a TGUI interface --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
Ghom
|
da42afcbae |
Reworks the fishing minigame into a game screen object from a TGUI interface (#78052)
Refactors fishing minigame from tgui window to dm screen objects |
||
|
SkyratBot
|
0e533de6cf |
[MIRROR] Multi-tile airlock assemblies/pathing [NO GBP] [MDB IGNORE] (#23138)
* Multi-tile airlock assemblies/pathing [NO GBP] (#77537) ## About The Pull Request Small fixes after https://github.com/tgstation/tgstation/pull/76732 - Creates base large subtype for mapping - Door assembly naming consistent with other airlocks - Base subtype large airlock no longer spawns in a normal sized airlock - Renames station2 subtype to public for consistency ## Changelog 🆑 LT3 fix: Base large airlock subtype no longer spawns a normal sized airlock image: Added mapping icons for large airlocks code: Repathed all public airlocks to consistent naming /🆑 * Multi-tile airlock assemblies/pathing [NO GBP] * maps * Merge remote-tracking branch 'upstream/master' into upstream-merge-77537 --------- Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com> |
||
|
lessthanthree
|
635bae421f |
Multi-tile airlock assemblies/pathing [NO GBP] (#77537)
## About The Pull Request Small fixes after https://github.com/tgstation/tgstation/pull/76732 - Creates base large subtype for mapping - Door assembly naming consistent with other airlocks - Base subtype large airlock no longer spawns in a normal sized airlock - Renames station2 subtype to public for consistency ## Changelog 🆑 LT3 fix: Base large airlock subtype no longer spawns a normal sized airlock image: Added mapping icons for large airlocks code: Repathed all public airlocks to consistent naming /🆑 |
||
|
SkyratBot
|
2644a9e37d |
[MIRROR] New Mech UI and equipment refactor [MDB IGNORE] (#23098)
* New Mech UI and equipment refactor * Update mecha_defense.dm * Update clothing.dm --------- Co-authored-by: Andrew <mt.forspam@gmail.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
Andrew
|
2d34c7433a |
New Mech UI and equipment refactor (#77221)
 ## About The Pull Request Made a new UI and refactored some mech code in the process. Fixes #66048 Fixes #77051 Fixes #65958 ??? if it was broken Fixes #73051 - see details below Fixes other undocumented things, see changelog. ## Why It's Good For The Game The UI was too bulky and Mechs were too complex for no reason. Now they follow some general rules shared between other SS13 machinery, and there is less magic happening under the hood. ## Detailed Changes ### New Mech UI, Air Tank and Radio as separate modules Previous UI for comparison: <img alt="9SScrXAOjy" src="https://github.com/tgstation/tgstation/assets/3625094/904e3d07-e7d7-4d3a-a062-93e0e35b4b66"> Previously mechs came with radio pre-installed and air canisters magically pre-filled with air even when you build one in fab. Radio and Air Tanks are now both utility modules that are optional to install. Gas RCS thrusters still require Air Tank module to operate. This made the Mechs more barebones when built, giving you only the basic functionality. <img alt="5SDMlXTJxv" src="https://github.com/tgstation/tgstation/assets/3625094/b9364230-49ac-416b-aa70-e851fbf2050e"> To compensate this change, all mechs got two extra utility module slots. All other modules got new UI. And ore box now shows the list of ores inside. <img alt="SRX5FjvsHA" src="https://github.com/tgstation/tgstation/assets/3625094/cbe2e98d-1cd4-4667-8dae-2f9227b4b265"> ### Mounted Radio Works as a normal radio, but with subspace transmission. Available from the basic mech research node and can be printed in fab. ### Cabin Sealing To compensate for the lack of air tank by default, mechs with enclosed cabin (e.g. all except Ripley) got an ability to toggle cabin exposure to the outside air. Exiting the mech makes cabin air automatically exposed. When you seal the cabin, it traps some of the outside air inside the cabin and you can breathe with this air to perform a short space trips. But the oxygen will run out quickly and CO2 will build up. Sealing the cabin in space will make the cabin filled with vacuum, and it will stay there until you return to air environment and unseal the cabin, letting the breathable air to enter. There are temperature and pressure sensors that turn yellow/red when the corresponding warning thresholds are reached. You could also use personal internals in combination with cabin sealing for long space travels, so Air Tank is completely optional now and mostly needed when you need RCS thruster. ### RCS thrusters They are now available earlier in tech tree and consume reasonable amount of air (5 times more than human jetpacks), and they don't work without Mounted Air Tank, unless it's an Ion thruster variant. ### Mounted Air Tank Available from the basic mech research node and can be printed in fab. Built model comes empty, and syndicate mechs come with one full of oxygen. <img alt="GrFDrH5Hwe" src="https://github.com/tgstation/tgstation/assets/3625094/b677b705-bda0-4c8c-96c7-d32bf7bf9f28"> Can be switched to pressurize or not pressurize the cabin. Releases gas only when the cabin is sealed shut. Starts releasing automatically, but can be toggled to not release if you want to use it just as a portable canister. Cabin pressure can now be configured in the module UI instead of Maintenance UI. Can be attached to a pipe network when the mech is parked above a connection port. Comes with a pump that works similarly to the portable pump. It lets you vent the air tank contents outside, or suck air from the room to fill the air tank. Intended to provide an ability to fill the air tank without the need to bother with pipes. Also has gas sensors that display gas mix data of the tank and the cabin (when sealed). ### Stock part changes All mechs now require a servo motor and they reduce mech movement power consumption instead of scanning module. Scanning modules are optional for mech operation (still required to build) and the lack of one disables the following UI elements: - Display of mech integrity (you can still see the alerts or examine the mech to get rough idea) - Display of mech status on internal damage (and you can't repair what you can't diagnose) The rating of scanning module doesn't have any effect as of now. Cargo mech comes without it roundstart. <img alt="2vDtt99oqb" src="https://github.com/tgstation/tgstation/assets/3625094/147144ca-824e-4501-acf5-6ee104f309e7"> Capacitors now also reduce light power usage and raise the overclocking temperature thresholds (see below). ### Maintenance Maintenance UI removed, and its logic migrated to other places. Access modification now managed inside the mech, and anyone who can control the mech, can adjust the access in the same way as they can set DNA key. To open the maintenance panel you just need a screwdriver. It is instant when the mech is empty and it has a 5 second delay when there is an occupant to avoid in-combat hacking and part removal. It will alert the occupant that someone is trying to tinker with their mech.  Once the panel is open, you can see the part ratings:  With open panel you can hack the mech wires (roboticists can now see them): <img alt="mj205G2qDa" src="https://github.com/tgstation/tgstation/assets/3625094/44cea0d1-44b4-4b50-b1d3-a97c0056bab3"> There are wires for: - Enabling/Disabling ID and DNA locks - Toggling mech lights - Toggling mech circuits malfunction (battery drain, sparks) - Toggling mech equipment malfunction (to repair after EMP or cause EMP-like effect, disarming mech) - 3 dud wires that do nothing The hacker may be shocked if the mech power cell allows. When the panel is open and the user has access to the mech, they can remove parts with a crowbar: <img alt="jR40gyTWtJ" src="https://github.com/tgstation/tgstation/assets/3625094/b573f5b9-b8ea-412e-b3e0-c872e01e0c23"> Hitting the mech with an ID from outside now toggles the ID Lock on/off if the ID has sufficient access. ### Power consumption and overclocking Rebalanced mech power consumption. T4 parts were not working in Syndicate Mechs, as their effect was not calculated until you manipulate parts manually. Constructed mechs with t1 parts even had their energy drain reduced with upgrade to t1. Now all mechs apply their base step power usage correctly don't ignore the stock parts. Servo tier now reduces base power consumption by 0% at t1, 50% at t2, 33% at t3 and 25% at t4 Capacitor tier now reduces base power consumption of mele attacks, phasing and light by the same amounts. Gygax leg actuators overload replaced with mech overclocking. Any mech can be overclocked by hacking wires, but only Gygax has a button for toggling it from the Cabin. Now there is an overclock coefficient. 1.5 for Gygax and other mechs, 2 for Dark Gygax. When overclocked, mechs moves N times faster, but consumes N times more power.  While overclocked, mech heats up every second, regardless of movement, and starts receiving internal and integrity damage after a certain temperature threshold. The chance is 0% at the threshold, and 100% at thresholds * 2. The roll happens every tick. Capacitor upgrades this threshold, letting you overclock safely for longer periods.  When you stop overclock, the temperature goes back down. ### Other changes and fixes Concealed weapon bay now doesn't show up when you examine the mech, so it's actually concealed now. New radio module can properly change its frequency, as it didn't work for previous radio. Launcher type weapons were ignoring cooldowns and power usage, so you could spam explosive banana peals, while they should have a 2 second cooldown: <img alt="q5GjUsHwGr" src="https://github.com/tgstation/tgstation/assets/3625094/d102725d-e9e1-4588-9d6c-b9e38b7a6535"> Now this is fixed and all launcher type weapons properly use power and have their cooldowns working. And now they have the kickback effect working (when it pushes you in the opposite direction in zero gravity on throw). Thermoregulator now heats/cools considering heat capacity instead of adding/reducing flat 10 degrees. So you can heat up cabin air quicker if the pressure is low. There were some other sloppy mistakes in mech code, like some functions returning too early, blocking other functionality unintentionally. Fixed these and made some other minor changes and improvements. ## Changelog 🆑 refactor: Refactored Mech UI refactor: Refactored mech radio into a utility module, adding extra slot to all mechs refactor: Refactored mech air tank into a utility module with an air pump, adding extra slot to all mechs refactor: Refactored mech cabin air - there is now a button to seal or unseal cabin to make it airtight or exchanging gases with the environment refactor: Removed mech maintenance UI Access is set in mech UI, and parts are ejected with a crowbar add: Mech now has wires and can be hacked qol: Roboticists now can see MOD suit and mech wires add: Mechs now require servo motor stock part and it affects movement power usage instead of scanning module add: Scanning module absence doesnt block mech movement and hides some UI data instead. Big Bess starts without one. qol: Hitting mech with ID card now toggles ID lock on/off if the card has required access fix: Fixed concealed weapon bay not being concealed on mech examine fix: Fixed mech radio not changing frequency fix: Fixed mech launcher type weapons ignoring specified cooldown fix: Fixed mech launcher type weapons not using specified power amount fix: Fixed mech temperature regulator ignoring gas heat capacity fix: Fixed mech stopping processing other things while not heating internal air fix: Fixed mech being able to leave transit tube in transit fix: Fixed mech internal damage flags working incorrectly fix: Fixed Gygax leg overloading being useless fix: Fixed mechs ignoring their stock parts on creation. Syndicate mechs now stronger against lasers and consume less energy on move. Upgrading from tier 1 to tier 2 doesn't make mech consume MORE energy than before the upgrade. balance: Rebalanced mech energy drain with part upgrades. Base energy drain reduced by 50%, 33%, 25% with upgrades and applies to movement (Servo rating), phasing, punching, light (Capacitor rating). balance: Hydraulic clamp now can force open airlocks balance: Made mech RCS pack consume reasonable amount of gas code: Fixed some other minor bugs and made some minor changes in the mech code /🆑 --------- Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: Sealed101 <cool.bullseye@yandex.ru> Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
SkyratBot
|
af9f02fa1e |
[MIRROR] Fix broken icons in RCD UI (Again) [MDB IGNORE] (#22814)
* Fix broken icons in RCD UI (Again) (#77217) ## About The Pull Request RCD UI has some broken icons  Its fixed now  ## Changelog 🆑 fix: broken icons in RCD UI /🆑 * Fix broken icons in RCD UI (Again) --------- Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> |
||
|
SyncIt21
|
0783909122 |
Fix broken icons in RCD UI (Again) (#77217)
## About The Pull Request RCD UI has some broken icons  Its fixed now  ## Changelog 🆑 fix: broken icons in RCD UI /🆑 |
||
|
SkyratBot
|
08c90f2116 |
[MIRROR] [MDB IGNORE] Angled Lights & Lighting Prototyping Tool [MDB IGNORE] (#22582)
* [MDB IGNORE] Angled Lights & Lighting Prototyping Tool (#74365) ## About The Pull Request Hello friends, I've been on a bit of a lighting kick recently, and I decided I clearly do not have enough things to work on as it is. This pr adds angle support to static lights, and a concepting/debug tool for playing with lights on a map. Let's start from first principles yeah? ### Why Angled Lights? Mappers, since they can't actually see a light's effect in editor, tend to go off gut. That gut is based more off what "makes sense" then how things actually work This means they'll overplace light sources, and also they tend to treat lights, particularly light "bars" (the bigger ones) as directional. So you'll have two lights on either sides of a pillar, lights inside a room with lights outside pointing out, etc.  This has annoying side effects. A lot of our map is overlit, to the point that knocking out a light does.... pretty much nothing. I find this sad, and would like to work to prevent it. I think dark and dim, while it does not suit the normal game, is amazing for vibes, and I want it to be easier to see that. Angled lights bring how lights work more in line with how mappers expect lights work, and avoids bleedover into rooms that shouldn't be bled into, working towards that goal of mine. ### How Angled Lights? This is more complex then you'd first think so we'll go step by step  Oh before we start, some catchup from the last time I touched lighting code. Instead of doing a lighting falloff calculation for each lighting corner (a block that represents the resolution of our lights) in view we instead generate cached lightsheets. These precalculate and store all possible falloffs for x and y distances from a source. This is very useful for angle work, since it makes it almost totally free. Atoms get 2 new values. light_angle and light_dir Light angle is the angle the light uses, and light_dir is a cardinal direction it displays in We take these values, and inside sheetbuilding do some optional angle work. getting the center angle, the angle of a pair of coords, and then the delta between them. This is then multiplied against the standard falloff formula, and job done. We do need some extra fenangling to make this all work nicely tho. We currently use a pixel turf var stored on the light source to do distance calculations. This is the turf we pretend the light source is on for visuals, most often used to make wall lights work nice. The trouble is it's not very granular, and doesn't always have the effect you might want. So, instead of generating and storing a pixel turf to do our distance calculations against, we store x and y offset variables. We use them to expand our working range and sheet size to ensure things visually make sense, and then offset any positions by them. I've added a way for sources to have opinions on their offsets too, and am using them for wall lights. This ensures the angle calculations don't make the wall behind a light fulldark, which would be silly. ### Debug Tool? In the interest of helping with that core problem, lights being complex to display, I've added a prototyping tool to the game. It's locked behind mapping verbs, and works about like this. Once the verb is activated, it iterates over all the sources in the world (except turfs because those are kinda silly), outlining and "freezing" them, preventing any future changes. Then, it adds 3 buttons to the owners of a light source.  The first button toggles the light on and off, as desired. The third allows you to move the source around, with a little targeting icon replacing your mouse The second tho, that's more interesting. The second button opens a debug menu for that light  There's a lot here, let's go through it. Bit on the left is a list of templates, which allow you to sample existing light types (No I have no idea why the background is fullwhite, need to work on that pre merge) You can choose one by clicking it, and hitting the upload button. This replaces your existing lighting values with the template's, alongside replacing its icon and icon state so it looks right. There are three types as of now, mostly for categorization. Bar, which are the larger typically stronger lights, Bulb, which are well, bulbs, and Misc which could be expanded, but currently just contains floor lights. Alongside that you can manually edit the power, range, color and angle of the focused light. I also have support for changing the direction of the light source, since anything that uses directional lighting would also tie light dir to it. This isn't *always* done tho, so I should maybe find a way to edit light dir too. My hope is this tool will allow for better concepting of a room's lights, and easier changing of individual object's light values to suit the right visuals. ### Lemon No Why What Ok so I applied angle lights to bars and bulbs, which means I am changing the lighting of pretty much every map in the codebase. I'm gonna uh, go check my work. Alongside this I intend to give lighting some depth. So if there's room to make a space warmer, or highlight light colors from other sources, I will do that. (Images as examples)  I also want to work on that other goal of mine, making breaking lights matter. So I'll be doing what I can to ensure you only need to break one light to make a meaningful change in the scene. This is semi complicated by one light source not ever actually reaching fullbright on its own, but we do what we must because we can.  I'm as I hope you know biased towards darker spaces, I think contrast has vibes. In particular I do not think strong lights really suit maintenance. Most of what is used there are bulbs, so I'm planning on replacing most uses with low power bulbs, to keep light impacts to rooms, alongside reducing the amount of lights placed in the main tunnels  **If you take issue with this methodology please do so NOW**, I don't want to have to do another pass over things. Oh also I'm saving station maps for last since ruins are less likely to get touched in mapping march and all. ### Misc + Finishing Thoughts Light templates support mirroring vars off typepaths using a subtype, which means all the templates added here do not require updating if the source type changes somehow. I'd like to expand the template list at some point, perhaps in future. I've opened this as a draft to make my intentions to make my changes to lights known, and to serve as motivation for all the map changes I need to do. ### Farish Future I'm unhappy with how we currently configure lights. I would like a system that more directly matches the idea of drawing falloff curves, along with allowing for different falloffs for different colors, alongside extending the idea to angle falloff. This would make out of engine lighting easier, allow for nicer looking lights (red to pink, blue to purple, etc), and improve accessibility by artists. This is slightly far off, because I have other obligations and it's kinda complicated, but I'd like to mention it cause it's one of my many pipedreams. ## Changelog 🆑 add: Added angle lighting, applies it to most wall lights! add: Adds a lighting prototyping tool, mappers go try it out (it's locked behind the mapping verb) /🆑 --------- Co-authored-by: MMMiracles <lolaccount1@ hotmail.com> * [MDB IGNORE] Angled Lights & Lighting Prototyping Tool * Update north_star.dmm * Revert "Update north_star.dmm" This reverts commit bb5b8b5a549f7edc3e23a369a147ed96bab41991. * Updatepaths * Update nukie_base.dmm * Newer version of northstar with the penguins * Update northstar_cryo.dmm --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: MMMiracles <lolaccount1@ hotmail.com> Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com> Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com> |
||
|
LemonInTheDark
|
41f20bc3ce |
[MDB IGNORE] Angled Lights & Lighting Prototyping Tool (#74365)
## About The Pull Request Hello friends, I've been on a bit of a lighting kick recently, and I decided I clearly do not have enough things to work on as it is. This pr adds angle support to static lights, and a concepting/debug tool for playing with lights on a map. Let's start from first principles yeah? ### Why Angled Lights? Mappers, since they can't actually see a light's effect in editor, tend to go off gut. That gut is based more off what "makes sense" then how things actually work This means they'll overplace light sources, and also they tend to treat lights, particularly light "bars" (the bigger ones) as directional. So you'll have two lights on either sides of a pillar, lights inside a room with lights outside pointing out, etc.  This has annoying side effects. A lot of our map is overlit, to the point that knocking out a light does.... pretty much nothing. I find this sad, and would like to work to prevent it. I think dark and dim, while it does not suit the normal game, is amazing for vibes, and I want it to be easier to see that. Angled lights bring how lights work more in line with how mappers expect lights work, and avoids bleedover into rooms that shouldn't be bled into, working towards that goal of mine. ### How Angled Lights? This is more complex then you'd first think so we'll go step by step  Oh before we start, some catchup from the last time I touched lighting code. Instead of doing a lighting falloff calculation for each lighting corner (a block that represents the resolution of our lights) in view we instead generate cached lightsheets. These precalculate and store all possible falloffs for x and y distances from a source. This is very useful for angle work, since it makes it almost totally free. Atoms get 2 new values. light_angle and light_dir Light angle is the angle the light uses, and light_dir is a cardinal direction it displays in We take these values, and inside sheetbuilding do some optional angle work. getting the center angle, the angle of a pair of coords, and then the delta between them. This is then multiplied against the standard falloff formula, and job done. We do need some extra fenangling to make this all work nicely tho. We currently use a pixel turf var stored on the light source to do distance calculations. This is the turf we pretend the light source is on for visuals, most often used to make wall lights work nice. The trouble is it's not very granular, and doesn't always have the effect you might want. So, instead of generating and storing a pixel turf to do our distance calculations against, we store x and y offset variables. We use them to expand our working range and sheet size to ensure things visually make sense, and then offset any positions by them. I've added a way for sources to have opinions on their offsets too, and am using them for wall lights. This ensures the angle calculations don't make the wall behind a light fulldark, which would be silly. ### Debug Tool? In the interest of helping with that core problem, lights being complex to display, I've added a prototyping tool to the game. It's locked behind mapping verbs, and works about like this. Once the verb is activated, it iterates over all the sources in the world (except turfs because those are kinda silly), outlining and "freezing" them, preventing any future changes. Then, it adds 3 buttons to the owners of a light source.  The first button toggles the light on and off, as desired. The third allows you to move the source around, with a little targeting icon replacing your mouse The second tho, that's more interesting. The second button opens a debug menu for that light  There's a lot here, let's go through it. Bit on the left is a list of templates, which allow you to sample existing light types (No I have no idea why the background is fullwhite, need to work on that pre merge) You can choose one by clicking it, and hitting the upload button. This replaces your existing lighting values with the template's, alongside replacing its icon and icon state so it looks right. There are three types as of now, mostly for categorization. Bar, which are the larger typically stronger lights, Bulb, which are well, bulbs, and Misc which could be expanded, but currently just contains floor lights. Alongside that you can manually edit the power, range, color and angle of the focused light. I also have support for changing the direction of the light source, since anything that uses directional lighting would also tie light dir to it. This isn't *always* done tho, so I should maybe find a way to edit light dir too. My hope is this tool will allow for better concepting of a room's lights, and easier changing of individual object's light values to suit the right visuals. ### Lemon No Why What Ok so I applied angle lights to bars and bulbs, which means I am changing the lighting of pretty much every map in the codebase. I'm gonna uh, go check my work. Alongside this I intend to give lighting some depth. So if there's room to make a space warmer, or highlight light colors from other sources, I will do that. (Images as examples)  I also want to work on that other goal of mine, making breaking lights matter. So I'll be doing what I can to ensure you only need to break one light to make a meaningful change in the scene. This is semi complicated by one light source not ever actually reaching fullbright on its own, but we do what we must because we can.  I'm as I hope you know biased towards darker spaces, I think contrast has vibes. In particular I do not think strong lights really suit maintenance. Most of what is used there are bulbs, so I'm planning on replacing most uses with low power bulbs, to keep light impacts to rooms, alongside reducing the amount of lights placed in the main tunnels  **If you take issue with this methodology please do so NOW**, I don't want to have to do another pass over things. Oh also I'm saving station maps for last since ruins are less likely to get touched in mapping march and all. ### Misc + Finishing Thoughts Light templates support mirroring vars off typepaths using a subtype, which means all the templates added here do not require updating if the source type changes somehow. I'd like to expand the template list at some point, perhaps in future. I've opened this as a draft to make my intentions to make my changes to lights known, and to serve as motivation for all the map changes I need to do. ### Farish Future I'm unhappy with how we currently configure lights. I would like a system that more directly matches the idea of drawing falloff curves, along with allowing for different falloffs for different colors, alongside extending the idea to angle falloff. This would make out of engine lighting easier, allow for nicer looking lights (red to pink, blue to purple, etc), and improve accessibility by artists. This is slightly far off, because I have other obligations and it's kinda complicated, but I'd like to mention it cause it's one of my many pipedreams. ## Changelog 🆑 add: Added angle lighting, applies it to most wall lights! add: Adds a lighting prototyping tool, mappers go try it out (it's locked behind the mapping verb) /🆑 --------- Co-authored-by: MMMiracles <lolaccount1@hotmail.com> |
||
|
SkyratBot
|
2f552919c1 |
[MIRROR] Icons folder cleaning wave two [MDB IGNORE] (#22454)
* Icons folder cleaning wave two * Merge conflict resolution * Modular path hell * hmm * Update 2022-10.yml * Another modular thing --------- Co-authored-by: YesterdaysPromise <122572637+YesterdaysPromise@users.noreply.github.com> Co-authored-by: Giz <vinylspiders@gmail.com> |
||
|
Bloop
|
4ae00db524 |
[MISSED MIRROR] makes the rcd able to make girders (#76515) (#22466)
makes the rcd able to make girders (#76515) ## About The Pull Request rcd can make girders at half the cost of making a wall in 1.3 seconds ## Why It's Good For The Game more "rapid" than using iron for girders and putting whatever material on it ## Changelog 🆑 add: rcd can make girders now /🆑 Co-authored-by: jimmyl <70376633+mc-oofert@users.noreply.github.com> |
||
|
YesterdaysPromise
|
fb10121022 |
Icons folder cleaning wave two (#76788)
## About The Pull Request Further continous organizing and cleaning the Icons folder. There are still some minior nitpicks left to do, but I reached my daily sanity expenses limit again, and the faster these get in the less issues for both me and others later. Also cleans some mess I caused by my blindness last PR. ## Why It's Good For The Game Saner spriters = better sprites |
||
|
SkyratBot
|
2f5c7f8389 |
[MIRROR] Icon folder cleaning wave one [MDB IGNORE] (#22374)
* Icon folder cleaning wave one * Fixe a merge conflict * Fixes some more merge conflicts * Fixes some modular icon paths * Fixes even more modular icon paths... Hopefully that's the last of them * Fixes some merge discrepencies * More merge issues * ok * not ok --------- Co-authored-by: YesterdaysPromise <122572637+YesterdaysPromise@users.noreply.github.com> Co-authored-by: Giz <vinylspiders@gmail.com> |
||
|
YesterdaysPromise
|
a373b4cb08 |
Icon folder cleaning wave one (#76703)
## About The Pull Request Due to a mental breakdown caused by unfathomable abomination that is icons folder, I swore to myself to one day clean it. Today is kind of that day. Been at it for around 6, you gotta understand I need a rest. I tracked most changes in descriptions of commits if you are looking for details. ## Why It's Good For The Game Saner spriters make better sprites. And also, just helps keep track of things. ## Changelog 🆑 image: added sprites for different variants of scrolls. image: modified couple posters with ghost pixels. /🆑 --------- Co-authored-by: OrionTheFox <76465278+OrionTheFox@users.noreply.github.com> |
||
|
jimmyl
|
b095659cde |
makes the rcd able to make girders (#76515)
## About The Pull Request rcd can make girders at half the cost of making a wall in 1.3 seconds ## Why It's Good For The Game more "rapid" than using iron for girders and putting whatever material on it ## Changelog 🆑 add: rcd can make girders now /🆑 |
||
|
SkyratBot
|
1beff3980c |
[MIRROR] Air Sensor are Craftable, Removed from RPD UI, Have New Linking System [MDB IGNORE] (#21964)
* Air Sensor are Craftable, Removed from RPD UI, Have New Linking System (#75869) ## About The Pull Request **1. Craftable & Removed from RPD UI** 1. Air sensor's are now craftable 2. You can turn them on/off with hand. Even though turning off the sensor will change it to a diffrent type[from `obj/machinery/air_sensor` -> `obj/item/air_sensor`] it's I/O port's are sill preserved when turning them on although you have to assign it a new name again which is usefull if you want to change the sensor's purpose in game. 3. They can now only be deconstructed by a welding tool and should be wrenched in place to turn them on. 4. Turned off air sensor's once unwrenched can be picked up like any regular item 5. Air sensor's are removed from the RPD UI because they don't go with pipes so it logically doesn't make sense to group them with pipe related device's Removed unused code in the process https://github.com/tgstation/tgstation/assets/110812394/3439a0f3-9c48-43ac-8f4b-98135435ec13 **2. New ID System** The problem with air sensor's is that each sensor is assigned a unique ID which is then stored in `GLOB.objects_by_id_tag` list. Each sensor name it's assigned based on the gas it's trying to sense(for naming only even though it can detect other gases) So if 2 sensor's having the same ID are made they will overwrite each other in this list leaving one sensor orphaned in the world which cannot be referenced because it's value was overwritten by a new sensor having the same ID in this list. The Solution? Rather than having all atmos computer's look up sensor's from this 1 global list make each computer keep track of all sensor's it's responsible for in it's own local list[which i called `connected_sensor's`] this way 2 sensor's can have randomly generated names in the global `GLOB.objects_by_id_tag` list but the computer will know what sensor to look up in this list based on the stored sensor ID's in the `connected_sensor's` list Basically what i am getting at is now you can make as many air sensor's as you wish but you will know have to connect that sensor to the computer using a multitool. Notice in the video how i made 2 sensor's called `Supermatter Chamber Sensor's`] and every time you try to connect an sensor which has the same name[`Supermatter Chamber Sensor's` in this case] they will ovewrite the old sensor in it's list as shown in the video https://github.com/tgstation/tgstation/assets/110812394/b5283c3b-c8a1-4b94-a6a8-8ba7a0007615 **Why it's good for the game**  I agree. Also air sensor's taking up a full Tab/Section in the RPD UI wasted a lot of UI space so that's removed now. Also making the air sensor's wrenchable and pickable item's was also requested in https://github.com/tgstation/tgstation/pull/72019#issuecomment-1355499873 so you relate them to device's like meter's Another huge issue was that the number of air sensor's you can make in the world was limited because each sensor in the world must have a unique ID but that's finally fixed now so yeah make as many sensor's as you want. ## Changelog 🆑 add: air sensor's are craftable refactor: air sensor's can now be turned off by hand and can only be deconstructed by a welding tool refactor: removed `Params()` proc qol: unwrenched air sensors can be picked up & recycled like regular item's del: air sensor are removed from the RPD UI qol: air sensor's are no longer restricted by their unique ID's which mean you can craft as many air sensors as you want. /🆑 --------- Co-authored-by: Time-Green <timkoster1@ hotmail.com> * Air Sensor are Craftable, Removed from RPD UI, Have New Linking System --------- Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: Time-Green <timkoster1@ hotmail.com> |
||
|
Zonespace
|
706b66ddfb |
Adds Solfed stamp, recolors NRI stamp (#21861)
adds solfed stamp, redoes NRI stamp |
||
|
SyncIt21
|
903eea5a69 |
Air Sensor are Craftable, Removed from RPD UI, Have New Linking System (#75869)
## About The Pull Request **1. Craftable & Removed from RPD UI** 1. Air sensor's are now craftable 2. You can turn them on/off with hand. Even though turning off the sensor will change it to a diffrent type[from `obj/machinery/air_sensor` -> `obj/item/air_sensor`] it's I/O port's are sill preserved when turning them on although you have to assign it a new name again which is usefull if you want to change the sensor's purpose in game. 3. They can now only be deconstructed by a welding tool and should be wrenched in place to turn them on. 4. Turned off air sensor's once unwrenched can be picked up like any regular item 5. Air sensor's are removed from the RPD UI because they don't go with pipes so it logically doesn't make sense to group them with pipe related device's Removed unused code in the process https://github.com/tgstation/tgstation/assets/110812394/3439a0f3-9c48-43ac-8f4b-98135435ec13 **2. New ID System** The problem with air sensor's is that each sensor is assigned a unique ID which is then stored in `GLOB.objects_by_id_tag` list. Each sensor name it's assigned based on the gas it's trying to sense(for naming only even though it can detect other gases) So if 2 sensor's having the same ID are made they will overwrite each other in this list leaving one sensor orphaned in the world which cannot be referenced because it's value was overwritten by a new sensor having the same ID in this list. The Solution? Rather than having all atmos computer's look up sensor's from this 1 global list make each computer keep track of all sensor's it's responsible for in it's own local list[which i called `connected_sensor's`] this way 2 sensor's can have randomly generated names in the global `GLOB.objects_by_id_tag` list but the computer will know what sensor to look up in this list based on the stored sensor ID's in the `connected_sensor's` list Basically what i am getting at is now you can make as many air sensor's as you wish but you will know have to connect that sensor to the computer using a multitool. Notice in the video how i made 2 sensor's called `Supermatter Chamber Sensor's`] and every time you try to connect an sensor which has the same name[`Supermatter Chamber Sensor's` in this case] they will ovewrite the old sensor in it's list as shown in the video https://github.com/tgstation/tgstation/assets/110812394/b5283c3b-c8a1-4b94-a6a8-8ba7a0007615 **Why it's good for the game**  I agree. Also air sensor's taking up a full Tab/Section in the RPD UI wasted a lot of UI space so that's removed now. Also making the air sensor's wrenchable and pickable item's was also requested in https://github.com/tgstation/tgstation/pull/72019#issuecomment-1355499873 so you relate them to device's like meter's Another huge issue was that the number of air sensor's you can make in the world was limited because each sensor in the world must have a unique ID but that's finally fixed now so yeah make as many sensor's as you want. ## Changelog 🆑 add: air sensor's are craftable refactor: air sensor's can now be turned off by hand and can only be deconstructed by a welding tool refactor: removed `Params()` proc qol: unwrenched air sensors can be picked up & recycled like regular item's del: air sensor are removed from the RPD UI qol: air sensor's are no longer restricted by their unique ID's which mean you can craft as many air sensors as you want. /🆑 --------- Co-authored-by: Time-Green <timkoster1@hotmail.com> |
||
|
SkyratBot
|
01464d23ee |
[MIRROR] ChemMaster and CondiMaster refactored, prints items over time [MDB IGNORE] (#21774)
* ChemMaster and CondiMaster refactored, prints items over time * conflict --------- Co-authored-by: Andrew <mt.forspam@gmail.com> Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com> |
||
|
Andrew
|
d278980066 |
ChemMaster and CondiMaster refactored, prints items over time (#75849)
 ## About The Pull Request Chem master has been using some hard coded styles for containers, pills and patches. Some people didn't bother to update styles, and they stayed outdated. Now it uses just a list of reagent containers instead, which makes it easy to add new containers - just one line of code. Also changed its sprite for better animations, emissive overlay, and to display buffer reagents on the sprite itself. Now it plays printing animation when you actually print containers and servos have a purpose now - they increase the amount of containers printed at once by up to 100% * part_tier. Pills and patches are always printed at double amount. And fixes #59734 ## Why It's Good For The Game Makes chem master easier to manage in code and easier to use in-game. Printing delay is added for consistency with other fabrication machines (like lathes), to give a purpose for the servo motor used in construction, for visuals (to show the printing animation only when something is being printed, and not just when you move stuff in and out of buffer as before) and to prevent people from spamming the world with unneeded objects with 0 second delay. ## Changelog 🆑 qol: Chemmaster UI tweaked fix: Fixed chem master showing wrong data during reagent analysis fix: Fixed chem master not working with fermented drinks image: Chemmaster resprited, now has an indicator for buffer reagents refactor: Refactored chemmaster code, it now uses reagent containers instead of styles balance: Chemmaster now uses servos and has printing animation of 0.75 second duration. Outputs 1 container or up to 2 pills/patches per cycle by default. Can be upgraded to output up to 4 and 8 with t4 servos. /🆑 |
||
|
VastKilleroOm
|
db63af885c |
New stamp for NRI (#21676)
* New Stamp for NRI Add new stamp for NRI docks and paperworks Stamp with text "Флотилия Её Величества". In translation "Her Majesty's Fleet" * Update code/modules/asset_cache/assets/paper.dm Co-authored-by: Zonespace <41448081+Zonespace27@users.noreply.github.com> * Update modular_skyrat/master_files/code/modules/paperwork/stamps.dm Co-authored-by: Zonespace <41448081+Zonespace27@users.noreply.github.com> --------- Co-authored-by: Zonespace <41448081+Zonespace27@users.noreply.github.com> |
||
|
SkyratBot
|
6c0951d35a |
[MIRROR] Condiments resprited [MDB IGNORE] (#21530)
* Condiments resprited (#75715)  ## About The Pull Request Resprited many condiment containers. And a tray (don't know why, it just was in the dmi) Replaced the old condiment bottle from Condi Master with the one that was used in Chem Master before the test tubes. ## Why It's Good For The Game More in line with other 3/4 stuff ## Changelog 🆑 image: Resprited many condiment containers image: Added a sprite for cooking oil / corn oil container image: Replaced old condiment bottles with the newer bottles in Condi Master /🆑 * Condiments resprited --------- Co-authored-by: Andrew <mt.forspam@gmail.com> |
||
|
Andrew
|
bc5581dc09 |
Condiments resprited (#75715)
 ## About The Pull Request Resprited many condiment containers. And a tray (don't know why, it just was in the dmi) Replaced the old condiment bottle from Condi Master with the one that was used in Chem Master before the test tubes. ## Why It's Good For The Game More in line with other 3/4 stuff ## Changelog 🆑 image: Resprited many condiment containers image: Added a sprite for cooking oil / corn oil container image: Replaced old condiment bottles with the newer bottles in Condi Master /🆑 |
||
|
KathrinBailey
|
df899f3e53 |
[Donator] Official Cat Stamp (#21442)
* OFFICIAL CAT!! Adds the stamp * Adds stamp to donator list I WANT MY STAMP!! |
||
|
SkyratBot
|
f9b66de42e |
[MIRROR] Fix broken icons in the crafting menu [MDB IGNORE] (#21439)
* Fix broken icons in the crafting menu (#75649) ## About The Pull Request **1. Rolling Pin Icon Fix** The rolling pin icon shows up correctly under the tools section  The problem was with the text `#define TOOL_ROLLINGPIN "rolling pin"` `"rolling pin"` has a space in it's name, so when it's sent to the UI and used as a css class identifier it get's treated as 2 separate classes class1 = rolling class2 = pin Causing undefined results. So i made sure to remove this space when inserting this name as a sprite sheet and also remove the space manually in the Client-Side UI Fixes #75525 **2. Basketball Hoop Icon Fix** The basket ball hoop has the correct icon in the crafting menu  This is not an `32 x 32` icon but an `32 x 64 ` icon so we assumed the icon size wrong hence it got rendered incorrectly. Now in the back end we query the size of the icon using the datum sprite sheet before sending it to the UI, so this should also fix a lot of other broken icon's that are not the standard `32 x 32` that went un noticed ## Changelog 🆑 fix: rolling pin icon show's up correctly under the tools section in the crafting menu i.e. for those recipes that require it fix: basketball hoop icon and other sprites that are not the standard `32 x 32` now show's up correctly in the crafting menu /🆑 * Fix broken icons in the crafting menu --------- Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> |
||
|
SyncIt21
|
14411daa11 |
Fix broken icons in the crafting menu (#75649)
## About The Pull Request **1. Rolling Pin Icon Fix** The rolling pin icon shows up correctly under the tools section  The problem was with the text `#define TOOL_ROLLINGPIN "rolling pin"` `"rolling pin"` has a space in it's name, so when it's sent to the UI and used as a css class identifier it get's treated as 2 separate classes class1 = rolling class2 = pin Causing undefined results. So i made sure to remove this space when inserting this name as a sprite sheet and also remove the space manually in the Client-Side UI Fixes #75525 **2. Basketball Hoop Icon Fix** The basket ball hoop has the correct icon in the crafting menu  This is not an `32 x 32` icon but an `32 x 64 ` icon so we assumed the icon size wrong hence it got rendered incorrectly. Now in the back end we query the size of the icon using the datum sprite sheet before sending it to the UI, so this should also fix a lot of other broken icon's that are not the standard `32 x 32` that went un noticed ## Changelog 🆑 fix: rolling pin icon show's up correctly under the tools section in the crafting menu i.e. for those recipes that require it fix: basketball hoop icon and other sprites that are not the standard `32 x 32` now show's up correctly in the crafting menu /🆑 |
||
|
SkyratBot
|
d3f2386664 |
[MIRROR] Bible refactor [MDB IGNORE] (#21190)
* Bible refactor * Delete book.dm * updatepaths * you're meaning to tell me i have to edit CODE?? --------- Co-authored-by: ChungusGamer666 <82850673+ChungusGamer666@users.noreply.github.com> Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com> Co-authored-by: Jolly-66 <70232195+Jolly-66@users.noreply.github.com> |
||
|
ChungusGamer666
|
dff70625e7 |
Bible refactor (#75350)
## About The Pull Request This started as a simple addition where burning a bible would curse you, but then I realized... Bibles aren't even proper books, thus can't be burned! So yeah, since that is not necessary due to how atom_storage works, I reworked that. ## Why It's Good For The Game Because burning bibles and getting cursed for it is funny.   ## Changelog 🆑 add: You can burn bibles now! But heresy has a steep cost... /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
SkyratBot
|
d54f6bacc0 |
[MIRROR] Patch resprite [MDB IGNORE] (#21102)
* Patch resprite (#75141) ## About The Pull Request Adds more selectable patches.  ## Why It's Good For The Game Currently there are only 4 patches to pick from. This selection is tragic, so how about a few more? Adds more patches so that chemists have some choice. ## Changelog 🆑 @ Xander3359 Sprites: Nebby#1467 image: Replaces the old patches with some new sprites /🆑 * Patch resprite --------- Co-authored-by: Xander3359 <66163761+Xander3359@users.noreply.github.com> |
||
|
Xander3359
|
62fe4a3b91 |
Patch resprite (#75141)
## About The Pull Request Adds more selectable patches.  ## Why It's Good For The Game Currently there are only 4 patches to pick from. This selection is tragic, so how about a few more? Adds more patches so that chemists have some choice. ## Changelog 🆑 @Xander3359 Sprites: Nebby#1467 image: Replaces the old patches with some new sprites /🆑 |
||
|
SkyratBot
|
655bda28f9 |
[MIRROR] Allows the surgery body zone selector to use other UI themes [MDB IGNORE] (#20822)
* Allows the surgery body zone selector to use other UI themes (#74957) ## About The Pull Request Allows uses of the body zone selector for non-base TGUI themes (that look good, that is), doesn't add any to the asset cache, however, as this is just groundwork ## Why It's Good For The Game The potential of things for looking better for other TGUI themes ## Changelog Nothing player-facing * Allows the surgery body zone selector to use other UI themes --------- Co-authored-by: Zonespace <41448081+Zonespace27@users.noreply.github.com> |
