- Makes QDELETED use isnull(x) instead of !x, giving about 0.2 to 0.25s
of speed.
- Make disposal constructs only update icon state rather than go through
expensive overlay code. Unfortunately did not have much effect, but is
something they should've been doing nonetheless.
- Makes RegisterSignal only take signals directly as opposed to
allocating a fresh list of signals. Very few consumers actually used
this and it costs about 0.4s. Also I think this is just a bad API anyway
and that separate procs are important
`\bRegisterSignal\((.*)list\(` replaced with `RegisterSignals($1list(`
Similar vein to #37116
This is supposed to be standard, yet here we are.
SHOULDN'T change anything, but there's likely something out there that's
bound to behave different because of it.
These were done manually, regex to find things that MIGHT need to be
corrected;
`^#define.+\+((?!\)).)*$`
`^#define.+-((?!\)).)*$`
`^#define.+\*((?!\)).)*$`
`^#define.+\/((?!\)).)*$` (yeah that's a lot of stuff.)
`^#define.+%((?!\)).)*$`
`^#define.+SECONDS((?!\)).)*$`
`^#define.+MINUTES((?!\)).)*$`
## About The Pull Request
reduces the damage modsuit bombs do vs. objects from 15 damage to 12.
## Why It's Good For The Game
whoever made modsuit bombs decided to define a damage variable with an
autodoc comment of "Damage done on explosion.", then _only use it for
object damage_, with a *hardcoded value of 12* being used for the damage
to mobs. it's a 3 point difference in damage, so I figured that the
better solution would just be to just unify the damage values instead of
making a new variable for this.
an alternative I considered was buffing the damage vs. mobs/hostile mobs
from 12/48 to 15/60, but idk if that'll affect lavaland balance in a bad
way. if it won't, go ahead and tell me and I'll do that.
## Changelog
🆑 ATHATH
balance: The damage modsuit bombs do to objects has been reduced from 15
damage to 12, to match the damage they deal to non-hostile mobs.
/🆑
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
when you mine gibtonite using concussive gauntlets, you now get launched
away from it, so you wont get hit by the explosion
also lets them mine basalt for glass
I went into this just planning on fixing some weird behaviour with
spider buttons and ended up touching a lot of files.
Specifically this is because some of the actions used by Giant Spiders
would print feedback messages in IsAvailable, which was bad because this
is called every time the button updates and so would (for example) print
a bunch of messages about eggs existing when you spawned as a
broodmother because the lay eggs button would be checking for that when
it was granted to you.
The feedback _is_ useful though so I've implemented a pattern used in
Spell where we just pass a flag describing whether we want to print it
or not, which is generally set to true in Trigger() or if the player
physically pressed the button.
A side effect of this is that any action with usability flags (such as
"not when handcuffed") will now tell you why it is failing if you click
it while it is unusable, which is nice.
The spider changes are largely to make sure that their buttons are
tinted at the correct time, they were previously tinted red as if
inactive at almost all times due to the icon not being updated when
relevant conditions changed.
This necessitated adding a new signal (two actually) sent when a
do_after begins and when it ends (for any reason, including premature
interruption).
I also fixed a quirk where the Wrap ability had a permanent 'active'
outline after using it once (the icon states were inverted).
I also fixed a bug where you could just lay infinite enriched eggs after
eating one guy, which is not how the game describes it as working.
I looked up the PR adding it
(https://github.com/tgstation/tgstation/pull/54451) and one egg per kill
seems to be how it is supposed to work.
And finally I changed a few nurse spider to_chats into balloon_messages,
on the principle that they're not information which needs to stick
around for more than a few seconds.
About The Pull Request
Adds a skillchip to the chef's vendor. This vendor allows the chef to kiss their food to deliver a chef's kiss.
Chef's kissing your food will add the "love" reagent to the food, which makes people much happier when they eat it. Be careful, overdosing on love can cause heart attacks.
Refactors microwaving.
Separates microwaving out of the edible component and makes it its own element, like grillable and bakeable.
Also removes some magic numbers from microwave code.
Code improvements all around baking and grilling code.
Refactors edible component inheritance.
Inheriting the edible component is now a viable way to cleanly add food types, flags, and callbacks. This makes it much much easier to change the values of an edible item without adding hacky signals / procs / getcomponent.
Why It's Good For The Game
Emergent chef gameplay.
Being able to further enhance your food with mood buffs.
Better code.
Changelog
cl Melbert
add: Chefs can now make food with love. They can purchase a skillchip from their vendor which enhances their kiss emote. Using your kiss on food you create will add a special reagent to it which makes it nicer.
refactor: Separated Microwavable from the Edible component, refactored microwave act to accompany this
refactor: Refactored how grilled items are generated
refactor: Refactored how silver slime food items are generated
refactor: Refactored how edible items inherit new edible statuses
code: Removed some magic numbers from microwaves
code: General code improvements for grillable / bakeable / etc
/cl
## About The Pull Request
Makes space ninjas spawn with their modsuit action buttons already
pinned
## Why It's Good For The Game
The radial menu isn't really practical for abilities you're going to be
using mid-combat, the throwing star dispenser is especially bad since
it's basically impossible to use at the rate it comes off cooldown if
you don't have it pinned.
People shouldn't need to know how to pin the modules or to go through
the UI pinning each of them just for the antag to be playable.
## Changelog
🆑
qol: Space Ninja now has their MODsuit module buttons pinned by default
/🆑
## About The Pull Request
so, scope and kinesis are the only things in the game (other than the
body zone selector) which use the function MouseMove. this tracks every
mouse movement, which meant we had to stuff a cooldown on it to not
calculate a ton of useless stuff. this time can misalign if you move
your mouse fast, not registering at all, as well as not working out with
the 0.2 second processing time of the things handling it (the scope
component and kinesis module)
instead of doing that, we are now keeping the mouse parameters as a
variable, which we update with every mousemove to the current
parameters. then we handle the calculations right as we need them (in
the kinesis/scope) module, rather than relying on mousemove cooldowns,
this should hopefully feel way better
## Why It's Good For The Game
😁
## Changelog
🆑
qol: sniper scopes and kinesis module should feel better to use
/🆑
* Fixes halloween races.
- Fixes a race condition involve checking for holidays befores SSevents is instantiated. Now, holiday checking is done through a helper, which will ensure the holidays list is created and filled before checked.
* Core internals refactor. Add open/close_internals procs to /obj/item/tank. Add open/close_internals, can_breathe_internals, and invalid_internals procs to /mob/living/carbon. Fixed bug in human_stripping.dm preventing changing internals for breathing tube users. Fixed bug in /obj/item/tank/toggle_internals that was auto-adjusting non-internals masks. Fixed bug in slements/strippable that caused two mobs to breathe from the same internals.
* 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
