Securitrons Need to be Patched

[Chayot]

Security-robots have done great, I really like them both as SEC and a criminal/antag.
They're not TOO hard, but definitely make me run when I see them.

The only problem comes around when someone decides to spam ~10 at a time and of course they swarm criminals.
Even at that, it's really funny seeing them zip around the station to no apparent goal and as a criminal I just put away my contraband and they pass along peacefully.

I would think the attack-on-move thing (Except from beepsky) to be sufficient, so long as you keep moving you'll be fine.
Just to keep the pressure on, chase them away from criminal activities.

> Make secbots ignore those fuckheads who take the Fuck With Security trait
The Jailbird trait? Is it possible this may translate into an easy way to avoid being arrested by them as the criminal will now be ignored?
If they're choosing jailbird, they deserve it! Part of the fun.

[Frank_Stein]

What if when Secbots bump into each other they get delayed or slowed and kinda wobble a bit?

So a few Secbots would probably be fine, but a huge group would probably devolve into the bots repeatedly bumping into each other.

[vampirate]

I'm partly responsible for secbots being this way, specifically that they patrol and summon properly.

The original plan was to have them be more of a nuisance, to discourage antags from standing still and finishing people off, with Beepsky as the exception that actually poses a major threat to any badguy and fill in for sec.

I think they did a great job before, filling those rolls without being needlessly awful.

But, after the changes I made, it highlighted a few other easily fixed jankbits in secbot behavior and code. Namely, the fact they had to wait before starting another chase path. This got fixed so that they never stop while chasing a perp.

But, secbots needed to not be moving to stun, or at least to telegraph that they are going to. I had put in a function to the movement proc to let it do a thing every step it takes, mainly to replace Beepsky's buggy attack-on-move thing. This got added to all the secbots for some reason, though.

So, secbots being so unbelievably annoying is partly my fault.

Here's what I can do:

Remove their attack-on-move thing (except from Beepsky)
Make them pause for a moment when they get to the end of a movement script
Make secbots ignore those fuckheads who take the Fuck With Security trait

Also, secbots can be built without using a stunbaton. Use a rod and some cables instead!

Honestly don't think changing them would be for the better.

---

At least not in this way. The only real problem is the spam, not the individual functions.

---

Which oof Chayot said... consider this a plus 1 on that statement.

[jflan17]

What if when Secbots bump into each other they get delayed or slowed and kinda wobble a bit?

So a few Secbots would probably be fine, but a huge group would probably devolve into the bots repeatedly bumping into each other.

Not knowing anything about coding and therefore how complex this would be, this looks to me like the most elegant solution.

[Mouse]

Making them (and the other various bots for that matter) not directly printable would solve any problems IMO. If I have to manually combine borg arms with bike horns to make an army of emagged ducks then people making an army of emagged secbots should have to put in similar amounts of effort.

[vampirate]

Making them (and the other various bots for that matter) not directly printable would solve any problems IMO. If I have to manually combine borg arms with bike horns to make an army of emagged ducks then people making an army of emagged secbots should have to put in similar amounts of effort.

This also eliminates a defense for robotics and medbay tho. It also makes things needlessly difficult for people who want to run a sec tron antag emag gimmick, which is secondary but also valid. I don't think adding tedium to the game is the way to go.

I'd propose that sectrons run a check if there are any other units active near them, and go to sleep if there are. Once a sectron is destroyed it sends out a wake signal that is used by the nearest sectron. This waking takes thirty seconds This means if one gets destroyed the destroyer has half a minute to do things before the next is active.

[KikiMofo]

Those people could always BUY the premade bots from QM couldnt they?

[Frank_Stein]

Making them (and the other various bots for that matter) not directly printable would solve any problems IMO. If I have to manually combine borg arms with bike horns to make an army of emagged ducks then people making an army of emagged secbots should have to put in similar amounts of effort.

This also eliminates a defense for robotics and medbay tho. It also makes things needlessly difficult for people who want to run a sec tron antag emag gimmick, which is secondary but also valid. I don't think adding tedium to the game is the way to go.

I'd propose that sectrons run a check if there are any other units active near them, and go to sleep if there are. Once a sectron is destroyed it sends out a wake signal that is used by the nearest sectron. This waking takes thirty seconds This means if one gets destroyed the destroyer has half a minute to do things before the next is active.

I'd say a mix of this and my idea of having them bump into each other.

I think it would be neat if bots communicated with each other more. In an idle state, they could go into this search mode for other bots in their area they could work with, looking for pings to respond to.

Once locked in on a goal, they try to ignore everything until it's done, but certain things like bumping into each other makes them stop and do a check again for pings, or send out their own pings for help, then either go back to their task or remain idle

[Superlagg]

One thing to keep in mind that bot code is one of the more janky piles of code, and the thing that checks to see if any specific thing is nearby is fairly expensive to run. For a bot to check if it bumped into another bot, there're a few ways we can go about this:

> Have the bot scan the contents of the tile its on every step and check if any of those things are the same type as the bot.

> Make a global list of all the bots' locations, and have the bots check this list if its location matches any of the other ones, as well as knowing which entry on the list is their own and disregarding that.

Then, run a proc that makes the bot fuck around, set a var that says it bumped into a bot, then unset that var in a few seconds so it doesnt keep bumping into the same bot endlessly.

At any rate, it'd probably be obnoxious to code wouldn't result in anything that'd fix the issues here.

I prefer how they used to work, that they were easy to avoid, group or not, but still needed to be avoided. I could change the way the stunner works to force the bot to stop, then run a fairly short actionbar to stun the person.

[RichardGere]

Remove their attack-on-move thing (except from Beepsky)
Make them pause for a moment when they get to the end of a movement script

These changes have already been made and merged since over a month ago (see https://github.com/goonstation/goonstation/pull/2082).

What you're seeing right now on the live servers are the nerfed securitrons.

[Wisecrack34]

oh no...

[Technature]

I'm sorry, but if you take away Securibot printing, how else am I supposed to mess with robotics as an AI?

[Superlagg]

Remove their attack-on-move thing (except from Beepsky)
Make them pause for a moment when they get to the end of a movement script

These changes have already been made and merged since over a month ago (see https://github.com/goonstation/goonstation/pull/2082).

What you're seeing right now on the live servers are the nerfed securitrons.

They were then later changed to do this every time they looped through their move list:

Code:

if(master?.mode == SECBOT_HUNT && master.target && IN_RANGE(master, master.target, 1))
    master.baton_attack(master.target)
    break

Meaning they can attack whenever they move if someone is in stunning distance.

[Studenterhue]

Bit late to the party, but this PR has just been merged that goes the "make buying secbots more expensive" and "increase cost of manufacturing secbots" routes. Robotics Crate is now 7500 instead of 2000, and to make secbots, you need a power source and higher-quality materials than before, and more of them, and it takes longer than before too. (It also makes a few other bots more expensive). Basically, you can't make them at right at roundstart anymore.

[Studenterhue]

As an update, this PR also has been merged. In addition to making non-Beepsky secbots take longer to cuff people (i.e. more time for someone to rescue you, somewhat lower disorient & stun resistance to tank the stun without getting cuffed), all secbots need to very briefly stop and "charge up" to be able to instantly stun you, and they lose this ability over time, rather than being able to instantly stun you all the time.

To recap, to address the issue of secbot swarms, they've been made more expensive and require special materials. So you can still make swarms, but you can't do it at roundstart and you need a fair amount of resources to do so. The power of these swarms was also indirectly nerfed by making secbots able to instantly stun only sometimes.

The proposal to make secbots block each other and generally slower in groups has been left untouched, but anybody's free to try their hand at coding such a thing, if they feel that these changes weren't enough. Or just pursue a different path.