* cargobus, start of gloves
* basics of the HAUL gauntlets
* fully mapped in
* almost forgot the gauntlets
* ntnet improvements
* cargo gaunts, tablet cargobus
* excludes body bags
* dmis and map back
* readd icons
Clears out two deprecated explosions systems (explosion ids and explosion levels)
Refactors a bunch of contents_explosions procs to be maybe slightly faster.
Cleans up a bunch of ex_act code.
Slightly cleaner code
A few less unused vars on /atom and /turf
About The Pull Request
Adds a function to Siliconnect in which you can tap a borg using a mobile device that is currently running the software, and it will download the borg's logs. These logs list events such as being locked or unlocked, taken offline and being restored, and the process of being emagged. Borg logs will now list the emag user's name as a new user.
Downloading the logs is done by right-clicking the borg while the software is open and active. This will "tap" the borg with the device, initiating the log transfer automatically. The transfer will take eight seconds to complete, requiring you and the borg to stay adjacent the entire time, and the borg will get a large red text alert about the upload when it starts. The logs are also not stored permanently on the device, and will be lost if the app is closed.
This PR also introduces the tap() proc for modular computer programs, and adds functionality the the computers to call it when right-clicking with the tablet as a tool. Should the app use the tap in a meaningful way (such as starting a borg log download), it will return TRUE, and the computer will end the secondary attack chain.
Currently, this requires using a tablet or laptop with Siliconnect, as you cannot tap with a console. Someday I hope to add an additional hardware option for consoles in the form of a wireless hand scanner to replicate tapping.
Why It's Good For The Game
Adds a neat way to "diagnose" a borg acting oddly, assuming you have a way to keep them still. Allows one to view if the borg has been emagged, by whom, what SiliConnect messages the borg has received, the number of law changes that have been made, as well as some other (somewhat fluff) information relating to taking damage and getting upgrades.
Changelog
🆑
add: You can now download a cyborg's internal logs by right-clicking them with a mobile device running SiliConnect. Take a look if one is acting a bit strange, you might find something interesting.
add: Borg integrity (health) is now roughly shown in SiliConnect, under "Condition".
/🆑
To Do:
Fix the to_chat not being sent to the borg when a log transfer breaks due to distance
Add some sort of text feedback when tapping an atom with a device, or viewing one being tapped.
Possibly restrict syndicate borgs from having their logs viewed by SiliConnect (and likewise with station borgs and Roboverlord) Changed my mind on this, will implement later if we find it's needed.
Change the log area of the window to expand naturally rather than use a fixed height
image
I'm not super deadset on the emag user's name being listed. It seems like a neat function unique to having a tablet running Siliconnect (as most of the other info is already available through other means), and one can always pop the brain out for a re-borg and demand the name anyway.
* Fixes modular computer runtimes
- Adds a proc to eat the source arg of the update icon signal.
* Fixes a couple things not passing the right args
- Fixes the alien leap hallucination passing a string as the first arg to updat_icon
- Fixes the roulette machine passing the payout as the first arg to update_icon.
Creates update_name and update_desc
Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together
Less non-icon handling code in update_icon and friends
Signal hooks for things that want to change names and descriptions
99%+ of the changes in this are just from switching everything over to update_appearance from update_icon
Converts many proc overrides to properly use list/modifiers, fixes some spots where modifiers should have been passed, calls modifiers what it is, a lazy list, and cleans up some improper arg names like L, M, C, and N. Oh and I think there was a spot where someone was trying to pass M.name in as a string, but forgot to wrap it in []. I fixed that too.
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
About The Pull Request
This PR removes intents and replaces them with a combat mode. An explanation of what this means can be found below
Major changes:
Disarm and Grab intents have been removed.
Harm/Help is now combat mode, toggled by F or 4 by default
The context/verb/popup menu now only works when you do shift+right-click
Right click is now disarm, both in and out of combat mode.
Grabbing is now on ctrl-click.
If you're in combat mode, and are currently grabbing/pulling someone, and ctrl-click somewhere else, it will not release the grab (To prevent misclicks)
Minor interaction changes:
Right click to dissasemble tables, racks, filing cabinets (When holding the right tool to do so)
Left click to stunbaton, right click to harmbaton
Right click to tip cows
Right click to malpractice surgery
Right click to hold people at gunpoint (if youre holding a gun)
Why It's Good For The Game
Intents heavily cripple both the code and the UI design of interactions. While I understand that a lot of people will dislike this PR as they are used to intents, they are one of our weakest links in terms of explaining to players how to do specific things, and require a lot more keypresses to do compared to this.
As an example, martial arts can now be done without having to juggle 1 2 3 and 4 to switch intents quickly.
As some of you who saw the first combat mode PR, the context menu used to be disabled in combat mode. In this version it is instead on shift-right click ensuring that you can always use it in the same way.
In this version, combat mode also no longer prevents you from attacking with items when you would so before, as this was something that was commonly complained about.
The full intention of this shift in control scheme is that right click will become "secondary interaction" for items, which prevents some of the awkward juggling we have now with item modes etcetera.
Changelog
cl Qustinnus
add: Intents have been replaced with a combat mode. For more info find the PR here: #56601
/cl
You will now attack modular computers if you are not in help intent, rather than opening up their menu.
Why It's Good For The Game
i died here as nightmare because i couldnt attack the computer
Allows modPC programs to send alerts, and adds a proc in the computer object to handle playing the sound effect and sending a message to visible users. These notifications can be muted on a per-program basis. Programs can also set themselves to highlighted in the NTOS Main menu; this is intended to be used along side alerts, but really can be used any time a program wishes to tell the user there is new information.
NT CIMS (SM monitor) now plays an alert during SM delaminations if the app is closed. The app must have had an SM selected before closing, or it will not send alerts. Notifications are sent when the SM makes a radio alert. If the app is currently the active program, the app will instead send a notification just once, when the SM begins delamination, so as to not annoy engineers that are already aware of the issue.
Alright, this is a functional rework for civilian bounties, which should serve a few purposes:
Cargo has a reason to actually keep working and stay within cargo.
Makes cargo bounties far more integrated into the round as opposed to being a static list of soft goals, being personalized to those who would actually do a bounty for the station.
Still make civilian bounties the prime, sirloin steak method for regular crew to make money.
So here's the 4-11:
Static cargo bounties have been removed, in favor of the new system of civilian bounties. That means that both the bounties app and the bounty console have been removed.
Civilian bounties have been buffed. They are no longer affected by inflation, but when your bounty is completed, you will recieve a "bounty cube". To receive the cash you would have received for the bounty (10% of the civilian bounty), that bounty cube must be shipped off the cargo shuttle, and using the magic of the price tag component, you make your cut, and cargo makes their 90%, ensuring that you'll actually see your money (for once!).
Civilian bounties are now independent of department budgets, in preparation for departmental purchases, so now you can more freely benefit from doing civilian bounties to buy things! (See #53881)
Non-mining cargo department crew now have fully randomized bounties, to give them stationwide goals for bounty hunting.
As an added benefit, the icon for bounty cubes basically screams value, so hopefully crewmembers will see it and instantly think to sell it.
Alright crew, here's the 4-11. This adds a new Modular Computer app, that works functionally identically to the cargo console. but before we delve into that, lets hit the adjacent aspects first.
Cargo Packs now contain a new variable, access_view, that is only applied to cargo packs viewed in this app. It determines the access level required to be able to see those individual packs, in the same way that you need certain accesses to open certain crates anyway. This means that outside of certain inter-departmental crates that see overlap in who can/should be able to order it, heads can browse and purchase crates based on their department's needs and wants.
The cargo ordering console has been renamed on the DM side. Because now that there's another, similar cargo ordering DM that was going to get confusing fast, as just calling it "Console" gets on my nerves and is harder to spot on VSC for me and everyone going forward forever.
Cool, back to buying stuff. heads of staff can download the cargo ordering app on tablets and laptops only, and it gives them access to purchase cargo using their department funds. These purchases are made against the user's department budget, and enables purchasing supplies with cargo without needing to beg them to use their money on your junk, adding it fully to the cargo shuttle's next load, while still giving cargo the first right to refusal if they wanted to, for some reason.
From there on out, cargo's responsibility is primarily getting the goods you bought to you, which is technically already their job!.
Implements the ?. operator, replacing code like A && A.B with A?.B
BYOND Ref:
When reading A?.B, it's equivalent to A && A.B except that A is only evaluated once, even if it's a complex expression like a proc call.
add: Science has been given a more experimentally themed set of bounties.
del: Much of the old science bounties were discontinued.
del: ...As have the glass shard and cheese honker assistant bounties.
Splits the restrained() proc into component traits: TRAIT_HANDS_BLOCKED for the general inability to use hands and TRAIT_RESTRAINED for the more specific condition that permits arrests.
Code moved away from the update_mobility() proc so it doesn't have to wait for an update, instead changing based on events. The idea is to eventually kill that proc.
Wrapper proc added for setting the handcuffed value so we can react to the event of it changing.
Kills the RestrainedClickOn() proc. That is now just an UnarmedAttack(), in where the ability to use hands can be checked. Monkeys keep their bite attack and humans their self-examine.
All ui_act procs should call parent by default. All procs should preserve the value of the parent proc when it's TRUTHY and pass it down the call stack. No UI should be interactible when its flags or state indicate it should not be, except when explicity overriden by child procs intentionally disregarding parent return values to achieve a specific goal.
There exists a specific state where ui.open() can be called yet the
result would be a null window and such behaviour would be intentional.
The following CRASH in ui.send_asset() would thus be misleading,
because send_asset() was called after open().
This PR adds more information to the CRASH about when the failure state
can occur, makes open() return a value based on whether it actually
opened a new pooled window or not, and makes sure modular computer apps
don't send_assets unless a new pooled window was created.
As said by the title.
Also fixes an oversight where the Plexagon HR Core app (job management) was reading worn ID rather than inserted ID.
Also adds names to differentiate between primary and secondary card readers so both show on the screwdriver remove menu.
Also makes using IDs on a modPC actually call the InsertID proc, so that having the secondary ID come first in the list of parts doesn't give it priority.
Co-authored-by: Bobbahbrown <bobbahbrown@gmail.com>
* Process procs now properly use deltatime when implementing rates, timers and probabilities
* Review fixes
* Geiger counters cleanup
Made hardsuit geiger code more similar to geiger counter code
Geiger counters are more responsive now
* Moved SS*_DT defines to subsystems.dm
* Rebase fix
* Redefined the SS*_DT defines to use the subsystem wait vars
* Implemented suggested changes by @AnturK
* Commented /datum/proc/process about the deltatime stuff
* Send delta_time as a process parameter instead of the defines
Also DTfied acid_processing
* Dtfied new acid component
Replaces like 70-80% of 0 and such, as a side effect cleaned up a bunch of returns
Edit: Most left out ones are in mecha which should be done in mecha refactor already
Oh my look how clean it is
Co-authored-by: TiviPlus <TiviPlus>
Co-authored-by: Couls <coul422@gmail.com>
* Support for expansion-class modPC hardware
* end of the line
* As requested
Did anyone know that the tablet vendor was attaching the wrong ModPC printer? I bet no one knew that.
* update
Defined all the existing light_color values.
Moved their definitions to colors.dm
Made white the default color. It was so already, but that was very obscured.
Moved the atom light-related variables to the atom definition.
Wrapped changes to variables such as light_color into procs that report the event through signals.
Moved the light_on variable to the atom level, also adding a signal for its changing, to represent toggling lights.
Cleaned up a little bit of code in where new variables were defined before redefinitions.
This is all atomization to reduce changes in #52413
None of this affect gameplay at all, it's all code cleaning and refactoring.
There's more colors to standardize, a search for color = will find lots of targets, and I see little need to have both the LIGHT_COLOR and COLOR patterns, but I don't want to make this PR bigger than it already is.
* How did this take me like 3 hours but the bounty UI took 4 weeks like fuck
* Uses style's suggestions for UI cleanup.
* Rebuild TGUI
* Squiggly Brackets No. 1
* Squiggly Brackets No. 2
* Rebuilds tgui also sorry style I got lazy
* Another tgui update
* GREP?
* Rebuilds tgui again
* Rebuild yet again
* How'd you like a nice tender lambchop?
* Take me HOOOOOOOME country ROOOOOADS
* Updates with Anturk's changes.
* Removes unnecessary flex element
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
