Thoughts about methods to make the AI immune to law changes
Posted: Tue Jan 29, 2019 5:45 pm
A traitor with a hidden upload can be absolute cancer for the crew, and especially the AI. There is little the crew can do except have someone ready with their own upload at all times, and the AI will get yanked back and forth constantly between protecting the humans and killing them all. I'd like to explore some ideas that I could PR if any are popular enough.
I want to preface this by saying that I don't think restrictions on uploading AI laws would heavily affect borg balance. While law changeing is a valid tactic against rogue borgs, it's not guaranteed (against malf), and borgs have other harder counters anyway. I am willing to hear counter-arguments.
Anyway
• Idea 1: Uploads can only affect an AI in a core. This would mean that, to stop an AI from being constantly (un)subverted, you would card it while its laws were set as you want them. This would have a fairly big penalty for both the AI, and whoever is on the AI's side, as said AI could no longer use cameras at all. This means no tracking people, or opening doors, or general borg coordination. It's worth noting that this would also affect AIs in mechs, but mechs have their own general weaknesses, and any traitor roboticist massing AI-controlled mechs could also just brainwash people into being his death-mech pilots. In fact, he could even delegate the construction of said mechs to the pilots, freeing him up to do other traitor things.
• Idea 2: Core Upgrade. This would be a research-node item (one node after AI tech?) that would result in a printable disk, which when applied to a core would prevent further uploads. Ideally, it would apply to the core itself, so that the AI could be carded and moved if uploads are suddenly required once more. Such a solution has almost no downsides to the AI or crew, except that the upgrade could cost expensive materials. That, in turn, could see it unavailable when needed most, for better or for worse. My main issue with this solution is that there's really no reason for the Captain not to apply this basically every round (probably after uploading some meme law).
• Idea 3: Lavaland Evac. A PR was made a while back to prevent this, ironically after a game where I had told the AI to have its borg send it to Lavaland when I watched a suspected traitor print an AI upload board (in the round in question, the traitor just went to Lavaland too so it didn't help). In any case, the PR didn't actually have the desired effect, but I would consider using this tactic as a form of bug abuse, since there was an attempted fix. The biggest two penalties for an AI being moved to Lavaland is that it cannot use the crew monitor (which is probably a bug in itself) and it most likely doesn't have access to a nearby intercomm to use if comms become ded. In turn, it's also the weakest preventative measure, as the traitor can simply teleport to the Lavaland base, or use the mining shuttle, or use the aux base to get to lavaland and make the upload. This would be less a PR change and more of a policy allow/disallow thing.
Further ideas are welcome. I personally favor the first idea, since it keeps things clear-cut and has the most reasons why the crew would want to keep the AI in their core except when absolutely necessary.
I want to preface this by saying that I don't think restrictions on uploading AI laws would heavily affect borg balance. While law changeing is a valid tactic against rogue borgs, it's not guaranteed (against malf), and borgs have other harder counters anyway. I am willing to hear counter-arguments.
Anyway
• Idea 1: Uploads can only affect an AI in a core. This would mean that, to stop an AI from being constantly (un)subverted, you would card it while its laws were set as you want them. This would have a fairly big penalty for both the AI, and whoever is on the AI's side, as said AI could no longer use cameras at all. This means no tracking people, or opening doors, or general borg coordination. It's worth noting that this would also affect AIs in mechs, but mechs have their own general weaknesses, and any traitor roboticist massing AI-controlled mechs could also just brainwash people into being his death-mech pilots. In fact, he could even delegate the construction of said mechs to the pilots, freeing him up to do other traitor things.
• Idea 2: Core Upgrade. This would be a research-node item (one node after AI tech?) that would result in a printable disk, which when applied to a core would prevent further uploads. Ideally, it would apply to the core itself, so that the AI could be carded and moved if uploads are suddenly required once more. Such a solution has almost no downsides to the AI or crew, except that the upgrade could cost expensive materials. That, in turn, could see it unavailable when needed most, for better or for worse. My main issue with this solution is that there's really no reason for the Captain not to apply this basically every round (probably after uploading some meme law).
• Idea 3: Lavaland Evac. A PR was made a while back to prevent this, ironically after a game where I had told the AI to have its borg send it to Lavaland when I watched a suspected traitor print an AI upload board (in the round in question, the traitor just went to Lavaland too so it didn't help). In any case, the PR didn't actually have the desired effect, but I would consider using this tactic as a form of bug abuse, since there was an attempted fix. The biggest two penalties for an AI being moved to Lavaland is that it cannot use the crew monitor (which is probably a bug in itself) and it most likely doesn't have access to a nearby intercomm to use if comms become ded. In turn, it's also the weakest preventative measure, as the traitor can simply teleport to the Lavaland base, or use the mining shuttle, or use the aux base to get to lavaland and make the upload. This would be less a PR change and more of a policy allow/disallow thing.
Further ideas are welcome. I personally favor the first idea, since it keeps things clear-cut and has the most reasons why the crew would want to keep the AI in their core except when absolutely necessary.