This PR fixes issues with the chameleon jumpsuit and sneakers. In addition to that, it properly defines setting for GAGS worn and inhand icons instead of having them be in Initialize() for specific item types. Names for the prisoner jumpsuits and wheelys have also been reverted to how they were before the GAGS PR.
* Adds explosion SFX to the blastcannon and explosive compressor
- Extracts the explosion SFX and screenshake proc from the SSexplosions explosion handling proc and lets the explosive compressor and blastcannon use it.
* Miscellaneous changes
- Adds defines for the internal explosion arglist keys
- Reverses the values of the explosion severity defines
- Changes almost everything that uses `/proc/explosion` to use named arguments
- Removes a whole bunch of argname = 0 in explosion calls.
* Removes named callback arguments.
* Changes the explosion signals to just use the arguments list
Adds a simple framework to let objects respond to explosions occurring inside of them.
Changes a whole bunch of explosions to use the object being exploded as the origin of the explosion rather than the turf the object is on.
Makes the explosive compressor and blastcannon actually use the TTVs they are given.
Adds support for things responding to internal explosions.
Less snowflake code for the explosive compressor and blastcannon calculating bomb range.*
Less confusing explosion severity defines.
Less opaque explosion arguments
*does not guarantee that the solution to letting them actually use the TTV is any less snowflake.
The emissives system is the system that both lets computer screens and vendors glow in the dark and lets mobs and items block those glows. The current implementation relies on using filters to let mobs and items mask out the glow in the dark overlays on some structures. This is difficult to extend properly without massively increasing maptick. This PR changes the emissives system to use BYONDs native image layering to mask emissive overlays. This should prove to be a more extensible option.
tldr; There exists a system that lets computer screens glow on the dark and lets mobs and items block the glow. It isn't very extensible and this PR attempts to make it more extensible.
How emissive overlays used to work
Currently emissive overlays and the emissive blockers that mask those overlays are handled using a system of inter-masking planes. The emissive overlays and the emissive blockers are placed on separate, hidden plane masters. These are essentially rendering layers and groups. The emissive blocker plane is then used to mask the emissive overlay plane which effectively allows the emissive blockers to block the emissive overlays from being seen. After is has been masked the emissive overlay plane is used to mask the lighting plane, essentially creating holes in the shadows wherever an unblocked glowing thing exists.
Why this is a potential problem
This system works fine. In fact it works great! The computer screens glow, any person or item that winds up on a computer blocks the glow, and everything just works. However, this system runs into some issues when you try to extend it to work on things other than structures. Namely, the current system only supports emissive overlays on structures and emissive overlays that are completely unblockable by any means. As a result, several interesting uses to the system require extending the system.
As a result, if you want to apply emissive overlays to items (which exist between structures and mobs) or emissive overlays to turfs (which exist below structures) you must extend the emissives system to get the emissive overlays and emissive blockers to properly function. Doing this naively, by adding extra emissive overlay and emissive blocker planes and applying all of the relevant masking filters, is not exactly performant.
Maptick is a major contributor to lag and the higher the maptick the more free lag you, the player, get delivered fresh to your client. Trying the naive method resulted in #55782 (1f1b58bb26), an attempt to add glowing carpet to the game. Since the PR revolved around adding glowing carpet it had to extend the emissives system to allow for emissive turfs and emissive blocking structures. Extending the system was done naively as described above and you can see the results. 1.5 times the maptick across the board. Ouch.
So, we know that extending the system in it's current form is impractical. At least if done naively. Thus we are stuck.
tldr; The emissive system currently uses inter-plane masking to allow for emissive blockers to function. This is difficult to reasonably extend without murdering maptick. See #56496 (1f1b58bb26) for the results of naively extending this system.
How emissive overlays are going to work
Alright, so we know that the current system of using planes to let the emissive blockers mask the emissive overlays is difficult to extend in it's current form. The solution is to change how the system works so that it can be extended in a more efficient manner. What we want is a system that allows one set of images to be out masked by another set of images and for the first set of images to be capable of masking the light plane. Preferably, we would also like the ability to interleave the masking effect between emissives and emissive blockers with almost arbitrary layering.
Conveniently, this layering and masking is something BYOND already does to normal items and objects. If we put the emissive overlays and the emissive blockers on the same plane we can use their layers to interleave them almost arbitrarily like any normal structures and items! All we need is a way to mask away the emissive blockers from the resulting rendered plane and we can mask the lighting plane with the remaining emissive overlays.
Luckily, BYOND has provided a single filter that is capable of this task. The color matrix filter. This filter can be used to apply a color matrix to an image! Provided that the emissive overlays and the emissive blockers are different colors we can use a color matrix filter to effectively mask out the emissive blockers from the plane! The resulting emissive plane can be applied as an alpha mask to the lighting plane as it used to, to the same effect. The best part is, we get layering practically for free!
This is exactly what this PR does. It converts the emissives system from the old plane and masking based blocking to a new layer-based system which uses BYONDs native layer handling to mask the emissive overlays.
## About The Pull Request
Changes up some layer and plane defines for no particular reason lol
## Why It's Good For The Game
Planes actually override layers, and layers control ordering within planes. A lot of the usage of plane and layer was wholly unnecessary. This refactor helps future maintainability while also being needed staging for _future features._
NanoTrasen has now graciously created new outfits for their esteemed members of Central Command! These include new turtlenecks, a fancy coat, a new cap, and a skirt edition of the current Official jumpsuit.
Creates update_name and update_desc
Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together
Less non-icon handling code in update_icon and friends
Signal hooks for things that want to change names and descriptions
99%+ of the changes in this are just from switching everything over to update_appearance from update_icon
* Gives the sniper rifle a suppressor overlay so that it no longer shows up as missing a sprite, also fixes donksoft pistols by repathing them from pistols over repathing them from toy saber smgs. Creates a flag for checking if a gun needs a toy overlay, so it is handled in the parent.
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
Brings a heavily improved, rewritten, and optimised fermichem to tg. I saw that tg seemed receptive to it, so I thought I’d do it myself. If you know of fermichem – there’s a lot changed and improved, so looking at other documents regarding it will not be accurate.
Revamps the main chemistry reaction handler to allow for over time reactions instead of instant reactions. This revamp allows for simultaneous reactions, exo/endothermic reactions and pH consuming/producing behaviours. Most of the reactions in game will now inherit an easy one size fits all reaction.
Temperature mechanics
Temperature affects reaction rate
The higher it is, the faster it is, but be careful, as chem reactions will perform special functions when overheated (presently it DOESN’T explode)
Temperature will increase or decrease depending on the exo/endothermic nature of the reaction
pH mechanics
Each reaction requires the pH of a beaker to be within a certain range.
If you are outside of the optimal, you'll incur impurity, which has a negative effect on the resultant chem
pH of a beaker will change during a reaction
Reacting Impure chem effects can vary from chem to chem, but for default will reduce the purity of other reagents in the beaker
Consuming an impure chem will either cause liver or tox damage dependant on how impure it is as well as reducing consumed volume
Purity can (presently) only be seen with a chemical analyser
Impure chems can purposely be made by making the reagent with a low, but not explosive, purity.
A chem made under the PurityMin will convert into the reagent’s failed chem in the beaker.
Optional catalysts
Reactions can use an optional catalyst to influence the reaction - at the more framework exists from tmeprature, reaction rate and pH changes as a result of a catalyst. Catalysts can be set to only work on a specific reagent subtype. It is preferable to those building upon this code that optional catalysts only affect a subsection of reagents.
Presently the only catalyst that uses this is Palladium synthate catalyst - a catalyst that increases the reaction speed of medicines.
Reaction agents
These are reagents that will consume themselves when added to a beaker - even a full one, and apply effects to the total solution. One example being Tempomyocin which will speed up a reaction, or the buffer reagents which change the pH.
Competitive reactions
These reactions will go towards a certain product depending on the conditions of the holder. The example one given is a little tricky and requires a lot of temperature to push it towards one end.
New and charged reactions
(see the wiki for details)
Acidic /basic buffer - These reagents will adjust the pH of a beaker/solution when added to one. If the beaker is empty it will fill it instead.
Tempomyocin - This will instantly speed up any reaction added it is added to, giving it a short burst of speed. Adding this reagent to a reaction will give it a suddent speed boost up to 3x times - with the output purity of the boost modified by the Tempomyocin's purity.5u per 100u will give you 2x, 10 u per 100u will give you 3x. IIt caps at 3x for a single addition, but there is nothing preventing you from adding multiple doses for multiple boosts.
Purit tester - this will fizzle if the solution it is added to has an inverse purity reagent present.
A few other reactions have been tweaked to make sure they work too. An example being meth - see the wikipage linked above.
A note on all reactions
The one size fits all reaction for all chems generally won’t create impure chems – it is very forgiving. The only thing to remember is to avoid heating reactions over 900 or you’ll reduce your yield, and try to keep your pH between 5 -9.
This PR doesn’t have specific example chems included (except for the buffers) – they will be atomised out and they use the mechanics in more depth
A note on plumbing
I reached out to Time Green and we worked together to make sure plumbing was fine. Time Green did some of his own tests too, and surprisingly it doesn't look like much needs to be changed.
About The Pull Request
This PR removes intents and replaces them with a combat mode. An explanation of what this means can be found below
Major changes:
Disarm and Grab intents have been removed.
Harm/Help is now combat mode, toggled by F or 4 by default
The context/verb/popup menu now only works when you do shift+right-click
Right click is now disarm, both in and out of combat mode.
Grabbing is now on ctrl-click.
If you're in combat mode, and are currently grabbing/pulling someone, and ctrl-click somewhere else, it will not release the grab (To prevent misclicks)
Minor interaction changes:
Right click to dissasemble tables, racks, filing cabinets (When holding the right tool to do so)
Left click to stunbaton, right click to harmbaton
Right click to tip cows
Right click to malpractice surgery
Right click to hold people at gunpoint (if youre holding a gun)
Why It's Good For The Game
Intents heavily cripple both the code and the UI design of interactions. While I understand that a lot of people will dislike this PR as they are used to intents, they are one of our weakest links in terms of explaining to players how to do specific things, and require a lot more keypresses to do compared to this.
As an example, martial arts can now be done without having to juggle 1 2 3 and 4 to switch intents quickly.
As some of you who saw the first combat mode PR, the context menu used to be disabled in combat mode. In this version it is instead on shift-right click ensuring that you can always use it in the same way.
In this version, combat mode also no longer prevents you from attacking with items when you would so before, as this was something that was commonly complained about.
The full intention of this shift in control scheme is that right click will become "secondary interaction" for items, which prevents some of the awkward juggling we have now with item modes etcetera.
Changelog
cl Qustinnus
add: Intents have been replaced with a combat mode. For more info find the PR here: #56601
/cl
* Adds emissive carpet, adds plane support to decal element
- Adds a basic abstract/debugging emissive carpet
- Makes decals capable of supporting plane
- Adds auto-smoothing decals
* Adds simple neon carpet variations
* Adds neon carpet reagents and recipes
* Refactors emissive blockers to allow multiple layers of emissive / emissive blocking objects
- Splits the emissive and emissive blocker plane masters into several plane masters which handle different layers of emissiveness.
* Makes neon carpet tile stacks emissive
* Rearranges and docs some emissive plane masters
- Folds the overlay lighting plane master into the emissive planes since it is also used to mask the lighting plane
* Fixes null mats_per_unit stack recombining after splitting
- I think I broke this a while ago when I reworked how stacks handle materials. Whoops.
- This basically only effects carpet at the moment. Good thing I did this when I did!
* Adds neon carpets to cargo
- Adds a cargo supply crate containing a _lot_ of neon carpets for 3000 credits
* Fixes neon carpet highlights leaking through vending machines and such
- Turns out vending machines axed their own emissive blockers whenever they updated their icon because they cleared their managed_vis_overlays...
- Generic emissive blocking has been elementized and some update_overlays procs have been straightened out.
* Fixes id_arg_index for the emissive blocker element
* Commits @Rohsie's suggestions
quickstart acts by ticking the first throw right away, but this can lead to stack overflows if this throw happens to trigger another throw. it should really be moved to a default off argument, as only user initiated throws should use it, but throws that themselves can be triggered by throws (like this) should definitely not use it.
These felt like another good test-case for ai controllers that someone could easily grasp, this makes it so that we can use the actual vending machine instead of a fake mimic mob. In theory you could even still use the vending machine, if you like living on the edge ofcourse.
The vendors now try to move towards you, and try to dive on top of you to squish you.
* Pubby cleanup and Kilo Fixes
Remove pubbystation subtypes of boozeomat
Remove pubby specific subtype of wallmed
Replaces pubby wallmed subtypes in use elsewhere with standard wallmeds
Added some missing solar panel wires
Adds Centcomm access to ERT dock to allow Centcomm guests to board the station
Tweaks some siding decals
* Supposed to be in the first commit
* Gets rid of some stray scaffolding
Gets rid of some stray scaffolding
* Missing grille
* Remove spawn points from solars
Remove xeno spawn points from Kilo solars - spiders use this spawn locations and are not vacuum proof
## About The Pull Request
The NanoDrug was created by splitting the drugs off from the tools in the NanoMed in #55069. When this was done a payment_dept variable was not given to the new machine. The default value for this is the engineering department, so payments taken in by the machine went to the engineering budget, not medical. This also resulted in engineering getting a discount at medical's vendors, while medical staff were charged full price.
## Why It's Good For The Game
The NanoDrug belongs to the medical department, not engineering.
Grenades have, for the longest time, used the proc name preprime() to refer to arming a timed grenade so that it will boom in a few seconds, and prime() to refer to the grenade actually going boom (or releasing foam or anything else grenades do when they go off). This was very confusing, so now these two procs are called arm_grenade() and detonate().
This repaths the nanodrug and nanomed vending machines, as well as visually tweaks the nanodrug vending machine from the nanomed vending machine, in order to
A) Fix the correct vending refills working on the correct vending machines.
B) Not make 2 different vending machines with different contents sell look identical.
Allows for visual clarity between 2 distinct, different vending machines. I got lazy and didn't do it the first time, and now they've been confusing players, apparently.
Additionally, makes them actually deconstruct able and constructible as a result of the fix to the circuit board.
Machines no longer vomit out their component parts when qdel'd and instead only vomit out their actual inventory contents.
Doing this uncovered another issue - Random vending machines will return INITIALIZE_HINT_QDEL and then attempt to qdel their circuits, which are still type paths and not initialised atoms yet (circuit was previously nulled by dump_contents, but this no longer happens in dump_inventory_contents). These circuits have been set to null appropriately.
The market crash event, and by proxy just regular inflation values were being applied to objects with custom prices and custom premium prices. Makes sense, this was a pain in the ass to get working originally across the top of the base prices.
...However, it seems that I forgot to apply that to the uh... base prices of vending, meaning that you had hilariously overpriced vendors on top of completely base prices.
* Final Stage Capitalism.
* tweaks.
* Got overzelous in my fervor for blood
* well, this now has my full attention.
* Whoops missed a <<
* fixes issue because there were changes I missed
* Cobby: Departmental income is static.
* Whoops
* Various high cost premium prices and a few custom_prices have been adjusted to better suit the lack of income. Code cleanup on income so they're all in-line with cargo.
* First, this has been atomized out.
* UI is now fixed as god intended.
* Actually no, this is dynamic now. No more confusion.
* Conflicts fixed.
* Apply suggestions from code review
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
* tgui recompile.
* Hopefully aquires that green checkmark.
* --fixes the spacing.
* var cleanup and departmental budget assignment cleanup.
* merge conflict fix
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
* 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
