A pretty heavy refactor for pAIs that just spilled into a rework.
Attempts to fully document and organize backend code.
Fixes a large number of bugs left untouched for a decade.
Breaks down the frontend into subcomponents.
Rebalances their software modules.
(should) fix pAI faces get removed if you activate them during alert #68242
* Fixes security level sounds not playing.
- The sound var was never set, turns out it used the default announcement sounds for alert or no alert.
* Documentation tweak
* Thank you san
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: san7890 <the@san7890.com>
Adds baseballs to the game (There is a baseball field in the holodeck).
You can now bat thrown objects with the baseball bat to launch them away at high speed.
https://streamable.com/471jvv (baseball is a boomerang here because otherwise this would have been impossible to test singleplayer)
Why It's Good For The Game
it could be fun to have a game of baseball, and people trying to bat an item thrown at them sounds funny
image
Changelog
cl Fikou, sprite by Mooster
add: Baseballs are now available in the Baseball Field on the Holodeck.
add: Baseball Bats can now hit thrown objects mid-air to send them back.
/cl
* Prevents overtime in the economy SS
Ok so like, we were doing a LOT of work all at once without yielding,
which is fine cause like, it's only fired once every 5 minutes, but it's
still kinda dumb
So I've cleaned up the subsystem to make it support an ssair style of
yielding, alongside an optimization to vending machine z level checks
that I suspect was taking a lot of cpu.
Remind me to refactor z level lookup someday bestie
Anyway yeah now we won't see strangely high overtime for ssecon anymore
* vending gang (renames a variable to not just be v
* It is done
* New player job selection fixes pack
If no jobs are available when random jobbing dont just runtime instead
pop a little tgui alert letting them know they are shit out of luck
Also makes the job debug actually print out the job titles instead of
just printing a . like some kind of insane person
Also also removes some syntax left over from a search and replace
* Update code/modules/mob/dead/new_player/new_player.dm
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Update code/modules/mob/dead/new_player/new_player.dm
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
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
* destroy proc holder pt1
- change proc_holder/spell to action/cooldown/spell
- docs all the spell vars, renames some of them
- removes some useless vars
- start with pointed spells, as they're easy
* kill proc_holder pt2
- kill a buncha vars and replace it with flags
- convert a ton over
- general code improvements
* kill proc_holders pt3
- convert a good few more spells
- rename some signals
- handle statpanel
- better docs
* kiill proc_holder pt4:
- restructure the file system of action.dm, separating a good amount of item actions and miscellaneous garbage into files where they belong slightly better. Also splits off item actions, cooldown actions, innate actions, etc. into their own files, overlal making it much better to work with
- converts touch attacks to actions
- converts blood crawl, jaunt subtype
* kills proc_holder pt5
- clears up some icon issues so all the currently converted pages don't have errors
- shapeshift
- some more action cleanup
* kills proc_holder pt5.5:
- some documentation
- reworks feedback to prevent oversight with teleports and stuff
* kills proc_holder pt6:
- converted cult spells
- converted magic missile
- converted mime spells
- chipped away at the errors
- removed some vars which were too general, replaced them with more locally applicable vars. for example "range" which could mean "projectile range" or "aoe radius" or whatever - instead of having a broad net which everyone applies to in a confusing matter, instead lets each spell delegate on their own.
- merged magic/spell and magic/aoe, as the comment intended
- more unified behavior for spell levelling
* kill proc_holders pt 6.5:
- replacing a buncha old proc_holders that have been updated to reduce some errors. sub 900 baby
* kills proc_holder pt 6.75:
- minor fixes
* kills proc_holder pt7:
- cuts down on some errors
- refactors some wiz events
* kills proc_holder pt 7.5:
- malf ranged modules
- some minor errors
* kills proc_holder pt 7.75:
- mor eminor error handling, cleaning up changes
* kill proc_holder pt8:
- refactors spell book
- refactors spell implant
- some more minor error fixing
* kill proc_holder pt 8.5:
- scan ability
* Adds some robust documentation
* kill proc_holder pt9:
- converts some / most mutations over
* kill proc_holder pt10:
- sort out all the granters
- refactor them slightly
- fix some compile errors
* Some set-unset sanity - going to need to test removing Share()
* Removes transfer actions. It doesn't seem to do anything.
- Transfer_actions was called when current = new_character so locially speaking the early return in Grant() should cause it to NOOP. Test this in the future though
* Removes sharing from actions, docs actions better
* Some better documentation for spell and spell components
* Kills proc_holder pt11:
- Finally finishes ALL THE SPELLS IN THE SPELL FOLDER
- Fixes some more errors
* kills proc_holder pt11.5:
- minor error fixing and sanity
* Method of sharing actions. Can be improved in the future, needs testing
* Implements a way to update the stat panel entry for a spell. Also gets rid of VV stuff, as you can update the bigflags directly in VV now.
* Curse of madness bug I put in.
* kills proc_holder pt12:
- sub 500 errors!
- converts cytology mobs
- converts and refactors spiders slightly
- some minor fixing around the place as usual
* kill proc_holder pt13
- Finishes heretic spells
- Sub 300 errors!
- some touch refactoring to account for mansus grasp
* kills proc_holder pt14:
- revenant
- minor bugfixing for heretic stuff
* kills proc_holder pt14.5:
- some missed stuff for revenant + heretic
* kills proc_holder pt15:
- alien abilities
- more minor fixing
- sub 100 errors. The end is nigh
* kill proc_holder pt16? 17:
- Finishes cult spells
- sub 50 errors!
- refactors the way charge works
- renames / moves some signals
* kills proc_holder pt final:
- sdql spells
- no more errors!
* Bugfixes round 1
* Various bugfixing
- documentation done
- give spell works
- can cast spell gives feedback conditionally
- is available takes into account casting ability
* Some accidental reversions + fixes
* Unit tests
* Completely refactors jaunting
- All bloodcrawling is now handled on the action itself instead of across various living procs
- slaughter demons have their own blood crawls
- jaunting dummies don't have side effects on destroy() anymore
* Wizard spell logging and even more refactoring
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
It occured to me, we didn't have a good way to "see" what turfs were actually being updated
Figured I'd fix that
I've also added some debug vars on SSlighting to make testing with/without some checks easier
Speaking of which, I've added a second check to lighting corner updating
Basically, if our past and current cached rgb values are the same, there's no point updating
This is possible because static lighting is relative. If you've got a
TON of blue, it'll outweight the red and green you have in smaller amounts
We also do some rounding to ensure values look right
Similarly, if you've got roughly the same lighting, and a bit of something you already have a lot of is added, you're not likely to actually enter a new "bracket" of color
Anyway uh, it's hard to profile this, but I've seen it help quite a bit, mostly with things like emergency lighting that updates lighting in small amounts often, and in constricted spaces.
To some extent just comes down to map design
Fixed locate weakpoint do_after being 3 seconds instead of intended 30. Also you can no longer roll locate weakpoint until you get at least 20 minutes of progression via objectives - these two were commented out for testing reasons and I just forgot to uncomment them.
Also moves station_weakpoints from SStraitor to the objectives themselves.
This PR rewrites almost all messages related to cascade events. Some messages felt kinda clunky to read or could have been written better. Overall, the new messages add to the experience as a cascade being a terrifying event in a way that I felt the old ones missed, and they make the event feel overall a lot sharper.
While looking at the resonance cascade code, I noticed that there a lot of stuff about cascades in the air which was not touched on. So, as I do, this PR evolved into a polish and roundup PR for cascades. There was a lot of stuff still hanging out relating to the event, and although the big backend of it sits, there was still a bit left to be completed. Therefore this PR deserves more the title of the "Resonance cascade POLISHENING" instead of the "REFLAVAHRING". But yeah, you ever go on a massive tangent before?
* The Quartermaster is officially a head of staff, with new accesses, a silver ID, ect ect.
* The HoP lost their cargo-related equipment and access, including the Vault monitor, and frequency.
* Reorganizes some of the access and jobs access code for readability.
* Engineers get access to minisat and tcomms, atmos techs get it on skeleton crew.
* Service jobs that used to have morgue access without reason (bartender/botanist/hop) had it moved to skeleton crew.
* RD lost access to Mining, Mining station, and Medbay (holdover from Genetics), but gained Construction access to easily access the AI.
* Roboticist has had their skeleton crew access to ordnance revoked to align with the geneticist's skeleton crew access
* Miners no longer have SHIPPING access (renamed from Mail Sorting)
* The HoS and Paramedics have proper access to the basics in each department again
* Minisats across all maps now require Minisat access to access.
* Secure tech storage now once again requires both Command and Tech storage access again.
So we've got this overlay cap of like 100 right? Prevents OOMs
But right now if you overrun it we have no way of knowing how you got
there, so we just end up with no info.
This pr solves that, by adding a printout of icon-icon_state-dir =
amount for each apperance.
Note, we are basically cheating by typing these overlay members as
mutable apperance, they can be just normal appearances, which we don't
have an accessible type for. Fortunately we can cheat.
Oh and if you overflow the limit you get the error overlay applied to
you, for sniks
Three main things I do:
Reinforce the remap that i have made with code changes, making the atmos control devices sane and easy to put if someone else stumbles upon this part of the code again. (a4aea1e - f16e620)
Splits the ordnance areas and renames them, kills ordnance misc and things that have nothing to do with ordnance (anymore?) moves them to exp_lab (useful stuff here) and aux_lab (fluff stuff here like laser range in delta or second circuit lab in tram). (0c99f9f- 3c82a88)
Adds a roundstart program disk containing nt frontier to the ordnance office table. Added a hint to file manager there too to help give players a nudge on how to publish papers. (fd747dc)
First one: Makes mapping these things not require varedit, nicer for other people that dont know how the atmos control stuffs works.
Second one: Misc lab has nothing to do with ordnance jesus christ. Also ord hallway is now irrelevant, our ordnance labs are very far from box now. Will probably make downstreams a bit angry for a while though since they might not be fully up to date on the ordnance maps.
Third one: Pretty much justified it in the about section.
Why is this not atomic: This touches all five maps and needs code backing, so I might as well combine them into one maintenance PR instead of giving my peers merge conflict three times.
This PR introduces 3 new kind of traitor objectives:
Eyesnatcher objective, you'll need to remove your victim's eyes by any means. You will be given a device that you can use to pull out someone's eyes after 3 5 second delays. This would be quite loud and painful to the victim, so make sure you got them restrained or knocked out.
"Public" Sleeper protocol - this is a high progression(30+ minutes) objective. It's basically Sleeper Protocol, but availible for everyone instead of only med personnel.
Locate Structural Weakpoint - a high progression(45+ minutes) objectives that can be only completed once. You will recieve a device that you'll need to use in 2 different (somewhat secure) areas in order to triangulate the structural weakpoint of the station, you'll need to stay in the area for 30 seconds and station AI will be alerted about your attempt. After triangulating it, you will be given a location-locked explosive which will also create from 5 to 8 minor explosions in a 17-25 tile area.
Kidnap personnel - Basically old contractor kidnap. Down someone, get them to the extraction location, call in a pod, stuff them into it and send it back. Additional TCs if you bring them alive.
DO NOT ADD US TO A LIST OF AI PROCESSING MOBS IF WE ARE QDELETING
hhhhhhhhhhhhhhhhhhh
Oh also lets add more deets to the warning, and upgrade it to an error
I want to actually have to fix these, or just remove them if they become
redundant
Changes the cascade walls from turfs to objects to improve the performances of the roundending cascade.
The issue was that ChangeTurf() was a pretty expensive proc to be called that many times so i moved the cascade wall into an object. It doesn't delete anything other than living mobs and the portal to prevent edge case runtimes.
Plus remove a span_bold() from the announcement text since it wasn't making the text bold but was leaving behind
This is a port of my PR from the beestation downstream BeeStation/BeeStation-Hornet#6845.
This basically adds a proc that will check if the arguments forwarded to generate the new moveloop are identical with the ones on maybe an old loop before it allows it to overwrite it that way we won't endlessly make new loops and destroy old ones even trough there is no reason to.
closes#64510 (Goliaths don't move after you shoot them)
Now the reason why this fixes goliaths chasing others is because goliaths have a movement delay of like 4 seconds enough time for the proc adding the moveloop to chase the target to fire again and add a new moveloop with the same arguments basically overwriting the old moveloop before that one could move the goliath even once this then basically resets the timer for the goliath to move and this goes on pretty much forever the only times the goliath can move is if lag somehow allows the moveloop to move the parent atom before it can get overwritten again (very rare but happened like once during testing).
Now my PR simply stops new identical moveloops (identical in terms of arguments) to get created and to overwrite old moveloops and thus allows the moveloop to continue normally and actually fire for goliaths.
stops unnecessary moveloop datums from beeing created and also fixes a bug as a bonus
* Jetpack and spacedrift: Fixes and niceties
Ok so when I ported spacemovement onto movement loop,
I neglected to port this behavior that existed to support jetpacks.
Basically, if something that lets you move while spacedrifing
completes a move while you're spacedrifting, the
drift should "disable" to let it complete, and then later restart.
I neglected to add support for that, so that's what this does.
There's some other stuff going on here, mostly things to let jetpacks
ignore some of drift's extra behavior, since when a jetpack is not on
stablized, we want both to coexist.
It's a bit of a mess, I'm sorry about that.
Oh and at temporal's suggestion I've moved the visual_delay set from
newtonian move to an istype on the drift component, that was a good
idea, thanks quiet
* Makes dropping a pull while drifting carry the momentum into the pulled thing\
* Adds some extra context to Process_Spacemove, fixes a bunch of stupid
space bugs
It used to be, if you called Process_Spacemove with a direction, it
assumed you were an "action", so a client or mob trying to move in a
direction.
Unfortuantely for it, I needed to be able to use direction to make mob
pull drifting work. So we now actually pass in a second variable
called continuous_move, which tracks if this Process_Spacemove is on
behalf of a continuous move or not
In addition to this, I've added logic to bumping "off" someone to
prevent backbumping if that makes sense, since the bump is in the form
of a newtonian move that's run before the thing that's bumping actually
moves, we need some way to exclude it from holding the other object in
place.
* Adds a jetpack component, uses it to unify all three versions of
jetpacking
I hate you fikou
There were three copies of the same behavior, which made it hard to fix
stuff. Let's just componentize it
* Fixes jetpacks stabalizing even without fuel
This is mildly hacky. The real fix is to do this with events, but I
really don't wanna bend my brain like that. This'll do
* Ensures turn_off always has a user)
* Shut pu
* Bulky drags no longer effect your movespeed in space, fixing a consistency issue between them and all other forms of drags
* Removes some redundant code, cleans up some messy stuff
* Removes redundant safety checking from jetpack code
* see above
* Removes redundant signals
* [DRAFT] Reformats Access IDs for accessibility and futureproofing
* replaced all the old defines and IDs everywhere
* replaced ID integers with strings, cleaned up a couple tram helpers
* replaces req_access_txt with req_access and fixes a few of my mistakes
Co-authored-by: san7890 <the@san7890.com>
i originally changed the refresh rate of the turf tab in the stat panel from 10, to 2, because i felt like it wouldn't be that intensive on clients. apparently it is. now we know!
Hey there,
That little portion that says (debug verbs required) is not helpful at all to anyone who isn't already familiar with the aforementioned debug verbs. It's a pretty buried feature in the codebase as of this PR, so I think it's best to add some more verbosity on actually getting these debug verbs enabled.
Escaping newlines seems to work with logging without any noted downsides, helps readability if it's not all smashed on that one line.
refactors the status panel to utilize the tgui/byond communication APIs instead of passing along href data, as well as converts the entirety of it into a datum/tgui_window
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
Allows configs to once again change job positions of jobs, and additionally allows them to completely disable some jobs. In the past, Pubby didn't have Lawyers and Curators, I doubt this would be the case in the future, but I find having this as an option for config is still good.
I also properly logged jobs not loading due to removal from mapping config, to be in job debug instead of testing.
Finally, I removed the old config_job, and made all configs use title instead. It was suggested I use typepath instead of title, but I am against doing it for the time being, as I don't expect Mappers to look for typepaths if all they want to do is make mapping stuff, though arguments can be made against that (like how its case sensitive so it's easy to break).
Cascade walls were processing on object subsystem, they are now in their own subsystem that ticks once per second and should be more reliable even in case of high td
better description for the walls to be more interesting
