[MIRROR] Paint cans actually hold an appreciable amount of paint #696
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… IGNORE] (#25086) * Paint cans actually hold an appreciable amount of paint (#79791) ## About The Pull Request Paint can total uses 10 => 200 ## Why It's Good For The Game Paint cans used to be infinite until it was discovered that was actually a bug and it was fixed back in May What wasn't actually changed was how much paint is supposed to be in the can. Cans only hold 10 charges of paint, and lack an apparent way to refill them (as far as I know), which is enough paint to do almost nothing with. Given crayons and spraycans hold 30 charges, 200 seems a lot more reasonable for a big old can of paint that can only colour things and is generally a lot bigger than spraycans (much less crayons) ## Changelog :cl: balance: Paint cans hold 20x more paint than before, painters rejoice! (Janitors cry more) /:cl: * Paint cans actually hold an appreciable amount of paint --------- Co-authored-by: YakumoChen <[email protected]>
AnywayFarus
added a commit
that referenced
this pull request
Nov 18, 2023
Iajret
pushed a commit
that referenced
this pull request
Jan 31, 2024
* Fixes the tram's schrodinger-like power consumption (#81122) ## About The Pull Request Fixes tgstation/tgstation#81106. The tram's dynamic power use does not get recalculated when leaving an area because the powernet between areas is made for static loads, This leads to APCs being drained quickly consuming too much power, or consuming negative energy leading to an APC being charged. The amount of times use_power is called on tram crossing signals during processing also leads to unexpected power consumption. This moves tram power to a rectifier machinery object in each area, controlled by signals from the tram. Tram crossing signals are fixed in how they consume power, changing between power use states instead of consuming during processing, and moved from the transport subsystem to fastprocess because they don't need to be running at 20fps. ## Why It's Good For The Game Tram draining an APC in a matter of seconds is bad. Tram having negative power draw at other times is also bad.  ## Changelog :cl: LT3 fix: Tram power consumption will no longer will randomly drain APCs fix: Tram power moved to area based rectifiers /:cl: --------- Co-authored-by: Ghom <[email protected]> * Fixes the tram's schrodinger-like power consumption --------- Co-authored-by: lessthanthree <[email protected]> Co-authored-by: Ghom <[email protected]>
ReezeBL
pushed a commit
that referenced
this pull request
Jan 31, 2024
…1766) * Fixes the tram's schrodinger-like power consumption (#81122) ## About The Pull Request Fixes tgstation/tgstation#81106. The tram's dynamic power use does not get recalculated when leaving an area because the powernet between areas is made for static loads, This leads to APCs being drained quickly consuming too much power, or consuming negative energy leading to an APC being charged. The amount of times use_power is called on tram crossing signals during processing also leads to unexpected power consumption. This moves tram power to a rectifier machinery object in each area, controlled by signals from the tram. Tram crossing signals are fixed in how they consume power, changing between power use states instead of consuming during processing, and moved from the transport subsystem to fastprocess because they don't need to be running at 20fps. ## Why It's Good For The Game Tram draining an APC in a matter of seconds is bad. Tram having negative power draw at other times is also bad.  ## Changelog :cl: LT3 fix: Tram power consumption will no longer will randomly drain APCs fix: Tram power moved to area based rectifiers /:cl: --------- * Fixes the tram's schrodinger-like power consumption --------- Co-authored-by: NovaBot <[email protected]> Co-authored-by: lessthanthree <[email protected]> Co-authored-by: Ghom <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Mirrored on Skyrat: Skyrat-SS13/Skyrat-tg#25086
Original PR: tgstation/tgstation#79791
About The Pull Request
Paint can total uses 10 => 200
Why It's Good For The Game
Paint cans used to be infinite until it was discovered that was actually a bug and it was fixed back in May
What wasn't actually changed was how much paint is supposed to be in the can.
Cans only hold 10 charges of paint, and lack an apparent way to refill them (as far as I know), which is enough paint to do almost nothing with.
Given crayons and spraycans hold 30 charges, 200 seems a lot more reasonable for a big old can of paint that can only colour things and is generally a lot bigger than spraycans (much less crayons)
Changelog
🆑 YakumoChen
balance: Paint cans hold 20x more paint than before, painters rejoice! (Janitors cry more)
/:cl: