BRPEDs can teleport rigged power cells. Through cameras. These rigged power cells will then pretty much immediately explode. This is a tad imbalanced.
Behaviour modified. Attempting to use a BRPED on a machine and having it attempt to swap over a rigged cell will cause the rigged cell to immediately go to maximum charge and explode.
Adds some logging to accompany it.
Why It's Good For The Game
Blowing things up from across the cosmos is bad.
Rigging BRPEDs to be able to explode when some poor sucker uses it to change over a power cell is cool.
Cyborg's pipe cleaner is now using a radial menu for choosing it's colors instead of a clumsy input one.
RCL now properly updates it's pipe cleaner holder's color, so you can actually see the color when using RCL radial menu.
RCL is now able to put cables down on floors seamlessly, as there is no reason to restrict it to just a plating and catwalks anymore due to the fact that pipe cleaner coils no longer function as a power carriers, but are merely visual entities for players to play with.
And lastly, pipe cleaners now use color defines and are setting its color directly instead of having redundant variable do it for them, which was needlessly complicating it.
- Psychologists are no longer mistakenly told they have headaches
when near the supermatter.
- Immunity to supermatter hallucinations is now provided by a new trait
`TRAIT_SUPERMATTER_MADNESS_IMMUNE`, provided by mesons, and being the
Psychologist.
- The ability for Psychologists to cause the supermatter to act slightly
differently (by turning pink, and having a higher minimum healing
temperature) is now a trait, `TRAIT_SUPERMATTER_SOOTHER`, which
currently only Psychologists get.
Converts most on_reagent_change calls to signals.
Converts on_reagent_change to a signal handler.
Expands the reagent exposure signals
Add a setter proc and signal for reagent temperature
Fixes adjust_thermal_energy not sending a temperature change event
Makes min_temp and max_temp actually do something with adjust_thermal_energy
Light fixtures now use different variants of overlays in order to be non-unique and save up on instantiating a TON of overlay objects. Also, fixed the GC for them
Tweaks existing lighting and adds some presets for mapping
Current list of presets is as follows:
Main Tube Lights: normal, cold and warm with a subtype each that disables night lighting
Red & blacklight (purple) for tube & small lightbulb
Why It's Good For The Game
Better support for more varied and interesting lighting. I made sure that the new presets are subtle and bright enough to not be distracting or made it harder to see
Changes to currently mapped lighting should be mostly unnoticeable, standard tube lights have a very faint greenish tint typical of fluorescent lights, while small lightbulbs have an orange tint reminiscent of tungsten lightbulbs
For mappers, I would suggest using types that disable nightlighting in work areas while keeping night lighting for hallways and other service/living areas.
Normal lights for hallways, cold lighting for medbay and science, warm lighting for bar, library and dorms, red lights for maintenance, maybe blacklight for server rooms etc.
About The Pull Request
Converts singularity's dissipation code to use delta time instead of assuming it'll always be the same.
Numbers were based on the previous code given a delta_time of 2.
Huge removal of dead vars, bad timers, and other sloppy jitteriness from beams. They go from checking movement to waiting for a signal.
VARIABLE KILL LIST:
sleep_time: signals baby
finished: signals BAYBEEE
target_oldloc: not only not typecasted as a turf or named as a turf, it was unused. when are we going to use this? the beam starts from the origin!
origin_oldloc: bad name, not typecasted. renamed to originturf
static_beam: how are you an unused variable and still get replaced by signals like really
timing_id: signallllss bbbaaaabbyy
recalculating: you get the drill by now signals baby
base_icon: unused, seemingly replaced by visuals I think
Does a value-wise refactor of crates and bounties in order to scale the value of these imports and exports to the value of crate exports (500 credits each). Then, I have adjusted the value of crate exports to 200 credits down from 500 to place the most standard unit of profit within cargo to a scale within that of roundstart paygrades currently on station. (350-1400 credits).
This effectively balances one of the biggest disparities left within the in-game economy, which is that cargo's price scales have really never been re-balanced with the considerations of on station prices, and have been still to the same scale as when they were based on cargo points 3 years ago. While admittedly some prices in vendors were scale to those original cargo values, so many of them weren't that it warranted a massive rebalance PR in order to places the scale of these items within an appropriate range of their intended user's cost values.
Replaces GLOB.poi_list |= src and GLOB.poi_list -= src with an element that handles it directly.
More consistent code, especially when a lot of code couldn't decide how to add/remove (some |=, some -=, some .Remove, etc).
Adds a MAPTEXT macro that wraps the given text in the maptext class, the thing we use for Runechat to make it so you can actually read it. Everything that sets maptext now uses this.
I wanted to refactor how movetype flags are added and removed into traits to prevent multiple sources of specific movement types from conflicting one other. I ended up also having to refactor the floating animation loop (the one that bobs up and down) code in the process.
Why It's Good For The Game
A way to avoid conflict from multiple sources of movement types.
This also stops melee attacks, jitteriness and update_transform() from temporarily disabling the floating movetype bitflag altogether until the next life tick.
Tested, but i'm pretty sure improvements could be made.
Changelog
cl
fix: jitteriness, melee attack animations and resting/standing up should no longer momentarily remove the floating movement type.
/cl
* Cyborg stack fix
- Makes cyborgs capable of recycling floor tiles again
* Touches up module code
- Makes module code slightly more OOP-compliant
- Speeds up module creation by an imperceptable amount
- Reworks how borg modules handle stacks
About The Pull Request
As the title says.
Creates a new proc, use_power_from_net() that attempts to pull power from the grid (by adding the amount needed to the APC's powernet load), and returns the amount gathered if there was enough surplus to do so. This bypasses the APC's internal cell for power drawn this way.
Changes cell chargers to use this new proc for charging a cell. The charger machine still uses some power from the APC, set to 1% of it's max cell charging rate, for machine-related power costs. I'm not deadset on that number, I just needed to start with something. To be clear, this 1% is to simulate running the cell charger's circuitry; all of the power for the cell it's charging is 1-to-1 coming from the powernet.
This does not subvert the original PR's purpose; cells are still drawing as much power from the grid as they charge with.
Why It's Good For The Game
Fixes cell chargers breaking rooms after the prior cell charger fix. The load is now on the grid, and it being surplus means that it (probably) won't actually powersink anything.
Fixes#54919 by taking a different approach that entirely avoids the issue.
Allows modPC programs to send alerts, and adds a proc in the computer object to handle playing the sound effect and sending a message to visible users. These notifications can be muted on a per-program basis. Programs can also set themselves to highlighted in the NTOS Main menu; this is intended to be used along side alerts, but really can be used any time a program wishes to tell the user there is new information.
NT CIMS (SM monitor) now plays an alert during SM delaminations if the app is closed. The app must have had an SM selected before closing, or it will not send alerts. Notifications are sent when the SM makes a radio alert. If the app is currently the active program, the app will instead send a notification just once, when the SM begins delamination, so as to not annoy engineers that are already aware of the issue.
* The Re-pricening
* Rewritten and adjusted for paycheck defines.
* I made the map changes finally.
* And the refills too.
* "OH YEAH REPLACING IT ALL WITH DEFINES AND SCALING IT THE EXCEL DOCUMENT WILL BE EASY, ARCANE!!!"
* And the premium ones too.
* Accidently spoiled a future pr due to dme bleedover
The PR aims to allow advanced tool users to be defined by traits rather than a hardcoded proc.
Also necessary for the CanUseTopic refactor I'm working on, which will be PRed separately for atomization purposes.
This PR also fixes an inconsistency with can_hold_items (since monkeys can actually hold items).
Fixes greyscale floor tiles merging regardless of their materials.
Fixes greyscale floor tiles voiding materials when splitting the stack.
Fixes greyscale floor tile stacks being created with no mats_per_unit and only enough custom materials for a single unit.
Fixes greyscale tile flooring being created with the wrong amount of materials.
Fixes greyscale tile flooring not producing floor tiles/producing floor tiles with 0 units.
## About The Pull Request
Hopefully I can make this PR as knowledge filled as possible, so sit down and buckle up, because we're about to talk about POWER USE.
So, machines use power. The station uses power. Without power, key, critical aspects of the game don't function, and keeping the station's lifeblood pumped with electricity is the primary goal of the engineering department. Cool. So there's currently 2 methods of "power use" that machines can use, that is, through the passive use of power (Assigned by the `idle_power_usage` and `active_power_usage` variables), or through the `use_power()` proc. What's interesting, is that neither proc actually draws directly from the cell of the APC, which is sort of assumed by a proc called `use_power()`, after all. Where the passive power draw aspect of an APC is done automatically as machines are processed, and then applied to the APC seperately, taking power per cycle, use_power just applies a temporary blip of power usage to one of the APC's power tracks (Equipment, Lighting, or Enviroment). One would assume then that this temporary power drain would apply for long enough that it would apply the intended cost to the cell, and then turn off.
But I'm making this PR, right?
So the most egregious issue this brings is in terms of the cell recharger. If you place a power cell into a cell recharger, the recharger calls use_power every processing tick in order to reduce the APC cell by an equivalent amount to what the cell is intending to gain in charge. After all, you're just moving the charge from the APC to the power cell, plus the processing charge required by the cell_charger. However, lets look a bit closer at how use_power actually works. For this example we'll use a default, unupgraded cell recharger attempting to put it's default 250 watts into an empty bluespace cell.
Because power is heavily linked to the area that the machinery is placed in, we snag the area, determine the power channel, and call a use power proc on the area. The area use power proc simply adds that 250 watts, or rather joules into the equipment power channel of the APC, a part of power usage. All of this is parroted over to the APC's processing side, where the actual cost to the power cell is calcualted as follows:
`var/cellused = min(cell.charge, GLOB.CELLRATE * lastused_total) // clamp deduction to a max, amount left in cell
cell.use(cellused)`
So that number, the 250 joules of power we're calling to the cell, is actually being multiplied by a global cellrate, which is applied to every power drain on the station, actually charging the APC cell a total of 0.5 kj.
Based on some rumentary math and some experimentation, I filled a full bluespace power cell with 40Mj of power using 351 Kj of power from a standard, stock APC cell with no other drain except the 5 joules of power draw from the cell recharger.
So: What does this mean?
- Power draw is completely fucking busted (We knew this).
- Using two power cells, an APC, and an inducer, you can create infinite energy, anywhere, at zero cost to the station.
- We really need to make cell recharging a direct power draw.
Thankfully, that last one actually fits the portfolio of being a fix!
This adds a new proc to machines called `directly_use_power`. It does what it says on the tin, directly charges the APC for instances where power is going 1-1 from a power cell to another cell, in order to prevent infinite energy exploits.
## Why It's Good For The Game
Power is all kinds of unbalanced. Attempting to enforce the concept that a single unit of power is equal to itself is probably a good step in the right direction and in all likelyhood appears to have been the original intent with cell chargers in the first place.
I'm self-aware enough to see that this has ramifications beyond just fixing an issue within the cell charger alone, so if maintainers want to close this until december that's perfectly fine, but this is one of those things that could really easily snap basic station balance in twain.
Whenever you stop to do something, and there's a broken light around, you would notice it spark, and if you stay, it sparks over and over again, becoming less of a nice rare occurance to something more annoying. This was very apparent during a shift yesterday on Manuel, where the entire station had lights broken, but they kept sparking over and over again and it never quite felt like we're in darkness.
The attack chain is a bit of a mess, and the introduction of signals hasn't helped in simplifying it.
In order to take a step into untangling this, I re-ordered the attack signals to no longer be by source type and instead to be grouped more modularly, as they are all members of the attack chain and function similarly. They all share the trait of potentially ending the attack chain via a return, but had several different names for it. I joined it into one.
Additionally, fixed a tk bug reported by @Timberpoes by adding a signal return check at the base of /mob/proc/RangedAttack
Lastly, removed the async call of /datum/mutation/human/telekinesis/proc/on_ranged_attack, which was added as a lazy patch to appease the linter complaining about a sleep on a signal handler (namely in /obj/singularity/attack_tk). Fixed the problem using timers.
Also cleaned some code here and there.
imo; the ss13 audio-scape is quite barren, you can only hear most things if you can see them, which in my opinion doesn't make much sense. This changes that so you can hear further away, but falloff is much higher, so in reality you will only hear things relatively quietly when they're out of sight.
This PR increases the hearing distance of most sound by 9, excluding sounds such as antag items that are meant to be used stealthily
This PR also replaces Byond's inbuilt falloff system with something I made, (And thanks to potato for helping me throw together a formula for it). This fall-off system makes sound fall off more naturally, with sounds being full volume within a certain range, and then softly falling off until they are completely quiet. This makes for a smoother transition between "This sound is full volume" and "I dont hear this sound".
Co-authored-by: ff <ff>
Implements the ?. operator, replacing code like A && A.B with A?.B
BYOND Ref:
When reading A?.B, it's equivalent to A && A.B except that A is only evaluated once, even if it's a complex expression like a proc call.
Yellow slime extract can no longer turn into a self-charging yellow slime core. This functionality has been completely removed.
Hypercharged yellow slime cores no longer self-charge.
They now have a capacity of 50,000 (up from their previous 20,000). This is 10,000 more than a bluespace power cell.
Their recharge rate is 2500. This is relatively slow for the power capacity, as hyper and bluespace cells charge at 10% of their capacity respectively and this is 5%.
Motorised wheelchairs have had their power usage reduced to 5% of their previous value since they were basically only usable with rechargable cells before
Making a hole in the supermatter chamber to vent it and so to slow down the delamination will instead make the delamination way faster, more so if the SM power is very high and the power level is high too.
Fix an old unintended feature where you could just vent to space the SM chamber to slow down or even stop a delamination (sometimes you could just make a hole in the chamber and it would stabilize while delaminating), the SM is easily fixable just by looking at the pipe and the meters, no need to vent to space. (Lemons note, in some cases a vent to space is needed, but it should not be a long term thing)
This PR makes the crystal invasion event a delamination event only, so no more random events (can still be admin triggered).
The chance for the delamination to trigger the event depends on the power of the SM, the closer it is to the tesla delamination (near 5000) the higher the chance.
Splits the restrained() proc into component traits: TRAIT_HANDS_BLOCKED for the general inability to use hands and TRAIT_RESTRAINED for the more specific condition that permits arrests.
Code moved away from the update_mobility() proc so it doesn't have to wait for an update, instead changing based on events. The idea is to eventually kill that proc.
Wrapper proc added for setting the handcuffed value so we can react to the event of it changing.
Kills the RestrainedClickOn() proc. That is now just an UnarmedAttack(), in where the ability to use hands can be checked. Monkeys keep their bite attack and humans their self-examine.
Basically, all ethereal charge capacity and interactions have been scaled upwards by 20x.
Power wise, ethereals now hold up to 3000, with the max safe threshold being 2000. For reference, upgraded powercells can hold 2500, with high capacity holding 10K).
All appropriate values have been tweaked to match this change. There shouldn't be ANY sort of noticeable difference in game, aside from power sources depleting faster, and a few values which I decided to tweak for balance reasons. They are: power cell draining time is 1.5 seconds longer, and light draining time is 0.5 shorter. Also, draining cells has less of a punishment multiplier upon the cell now, (originally, the the cell lost 33x as much as you received. now its 12x). (to avoid returning to this in why its good, I did this because now that ethereals are capable of holding more, I can afford to have less of a punishment, while still maintaining a reasonable level of punishment).
Also some minor code and grammar improvements.
All ui_act procs should call parent by default. All procs should preserve the value of the parent proc when it's TRUTHY and pass it down the call stack. No UI should be interactible when its flags or state indicate it should not be, except when explicity overriden by child procs intentionally disregarding parent return values to achieve a specific goal.
