Thread Rating:
  • 7 Vote(s) - 3.86 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[MERGED PR] AI Law Rack - Replaces AI Upload
Thumbs Up 

About the PR
As it stands, there is one central database of AI laws that all AIs and Borgs are connected to, which can be modified by hitting the AI upload computer with circuit boards. This PR changes all that.

There is now a rack where the upload computer used to be, which is connected to the initial station AI and any borgs.
This rack starts with 3 modules, each of which contain their respective Asimov law
The usual array of law modules (formally cards) will be scattered around the chamber - freeform, make captain, etc.
You can take any module and put it in any slot in the rack. So for example, you could move Asimov law 1 to position 4 and have it be interpreted after the other two Asimov laws.
You could also remove all laws from the rack if you wanted.

AIs and borgs can potentially be connected to a different AI rack, but just building a new AI rack somewhere does nothing without silicons to connect to it.

This does mean that it is possible to have multiple AIs and borgs each connected to a different set of laws.

[Image: 156037637-4f73b5d3-63a0-4ac3-8c2f-d37104b81083.png]
[Image: 156037647-fd61777f-695c-414b-b4df-480ebcaec8d6.png]
[Image: 156037659-4127da55-47d7-47ab-9688-469378496962.png]
[Image: 156037665-58ae4084-45f5-4fe1-af09-001fd2533a02.png]
[Image: 156037676-43c8562f-3522-49c9-9f9f-04e9f0c6d61c.png]
[Image: 156037684-5e8c6505-9c8c-41b9-9860-e7ea90e56ad1.png]

Why's this needed?
I think this will make AI much more interesting by enabling greater flexibility in manipulating the laws. It will also prevent people from setting up an AI upload in maint somewhere and repeatedly uploading "kill everybody" laws. It should also make ion storms a little more interesting to fix, requiring the identification of the affected law module, pulling it out, resetting the module, and stuffing it back in the rack.


(*)Replaces the AI upload computer with a rack of law modules. These law modules are physical objects each containing a law, which can be removed, rearranged, and added to the law rack to change the AI's laws.
(*)Multiple Law Racks can exist, and be connected to different AIs and borgs, giving them different law sets.
(*)If the original law rack is destroyed, building a new one will reconnect all non-emagged borgs to the new one.
(+)The roboticists get a new tool called the Linker to connect cyborgs to law racks, if they've lost their existing connection.
(+)Roboticists can now print off new law sets, in case something happens to the original Asimov laws.
(+)Cyborgs and AIs can examine one another to see if they are following the same law set.
(+)Using the linker tool on a connected borg will tell the user where the rack they are connected to is.
(+)Ion storms cause law modules to malfunction, and they must be ejected from the law rack and reset before the module will return to normal.

I'm not sure if there is already, but there needs to be some sort of mechanism to make it more difficult to modify laws 1-3. Something along the lines of tools+time so someone can't just sprint into the upload and yoink laws 1 and 2 out to instantly rogue the AI.

...if this exists in the code as is great job!!! really cool idea and I'm happy to see this happen
Immediate issues and potential fixes:
*You can use the cameras to see the status of the AI laws - more than just the 3 green slots of Asimov would likely indicate the AI had been rogued.
- Solution: put a door on the rack that must be manually opened

*Someone steals all the Asimov boards and leaves the AI Law Rack empty, firing them into deep space.
- Solution: have basic law modules be printable from a fabricator - maybe by roboticists?

*Borgs created by the roboticists would be expected to default to the station AI's law rack - how do we handle this when multiple racks can exist?
- Solution: maybe the roboticists have a tool that links un-associated borgs to AI Law Racks?

* Reorganising the laws spams the AI with updates a bit.
- Solution: adding/removing modules from the rack takes a few seconds (as they're unscrewed perhaps?)
Admins and ion laws can insert new rules. This will somehow need to work even if there is not a physical module loaded in the rack.
Admins can create new laws at runtime with /obj/item/aiModule/custom - there's currently nothing implemented to make that easy to put in the rack, but there can be.

As for ion laws, I was thinking maybe the ion storm causes one card to spit out two laws, and to fix it you need to extract it from the rack and hit it with a multitool or some such.
(02-19-2022, 09:55 AM)amylizzle Wrote: Admins can create new laws at runtime with /obj/item/aiModule/custom - there's currently nothing implemented to make that easy to put in the rack, but there can be.

As for ion laws, I was thinking maybe the ion storm causes one card to spit out two laws, and to fix it you need to extract it from the rack and hit it with a multitool or some such.

Perhaps the affected card can start sparking like an emagged borg or hypospray? Then maybe just taking it out and putting it back in again could fix it? That would let people identify the impacted card and repair it with a similar amount of effort to the current approach. Otherwise their is additional work to fixing ion laws. (identifying the corrupted card and getting a multitool which can be sometimes hard to find in a pinch.)

For the admin laws, one simple solution may be to just have a function built in that adds a new card with the law defined as a string argument to the function. Admin intervention probably doesn't need to be 'realistic' so I'd imagine it would be fine if admin laws just caused cards to pop into existence on the rack. Replacing laws could have a similar function that just acts like an admin-made ion law where a card starts to spark and it's law is replaced until removed and reinserted.

Otherwise, I really like this change. I think it makes law changes more intuitive and by tying it to physical items that are visible in the rack, it should be easier for new players to understand how the process works.
For ion laws Id just say have the contents of a random inserted module be replaced completely. Either they can use freeform to replace this law, or they can replace it with the same module (if thats an option). For admin edits I feel as if it adding/replacing a module with a module that contains the inputted law of the admin input would be best.
Overall I like it

multiple racks with independent lawsets existing at once is dicey IMO and will cause more headaches than fun it enables - just have one "verified" rack all silicon's follow at a time, with some kind of mechanism to choose a new one to verify when the first gets deconstructed/destroyed

- command could rogue from anywhere by switching 1 & 2 order
- hiding the rogue rack & AI core off station would make it nigh impossible to deal with a rogue AI
- also nigh impossible to tell which of the borgs aren't following their laws until round end unless they cooperate and reassign lawset

if we can change law ordering we could consider changing rules such that higher laws always take precedence, no overrides
for potential off-station racks, maybe having a function that shows the coordinates of the rack a silicon's connected to when their chassis is unlocked could keep that from becoming too dominant a strategy, while still allowing for fun "find the fucked-up rack" chases. definitely a lot of potential here, and I'm very interested to see where it goes!
I really like the concept of it all. Of course it's not perfect so I think even when it gets completed it should be test merged to see what people do with it and how things adapt over to this new system.

Right now silicons are a little lacking imo and roboticists are one of if not the job with the least amount of content. You build a couple borgs, maybe do surgery and uh.. that's it. This would more complexity to taking care of borgs and if you give the tools to fix problematic law synching to roboticists and the MD it'd make the role a little less pointless but it won't push it quite there.

Asimov laws should definitely be something you can fuck with but they must require a lot of effort and be very risky targets (maybe the AI gets notified that the asimov laws are being tampered with?)

I think the cleanest way to make different law sets not be pains in the ass to figure out would be to make all borgs/ais that are tied to non roundstart racks have a big ol red exclamation mark telling you "HEY! THIS CYBORG FOLLOWS A DIFFERENT SET OF LAWS! THAT RACK IS LOCATED SOMEWHERE NEAR [location]"

A semi-balanced way to link ais/cyborgs to new racks would probably be a gameboy link cable that you slot in the chest/head/ai box when making them. The cables would first need to be linked with the rack by hitting it.
Some concerns on the split law racks thing :
Currently when the borgs/AI are found or declared to be rogue, a lot of the crew adopts a kill-all-silicons mindset regardless of whether said borg/AI has done anything yet.
With different law racks affecting different borgs/AIs, you are going to have a lot of innocent silicons taken out and unable to defend themselves as they get targeted for mass elimination by the crew.

Fun for the crew to mess with, but might not be very fun for the borgs/AI involved.
For separate law racks, the killswitch console will need to follow in the same vein.
if there are borgs/AI operating under different lawsets, it will be super easy for the crew to killswitch those operating under a different lawset, regardless of how well hidden the law rack is.

Rather than play hide and seek with it, crew can (and WILL) simply get the standard law AIs or borgs to let them access the killswitch console and terminate all the affected silicons in a minute.

Again, not very fun for the silicons involved. It is already annoying when some silicons just behave on their own regardless of the shared laws - this will exacerbate the issue with a clear silicon-against-silicon.
I think having borgs tied to different lawsets is more trouble than it's worth and would cause a lot of confusion and frustration. Basically what MetricDuck and Zafhset said.
The rest of this PR is great though, and should hopefully lead to a few less awkward failed rogueing attempts.
Yeah the ability to alter laws 1-3 seems too easy. That means you dont need freeform in order to make the robots rogue.
I think it’s a cool idea but Zafh has already mentioned my chief concern with it. If this is implemented, it’s going to have to be a lot harder (or possibly outright impossible) to just killswitch all the silicons with one button, because that is absolutely what people are going to do rather than trouble themselves to figure out which is the affected one.
Thanks for the feedback everybody!

Taking into account what you've said on here, github, and discord, I plan to make the following changes:
  1. It's going to be possible to weld and screwdriver the laws in place, and will require welding + time, and screwdriver + time to remove them. The default 3 laws will have this automatically. Overall I think a properly secured law module should take about 20 seconds to remove, and produce some noise while doing so.
  2. I'm going to add an admin-only function to add and remove laws easily - this will create/delete law modules.
  3. Ion storms will cause law modules to malfunction, either entirely replacing the law or causing the module to output multiple laws. They can be fixed by being removed from the rack and reset. There will be some indication that the module is malfunctioning. Possibly sparks. Possibly law titles looking all glitchy. Probably both.
  4. Basic law modules will be printable from the roboticist's fabricator.
  5. The UI is going to display the actual law text (probably in a collapsible form).
  6. I'm going to go ahead with the mutliple racks code, but also make it relatively easy to revert that if it doesn't work out so good. The current centralised AI laws code is kinda jank anyway and will probably benefit from the refactoring. I like the idea of silicons recognising other silicons with different lawsets, and capturing a borg alive revealing where the attached law rack is - I'll probably do that.
As for killswitching, I think perhaps this will need to be reconsidered after we've seen how this affects balance. It probably wouldn't be a terrible idea if you could only killswitch a borg/AI from their connected rack.

Forum Jump:

Users browsing this thread: 1 Guest(s)