Visitor greeter -- plan to make free

For no good reason, I wrote a simple visitor greeter, which would either post a dialog, give a notecard, or both, to visitors. It remembers the last 2000 visitors to avoid being a nuisance; it won't "greet" you if it remembers you.

It's a rather simple script, notecard configurable for the dialog text, and gives a (non-config) notecard if one is in object inventory. Set (or delete) the dialog text, optionally drop in a note, set it out, and click the "hide" button to make it invisible.

It uses the volume-detect collision box. (I wrote it as a scan first, but then thought better of it. The scan code is still there if there's a good reason for it.) You'd put it at your LZ or in a doorway folks would pass through when entering.

When it detects a visitor, it pulls an integer from the key. (Given LL's key format, this is guaranteed to be evenly distributed.) I'll call this the key hash. It keeps the last 2000 avatars' key hashes on a list.

If the visitor's hash isn't on the list, it's added (usually). If the list was already maxxed out, the oldest entry is discarded to make room.

If the visitor's hash is on the list, it's pulled out and added to the end. Therefore, frequent visitors won't normally be bothered, not unless it's a very popular site.

It records up to 2000 hashes. (An integer on a list seems to take about 20 bytes, in Mono. I still need to verify that it won't stack-error when full, and may have to adjust the limit downward).

If you configured menu text, and the visitor is unrecognized, it posts a dialog with one button, "Agree". If you don't click it, it won't remember you, so it'll ask you again.

When the owner touches, it gives a dialog with the choices of Reset, Show, and Hide. Show is 50% transparent for easy positioning. Hide is 100% transparent.

When you change the notecard, it automatically updates the configuration, but doesn't discard the list of avatar key hashes. If you changed the rules or just want to remind everyone, use Reset.

For very popular clubs, I might add an option for it to ignore anyone wearing the group tag. I wonder how many clubs see 2000 visitors between a typical person's visits.

I'm interested in your input/feedback. Is it evil to add yet another greeter?

For each collision (visitor), it does an llListFindList, append to list, and for recognized visitors, llListReplaceSubList() to delete their hash before appending it. Seem kosher with 2000 entries, in a place where it might get kicked a lot?

Memory -- do you think folks will want such a memory hog after parcel memory limits kick in? (I can easily make the max length notecard-configurable.)

Is volume detect better than a periodic scan? (I would expect so, but maybe not.)

With very little addional code and processing, I could keep a low-pass-filtered value for the "average" number of visitors per day.

Theere's no way to recover the names of visitors on the list. I could add a feature that, given an avatar's key, answers whether that av's key hash is on the list. But, I'd rather not bother. Seems kinda silly, but then, I've never managed a venue.

Oh, it sends an LM with the key of each "new" visitor, so it would be easy to add a script to send the data to an offworld server.

Let me know what you think
Thanks,
Jeff

why not, s'got some good features... the hash makes storage nice especially for busy places that don't actually need to track names/keys ( i can only squeeze ~500 keys into mine safely).looks like we went the same direction with moving frequent visitors back down the list to avoid culling, but kept the keys (and times) because I use a similar setup in another toy of mine that does more indepth tracking.

As it turns out the upper limit is 1200 or so. 1250 works, but I want to leave a bit more of a saftey pad.

I just take the first 8 digits of the key. Concerning the birthday problem, I did the math and with 2000, the probability of a single collision is 1% -- and the only consequence of that is someone doesn't get a message. Heck, that happens more often due to crashing!

Too bad there's so much overhead per list item (not that I know how much it should take), and the fact that we need enough space to hold two copies of the list for a brief moment. If I could figure out a way to eliminate that, 2000 would be achievable. I think this happens when removing one entry to make room for the next.

I'm surprised you can keep both key and time and have 500 entries, if I can get only 1250 integers. But, having two smaller lists, you need less space available.

Hmm, that reminds me of a trick I did with MLPV2, back in LSL days. Instead of keeping one list for some thing, I kept 4. That way I needed only 25% headroom, not 100% (of the saved data). I could try that here too.

I could also pack more in with two scripts, one to hold data and the other for the logic. But I doubt I'll pursue that.

you can check it out, it's on my user page for the portal, I did that with almost pure additions, but because it only holds an integer for the time, and the rest of the script does almost nothing... it literally says "hello < insetnamehere >"