This time I'm waiting for a bunch of SQL queries to finish. They, take a while.
Documents everything relevant about the CI process broadly. Intentionally written for someone who isn't familiar with any relevant terminology.
Closes#70169
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
Hey there,
The wiki is not good for very visual guides (from my personal experience), and this guide serves a much better guide to getting Git set up (as well as being up to date with all of the latest stuff). The Wiki is important, but let's arm new contributors for the best success possible.
This pr goes through: /client/Click(), /client/Topic(), /mob/living/verb/resist(), /mob/verb/quick_equip(), /mob/verb/examinate(), and /mob/verb/mode() and makes them queue their functionality to a subsystem to execute in the next tick if the server is overloaded. To do this a new subsystem is made to handle most verbs called SSverb_manager, if the server is overloaded the verb queues itself in the subsystem and returns, then near the start of the next tick that verb is resumed with the provided callback. The verbs are called directly after SSinput, and the subsystem does not yield until its queue is completely finished.
The exception are clicks from player input since they are extremely important for the feeling of responsiveness. I considered not queuing them but theyre too expensive not to, suffering from a death of a thousand cuts performance wise from many many things in the process adding up. Instead clicks are executed at the very start of the next tick, as the first action that SSinput completes, before player movement is processed even.
A few months ago, before I died I was trying to figure out why games at midpop (40-50 people) had non zero and consistent time dilation without maptick being consistently above 28% (which is when the MC stops yielding for maptick if its overloaded). I found it out, started working on this pr, then promptly died. luckily im a bit less dead now
the current MC has a problem: the cost of verbs is completely and totally invisible to it, it cannot account for them. Why is this bad? because verbs are the last thing to execute in the tick, after the MC and SendMaps have finished executing.
tick diagram2
If the MC is overloaded and uses 100% of the time it allots itself this means that if SendMaps uses the amount its expected to take, verbs have at most 2% of the tick to execute in before they are overtiming and thus delaying the start of the next tick. This is bad, and im 99% sure this is the majority of our overtime.
Take Click() for example. Click isnt listed as a verb but since its called as a result of client commands its executed at the end of the tick like other verbs. in this random 80 pop sybil round profile i had saved on my computer sybil 80 pop (2).txt /client/Click() has an overtime of only 1.8 seconds, which isnt that bad. however it has a self cpu of 2.5 seconds meaning 1.8/2.5 = 72% of its time is overtiming, and it also is calling 80.2 seconds worth of total cpu, which means that more than 57.7 seconds of overtime is attributed to just /client/Click() executing at the very end of a tick. the reason why this isnt obvious is just because the verbs themselves typically dont have high enough self cpu to get high enough on the rankings of overtiming procs to be noticed, all of their overtime is distributed among a ton of procs they call in the chain.
Since i cant guarantee the MC resumes at the very start of the next tick due to other sleeping procs almost always resuming first: I time the duration between clicks being queued up for the next tick and when theyre actually executed. if it exceeds 20 milliseconds of added latency (less than one tenth the average human reaction time) clicks will execute immediately instead of queuing, this should make instances where a player can notice the added latency a vanishingly small minority of cases. still, this should be tm'd
* Moves Cobby from the Maintainers section to the Contributors section as they had retired, and lowercases the 'd' in Dragomagol to match their Github username.
Wake up honey new Mothblocks style guide just dropped
Rendered
Read closely as I make some new expectations that I think are very good for readability but that we don't tend to employ.
@tgstation/commit-access
I don't think this will actually fix the CI failure right now (which is a GitHub bug) but some random guy said it worked for him
I don't believe him, let's see
This has no breaking changes other than like old node versions? Or something?
Adds validate_dme.py to the CI suite to verify that tgstation.dme is in proper alphabetical order
And by alphabetical order I mean the ass-backwards specific rules that Dream Maker enforces
I looked at #66813 (215dfeb185) and found more housekeeping to do:
Combines Lemon's and Ghilker's atmos sections into the same line in the multiple owners section
Formats oranges' citrium.dm line to be like the rest of the file
I standardized some stuff regarding Codeowners (space between the names and the files they own), and since Maps/Sprites are managed seperately than the other "Multiple Codeowners" Section, I decided to split that out as well (let me know if that was cringe or not).
I also put Jordie in the Contributors section as well (😢) .
Areas.dmi right now houses all of our mapped turfs icons (which is roughly 400 icons). Not an issue, but it's incredibly large and clunky to navigate right now. This isn't an issue for the average coder and/or player code diving, but it is for mappers wanting to add new turfs. Currently, the file has some organization, but its still an overall mess. This PR aims to slice the behemoth with multiple .dmi files corresponding to specific areas.
I also plan to repath /area/* -> /area/station/* for station turf only. This is to clean it up, as most other turfs follow this format (that being /area/turf_zone/*).
I'm also writing an update paths file as I go along.
We already have a sort of excerpt section in here, but I'm throwing a link to the HackMD guide we now have in this guide that directly involves Maps and Away Missions to help new mapping contributors or people who simply want to get a jump on mapping stuff.
* Refactors dizziness into a status effect
* Refactors the dizziness setter to use the new kind
* Drunkness.
- Should drunk continue to work off of a magic value or be swapped to duration? I've not yet decided: For understandability it's preferabale for "drunk" to use a timer (they are drunk for 3 more minutes), but both adding drunk and decreasing drunk currently use weird calculations which would be difficult to carry over.
- Ballmer is a liver trait
* Dizzy was a setter, not an adjuster
* Does all the drunk effects over
- refactors examine text fully
- refactors stabilized blacks because of this
* Removed
* repaths, fixes some issues
* Minor fixes
* Some erroneous changes
* Fixes some dizziness errors
* Consistency thing
* Warning
* Undoes this change, I dont like its implementation
* max_duration
* Max amount
* Should be a negative
* max duration
* drunk doesn't tick on death
* Rework dizziness strength
* Erroneous dizzy change
* Fixes return type
About The Pull Request
Separated compiling the integration tests and running them as separate steps for organization purposes.
Added a TEST_ASSERT_NULL(value, reason) and TEST_ASSERT_NOTNULL(value, reason) because those are conceptually simple tests.
Makes the PASS and FAIL prefixes in the integration test log be green and red for better readability.
Failure reasons now display the file and line number.
In order to achieve this, direct calls to Fail() are now wrapped in a macro, TEST_FAIL(), as Fail() itself needs preprocessor stuff passed to it.
In the midst of updating it, I noticed multiple cases of tests directly calling Fail() and returning when they should have used a better macro, so those were updated. There was at least one case where it appeared that the code assumed that the test ended at Fail(), but made no attempt to do so, such as with the RCD test.
Feel free to double check all of the changed unit tests in case I made a functional behavior change, but they currently pass.
To take advantage of the previous change, failures are now marked as annotations. Note that outside of github, this creates an ugly-looking line but the primary environment is as a github action.
Examples with intentionally botched unit test:
image
image
image
Why It's Good For The Game
Makes inspecting failed unit tests significantly easier.
Changelog
N/A
About The Pull Request
This PR:
Moves the part explaining why you should justify your changes to its own section in contributing.md, and expands on it greatly.
Adjusts the pull request template to place a further emphasis on arguing for why your changes are good in the Why It's Good For The Game section.
Why It's Good For The Game
Changes that piss people off because of x, y, and z can have merit in spite of that, but that merit should be explained. Period. There is no downside to putting in a reasonable effort to justify why what you're doing will improve the game.
Lazy, low effort explanations for the merits of your changes, wholly unsuited to the level of justification needed to be considered adequate by anyone, should no longer be accepted into our codebase until they are at the very least adequate. This isn't stuff like bugfixes or tiny features no one has any problems with, this is for stuff like #58038 or #62947 or #57831 or #64693 which have either abysmal justification for their changes or are outright refusing any real attempt at a justification relative to their effects.
Proper justification for controversial PRs should be required even if you have explicit support of a maintainer, or maintainers, or a head coder, or multiple head coders, or the entirety of humanity, or God himself before the pr is even made. Because when a PR is merged, the argument for its changes become the codebases argument instead of just the authors. Thus all potentially controversial changes should have a level of effort put into their arguments proportional to their effect on the game.
Documentation is extremely important for the longevity of the codebase.
Well written documentation allows for experienced coders to use the code to it's fullest extent, while also allowing new contributors to get a foothold easier.
* Updates Maps And Away Missions MD
Hey there,
This was outdated for a bit, so I decided to pretty it up and make a few things a bit more explicit.
I alphabetized the maps since we don't really prioritize one-over-the-other (except Meta now being the default map instead of the non-existent Box).
I also alphabetized Removed Station Maps, and removed the "outdated" (they are all outdated, or will definitely all be outdated by the time a reader reads this).
I elaborated a bit more on how station maps are loaded these days (correct me if I am wrong).
Standardized how we show code paths.
Gave explicit instructions on never using Dream Maker to map, and linking two programs that we tell anyone who wanders in on the Discord to use anyways (please do inform me if we should not do this- but Dream Maker just fucking sucks shit).
I also fixed up some language around the Away Missions part, and added a newer section for the Map Depot since I do not believe it is discussed elsewhere on the main repository (as well as a short warning on anyone who things they can get Phobos or something running out-of-the-box).
Alright, cool.
