About The Pull Request
Cows are now grazers, they love eatin' wheat and it even heals them if hurt. If they see it just on the ground, they might eat it all! Careful, botanists! While tamed, cows won't eat off the ground if they're busy ferrying you around.
FYI: this is going to conflict with #69247 and so thiss should not be merged until that is
Why It's Good For The Game
Wanted to add this with the original port of cows to basic mobs, didn't have the TECH to do so. Now I do, now it's done. I also wanted it ready for the future where mice and rats are ported, so they'd seek out cheese to eat. I also also think it's a neat way for a cow to heal.
Adds the capability of fishing in chasms.
Chasms contain Chasm Chrabs, which are cute little crustaceans you can eat or put in an aquarium.
More importantly, chasms contain everything which has ever fallen into a chasm.
Falling into a chasm is no longer instant permanent round removal... as long as someone is willing to do some fishing, which means your chances of return haven't necessarily increased that much.
Potential rescuers (or people lamenting about how they dropped their necropolis chest into a hole) should also beware, chasm crabs are actually young Lobstrosities and there's a rare but not insubstantial chance that you'll fish one of them up instead, which won't make it very happy.
If you somehow come back to life inside a chasm (generally only likely by being a changeling or some admin interference, but perhaps you have some kind of implant which does it) you'll climb back out again, so holes are no longer a way of disposing of a changeling for good. You think The Thing would be defeated if you threw it down a hole?
Ethereals can't manage this because falling into a chasm causes too much damage and they simply smash on the way down.
add: You can now fish in chasms, and might manage to catch things that careless miners have dropped in there.
add: If your pole is long enough to reach into a deep hole, you might catch crabs.
balance: Changelings can climb out of chasms if you throw them into one.
imageadd: An icon of a nice little crab, who will grow up into something less nice.
add: You can craft fishing equipment from various lavaland materials, so that Ashwalkers can fish up dead miners before you.
add: You can sometimes find worms while digging up tiles, if appropriate for that material.
Moves singulo and supermatter dmis into obj/engine, renamed from obj/tesla_engine
Moves Halloween, Christmas, and misc holiday items to obj/holiday
Moves lollipops to obj/food
Moves crates, closets, and storage to obj/storage
Moves assemblies to obj/assemblies
Renames decals.dmi to signs.dmi ...because they're signs and not decals
Moves statues, cutouts, instruments, art supplies, and crayons to obj/art
Moves balloons, plushes, toys, cards, dice, the hourglass, and TCG to obj/toys
Moves guns, swords, shields to obj/weapons
refactor: A bunch of things that used to not do anything (or just fall back on the chest) when targeting a limb that someone was missing will now be far more likely to attack another limb!
1- Replaces checks for deafness as a clothing trait, since clothing traits' have a ref to themselves in the source
2- Makes ear healing not NOT heal if you're above 0 ear damage, because that's the point of fixing your ears?
About The Pull Request
span_userdanger -> span_danger
Why It's Good For The Game
I think it's hilarious that it's that big, but it's not necessary. It only makes sense for blind hit alerts which use span_userdanger for nonblind alerts too.
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
* Fixes rust element not correctly using tool procs, now welding rust off will properly blind the user.
Co-authored-by: Capybara <Capybara@CapybaraMailingServices.com>
Bileworms are a new lavaland monster, that has unique AI that should prove them.
Instead of moving normally, it periodically burrows underground and resurfaces nearby.
Its attack is an AOE acid spit.
About The Pull Request
replaces a ton of log_game with user.log_message so the log is added to individual and global logs.
adds a few logs for individual LOG_VICTIM, LOG_ATTACK etc logging.
adds logging for bluespace launchpad's tele coords being changed.
took the word "has" out of log_combat, as it's extra and just lengthens the log.
Why It's Good For The Admins
It's extremely laggy to open game.txt so an alternative is individual game logs
Changelog
cl
admin: A lot of game logs will now also be in individual game logs, for convenience in log diving.
admin: Added logging for bluespace launchpad x and y offset changes, which go to individual game logs.
admin: Attack logs will now be slightly shorter, one useless word was removed.
/cl
* Food trash element drops trash when used
Makes trash food element drop the trash food (like candy wrappers) when used as an ingredient in stuff, like putting it in a bowl to turn it into a salad.
* Update food_trash.dm
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.
About The Pull Request
Fixes some cases in which actual references were used in trait sources instead of keys (or ref() keys).
This can cause some rare and difficult to find hard deletes.
Trait sources should be a string key relating to the source of it, not an actual reference to what added it. References within trait sources are never handled in Destroy(), because it's not expected behavior, meaning it can cause hanging references.
So, I went through with a regex to find some cases and replaced them.
I used the following and just picked through the few by hand to find erroneous ones.
ADD_TRAIT\(.+, .+, [a-z]+\)
REMOVE_TRAIT_TRAIT\(.+, .+, [a-z]+\)
Why It's Good For The Game
Less hard deletes, probably.
Changelog
cl Melbert
code: Some traits which mistakenly were sourced from a hard reference are no longer.
/cl
* adds examine_block class and a define for it
made some outputs in chat use examine_block
* add examine block to tip of the round
clean up some ------ and ***** seperators
added <hr> tags to divide sections
cleaned up botany plant analyzer text outputs
* bullet points for reagents
* removes <hr> from mobs examines
fixes AIs and borgs having a double "That's Default Cyborg!"
removed some \n newlines
minor code edits
* removes all <hr>
bold names in get_examine_name()
cleaned up plant analyzer output formatting
adjust colors and margins of examine_block class
remove \a from borg examine()
* remove max-width from css
* changed margin and padding units from px to em
* minor edit
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
Adds fishing and fishing minigame.
You use fishing rod to fish.
Equipping specific bait/hook/reels will affect your success chances.
You can fish out fish,items and other things.
Fishing Equipment
Fishing rods have three slots: Bait, Reel and Hook.
Any food can be used as bait but dedicated bait makes fishing easier.
You can buy hook and line sets
New bait types:
Worms : Buy can of them at cargo (alternative acquirement method pending)
Doughballs : Use knife on flat piece of dough to get five of them.
Fishing rod types:
Basic : Print these at the lathe, nothing fancy here.
Tech: Experimental tech. Provides infinite bait
Fishing rods can also hook and reel normal items.
Equipment screen and reeling video
Fishing spots
Keep in mind this PR is meant to add the basic systems and i intend to fill these with more fish in future PR's so wait with suggestions until then.
Lavaland lava (no fish here right now, just other stuff), requires reinforced line to fish in.
Maintenance moisture traps.
Beach away mission water.
Fishing portal available for purchase from cargo - This is stopgap until we fill more spots.
Difficulty depends on fishing spot, fish type, and the fish traits and rod setup combinations.
All fish types can have specific traits, most common ones being favourite and disliked bait types/categories.
Other
Fishing catalog now lists fishing related info
New admin debug verb, fishing calculator that show probabilities with different setups so it's easier to balance this.
Fish now have average weight and size. Make sure to boast if you catch a big one.
Adds tgui mouse passthrough
Screens
Sprites:
Fishing portal sprite by @ArcaneMusic
Other sprites by @Mey-Ha-Zah
Bad ones by me. (Could still use better fishing minigame backgrounds)
Sounds:
https://freesound.org/people/soundscalpel.com/sounds/110393/https://freesound.org/people/soundslikewillem/sounds/343748/
Fixes#67622#66530 made it so anything with the ridable element lost the element whenever it died.
Unfortunately it added NO supplementary logic that re-adds the ridable element of that thing died.
Guess what uses the ridable element? Humans, for fireman carrying and piggybacking
So, if you ever died, it'd permanently brick your ability to fireman carry.
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
* Makes ridable not work if you cant hold the offhand
Because amount_equipped is 0, and because not being able to insert the riding_offhand only break's, rather than returns FALSE to cancel, it goes on to fireman carry you're not supposed to be able to carry, leading to situations where people are fireman carrying others and is completely unable to drop them.
* adds a block buckle to slime's traits too
* refactor it back to a single organ but with different eye vars
* nOt In A LoOp
* forgot emissive overlay
* remove old obscured var
* quirk
* fine we do it like this, PAIN
* add applying_preference paramter to is_accessible and check for it when applying
* update dummy on quirk change
* client might not exist if we are applying the preference, because unit tests
* unique icon
* lazy webedit review
* revert is_accessible refactor
* mild stupid
* change the way heterochromia is applied
* better handling
* Apply suggestions from code review
* add apply to human behaviour
* hopefully fix that which the merge hooks broke
* Update code/datums/quirks/neutral.dm
* Web commit for shame
* Update code/datums/quirks/neutral.dm
* Update code/datums/quirks/neutral.dm
Co-authored-by: Ryll Ryll <3589655+Ryll-Ryll@users.noreply.github.com>
* Update basic.dm
Co-authored-by: Ryll Ryll <3589655+Ryll-Ryll@users.noreply.github.com>
About The Pull Request
Fixes#63868. Actual one liner fix for this one here. If this pr dies feel free to atomize this one.
AND it turns out to not be tim's fault.
Fixes#63548. But i really shouldnt say fixed. The original implementation was causing the invincible plating bug. When tim's refactor got in it instead relies on the element state, which was broken from the get go, removing the invincible plating bug which was in a sense "intended" its all messy man I hate this code. Thats why im removing the plating thing. Let the turf handle the turf change themselves this complicates things.
Mapped in glass floors have openspace (now baseturf bottom) as their baseturfs, while built ones have plating under them. Which doesnt make sense to be honest. Why would things be visible if a plating is under the glass. They are also crowbarrable on top of this, which to be fair is my main reasoning behind the PR.
To solve this, I am instead making glass floors replace the plating instead of building over it. This is made to be generalizable for every tile in game, as long as their initial baseturf is the same and the tile wants it to happen.
do after of three seconds is completely arbitrary. If any maint want it changed let me know.
Why It's Good For The Game
First one solves a bug
Second one makes more sense
And er, icebox is currently using the glass floors in sec, they can be crowbarred very easily. This might be a good idea from a gameplay perspective.
Changelog
cl
del: Removed adding glass floors to plating
balance: Allows you to replace plating with glass floors instead. 3 second timer.
del: Removed deconstructing the glass floors. No replacement for this one, use a rcd.
fix: Fixed metastation glassfloor spawning a weird turf when crowbarred.
/cl
* Life() Optimization Part 1: Organ order
It turns out organ code is really quite dumb. Wastes a lot of time.
I'm going to be doing what I can to optimize it in this branch.
To start with:
If we can ensure organs are sorted according to organ_process_order inside
internal_organs_slot
We can do away with a needless get_organ_slot call in handle_organs, and
avoid needing to iterate over 30 entries, one per possible organ slot,
instead iterating just the ones we have
This saves roughly 5% of life
* Organ Optimization Part 2: base on_life()
Organ on_life, despite not looking it, is a remarkably hot proc. Called
something close to 9 times for each human on the map, it's worth taking
care to clean it up.
As things currently stand, we do two dumb things.
The first is manually checking for organ failure each iteration.
We do this because we allow organ damage to be modified outside of the
applyOrganDamage proc, which also calls check_failing_thresholds.
There's no reason to do this, so I've gone through and removed all
instances of it
The second is calling applyOrganDamage no matter what, to "heal" the
organ. Even if it isn't damaged.
The fix for this is simple, just an if check.
This saves roughly 10% of pre changes Life() cost
* Blood cleanup beta version
Blood code is slightly more sane, but it calls get_part_bleed_rate a
lot, and does other checks that are the same so long as the bleed rate
never changes. This is reasonably expensive
So, I'm going to make it event driven, and cache the bleed rate. But to
do that, I need to be able to react to limb ownership changes, and well,
there's a few that don't use the existing setter. This commit fixes that
* Blood cleanup beta 2.0
I'm starting on the work to make bleed rate cached
Adds NO_BLEED to the signal registration of set_owner
This lets us generically react to it
Makes changing your bleedstacks into a proc we can hook into
Fully implements it
* Blood optimization beta 3.0
Hooks into embedding/embed details updating, this ensures the embed
aspect of bleed rate is properly accounted for
* Blood optimization beta 4.0
Hooks wounds into refresh_bleed_rate, adds a setter for blood flow to
support this
I feel like there are places where this would be useful, but I'm not
totally sure
Kinda wanted to ask ryll
* Blood optimization, the final countdown
Fully caches bleed_rate. Because I can do this, we only need to call update_part_wound_overlay when bleed rate updates
This saves 15%! of human life tick. Get owned
* Optimizes body_temperature_alerts
It turns out that clearing alerts and sending signals every process is
wasteful. There's no reason to do it unless last process was a problem
one
The change for that is quite easy, literally just a new var on human.
Saves 2% of human life tick.
Very nice for the amount of time I put into it
BTW, I have a feeling that most of the overhead of bodytemp is caused by
human body temperature being higher then room temperature. Not sure
what to do about this though
* Does something similar to disgust
Basically, don't continusly send signals if you have no disgust
It's rare enough that this is all the caching we really need to do
Saves roughly 1% of life tick. Right on the edge of not worth it
* Some cleanup to how mob fires handle their lighting, adds a check to liver coder
* Cleans up update_gravity slightly
It's very close to outside a measurable deviation faster, but I honestly
just did it to make it easier to read
* Fuck you
* Very minor organ optimization
Instead of using internal_organs_slot for our organ iteration,
we use it to produce a sorted internal_organs list.
This is barely worth it, ends up being 0.7% of life saved.
I only did it because it makes a semi noticable impact on our current
numbers.
* Revert "Very minor organ optimization"
It turns out mutating internal_organs is important sometimes
The usefulness of this change is small enough that I don't want to spend
more time on it
So back it goes into the dirt
This reverts commit 622bd34adb8d8a3d5f2763ac659446ef3362e3cd.
* Properly returns false in IgniteMob
* Adds a parent call to setBleedStacks
I like it, it's a good idea
