* Cache sprite data alongside spritesheets, fixing emotes and a whole lotta other missing images (#80601)
* Cache sprite data alongside spritesheets, fixing emotes and a whole lotta other missing images
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* General maintenance for chem heater (#80495)
## About The Pull Request
1. Converted UI to typescript
2. Removed all tutorial code(and the icon files it used) Also removes
the reward that came with it. Both were not a big deal to begin with so
you know no one will miss it, In the name of code clean up and reducing
dmi file sizes it serves us better removing them
It did not compile in the new UI
And the text to display is way too clunky to be readable code wise (no
indentation just big raw blobs of unorganized text)
9983b883f7/code/modules/reagents/chemistry/machinery/chem_heater.dm (L334-L339)
And the steps manually set chem temps and volumes without calling the
appropriate procs basically its a mess so best to throw it all away.
3. Fixed the debug chem heater only absorbing 100 units of buffer from
the beaker even though it has a capacity of 2000. This is because it
used a constant of 100 for calculating how much volume to absorb
9983b883f7/code/modules/reagents/chemistry/machinery/chem_heater.dm (L449)
Even though the debug chem heater has a capacity over 1000
9983b883f7/code/modules/reagents/chemistry/machinery/chem_heater.dm (L495-L497)
Now the absorbing mechanism is based on the `maximum_volume` of the
holder and not on a fixed constant
4. Fixed the chem heater showing the wrong overlay when its panel is
opened and then closed while a beaker is inside
It would use the same icon for both open & closed state
9983b883f7/code/modules/reagents/chemistry/machinery/chem_heater.dm (L164)
But it should actually use this state
9983b883f7/code/modules/reagents/chemistry/machinery/chem_heater.dm (L59)
That's fixed now too.
5. Removed unused procs, variables and a whole lot of tracking which
UI's are opened/closed. All this is not necessary because the `SStgui`
subsystem tracks them for you so it was a lot of code bloat. autodocs
vars, procs and the regular stuff
6. Added more examines & tooltips for chem heater
## Changelog
🆑
fix: debug chem heater now withdraws more than 100 units from its
inserted beaker.
fix: chem heater has correct overlay when its panel is closed with a
screwdriver while a beaker is inside.
qol: added more examines and tooltips for the chem heater.
code: converted chem heater UI to typescript. removed unused procs,
vars, ui tracking code. Added auto doc for everything.
refactor: removed chem heater tutorial help button & its related reward,
chem heater code has been optimized as a whole.
/🆑
* General maintenance for chem heater
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
## About The Pull Request
1. Converted UI to typescript
2. Removed all tutorial code(and the icon files it used) Also removes
the reward that came with it. Both were not a big deal to begin with so
you know no one will miss it, In the name of code clean up and reducing
dmi file sizes it serves us better removing them
It did not compile in the new UI
And the text to display is way too clunky to be readable code wise (no
indentation just big raw blobs of unorganized text)
9983b883f7/code/modules/reagents/chemistry/machinery/chem_heater.dm (L334-L339)
And the steps manually set chem temps and volumes without calling the
appropriate procs basically its a mess so best to throw it all away.
3. Fixed the debug chem heater only absorbing 100 units of buffer from
the beaker even though it has a capacity of 2000. This is because it
used a constant of 100 for calculating how much volume to absorb
9983b883f7/code/modules/reagents/chemistry/machinery/chem_heater.dm (L449)
Even though the debug chem heater has a capacity over 1000
9983b883f7/code/modules/reagents/chemistry/machinery/chem_heater.dm (L495-L497)
Now the absorbing mechanism is based on the `maximum_volume` of the
holder and not on a fixed constant
4. Fixed the chem heater showing the wrong overlay when its panel is
opened and then closed while a beaker is inside
It would use the same icon for both open & closed state
9983b883f7/code/modules/reagents/chemistry/machinery/chem_heater.dm (L164)
But it should actually use this state
9983b883f7/code/modules/reagents/chemistry/machinery/chem_heater.dm (L59)
That's fixed now too.
5. Removed unused procs, variables and a whole lot of tracking which
UI's are opened/closed. All this is not necessary because the `SStgui`
subsystem tracks them for you so it was a lot of code bloat. autodocs
vars, procs and the regular stuff
6. Added more examines & tooltips for chem heater
## Changelog
🆑
fix: debug chem heater now withdraws more than 100 units from its
inserted beaker.
fix: chem heater has correct overlay when its panel is closed with a
screwdriver while a beaker is inside.
qol: added more examines and tooltips for the chem heater.
code: converted chem heater UI to typescript. removed unused procs,
vars, ui tracking code. Added auto doc for everything.
refactor: removed chem heater tutorial help button & its related reward,
chem heater code has been optimized as a whole.
/🆑
* 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>
* 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>
## 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.
/🆑
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.
## 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
🆑
/🆑
## 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. -->
* 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>
## 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)
* 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>
## 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.
/🆑
## 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>
## 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
0fb8b8b218/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?
0fb8b8b218/code/__DEFINES/construction.dm (L91-L94)
It gets worse why are global lists declared here?
0fb8b8b218/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.
0fb8b8b218/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
0fb8b8b218/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
0fb8b8b218/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
0fb8b8b218/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
0fb8b8b218/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.
0fb8b8b218/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>
## 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>
* 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>
* 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>
## 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
/🆑
## About The Pull Request
Made a new UI and refactored some mech code in the process.
Fixes#66048Fixes#77051Fixes#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>
* [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>
## 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>
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>
## 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
* 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>
## 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>
## 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
/🆑
* 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>
## 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>
## 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.
/🆑
* 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>
## 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
/🆑
* 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>
