Jump to content

[Ron] Repost: Malf AI improvments


Recommended Posts

Posted

Some of the oldies may have seen this before, but I'm reposting it now, along with some extra new ideas.

------

Blue screen APCs = Malf.


This is an concept that is so hard-wired into the typical SS13 player it is impossible to separate from them from it realistically, no matter how much you push not metagaming. It's ingrained, obvious, and it doesn't matter if there is a random event that sometimes causes bluescreened APCs. It's just going to happen, random people will begin reporting them, and from there it is a slippery slope to the malfunctioning AI having someone in their core uninvited because 'they suspect system corruption'.


This mechanic is a legacy of an older version of Malfuctioning AI, where you had to have a specific number of APCs under your control in order to blow the station, and things were much more simplistic - there had to be a way to notice the AI doing it's thing before the station exploded, or you were screwed. It was extremely fast paced compared to the much more moderate hour and a half or often MORE process that is involved with NewMalf. With the increased complexity of new-malf, more complexity needs to be added to the process.


Malfuctioning AI need to have more breathing room, as the assault on their core should not be starting until they take overt, obvious action. I have worked out a general idea for this, but critique is welcome.


1) Blue Screened APCs: These should stop happening, at least initially. Make the error report for the APC visible only to people actually opening up the APC interface. People randomly passing by should not see a bright overt flashing APC error. Something like, "Interface error: Unable to accept commands" when they try to toggle something. It may be more reasonable for the bluescreened APCs to start happening after the Override command begins. When this happens, all hacked APCs bluescreen immediately, and more of them begin to as the station is taken over. At this point, the AI is on full assault, there is no subtlety. The APCs are being brute forced and used outside of their manufactured purpose.

2) In the defense of engineers, the current 'counter' to bluescreened APCs is very unintuitive: You must tear down the entire APC and build a new one. I propose some method of troubleshooting 'malfunctioning' APCs, like a tool you use on it that debugs it or perform a full reset on the hardware. It should take a while to do this (ideally more than the 60 seconds it takes to hack it, because they're not a super powerful AI), and then the APC is fixed. This will lower some of the alarm caused by having to literally destroy an APC to fix it (wow, this APC was really fucked up and this concerns me!), and make it streamlined more into a general troubleshooting thing. This tool will cease to work during the Override stage when everything bluescreens, thus furthering the evidence that something bad is going on.

3) Make recalling the shuttle possible even during override, if you have the upgrade or ideally, let the override be stopped at will. Keep in mind starting override can carry a high processing cost, making spamming it on and off unfeasible. However, having a full 10+ minutes where you are unable to utilize any malfunction commands is devastating, and actually can cause the round to end early because of shuttlecall spam you can no longer stop. Alternatively, rework how shuttle calls function to limit shuttle spam like forcing them to contact the Odin or call an ERT - people shouldn't be doing tug of war with the malf AI. It's not fun for anyone and is kind of immersion breaking.

4) The manipulation tree has some useless stuff in it. The biggest offender is "Electrical Pulse.". The only thing this does is randomly blow some lights somewhere on station, anywhere, with a tiny chance of breaking an APC in the process. This INCLUDES your core APC, so it is actually possible to accidentally kill yourself using this ability. Considering that even when NOT malfunctioning you can 'overload lighting circuits' on any APC on the map, with far more precision and less risk to the station and yourself, this ability is almost useless. Proposed replacement: This tree seems to mainly involve hijacking various nonencrypted station subsystems and machinery. One of the biggest weaknesses of the AI is that people can hold conferences off-radio and plot to kill it without its knowledge. It can use intercoms to listen in, but this suffers from two major problems: First, every intercom on station has a sharply limited 'hearing' range, of about 2-3 squares. Second, it's impossible to do this covertly, because all someone has to do is click on the intercom and see that it's set to a strange station, and they instantly know the AI is responsible and disable it, running out of earshot or watching it like a hawk to see if it turns itself back on. My proposed solution is to allow malfunctioning AI to utilize the sensors on the AI holopads covertly. I know they're on there - when you activate the holopad, you can hear and see everything around it as if you were standing on that spot as a regular mob. The problem is it is impossible to use them without activating the holopad and alerting everyone in the room you are present and listening. This is a fine safety protocol for normal AI, but there is no reason why a malfunctioning AI should follow safety or privacy procedures.

5) The interdiction tree is missing a key element that used to be in old Malf - the ability to hack IPCs. I don't know where this should show up on the tree progression. But I feel it should be a thing again. If you can remotely hack unlinked borg to bind them to you, and even hack other AI units, IPC should be susceptible too. Perhaps replace Hack Cyborg with the more broad "Hack Synthetic" (AI should still be their own tier at the top), and/or auto-hack IPCs who finger your hacked APCs.

6) The networking tree could use a tuneup - instead of making 'hack APC' the first tier of it (and thus a required first step for all malf), make it an entirely separate, singular research you have to do before you can do anything else (or just make the AI have it by default?), and add a replacement ability somewhere in that Tree, like being able to move your AI's core to any hacked APC during emergencies.

7) Hack Camera needs to be done more intuitively. Currently (I think?) it only works with any effectiveness by right clicking on the camera and selecting 'hack camera' This works file, until crew members begin smashing every camera in sight. Since one of the functions of 'hack camera' is to reactivate a camera, it is somewhat difficult to hack a camera you can no longer see due to it being disabled. Usually I end up having to waste time and resources giving a nearby camera xray vision just to see the camera so I can click on it. That's really silly and roundabout. Maybe something like a special interface similar to what the security cameras computer has, that shows you all cameras and broken ones are greyed out.

8) This is hypothetical and kind of vague, but a new (or several new?) kind(s) of additional Tree to used as an alternative to the override - it's high cost and research times for end stuff will be comparable to override, forcing you to pick an option between the two. But, hypothetically, a tree more about synthetic superiority than destruction and control of the station itself, like being able to reset borg models to default again and/or unlock secret malf borg models, prevent RD-console detonation of your borgs, Perhaps even a way to turn your core into a mobile weapon's fortress, I don't know, I'm spit-balling here.

9) A way to hack in access to the telecomm sat's turrets, bypassing the 'firewall'?

Posted

Agree with all of these.


Also think that CPU generation should probably scale with the current server population, as the MalfAI has very limited inherent scaling capabilities.

Posted

I have some ideas how to generate CPU Points without APCs.

We have have quite a few modular computers on the station.


It should be quite possible to allow the AI to spawn a process on their that generates CPU Points for the AI (amount depending on the other programs that are running, the processor, ...)


And then there is stuff in another project I am working on that could allow something simmilar

Posted

Hmmmm. I generally agree that malf could use an update, and most of these suggestions are fine, but I take a bit of an issue with hacking IPCs. I don't think turning them into slaves is very fun for the players playing them. Maybe make it work a bit more like a vampire dominate command, in which the AI enters an executable line into their code that they have to execute then and there, before their systems purge it back out.

Posted
Hmmmm. I generally agree that malf could use an update, and most of these suggestions are fine, but I take a bit of an issue with hacking IPCs. I don't think turning them into slaves is very fun for the players playing them. Maybe make it work a bit more like a vampire dominate command, in which the AI enters an executable line into their code that they have to execute then and there, before their systems purge it back out.

 

This was admittedly originally written before Skull introduced his vampire update, so it was working off the original concept of hacking ipcs, where they get law-slaved to the AI. Being lawed as a synthetic is pretty normal and people play borg all the time without saying it's no fun, so I'm not really sure why you think doing this would suck all the fun out of being an IPC? This is an argument I see brought up a lot by people who see the idea of a 'control other character' ability and began to claim that sucks all the fun out of the round for them, and I really don't agree with that.


But either way, giving them a single command is a potential solution too, assuming it works like the dominate effect and they don't remember it was due to fingering that APC... but I feel I should point out that the dominate ability is something easily available to vampires pretty quickly down their blood-drain abilities, and furthermore is an ability that you actively use on someone you are interacting with personally - you select the ability, type a command to issue to them, then it is issued. Hacking someone who is performing an action on an object you have previously claimed but may not necessarily be looking at is a much more passive process. How long does it take for an IPC to charge? Are you supposed to get a notification the IPC is charging from your APC is X location, move your camera over there, see what's going on in the area, come up with a command to give them, type it out, and issue the 'hack' all in the time it takes them to charge before they move away? A real AI might be able to do that, but a player needs time to think and examine the area for potential chaos and we work at meatbrain speed. You could set a generic command to be auto-hacked into any IPC who charges from your APCs, but then it would be something you couldn't make personalized, limiting it to things like 'cause general chaos' or 'kill all humans', which DEFINITELY isn't as fun, for anyone involved.


In this case, lawing the IPCs really does seem the most workable course for this ability, because it doesn't require active participation of a player who is capable of having vision anywhere on the station at any time and may be busy with many things already. Of course, I might be missing some way the dominate effect could be workable.

Posted

The biggest problem I'd have with "slave-lawing" the IPCs is that I don't see a way to un-slave them afterward, and the fact that they generally just become a downgraded borg. Also, with what I meant by "like the dominate command", it meant that it would be wireless, AKA no APC needed, and just essentially can be done without the target standing still, but at a bit longer cooldown that the vamp dominate, what with the AI being all seeing and everything. Or, you could add a bit of a generous buffer between an IPC charging and leaving the APC. Just saying that permanently slaving IPcs is a bad thing because, people wanna play robots without being slaves like borgs. Pretty sure that's the reason I would play an IPC anyway.

Posted
The biggest problem I'd have with "slave-lawing" the IPCs is that I don't see a way to un-slave them afterward, and the fact that they generally just become a downgraded borg. Also, with what I meant by "like the dominate command", it meant that it would be wireless, AKA no APC needed, and just essentially can be done without the target standing still, but at a bit longer cooldown that the vamp dominate, what with the AI being all seeing and everything. Or, you could add a bit of a generous buffer between an IPC charging and leaving the APC. Just saying that permanently slaving IPcs is a bad thing because, people wanna play robots without being slaves like borgs. Pretty sure that's the reason I would play an IPC anyway.

 

Hm. I think the best option would be sorta flavoring it as they get a virus when they finger your APC, and you have like, 2 minutes or so to issue a command to them with the handwavey assumption that's what the virus uploads into their code and it took a while to affect them, and if you are too slow it just handwaves away that it didn't take. I don't think just right clicking on them and issuing a command any time would work - I remember someone, probably Nanako, previously saying that IPCs do not have network access, so you would have to hack them with a physical connection.

Posted

Yeah I'm not too up to date myself on IPC lore, and I don't have a whitelist on them, but as far as I can see that would be a good solution. Just nothing too permanent, there's adifference between borgs and IPCs for a reason after all.

Posted

Kaed, why not try making some of these yourself? Having a goal to work on can help with learning to code.


Why not try coding a function for the Debugger tool to fix broken APCs. Its a thing that can occasionally spawn in cargo, but it could be added to engineering or science.


We're all quite aware that these things need done but most of us are just too busy with other things. Most members of the dev team have 2-3 large scale projects we're backlogged on. Nobody seems to be getting around to malf AI stuff just now


Anyone is allowed to submit Pull requests to our codebase, we can help with compile errors and getting stuff working

Posted
Kaed, why not try making some of these yourself? Having a goal to work on can help with learning to code.


Why not try coding a function for the Debugger tool to fix broken APCs. Its a thing that can occasionally spawn in cargo, but it could be added to engineering or science.


We're all quite aware that these things need done but most of us are just too busy with other things. Most members of the dev team have 2-3 large scale projects we're backlogged on. Nobody seems to be getting around to malf AI stuff just now


Anyone is allowed to submit Pull requests to our codebase, we can help with compile errors and getting stuff working

 

That's a nice idea, but I haven't the foggiest how I could go about coding such a thing. The most I've ever done in dream maker is make a shitty walkabout map with a stick figure. I don't know the code I'd be working with, much less what I'd be doing with it.

  • 1 month later...
Posted

Hmmmm. I generally agree that malf could use an update, and most of these suggestions are fine, but I take a bit of an issue with hacking IPCs. I don't think turning them into slaves is very fun for the players playing them. Maybe make it work a bit more like a vampire dominate command, in which the AI enters an executable line into their code that they have to execute then and there, before their systems purge it back out.

 


Pls stop speaking for IPC players

im personally 500% okay with being hacked completely

Posted

I've actually wanted a way of having my IPC's get influenced by malf AI's but there's just not a convenient way of coordinating it. A system for it would be great, and I'd be interested in any interaction like that, same as paradox.

Guest
This topic is now closed to further replies.
×
×
  • Create New...