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>
* [s] Dead people can no longer communicate with the living
Thought listener, through chicanery, could let you still pass through valid strings (and not fail) if you were a mob/dead/observer occupying your mob/living body. god dammit. check to make sure the fucker is dead.
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
Changes components\atom\reagentscanner to use table list from Assoc list.
Added purity output to components\atom\reagentscanner.
At time of making this its impossible to iterate through the output of reagentscanner via loops or numerical index and to determine the amount or the reagent scanned you needed to know its associated value which is less than idea.
Queried this issue on coderbus meeting 3 then asked Watermelon and he agreed that a change would be good.
Added a "purity" to the table outputs to make shells of this component "desirable" to chemistry who need to use Ph_meter to check exact purity. If this not allowed I’m willing to make an \atom\reagentscanner\adv variant that will comparable to Ph_meter.
I intend to give the same treatment to materialscanner.
* Optimizes away /obj/Initialize
We were spending like 0.15 seconds just checking for blueprints, obj
flags and network ids
All these things can just be applied where they're wanted, saves time
Oh and I replaced object flags with an emag injector. I'll give it a
sprite and name later I promise
* Requires a GenerateTag() call to set DF_USE_TAG, rather then doing a check in atom New
This is technically harder to use, but I don't really want people using
tags, and it saves 0.15 seconds
* Moves generatetag to /datum
* I am dumb
* Saves 0.5 seconds, makes init emissive blockers actually work
Ok so background. If an overlay is added with add_overlay, and not
"managed" somehow, it will effectively never be removed, because
nothing's tracking it.
Update_overlays uses the managed_overlays list/var (one of those) to do
this.
I'm gonna piggyback off this to make emissive overlays actually like,
respect overlay updates.
Oh and uh, I've saved maybe 0.5 seconds by caching the new emissive, and
not using add_overlay. There's a chance this will lead to overlay
corruption, but since we never readd the flattened, I think we'll be
safe
* Fixes plane not being set right, changes color logic too, since alpha will override past color sets
* Makes it actually work. also makes rand posters update appearance to clear away the overlay, since it shows on right click and looks bad
* Fixes blockers showing as emissives. It turns out alpha sets override the color list we use. Not sure why we pretend to support them
* Makes the injector support traits, adds an amazing sprite
Moves singulo and supermatter dmis into obj/engine, renamed from obj/tesla_engine
Moves Halloween, Christmas, and misc holiday items to obj/holiday
Moves lollipops to obj/food
Moves crates, closets, and storage to obj/storage
Moves assemblies to obj/assemblies
Renames decals.dmi to signs.dmi ...because they're signs and not decals
Moves statues, cutouts, instruments, art supplies, and crayons to obj/art
Moves balloons, plushes, toys, cards, dice, the hourglass, and TCG to obj/toys
Moves guns, swords, shields to obj/weapons
See title, these checks are based on those used by set_turf_examine_tab for the statpanel.
Fixes#68596 (in the specific case of the plasma image holder in the bug, it has MOUSE_OPACITY_TRANSPARENT)
* Refactored fundamental circuit components that have varying inputs. Made the integrated circuit UI slightly better.
* Fixes with UI
* Removes logger
* Ran prettier
* Fixed documentation
* Rebalances drone circuit
* Drones can now charge in chargers
Co-authored-by: Watermelon914 <hidden@hidden.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
Fixes#67885.
I don't know if this works because I can't reproduce locally, but I can reproduce on servers so I'll let you know next Sybil round It works
* Fuck you (refactors ur tails)
* Errors
* Wow. Pain.
* Fixes up probably everything
* finish up here
* Fixes hard del maybe
* original owner hard del
* garbage collection runtime
* suck my peen byond
* Mapped tails
* motherfucker.
* motherrfucker. again.
* Whooopppppsie
* yeah bad idea
* Turns out external organs literally just sat in nullspace forever if their parent was deleted, and didnt Remove() themselves, causing harddels.
* So anyways I repathed all organs
* Fixes
* really.
* unit test... test
* unit test-test but it passes linters this time because im a moh-ron
* I've lost track of what im doing at this point
* Hopefully fixes hard del?
* meh
* Update code/datums/dna.dm
* things n stuff
* repath from master pull
* [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>
* makes hud images only apply by z level
* makes some of the atom_hud procs have better names
* fixes warning with the hud_user list and adds better documentation
* better docs for hud_images
* removes TODOs
* docs for hud_list
* adds support for linked z levels so mobs can see lower ones
* fixes merge conflict and shittily makes only shocked airlocks get added
* adds support for setting images in the hud as active and inactive
* gets rid of unatomic spatial grid change
* maybe i should actually try COMPILING my changes
* fixes merge skew and makes it compile again
* fixes huds refusing to remove from users who changed z level
* improves z level and registration logic
* fixes antag huds not appearing
* Fixes antag huds not properly setting. We now use hud_list in init, so it needs to be set before the new call, not after. Not sure why the use of appearance key was split like this, but none else knows either so none can stop me
* Ensures that hiding a basic appearance also hides the atom's active list too
* Fixes antag huds going poof
Ensures that remove_atom_from_hud will return false if the passed atom
isn't managed by it
This fixes antag huds disappearing randomly, since they assumed that if
the parent call of remove_atom_from_hud returned true, we should delete
ourselves. This is a safe assumption for them to make, since they should
only ever have one atom.
Does kinda bork if we call remove_atom_from_hud in a way that is unsure
if the passed atom is actually in that list. We were forced into doing
this by how atom huds use the qdeleting signal.
* makes basic alternate_appearance's only update themselves when setting their hud image to active and makes them not add themselves to the global huds_by_category list
* fixes mistake with hud_users list being set non associatively (bad)
* as anything in bot path loops
* Fixes merge skew problems
* Makes bot paths non global
This way they can show themselves to only the bot that "owns" them, ya
feel me?
* Fixes huds not showing up sometimes, cleans up some code
Post Kapu's limb refactor, we were calling prepare_huds twice in a human
init call chain. What was happening was this:
call prepare_huds() // Human
I gained a new hud image
I set active hud icons to mirror it
call prepare_huds() // Living
I overwrote the new hud image
I attempted to set active hud icons, which failed because it assumes
this can never happen
*cries*
* Renames add_hud_to_atom to show_to
My hope is this will make understanding hud code a bit easier, by tying
the behavior to a "verb" more closely. Also renamed a few vars
* remove_hud_from_mob -> hide_from
* Nitpicks a few comments
* Whoops/fuck/shit/damn it all/hhhhhhhhhhhh
* Moves check down, improves stack trace a bit
Co-authored-by: KylerAce <kylerlumpkin1@gmail.com>
adds Lizard Scream, Moth Buzz, Toy Squeak, Xenomorph Hiss, Warp Whistle, Poster Rip, Coinflip, Flash, Flashbang, Laugh Track, Whip, Gavel, and Megaphone to the circuit sound synthesizer
please comment other sounds you want to see in this since its easy to add and gives more creativity to circuit makers
* unfinished circuit laserpointer module
If this makes a pr I will be very mad
* Almost done making it function
* adds it to the research path
* lets it be logged
* Makes it work and printable
* removes felinid moving to save time dilation + removes cyborg stun because just no
* minor changes
* removes unused var oops
* guh?? (alphabet)
Since #51534, it would appear that the actual contents of papers wasn't being logged.
Current paper logs are effectively useless. This makes them actually useful again.
This PR adds 2 new BCI components: VOX component which allows to play vox announcements(for the user only!) and Thought Listener component which allows user to input a string upon activation.
I've also added a rotation port for the object overlay component so you can make pinpointers using it.
This PR requires #65604
Adds view sensor component to circuits which allows to get all visible(no ghost detectors, sorry) movable atoms in a 5 tile range. It only works when your circuit's shell is placed on the ground or is held in hands.
Adds a wiremod component called "Format List" and one called "Format Associative List" that you get at round-start.
It accepts a format string and a list of parameters.
For "Format List":
The format string contains normal text, and codes of the form %n (eg. %1, %2, %3) that correlate to indexes in the param list.
For "Format Associative List":
The format string contains normal text, and codes of the form %key (eg. %name, %health) that correlate to keys in the associative param list.
The param list can contain any types, which will be automatically converted to strings.
Conversion of entities to strings still follows the range rule of To String. Important to keep in mind if you're formatting an NTNet transmission.
For the associative version, the keys must be strings comprised of letters, numbers, or underscore.
Simplest example that says "Bob McToolbox pressed the button.":
See title. Lets you use input and output signals to set variables instead of automatically setting them.
Gives more control, additionally there may be cases where you don't want this, and the normal component still exists.
They're two separate components so that the first one can be a lot more compact
Tags would bug out due to how the 'Save Shell' component would copy all the variables on an object except a few restricted ones, though this proved to be very buggy.
The duplicator part has been removed and more proper logging has been added.
To compensate for the duplicator part being removed, admin circuit display names will now replace the entire name of the shell.
This makes several small changes to the MODsuit circuit module:
Adds the MODsuit Action component. When selected, the circuit module opens a radial menu with which to select an action component to trigger.
Due to its similarity to the BCI Action component, both it and the BCI Action component have been made subtypes of an abstract equipment_action component that implements their shared functionality.
Renames the MOD component to the MOD circuit adapter core component.
Changes the "selected module" port on the MOD circuit adapter core to a string port, for consistency with the corresponding input port.
The circuit in the circuit module can be removed. Consequentually, the circuit module no longer comes with a pre-installed circuit.
The "Toggle Suit" signal port on the MOD circuit adapter core can now activate the modsuit.
Makes the circuit module printable in the component printer, for consistency.
Moves the circuit module's code to modules/wiremod, for consistency.
BCI action component properly typechecks the shell it's inserted in.
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
This PR adds several circuit components used for scanning and checking ID cards:
The Get ID component returns the ID the target is wearing or holding
The Read ID Info component returns the name, rank, and age registered on the ID
The Read ID Access component returns a list of all the accesses on the ID
The Access Checker component does comparisons on lists of numbers, specifically tailored for checking ID access
Due to the access checker using a similar UI element to the airlock electronics, that element has been moved to its own file in tgui/interfaces/common. This change is not player-facing.
About The Pull Request
Converts more inputs to TGUI. Possibly all user-facing input lists in the game.
Did any surrounding text/number inputs as well
Added null choice support so users can press cancel.
Added some misc TGUI input fixes
Fixed custom vendors while I was there
I refactored a lot of code while just poking around.
Primarily, usage of .len in files where I was already working on lists.
Some code was just awful - look at guardian.dm and its non use of early returns
If there are any disputes, I can revert it just fine, those changes are not integral to the PR.
Why It's Good For The Game
Fixes#63629Fixes#63307
Fixes custom vendors /again/
Text input is more performant.
Part of a long series of TGUI conversion to make the game more visually appealing
Changelog
cl
refactor: The majority of user facing input lists have been converted to TGUI.
refactor: Tgui text inputs now scale with entered input.
fix: Many inputs now properly accept cancelling out of the menu.
fix: Fixes an edge case where users could not press enter on number inputs.
fix: Custom vendor bluescreen.
fix: You can now press ENTER on text inputs without an entry to cancel.
/cl
Attempting to load a BCI or circuit MODsuit module with the save shell component yields an empty circuit. This PR fixes that by making the save shell component check for and delete any pre-existing circuit in the loaded shell.
Added a couple components that convert a number into an array of binary digits and viceversa.
May help players mak more complex and advanced components without filtering those lacking knowledge in the binary field.
Adds COMSIG_ITEM_AFTERATTACK_SECONDARY and COMSIG_MOB_ITEM_AFTERATTACK_SECONDARY signals, which are both called by item/proc/afterattack_secondary.
Adds COMSIG_ITEM_PRE_ATTACK_SECONDARY and COMSIG_ITEM_AFTERATTACK_SECONDARY to the list of circuit signal handler presets.
The proc call, set var, and spawn atom components will resolve any weakrefs passed to them in their parameter port, seeing as the list literal component now converts datums into weakrefs.
Title. The clickon proc calls params2list only after the component signal was sent notwhitstanding clickon comsig procs also needing to access these parameters in order to work properly, which means every one of these comsig procs has its own params2list(params) call. This problem isn't exlusive to these comsig procs. For some reason the params text string is passed down to the melee click chain, afterattack and afterattack_secondary instead of the params/modifiers list... buuut we'll get there later. TL;DR params2list is being called more times than necessary because of a suboptimal old code.
Another issue: Some of these comsig procs ignore parameters such as shift, which is used to examinate things and access popup menus, alt, ctrl and/or middle mouse button. This is the case of the honorbound mutation datum, shy and shy in room components, mechas and the clown car. This is of course also getting fixed.
I'm adding a circuit component that can print text string on a paper object in a variety of colors and font typefaces (currently only web-safe ones are available, maybe i'll add some fancy ones in the future but they'd need to be imported either through @import of @font-face in a separate CSS not imported by every tgui UI).
It's important to note that because the UI sanitizes new text inputed by users and not what's already written on the paper (so the pen_color and pen_font don't be purged in the process), we can't safely have these strings "printed" into the info variable directly, because of that these values will be stored in two new list variables, one for the text and one for font color, face and the signature. When the paper sheet UI is opened, these will be sanitized and then parsed into the text, so the next time the paper is edited we can clear these two lists.
Obviously better than a hacky byond proc - parsemarkdown() is outdated af -, albeit a bit messy... like the rest of paper code.
Requires #62033.
Adds a circuit component that outputs the station time in chosen format and unit of time when triggered. The options are currently 24-hour and 12-hour for the time format, hours, minutes and seconds for the unit of time.
The component is called timepiece because clock was already taken by another component that sends signal outputs at intervals.
Components like the MMI one can't be added to circuits more than once since they may register signals with same proctype and similar things which make for some tangled up race conditions if more than one is present.
Unfortunately this safety can be bypassed - with little gain alas, an MMI can't be inserted by attacking the component with it. it needs a shell - by using a module component. That's no good. So I'm adding a flag that can be used to stop certain components from being added to module components.
