NetID Pinpointer

[Garash]

Here's the idea: it'd be like the BloodTrak blood pinpointer, but for nerds machines!

It's main use would be to track down whatever contraption/computer is being used by some hooligan to spam fire alarms, nuclear charge activations, shuttle calls, or whatever else magical packet idea the player came up with. (Note that shuttle recall spam should still be ahelped, even if it's done by an antag (sorry for making you write down that rule pali!))

It seems like a feasible idea: DM has a locate(TextRef) function, and NetIDs are chopped off \refs. So the code could rebuild the \ref from a NetID that's either directly imputed by a user, or picked from a searchable list of all NetIDs, if we want to have that. Only other thing to check would be that the object has a NetID set up so the user doesn't track something like a wall or an other player.

Placing one in tech storage, computer core, det's office and a few in the mechanics lab, might also pique people's interest in packets. Feature discoverability is a positive thing, right?

"But what about the Powernet-networking Component which can spoof it's sender NetID?" While to me it looks like a legit coding oversight (One comments says "//Override whatever jerk info they put here" when fixing a wired mode sender field.) It does enable for some fun shenanigans. So I'd propose adding in an additional field like sender_proxy = (actual NetID) when the sender is spoofed/missing. That way people can still do fun spoofing stuff, but they can get tracked down by someone else packet sniffing. Wireless Network Cards in mode_free do seem like they're missing their sender field by design, so I wouldn't touch that though.

If people think this is a good idea and nobody steps up to make a PR, I could look into coding it 👀.

[UrsulaMejor]

Are netids unspoofable or even useful for this?

If this could possibly function, I think itd be a neat tool

[pali6]

This would be way too abusable to track literally anyone on the station via a PDA. But if you can propose a way to solve that issue it sounds good. Though I think the avilability of this device you propose is too much, it doesn't need to be in four different places.

I don't like the sender_proxy idea. At least not in the form of it being a packet field. An alternate idea I have is that this pinpointer device could be slightly more general "network forensics" device that could sniff packets (wireless as usual, wired... maybe if you are standing on a data terminal?) and clicking on a packet there could let you track the sender of that packet. This way instead of "sender_proxy" being a field in the packet there would be a var/atom/sender_device or something like that on the packet.

This would also solve a different issue: By doing all of this via locate() you run into the abuse of being able to track ANY ATOM if you know its ref (which is not difficult to get in-game, hell, sometimes if you have lag and use a verb on an object and the server reports the object has moved and is no longer in range the ref will appear in your command bar). And even if you managed to get around that issue there's the secondary issue of refs not being unique. Well, they are unique at a given point in time but when an object gets deleted its ref can get assigned to something else. And then there's the tertiary issue that relying on netIDs being convertible to refs is not something you should do because sometime in the (likely distant) future I'd like to change the netID assignment "algorithm" to be more random so it's not (almost) fixed every round. Doing the packet sniffer thing where you click on a packet and track its owner would fix this issue (though not the PDA issue).

[getbrecked]

As Security, I implanted someone with a tracker and noticed that the locator on the GPS' sprite would only update to an accurate position when I clicked on their name in the list again.

Maybe it could function like that, giving you the device's location without updating until you use it again. A cooldown could also be implemented, or maybe a degree of randomness?

[pali6]

I don’t think that’s necessary really. If you are answering the PDA issue I raised I think I’d rather prefer some sort of a solution there where you PDAs / PDA packets are untraceable unless using the Packet Sender app.

[Marksman]

Perhaps another way of nerfing it while still allowing PDA's would be to make it like the Packet sniffer and require being placed on a data port to update the arrow

[pali6]

Hm that doesn’t make much intuitive sense for wireless devices.

[Garash]

Proposed availability is too much

Gotcha, the idea was that everywhere that had a packet sniffer there'd be a pinpointer too, and then I figured since it's a sleuthing tool there could be one in the det's office. If we want less availability I think one in tech storage and another in computer core makes sense?

Better implementation idea

Oh I see that /datum/signal already has a var/atom/movable/source, I imagine we could be using that? From then, it's a UI that lists sniffed packets, and you pick one, like you said yep.

For balance reasons, PDA packets, (except for the ones sent through the "Packet Sender" program,) should not be able to be tracked down

I think a new property on /datum/signal, var/untraceable, defaulting to 0 but set to 1 on select PDA packets could do the trick.

Assuming it works like a packet sniffing tool, how do we start tracking wired packets?

What if the pinpointer could be inserted inside an active Packet Sniffer, at which point you could start seeing wired packets too?

... At which point it would be nice if the feature reworked the Packet Sniffer UI into a more modern look, and that's starting to look like a lot for someone who doesn't even have a dev environement set up haha! So I'm starting to think I should look into something a bit more simple first, like being able to make pllasma glass out of plasmastone&molitz, or molitz into glass.

[AmazingDragons]

This sounds like a really cool idea, and I'd love to see it implemented.

That said, I think it'd work better as a form of pinging, similar to how you can ping a pda to get the owner's name. So you could send a packet to any device, and it would respond with its location. Then potentially there would be a way to override the location auto-reply with something else for the ultra-nerds who are worried about being tracked.

I also had a couple of ideas that I'm not super sure of, but might as well share. First idea is that the coords could be offset in the same way as telescience (so you'd need the calculation to actually figure out where the device is) and this would also make messing with the location in a believable way much more difficult. This could potentially also only apply to pdas, to allow them to be more secure than other devices, while still being findable.

Second idea is for a cargo orderable pre-built mechcomp device that has an easy system to put in a net_id and find the location of it. It could also include a guide of what it is doing and how it works. This could be immensely useful for players trying to get into mechcomp, as well as making locating these devices not locked to packet-nerds. This would require some thinking about logistics of delivering it, and making sure that it all comes properly hooked up. It could require some assembly from the user, with a guide to that, or maybe could all come in a mechcomp cabinet, though that would then become the only way to produce mechcomp cabinets, which is a beast of its own.