**About the pull request**
Radial menu's replaced with TGUI window for all plumbing RCD's
https://user-images.githubusercontent.com/110812394/204481973-8f6d62c0-9288-4165-bce7-ee8bfec95bee.mp4
**Why it's good for the game**
**1. Faster Navigation**
- Old System: It had 3 radial menus'
->To select type of device to build
->To select the colour of fluid ducts
->To select the layer of devices
3 menus for one system makes navigation between them annoying for e.g.:
to create a red fluid duct of layer 5 you have to open all these 3 menus
& cycling through the radial menu by clicking the next button is time
consuming when you have a large number of items
- New System: with just one window open it's as simple as 3 clicks and
your done just like the RPD
**2. Always available**
- Old System: When you select an option inside a radial menu the menu
closes so you have to reopen it again to change a setting
- New System: open the window drag it to the side and it will always be
there for you
**3. Just easier for our eyes**
- Old System: Moving my eyes in a circle across the menu only to find
out i have to click Next and circle my eyes again honestly makes my head
spin
- New System: The menu options are small enough to be viewed all at once
& helps me see what I need more easily
**4. Consistency**
Both the RPD & plumbing all have similar concepts i.e., pipes, devices,
layers & colours it only makes sense they should have similar
interfaces. Also categorizing the items into tabs can help with
explaining what each item does
**Conclusion**
Just because the radial menu looks attractive shouldn't mean it must be
used everywhere, it only makes sense to use it when the number of
options of an item is small enough to be displayed on the screen all at
once for e.g., modules in a Mod suit. If the user has to click the next
button to cycle through the item's, it defeats the purpose of the radial
menu and makes the user work more to find his settings
**Side Note :** removed unused code in RapidPipeDispenser.js
**ChangeLog**
🆑
add: plumbing constructor TGUI, just like Rapid Pipe Dispensers
del: plumbing constructor radials
code: categories for each item
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Co-authored-by: Time-Green <timkoster1@hotmail.com>
## About The Pull Request
Fixes annoying roundstart runtimes coming from a wrong deduplication
method. `sprites[id]` was empty at the time of the check and only got
filled when it started actually building the spritesheet. Now it's
tracked in a local variable.
No changelog update since it's not visible on the player side.
So i left over some basic `/whatever/proc/format` uses in the original
PR this fixes it.
Notable exceptions to the rule:
- Paths in add_verb/remove_verb, we need full path instead of a name
there to access verb metadata so we can't use proc ref macros there.
- regex.Replace, found out that it does not accept call by name. Instead
i added new REGEX_REPLACE_HANDLER so we can at least try to mark these.
There's still leftover global procs that do not use GLOBAL_PROC_REF but
they functionally equivalent so that's for later.
I don't see any reasonable way to grep for this. But if you got any
ideas please share.
## About The Pull Request
Demo: https://streamable.com/wnj3mf
Features:
- Full support for most gradients/vectors/numbers/generators/transforms
( I might have forgotten some of the more esoteric ones)
- A "tutorial" section that explains the different rand/generation types
and how physics works with pictures
- Button for viewing what each var does
- Selecting a particle type to set immediately
- The generator types use defines now
Not included:
Color matrix support for color generators (I'm sorry but hell no)
Special thanks to @jlsnow301 for explaining js things to me
## Why It's Good For The Game
Making cool stuf
## Changelog
🆑
refactor: Added a particle editor to VV dropdown which can be used by
coders and admins to edit particle values on the fly easily.
/🆑
Co-authored-by: TiviPlus <572233640+TiviPlus@users.noreply.com>
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>
An Emojipedia app has been added to tablets, given to Mimes and Curators by default, allowing anyone to know all emojis. Additionally, emojis can be used in tablets by every job now.
* Moves spawners and decals to a different init/delete scheme
Rather then fully creating and then immediately deleting these things,
we instead do the bare minimum.
This is faster, if in theory more fragile. We should be safe since any
errors should be caught in compile since this is very close to a
"static" action. It does mean these atoms cannot use signals, etc.
* Potentially saves init time, mostly cleans up a silly pattern
We use sleeps and INVOKE_ASYNC to ensure that handing back turfs doesn't
block a space reservation, but this by nature consumes up to the
threshold and a bit more of whatever working block we were in.
This is silly. Should just be a subsystem, so I made it one, with
support for awaiting its finish if you want to
* Optimizes garbage/proc/Queue slightly
Queue takes about 1.6 seconds to process 26k items right now.
The MASSIVE majority of this time is spent on using \ref
This is because \ref returns a string, and that string requires being
inserted into the global cache of strings we store
What I'm doing is caching the result of ANY \ref on the datum it's
applied to. This ensures previous uses will never decay from the string
tree.
This saves about 0.2 seconds of init
* How to conflict with PRs: A guide
* Removes unnecessary support for the now-removed job disks from Tablet's TGUI menu, and tablet's ui_act.
* Adds autodoc comments to computer files
* Removes the unused 'unsendable' var on computer files
* Generally improves code on tablets, now process isn't looping through every idle thread twice!
* Moves the check for program in idle_threads above checking if supported by hardware, because it's already running, so there's no need to check.
* eh
* revert a scipaper change
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
* Removes recharger tablet parts
Removes 'advanced' tablet subtypes that we used before PDAs were added, in some jobs.
Replaces Roboticist's advanced tablet mail with a laptop
Moves the notepad's note var from the tablet, to the note app
Moves modular computer's defines into their own file
Machine computers now directly use power from the machine they're in, while the rest uses power cells.
Silicon tablets don't use power at all.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
The asset was being loaded, seeing that fully_generated is false, so it
attempts to rebuild. The rebuilding clears the existing file cache, and
fucks us.
Life is pain.
* Adds lazyloading to the asset subsystems
This currently applies only to spritesheets because of how monumentally
expensive they are.
If an asset is requested it will immediately be fully loaded, but
otherwise we slowly load them in with a separate subsystem.
This allows us to not hold up initialize with hair stuff. Saves roughly
33% (16 seconds with LOW_MEMORY_MODE) of initialize on my machine
My target is something closer to the 9 second init that had back in
2019, this is a good first step. Lets see how much more we can do yeah
lads?
Co-authored-by: san7890 <the@san7890.com>
About The Pull Request
This is my fourth food expansion PR, adding and changing quite a few things.
This PR will:
Add 7 different types of salads
Add a new ingredient supply beacon box called 'Salads', which includes ingredients used for the salad recipes
Give cherry jelly its own container, and allow jelly to be ordered from the produce console
Make cherry jelly actually nourish you when consumed
Add paçoca, a Brazilian peanut candy requested by @GuillaumePrata
Add mashed potatoes
Add shepherds pie
Add Cullen skink
* Makes condiments their own subtype, fixes geese, prepares for merging
* Fixes geese checking drink type instead of edible foodtype to eat gross food.
* Renames foodtype var on drinks to drink_types to prevent above from happening again because it KEEPS HAPPENING. DRINKS AREN'T FOOD!
* Makes Condiments their own subtype of reagent_containers because they don't make any use of being a subtype of food, at all.
* Starts moving things from food to /food/drink subtype in preparation for merging /food/drink with /drink
* fully removes Food subtype
* /reagent_containers/drinks are now /reagent_containers/cup - This is so it's no longer confused with eachother.
* /food/drinks is now /reagent_containers/cup/drinks, so we can keep their special abilities.
* Fixes a LOT of errors with food, which are STILL checking the reagent_containers, despite ACTUAL food being refactored away from it a long time ago.
This doesn't compile yet, but I do want to make sure my progress is well tracked.
* remove copypaste code, changes soda cans
* Removes most copy paste code between the two drinks, moving most stuff to parent whenever needed.
* Made soda cans their own subtype since they didn't share anything with glass bottles anyways.
* Fixes more problems with food/drinks, especially with geese. Geese really were just broken this whole time and no one said a word...
* Removes a snowflake signal, now that both drink types share a common one.
* Adds everything to the .dme
Currently my goal is to get this all compiling, then remove isGlass var by making glass be all glass ones only.
* Moves all icons into a single drinks dmi
I'm not that great at icon stuff, hopefully I didn't forget/break anything.
* Turns juices into their own subtype
This allows us to let them check for type in molotov, to both get rid of a use of isGlass, and so non-glass non-cartons don't show up as 'carton'.
* fixes compile issues, adds updatepaths
* a better updatepaths
* updates the damn maps now
* properly names the updatepath
* how did that get there
* i suck at handling merge conflicts
* how am i this bad
* code improvement and soda fix
* more fixes
* Don't be a timer
Ports from old food bottles to trans the reagents, rather than add a timer to.
* Merge conflicts and fixes bottle smashing
* Bottle smashing is now consistently functional regardless of how much liquid they have in them, when before it would spill first, then smash on the second hit.
* runs updatepaths again
Fixes#65831
In this PR I added a system of pre-prepared paper forms for the printer. This system worked for a while and because of security problems in the papers was completely broken by quick fixes to the holes. I did not try to fix the forms, because at the time because of the broken papers it was pointless, and I decided to wait until the code papers are fully recycled. Waiting for a fix, I rewrote the config and now the system blanks again normally print forms. In addition, this fix allowed to bring the configuration of the forms in a more readable form.
As a bonus, I decided to add a "VOID" stamp. I was going to do it back when the system of forms was introduced, but because the stamps at the time did not work properly I did not do it.
Adds fishing and fishing minigame.
You use fishing rod to fish.
Equipping specific bait/hook/reels will affect your success chances.
You can fish out fish,items and other things.
Fishing Equipment
Fishing rods have three slots: Bait, Reel and Hook.
Any food can be used as bait but dedicated bait makes fishing easier.
You can buy hook and line sets
New bait types:
Worms : Buy can of them at cargo (alternative acquirement method pending)
Doughballs : Use knife on flat piece of dough to get five of them.
Fishing rod types:
Basic : Print these at the lathe, nothing fancy here.
Tech: Experimental tech. Provides infinite bait
Fishing rods can also hook and reel normal items.
Equipment screen and reeling video
Fishing spots
Keep in mind this PR is meant to add the basic systems and i intend to fill these with more fish in future PR's so wait with suggestions until then.
Lavaland lava (no fish here right now, just other stuff), requires reinforced line to fish in.
Maintenance moisture traps.
Beach away mission water.
Fishing portal available for purchase from cargo - This is stopgap until we fill more spots.
Difficulty depends on fishing spot, fish type, and the fish traits and rod setup combinations.
All fish types can have specific traits, most common ones being favourite and disliked bait types/categories.
Other
Fishing catalog now lists fishing related info
New admin debug verb, fishing calculator that show probabilities with different setups so it's easier to balance this.
Fish now have average weight and size. Make sure to boast if you catch a big one.
Adds tgui mouse passthrough
Screens
Sprites:
Fishing portal sprite by @ArcaneMusic
Other sprites by @Mey-Ha-Zah
Bad ones by me. (Could still use better fishing minigame backgrounds)
Sounds:
https://freesound.org/people/soundscalpel.com/sounds/110393/https://freesound.org/people/soundslikewillem/sounds/343748/
* makes compile time icons not do expensive file io for asset gen
* better documentation on some asset vars and procs
* makes generate_and_hash_rsc_file() do fcopy() and passes down the chain
* implements msos suggestion to optimize get_icon_dmi_path()
This bug breaks disabling the cdn mid round if the cdn is broken, as well as enabling it mid round if it started the round disabled. some things fail back to byond transfers, but not all things.
* Prevents potentially infinite length books from being written and stored. I'm not sure if this is an actual issue, but I have a funny feeling it may become one someday
* Moves the paper defines to their own file
* It's become clear to me that I am stupid
* git add --all
* Makes book info into a datum to allow for easy passing around
* Converts the library scanner to tgui, lays the groundwork for tgui visitor consoles
* Makes the db request for book info sort
Adds the frontend for the visitor's console
Adds a hash to prevent duplicate db requests
Adds a prams changed var to help facilitate a better search button
Makes the page number code accept text as input
* Makes the ui index at 1 even tho we index at 0 internally
* Begins the conversion process for the library console.
Changes the library console to override the visitor, to utalize for the archive access portion of the ui
Makes scanner into a weakref, I'm coming for you handheld scanner
Renames some vars to make things clearer
* Converts the remaining refs of the old console typepath over, adds a circuit board for consoles because pain
* Changes how bookshelves load in books
Instead of loading them in lazyally, we load them during init
This lets us track what books are stored in which areas
Somewhat jutting off of this, adds map config for designating something as "part of the library"
This will be useful later
* Renames the random poster, adds a spritesheet for bibles. Both will be useful in a moment
* Ok. This is a bit of a mess.
Converts the library console to tgui.
This comes with a few minor behavior changes:
You can now select what type of poster you want to print, instead of just printing a random one
It's now possible to heed the console's emag warning
The console's inventory page will fill at roundstart with the books in your area/if you're in a library, any
areas designated as "library like" in the map config
You can see what type of bible the chaplin has selected?
"Fixes":
You can no longer just dump books into the scanner forever
Implementation details:
Any input that makes a db request will now A: freeze up any other db inputs until it's finished, and B: Start a
1 second timer before any new db requests can be made
Of note, I'm handling html encoding in a very targeted way.
All book_data datums need to have html encoded values. get_title/author/content exist so a defaulting and tgui
appropriate version can be loaded in. This somewhat matches with the trusted var on set_title, it exists to
prevent double html encoding.
While we're here
Input/DB (Book data should be html encoded)
Inside book datum (Book data should be html encoded)
Sending to tgui (Book data should be decoded during extraction with the get_() procs)
Sending anywhere else (Book data should be html encoded, otherwise it's an xss vuln)
Uhhhh tgui stuff?
I'm using a custom theme for emag visuals, I'll get into that more later
The visitor and book management console share the same data/act pipeline, which is why they're parented/subtyped
They also share a page selection component, which is why the visitor's console imports it.
Uhhhhh
Oh right, fuck.
Ok so the page selection component is kinda cursed, the left and right controls are fine
But I'm trying to get a << < [page/max] > >> setup going, and that means resetting the center input past change
so the default value can be used
This ends up being slightly hacky. I'm sorry.
Oh also, I implemented a custom tab setup for this ui. I have no idea why it was literally like 5 months ago.
I think it looks pretty nice, but if you want me to nuke it I can. Sorry for any headache around this.
More tgui stuff next
* Scanner/visitor cleanup, some other odds and ends
* Adds in a dark red and black theme for library computers to be triggered by an emag.
Things of note: I'm overriding some lists that get passed into buttons and one other thing using set, since the
list is alreadt generated by that step in the process? I think?
I've added dimness control to the dimmer component, since well, it was dimming already dark uis.
I also made and added a rather large background svg. I've got no experience with this sort of thing, and all the
compression methods I found for this ended up being busts. I know this isn't acceptable as an end product, but I
don't know how to get it there.
Somewhat on that note, this ui might not be worth the size for the amount of use it gets. I'm fine with nuking
it if that's the case, I bring this up because I have a very poor understanding of the logistics of something
like this, so I have a feeling I've fucked up somewhere
* Forgot these, just a scss file for library computers, barely used but I think it's worthwhile
* Missed this eariler. As a part of the uploading tab, I'm displaying the contents of books. I'm loading in that
context as raw html so paper -> book books look close to right. Means I need more html tags then our current
sanitize provides. I don't think any of these will cause issues, and there's also a good chance I'm missing
some. Will come up with a list later
* Updates the rest of the maps to use the new management typepath
* Fixes the default bible name being Default Bible Name, I am sorry
* Turns out I had the scaling wrong for bible names, lead to weird stacking because the bible icon doesn't scale, so I lowered its sizing
* Yeets unneeded exports (Thank you jlsnow)
Haha wouldn't it be funny if I didn't know how components worked
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
* Resets the maps to master
* Fixes oversights from merge commit, changes maps
* Removes needless Flex's from the scanner
* Gives the library console the ability to parse markdown. Expands the list of acceptable html elements a bit
* Adds audio cues for printing and inserting/removing from the scanner, makes the scanner nicer to use in general
* Uses a compressed version of the background. It's still huge, but smaller at least
* Adds the printing audio to the book binder
* Cleans up tram
* curse you tram
* AHHHHHHHH
* MY LIFE IS TRUE PAIN
* Adds a path conversion statement to make people's lives easier
* Apply's style's suggestions
thx style
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
* Compresses the background svg
* Further js cleanup
* We no longer render markdown in the ui, since any source of markdown is converted to html anyway
* More ui changes
Makes the tab/main screen logic use Flex rather then manuel offsets
Makes modals better fit the size of their contents
Readjusts the width of some inputs
Properly uses the header prop for a table
Makes the buttons in the upload panel look nicer
Restructures the print tab a bit
* Increase a modal's size
* Fixes computers with no keyboard overlay showing their screen even when the power is out
* Moves some data and logic onto the library subsystem. Kyler's review
Fixes harddels held by the library scanner. Makes the scanner's buffer
actually do something
* Makes book icon randomization a proc rather then just copypasta'd code
* Removes the kilo library edit, the soul was removed
* Damn you san (Fixes mapconflicts)
* Pain
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
Refactors fish into proper paths.
Removes aquarium behaviour intermediary datums.
Moves fish functionality out of aquarium content component.
Fixes flopping animation resetting on dropping.
Simplifies everything. There should be no player facing changes.
The animate signal is kinda weak method of solving the animate queue issue but it seemed least intrusive to me.
Open to any better ideas.
TLDR
Mech UI now TGUI: https://streamable.com/ahjydy
Mechs now use "slots" for equipment
They can only mount 2 guns(left and right arm, left and right click to use)
Tesla & Concealed bay is removed
Removed mech damage deflection
Full list of changes
Note: weapons in this section refer to all click-using equipment such as guns/hydraulic clamp/etc
Hackmd: https://hackmd.io/lgr-LetfSKyHzPP0zQUXPA
Tesla has been removed (Tesla gives you effectively infinite power on station and off station(where the design direction for mechs is intended) they are useless)
Concealed mech bay has been removed (Concealed mecha bay relied on selection for visibility so it doent make sense to exist when all equips are "selected", the code was bad (instead of flag or something you just used locate() everywhere)
Honker no longer has snowflake UI (I'm sorry but if I have to make a third UI for this im going to go insane)
Mechs now mount 2 arm weapons, and certain amount of "utility", "armor" and "power" module types
The two arm weapons do not share a cooldown anymore UNLESS they are identical weapons
left click to shoot left weapon right click for right weapon, this will shoot the weapon unless you click next to you with a ranged weapon it will then try to melee (This also applies to attaching the weapon to the mech)
It is no longer possible to deflect or have multipliers for damage from innate or armor sources, armor will now just apply a direct armor change
Since plasma generator needed to be selected to use you now need to click on the power generator with a stack of plasma to refill it
Internal damage:
The mech no longer needs to be low health to take internal damage
Internal damage now no longer has several convoluted ways to fix each different type and is now a timed action performed in the UI
Weapons no longer have an RNG chance to be damaged or immediately deleted by damage
Weapons will now take damage aimed at the right and left arms respectively, this can be repaired using the new UI. NOTE: this is intended to be implemented as weapon/module disabling but I left it out of this PR to try resemble some shortness
Both internal and equipment damage have minimum thresholds of damage required in a hit before they attempt to check whether the mech should take internal or equipment damage, teh threshold is lower for equipment damage
You can no longer reload weapons using energy
Demo Video
https://streamable.com/ahjydy
I was fucking deranged when I originally made this. I not only didn't actually include the assigned species to the uplink's ui data, but I made the code add each objective item to the uplink list twice. This fixes both of those problems, and makes it more readable.
Fixes a mistake I caused.
Closes#64806 (Species-Restricted uplink items don't appear)
Role-restricted and species restricted items can be purchased again.
Species-restricted items no longer appear in surplus.
* Move element to component, start UI, move assets into their own directory
* Complete UI
* Stop when another surgery is started
* Set your real zone since I forgot you actually need to start the surgery too
* Bring this back since I was just removing it as part of a cleanup for asset cache, but I can't prove it's not used anymore
* Remove unnecessary constructor I was using for something else
* Fix signal override
Preference asset creation, which while consistently created in early assets, can be requested at any time before then and often is, currently takes about 15 to 25 seconds to produce. Because of extremely hard to reproduce BYOND icon bugs, most of this is done on the same tick.
Lowering the cost of initialization itself is very tricky. Some of it we can theoretically optimize, such as creating humans for antagonists, others we can't, such as the raw cost of icon blending.
Furthermore, adding new icons later down the line would just increase this initialization time even more.
Instead of optimizing the asset creation, which is an uphill battle, this instead chooses to amortize the cost by caching preference assets created per git revision. This means that preference assets will be created, with their long delay, only once whenever the code changes.
This is done on a config, defaulting to on so that production needs no changes, as the whole point of these being made at runtime at all is that it keeps assets/art styles consistent, and PRs making subtle bugs that break preference generation in some way is not uncommon. On development, your git revision will stay the same until you commit, no matter what code changes you make.
Atomizes a much larger PR for another time...
There are typos in span and other html messages that causes them to not render correctly or at all.
Bug fixes
Converts those instances of span to use the macro
About The Pull Request
Paintings can now do stroke painting.
Added painting management panel for admins.
Paintings now display author's character name, year of painting, medium and patron when hung on wall.
You can become new patron by paying more than the previous one.
Added painter's palettes to library vendor. (Sprites by @Mickyan )
Backend changes:
Images are now stored in /data/paintings/images/*.png instead of /data/paintings/[category]/*.png
Old categories are now just tags
Screens & Video
Changelog
cl
add: You can now become patron of your favorite painting by buying sponsorship from Nanotrasen Trust Foundation.
add: Painter's palettes are now available at library vendor.
qol: Can use strokes in paintings now
/cl
Bring _HELPERS/_lists.dm to latest standards by:
-Adding proper documentation and fixing existing one
-Giving vars proper names
-Procs now use snake case as per standard (many files that use those procs will be affected)
About The Pull Request
Rewrites the entire preferences menu in tgui. Rewrites the entire backend to be built upon datumized preferences, rather than constant additions to the preferences base datum.
Splits game preferences into its own window.
Antagonists are now split into their individual rulesets. You can now be a roundstart heretic without signing up for latejoin heretic, as an example.
This iteration matches parity, and provides very little new functionality, but adding anything new will be much easier.
Fixes#60823Fixes#28907Fixes#44887Fixes#59912Fixes#58458Fixes#59181
Major TODOs
Quirk icons, from @Fikou (with some slight adjustments from me)
Lore text, from @EOBGames (4/6, need moths and then ethereal lore from @AMonkeyThatCodes)
Heavy documentation on how one would add new preferences, species, jobs, etc
A lot of specialized testing so that people's real data don't get corrupted
Changelog
cl Mothblocks, Floyd on lots of the design
refactor: The preferences menu has been completely rewritten in tgui.
refactor: The "Stop Sounds" verb has been moved to OOC.
/cl
## About The Pull Request
**Upgrades:**
- Yarn 3.0
- TypeScript 4.3
- Sass 1.37
- Required some refactoring of `/` into `math.div()` in CSS
**Dependency removals:**
- Removed ESM package, see: https://github.com/standard-things/esm/pull/902
I initially thought it was impossible to stop relying on this package, but fortunately, ES module support in Node 12+ now comes standard and I only had to convert the very few external module imports to `require()` (because Yarn PnP).
I also moved `logging.js` directly into `tgui-dev-server` package, because that's where it is used. One less internal dependency.
**Sidegrades:**
- Removed creation of a common tgui chunk, because in practice it creates unnecessary complexity (devs sometimes get a white screen due to this chunk being invalid) and doesn't really save that much data on CDN, and **definitely** doesn't make tgui load faster.
I think that is all. I tested it a bit and everything seemingly works.
