* Reconfigures the Infiltrator armor set into the Infiltrator modsuit. Comes with a brain agony demoralizer device, and makes it literally impossible to examine you.
Splits head dmi into separate files for both mob and obj icons. Kept similar to suit split categorization + some more. New files include beanie, bio, chaplain, costume, cowboy, default, hats(softcaps, fedoras, head caps, generic hats), helmet(helmets and other armored headgear/hoods), spacehelm, utility(hardhats, mostly work related hats), wizard.
Moves animal/pet head sitting icons to 1 folder, pets_head.dmi
Renames PAI head sitting icon file to pai_head.dmi
Code improvements are much appreciated as some things may be rather hacky.
Adds more options to the currently very limited modsuit adapter shell. Right now you can only select a module and activate (not deploy) the suit.
This has some major problems as you literally can't even deploy the suit to activate it so that's rendered useless and selecting a module is like... kind of a weird input anyways but I won't judge so I left it in. Please comment down below if you'd like for me to add an "Activate Selected Module" input and "On Module Activated" output as those are certainly possible to do. I was just a little torn on how balanced that would be.
Changes:
"Module to Select" input is now an option. You can still use a string input, but simply inserting it into the suit and activating it, then accessing the circuit that way will give you a list of all modules that the modsuit has.
Modsuit quick deploy (RMB) no longer tries to deploy the rest of the pieces when used while the suit is only partially deployed. It will now instead retract the extended pieces. This makes the "Toggle Deployment" input less prone to errors. (Why was it like this in the first place? Having to manually retract the already extended pieces sucks ass.)
Added Inputs:
"Toggle Deployment" is a new signal input that does exactly what it says it does. It simply tries to extend or retract all pieces of the modsuit depending on it's current state.
Added Outputs:
"Activated" is a new number output that outputs 1 if the suit is activated and 0 if it's not.
"Deployed" is a new number output that outputs 1 if all parts of the suit are extended and 0 if they aren't.
"Deployed Parts" is a new string list output that outputs a list of the names of all currently deployed parts.
"On Deploy" is a new signal output that outputs a signal whenever all parts of the suit are deployed or retracted, regardless of the method used.
"Finished Toggling" is a new signal output that outputs a signal whenever the suit has finished activating or deactivating, regardless of the method used.
* Makes flags properly check themselves
Byond ref: https://www.byond.com/docs/ref/#/operator/&
Basically, flags should use & instead of ==
We can have more than 1 slot on any item, so it's preferred that we do this instead. Even if it doesn't immediately fix any problems, it's something that should be the standard anyways to prevent it from ever being a problem.
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
About The Pull Request
I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.)
This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering.
I'll do my best to keep this compact, but there's only so much I can do. Sorry brother.
Core idea
OK: first thing.
vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc.
This is bad. But how to do better?
It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly.
We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed.
But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect.
Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on).
That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly.
Everything else is just gravy.
About the Plane Cube
Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane.
We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live.
As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well.
Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you.
About Plane Master Groups
BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc)
Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc.
So we need to maintain a mirror of each plane for every map we have open.
This was quite messy, so I've refactored it (and maps too) to be a bit more modular.
Rather then storing a list of plane masters, we store a list of plane master group datums.
Each datum is in charge of the plane masters for its particular map, both creating them, and managing them.
Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to.
Much better then the hardcoded pattern we used to use. So much duplicated code man.
Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers.
image
In addition, I've added a debug ui for plane masters.
It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays.
It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live.
In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc.
It also comes with an info dump about the ui, and plane masters/relays in general.
Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible.
See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md.
"Landing" planes
Ok so I've explained the backend, but how do we actually land planes properly?
Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use.
This is just a lot of gruntwork, but it's occasionally more complex.
Sometimes we need to cache a list of z layer -> effect, and then use that.
Also a LOT of updating on z move. So much z move shit.
Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags.
This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday
I also need to update mob overlays on move.
I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order.
The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet.
It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point.
Behavior changes
We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it.
So instead we display the other side as a ui element. It's worse, but not that bad.
Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior.
The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane.
I don't really care, but it should be fixable, I think, given elbow grease.
Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think.
Why It's Good For The Game
<visual candy>
Fixes#65800Fixes#68461
Changelog
cl
refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it
admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb
/cl
* Adds a base modsuit chestplate allow list, cutting down on copy paste
* Allows Jetpacks to work while equipped to a de-hardcoded slot_flags list
* Allows the Captain's jetpack to fit on space suits and MODsuits by default
* Makes the Captain's jetpack fit on the Suit storage slot.
* Reworks and resprites the metal hydrogen fireaxe
* Move the fireaxe icons around to fix the conflict.
Also kills the folder I made for items, as a previous PR splitting DMIs did that already.
* Deletes a DMI that I forgot to remove
the admin suit now has the advanced jetpack instead of the normal one
fixes chestplate unequipping no longer retracting the suit storage item
fixes the surgical processor causing runtimes with medborgs after the modsuit pr
fixes#68166fixes#68574
tweaks the colors on the security modsuit to be lighter, i think i did that on the original pr but it got reverted due to merge conflicts
makes the standard quick carry module have nitrile level carrying instead of latex level
environmental bodybags are now always pressurized
adds medical and security hardlight bags, which are environmental bags you can use to move people through space, security ones can be sinched to prevent escape
adds a medical version of the prisoner capture module, for patient transport, prisoner capture and patient transport now use the medical/security holobags, medical one deploying them faster. when you move too far out of range the holobag dissipates
adds a defibrillator module, extends shock paddles
adds a thread ripper module, this module temporarily rips away the matter of clothing, to allow stuff like injections, surgery, defibrillation etc through it
adds a surgery processor module, essentially a portable surgery computer like borgs have
fixes a bug where you can unwield defibrillator paddles just after starting the do_after to defib onehanded
fixes a bug where the modsuit gps would have a broken name when renamed
* - Fixes storage mass transfer
- Brings some sanity to storage procs
- Implements a griddle feature that never was
* Uncomment this
* Right-click attack fix
* Scoop fix
* Smartfridges use silent
* Restores some lost checks
* Fixes storage implants
* Makes condiments their own subtype, fixes geese, prepares for merging
* Fixes geese checking drink type instead of edible foodtype to eat gross food.
* Renames foodtype var on drinks to drink_types to prevent above from happening again because it KEEPS HAPPENING. DRINKS AREN'T FOOD!
* Makes Condiments their own subtype of reagent_containers because they don't make any use of being a subtype of food, at all.
* Starts moving things from food to /food/drink subtype in preparation for merging /food/drink with /drink
* fully removes Food subtype
* /reagent_containers/drinks are now /reagent_containers/cup - This is so it's no longer confused with eachother.
* /food/drinks is now /reagent_containers/cup/drinks, so we can keep their special abilities.
* Fixes a LOT of errors with food, which are STILL checking the reagent_containers, despite ACTUAL food being refactored away from it a long time ago.
This doesn't compile yet, but I do want to make sure my progress is well tracked.
* remove copypaste code, changes soda cans
* Removes most copy paste code between the two drinks, moving most stuff to parent whenever needed.
* Made soda cans their own subtype since they didn't share anything with glass bottles anyways.
* Fixes more problems with food/drinks, especially with geese. Geese really were just broken this whole time and no one said a word...
* Removes a snowflake signal, now that both drink types share a common one.
* Adds everything to the .dme
Currently my goal is to get this all compiling, then remove isGlass var by making glass be all glass ones only.
* Moves all icons into a single drinks dmi
I'm not that great at icon stuff, hopefully I didn't forget/break anything.
* Turns juices into their own subtype
This allows us to let them check for type in molotov, to both get rid of a use of isGlass, and so non-glass non-cartons don't show up as 'carton'.
* fixes compile issues, adds updatepaths
* a better updatepaths
* updates the damn maps now
* properly names the updatepath
* how did that get there
* i suck at handling merge conflicts
* how am i this bad
* code improvement and soda fix
* more fixes
* Don't be a timer
Ports from old food bottles to trans the reagents, rather than add a timer to.
* Merge conflicts and fixes bottle smashing
* Bottle smashing is now consistently functional regardless of how much liquid they have in them, when before it would spill first, then smash on the second hit.
* runs updatepaths again
About The Pull Request
Mood was abusing signals and get component pretty badly, so I redid it as a datum to stop this.
Why It's Good For The CODEBASE
Better code pratices, also gives admins easier tools to manage mood
Changelog
cl
admin: Added two new procs into the VV dropdown menu to add and remove mood events from living mobs.
/cl
the mining modsuit now costs 3000 from 2500
the mining modsuit now still slows you down over lava, though you still resist it
the plasma core now accepts plasma both in sheet form and ore form
the plasma core should no longer buggily not refill you
the mining modsuit bombs should now have enemies target you
Currently, storage works as a subtype of /datum/component, utilizing GetComponent() and signals to operate. While this is a pretty good idea in theory, the execution was pretty trash, and we end up with alot of GetComponent() snowflake code (something that shouldn't even need to be used frankly), and a heaping load of scattered procs that lead into one another, and procs that don't get utilized properly.
Instead, this PR adds atom_storage and proc/create_storage(. . .) to every atom, allowing for the possibility of storage on quite frankly anything. Not only does this entirely remove the need for signals, but it heavily squashes down the number of needed procs in total (removing snowflake signal procs that just lead to one another), reducing overall proc overhead and improving performance.
* destroy proc holder pt1
- change proc_holder/spell to action/cooldown/spell
- docs all the spell vars, renames some of them
- removes some useless vars
- start with pointed spells, as they're easy
* kill proc_holder pt2
- kill a buncha vars and replace it with flags
- convert a ton over
- general code improvements
* kill proc_holders pt3
- convert a good few more spells
- rename some signals
- handle statpanel
- better docs
* kiill proc_holder pt4:
- restructure the file system of action.dm, separating a good amount of item actions and miscellaneous garbage into files where they belong slightly better. Also splits off item actions, cooldown actions, innate actions, etc. into their own files, overlal making it much better to work with
- converts touch attacks to actions
- converts blood crawl, jaunt subtype
* kills proc_holder pt5
- clears up some icon issues so all the currently converted pages don't have errors
- shapeshift
- some more action cleanup
* kills proc_holder pt5.5:
- some documentation
- reworks feedback to prevent oversight with teleports and stuff
* kills proc_holder pt6:
- converted cult spells
- converted magic missile
- converted mime spells
- chipped away at the errors
- removed some vars which were too general, replaced them with more locally applicable vars. for example "range" which could mean "projectile range" or "aoe radius" or whatever - instead of having a broad net which everyone applies to in a confusing matter, instead lets each spell delegate on their own.
- merged magic/spell and magic/aoe, as the comment intended
- more unified behavior for spell levelling
* kill proc_holders pt 6.5:
- replacing a buncha old proc_holders that have been updated to reduce some errors. sub 900 baby
* kills proc_holder pt 6.75:
- minor fixes
* kills proc_holder pt7:
- cuts down on some errors
- refactors some wiz events
* kills proc_holder pt 7.5:
- malf ranged modules
- some minor errors
* kills proc_holder pt 7.75:
- mor eminor error handling, cleaning up changes
* kill proc_holder pt8:
- refactors spell book
- refactors spell implant
- some more minor error fixing
* kill proc_holder pt 8.5:
- scan ability
* Adds some robust documentation
* kill proc_holder pt9:
- converts some / most mutations over
* kill proc_holder pt10:
- sort out all the granters
- refactor them slightly
- fix some compile errors
* Some set-unset sanity - going to need to test removing Share()
* Removes transfer actions. It doesn't seem to do anything.
- Transfer_actions was called when current = new_character so locially speaking the early return in Grant() should cause it to NOOP. Test this in the future though
* Removes sharing from actions, docs actions better
* Some better documentation for spell and spell components
* Kills proc_holder pt11:
- Finally finishes ALL THE SPELLS IN THE SPELL FOLDER
- Fixes some more errors
* kills proc_holder pt11.5:
- minor error fixing and sanity
* Method of sharing actions. Can be improved in the future, needs testing
* Implements a way to update the stat panel entry for a spell. Also gets rid of VV stuff, as you can update the bigflags directly in VV now.
* Curse of madness bug I put in.
* kills proc_holder pt12:
- sub 500 errors!
- converts cytology mobs
- converts and refactors spiders slightly
- some minor fixing around the place as usual
* kill proc_holder pt13
- Finishes heretic spells
- Sub 300 errors!
- some touch refactoring to account for mansus grasp
* kills proc_holder pt14:
- revenant
- minor bugfixing for heretic stuff
* kills proc_holder pt14.5:
- some missed stuff for revenant + heretic
* kills proc_holder pt15:
- alien abilities
- more minor fixing
- sub 100 errors. The end is nigh
* kill proc_holder pt16? 17:
- Finishes cult spells
- sub 50 errors!
- refactors the way charge works
- renames / moves some signals
* kills proc_holder pt final:
- sdql spells
- no more errors!
* Bugfixes round 1
* Various bugfixing
- documentation done
- give spell works
- can cast spell gives feedback conditionally
- is available takes into account casting ability
* Some accidental reversions + fixes
* Unit tests
* Completely refactors jaunting
- All bloodcrawling is now handled on the action itself instead of across various living procs
- slaughter demons have their own blood crawls
- jaunting dummies don't have side effects on destroy() anymore
* Wizard spell logging and even more refactoring
Adds the Active Sonar Module to the game, a module which lets you see the locations of living creatures within a 9 tile radius.
It can be attained by researching Security Modules, and then printed like any other module.
It takes 3 complexity to house, has a 25 second cooldown, and takes a good amount of energy to use.
ever see the tram take 10 milliseconds per movement to move 2100 objects? now you have
https://user-images.githubusercontent.com/15794172/166198184-8bab93bd-f584-4269-9ed1-6aee746f8f3c.mp4
About The Pull Request
fixes#66887
done for the code bounty posted by @MMMiracles to optimize the tram so that it can be sped up. the tram is now twice as fast, firing every tick instead of every 2 ticks. and is now around 10x cheaper to move. also adds support for multiz trams, as in trams that span multiple z levels.
the tram on master takes around 10-15 milliseconds per movement with nothing on it other than its starting contents. why is this? because the tram is the canary in the coal mines when it comes to movement code, which is normally expensive as fuck. the tram does way more work than it needs to, and even finds new ways to slow the game down. I'll walk you through a few of the dumber things the tram currently does and how i fixed them.
the tram, at absolute minimum, has to move 55 separate industrial_lift platforms once per movement. this means that the tram has to unregister its entered/exited signals 55 times when "the tram" as a singular object is only entering 5 new turfs and exiting 5 old turfs every movement, this means that each of the 55 platforms calculates their own destination turfs and checks their contents every movement. The biggest single optimization in this pr was that I made the tram into a single 5x11 multitile object and made it only do entering/exiting checks on the 5 new and 5 old turfs in each movement.
way too many of the default tram contents are expensive to move for something that has to move a lot. fun fact, did you know that the walls on the tram have opacity? do you know what opacity does for movables? it makes them recalculate static lighting every time they move. did you know that the tram, this entire time, was taking JUST as much time spamming SSlighting updates as it was spending time in SStramprocess? well it is! now it doesnt do that, the walls are transparent. also, every window and every grille on the tram had the atmos_sensitive element applied to them which then added connect_loc to them, causing them to update signals every movement. that is also dumb and i got rid of that with snowflake overrides. Now we must take care to not add things that sneakily register to Moved() or the moved signal to the roundstart tram, because that is dumb, and the relative utility of simulating objects that should normally shatter due to heat and conduct heat from the atmosphere is far less than the cost of moving them, for this one object.
all tram contents physically Entered() and Exited() their destination and old turfs every movement, even though because they are on a tram they literally do not interact with the turf, the tram does. also, any objects that use connect_loc or connect_loc behalf that are on the same point on the tram also interact with each other because of this. now all contents of the tram act as if theyre being abstract_move()'d to their destination so that (almost) nothing thats in the destination turf or the exit turf can react to the event of "something laying on the tram is moving over you". the rare things that DO need to know what is physically entering or exiting their turf regardless of whether theyre interacting with the ground can register to the abstract entered and exited signals which are now always sent.
many of the things hooked into Moved(), whether it be overrides of Moved() itself, or handlers for the moved signal, add up to a LOT of processing time. especially for humans. now ive gotten rid of a lot of it, mostly for the tram but also for normal movement. i made footsteps (a significant portion of human movement cost) not do any work if the human themselves didnt do the movement. i optimized has_gravity() a fair amount, and then realized that since everything on the tram isnt changing momentum, i didnt actually need to check gravity for the purposes of drifting (newtonian_move() was taking a significant portion of the cost of movement at some points along the development process). so now it simply doesnt call newtonian_move() for movements that dont represent a change in momentum (by default all movements do).
also i put effort into 1. better organizing tram/lift code so that most of it is inside of a dedicated modules folder instead of scattered around 5 generic folders and 2. moved a lot of behavior from lift platforms themselves into their lift_master_datum since ideally the platforms would just handle moving themselves, while any behavior involving the entire lift such as "move to destination" and "blow up" would be handled by the lift_master_datum.
also
https://user-images.githubusercontent.com/15794172/166220129-ff2ea344-442f-4e3e-94f0-ec58ab438563.mp4
multiz tram (this just adds the capability to map it like this, no tram does this)
Actual Performance Differences
to benchmark this, i added a world.Profile(PROFILER_START) and world.Profile(PROFILER_START) to the tram moving, so that it generates a profiler output of all tram movement without any unrelated procs being recorded (except for world.Profile() overhead). this made it a lot easier to quantify what was slowing down both the tram and movement in general. and i did 3 types of tests on both master and my branch.
also i should note that i sped up the "master" tram test to move once per tick as well, simply because the normal movement speed seems unbearably slow now. so all recorded videos are done at twice the speed of the real tram on master. this doesnt affect the main thing i was trying to measure: cost for each movement.
the first test was the base tram, containing only my player mob and the movables starting on the tram roundstart. on master, this takes around 13 milliseconds or so on my computer (which is pretty close to what it takes on the servers), on this branch, it takes between 0.9-1.3 milliseconds.
ALSO in these benchmarks youll see that tram/proc/travel() will vary significantly between the master and optimized branches. this is 100% because there are 55 times more platforms moving on master compared to the master branch, and thus 55x more calls to this proc. every test was recorded with the exact same amount of distance moved
here are the master and optimized benchmark text files:
master
master base tram.txt
https://user-images.githubusercontent.com/15794172/166210149-f118683d-6f6d-4dfb-b9e4-14f17b26aad8.mp4
also this shows the increased SSlighting usage resulting from the tram on master spamming updates, which doesnt happen on the optimized branch
optimized
optimization base tram.txt
https://user-images.githubusercontent.com/15794172/166206280-cd849aaa-ed3b-4e2f-b741-b8a5726091a9.mp4
the second test is meant to benchmark the best case scaling cost of moving objects, where nothing extra is registered to movement besides the bare minimum stuff on the /atom/movable level. Each of the open tiles of the tram had 1 bluespace rped filled with parts dumped onto it, to the point that the tram in total was moving 2100 objects. the vast majority of these objects did nothing special in movement so they serve as a good base case. only slightly off due to the rped's registering to movement.
on master, this test takes over 100 milliseconds per movement
master 2000 obj's.txt
https://user-images.githubusercontent.com/15794172/166210560-f4de620d-7dc6-4dbd-8b61-4a48149af707.mp4
when optimized, about 10 milliseconds per movement
https://user-images.githubusercontent.com/15794172/166208654-bc10086b-bbfc-49fa-9987-d7558109cc1d.mp4
optimization 2000 obj's.txt
the third test is 300 humans spawned onto the tram, meant to test all the shit added on to movement cost for humans/carbons. in retrospect this test is actually way too biased in favor of my optimizations since the humans are all in only 3 tiles, so all 100 humans on a tile are reacting to the other 99 humans movements, which wouldnt be as bad if they were distributed across 20 tiles like in the second test. so dont read into this one too hard.
on master, this test takes 200 milliseconds
master 300 catgirls.txt
when optimized, this takes about 13-14 milliseconds.
optimization 300 catgirls on ram ranch.txt
Why It's Good For The Game
the tram is literally 10x cheaper to move. and the code is better organized.
currently on master the tram is as fast as running speed, meaning it has no real relative utility compared to just running the tracks (except for the added safety of not having to risk being ran over by the tram). now the tram of which we have an entire map based around can be used to its full potential.
also, has some fixes to things on the tram reacting to movement. for example on master if you are standing on a tram tile that contains a banana and the TRAM moves, you will slip if the banana was in that spot before you (not if you were there first however). this is because the banana has no concept of relative movement, you and it are in the same reference frame but the banana, which failed highschool physics, believes you to have moved onto it and thus subjected you to the humiliation of an unjust slipping. now since tram contents that dont register to abstract entered/exited cannot know about other tram contents on the same tile during a movement, this cannot happen.
also, you no longer make footstep sounds when the tram moves you over a floor
TODO
mainly opened it now so i can create a stopping point and attend to my other now staling prs, we're at a state of functionality far enough to start testmerging it anyways.
add a better way for admins to be notified of the tram overloading the server if someone purposefully stuffs it with as much shit as they can, and for admins to clear said shit.
automatically slow down the tram if SStramprocess takes over like, 10 milliseconds complete. the tram still cant really check tick and yield without introducing logic holes, so making sure it doesnt take half of the tick every tick is important
go over my code to catch dumb shit i forgot about, there always is for these kinds of refactors because im very messy
remove the area based forced_gravity optimization its not worth figuring out why it doesnt work
fix the inevitable merge conflict with master lol
create an icon for the tram_tunnel area type i made so that objects on the tram dont have to enter and exit areas twice in a cross-station traversal
add an easy way to vv tram lethality for mobs/things being hit by it. its an easy target in another thing i already wanted to do: a reinforced concept of shared variables from any particular tram platform and the entire tram itself. admins should be able to slow down the tram by vv'ing one platform and have it apply to the entire tram for example.
Changelog
cl
balance: the tram is now twice as fast, pray it doesnt get any faster (it cant without raising world fps)
performance: the tram is now about 10 times cheaper to move for the server
add: mappers can now create trams with multiple z levels
code: industrial_lift's now have more of their behavior pertaining to "the entire lift" being handled by their lift_master_datum as opposed to belonging to a random platform on the lift.
/cl
About The Pull Request
Makes smoke propagate the fingerprints of the last person to touch the source of the smoke.
This makes gunpowder smoke actually log the person responsible for the explosions.
Why It's Good For The Game
As of right now gunpowder smoke (and similar) doesn't actually have very good logging as as far as the smoke is concerned it's never been touched and so the resulting explosions are blameless. Obviously, scrolling up for a good minute looking for who has just obliterated the escape shuttle is slightly annoying for the admins. Ergo, making the explosions log who actually is responsible for making the smoke they originate from should reduce admin annoyance.
Changelog
cl
admin: Smoke now logs the last person to touch the source of the smoke as the last person to touch the smoke itself. Gunpowder smoke should be less annoying to log dive as a result as every explosion will log that person.
/cl
Why It's Good For The Game
Ninja code is pretty bad, I think it's best to move away into nice modular stuff instead.
Changelog
cl Fikou, PositiveEntropy, Nerevar, InfraRedBaron
refactor: the ninja space suit is now a modsuit
fix: fixes dash beams not working
/cl
* Fuck you (refactors ur tails)
* Errors
* Wow. Pain.
* Fixes up probably everything
* finish up here
* Fixes hard del maybe
* original owner hard del
* garbage collection runtime
* suck my peen byond
* Mapped tails
* motherfucker.
* motherrfucker. again.
* Whooopppppsie
* yeah bad idea
* Turns out external organs literally just sat in nullspace forever if their parent was deleted, and didnt Remove() themselves, causing harddels.
* So anyways I repathed all organs
* Fixes
* really.
* unit test... test
* unit test-test but it passes linters this time because im a moh-ron
* I've lost track of what im doing at this point
* Hopefully fixes hard del?
* meh
* Update code/datums/dna.dm
* things n stuff
* repath from master pull
* New illiterate quirk that makes a person unable to read or write. This applies to books, PDAs, paper, computers, and other electronics.
* New brain trauma dyslexia that makes you illiterate until fixed.
* Ashlizards are now illiterate as a default starting trait. The mining shuttle computer has been updated to compensate illiterate mobs randomly smashing buttons that causes a shuttle launch.
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Jetpack and spacedrift: Fixes and niceties
Ok so when I ported spacemovement onto movement loop,
I neglected to port this behavior that existed to support jetpacks.
Basically, if something that lets you move while spacedrifing
completes a move while you're spacedrifting, the
drift should "disable" to let it complete, and then later restart.
I neglected to add support for that, so that's what this does.
There's some other stuff going on here, mostly things to let jetpacks
ignore some of drift's extra behavior, since when a jetpack is not on
stablized, we want both to coexist.
It's a bit of a mess, I'm sorry about that.
Oh and at temporal's suggestion I've moved the visual_delay set from
newtonian move to an istype on the drift component, that was a good
idea, thanks quiet
* Makes dropping a pull while drifting carry the momentum into the pulled thing\
* Adds some extra context to Process_Spacemove, fixes a bunch of stupid
space bugs
It used to be, if you called Process_Spacemove with a direction, it
assumed you were an "action", so a client or mob trying to move in a
direction.
Unfortuantely for it, I needed to be able to use direction to make mob
pull drifting work. So we now actually pass in a second variable
called continuous_move, which tracks if this Process_Spacemove is on
behalf of a continuous move or not
In addition to this, I've added logic to bumping "off" someone to
prevent backbumping if that makes sense, since the bump is in the form
of a newtonian move that's run before the thing that's bumping actually
moves, we need some way to exclude it from holding the other object in
place.
* Adds a jetpack component, uses it to unify all three versions of
jetpacking
I hate you fikou
There were three copies of the same behavior, which made it hard to fix
stuff. Let's just componentize it
* Fixes jetpacks stabalizing even without fuel
This is mildly hacky. The real fix is to do this with events, but I
really don't wanna bend my brain like that. This'll do
* Ensures turn_off always has a user)
* Shut pu
* Bulky drags no longer effect your movespeed in space, fixing a consistency issue between them and all other forms of drags
* Removes some redundant code, cleans up some messy stuff
* Removes redundant safety checking from jetpack code
* see above
* Removes redundant signals
Doubles the range of the MOD Pathfinder AI
Fixes modules rendering below the suit.
Adds the ability for modules to be used when inactive.
Documents/cleans up some code.
Updates some old descriptions and explains some concepts better.
Armor Booster and Ash Accretion can no longer boost your speed over no slowdown at all.
Makes flashlight module start with 4 instead of 3 range, so it's better for people that don't know about configuration.
Doubles t-ray module range, from 2 to 4 (t-ray scanner is 3).
Puts the noslip module lower in progression, lowers its' price to 2.
New sprites for the magnetic harness module by Onule.
Brings back the holster module, it can now be used when the suit is inactive, can be printed with security suit research.
Adds the power kick module for the ERT Commander. It's a powerful kick.
refactors our disease code a tiny bit
removes permeability_coefficient variable from clothing, it decided how much stuff like chems or disease passed through your clothes, while BIO armor only decided how much you could spread diseases yourself, making it pretty much laughable
permeability_coefficient is now fully rolled into bio armor, so your bio protecting stuff will now protect you from other biological hazards like blobs
Have you ever noticed that the chemical smoke and chemical foam reactions are a lot less effective in confined spaces? This is because they currently attempt to spread to all tiles within n steps of their origin. If they can't expand onto a tile they get blocked and the expanding cloud/flood misses out on all the tiles that would be in range, but that can't be reached.
Obviously smoke and foam getting blocked by walls and the like makes intuitive sense, but it seemed a bit nonsensical that walls would basically delete a significant chunk of an expanding, amoebic mass. The solution I came up with is making smoke and foam expand until they cover a certain area, with a shared tracker for the target size and total size of the flood. The flood will simply expand as normal until it covers the desired target area. Blocked expansions just don't count and will be made up for with expansion elsewhere.
Attendant to these changes are a whole bunch of minor code improvement to smoke, foam, and one for wizard spells because I was already in the area and :pain:.
There have been some minor balance changes to the chemical smoke and foam reactions:
I converted them over to passing the desired area of the resulting smoke cloud/foam flood. The old equation for the resulting area was along the lines of 2sqrt(x)(sqrt(x) + 1) + 1 given reaction volume x and given unobstructed expansion. I've made them just pass around 2x instead. This is actually less than they used to try for, but now they're guaranteed to reach that unless the flood is fully contained. Not entirely certain if buff or nerf. Probably buff on the station.
Also, foam dilution is now based on covered area instead of target expansion range. Since this scales faster than it used to foam has been effectively nerfed at high volumes. To compensate for this I removed the jank 6/7 effect multiplier and increased the base reagent scaling a bit. Again, not certain if buff or nerf.
* Removes all supurfolus uses of QDEL_HINT_LETMELIVE
This define exists to allow abstract, sturucturally important things to
opt out of being qdeleted.
It does not exist to be a "Immune to everything" get out of jail free
card.
We have systems for this, and it's not appropriate here.
This change is inherently breaking, because things might be improperly
qdeling these things. Those issues will need to be resolved in future,
as they pop up
* Changes all needless uses of COMSIG_PARENT_PREQDELETED
It exists for things that want to block the qdel. If that's not you,
don't use it
* Adds force and hard del verbs, for chip and break glass cases
respectively
The harddel verb comes with two options before it's run, to let you
tailor it to your level of fucked
* Damn you nova
Adds proper parent returns instead of . = ..()
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* Ensures immortality talismans cannot delete their human if something goes fuckey. Thanks ath/oro for pointing this out
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
