Jump to content

Little brain teaser: low lag RFID tag


Kyrah Abattoir
 Share

You are about to reply to a thread that has been inactive for 1798 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I had this idea to implement some kind of RFID tag/fob system and started wondering about way to do this with the least possible amount of script usage. I figured I'd share with the class and we could discuss implementation (no I'm not telling you to do my work i figured it would be interesting)

The basic idea involves a door, and the RFID tag/fob.

  • The fob can be worn, rezzed, physical, it doesn't matter.
  • The door unlocks when a fob with the right ID is less than 2 meters away.
  • The door re-locks when there is no fob in proximity.
  • Users shouldn't have to interact with the door at all.

I can thing of many ways to do this, but I dislike most of them:

Option 1

The fob has a sensor scanning for door names and llRegionSayTo to all found doors in proximity.

  • Pros: no script time when there is no fob around.
  • Cons: sensor polling, requires doors to be specifically named.

Option 2

The fob announces itself constantly on the door channel through llWhisper(). Doors filter out fobs with wrong ID and fobs that are too far away. This is the "more realistic" option.

  • Pros: Anything can be a door, the fob is as dumb as possible, which is usually a good thing, no script time when there is no fob around.
  • Cons: constant message sending is bad.

Option 3

The fob announces itself with a region wide message when attached or on region crossings, doors then regularly poll for the position of the fob in relation to themselves, if the fob stopped existing, it is removed from the check queue. When no fobs are in the check queue, polling stops.

  • Pros: Again, anything can be a door, the fob is as dumb as possible, no script time when there is no fob around, no sensors or listeners are solicited, but you'll still have to poll.
  • Cons: All doors are polling for all valid fobs if there is any present in the region.

 

Other possibilities?

Edited by Kyrah Abattoir
  • Like 2
Link to comment
Share on other sites

@Kyrah Abattoir

Well, I'm actually an acronym illiterate therefore i have absolutely no idea what a fob or RFID might ever be, BUT since it's a matter of scripts that need to communicate to each other, the only idea to reduce strain i have is as follows:

  • The fob starts scanning around only if gets clicked by someone in a specified range (you said 2 meters)
  • If a RFID tag is found, it does its job
  • the RFID/fob tag should be clicked in order to announce itself to other devices
  • If connection can be established, the fob does its thing
  • if the RFID gets detached, sends a connection interruption command and the fob shuts down
  • The fob and the RFID both shut down if the avatar walks away further than X distance and anyway after X time has passed

Pros: you get to use sensors and listen only when needed, for the time needed; fobs don't have to listen or poll up to unreasonable distances, RFIDs don't have to use LLRegionSay

Contra: The user needs to click both devices, an hardcoded X amount of time for automatically shutting the system down

Edited by OptimoMaximo
  • Like 1
Link to comment
Share on other sites

Option 2, but the FOB doesn't talk non-stop. It only sends messages when the avatar stops moving, as determined via llGetAgentInfo(). If you walk/fly/swim past a door, it doesn't open. If you stop within 2 meters, it does. This avoids the RL annoyance of walking past the Target entrance on my way to Home Depot, triggering the doors.

You will, of course, have to call llGetAgentInfo() often enough to be responsive, but that should be lower overhead than a similar rate of llWhisper()s.

Edited by Madelaine McMasters
  • Like 3
Link to comment
Share on other sites

Option 4: Put a collission prim (llVolumeDetect) with a diametre of 2m next to the door . When the prim is hit by an avatar, it sends a message on the fob-channel via llWhisper to a potential fob. If there is a fob that hears the message, it sends a message on the door-channel back via llWhisper to the door: "Open Sesame!"

Pros: Only two messages exchanged. Very low on resources.

Cons: Let me know. Can't think of any.

Edited by Estelle Pienaar
  • Like 6
Link to comment
Share on other sites

5 minutes ago, Estelle Pienaar said:

Cons: Let me know. Can't think of any.

Perhaps that it requires 1 more prim, but that's all.

If llVolumeDetect can be enabled on only 1 prim in a linkset (which i don't know, i'll look it up), that may be a pro on a Contra point, because if it can't be enabled that contra becomes a fuss to manage, having to position a floating prim in the right location

 

Edited by OptimoMaximo
  • Like 1
Link to comment
Share on other sites

5 hours ago, Estelle Pienaar said:

Option 4: Put a collission prim (llVolumeDetect) with a diametre of 2m next to the door . When the prim is hit by an avatar, it sends a message on the fob-channel via llWhisper to a potential fob. If there is a fob that hears the message, it sends a message on the door-channel back via llWhisper to the door: "Open Sesame!"

Pros: Only two messages exchanged. Very low on resources.

Cons: Let me know. Can't think of any.

Yeah I thought about that but unless using multiple links and scripts (not that great in itself), the door can't have a volumedetect AND also prevent you to just go through it.

  • Like 1
Link to comment
Share on other sites

6 hours ago, Estelle Pienaar said:

Option 4: Put a collission prim (llVolumeDetect) with a diametre of 2m next to the door . When the prim is hit by an avatar, it sends a message on the fob-channel via llWhisper to a potential fob. If there is a fob that hears the message, it sends a message on the door-channel back via llWhisper to the door: "Open Sesame!"

Pros: Only two messages exchanged. Very low on resources.

Cons: Let me know. Can't think of any.

i would go with this method

taking into account also what Maddy mentions

when the door gets the message from the fob, the door checks the rotation of the avatar. Only opening when the avatar is facing (ish) the door

CON: the door has to have an open listen

 

is possible to trim this down further, when the fob has to be attached to the avatar to operate the doors. The fob could be unscripted and no-modify. Collider checks for the attached fob. When found the collider sends the message to the door

CON: fob can be counterfeited when the creator has previously released modify objects

 

 

 

Edited by Mollymews
con
  • Like 1
Link to comment
Share on other sites

1 hour ago, SeanMcDonald said:

Couldn't this be mitigated by checking the fob's UUID?

UUID's change when objects are rezzed

thinking about it more tho, now that you mention what else could be done

a anti-counterfeit solution could be OBJECT_CREATOR and OBJECT_CREATION_TIME.  Creation time is typically unique for each new object belonging to the creator.  The collider script would need to know the creation time of the fob

 

  • Like 1
Link to comment
Share on other sites

OBJECT_LAST_OWNER_ID could help detect counterfeits unless the fobs are supposed to be able to be passed around after one of the door network's "fob-masters" first hands them out.

A related complexity might be the need to distinguish between the set of fobs meant to operate one network of doors from other fobs for other doors, but maybe that won't be a requirement if this will never be a commercial product. (I think this is the flexibility Kyrah just mentioned.)

It would be nice if authentication can remain just finding and examining an unscripted fob in the avatar's (visible, non-HUD) attachment list. Even if there are fewer fob-bearing avatars than there are fob-controlled doors, any attached script beats the sim hard upon arrival, so the fewer the better. (Rezzing the fob from Inventory instead of wearing it would have the same effect, but that seems super inconvenient.)

While I'm complicating requirements, might there ever arise a situation where one player's fob needs to be revoked? If so, there may be another step in the authorization process where the door-unlocker checks with a central database of revoked fob-owners for the door network.

  • Like 1
Link to comment
Share on other sites

Yeah I agree that having scripts on the fobs itself is less than ideal, but i can't think of a way to make a fob unique and consistently detectable, yet and the same time being a duplicate of the original object, without inheriting the privileges of the original.

Fobs also can't set their name or description to something unique unless they are nomod (tamper proof but frankly not ideal in SL in general), unless the script sets the fob identity right before self destruction. Or something like that.

You also can't spoof a fob's identity if it's completely static, (while it's not really a requirement, it can be fun).

  • Like 1
Link to comment
Share on other sites

With the centralized authorization+revocation database I was kinda drifting in the direction of the fob being nearly cosmetic - just a readily detected trigger for an authorization query where it's really the avatar's UUID (assumed unique and authentic) who's authorized for a particular set of doors. That's completely wrong, though, if the roleplay is to include transfer of fob between avatars (e.g., illicit "sale" of ID, or "killing" a player to "steal" their ID, perhaps).

  • Like 1
Link to comment
Share on other sites

4 hours ago, Qie Niangao said:

...there may be another step in the authorization process where the door-unlocker checks with a central database of revoked fob-owners for the door network.

Now that you've said this...

If I were building this system on an Opensim grid, I'd use a Google Sheet for the database, accessing through URL calls.  Each door or door-network is linked to a unique spreadsheet/database that records avatar keys of players who have access to that door.  When a legal fob is passed to a new player, it immediately records the player's key in the database.  When the player approaches a door, it checks the database and opens if it recognizes the player.

Pros:

  • Fobs can be passed around or new ones added to the network (may also be a con)
  • Single-run script in the fob which then auto-deletes
  • Access can be revoked by spreadsheet owner
  • Players could be blacklisted to prevent access even if they acquire a new fob

Cons:

  • May be too easy to counterfeit fobs?
  • Door script has to check the database for every avatar who approaches
  • External database storage could be hacked

I think I'm overthinking this.  Like a newbie. :)

  • Like 1
Link to comment
Share on other sites

5 hours ago, Qie Niangao said:

With the centralized authorization+revocation database I was kinda drifting in the direction of the fob being nearly cosmetic - just a readily detected trigger for an authorization query where it's really the avatar's UUID (assumed unique and authentic) who's authorized for a particular set of doors. That's completely wrong, though, if the roleplay is to include transfer of fob between avatars (e.g., illicit "sale" of ID, or "killing" a player to "steal" their ID, perhaps).

Precisely, the idea is to tie the auth to the fob itself and not the avatar carrying it :)

  • Like 2
Link to comment
Share on other sites

some more thoughts, building on what has been mentioned already

about the door

1) there is a collider prim. llVolumeDetect(TRUE)
2) agent hits the collider
3) collider detects attached hob and validates with hob server
4) on validation collider moves to collide the door, then up out of the way
5) there is a door. Opens only on collision with the collider
6) doors auto-shuts after some time
7) collider moves back to station when agent no longer on station

PRO: door script doesn't need an open listen

about the hob

is no way around what you previously raised re hob identification. And what Qie and Sean raised. There has to be some kind of hob server

1) hob must be uniquely identifiable. An identity readable by llGetObjectDetails()
2) KEY_CREATOR + CREATION_TIME can uniquely identify the type of hob
   Red Hob, Blue Hob, Gold Hob, etc. The type can't be spoofed
3) the hob is no-mod + no-copy + transfer
4) when the hob is transferred then any capabilities or value are transferred to the next owner
5) a hob can then have some tradeable value between hob owners

6) there is a script in a new hob
7) on first time rez, the hob script checks for the presence of the hob server
8 ) if found hob server sends a unique id to the hob
8a) hob renames itself: Kyrah's Red Hob #23676 (i would go with name, to make it easier for people who have more than one hob)
8b) hob deletes its script
9) if hob server not found, script remains until next rez or can recheck for server on owner touch
10) the hob thereafter can be validated
11) validation string: KEY_CREATOR + CREATION_TIME + unique name  


about next owner

1) can receive a hob from any source
2) wear the hob, interact with a hob client device: collider, console, etc
3) server validate the unique ID and the agent wearing it
4) if valid then server transfers any value associated with the hob to the now owner
5) a hob can be server invalidated according to hob usage rules

 

Edited by Mollymews
8
  • Like 2
Link to comment
Share on other sites

If this is a one time non-commercial project, I would consider using different SL groups for different access levels and people need to wear their group tag. So there would e.g. be the "RP area - Access Level 1", "RP area - Access Level 2", and "RP area - Access Level 3" groups. The llVolumeDetect(TRUE) script only needs to check for the active group title and opens (or not) accordingly. The advantage would be that a future administrator only needs to give or take away group access and does not have to fiddle with a server or unique keys. The downside is that you need to pay a bit for setting up the groups and it is a bit cumbersome for the user to change the active group just to get door access (but not much more cumbersome than the step to search for an item in inventory and wear it).

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1798 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...