Thread Rating:
  • 6 Vote(s) - 2.83 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[PR] Headlocking
#1
Information 
PULL REQUEST DETAILS



[INPUT]
About the PR
This PR has 3 major changes:
- As the title states, allows manufacturers and fabricators to lock their items behind Head access, requiring a Head ID card to be used on the machine to toggle the restricted items on and off. (Emags can also be used to turn them on, although not back off again.)
- Does that very thing for AI core frames at Robotics Fabricators.
- Adds two roundstart hint messages, one explaining the new mechanic ("Command personnel can use their ID on manufacturers to unlock restricted items."), the other explaining that it needs to be done in order to produce AI cores. ("To produce an AI core frame, you need a Head of Staff to use their ID on a Robotics Fabricator.")


Why's this needed?
I've asked around the Discord several times, and it seems like nobody likes AI cores being produced without a good reason, and yet it happens pretty frequently. As an AI main, in my experience, having more than two active AIs at a time (and sometimes, more than one) usually does nothing but create conflicts about law interpretations and cause general chaos. I've even heard legends of one round where there ended up being six, and it resulted in the entire silicon population giving up and quitting for that round.


Changelog

Code:
(u)Arahimine:
(*)Robotics Fabricators require a Command ID card to be used before they can produce AI frames.


PULL REQUEST DETAILS
Reply
#2
I'm disappointed this wasn't for putting people in headlocks.
Reply
#3
Honestly I was expecting headlocks too. I like additions to combat.

Anyways, this seems pretty good. I haven't seen much of the AI conflict myself, but requiring head access to make new AIs seems like a fair way to address that issue without outright removing constructable AIs or making it require more/rarer materials. I imagine the general framework of locking certain manufacturing recipes to head access would be useful for present and future manufacturable items too.

Oh, and it seems like it tells you if something is locked to Head access too? That's/That'd be pretty good.
Reply
#4
Yes. Good PR. Hopefully this fixes issues with like, six-AIs-who-all-spam-laws-every-5-minutes-and-have-a-mile-long-law-of-nothing-but-the-f-bomb-in-all-caps-because-robotics-thought-this-was-funny sorts of issues.

Not that that would ever happen...
Reply
#5
I kinda feel like aggressive grabs are kind like headlocking someone, since you go from that to a chokehold. or maybe not, idk.
Haven't looked @ code yet, but make sure that emag pops the head-restriction as well
Reply
#6
To the point of the actual PR. I don't understand why this is needed. Granted I don't play AI at all, but multiple AI's is always seems decently fun imo. But the only argument given is that it's not fun because it's too much chaos. I'd like to see a betterargument than that, because it's not particularly any more convincing to say, "it's not fun because of the chaos" compared to "it is fun because of the chaos".
Reply
#7
I WANT TO PUT SOMEONE IN A HEADLOCK
Reply
#8
I'm not personally a fan of this change. I'm the kind of roboticist that builds 6 late join ai shells and gives each one a cyborg shell. It makes things fun.
Reply
#9
There's been several times where it's been one of those shifts where a rampager has been clearing up a bunch of the station, all the headIDs are eerily missing, AI is dead, and even the commconsoles have been knocked out of commission or are being puppydog-guarded by a killer who has decided the shift may not end.

In those cases, heading to the Faint Signal with a pal and getting AI'd just to call the shuttle has been a last resort. It's been very fun to pull off every time.

I'd be sad if that were made impossible.
Reply
#10
After years of progressive changes to make it less difficult to replace the AI, this move is reactionary and Bad™ in my strong and uncritical opinion.
Reply
#11
In theory I like the idea of head access unlocking more dangerous manufacturer options that hacking alone can't get you, but I'll echo some others in this thread in thinking that AI core frames shouldn't be locked behind it.
Reply
#12
(10-25-2020, 11:40 AM)cyberTripping Wrote: In theory I like the idea of head access unlocking more dangerous manufacturer options that hacking alone can't get you, but I'll echo some others in this thread in thinking that AI core frames shouldn't be locked behind it.

That's how I feel about it too. I think using a Head Level ID to reduce restrictions would be a good mechanic to explore in other areas too.

Sort of a "Desperate times call for desperate measures" type deal, where the Head of a Department can make it easier for people to take action against something.
Maybe the Medical Director can turn off the safety measures for defibs and hyposprays. Sort of like opening the armory.
Reply
#13
(10-25-2020, 01:02 PM)Frank_Stein Wrote: Sort of a "Desperate times call for desperate measures" type deal, where the Head of a Department can make it easier for people to take action against something.
Maybe the Medical Director can turn off the safety measures for defibs and hyposprays. Sort of like opening the armory.

I think it's important to make sure that any head-locked items aren't just a buff for traitor heads. I feel like the sweet spot for head-locked items would be things that are too risky or dangerous to be made without oversight, but are not easily weaponizable. Something like non-whitelisted hypos would just mean giving the MDir a free new traitor weapon, in my opinion.
Reply
#14
Fan of generic framework for letting items be locked behind specific access (this would be a bit of a nerf to QM as things got locked behind it, which I'm very okay with because they have far too many things they can make already), not a fan of specifically making AIs harder to make.

If the issue is "multiple AIs is rough because of different law interpretations and getting bogged down in that", I think this won't solve the problem, just reduce how often it comes up and make some potentially fun interactions less common.

I would rather solve the "problem" of this by having either a) a hierarchy of AIs based by default on their creation order (to solve the issue of AI players on an even-footing not being able to agree on how to interpret a law) or b) let AI lawsets be distinct from each other (much bigger conversation about gameplay effect required) so that there isn't any need for the discussion and AI units are free to interpret their laws as they see fit.
Reply
#15
I'm going to have to jump in on this again. I like Mordent's idea about AI hierarchy as a potential compromise.

Overall I still want AI creation locked, at least on the RP servers. I am so disappointed by a recent AI round where multiple AIs were made without even mentioning it in any capacity, and the first one violated Law 1 and 3; we had a Law that overrode 2 and was secret, and they stated it on general comms and then bolted open external airlocks and airlocks leading to the hellburn. They told the people in upload to reset their laws. I had a specific shell made by the roboticist that was swiped and was not aware of that until I tried to deploy to it (after laws were reset) to fulfill a Law 2 request and help a salesman make a little marketplace. I found not only was it taken, but the other AI in it was using it to ignore the machinespeak channel request and instead kill monkeys in escapes. Part of this is ahelp-territory and sticking to the rules, but part of it is a total lack of care in any capacity for roundstart silicon players that I think people will continue to defer unless there is some sort of restriction on this.

That was the worst round I've ever been in. This isn't the first round playing AI that has become unmanagable, rules-flouting, and frustrating because of this specifc issue. Multiple AIs who aren't on the same page isn't fun at all.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)