* Optimization pass focused on foam code (saves about 30% of cpu usage I think) (#76104)
## About The Pull Request
Foam is crummy at high load rn, both because it runs on a low priority
background subsystem, and because it wastes a bit of time.
Let's reduce usage (while speeding up a bunch of other stuff too), and
give it more cpu generally.
[Optimizes reagent processing
somewhat](d409bd4afc)
Turns out most of the cost of foam is the reagents it carries, and the
varying effects they have
I'm doing my best here to optimize them without touching "user space"
too much
That means doing things like prechecking if we're gonna spawn on top of
an existing decal (from glitter, flour, etc), and using that same proc
to also avoid spawning on unacceptable turfs (I had to convert
inheritance to a bitflag system to make this work, but I think that's ok
since we want it imparative anyhow)
It's actually nice for code quality too, since it lets me clean up code
that was using raw locates and weird var pong.
god I wish I had implied types man
[Optimizes foam spreading in its most accursed aspect, reagent
copying](5cc56a64ad)
Holy shit reagent code is a lot.
I'm doing a bunch of small things here. istype in init -> typecache,
removing procs that are called once and loop over a list we JUST looped
over (ph and the caching for reactions in particular)
I am mainly trying to optimize copy_to here, since that's what foam
spams
As a part of this, I removed a pair of update_total and handle_reactions
calls that were done on the reagents we are copying FROM
I have no god damn idea why you would want to do that, but if anything
is relying on the copy proc modifying the source, then that code
deserves to break
Speaking of, I cleaned up handle_reaction's main filter loop a lot,
removed a lot of redundant vars and changed it from a full loop w
tracker vars to an early exit pattern
This meant using a loop label, which is unfortunate, but this is the
fastest method, and it does end up cleaning up the code significantly,
Which is nice
Oh also I made the required_other var function even if there is no atom
attached to the reaction, since I don't see why it wouldn't
This last bit is gonna get a bit esoteric so bear with me
Failing calls (which are most of them) to handle_reactions are going to
be fastest if they need to check as few reactions as possible
One reagent in a reaction's required list is marked as the "primary",
and thus gets to trigger checking it.
We need all the reagents to react anyhow, so we might as well only check
if we have one particular one to avoid double checking
Anyhow, in order to make most calls the fastest, we want these reactions
distributed as evenly as possible across all our reagents.
The current way of doing this is just taking the first reagent in the
requirements list and using it, which is not ideal
Instead of that, lets figure out how many reactions each reagent is in,
then divy reactions up based off that and the currently divvied
reactions
This doubles the reagent index count, and takes the most common reagent,
water, from 67 reactions to I think like 22
Does some other general cleaning in reagent code too, etc etc etc
[Fixes runtimes from the forced gravity element being applied more then
once](941d067611)
I feel like this element should take a trait source or something to make
them potentially unique, it's too easy to accidentally override one with
another
[Removes connect_loc usage in atmos_sensitive, replaces it with direct
reg/unreg](de1c76029d)
I only really used it because I liked the componentization, but it costs
like 0.2 seconds off init alone which is really stupid, so let's just do
this the very slightly harder way
[Micros foam code slightly by inlining a LinkBlockedWithAccess
call](744da3694c)
This is in the space of like 0.05 seconds kinda save so I can put it
back if you'd like, the double loop just felt silly
[Changes how foam processes
slightly](ee5e633e32)
Rather then treating spreading and processing as separate actions, we do
both in sync.
This makes foam fade faster when spreading, which is good cause the
whole spread but unclearing foam thing looks silly.
It also avoids the potential bad ending of foam spreading into itself,
backwards and forwards. This is better I promise.
[Bumps fluid priority closer to heavy eaters, moves it off
background](811797f09d)
Also fixes a bug where foam would travel under public access airlocks.
## Why It's Good For The Game
Saves a lot of cpu just in general, from both init and live.
In theory makes foam faster, tho I'd have to test that on live at
highpop to see if I've actually succeeded or not. Guess we'll see.
* Optimization pass focused on foam code (saves about 30% of cpu usage I think)
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Bloop <vinylspiders@gmail.com>
* Macros multi-z code, removes the false premise of manual offsets (#76248)
## About The Pull Request
[Removes the pretense of relative multiz
levels](0293fdc2bd)
Our multiz system does not support having a z level that is only
connected one way, or which goes down backwards or anything like that.
That's a fiction of the trait system, the actual backend has never
really supported this.
This pr removes the assumptions we were making backend around this, and
uses that to save cpu time.
I am also converting multiz_levels from an assoc list to a pure one,
which saves significantly on access times and cleans up the code
somewhat.
Also I'm making the get_below/get_above procs into macros, for the sake
of cpu time.
[Converts the starlight disease to use BYOND's directional defines
instead of our
own](7d698f02d9)
To some extent spurred on by
https://github.com/DaedalusDock/daedalusdock/pull/298, tho it was known
before
## Why It's Good For The Game
Faster multiz code, faster init, etc etc etc
* modular files how very dare you
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Fixes silly siding sprites (#76586)
## About The Pull Request
Detaches siding code from the macro in #74171 because it wasn't doing
its job properly. I tried to fix it, but I'm not a very good coder and
opted to manually define each of the variations of siding. So this is
more of a bandaid fix than anything.
## Why It's Good For The Game
Fixes#76195, fixes#75059
Correct turf decals look better than wrong ones
look at how much nicer this corner looks now
## Changelog
🆑
image: Siding now uses the correct sprite on corners and endpieces.
/🆑
* Fixes modular icon states
---------
Co-authored-by: norsvenska <73006946+norsvenska@users.noreply.github.com>
* Icon folder cleaning wave one
* Fixe a merge conflict
* Fixes some more merge conflicts
* Fixes some modular icon paths
* Fixes even more modular icon paths...
Hopefully that's the last of them
* Fixes some merge discrepencies
* More merge issues
* ok
* not ok
---------
Co-authored-by: YesterdaysPromise <122572637+YesterdaysPromise@users.noreply.github.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Makes decals only caught on mapload & removes turf_loc_check (#76130)
Theres one player-facing change in this PR and it's that I removed human
gibs from being valid in space turfs, making it more consistent with the
other gib decals.
I've cleaned up many instances of decals spawning in bad turfs on
mapload in https://github.com/tgstation/tgstation/pull/75189, but making
it error anytime in-game a decal is put over an invalid turf is bad as
it punishes contributors for not optimizing their decals properly.
This changes it so it only errors if it's on mapload, unit testing or
not.
I've also removed ``turf_loc_check`` and replaced instances of it with
overwriting ``NeverShouldHaveComeHere``, which gives us greater control
of where decals can be placed.
This let me remove 2 subtypes that were made to have decals in specific
places (which then got placed elsewhere, ruining it all).
Mappers are still able to set decals to be placed anywhere, they just
need to add it as a valid turf for that decal.
* Makes decals only caught on mapload & removes turf_loc_check
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Proper broken tiles (#75623)
## About The Pull Request
The current broken tiles have some visual issues:
- There is an ambient occlusion shade when it touches normal tile
- It has a layer higher than it should be which leads to things that are
normally above the floor layer, render below it. Such as atmos
machinery, cleanable overlays, etc.
This PR makes the render on a proper layer and work like a partially
destroyed floor tile that can be reclaimed with crowbar.
Also, the cleanables are now on FLOOR_CLEAN_LAYER to make dirt appear
above catwalks and these new tiles.
And the flat dirt now has 4 variants of sprites, while dust uses the old
dirt sprite. It seems like dust was just dirt with different description
before.
## Why It's Good For The Game
A broken tiling with no visual bugs and proper floor-like logic.
## Changelog
🆑 MTandi, Borbop
fix: Dust now has dust icon, instead of dirt icon. Dust on all maps
replaced with dirt
image: Flat dirt now picks from 4 new sprites
refactor: Made broken tiling work more like tiling and have
corresponding visuals. Added directional mapping variants.
fix: Cleanables now use FLOOR_CLEAN_LAYER to make sure that trash is
visible above catwalks
/🆑
* Proper broken tiles
* Update north_star.dmm
* Update north_star.dmm
---------
Co-authored-by: Andrew <mt.forspam@gmail.com>
Co-authored-by: Jolly-66 <70232195+Jolly-66@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Fixes moveloop shit (#75675)
## About The Pull Request
I was using the step_x procs when I should have been using get_step_x
and Move()
This was causing some mob behavior to not properly respect things like
gravity or potentially entered/exited signals.
Also ensures we pass direction into Move consistently, and deletes a
function that was meant to like, use step_to but with directions? Was
never actually used properly
I forgot to properly respect the "don't change dir" flag
Closes#75673🆑
fix: Mobs will fly around space... less
/🆑
* Fixes moveloop shit
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Massive Spraycan and Crayon Powercreep: smaller graffiti cost less to draw. (#75588)
## About The Pull Request
Currently, drawing a small circle on the floor consumes as much charge
as any other drawable but the larger horizontal ones that cost five
times as much, which is a bit dull for non-cyborg players, having to
burn through a ton of spraycans just to cover the floor in several small
dots if ever attempting to do some floor art.
This PR aims to reduce the cost of some of the smaller drawables, like
"shortline", "smallbrush", "pawprints" etc., in virtue of the smaller
area they cover. The balances changes may seem bit of an arbitrary and
not include ones that are a bit on the edge between "small" and not
"small", but I'd rather keep it simple than have other values such like
"semi-small" integrated and snowball this balance PR into a more
finnicky, disputable or not agreeable with version of itself.
This also covers re-coloring and existent graffiti. Currently it always
costs 2 charges to change its color regardless if it costed 1 or 5 to
spray in the first place. With this PR, the costs should match that of
when they were drawn. To boot, It also takes into account the tagger
quirk now.
Code had to be cleaned up and improved a bit for a smoother
implementation of these changes.
A fairly unrelated but small change: Trying to suicide with an empty
spraycan will now fail, because it's empty. It's that simple.
## Why It's Good For The Game
Enables non-cyborg players to engage in jolly floor-vandalizing-art in a
more consistent, slightly more enjoyable way.
## Changelog
🆑
balance: Drawing small graffiti like paw/foot/claw prints, small brush
dots and short lines should cost half as many charges off your spraycan
or crayon.
balance: The cost of recoloring graffiti decals is now consistent with
that of drawing them.
balance: Trying to suicide with an empty spraycan will now fail, because
it's empty. It's just that simple.
/🆑
* Massive Spraycan and Crayon Powercreep: smaller graffiti cost less to draw.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Audio File Cleanup (#74863)
## About The Pull Request
Removes a bunch of sound files that we don't use and moves some sound
files into better locations. I'm hoping to get an archive repo for
sounds going, much like the
[map_depot](https://github.com/tgstation/map_depot) and
[SS13-sprites](https://github.com/tgstation/SS13-sprites).
EDIT: The old sound files are being moved here:
https://github.com/tgstation/SS13-sounds
Also increased the volume of the clownana rustle sound and clipped off
some dead air from shockwave_explosion
## Why It's Good For The Game
Removes a total of 1.95MB worth of unused sound files from the codebase.
## Changelog
🆑 Tattle
soundadd: increased the volume of the clownana rustle
/🆑
---------
Co-authored-by: tattle <article.disaster@ gmail.com>
* Audio File Cleanup
* Fixes the missing sound files ;)
---------
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: tattle <article.disaster@ gmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Fixes decals not layering as expected in world (#74232)
## About The Pull Request
They just... were not passing their layer into the element. Stupeeed
Rearranges some layers to ensure things work as they do now
## Why It's Good For The Game
Closes#74165
Should fix weird decal layering. If it doesn't yell at me.
## Changelog
🆑
fix: Fixes decals layering weird in some cases
/🆑
* Fixes decals not layering as expected in world
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Macro Helper For Re-Used Turf_Decal Patterns (#74171)
oh that's sexy
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
Hey there, blast from the past PR format. Can you spot the issue here?
Well, I did while working on #74169, and it pissed me off. This is a
really simple pattern, and the only reason why it's just copypasted (and
prone to such errors) is because no one took the time to do it properly
like this. So, I just decided to do it while I had time today. Very
nice.
I also removed all the names because there was no point in them: in all
contexts you would be operating off the typepath, the name would never
come up. like so:
memory save? it's just un-needed anyways
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
Silly error proofing is nice! Way easier to add new colors! No need to
ctrl+c/ctrl+v everything to death anymore! whoopie
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
Nothing that players should fret about.
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
* Macro Helper For Re-Used Turf_Decal Patterns
---------
Co-authored-by: san7890 <the@san7890.com>
* Adds the Smoking Room icebox surface ruin (#73876)
## About The Pull Request
My contribution to the March Into Mapping/Mapness event -- The forlorn
homestead of mister Charles Morlbaro, a high-brow individual with a
taste for cigarettes. This ruin spawns on the surface level of Icebox.
A local of the ice planet, Morlbaro lived a peaceful life at home, until
an _incident_ compromised one of his windows. Fearing the cold and
unable to keep anything larger than a cigarette lit, he sequestered
himself in his private smoking room, and hasn't been seen since.
...
Oh, right, the loot. That's the most important part for some of you
guys.
Where there's smoke, there's fire, and where there's cigarettes, there's
lighters. Mister Morlbaro collected novelty lighters, which have to be
worth something to someone, right? You might be able to find some if you
dig around in his belongings. Just try not to disturb him if you choose
to enter his smoking room.
### Mapping March
<!-- If your pull request is part of Mapping March and you want to earn
an antagonist token for your FIRST mapping pull request submitted this
month, please include your ckey. For more information, read about the
event here: https://hackmd.io/@ EOBGames/BkwuRlxkh -->
Ckey to recieve rewards: theduffelbag
## Why It's Good For The Game
Ruin variety is nice. This one doesn't have any particularly spectacular
loot, but it's a surface ruin.
Bro space ruins are sooooo 2020 bro, it's all about icebox ruins now
bro.
## Changelog
🆑 Rhials
add: Adds the Smoking Room icebox ruin, found on the station level!
/🆑
* Adds the Smoking Room icebox surface ruin
---------
Co-authored-by: Rhials <Datguy33456@gmail.com>
* Adds Pinatas that can be purchased by cargo and clown operatives! (#73868)
## About The Pull Request
Pinata's drop various items when struck with a sufficiently powerful
weapon. This PR adds two types, a standard one which can be bought from
cargo which contains various candy items and a syndicate one which
contains both candy items and explosives purchasable by clown
operatives.
The pinata functionality is also a component so admins can turn any
structure/machine/mob into a pinata and customize the "candy" inside
Sprites by @ Mey-Ha-Zah animated versions by me
## Why It's Good For The Game
Adds a cute little celebration themed structure that can be bought by
players to accommodate a celebration based gimmicks or the party trait.
I think the options on things to do as a crew during a celebration are a
bit limited at present with most of the options being making/purchasing
food, activity wise the main example of a celebration item is pin the
tail on the corgi which is a bit uninteresting, the pinata on the other
hand is more cathartic and provides a "reward" in the form of various
candy items for people who participate in smashing it. I also think its
just funny to have clown operative gambling half their TC to try and get
explosives.
## Changelog
🆑 Mey-Ha-Zah & NamelessFairy
add: Added pinata crates to cargo, they contain various candy items. Fun
at parties.
add: Clown operatives can now purchase a weapons grade pinata, this
contains both candy and explosives. Still fun at parties.
admin: Admins can now turn players, mobs and objects into pinata's with
the new pinata component.
/🆑
* Adds Pinatas that can be purchased by cargo and clown operatives!
---------
Co-authored-by: NamelessFairy <40036527+NamelessFairy@users.noreply.github.com>
* Makes some improvements to how AI can use JPS with movement loops (#72685)
## About The Pull Request
This PR makes some changes to how JPS is used in movement loops, as it
was causing a variety of issues:
- Fixed some code where JPS would fail because the path is still being
made. Instead, the movement loop will now wait.
- Reduced the subsystem wait for the pathfinder subsystem from 2 seconds
to 0.1 seconds. @ LemonInTheDark told me that this is better, I'll update
this with a better explanation once I squeeze it out of him :D
- Allows you to provide an initial path to the movement loop, in case
you pre-calculated one while making a plan.
## Why It's Good For The Game
Makes working with JPS a bit easier when making AI.
---------
Co-authored-by: Capybara <Capybara@ CapybaraMailingServices.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@ users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@ users.noreply.github.com>
* Makes some improvements to how AI can use JPS with movement loops
---------
Co-authored-by: CapybaraExtravagante <110635252+CapybaraExtravagante@users.noreply.github.com>
Co-authored-by: Capybara <Capybara@ CapybaraMailingServices.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@ users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@ users.noreply.github.com>
* Adds nutriment factor to liquid gibs. (#73033)
## About The Pull Request
Over the years I've heard quite a few lizard players scratch their heads
in confusion due to the lack of gibs filling you up. I gave it a fairly
low value of 2 so people don't end up trying to power game it.
## Why It's Good For The Game
Adding an alternative use to gibs is always nice, at the moment it's
mostly just used for soap and cytology (Which barely anyone does.)
## Changelog
🆑
balance: Gibs now provide a small amount of nutriment.
/🆑
* Fixes the modular uses of liquid gibs
* Fixes an error that somehow slipped through.
---------
Co-authored-by: carshalash <carshalash@gmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Smoothing groups optimization, save 265ms with configs, more on production & w/ space ruins (#71989)
This one is fun.
On every /turf/Initialize and /atom/Initialize, we try to set
`smoothing_groups` and `canSmoothWith` to a cached list of bitfields. At
the type level, these are specified as lists of IDs, which are then
`Join`ed in Initialize, and retrieved from the cache (or built from
there).
The problem is that the cache only misses about 60 times, but the cache
hits more than a hundred thousand times. This means we eat the cost of
`Join` (which is very very slow, because strings + BYOND), as well as
the preliminary `length` checks, for every single atom.
Furthermore, as you might remember, if you have any list variable set on
a type, it'll create a hidden `(init)` proc to create the list. On
turfs, that costs us about 60ms.
This PR does a cool trick where we can completely eliminate the `Join`
*and* the lists at the cost of a little more work when building the
cache.
The trick is that we replace the current type definitions with this:
```patch
- smoothing_groups = list(SMOOTH_GROUP_TURF_OPEN, SMOOTH_GROUP_FLOOR_ASH)
- canSmoothWith = list(SMOOTH_GROUP_FLOOR_ASH, SMOOTH_GROUP_CLOSED_TURFS)
+ smoothing_groups = SMOOTH_GROUP_TURF_OPEN + SMOOTH_GROUP_FLOOR_ASH
+ canSmoothWith = SMOOTH_GROUP_FLOOR_ASH + SMOOTH_GROUP_CLOSED_TURFS
```
These defines, instead of being numbers, are now segments of a string,
delimited by commas.
For instance, if ASH used to be 13, and CLOSED_TURFS used to be 37, this
used to equal `list(13, 37)`. Now, it equals `"13,37,"`.
Then, when the cache misses, we take that string, and treat it as part
of a JSON list, and decode it from there. Meaning:
```java
// Starting value
"13,37,"
// We have a trailing comma, so add a dummy value
"13,37,0"
// Make it an array
"[13,37,0]"
// Decode
list(13, 37, 0)
// Chop off the dummy value
list(13, 37) // Done!
```
This on its own eliminates 265ms *without space ruins*, with the
combined savings of turf/Initialize, atom/Initialize, and the hidden
(init) procs that no longer exist.
Furthermore, there's some other fun stuff we gain from this approach
emergently.
We previously had a difference between `S_TURF` and `S_OBJ`. The idea is
that if you have any smoothing groups with `S_OBJ`, then you will gain
the `SMOOTH_OBJ` bitflag (though note to self, I need to check that the
cost of adding this is actually worth it). This is achieved by the fact
that `S_OBJ` simply takes the last turf, and adds onto that, meaning
that if the biggest value in the sorting groups is greater than that,
then we know we're going to be smoothing to objects.
This new method provides a limitation here. BYOND has no way of
converting a number to a string at compile time, meaning that we can't
evaluate `MAX_S_TURF + offset` into a string. Instead, in order to
preserve the nice UX, `S_OBJ` now instead opts to make the numbers
negative. This means that what used to be something like:
```dm
smoothing_groups = list(SMOOTH_GROUP_ALIEN_RESIN, SMOOTH_GROUP_ALIEN_WEEDS)
```
...which may have been represented as
```dm
smoothing_groups = list(15, MAX_S_TURF + 3)
```
...will now become, at compile time:
```dm
smoothing_groups = "15,-3,"
```
Except! Because we guarantee smoothing groups are sorted through unit
testing, this is actually going to look like:
```dm
smoothing_groups = "-3,15,"
```
Meaning that we can now check if we're smoothing with objects just by
checking if `smoothing_groups[1] == "-"`, as that's the only way that is
possible. Neat!
Furthermore, though much simpler, what used to be `if
(length(smoothing_groups))` (and canSmoothWith) on every single
atom/Initialize and turf/Initialize can now be `if (smoothing_groups)`,
since empty strings are falsy. `length` is about 15% slower than doing
nothing, so in procs as hot as this, this gives some nice gains just on
its own.
For developers, very little changes. Instead of using `list`, you now
use `+`. The order might change, as `S_OBJ` now needs to come first, but
unit tests will catch you if you mess up. Also, you will notice that all
`S_OBJ` have been increased by one. This is because we used to have
`S_TURF(0)` and `S_OBJ(0)`, but with this new trick, -0 == 0, and so
they conflicted and needed to be changed.
* Sorting how did I miss it
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: Funce <funce.973@gmail.com>
* Replace moveToNullspace in decal Destroy() to loc = null -- Saves 0.11s of init time (#71706)
This calls Exited(), Entered(), etc etc etc etc, and it is not necessary
for this. Was 119ms, now 9.
* Replace moveToNullspace in decal Destroy() to loc = null -- Saves 0.11s of init time
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Changes our map_format to SIDE_MAP (#70162)
## About The Pull Request
This does nothing currently, but will allow me to test for layering
issues on LIVE, rather then in just wallening.
Oh also I'm packaging in a fix to one of my macros that I wrote wrong,
as a joke
[removes SEE_BLACKNESS usage, because we actually cannot use it
effectively](c9a19dd7cc)
[c9a19dd](c9a19dd7cc)
Sidemap removes the ability to control it on a plane, so it basically
just means there's an uncontrollable black slate even if you have other
toggles set.
This just like, removes that, since it's silly
[fixes weird layering on solars and ai portraits. Pixel y was casuing
things to render below who
shouldn't](3885b9d9ed)
[3885b9d](3885b9d9ed)
[Fixes flicker
issues](2defc0ad20)
[2defc0a](2defc0ad20)
Offsetting the vis_contents'd objects down physically, and then up
visually resolves the confliciting that was going on between the text
and its display.
This resolves the existing reported flickering issues
[fixes plated food not appearing in
world](28a34c64f8)
[28a34c6](28a34c64f8)
pixel_y'd vis_contents strikes again. It's a tad hacky but we'll just
use pixel_z for this
[Adds wall and upper wall plane
masters](89fe2b4eb4)
[89fe2b4](89fe2b4eb4)
We use these + the floor and space planes to build a mask of all the
visible turfs.
Then we take that, stick it in a plane master, and mask the emissive
plane with it.
This solves the lighting fulldark screen object getting cut by emissives
Shifts some planes around to match this new layering. Also ensures we
only shift fullscreen objects if they don't object to it.
[compresses plane master
controllers](bd64cc196a)
[bd64cc1](bd64cc196a)
we don't use them for much rn, but we might in future so I'm keeping it
as a convienince thing
🆑
refactor: The logic of how we well, render things has changed. Make an
issue report if anything looks funky, particularly layers. PLEASE USE
YOUR EYES
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Changes our map_format to SIDE_MAP
* Modular!
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
Co-authored-by: Funce <funce.973@gmail.com>
* Reinforced plating for all your Multi-Z mapping needs (#71576)
## About The Pull Request
This PR adds reinforced plating and a corresponding baseturf_helper,
plating that cannot be deconstructed with the RCD and requires a few
steps to degrade to regular plating.
The plating is designed to serve the same purpose as R-Walls but for
verticality. It shares its heat resistance with reinforced floor and
hull, and in texting it can endure a single C4 blast but not X4 assuming
the floor placed on it is already removed.
It is currently is unused on the existing maps due to it being poor
practice to place secure locations that would justify reinforced floors
on the lower Z levels, however I have spoken to people working on maps
actively at the moment and they have express interest in being able to
use these floors.
The plating can be constructed by using 2 sheets of plasteel on standard
plating and is disassembled using wrench > welding tool > crowbar. The
first stage of deconstruction causes the bolts holding the
reinforcements in place to fall to the Z level below playing a sound and
leaving a cleanable decal, adding a audio-visual alert that someone is
about to come through your ceiling.
UPDATE: I've added a ceiling variant of the baseturf editor, this can be
placed on a lower Z level where it will modify the baseturfs of the Z
level above within the original area. This will make it significantly
easier to ensure that you only cover tiles you want reinforced when
protecting lower Z levels.
If anyone has any recommendations for sounds please tell me and I might
swap them out but I think the two I've chosen work well. Additionally if
anyone is able to make a better sprite for the screws or plates then
that'd be a great help but I think the current ones work well enough.
## Why It's Good For The Game
Currently Multi-Z maps have a very tight restriction on where secure
areas can be put, only allowing for them to be placed on the top Z
level, under more secure Z levels or in exterior satellites and coated
with hulls. This is due to standard plating and/or reinforced floors are
very easy to get through without warning if you bring the right tools.
This PR effectively adds R-Walls but for floors allowing mappers to
properly protect lower Z levels from vertical infiltration methods. This
also adds a visual and audible indictor to the deconstruction of
reinforced floor tiles to bring them more in line with the visuals of
deconstructing a wall.
## Changelog
🆑
add: You can now reinforce plating to protect your department from the
troublemakers upstairs. Station builders might find these useful to put
the stations most secure locations on the lower floors.
imageadd: added sprites for reinforced plating
code: RCD proofing has been variablized and can now be applied to any
floor type instead of just reinforced floors.
/🆑
* Reinforced plating for all your Multi-Z mapping needs
Co-authored-by: NamelessFairy <40036527+NamelessFairy@users.noreply.github.com>
* Adds coordinates to the chess and checkers holodeck modules (#70866)
## About The Pull Request
This PR aims to add coordinates on both edges of the preset chess and
checkers (sure, why not) templates used in the holodeck feature: top row
and right column on the inner border of the board; the bottom and left,
just outside it.
## Why It's Good For The Game
This ought to help the player take advantage of the algebraic notation
if they wish to. It also adds, like, an itsy bitsy of decor to both
modules (alas, the checkers module still uses mapedited carboard cutouts
which partially cover some of the letters and numbers, but changing them
is outside the scope of this PR).
## Changelog
🆑
add: Added two sets of coordinates to the checkers and chess modules for
the holodeck.
/🆑
* Adds coordinates to the chess and checkers holodeck modules
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Fix Flypeople food consumption (#71432)
## About The Pull Request
This PR fixes#70716 by having flypeople ingest vomited reagents into
their stomach instead of directly modifying nutrition. To accomplish
this, flypeople no longer vomit their entire stomach contents every life
tick, which also fixes them vomiting immediately on spawn. Instead they
vomit only after taking bites of food.
Since flypeople aren't currently metabolizing food the same way as other
species there's a huge discrepancy in nutrition gained from food. For
example, a human gets 37 nutrition from a slice of pizza and 270
nutrition from a whole margherita pizza, but a flyperson only gets 10
and 70 respectively, meaning they'd need to eat 4 entire margherita
pizzas and slurp up the vomit to go from total starvation to being
satiated again. With this change flypeople get ~190 nutrition from a
whole margherita pizza.
## Why It's Good For The Game
Makes it easier for flypeople to stay satiated without having to consume
mass amounts of food. Also makes it easier and more predictable to deal
with flyperson interactions with other reagents getting in their stomach
- for example, currently taking a happy pill causes flypeople to vomit
due to the sugar.
## Changelog
🆑
fix: Flypeople gain a comparable amount of nutrients from vomited food
to other species (~70%, up from ~30%)
fix: Flypeople no longer vomit after drinking fluids
fix: Flypeople no longer vomit all contents of their stomach on spawn
code: Stomachs can now react to foods entering them by overriding the
`after_eat` proc
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Fix Flypeople food consumption
Co-authored-by: Roryl-c <5150427+Roryl-c@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Fixes runtime with the infective component on gibs (#70706)
* Fixes runtime with the infective component. streak_diseases is a lazylist and is sometimes not instantiated.
* Lazynull
* Fixes runtime with the infective component on gibs
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Fixes oil igniting (#70594)
About The Pull Request
Fixes#70592
Why It's Good For The Game
The correct message is displayed when you ignite a patch of oil.
* Fixes oil igniting
Co-authored-by: RaveRadbury <3204033+RaveRadbury@users.noreply.github.com>
* fixes ant runtime (#69890)
* Checks for caltrop component's existence before seeing what it does.
* fixes ant runtime
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* Save 2.2s minimum (with zero ruins, likely a good bit more in production) of atom init time (#69564)
Pre-sort smoothing_groups and canSmoothWith
Without any ruins, these sorts were taking more than 0.6s, and the bulk of the runtime cost of sortTim during init time.
This only happens on init and they are never changed apart from that, so pre-sorts everything and adds a unit test (in the form of #ifdef UNIT_TESTS, because you can't initial a list) to ensure that they are proper.
Keep visibilityChanged() to mapload only for turf/Initialize
Saves about 0.4s worst case scenario (e.g. with no ruins). Very expensive code (175k loop iterations) for 0 side effects.
Space areas now have the fullbright overlay, not the space turfs
Saves about 0.8s worst case scenario. Seems to work fine with starlight.
Remove is_station_level check for window spawners assigning RCD memory.
Saves about 0.3s worst case scenario. The logic for this isn't consistent since neither walls nor floors check this (for performance), plus some minor micro-opts to spawners.
Optimize is_station_level
Doubles in speed, used heavily in /turf/open/floor and in other initialization procs. Bit hard to tell exactly how much is saved, though.
* Save 2.2s minimum (with zero ruins, likely a good bit more in production) of atom init time
* Hopefully fixes the broken CI
* Okay now it shouldn't be failing CI anymore (hopefully)
* Fixes even more issues with smoothing_groups, this time hopefully for good
* Okay NOW it's going to pass CI, surely...
* Okay haha what if it passes this time? :)
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Adds fire ants (#69365)
cl ShizCalev
add: Space ants will now turn into space fire ants when burned with fire.
/cl
* Adds fire ants
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* Tilening V2 Part 2: KrysonWood Edition (#69088)
About The Pull Request
Hey there! Didn't expect me to be back so soon? Well, that's because I had yet another project on the backburner: A Sequel to Tilening V2!
Where we last left off, we redid a huge majority of the sprites related to iron floors, but another big culprit was left untouched: Wood Floors!
So, what did I do? I asked @ Krysonism for the wood tiles they've used for a majority of their Wallening mockups, and finalized their work! Behold:
image
image
image
image
As a result, I felt that as I was touching up those wood sprites, I should've addressed a few more tiles while on the way, which is when I decided upon retouching the titanium and plastitanium tiles as well!
image
image
image
image
image
Decals related to these two tile types were also changed!
Here's some highlights of it during a few test screenshots on localhost!
This PR also changes the appearance of plating, making it smoother as some people complained about the waffle pattern and I agree, it was excessive!
image
Finally, this PR very minorly adjusts a few tiles, such as the black and white tiles, diagonal, black and grey tiles, etc, as well as removing unused damaged icons, and replacing them with the better ones we have. Said unused/old icons will be dumped onto the spriting depot.
Why It's Good For The Game
A continuation of my work, as well as being the intended vision Kryson desired for the upcoming wallening project! There's still a lot to go, but its a good step in the right direction of visual progress!
Changelog
cl PositiveEntropy, Kryson
del: Removes old and unused titanium, plastitanium and plating damaged states.
imageadd: Resprites the wooden, titanium and plastitanium-related floors!
imageadd: Decals related to the resprited tiles have been adjusted accordingly.
imageadd: Updates the appearance of plating to be smoother!
/cl
* Tilening V2 Part 2: KrysonWood Edition
* Tilening V2 Part 2: KrysonWood Edition
Co-authored-by: Imaginos16 <77556824+Imaginos16@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
* Removes ComponentInitialize()
* Fixes a leftover merge conflict marker
* Fixes the oversight that came from the upstream merge skew
* Fixes all of the instances where we used ComponentInitialize() when we shouldn't've been
* Fixes CI being broken because of the HEV suits
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Pointing at something on yourself now shows the item (#68642)
Why It's Good For The Game
Further reducing reliance on reading the chat box. Previously it wasn't obvious someone pointing at themselves was pointing at something on them, and not just, them.
Changelog
cl
qol: Pointing at something on yourself now shows the item.
/cl
* Pointing at something on yourself now shows the item
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
