7 Commits

Author	SHA1	Message	Date
Arturlang	0bc42d6940	Fixes the issue of usr pointing to admins by making Trigger pass down clicker (#92354) ... ## About The Pull Request Fixes the issue of usr pointing to admins by making Trigger pass down clicker, as usr is fucky and can be passed down by other unrelated procs. Fun. Added the clicker arg to all usages of Trigger as well Also changes isobserver check in antagonist ui_act code that prevents observers from clicking UI's instead to check if the ui.user is owner.current ## Why It's Good For The Game Fixes admins giving heretic to people opening the heretic UI for the admin instead	2025-08-05 22:58:40 -05:00
LemonInTheDark	77823ad210	Pathfinding Visualization, JPS fixes, Misc Improvement (#90233) ... ## About The Pull Request [cleans up poor namespacing on light debugging tools](93cc9070d5) [Implements a pathfinding visualization tool](ed91f69ac4) It holds a set of inputs from the client, and uses them to generate and display paths from source/target. Left click sets the source, right click sets the target. Pathmap support too, if no target is set we display the paths from every turf in the map to the source, if one is set we build a path TO it from the source. I had to add COMSIG_MOB_CLICKON to observers to make this work (tho idk why it didn't exist already), I also removed the everpresent colorblind datum from admin datums, only needs to exist if they're using it. [Adds a mutable_appearance helper that dirlocks them, wallening port which I thought might be useful here, and will likely be useful elsewhere in future](87f752e7c3) [Fixes an infinite loop in pathmaps if we tried to pull a cached path to an unreachable target, && not || 4head](10086a655d) [Fixes JPS not dealing with border objects properly. They violate some of the assumptions JPS makes, so we need to backfill them with checks. These basically read as (if the thing that should normally take this path can't reach this turf, can we?)](f56cc4dd43) ## Why It's Good For The Game Maybe deals with #80619? Adds more robust testing tools for pathfinding, should allow people to better understand/debug these systems. I added this with the idea of adding multiz support but I don't have the time for that rn. JPS will work around thindows better, that's nice. https://file.house/IrBiR0bGxoKw1jJJoxgMRQ==.mp4 ## Changelog 🆑 fix: Fixed our pathfinding logic getting deeply confused by border objects admin: Added clientside displayed pathfinding debug tools, give em a go /🆑	2025-03-28 01:51:57 +02:00
itsmeow	cc335e7e9e	IconForge: rust-g Spritesheet Generation (#89478) ... ## About The Pull Request Replaces the asset subsystem's spritesheet generator with a rust-based implementation (https://github.com/tgstation/rust-g/pull/160). This is a rough port of https://github.com/BeeStation/BeeStation-Hornet/pull/10404, but it includes fixes for some cases I didn't catch that apply on TG. (FWIW we've been using this system on prod for over a year and encountered no major issues.) ### TG MAINTAINER NOTE  ### Batched Spritesheets `/datum/asset/spritesheet_batched`: A version of the spritesheet system that collects a list of `/datum/universal_icon`s and sends them off to rustg asynchronously, and the generation also runs on another thread, so the game doesn't block during realize_spritesheet. The rust generation is about 10x faster when it comes to actual icon generation, but the biggest perk of the batched spritesheets is the caching system. This PR notably does not convert a few things to the new spritesheet generator. - Species and antagonist icons in the preferences view because they use getFlatIcon ~~which can't be converted to universal icons~~. - Yes, this is still a *massive* cost to init, unfortunately. On Bee, I actually enabled the 'legacy' cache on prod and development, which you can see in my PR. That's why I added the 'clear cache' verb and the `unregister()` procs, because it can force a regeneration at runtime. I decided not to port this, since I think it would be detrimental to the large amount of contributors here. - It is *technically* possible to port parts of this to the uni_icon system by making a uni_icon version of getFlatIcon. However, some overlays use runtime-generated icons which are ~~completely unparseable to IconForge, since they're stored in the RSC and don't exist as files anywhere~~. This is most noticeable with things like hair (which blend additively with the hair mask on the server, thus making them invisible to `get_flat_uni_icon`). It also doesn't help that species and antag icons will still need to generate a bunch of dummies and delete them to even verify cache validity. - It is actually possible to write the RSC icons to the filesystem (using fcopy) and reference them in IconForge. However, I'm going to wait on doing this until I port my GAGS implementation because it requires GAGS to exist on the filesystem as well. #### Caching IconForge generates a cache based on the set of icons used, all transform operations applied, and the source DMIs of each icon used within the spritesheet. It can compare the hashes and invalidate the cache automatically if any of these change. This means we can enable caching on development, and have absolutely no downsides, because if anything changes, the cache invalidates itself. The caching has a mean cost of ~5ms and saves a lot of time compared to generating the spritesheet, even with rust's faster generation. The main downside is that the cache still requires building the list of icons and their transforms, then json encoding it to send to rustg. Here's an abbreviated example of a cache JSON. All of these need to match for the cache to be valid. `input_hash` contains the transform definitions for all the sprites in the spritesheet, so if the input to iconforge changes, that hash catches it. The `sizes` and `sprites` are loaded into DM. ```json { "input_hash": "99f1bc67d590e000", "dmi_hashes": { "icons/ui/achievements/achievements.dmi": "771200c75da11c62" }, "sizes": [ "76x76" ], "sprites": { "achievement-rustascend": { "size_id": "76x76", "position": 1 } }, "rustg_version": "3.6.0", "dm_version": 1 } ``` ### Universal Icons Universal icons are just a collection of DMI, Icon State, and any icon transformation procs you apply (blends, crops, scales). They can be convered to DM icons via `to_icon()`. I've included an implementation of GAGS that produces universal icons, allowing GAGS items to be converted into them. IconForge can read universal icons and add them to spritesheets. It's basically just a wrapper that reimplements BYOND icon procs. ### Other Stuff Converts some uses of md5asfile within legacy spritesheets to use rustg_hash_file instead, improving the performance of their generation. Fixes lizard body markings not showing in previews, and re-adds eyes to the ethereal color preview. This is a side effect of IconForge having *much* better error handling than DM icon procs. Invalid stuff that gets passed around will error instead of silently doing nothing. Changes the CSS used in legacy spritesheet generation to split `background: url(...) no-repeat` into separate props. This is necessary for WebView2, as IE treats these properties differently - adding `background-color` to an icon object (as seen in the R&D console) won't work if you don't split these out. Deletes unused spritesheets and their associated icons (condiments spritesheet, old PDA spritesheet) ## Why It's Good For The Game If you press "Character Setup", the 10-13sec of lag is now approximately 0.5-2 seconds. Tracy profile showing the time spent on get_asset_datum. I pressed the preferences button during init on both branches. Do note that this was ran with a smart cache HIT, so no generation occurred.  Much lower worst-case for /datum/asset/New (which includes `create_spritesheets()` and `register()`)  Here's a look at the internal costs from rustg - as you can see `generate_spritesheet()` is very fast:  ### Comparison for a single spritesheet - chat spritesheet: **Before**  **After**  ## Changelog 🆑 fix: Fixed lizard body markings and ethereal feature previews in the preference menu missing some overlays. refactor: Optimized spritesheet asset generation greatly using rustg IconForge, greatly reducing post-initialization lag as well as reducing init times and saving server computation. config: Added 'smart' asset caching, for batched rustg IconForge spritesheets. It is persistent and suitable for use on local, with automatic invalidation. add: Added admin verbs - Debug -> Clear Smart/Legacy Asset Cache for spritesheets. fix: Fixed R&D console icons breaking on WebView2/516 /🆑	2025-03-03 14:58:27 +01:00
Lucy	d656f0f4ec	Refactor GLOB.admin/debug/fun_state into cached /datum/ui_state/admin_state instances (#89417) ... ## About The Pull Request So, some admin verbs/tools that used tguis, i.e edit/debug planes, were available to admins with +DEBUG... but the ui_state used `GLOB.admin_state`, which checks for +ADMIN - meaning that if they _only_ had +DEBUG, they would have the verb... but it would do nothing when they used it. I've refactored `GLOB.admin_state`, `GLOB.debug_state`, and `GLOB.fun_state` into a merged `/datum/ui_state/admin_state`, with a var for which specific permissions are being checked for. You now use the `ADMIN_STATE(perms)` macro to get the UI state for those specific perms, i.e `admin_state(R_ADMIN)` or `admin_state(R_DEBUG)`, and the resulting UI state will check for _those specific perms_. These are initialized and cached in `GLOB.admin_states` (which should never be directly accessed). So, I've went thru every single usage of `GLOB.admin_state`, `GLOB.fun_state`, and `GLOB.debug_state`, and made them all use `ADMIN_STATE()` with the actual permission flags needed to use said UI in the first place. ## Why It's Good For The Game Kinda dumb for specific admin permissions to be granted verbs that don't let them use it anyways. ## Changelog 🆑 admin: Certain UI-based tools (plane debugger, filter editor, etc) that were given to admins with only +VAREDIT or +DEBUG, but refused to open without +ADMIN, now actually work for admins that have the needed permission. /🆑	2025-02-17 00:54:00 +01:00
SyncIt21	b6369a47b4	Mouse drag & drop refactored attack chain (#83690) ... ## About The Pull Request Mouse drag & drop has been refactored into its own attack chain. The flowchart below summarizes it  Brief summary of each proc is as follows **1. `atom/MouseDrop()`** - It is now non overridable. No subtype should ever touch this proc because it performs 2 basic checks a) Measures the time between mouse down & mouse release. If its less than `LENIENCY_TIME`(0.1 seconds) then the operation is not considered a drag but a simple click b) Measures the distance squared between the drag start & end point. If its less than `LENIENCY_DISTANCE`(16 pixels screen space) then the drag is considered too small and is discarded - These 2 sanity checks for drag & drop are applied across all operations without fail **2. `atom/base_mouse_drop_handler()`** - This is where atoms handle mouse drag & drop inside the world. Ideally it is non overridable in most cases because it also performs 2 checks - Is the dragged object & the drop target adjacent to the player?. Screen elements always return true for this case - Additional checks can be enforced by `can_perform_action()` done only on the dragged object. It uses the combined flags of `interaction_flags_mouse_drop` for both the dragged object & drop target to determine if the operation is feasible. We do this only on the dragged object because if both the dragged object & drop target are adjacent to the player then `can_perform_action()` will return the same results when done on either object so it makes no difference. Checks can be bypassed via the `IGNORE_MOUSE_DROP_CHECKS` which is used by huds & screen elements or in case you want to implement your own unique checks **3. `atom/mouse_drop_dragged()`** - Called on the object that is being dragged, drop target passed here as well, subtypes do their stuff here - `COMSIG_MOUSEDROP_ONTO` is sent afterwards. It does not require subtypes to call their parent proc **4. `atom/mouse_drop_receive()`** - Called on the drop target that is receiving the dragged object, subtypes do their stuff here - `COMSIG_MOUSEDROPPED_ONTO` is sent afterwards. It does not require subtypes to call their parent proc ## Why It's Good For The Game Implements basic sanity checks across all drag & drop operations. Allows us to reduce code like this 8c8311e624/code/game/machinery/dna_scanner.dm (L144-L145) Into this ``` if(!iscarbon(target)) return ``` I'm tired of seeing this code pattern `!Adjacent(user) || !user.Adjacent(target)` copy pasted all over the place. Let's just write that at the atom level & be done with it ## Changelog 🆑 refactor: Mouse drag & drop attack chain has been refactored. Report any bugs on GitHub fix: You cannot close the cryo tube on yourself with Alt click like before /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com>	2024-06-13 13:28:41 -07:00
Jeremiah	e766f921f6	Code cleanup: Sorting (#83017) ... ## About The Pull Request 1. Removes code duplication 2. Fully documents `sortTim()` 3. Makes a define with default sortTim behavior, straight and to the point for 95% of cases 4. Migrates other sorts into the same file 5. Removes some redundancy where they're reassigning a variable using an in place sorter For the record, we only use timSort ## Why It's Good For The Game More documentation, easier to read, uses `length` over `len`, etc Should be no gameplay effect at all	2024-05-04 23:33:52 -04:00
LemonInTheDark	41f20bc3ce	[MDB IGNORE] Angled Lights & Lighting Prototyping Tool (#74365) ... ## About The Pull Request Hello friends, I've been on a bit of a lighting kick recently, and I decided I clearly do not have enough things to work on as it is. This pr adds angle support to static lights, and a concepting/debug tool for playing with lights on a map. Let's start from first principles yeah? ### Why Angled Lights? Mappers, since they can't actually see a light's effect in editor, tend to go off gut. That gut is based more off what "makes sense" then how things actually work This means they'll overplace light sources, and also they tend to treat lights, particularly light "bars" (the bigger ones) as directional. So you'll have two lights on either sides of a pillar, lights inside a room with lights outside pointing out, etc.  This has annoying side effects. A lot of our map is overlit, to the point that knocking out a light does.... pretty much nothing. I find this sad, and would like to work to prevent it. I think dark and dim, while it does not suit the normal game, is amazing for vibes, and I want it to be easier to see that. Angled lights bring how lights work more in line with how mappers expect lights work, and avoids bleedover into rooms that shouldn't be bled into, working towards that goal of mine. ### How Angled Lights? This is more complex then you'd first think so we'll go step by step  Oh before we start, some catchup from the last time I touched lighting code. Instead of doing a lighting falloff calculation for each lighting corner (a block that represents the resolution of our lights) in view we instead generate cached lightsheets. These precalculate and store all possible falloffs for x and y distances from a source. This is very useful for angle work, since it makes it almost totally free. Atoms get 2 new values. light_angle and light_dir Light angle is the angle the light uses, and light_dir is a cardinal direction it displays in We take these values, and inside sheetbuilding do some optional angle work. getting the center angle, the angle of a pair of coords, and then the delta between them. This is then multiplied against the standard falloff formula, and job done. We do need some extra fenangling to make this all work nicely tho. We currently use a pixel turf var stored on the light source to do distance calculations. This is the turf we pretend the light source is on for visuals, most often used to make wall lights work nice. The trouble is it's not very granular, and doesn't always have the effect you might want. So, instead of generating and storing a pixel turf to do our distance calculations against, we store x and y offset variables. We use them to expand our working range and sheet size to ensure things visually make sense, and then offset any positions by them. I've added a way for sources to have opinions on their offsets too, and am using them for wall lights. This ensures the angle calculations don't make the wall behind a light fulldark, which would be silly. ### Debug Tool? In the interest of helping with that core problem, lights being complex to display, I've added a prototyping tool to the game. It's locked behind mapping verbs, and works about like this. Once the verb is activated, it iterates over all the sources in the world (except turfs because those are kinda silly), outlining and "freezing" them, preventing any future changes. Then, it adds 3 buttons to the owners of a light source.  The first button toggles the light on and off, as desired. The third allows you to move the source around, with a little targeting icon replacing your mouse The second tho, that's more interesting. The second button opens a debug menu for that light  There's a lot here, let's go through it. Bit on the left is a list of templates, which allow you to sample existing light types (No I have no idea why the background is fullwhite, need to work on that pre merge) You can choose one by clicking it, and hitting the upload button. This replaces your existing lighting values with the template's, alongside replacing its icon and icon state so it looks right. There are three types as of now, mostly for categorization. Bar, which are the larger typically stronger lights, Bulb, which are well, bulbs, and Misc which could be expanded, but currently just contains floor lights. Alongside that you can manually edit the power, range, color and angle of the focused light. I also have support for changing the direction of the light source, since anything that uses directional lighting would also tie light dir to it. This isn't *always* done tho, so I should maybe find a way to edit light dir too. My hope is this tool will allow for better concepting of a room's lights, and easier changing of individual object's light values to suit the right visuals. ### Lemon No Why What Ok so I applied angle lights to bars and bulbs, which means I am changing the lighting of pretty much every map in the codebase. I'm gonna uh, go check my work. Alongside this I intend to give lighting some depth. So if there's room to make a space warmer, or highlight light colors from other sources, I will do that. (Images as examples)  I also want to work on that other goal of mine, making breaking lights matter. So I'll be doing what I can to ensure you only need to break one light to make a meaningful change in the scene. This is semi complicated by one light source not ever actually reaching fullbright on its own, but we do what we must because we can.  I'm as I hope you know biased towards darker spaces, I think contrast has vibes. In particular I do not think strong lights really suit maintenance. Most of what is used there are bulbs, so I'm planning on replacing most uses with low power bulbs, to keep light impacts to rooms, alongside reducing the amount of lights placed in the main tunnels  **If you take issue with this methodology please do so NOW**, I don't want to have to do another pass over things. Oh also I'm saving station maps for last since ruins are less likely to get touched in mapping march and all. ### Misc + Finishing Thoughts Light templates support mirroring vars off typepaths using a subtype, which means all the templates added here do not require updating if the source type changes somehow. I'd like to expand the template list at some point, perhaps in future. I've opened this as a draft to make my intentions to make my changes to lights known, and to serve as motivation for all the map changes I need to do. ### Farish Future I'm unhappy with how we currently configure lights. I would like a system that more directly matches the idea of drawing falloff curves, along with allowing for different falloffs for different colors, alongside extending the idea to angle falloff. This would make out of engine lighting easier, allow for nicer looking lights (red to pink, blue to purple, etc), and improve accessibility by artists. This is slightly far off, because I have other obligations and it's kinda complicated, but I'd like to mention it cause it's one of my many pipedreams. ## Changelog 🆑 add: Added angle lighting, applies it to most wall lights! add: Adds a lighting prototyping tool, mappers go try it out (it's locked behind the mapping verb) /🆑 --------- Co-authored-by: MMMiracles <lolaccount1@hotmail.com>	2023-07-19 04:39:55 +00:00