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.
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.
* Refactors tcg code a bit. Adds support for "keywords"
Idea is to allow card makers to embed tooltips in their card
descriptions.
These tooltips are defined in the keywords.json file
They can be referenced using {$keyword_name}
I've also done some refactoring to move more logic and state onto the
subsystem, and implemented a few keywords from the wiki
* New keywords, applies the old ones to the second card set
* Adds support for embedding react components in tgui chat
This is done by adding the data-component attribute to an html element
The value of that attibute is the component you want to use.
New components can be added by modifying the TGUI_CHAT_COMPONENTS list
in tgui-panel/chat/renderer.js.
Props can also be passed in in a limited capacity.
Any props you wish to pass must be added to
TGUI_CHAT_ATTRIBUTES_TO_PROPS.
This is due to a style restriction of html attributes, they cannot
contain an upper case char.
Use this list to convert between attibute compatible text and the prop's
name.
Props support 3 datatypes.
true and false can be passed by wrapping them in ""s. (Note to self add
a special char here to prevent colison with people just passing the
string true.
Numbers are supported in a limited capacity. Whitespace is not allowed,
but floats and ints are fair game.
And of course, strings are fully supported.
I've currently added support for Tooltip, since that's what I'm using
this for. Also added some tooltip html styles to the chat css.
* Implements the embedded component system to make tcg cards have nice pretty tooltips so people don't need to have the wiki open on one screen
* Adds documentation for embedding tgui components in chat, adds some protection against accidentially sending true as a bool
* Adds italitcs to the tooltips, moves the span stuff to a macro
* tGUI -> tgui, thank fikou
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Style suggestions
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
* Removes unneeded key from the components list
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
* Removes needless span
* Actually adds the tooltip, oops
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
About The Pull Request
I found this out while reading through the contributing file today and thought I should change it before goof uses it as an excuse to label a ton of PRs again.
For those unaware: https://github.com/orgs/tgstation/teams/issue-managers/discussions/10
Why It's Good For The Game
github thing, not a game one.
Changelog
Not needed.
makes most updating stat panel tabs update once every 4 seconds instead of 4 deciseconds, but switching tabs instantly updates statpanel data for you. also makes examining a turf make flat icons for a maximum of 10 contents instead of 30 because its ridiculous to call getFuckingFlatIcon() wrappers that many times. also makes SSfluids not have SS_TICKER and updates its wait accordingly because theres no reason for it to be a ticker subsystem
the mc tab updates every 2 seconds unless someone has the pref enabled to refresh it quickly because SOME UNILLUMINATED LEMONS absolutely must watch overtime spikes in real time
statpanels can take between 1-3% of masters total processing time at very high pop, which is silly considering theres no need for someone to know any of the data updated accurate to less than half of a second. The only reason it needed to update so fast was because it looked awful when switching tabs, which will only be updated on the next fire. now switching tabs updates data instantly so theres no need to update the rest of the data quickly.
also makes each stat tab update into its own proc so we can tell how much each tab update costs
AI Controllers are pretty difficult to learn if you don't have someone to explain the concepts, I thought I could cut that out by having a handy dandy guide to show people. If we're ever to eventually move all simplemobs onto basic mobs, we need to have a weapon like this to combat the questions.
The more people who understand Datum AI, the better. I remember a few maintainers mentioning that it would be nicer to have more guides in the repo, since it is essentially 9,970 bytes of future review prevention.
A while back oranges made this really nice pr. #59465 It was mostly done to make snake_case mandatory for pretty much everything, along with a few other style things. But he got fed up with our 800 line contrib file, and decided to split it up.
I share a similar hatred for our guidelines, people don't read them and finding anything is just guesswork
People will just throw their work at the bottom or top of a file with no regard for any order. It's hell to read and work with.
So I "borrowed legally under agpl v3" ~~stole~~ his code and expanded on it.
I think? he was working with the intent of splitting the main tower file into several different subfiles. I don't think I have the right vision to do that properly, but I've done what I can.
Splits contributing.md's Specifications section into 2 files:
- Style.md, which describes formatting patterns and clean code.
- Standards.md, this lays out the rules we have for code. More function, less cleanliness.
Each file is separated into different sections. They cover things like styling for procs, variables, paths, or how to structure your code properly, optimization pitfalls to avoid, etc.
I've also created a development guides section in the contributing guidelines, to include links the above alongside things like autodoc, hard deletes, and the policy config section.
Makes a subfolder of .github called /guides to hold files like this, and the ones that exist to teach people how to set up servers.
## Why It's Good For The Game
I got bored, and MSO took away my keys, so I can't fix harddels right now.
Plus if I did my job right this will make learning from and adding to what we've written down much easier.
* Migrates some content over from hackmd, this should make it more visible, which I think is a good thing.
In other news, we really should reorg this document, should make subdocs like oranges wanted
* Parently we lint for this, nice
Bans the use of icons and icon_state strings as overlay items.
Adds a note about using associated lists to cache things
Why:
Overlays get converted to appearances by byond on insert, so if we want to be able to do list math on the overlay lists, we have to do this conversion ourselves as well, otherwise -= "blah" wouldn't work as it won't be a string anymore.
This requires creating a new appearance every time an overlay operation happens for these use case, or search for cached versions of them in an associated list. images, appearances and mutable appearances can be converted into an appearance for free because they already are appearances
Associated lists have a lot of hidden overhead, leading to them to get abused for caching details that doesn't need to be cached. they are faster to search then normal lists, but slower then global, static, and proc vars, and very likely the same as datum vars, if not slower.
They have a higher per item memory usage then global vars (8b), proc vars (8b), datum vars (16b), or flat lists (8b) because they have to store the key twice, once in the flat array for for loops, and again in the tree structure along with the value.
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
This has more or less been enforced already by me and Rohesie, but puts it into clear writing, as the frequency of these names stays about the same.
Formally bans variables like M, C, and H. Writes an exclusion for `i`, as though I don't like this one, I believe other maintainers disagree. Let me know if I'm misinformed.
Also adds some additional details on negated names, such as `is_not_flying` -> `is_flying`.
* Updates the contribution guidelines to include the `as anything` key to skip checks in lists.
* Reduces the explanation a bit, to make it more succinct.
* Makes the examples use default byond types and vars, and code that actually compiles, instead of pseudo-code. Plus early continues, because they're good.
Updates the contribution guidelines to require the addition, removal or replacement of station maps to require prior approval before making the PR.
Ultimately shouldn't change much about how the PRs are handled, but gives an early warning that approval should be sought and should help cut down on lost time mapping if I would reject a PR outright. With how long station maps take to make, prior warning that it outright won't be merged is, in my opinion, good.
Adds a clause to the contributing guidelines that you are expected to have tested your code, which implicitly bans webedited larger PRs. Also updates the wording about changelogs.
Delta-time is a concept we added but isn't used a lot yet, I think adding it to the contribution guidelines with an explanation of how to actually use it (As its a concept that only really applies to game dev afaik, and isn't something everyone is familiar with) will increase the amount of people using it.
* Case of lower
* More changes
* Ruins the nice 420 diff, brainfart when doing the second batch of conversions
* More changes
* Next batch. I think
* Converts even more paths
* Restarts bots
* Capital Free Zone
* Come on travis, do something
* Renames areas
* Bots, please stop dying
* Updates CONTRIBUTING.md and updates a few paths I missed.
* APC recgarftzfvas
/obj/item/computer_hardware/recharger/apc to /obj/item/computer_hardware/recharger/apc_recharger
