## About The Pull Request
In some cases, you need to perform behaviors that can occur ontop of
different behaviors. E.g. "I need to continiously spit out foam while
moving to a point". If these behaviors are put separetely, it is
difficult to determine that the behavior for spitting out foam needs to
end. And in the current code, aslong as it has not ended, the plan will
never end. So once the AI reaches the point it would stand still at the
end and spit out foam unendingly.
To work around this I've made it so behaviors can be set to allow
planning while they run if they have the
AI_BEHAVIOR_CAN_PLAN_DURING_EXECUTION flag. If all remaining behaviors
on a controller have this flag, a new plan is made. If this plan is the
exact same as the plan that was currently being performed, nothing
happens. But if the plan is different, the current one is ended and the
new plan is executed. This means situations like this are handled
gracefully now. This will be required for basic bots.
## Why It's Good For The Game
More graceful handling of "continous" behaviors! :)
## Changelog
🆑 Capybara Holly
refactor: Allows datum AI to create new plans while a plan is still
executing
/🆑
Co-authored-by: Capybara <Capybara@CapybaraMailingServices.com>
## About The Pull Request
This is a dumb idea, and leads to fucked rendering on occasion
## Why It's Good For The Game
Fixes another portion of #70258, a player will no longer have a hidden
antag hud if they move down a z level after getting an antag. We were
trying to offset the floating plane of their image, and it went to shit.
Also fixes a bug with observers not having antag huds for the combo hud
to see. We were only giving them one on mind.on_transfer, rather then on
mind assignment. I hate mindcode
## About The Pull Request
It's kinda hacky, but it is nearly the same as just rendering one z
layer.
We allow people to ENTIRELY REMOVE most plane masters from their screen.
This has the side effect of disabling most visual effects (AO is a big
one) which saves a LOT of gpu.
We rely on planes being essentially layers to ensure things render in
the proper order. (outside of some hackyness required to make parallax
work)
I've kept parallax and lighting enabled, so visuals will still look
better then multiz pre plane cube.
It does also mean that things like FOV don't work, but honestly they
didn't work PRE plane cube, and FOV's implementation makes me mad so I
have a hard time caring.
Reduces gpu usage on my machine on tram from 47% to 32%, just above the
27% I get on meta.
I'm happy with this.
Oh also turns out the parallaxing had almost no cost. Need to remove it
as a side effect of what I'm doing but if I could keep it I would.
There's still room for in between performance options, like disabling
things like AO on lower z layers, but I didn't expect it to make a huge
impact, so I left things as is
Also fixes a bug with paper bins not respecting z layer. It came up in
testing and annoyed me
## Why It's Good For The Game
Ensures we can make multiz maps without running into client performance
issues, allows users to customize performance and visual quality.
## Changelog
🆑
add: Adds a new rendering option to the gameplay preferences. You can
now limit the rendering intensity of multiz levels. This will make
things look a bit worse, but run a LOT better. Try it out if your
machine chokes on icebox or somethin.
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
So i left over some basic `/whatever/proc/format` uses in the original
PR this fixes it.
Notable exceptions to the rule:
- Paths in add_verb/remove_verb, we need full path instead of a name
there to access verb metadata so we can't use proc ref macros there.
- regex.Replace, found out that it does not accept call by name. Instead
i added new REGEX_REPLACE_HANDLER so we can at least try to mark these.
There's still leftover global procs that do not use GLOBAL_PROC_REF but
they functionally equivalent so that's for later.
I don't see any reasonable way to grep for this. But if you got any
ideas please share.
## About The Pull Request
Alright. So.
Right now, JPS works like this:
```
code requests path
we enter the actual pathfinding
pathfinding sleeps when it overruns a tick
if it sleeps, it'll then wake up before the mc starts
continue
```
This has annoying side effects. Primarily that we have no real control
over JPS, we just sorta have to eat its cost.
So if there's like 10 different things pathfinding at once, the mc will
have no time to do anything. Hell we might even end up eating into
maptick's time if the jps work is expensive enough (note the cost of
sleeping is not accounted for, and that has overhead)
This has happen before, usually when someone makes a lot of bots, and
it's really annoying.
So then, lets put JPS on a subsystem. That way the MC has control over
it.
But wait, existing code expects to yield and get back a path list, and
that's a sane request.
This is solvable, but requires abusing pass by reference lists, and the
ability to make callbacks into partials (preinsert arguments into them
before they're called, and accept other args later)
Because of this, we can now pass callbacks into pathfinders, allowing
for async use, rather then JUST yielding.
Of note: I've removed the 10 pathfinding datums limit, since
ratelimiting like that is handled nicely by the MC.
I've also removed the 15 second timeout, since mc yielding would trigger
it too often. I'm unsure if this means we don't have exit conditions for
pathfinding, need to talk to ryll. (@Ryll-Ryll what happens if jps just
like, fails to find a path?)
Also of note: I think bots will fire off more then one pathfinding
attempt at a time if their first takes too long to complete. This is
dumb, why do we do this?
Optimizes JPS by more then 40% by removing redundant for(thing in turf)
loops, and avoiding making proc calls if objects are non dense.
This makes things slightly more fragile, but saves a LOT of time. I
think it's worth it, tho talking to mso it might be possible to do
better. Maybe I should do a LINDA system style thing. (I did a linda
system style thing I fixed it)
Optimizes botscanning, fixes bots not seeing things adjacent to them
The list of types could be a cached typecache
We could inline both checkscan and check_bot
check_bot SHOULD NOT BE CALLED ON EVERY OBJECT IN VIEW HOLY SHIT WHY
We don't need to process adjacent and the shuffled view separately, it's
in fact easier to process them in one block
Renames a var
Moves bot's pathing images to above most floor objects, so they're
visible in maint
## Why It's Good For The Game
Speed. Also manuel will stop killing their server by placing 20000
medibots (fucking icebox man every time)
## Changelog
🆑
fix: Bots will now "notice" you if you're standing right next to them
fix: Bot paths will now draw above things like pipes, rather then below
them
refactor: Changed how pathfinding paths get generated
refactor: Made pathfinding and bot searching significantly faster
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
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
Hey there,
force_ending was a boolean (with inconsistent usage, flip-flopping
between using TRUE/FALSE and 1/0 variables), so let's just change it all
over to the macros and call it a good day.
I also updated documentation of the variables in that "code block" in
SSTicker while in the area because changing just one line made it look
ugly. Some of the documentation was no longer current to it's... current
use in code, so I updated those as well.
## Why It's Good For The Game
Pure code improvement, DMdocs are swell, and readability is kino.
## Changelog
Nothing here should affect players.
## About The Pull Request
I have been chipping away/procrastinating at this since May, but after
several years, I have finally updated how Trophy Cases work.
So, what this PR does is the following:
- Standardized everything in persistence.dm to use snake case, and added
basic autodocs
- Automatically moves trophies from data/npc_saves/TrophyItems.json to
data/trophy_items.json. Removed legacy .sav conversion by request, it
has been a long time.
- Trophy cases are opened and loaded the same way you would open a
regular ID locked display case (used curator access, relevant access
autodoc has been updated)
- Instead of cheap plastic replicas that turn to dust anyways, trophy
cases use holograms, which can be dispelled by hand
- Trophy data gets saved if an item stays in the trophy case when the
shuttle arrives to centcom, and the item has a description set. This is
in line with paintings, which has to still hang on the wall at round
end.
- You can edit the description of new trophies by using the librarian's
key to unlock History Mode
- When you click on a closed trophy case, it will open a tgui, and will
not display the case description. It will still do for open cases.
Vendatrays have been updated to do the same.
- The UI's icon uses icon2base64(getFlatIcon(showpiece, no_anim=TRUE)).
Vendatrays have been updated similarly, so items with directions and
animations are displayed properly. The base64 strings are updated in
update_static_data.
- Fixes vendatrays from displaying some characters in strange ways, such
as displaying /improper.
- Renames some one letter, or nonindicate argument and var names in
trophy case code
- Adds a trophy management admin panel, where admins can finally delete
all the curator ID cards swallowed over the years. Or, they can replace
the paths with funny new paths.
- If an entry has an incorrect, no longer existing path, it will be
marked red in the management panel
- Adds MAX_PLAQUE_LEN define, which 144 characters
- Removes start_showpieces from trophy cases, as it was completely
unused. The start_showpiece_type var is still around.
- Moves trophy_message var to trophy cases. Only a dice collector
display case used them in the Snowdin map.
What this PR does not do
- Sadly, it still only saves the base image of an item, and no layers or
altered image states. This has to come in the future.
<details>
<summary>Click here to see various states of the trophy tgUI</summary>
Locked history mode, existing item.
Unlocked history mode, but holographic trophy is present.
Locked history mode, no item.
Unlocked history mode, no item.
Unlocked history mode, item placed, default text. (Note: this picture is
out of date. The typo has been fixed, and "record a message" is now
"record a description" for consistency)
Unlocked history mode, item placed, new text.
</details>
<details>
<summary>Click here to see the admin panel</summary>
</details>
## Why It's Good For The Game
Less curator ID's stuck in the Trophy Cases, and the existing ones can
be cleaned up. A more immersive Trophy Case user experience, in general.
## Changelog
🆑
refactor: refactored trophy cases, to be more user friendly
admin: created a trophy managment admin panel
/🆑
## About The Pull Request
This is an expanding of
https://github.com/tgstation/tgstation/pull/69708
Adds a config to not connect machines to a techweb at the start of a
round
Adds the ability to multitool a server to get its techweb in its buffer,
which can then be used on machines to sync them.
Adds support for some machines to not cry when they don't have a techweb
linked to it, in case they actually don't.
If the config to not have machines connected to the science server is
enabled, research servers will make their own techwebs instead. This is
barebones though and would need more work if this option is used.
For misc stuff:
- I replaced checking ``GLOB.machines`` for research servers, to instead
check ``SSresearch.servers``, where we can use ``as anything``.
- Removed unused vars on the RD server control
- I renamed the operating computer's .dm file to remove the capitalized
letter from it. It's now operating_computer instead of Operations.
## Why It's Good For The Game
This is adding support for 2 different cases that can be used in the
future:
1. Off-station roles, we can make roles like Oldstation have their own
techweb so they don't ruin science's efforts, or use their advanced
research to get things we don't want, or even possibly have some
blacklist webs for ghost roles (like teleporters) so that way we don't
need to have this dance where we have to give them a very specific
amount of materials for them to do things while not being able to get a
teleporter and leaving. I heard discussions that people wanted this a
while back, and one of the main things preventing this from happening is
the lack of support. Hopefully this is encouragement to make it a
reality, because I think it would be a really cool expansion of ghost
roles and a good way to prevent them from messing with the round in
progress.
2. Downstreams who want to do different things with Science. Personally
I made this PR with voidcrew(shiptest) in mind and think this would make
their lives easier. I didn't expand too much on this because I'm leaving
up mostly to the downstreams to figure out what they want to do with
these systems.
## Changelog
This generally isn't really player facing, since most of the changes
would only come into effect if the config is enabled??
🆑
fix: Research servers now only show servers connected to their techweb.
/🆑
## About The Pull Request
Golems is apparently disabled on Icebox, but isn't disabled on Lavaland.
However, blacklisting ruins doesn't care for maps, and will blacklist
all, as if it were using all maps at once. This isn't a problem because
Lavaland and Icebox do not share common ruins, except for one: Golem
ship.
## Why It's Good For The Game
Config now works as it's supposed to, Golems should spawn on Lavaland
again (assuming it's enabled in config, I dont keep up to date with
that)
## Changelog
🆑
fix: Ruins blacklisted from icebox shouldn't also blacklist it from
lavaland, and vice versa.
/🆑
## About The Pull Request
SSmapping.anomaly_hard_limit_by_type was apparently missing the new
dimensional anomaly core
incredible innit?
Adds the dimensional anomaly core to the anomaly_hard_limit_by_type
## Why It's Good For The Game
Fixes#71147
## Changelog
🆑
fix: Raw dimensional cores can now be refined properly
/🆑
## About The Pull Request
A few roundend reports got lost from moving to dynamic and other prs.
This PRs re-allows them to occur. Namely: "Wizard Killed" (lost in
dynamic), "Blob nuked" (lost in dynamic), "Cult escaped" (lost in cult
rework), and "Nuke Ops Victory" (station destroyed via nuke) (lost from,
what I can see, an oversight / accidental swap of report values).
Additionally, small roundend report QOL for cult: Removes antag datums
from spirit realm ghosts after being dusted, so they do not show up on
the report. And in reverse, heads of staff who were dusted / destroyed
in revolution rounds are now also shown in roundend reports.
## Why It's Good For The Game
Some of these reports are dead, which is is a shame because I think
they're cool and fun.
## Changelog
🆑 Melbert
qol: Successfully fending off a blob now has a cross station news report
again. More pressing reports will take priority over it, though.
qol: Successfully killing a wizard (and all of their apprentices) now
has a cross station news report again.
qol: If more than half of a cultist team manages to escape on the
shuttle (rather than summoning Nar'sie), they will send a unique cross
station news report. This is still a loss, by the way. Summon Nar'sie!
qol: Nuclear Operatives successfully nuking the station now has its
unique cross station news report again, and no longer uses the generic
"The station was nuked" report.
qol: Nuking the station to stop a blob infection now has a unique cross
station news report again. Good luck convincing admins to allow this.
qol: Cult ghosts from "Spirit Realm" no longer persist on the cult's
team after being desummoned, meaning they will not show up on roundend
report.
qol: Heads of staff will now always show up on revolution roundend
report - even if their body was fully destroyed.
/🆑
## About The Pull Request
Adds a new station trait, the Cybernetic Revolution
It causes every crewmember to spawn with a cybernetic implant/organ (it
depends on their job).
For example. the bartender has an upgraded cybernetic liver, security
officers have extendable flashes, prisoners have flash shielded eyes.
For AIs, they get the surveillance upgrade.
The trait also lowers research costs for the cybernetic designs, triples
the price of EMP kits and EMP flashlights, doubles price of EMP bombs,
and allows traitors to buy autosurgeons, so they can implant themselves
with whatever they ripped out of the crew.
If you do not wish to partake, you can also take the Body Purist quirk,
which prevents you from getting a cybernetic, but everytime you have a
mechanical limb/organ from some other source, you will take a severe
mood penalty.
## Why It's Good For The Game
This could be a cool modifier to rounds once in a while, slightly
modifying the gameplay of all the crew.
Also our implant system is very barely used, so why not?
## Changelog
🆑
add: New Station Trait: Cybernetic Revolution
add: Body Purist Quirk
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
This replaces needless GLOB.machines with more precise lists whenever
one existed, plus adding a new one for CTF machines.
## Why It's Good For The Game
GLOB.machines holds every single /obj/machinery in the game, so checking
the whole list for stuff is pretty big. This aims to cut that down by
using smaller lists whenever possible. I also gave CTF a new list
because it checked machines very often.
## Changelog
Nothing player facing.
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>
## About The Pull Request
Migrates sound toggle prefs away from legacy toggles, and changes all
related preference checks to the modern form. Cleans up unnecessary
defines linked to the old prefs. Increments the minimum save file
version so a piece of old sound related code can be neatly removed. (The
minimum version hasn't changed in two years anyone who hasn't played in
at least that long probably doesn't even remember they had prefs saved)
Splits off jukebox music into its own preference distinct from
instruments. (This was actually the change that brought about this whole
PR the rest of the igration just made sense to do at the same time)
## Why It's Good For The Game
More granularity in sound preferences is good. It is quite reasonable
for players to want to hear normal volume and largely unobtrusive
instruments, without also being subjected to the aural torture of the
jukebox. As implementing this wothout creating an unwelcome extra legacy
toggle already required setting up a non-legacy sound toggle, it is most
reasonable to migrate the other sounds at the same time.
## Changelog
🆑
qol: Jukebox music can be controlled by a new seperate preference, and
is no longer linked to the instrument sound preference option.
refactor: Sound related toggle preferences have been migrated away from
the legacy system. Pre-existing preferences should be safely migrated
but players are advised to check.
/🆑
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
Area contents isn't a real list, instead it involves filtering
everything in world
This is slow, and something we should have better support for.
So instead, lets manage a list of turfs inside our area. This is simple,
since we already move turfs by area contents anyway
This should speed up the uses I've found, and opens us up to using this
pattern more often, which should make dev work easier.
By nature this is a tad fragile, so I've added a unit test to double
check my work
Rather then instantly removing turfs from the contained_turfs list, we
enter them into a list of turfs to pull out, later.
Then we just use a getter for contained_turfs rather then a var read
This means we don't need to generate a lot of usage off removing turf by
turf from space, and can instead do it only when we need to
I've added a subsystem to manage this process as well, to ensure we
don't get any out of memory errors. It goes entry by entry, ensuring we
get no overtime.
This allows me to keep things like space clean, while keeping high
amounts of usage on a sepearate subsystem when convienient
As a part of this goal of keeping space's churn as low as possible, I've
setup code to ensure we do not add turfs to areas during a z level
increment adjacent mapload. this saves a LOT of time, but is a tad
messy
I've expanded where we use contained_turfs, including into some cases
that filter for objects in areas. need to see if this is sane or not.
Builds sortedAreas on demand, caching until we mark the cache as
violated
It's faster, and it also has the same behavior
I'm not posting speed changes cause frankly they're gonna be a bit
scattered and I'm scared to.
@Mothblocks if you'd like I can look into it. I think it'll pay for
itself just off `reg_in_areas_in_z` (I looked into it. it's really hard
to tell, sometimes it's a bit slower (0.7), sometimes it's 2 seconds
(0.5 if you use the old master figure) faster. life is pain.)
## Why It's Good For The Game
Less stupid, more flexible, more speed
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Posters are kind of insane and they require that the poster item have
either a poster_type defined in the type or that you pass the structure
version of the poster to /new() otherwise they don't work. The weird
thing is that the structure needs to be in the contents of the item too,
or it again won't work (it won't remove the poster from your hands when
placing it). I fixed it so all you need to do is pass the structure
version of the poster to /new() on the item and it will move the
structure to the contents of the item if needed. It's still a bit insane
but it's better than it was and it fixed the bug.
Also SSLibrary.printable_posters was grabbing the directional mapping
helper of the random poster and so when you printed it and placed it,
you'd get confusing results. I made a quick fix to stop that from
happening.
## Why It's Good For The Game
Bug fixes are generally good things.
Fixes#70382Fixes#66504
## Changelog
🆑 VexingRaven
fix: Fixed posters printed from the library console staying in your hand
when you place them
fix: Fixed Random Official Poster printed from the library console
always placing the west-facing variant no matter where you place it
/🆑
## About The Pull Request
A slight logging error resulted in a specific warning about pipenets
never being suppressed, instead continually printing the message that
states that further messages will be suppressed. This was caused by the
limit on pipenet warnings being decremented in the wrong place. This
oversight has been corrected.
## Why It's Good For The Game
This is really annoying to scroll through.
## Changelog
🆑
fix: Properly suppressed a message about suppressing messages.
/🆑
`area.contents` loops over everything in the world to collect its list,
every time.
We need to avoid it where possible. Lemon already working on a PR to
cache it. In the distant future we will lint this.
This was a useless consumer of it. It cost 0.1s to index contents twice
like this.
* 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.
* Moves spawners and decals to a different init/delete scheme
Rather then fully creating and then immediately deleting these things,
we instead do the bare minimum.
This is faster, if in theory more fragile. We should be safe since any
errors should be caught in compile since this is very close to a
"static" action. It does mean these atoms cannot use signals, etc.
* Potentially saves init time, mostly cleans up a silly pattern
We use sleeps and INVOKE_ASYNC to ensure that handing back turfs doesn't
block a space reservation, but this by nature consumes up to the
threshold and a bit more of whatever working block we were in.
This is silly. Should just be a subsystem, so I made it one, with
support for awaiting its finish if you want to
* Optimizes garbage/proc/Queue slightly
Queue takes about 1.6 seconds to process 26k items right now.
The MASSIVE majority of this time is spent on using \ref
This is because \ref returns a string, and that string requires being
inserted into the global cache of strings we store
What I'm doing is caching the result of ANY \ref on the datum it's
applied to. This ensures previous uses will never decay from the string
tree.
This saves about 0.2 seconds of init
* Converts mice and rats to basic mobs
* Update paths
* Fixes
* Tweaks
* .
* Use helpers
* Unit test
* Correct the targeting
* Fixes the unit test?
* Fixes the unit test
* Docs
* update the path script with pr id
* Faction check tweak
* Review
* AHH
About The Pull Request
Basically it was in the documentation of #70199 that this verb was meant for when a new job is added, or for downstreams that have more jobs than /tg/ does. So I tried to use it, and it runtimed because it didn't have one of our own jobs in the jobconfig.toml file already, thus completely defeating the point of the verb.
So I just scooted the variable declarations into the proper null-checked if block, and now it works just fine!
Also, I noticed that a job we had disabled via config wasn't getting properly disabled, turns out values of 0 in the config weren't being respected, and were getting reset to the codebase default. This behavior is now fixed, and shouldn't be an issue anymore, hopefully.
Why It's Good For The Game
Makes a useful verb, actually work for its intended usecase :)
Changelog
🆑 GoldenAlpharex
config: The Generate Job Configuration verb now works as expected when there's at least one job in-game that doesn't exist in the new jobconfig.toml file already.
fix: Any value that is set to 0 in jobconfig.toml will no longer default to the codebase's default, and will actually be considered as 0.
/🆑
Change admin message to stack trace
The admins don't know what to do with this error and I swear to god if I get another ping without a round id or server name I am going to literally explode
* Cleans up the fallout from plane cube
Alright.
Makes cleaning bubbles respect planes
Adds support for updating overlays on move, fixing an issue with pointing at items
Adds better error messages for failing to provide args for mutable_appearance()
Fixes a bug where string overlays were not respecting insertion order
* Adds documentation for offset spokesman and offset_const
* Better stack trace
* Removes some redundant uses of cached MAs
At this scale, attempting to cache MAs like this has 0 impact on anything
And just makes things more messy then they need to be
* ensures fullscreen objects START offset, so things are always proper
* ensures chatmessages always have the right offset
* fixes compile
* whoops, the above lighting plane should actually be ABOVE the lighting plane
* fixes compile, also cleans up the fire overlay a tad
* Adds a unit test for plane masters that are shrunk by multiz being double shrunk
This is slightly hacky because of how I'm handing the plane master
group, but it's not THAT bad, and gives me some real good coverage
* Properly targets the seethrough plane at the game world plate. This fixes unit tests, and also just makes more sense
* whoops
* oh
* adds datum support for allocate(), cleans up a harddel from testing
* Makes camera chunks index at 1, and also makes them support non powers of two sizes, since that was unneeded
* fixes runtime in allocate
Two things:
Stone stairs didn't actually line up, not a soul would have noticed because mappers probably aren't gonna use it for a while, but I fixed it anyways.
Second, you could still build mat datum stairs freely without the whole frame system, invalidating its existence, so I've fixed that too. You can still build mat datum stairs, you just need a stairs frame made of iron or wood first.
* PKP Mind Virus: Glorfing Cigs edition
If you glorf while smoking you'll get the cig stuck in your throat, leaving you unable to breath, speak, or eat. Based off the sort of cig you have a random delay before you vomit up the cig. (Pipes last forever don't philoso-larp kids). Other players can help you by using the help action on you while you're hurt, which leads to something imitating the himelich manuver, a broken chest, and a vomited up blockage. Other forms of vomiting will work too, if that's even applicable.
Oh I fixed a bug in vomit code. Because paralyzing you forces you to the ground, thus changing your dir, paralyzing vomits always went down. This is cringe, easy fix tho.
Ah and I added some extra functionality to sound loops too. You can set them to pick and take from the provided list, then refilling it once it's empty. This keeps some variety while preventing the risk of repeat sounds
Oh and I added some new signals. Some misc ones, for force say and a different kind of help then the existing one, which I renamed. One for breathing, which I used to clean up leroxin. I was planning to hook this but didn't need to in the end.
One for vomiting too. and eating. Also added a way to update looping timer delays. Forgot about that, I also added variable delay for sound loops, because I thought it sounded better here.
Features audio courtesy of our very own san7890, and the quake jump sound.
* Makes only station areas part of Statioj
* Makes only subtypes of /area/station be part of the station
* Removes Icemoon and Shuttles as a check for Anomaly placers as they aren't needed anymore, not being part of shuttles.
* Removes a ton of uses of NO_ALERTS where it is no longer needed.
reintroduces the intermittent queuing behavior found in #65791 since i can actually recover that part. now after MeasureText() puts us in the player input portion of the tick it will queue a callback for the next tick to resume chat message creation
generate_image() is a highly overtiming proc, now its less so
Adds a few new types of stairs, and makes stairs buildable within rounds.
Also removes the terminator sprite variation for stairs, because its basically unused and really not needed with plane cube multiz.
* bileworm health patch
- bileworms start off easier
- vileworms are how they are now + a little tougher
- fixes bileworms breaking proximity spawn rules
- adds gold to bileworm loot
* ssticker
* diagonals readded to attacks\, map fix
* d-delete this
* Update evolutionary_leap.dm
* DONE
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
About The Pull Request
Micros lighting objects, and their creation
We save a good bit of time by not walking space turfs adjacent to new objects.
We also save some time with micros in the actual underlay update logic.
I swear dude we spend like 0.8 seconds of init applying the underlay. I want threaded maptick already
Micros lighting sources, and corner creation
A: Corners were being passed just A turf, and then expected to generatecorners based on that. This is pointless.
It is better to instead pass in the coords of the bottom left turf, and then build in a circle. This saves like 0.3 seconds
B: We use so many damn datum vars in corner application that we just do not need to.
This resolves that, since it pissed me off. It's pointless. Lets cache em instead
There's some misc datum var caching going on here too. Lemme see...
Oh and a bit of shortcutting for a for loop, since it was a tad expensive on its own.
Also I removed the turfs list, because it does fucking nothing. Why is this still here.
All my little optimizations save about 1 second of init I think
Not great, but not bad, and plus actual lighting work is faster now too
Why It's Good For The Game
Speed
