Hey there,
This PR is a continuation of #65290. I was not aware that there was an actual use case for these, so I decided to make them as soon as I became aware of it.
image
But what are "these"? Basically, these just add two new types of decals, opposing corners. On the left, you have the current functionality (which will still remain after this PR): adding two different "tile/purple" with different dirs on the same tile to give that effect. HOWEVER, on the right, this has been flattened into one singular turf decal: "tile/purple/opposingcorners". Very cool.
In summation, instead of having multiple corners on one tile to represent the "opposing effect" (as in having one corner in the top left and one in the bottom right) with it being the same color, you now only need one of these turf decals.
Unlike the other PR, this change is not mapped in.
Why It's Good For The Game
Less map key bloat, mappers only have to click a certain tile once if they want, more versatility, etc.
Also: please let me know if I need to change the dirs around for the current sprites. I just went off what made sense to me.
Changelog
cl
imageadd: Nanotrasen has upgraded "that machine that prints all of those decals on our station tiles" to now print two corners that face opposite each other at the same time. Very cool!
/cl
About The Pull Request
Alternative to #65354
Ok so like, there was a lot of not floor types on /floor. They didn't actually want any of their parent type's functionality, except maybe reacting to breaking (which was easy to move down) and some other minor stuff.
Part of what we don't want them to have is "plateable" logic.
I should not be able to put floor tiles on the snow and be fine. It's dumb.
Instead, I've moved all non floor types down to a new type, called /misc.
It holds very little logic. Mostly allowing pipes and wires and preventing blob stuff.
It also supports lattice based construction, which is one of the major changes here. I think it makes more sense, and it fixes an assumption in shuttle code that assumed you couldn't place "a new tile" by just hitting some snow with a floor tile.
Oh and lattices don't smooth with asteroid tiles anymore, this looks nicer I think.
Moving on to commits, and minor changes
Changes clf3 to try and burn any turfs it's exposed to, instead of just floors
Moves break_tile down to the turf definition, alongside burn_tile
If you're in basic buildmode and click on anything that's not handled in a targeted way, you just build plating
FUNCTION CHANGE: you can't use cult pylons to convert misc tiles over anymore
Generalizes building floors on top of something into two helper procs on /turf/open, reducing copypasta
Adds a new turf flag, IS_SOLID, that describes if a turf is tangible or not.
Uses this alongside a carpet and open check to replace plating and floor checks in carpet code. This does mean that non iron tiles can be carpeted, but I think that's fine
Moves the /floor update_icon -> update_visuals call to /open
This change is horrificly old, dating back to 8e112f6 but that commit describes nothing about why it was done. Choosing to believe it was a newfriend mistake. Uncomfortable nuking it though, because of just how old it is. Moving down instead
Create a buildable "misc" type off open, moves /dirt onto it
Basically, we want a type we can use to make something support
construction, since that can be a messy bit of logic. Also enough
structure to set things up sanely.
I'm planning on moving most misc turfs onto it, if only because
constructing on a dirt tile with rods should be possible, and the same
applies to most things
Murders captain planet, disentangles /turf/open/floor/grass/snow/basalt
Adds a diggable component that applies the behavior of "digging"
something out from a turf.
Uses it to free the above pain typepath into something a bit more
sensible
The typepaths that aren't actually used by floor tiles are moved onto
/misc
The others are given names that better describe them, and kept in
fancy_floor
Oh and snowshoes don't work on basalt anymore, sorry
Snowed over platings now actually have broken/burned icon states, fixing black holes to nowhere
Misc turfs no longer smooth as floors, so lattices will ignore them
Placing a lattice will no longer scrape the tile it's on
Ok this is a really old one.
I believe this logic is a holdover from kor's baseturf pr
(97990c9)
It used to be that turfs didn't have a concept of "beneath" and instead
just decided what should be under them by induction. This logic of "if
it's being latticed scapeaway to space" made sense then, but has since
been somewhat distorted
We do want to scape away on lattice spawn sometimes, mostly when we're
being destroyed, but not always. We especially don't want to scape away
if someone is just placing a rod, that's dumb.
Adds a path updating script for this change
I've done my best to find all the errors this repathing will pull out, but I may have missed some. I'm sorry.
Why It's Good For The Game
Very old code made better, more consistent turfs for lavaland and icebox, better visuals, minor fix to snowed plating, demon banishment in lattice placement, fixes the icebox mining shuttle not being repairable
Changelog
cl
add: Rather then being tileable with just floor tiles, lavaland turfs, asteroid and snow (among other things) now support lattice -> floor tile construction
fix: Because of the above, you can now properly fix the icebox mining shuttle
refactor: Non floor turfs are no longer typed as floor. This may break things, please yell at me if it does
/cl
Someone made a suggestion to me that fixed a problem I've been trying to work around, and now that I've made it so people can set custom decompose times, that made this WAY EASIER.
When most foods decay, they will turn into the generic moldy food sprite you've become accustomed to, without the ants. After 30 seconds, that moldy food will get consumed by ants, leaving only the anthill.
Ants also no longer spawn on lavaland's basalt, by Fikou request.
* Four Corners, Red Rover: An Exploration in Decaled Trends
You there! What exactly is wrong with this photograph?!
You don't need to tell me, I've boxed it out. There's four individual corners for the decalling. This is weird. You may be asking: Why don't they use the "full tile" turf decals? Let me demonstrate.
Look at the difference between the one at left and the one in the middle. The turf decal totally smothers the nice contrast lines afforded to use by the base turf, causing it to have smooth, clammy exterior. This is probably why no mapper ever uses the full turf decal, much to the chagrin of people who stare at how big the size of this repo is.
Now, what's that on the right? Why, it's the new sprite (and pathing I made) to help counter-act this issue! This perfectly lines up with the contrast lines of the base turf, allowing us to have a non-flattened visualization, while not having four fucking turf decals a turf load upon initialization. How epic!
I've also added "contrasted" variants of the "half" and "anticorner" turf decals for future use. I probably won't go through and update this in this PR, but the opportunity remains available.
I may or not map this change across all the maps. We shall see.
* neutral corners
we love vsc
* no wait
i forgot a bunch of potential edgecases so we'll have to go back. yellow should be fine but neutral, dark, blue, and green should get a second look over
* recheck
found some stuff, probably missed out on others. let us commence forth
* MISTAKE
nearly a fucko bwoingo
* final pass
it compiles and i've had enough, someone else can probably figure it out from this point onwards
* #65230 goated my timbs
now we wait for linters to fail
* YOU DIDN'T SAY THAT THE FIRST TIME
LINTERS AAFAFAFF
About The Pull Request
Simply converts all instances of soundkeys that use get_sfx from strings into defines.
E.g. "sparks" is now SFX_SPARKS
Why It's Good For The Game
It makes life a lot easier when you're looking for a sound effect. You just type SFX_ and you get suggestions in VSC. Plus, it looks better.
image
Changelog
Not player facing.
How do I play/test/operate this?
Download NT Frontier on any modular computers. It should debrief you on what experiments are available and how to publish.
If you want to do a bomb experiment, make sure it's captured by the doppler array (as usual) and then print the experiments into a disk and publish it.
If you want to do a gas experiment, make the gas and either pump it into a tank and 1) overpressurize it with a "clear" gas like N2 or 2) overpressurize tanks with the gas itself. Make sure you do the overpressurizing in the compressor machine. When tanks are destroyed/ejected leaked gas will get recorded. Print it into a disk and publish it.
For publication, the file needs to be directly present inside the computer's HDD. This means you need to copy it first with the file manager.
Fill the data (if desired, it will autofill with boiler plate if you dont) and send away!
Doing experiments unlock nodes, while doing them well unlocks boosts (which are discounts but slightly more restrictive) which are purchaseable with NT Frontier.
If you are testing this and have access to admin tools, there are various premade bombs under obj/effect/spawner/newbomb
A doc I wrote detailing the why and what part of this PR.
https://hackmd.io/JOakSYVMSh2zU2YL5ju_-Q
---
# Intro
## The Problem(s)
Ordnance, (previously toxins) seems to lack a lot of content and things to do. The gameplay loop consists of making a bomb and then sending it off for credits or using it to refine cores. Ordnance at it's inception originally relies on players experimenting and finding the perfect mix over multiple rounds, but once the recipe for a "do-everything" mix got out, the original charm of individual discoveries becomes meaningless.
Another issue with ordnance is the odd difficulty curve. As a new player, ordnance is almost impossible to decipher, but once you watch a tutorial or read a wiki and can mail a 50k into space, there pretty much isn't anything else to do. Most players will be satisfied at this point without the gameplay loop encouraging them to understand or play more. The only thing you can do afterwards is to sink your teeth in and understand why that particular mix explodes the way it does. This again has a significant difficulty curve, but if you do that, the department doesn't acknowledge or reward that in any way. There are pretty much two huge spikes, with the latter one not really existing inside the department.
TLDR:
* The content being same-y over rounds.
* Odd difficulty curve:
1. A new player is oblivious to everything.
2. Those in the middle can repeat the final goal consistently without needing to understanding why
3. There is nothing to justify spending more time in the department after reaching the midgame.
## Abstract
Scientific Papers aim to add a framework to run multiple experiments in ordnance. Adding more experiments scattered across various atmospheric aspects might allow players of various knowledge levels to still have something engaging to do. A new player should have an easier challange than to mail a 50K. While those that already can make bombs should have an easier time understanding why their bombs explode the way it does. Once they fully understand why, they can set their sights on taking advantage of another reaction to set their bomb off or hone one particular reaction down.
## Goals
* Have some intro-level challanges for new players.
* Have some semblance of late-game challanges for more experienced players.
* Explain the mechanics better for those in the middle of the road.
* Incentivize trying new things out in the department.
* Better integrate Ordnance with Experisci
## Boundaries / Dont's
* Do not incentivize people to learn ordnance by using PvP loots.
* Do not shake or change the reaction system by a huge amount.
* Disincentivize having a single god-mix that does everything.
****
# Main design pillars
## A. Framework surrounding the experiments
### A.1. New experiments
Add new experiments to the ExperiSci module. These will come in two flavours: New explosions to do, and various gas synthesis experiments. Both of these are actually supported by the map layout of ordnance right now, but there is no reason to do anything outside of making a 50k as fast as possible.
### A.2. Rewards for experiments: Cash and Techweb Boosts.
Scientific papers will add a separate experiment handling system. A single experiment will be graded into various tiers, each tier corresponding to the explosion size or amount of gas made. Doing any tier of a specific experiment will unlock the discount for that specific reactions. A single explosion **WILL NOT** do multiple experiments (or even tiers) at once.
On publication, a partner can be selected. A single partner only has a specific criteria of experiments they want. The experiments will then be graded on "how good they are done", with the criteria being more punishing as tier increases. Publication will then reward scientific cooperation with the partnered partner. Players can spend this cooperation on techweb boosts. Techweb boosts are meant to be subservient to discount from experiments and will not shave a node's price to be lower than 500 points.
**Experiments will only unlock nodes, discounts are handled through this boost system.**
This is more for maintainability than anything.
### A.3. On Tedium
*This is a note on implementation more than anything, but I think this helps explains why several things are done.*
Due to the nature of atmospheric reactions in the game (they're all linear), tedium is a very important thing to consider. An experiment should have a sweet spot to aim for, but there should not be a point where further mastery is stopped dead on it's track with a reward cap.
Scientific Papers attempts to discourage this behaviour by having the "maximum score" scale off to infinity but with the rewards being smaller and smaller. The sweet spot is always there to aim for and should be well communicated with players, but on their last submission of an experiment topic players should be encouraged to do their best. There should always be a reward for pushing the system to it's limit as long as it doesn't completely nullify the other subdepartments. This is the reason why there is a hard limit on the number of publications and why the score calculation is a bit more complex than it needed to be.
## B. Gas Synthesis (Early-Mid Game)
Scientific papers will add one new machine that requests a tank to release x amounts of y gas. This will be accomplished by adding a tank pumping machine which will either burst or explode a tank, releasing the gas inside. The gas currently requested are BZ, Nitryl, Halon and Nob.
The overarching goal of this compressor machine is to present a gas synthesis challange for the players and to get them more accustomed to how a tank explodes. The gas synthesis part can always be changed in order to reflect the current state of atmospheric reactions.
## C. Explosion Changes (Mid-Late Game)
### C.1 Cause and effect.
The main theme of the explosion changes is establishing cause and effect of explosions. Reactions that happens inside a tank that's going to explode will be recorded and forwarded to a doppler array. Some experiments will require only a single cause to be present (think of it as isolating a variable). This is currently implemented for nobliumformation and pressure based bombs. Having other reactions occuring besides noblium formation will fail the first one, while having any reactions at all will fail the second one.
Adding more explosions here will be a slight challange because as of now the game has only two reactions that can reliably make an explosion.
### C.2 Tools upgrade.
Doppler array has now been retrofitted to state the probable cause of an explosion, be it reactions or just overpressurization on gas merging. These should help intermediate players figure out what is causing an explosion.
Added a new functionality to the implosion compressor:
Basically performs the gas merging and reaction that TTV does in a machine and reports the results back as if someone uses an analyzer on them. Here to give players feedback so they can try and understand what is actually going on in a bomb.
## D. Player Interaction
There should be more room for more than 1 player to play ordnance simultaneously. Previously players are also able to split tasks, but this rarely happens because tritium synthesis needs only the gas chamber to be reconfigured. Now, different players can pick different experiments and work on them. Players can also do joint tasks on one single experiment. Gases like noblium will need tritium production and also a cooling module online.
Ordnance can also coordinate with their parent department on what they really need, be it money or research bonuses.
# Potential Changes
The best-case changes that can be implemented if the current roster of content isn't enough is more reactions that can be used in bombs. Eliminating bombs entirely goes against the spirit of the subdepartment, while adding new ones will need a lot of care and consideration.
Another possible change is to implement a "gas payload" bomb. Bombs that has a set number of unreacting gas inside that will increase the heat capacity, reduce the payload, and neccesitates more bespoke mixes.
Adding more gas synthesis experiments is discouraged. The main focus of ordnance should be bombs, with gas synthesis being a side project for ordnance. These are present to ease the introduction to bombs and provide some side content.
There should be a somewhat well-justified goal in adding new synthesis experiments: e.g. BZ is there as a "tutorial" gas, Nitryl to introduce players to cooling/heating mixes, Halon to a more efficient tritium production, and Nob as a nudge to nobformation bombs and mastery over other aspects.
# Conclusion / Summary
Add more experiments to ordnance that players can take, accomplish this by:
1. Making the players perform gas synthesis or make bombs.
2. Have them collect the data, see if it fits the criteria. Explain why if it fits and why if it doesn't.
3. Have the player publish a paper.
Reward them based on how well did they do, give players agency both on the experiment phase and also publication phase.
---
TLDR: Added new experiment to toxins, added the framework for those experiments existing. Experiments comes in gas synthesis and also bombs but with more parameters. Experiments needs to be published through papers, various choices to be made there.
Implementation notes:
Because of how paper works, ordnance experiments are handled outside of experiment_handler components. My reasoning for this is twofold:
The experiments will be completed manually on publication and if the experiment isn't unlocked yet it will still be completed.
Experiment handler datums have several procs which require an atom-level parent, and I figured this is the most sensible and cleanest way to implement this without changing the experiment handler datum too much.
Small change to /obj/machinery/proc/power_change() signal ordering to adjust the state first and then send the signal. Didn't found any other usage of this signal except mine but barge down my door if it broke something.
Rewrote the ttv merge_gases() code to be slightly more readable.
A small code improvement for thermomachine to use tofixed (my fault).
Ordnance have been updated to enable the publication of papers
Several new explosive and gas synthesis experiments have been added to ordnance
Anomaly compressor has been TGUIzed and now supports simulating the reaction of the gases inside the ttv.
New tank compressor machine for toxins. You can overpressurize tanks with exotic gases and complete experiments.
Several techweb nodes are locked and require toxin experiments to complete.
Toxins can purchase boosts for various techweb nodes.
You no longer need to anchor doppler arrays for it to work.
Doppler array and implosion compressor now supports deconstruction, implosion compressor construction added.
Doppler now emits a red light to denote it's direction and it being on. Doppler not malf.
Implosion compressor renamed to anomaly refinery.
Created a new program tab "Science" for the downloader app. Removed Robotics.
Reworked the code for bombspawner (used in the cuban pete arcade game)
I found out how emissives work and my first thought was "damn ants should glow that would look sick"
So now they do.
Also, having less than 5u ants in your body will make you not scream, so 0.0001u ants will no longer have that tiny chance of making someone scream for their life.
If an ant pile has a max damage value less than 1, then they won't be able to bite through your shoes. This is the same threshold as the second tier ant icon.
Makes the giant ant a hostile mob with the neutral faction, meaning they will attack anything not in the neutral faction.
* Fixes infi pushing off something in space
Right now you can just push "into" a dense object forever, and depending
on your move rate, just kinda glide
We can fix that by checking if we're trying to push "off" something
we're moving towards
* Makes pushing off something shift it instantly
Currently if you kick off something in space it waits the delay of the
move to start drifting. Looks dumb, let's not
* Updates backup movement to properly account for directional windows. GOD I HATE DIRECTIONAL DENSITY SHOOOOOT MEEEEEEEEEEEEEEEEEEE
* Uses range instead of orange so standing on the same tile as a directional counts properly, rather then suddenly entering a drift state. I hate it here
* Ensures all args are named, updates implementations of the proc with the new arg
Rather then sticking around till their 7 second delay, they dissipate
once they finish their movement. This dissipation comes with a fading
and such to make things look nicer.
I've applied the fading behavior to sprays too, since they could also
use the help.
I really hate how things look currently, makes me break out in hives
Anomalies are effects, effect remover is made to remove effects, might as well make use of it?
Also makes some cool sparks around it now so that's neat
Broken Super_UV icon (big flashing red overlay), no icon to indicate its locked, and unscrewing it straight up broke the whole icon!
That's all fixed, along with some quality of life, including warnings explaining WHY stuff failed...
I even made the super_uv ACTUALLY output black smoke, as the description says it does, because its cool.
Tidies up something that sees more use now that we have MODsuits (and potentially will get them buildable if that other PR goes thru)
The Suit Storage Units now have a Locked indicator on their lights! In exchange, decontamination above safe levels has a slightly different indicator (flashing red/yellow)
SSU gives chat warnings as to why it blocks decontamination (no items/safeties on)
SSU panel/super-decontamination icons work properly now
The SSU super-decontamination also creates a plume of black smoke at the end, as the flavor description said it did.
About The Pull Request
Adds an argument to typecache generation that allows specifying the whether to include/exclude types in the input list.
Also adds another argument to specify whether to remove falsey values after the typecache is generated.
Why It's Good For The Game
Might make zaps slightly faster???
Honestly I just thought it would be a good way to condense some whitelist/blacklist typecache sets.
makes dropkey deactivate device modules
fixes speed potion being fucky
fixes doubled up balloon alerts
makes some cell code better i think
makes the gps module open the gps tgui for you, instead of putting a gps in your hand
the loader suit can now hold mailbags
Reworks the mining modsuit.
The suit is no longer cold-proof (this can be mitigated by using module space for thermal regulators)
The suit fits less modules than standard suits, but cant burn in lava.
In suit storage it can carry ore bags, resonators and kinetic crushers.
It features a storage, gps, ore bag, drill, clamp and by default comes with a plasma core, being recharged with plasma ore rather than by power cell.
Features two new modules:
Ash Accretion, it gathers dust from basalt (or snow) you walk on to create a layer of ash around the suit, acting as armor and a speed up that quickly drains when you walk on other terrain.
Sphere Transform, turns you into a fast moving ball that can travel past lava, you cannot use your hands when in this form, but you can launch aoe mining bombs to attack or mine
About The Pull Request
Same vein (although a lot larger than) #64118
On the tin. This moves them into their own folders and the paths were updated in the code.
Why It's Good For The Game
It's not exactly good visuals for stuff that can be placed elsewhere to just be sitting in the root. Organization is nice.
Changelog
cl
fix: For those of you into code, some stuff with the icon pathing has been shuffled around so it's no longer in the roots of the icon/ folder. If you aren't into code, that's fine too.
/cl
* Revert " Properly speeds up a lot of things, mostly mobs (#64270)"
This reverts commit a836574388.
THE BYOND REF WAS A LIE, THE PLAYERS ARE FOOLS, HELP, HELPPPPPPP
It turns out that despite what the byond ref says, the walk proc's delays were not in fact in ticks, but in deciseconds.
This means when I "fixed" mob movement by doubling all walk delays, what I actually did was double the speed of anything that used walk()
I have a feeling that the actual issue players were seeing was just move_to having fucked up distance logic, and the movement of slow mobs being smoothed out. I've changed that, so hopefully this puts a seal on the whole problem
I've had a request put in to make beepsky faster, but I think that's best done in a seperate pr
* Adds a flag to disable smooth moveloop movement
Applies it to hostile mob's Goto()
Backports the fixes to move_to and move_away from the previous pr
Boritos finally decided to start supplying the station with their cornchips. This PR comes with 4 flavors of boritos that can be bought from vendors as well as a slight uplift for the sprite of Ready Donkmeal's trash variant, making it actually look like trash rather then a pristine box.
Also hey if you walk on boritos packages they pop! Thats cool right?
This removes code/__DEFINES/misc.dm and moves all the defines to either:
another existing define file
new define file
local .dm file if the define was only used in one file
I also deleted defines that were not being used and added documentation to all of the ones that were moved out of misc.dm
Why was this needed? People were basically using the misc.dm file as a dumpster to toss all their defines into that was creating one giant mess. The defines have been organized into their proper groups and files now.
When I made my move loop changes (815bb8a) 62567, I converted a few walk() procs to
the new system
What I didn't know when I did that conversion is that walk() operates on ticks, when move loops operate on
deciseconds
So when I converted say, mob movement over, I accidentially halved the attack movespeed of all of our mobs
This resolves that, alongside a few other misteps
Of note: There are old comments implying that walk()'s delay is not actually linear, or simply as the reference says "in ticks"
I don't have a good idea of how fast things actually should be though, which makes this tricky
In light of this, I've decreased the move speed of legion slightly, in hopes that it will feel more "normal"
I've also fixed a bug with move_to and move_away, they were treating their distance parameters as move to this and one more, rather then move to this. This lead to mobs attempting to overlap with your sprite. s cringe, and also fixed
fixes#64029 (Springlock MOD module kills you even when you have Memento Mori necklace)
fixes#64136 (modsuits cant run out of charge)
fixes#64158 (trying to install a battery into a modsuit with free storage space places the battery into storage)
fixes#64186 (ModSuits : taking out cell doesn't give it back)
fixes#64161 (Modsuit cores disappear in construction)
makes mod jetpacks show particles indoors
gives the prototype suit back their upgraded cell (they literally lose 1% of power per 3 seconds with their current one)
Fully reworks the kinesis module to not be TK but lamer, it is now a gravitational anomaly locked module.
Unique stuff that can be used in fun scenarios
* Adds a subsystem to handle automated directional movement, replaces all instances of walk_towards with it. Makes meteors and immovable rods not drift in space, and makes immovable rods more destructive. Note, I've opted not to use byond's method of moving towards something, which is effectively Move(src, get_step(src, get_dir(src, target))) as it's cringe and doesn't make a smooth line. I've replaced it with a autoupdating rise over run setup, read the code for more details
* woop forgot the subsystem
* Documentation, contributing.md entry, and some cleanup
* Makes the moveloop datum more oop friendly, sets us up for a lot of conversions
* Converts the curseblob and walk_away() to the subsystem
* Changes the default for override from FALSE to TRUE
* converts walk() over, still need to add a replacement proc for it, but we didn't actually have anything that used the raw proc
* converts the rest of walk_to() over, nearing the end now
* cleans up some errors
* Fully documents everything, fills in some missing movement types, uses the power of oop to make things cleaner, and typepaths longer
* Finishes the contributing.md stuff
* Done
* Fefaults -> Defaults, can you tell I wrote this at 1AM?
* resolves bubblegum issues
* Roh's suggestions
Co-authored-by: Rohesie <rohesie@gmail.com>
* Cleanup
* Hey lemon, did you know that Destroy() lives on datums? ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
* Converts over the discrepencies created in my absense
* HAHA FUCK YOU I PAY MY DUES
* Whoops lost some stuff in the merge
* Converts the system from seconds to deciseconds to make dealing with the api more sane
* Some stuff I missed
* Makes movement an inheritable subsystem type, splits the moveloop file into two, one for the subsystem, and one for the datums
* Makes a subsystem that handles directing movers out to other subsystems. It's a bit bad right now, but it's a
good first step. I think I'll move the move loop datum to a lazy var on mobs instead of an assoc list, don't
like lists.
Also makes the movement procs global, I'll move em to the /movement subsystem at some point or something like
that
* Converts the existing uses of the procs over to the new format
* Adds support for subsystem precedence, so a type of A can override type B.
General cleanup, still kinda in debug mode but it's getting better
* I'll admit I'm not too familiar with this, but I think it will work
* Adds starting logic so movement types "pausing" makes any sense
Redoes how waiting is handled to make it based on world.time directly. I don't remember why. I think it's better
this way.
Adds a drifting movement type, moves space drift over to it.
Needs severe work before it's ready, too much info stored and modified on the moving object, see comment
Starts work on making drifting smooth
* Moves almost all space drifting vars over to signals on the movement datum
Properly implements glide size stuff for both the subsystem and the loops. Space drift will be smoother now.
It's not perfect, but it'll work just fine for now
Adds a way to override a client'd mob's glide size mid move, uses it to make entering a spacedrift look right
Adds a way to delay a client move outside of just move_delay, meant to be used for long periods, and setup such
that it doesn't make inputs persist
Adds flags to movement loops, alongside MOVELOOP_OVERRIDE_CLIENT_CONTROL, which blocks client movements while
the loop is firing, and for it's visual delay after
This means you can't exit a space drift until you hit the actual wall. This feels a lot better
Some general logic stuff, move() will return true/false if it succeeded or failed
Adds a stop_loop() proc that's called when a move loop is no longer active
Suck my nuts
* Moves precedence to the loop instead of the subsystem
* Moves drifting into a component, this lets me explictly block input after the move loop ends, so people can't
move the moment they functionally move onto a new tile
This is a bit underdeveloped currently, but that's a problem for another day
Cleans up some uses of move procs, fixes runtimes in metoer and curseblob code
Adds signals for stopping/starting a move loop, sending one for destroy is redundant.
Moves existing event signals from the movable being acted on to the loop itself, makes more sense this way
Makes the move handler return the created loop up the chain so we can register to it
Fixes a logic error in loop contesting code that lead to loops never actually being removed from subsystems
because they didn't know they should be.
Properly changes lifetime from a time to stop, to functionally an amount of moves to complete before stopping
Adds some new signals for pre/post loop process. This is to better tie into components.
I decided I didn't like the idea of tying all functionality to the loops themselves
The loop decides functionally how to move, components or just tied in signals can decide when/when not to move
and can modify properties of the loop
Making a new loop for things like atmos drift, something I'm interested in tackling in the future, seemed silly
* Moves movement procs directly to the subsystem for better namespacing or whatever
* Moves movement packets onto /atom/movable, no longer need the debugging
I've decided to not just put their contents fully onto atom movable, since it makes debugging on live much
harder, can't sdql for them anymore.
Fixes a runtime in meteor code, properly this time
Fixes a logic error in stop_looping
Makes move manager NO_INIT, because well, it doesn't init
* Commits human sin, makes Recover() work properly for movement subsystems
* Fixes immovable rod orbits not always working, they were returning too early in moved and fucking up the var we use to track move count, and thus not sending a signal properly
* Reworks the curseblob to use signals more, and to not use override
* Missed this in the movement ss commit
* Removes override, makes having a higher or equal precedence take its place
* Updates documentation
* Cleans up some unused defines
* Nukes the unused flags option
* Whoops forgot to qdel check
* Removes an unused var I had for client move prevention before I started using a component
* Let's do this properly
* Modernizes meteor code to better match how explosions actually work currently
* Some more cleanup
* Cleans up effect code a little bit
Nukes the effect system's sleep loop, we use movement loops instead
As a part of that, instead of 1 timer per effect spawned, we react to loop failure and make it 1 timer per
effect system
This should reduce the amoumt of slowdown we see after mass lighting break
It's not everything, we're still making a timer per spark effect, but it cuts things down significantly
* Updates explosions to not sleep
* Adds support for modifying a loops delay post process, makes extinguisher code suck less then it does currently, nukes some more sleeps and timer loops
* Converts water tank resin over to move loops rather then sleeps, minor behavior change mind, the cooldown starts on fire rather then on land, but I think that makes more sense anyway
* compile and runtime fix
* Fixes some runtimes, cleans up some code, ensures feature parity when it comes to logging
* Prevents resin foam from space drifting
* Adds support for flags back into the system, I need it for reasons
* Updates move_towards to fix some bugs and resolve some inconsistent behavior, implements a flag that makes a loop's first move start instantly
* Fixes extinguishers not actually transfering any reagents
* Converts sprays to the new system. This does actually minorly change behavior, in that I've changed the order of spray actions from step -> sleep -> wash to step -> wash -> sleep, but I'm not terribly torn up about it because frankly I think it feels better
* Converts grav catapults over to the new system
* Converts trays over to moveloops
* Converts robot streaking to move loops, the other two coming soon
* Compile you won't. Also fixes a behavior issue with oil streaks
* Does directional step_to properly, cleans up the other two streaking types
* Converts step_trigger over, not that it's actually used anywhere. Changes how stoping a move works, you need to explicitly qdel, other the step is just considered to be ignored. This will make life easier later
* Adds a jps movement loop. It's a bit bloaty, id is stupid, but it'll work just fine
* Makes the system support passing in a datum that's just used as extra context for the move. The hope is this makes signalizing things less of an absolute headache
* Begins the conversion of ai movement datums to movement loops
* These two are reasonably simple, only weird thing I'm doing is A: Not allowing target hotswapping, which I hope none is doing, and B: passing the controller into the move loop as extra context so things work properly
* JPS is a bit more complex, partially because the old implementation was a bit weird. 2 major things. 1: I'm dropping what I think was a redundant behavior minimum distance check from the premove bit of logic, since I'm pretty sure it didn't do anything. 2, instead of just stoping the step in an error state like being pulled, we count it against our max move total
* Audit
* Moves most forced movement to the framework, adds some components to make things nicer
* Implements a flag that makes the loop always operate, regardless of precedence and without impacting any other loops
* Moves movement subsystems into the right folder
* Hey potato what if you had two procs that did the same thing and one called the other? Wow it's useless
* Merges slipping and force movement
* Converys conveyors over to the system. It's a bit fragile, but I think it's totally worth it to save the sleep loop
* Precedence -> Priority, cleans up some logic errors, makes priority highest to lowest instead of lowest to highest, straight cleans some code up
* Makes poly and bubbles ignore spacedrift, now that precedence actually functions properly. I'm likely missing cases of this, will deal with it later
* Depression, thy name is linter
* Fixes linter, and hopefully fixes the runtimes in ci too
* Wew
* Sets sprays and extinguishers back to legacy, since people do actually seem to have noticed
* Spelling errors my beloved
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* More detail, moves return descriptions
* Converts transit tubes to the system?
* Adds the glide size modifier. Not honestly sure that this should be default, considering how crummy it makes things look for normal walking, but it's useful as hell here
* Adds a force move in dir template, actual support for fast initial steps (wtf old me) and a helper proc for setting delay
* Cleans up displosal code a bit, I thought about adding it to the system but it would functionally be just 'disposal loops'. Maybe I'll make a template subtype? not sure how I want to handle stuff like this
* Cleans up mob movement a bit
* Let's use the controller's visual delay
* Makes the resin thrower nicer, cries
* Cleans up some comments, replaces an implicit world.icon_size with an explicit one, fixes up a typecheck
* typecache instead of double istype. Can't do much about the !atom/movable, list would be too big I feel
* hhh
* bro wtf
* Documents the why of SS_TICKER
* Puts SSmovement on SS_TICKER. Lets us support tick steps
* Cleans up the charge action. Makes it use moveloops
* Fixes CI? kinda worried that this just got dropped
* Converts disposal pipes to move loops. They stutter a bit more then usual as of now, hoping that's a me thing, if it's not I'ma look at uping the priority of the base subsystem
* Moves the move subsystems off background, puts some on ssticker
* Prevents some things that shouldn't move in space from moving in space
* Documents the general form and usage of the system
* Virgin one vs chad once
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Removes unneeded check
* Moves appropriate movement subsystems into SS_BACKGROUND. Removes redundant SS_KEEP_TIMINGs
I do want the behavior of SS_TICKER, which at this point is tick based waits, and ignoring overtime when
calculating next fire.
Since honestly, these subsystems should ignore overtime in regards to next fire, the cost of moving A may be
nothing compared to the cost of moving B.
* Makes the MODULUS macro use floor. I knew our coders would never let me down, glad this exists, thanks ninja
Fixes teleporting caused by shitty round() behavior, adds a "you hit your target" case to homing loops
* Converts blood splatters to move loops, that'll do it
Co-authored-by: Rohesie <rohesie@gmail.com>
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
Creates a wrapper macro for ex_act() and moves the signal and contents explosion calls to there. This way we can ensure the signal is always fired. Also desnowflakes reagents responding to explosions.
Ensures that a signal is always called when the attendant proc is called.
Atomizes a much larger PR for another time...
There are typos in span and other html messages that causes them to not render correctly or at all.
Bug fixes
Converts those instances of span to use the macro
I'm refactoring proximity monitors and fields, removing lots of bloat from both that's hardly even used. Proximity monitors no longer generate effect objects to track the surrounding area, should be less cpu expensive and easier to maintain (or phase out), read and use.
This PR also adds a couple components which may be needed for future stuff (for starters, the mirror reflection PR #62638 could use the connect_range comp)
Improving old old, ugly old code and adding some useful backend components. Tested and working.
