* Makes flags properly check themselves
Byond ref: https://www.byond.com/docs/ref/#/operator/&
Basically, flags should use & instead of ==
We can have more than 1 slot on any item, so it's preferred that we do this instead. Even if it doesn't immediately fix any problems, it's something that should be the standard anyways to prevent it from ever being a problem.
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
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>
Experimentor no negative temperature.
Simplifies the cold and hot air interactions with the experimentor. Removing a portion of the air and heating or cooling it, then merging it has no difference than just heating the air, as the heating or cooling is purely energy based.
Adds max check for experimentor cold air reaction, to prevent negative temperatures.
* boxes change material content with ammo remaining
+ fills in custom_mats for printable ammo
+ makes equation for changing material content work
+ fixes printing cost for two boxes
* fixes ammo boxes being almost universal
fixes fail message to properly work
used to only use "can't fit any more",
now properly uses "no equipment can use this ammo"
* Uses update_appearance instead of update_name
* Basic outline for Bartender RCD
* Alphabetically sorted drink and booze dispenser reagent lists
* Added soda/booze synthesizers to the service plumbing constructor
* name change
* Syntax Error fixing
* Name and research updates
* Updated constructor selection
* Mixing chamber sister class
* brewery RCD redo again
* Custom Mixing Chamber UI
* Finalized plumbing reskins
* Allowed the service techfab to print chemical recipient boards
* added test sprites and removed un-needed renames
* Last Rename
* leftover whitespace fixes
* more whitespace removal
* one more name update
* refactor for upstream
* fixing TGUI i broke
* last whitespace fix
* last last whitespace fix
* please have this fix the whitespace
* updated doc comments
* updated ui_data and ui_act procs make more sense
* Update code/modules/plumbing/plumbers/reaction_chamber.dm
Co-authored-by: lex <alexdpow@gmail.com>
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
Removes the "used" variable from the sepia/timefreeze cameras. This does not increase the camera's film capacity at all, but they can be refilled for another single shot using camera film.
* Automatic R&D sync
* One second instead of a half-second
* Moth changes + more
- Actually use SIGNAL_HANDLER
- Use update_static_data_for_all_viewers instead of only updating static data for the current user
* Batch techweb updates
About The Pull Request
Reorganizes the entire icons/mob folder.
Added the following new subfolders:
nonhuman-player (this was initially just called "antag", but then I realized guardians aren't technically antags)
simplemob
silicon
effects (for bloodstains, fire, etc)
simplemob/held-pets (for exactly that -- I wasn't sure if this should go in inhands instead)
species/monkey
Moves the following stuff:
All human parts moved into species, with moth, lizard, monkey, etc parts moved to corresponding subfolders. Previously, there were some moth parts in mob/species/moth, and others just loose in mob. Other species were similar.
icemoon, lavaland, and jungle folders made into subfolders of simplemob
All AI and silicon stuff, as well as Beepsky et al. into the silicon folder, simplemobs into the simplemob folder, aliens into the nonhuman-player folder, etc.
Split up animal_parts.dmi into two bodyparts.dmi which were put in their respective folders (species/alien and species/monkey)
Code changes:
Filepath changes to account for all of this
Adds a check when performing surgery on monkeys and xenos, because we can no longer assume their limbs are in the same file
Turns some hardcoded statues and showcases that were built into maps into objects instead
Things I'd like to do in the future but cant be assed right now:
Remove primarily-antag sprites from simplemob/mob.dmi (Revenant, Morph, etc.) and put them in the nonhuman-player folder
Split up mutant_bodyparts.dmi into different files for Tizirans, Felinids, monkeys, etc and put them in their own folders. Those may have once been meant primarily for mutated humans but that's now how they're being used right now.
About The Pull Request
Title
Nerfs it by eight times
Currently papers can make several hundred thousand of credits if done right. This rectified it to be somewhat nearer the old 50k. Just take the gain amount in experiments.dm and multiply it by 125 for the money obtained for a middle of the road experiment. Multiply it again by two if the experiment is really good. Multiply it by two again if people chose the ghost writing partner.
So this means doing the absolute best experiment, hypernob, at the absolute best state (120 gain * 2 = 240), with money partner (240 * 2 = 480), will give 60k to the department. Much more sane number and happens the be similar to the old 50k.
A middle of the road experiment like BZ will give somewhere around 3-10k, doing the absolute absolute best for BZ is ~30k.
Why It's Good For The Game
Numbers are a bit wack on the original conception. This is probably a bit more in line with other methods of money generation.
Changelog
cl
balance: nerfs scipaper paper publication money across the board
balance: nerfs scipaper ghost writing partner.
/cl
About The Pull Request
Shadowpeople
brain now holds their healing properties.
while possible to extract the brain and put them in another species, the burn-in-light downside really makes it a lot more worth it to just stay a shadowperson and enjoy their other benefits than to swap.
Now use burning eyes from nightmares instead of an unsprited nightvision granting eyeball.
surgery.dmi split up
surgery_ui.dmi holds zone selection ui things for research
surgery_tools.dmi holds surgical tools
/organs folder holds organs.dmi, and species specific organ files for flies and shadowpeople
flies don't put in their random organs because of dmi memes, all their UNIQUE organs will be in the .dmi
Why It's Good For The Game
moving behavior onto the organ moves us closer to species as a blueprint, not species as something that magically grants immutable bonuses.
surgery.dmi is poorly described, holds many different things, and conflicts often because of it.
Changelog
cl
add: Shadowpeople now heal from their brains! Their brain-tumor-thingy!
code: split up surgery.dmi
/cl
About The Pull Request
Deletes /obj/shapeshift_holder, replaces it with /datum/status_effect/shapechange_mob
Refactors Heretic worm form into a shapeshift spell
Refactors Wabbajack, and associated code
Fixes#69117Fixes#65653Fixes#59127Fixes#52786
Why It's Good For The Game
/obj/shapeshift_holder was one of the worst remaining abuses of /obj direct subtypes, so I replaced it with a cool fancy datum.
This also decouples the shapeshifting behavior entirely from the shapeshifting spell. So we have support for shapeshifted mobs not sourced from a spell. Which is neat, we could technically swap Wabbajack to use this in the future.
Changelog
cl Melbert
fix: Wabbajacking a shapeshifted mob no longer runtimes horribly. When a shapeshifted mob is wabbajacked, they'll now be removed from their shapeshift and stunned.
fix: Transforming via a shapeshift should no longer rob you of your hearing / runechat awareness.
fix: Shapeshifting plays nicer with holoparasites.
fix: Being polymorphed from a xeno to a non-xeno correctly makes you a non-xeno
refactor: Refactored shapeshifting, the shapeshift holder is now a status effect instead of an object.
refactor: Heretic worm form is a shapeshift spell now, this might have some minor behavioral changes but should overall be the same.
refactor: Refactored Wabbajack (+ cursed pool). Overall a bit more clean / consistent behavior.
/cl
About The Pull Request
Everyone has been asking: "When will there be an anomaly like the bioscrambler, but for the space station? Please, we need more things which replace objects with different objects from the same typepath."
Well I made it and it looked like ass because non-tiling floor and walls look terrible, so then I made this instead.
Dimensional.mp4
The "dimensional anomaly" shifts matter into a parallel dimension where objects are made out of something else.
Like the Bioscrambler anomaly, it does not expire on its own and only leaves when someone signals it or uses an anomaly remover.
When it spawns it picks a "theme" and converts terrain around it until it covers a 7x7 square, then it teleports somewhere else and picks a new theme.
A lot of these themes are relatively benign like "meat", "fancy carpet", or "gold". Some of them are kind of annoying like "icebox" because it creates floor which slows you down, or "clown" because bananium is intentionally annoying. Some of them are actively dangerous, mostly "uranium" and "plasma".
The main problem this will usually cause for crewmembers is decreasing area security. When it replaces doors it replaces them with ones which don't have any access control, and it will also replace RWalls with normal and much more vulnerable walls which will make breaking and entering significantly easier until someone has taken the time to fix the damage. But also sometimes it will irradiate them, you never know.
The fact that sometimes the changes are benign (or provide uncommon materials) and might be happening in places you don't care about access to might encourage people to push their luck and leave it alone until it starts turning the captain's office into a bamboo room or repainting medbay a fetching shade of flammable purple, which I would consider a success.
Armour.mp4
If you successfully harvest the anomaly core you can place it into the reactive armour to get Reactive Barricade Armour, which shifts your dimension when you take damage and attempts to place some randomised (not terribly durable) objects between you and hopefully your attacker (it really just picks up to four random unoccupied tiles next to you). If you're EMPed then the changes it make to the environment will often be as unpleasant for you as they are for a pursuer, and significantly more likely to harm both of you rather than just provide obstacles.
Other changes:
I split anomalies out into their own dmi file, seems to be all the rage lately.
I moved the anomaly placing code into a datum instead of the event because I wanted to reuse it but if you have a better idea about where I could have put it let me know.
This also fixes a bug where the material spreader component wasn't working when I applied plasma materials to something, the extra whitespace was parsing as another argument for some reason and meant it would runtime.
Supermatter delamination was still pointing to Delimber anomalies instead of Bioscrambler.
tweaks the colors on the security modsuit to be lighter, i think i did that on the original pr but it got reverted due to merge conflicts
makes the standard quick carry module have nitrile level carrying instead of latex level
environmental bodybags are now always pressurized
adds medical and security hardlight bags, which are environmental bags you can use to move people through space, security ones can be sinched to prevent escape
adds a medical version of the prisoner capture module, for patient transport, prisoner capture and patient transport now use the medical/security holobags, medical one deploying them faster. when you move too far out of range the holobag dissipates
adds a defibrillator module, extends shock paddles
adds a thread ripper module, this module temporarily rips away the matter of clothing, to allow stuff like injections, surgery, defibrillation etc through it
adds a surgery processor module, essentially a portable surgery computer like borgs have
fixes a bug where you can unwield defibrillator paddles just after starting the do_after to defib onehanded
fixes a bug where the modsuit gps would have a broken name when renamed
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
Fixes issues with coffeemakers, as detailed in #69344:
Adds coffeemaker boards to the techweb.
Readds sprites for coffee cartridges, which were lost due to merge skew with
Adding tempeh (tem · pay) #68359.
Fixes the in-map-editor sprite, which was set to an invalid value.
The others were either unreproducible (I attempted on live, and could not find an issue that lead the coffeemakers to not work) or are simply not something promised in the original PR (they were deliberately not added to maps to avoid the otherwise inevitable map merge conflicts that would arise, and the sprites are the best I can personally muster).
refactor: A bunch of things that used to not do anything (or just fall back on the chest) when targeting a limb that someone was missing will now be far more likely to attack another limb!
* - Fixes storage mass transfer
- Brings some sanity to storage procs
- Implements a griddle feature that never was
* Uncomment this
* Right-click attack fix
* Scoop fix
* Smartfridges use silent
* Restores some lost checks
* Fixes storage implants
* First draft on this branch. Should work.
* Whoopsie
* Some fixes
* And again
* Final draft, question mark?
* Please enter the commit message for your changes
* Uhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
* please work
* Saving for the week offline
* Final draft
* Final final draft
* Oh and clean this up
* eah
* Okay, final for real.
* I lied.
* Sure thing boss
* clinclin
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* That's all of em I think
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Makes trapdoors player-craftable.
Player-crafted trapdoors have a tiny outline as well as being visible on examine. (Mapped in trapdoors have conspicuous = FALSE by default)
Trapdoors can be made by using a trapdoor kit (crafted via player crafting menu) on openspace.
Trapdoor electronics / assembly can be made via autolathe or engineering lathe.
A preloaded trapdoor remote (optional) can be made by crafting the electronics with a compact remote (from science lathe / circuit lab) and some cable coil.
Also allows unlinking trapdoors via a multitool, decreased trapdoor link range, and made some changes to trapdoor code.
Added change: Trapdoors now don't break with just a crowbar
Why It's Good For The Game
Trapdoors currently can only be added in by mappers and this would allow for a lot of interesting contraptions, while having player-crafted trapdoors be detectable provides some counterplay
Picture
trapdoorlookdemo
Changelog
cl
add: You can now make trapdoors. Craft a trapdoor kit and use it on an openspace tile to make one, then link and activate it with some trapdoor electronics (printable at an autolathe or the engineering lathe) and optionally a trapdoor remote (crafted in personal crafting menu).
qol: You can now unlink trapdoors by using a multitool on them.
balance: Trapdoors now won't break if you just crowbar them. You need to block them from closing, such as with a lattice, cover it up with a wall, or fully destroy the floor tile its on to get rid of them.
/cl
About The Pull Request
second part of #68417, which splits the suits.dmi, but this time focuses on obj items. everything stated in that pr applies to here aswell, it follows the same categorization.
Why It's Good For The Game
finishes the much needed splitting of suits.dmi, easing the minds of spriters everywhere and lowering the probability of future pr conflicts in this area
Adds keyboard shell.
Works very similar to the thought listener component for BCIs
It opens up an input panel when you use it (tgui_input_text)
Players with the illiterate quirk cannot use this shell. When they try to use it they get a warning message.
It's printed out as assembled (like compact remote or controller)
It can fit in a bag but not in a box
Has small capacity (SHELL_CAPACITY_SMALL)
Available after researching the Advanced Shells tech node
Can be printed from the component printer or the protolathe
Costs 2000 glass and 10000 iron sheets to print (slightly more than the controller shell)
Has 3 outputs. First one returns the entity who used the shell, second is the text that entity wrote and submitted, third one is triggered after the input window is closed. (by submitting, cancelling or just hitting the X button)
Icons (screenhots from the dream maker)
* 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
* Removes ComponentInitialize()
Completely removes ComponentInitialize() as a proc, which was called on every single atom in the game, twice in some instances (like new players), over something that can already be done with Initialize().
This is the second attempt at doing this, after the first attempt fell apart for some reason. This time it was way easier though, since storages are no longer a Component.
* update icon blocker added before calling parent
* Update code/game/machinery/porta_turret/portable_turret.dm
Co-authored-by: san7890 <the@san7890.com>
* adds a mapload while I'm here
* moves human mood
* Does some UNRELATED thing to the PR
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
About The Pull Request
replaces a ton of log_game with user.log_message so the log is added to individual and global logs.
adds a few logs for individual LOG_VICTIM, LOG_ATTACK etc logging.
adds logging for bluespace launchpad's tele coords being changed.
took the word "has" out of log_combat, as it's extra and just lengthens the log.
Why It's Good For The Admins
It's extremely laggy to open game.txt so an alternative is individual game logs
Changelog
cl
admin: A lot of game logs will now also be in individual game logs, for convenience in log diving.
admin: Added logging for bluespace launchpad x and y offset changes, which go to individual game logs.
admin: Attack logs will now be slightly shorter, one useless word was removed.
/cl
JohnFulpWillard
Member
JohnFulpWillard commented 23 days ago
About The Pull Request
Merges ordnance data disk and frontier data disk, since the ordnance data disk's description says it is for ordnance-related stuff, yet doesnt have the main app people need to do Ordnance, which I found weird.
I additionally moved the NT Frontier app to the rest of the programs folder, and renamed it Frontier so it is easier to find.
Why It's Good For The Game
This allows the semi-public ordnance data disk (as they are found in vending machines) to actually contain the ordnance app it claims it provides, making it easier for an Atmospherics Technician (or anyone, really) to get the app needed to upload gasses they make, as experiments for their nodes.
This makes it easier for Engineering to do Engineering-related experiments to get Engineering-related tech nodes, much like Medical can by doing Dissection surgeries, while also giving more use to the Frontier's ability to put authors, since now Science and Atmospherics can see eachother completing experiments and maybe even try to outdo the other.
Changelog
cl
balance: Ordnance data disks now have the Frontier app on them, and has entirely replaced Frontier data disks.
/cl
* 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>
