SasTech KioskNet

Object and Information Distribution System

KioskNet Tools

This document contains info about the various KioskNet tools and gadgets to help run your system and take advantage of all the cool features it offers. Included inside are items to:

IM MACHINE

Notes

The IM Machine operates in two modes - in SUBSCRIBER mode it sends IMs/objects to your subscriber list. SUBSCRIBER mode is only available if you have the Subscriber edition or addon installed. In OWNER mode it sends IMs/objects to your kiosk owners. The version of the IM Machine supplied in the KioskNet Tools and Gadgets box contains a copy-only version that cannot be given to others. The IM Machine supplied with the Subscriber Edition is full perm so it can be given to other avatars to send messages on your behalf to your subscribers.

  1. Rez an IM Machine. The IM Machine will by default rename itself to YOUR name so that the messages appear to come from you. You can configure a different name in the IM Machine config.
  2. Click Configure from the menu to configure your IM Machine.
  3. Select your myID for the group you want to send to.
  4. Make sure SUBSCRIBERS is selected for the Machine Mode option. If you do not see "SUBSCRIBERS" as an option there, you probably don't have your server configured with the addon yet*. If you bought the Subscriber edition, then "SUBSCRIBERS" should definitely be there as an option already.
  5. To automatically load the last settings you used, click the "Copy Last" button.
  6. Set other options. Hover your mouse over any option to see what it does.
  7. IMs can be very long - feel free to use the entire message box for a long message!
  8. Click the big "+" to add a separate IM. Each additional IM will cause your send to take longer.
  9. Click Save to send your settings to the IM Machine.
  10. Remove the sample notecard from the IM Machine and add any objects you want to send out.
  11. Click the IM machine and click IM from the menu to start sending.

*If you do not see "SUBSCRIBERS" as an option on your IM Machine in the Machine Mode options, you don't have your server configured with the addon yet. Simply open up your Subscriber Addon box and read the README notecard inside there for instructions on adding the Addon to your server. The Addon works with ANY KioskNet server. Be sure to reboot, Configure, and SAVE your settings after adding the Subscriber addon to your server!

"Wait Until Online" Setting Notes

This setting will cause the IM machine to only send to avatars that are online. It won't resend to someone in your subscriber group that has already received the message. It's very important to realize the IM machine will appear to stop while sending, but obviously it needs to do that to wait for subscribers to log in so it can send your items/IMs to them. The IM Machine will run through your list of subscribers that have not been sent to yet and check to see if they are online, then pause for a few minutes and try it again.

It's also very important to understand the "Wait Until Online Days" setting too. The IM Machine will not keep retrying to find people forever, it will stop checking at the end of that number of days then send to the rest of the subscribers that never logged in during that time period, even if offline. At least then, there is a chance (if they have not capped) they will get your stuff.

With that in mind, it's really important to NOT stop (or pick up) your IM machine before that number of days has elapsed or else the IM Machine will not send to the remaining subscribers your stuff, they will be guaranteed to NOT get your stuff. So be sure to think about how many days you really want this IM machine to keep watching for customers to log in and set a good number so your IM Machine can finish.

It is REALLY important to NEVER pick up an IM Machine. Instead, delete it by clicking "Kill" from the menu. The IM Machine has lots of data stored in the database connected to your IM Machine to track who has not logged in yet. This data is not cleaned up when you pick up your IM Machine. Furthermore the system has no way to know that your IM machine is actually gone and will not remove that IM Machine from the History menu for subscribers, which means customers will have a bad experience trying to get a resend when that IM Machine is gone and the system doesn't know it yet.

There are some very important issues and effects of turning this mode on:

Letting Other Avatars Send IMs

There are two ways to allow someone else to send IMs to your group. The first is to make them full system admins. After making them admins, you can give them an IM machine (they cannot use one that you own) so that they can rez it, configure it, add items and send to your group, just like you would.

The second, and more secure method, is to use the Group Operator setting. This allows all members of an in-world group of your choosing to send IMs to your subscribers.

To tell the system which group is authorized to send messages:

  1. Set the group key on the website from your subscriber list page. Go there, and you will notice a button there named "Operator Group" that you can click to specify the key to your in-world group of message senders.
  2. Give an IM machine to anyone you want to be able to send IMs. They cannot use your IM Machines, they must have their own.
  3. Make sure the IM Machine owner tags their IM Machine with that group tag inworld.
  4. Make sure the IM Machine owner has that group tag active on themselves. Tell them to NOT deed the IM Machine to a group!

This means that they do not need to be made an admin for your KioskNet network, so they can't mess up anything with your system. All they can do is operate an IM machine. If you want to stop someone from sending, all you need to do is remove them from the in-world group. Their IM machine will stop working for future IMs.

IM Machine menu items:

Load: This only shows up if the IM machine is configured with "Wait Until Online" checked. This will cause all your subscribers to be marked as "not sent to yet", for this particular IM Machine, so the system can keep track of who needs to be checked. Only do this once, unless you really do want to re-send to everyone! The system will always remember who has been sent to from this particular IM machine, even if you restart IMs, so they won't get IM'd again. If you ever pick up and re-rez your IM machine, however, it will immediately forget who has been sent to and will reset all settings on rez.

IM: To start sending IMs, click the "IM" menu item and they will begin sending.

Stop IMs: Click this to stop the machine from sending while it is in the middle of sending.

Send To Me: This does a single test send to you to confirm that your settings are correct and you get what you expect.

Die: This causes your IM Machine to "unregister" as an active IM machine, which means that it will no longer show up in the IM history when your subscriber button on your kiosks are clicked. This moves the IM machine entry to the Archived IM Machines list on your Dashboard so you have a permanent message history. It then deletes the IM Machine for you.

After Sending

If your im machine is in OWNER mode, when it is done sending, you can simply delete the IM Machine since it is not needed any more, since there is no way kiosk owners can request resends of those messages.

If your IM machine is in SUBSCRIBER mode, you should avoid manually deleting your IM Machine. You should only delete it by using the "Die" menu item on the IM Machine menu. The reason for this is that when the subscriber IM Machine is done sending messages, it needs to be left alone so that subscribers can go to a kiosk and have messages resent - the IM Machine must be kept around since it stores the text and objects to be resent. Each IM Machine corresponds directly to one item in your message history list available from your kiosks. So keep your subscriber IM Machine rezzed in world until you no longer want subscribers to be able to get that message resent. At that point, when you are ready to archive it, click the IM Machine and select Die and this will allow the IM Machine to unregister from the server as an active IM machine (which moves it to your Archived subscriber group IM Machines list and removes it from your message history list), and your IM Machine will then delete itself. If you want to permanently remove an item from the archive list, just click the red button on that list and it will be permanently deleted.

It is VERY important that you never pick up a SUBSCRIBER IM Machine into inventory. Unlike your KioskNet server, if a SUBSCRIBER IM Machine is picked up, the web server will no longer be able to communicate with it and that message will no longer be able to be resent when a subscriber requests a resend. However, you can move an IM machine by following these instructions. If you do accidentally pick one up, you can re-rez it and configure it again and it will immediately show up in the history menu and be avilable for resends. Note that your old IM Machine will show up in the history list for a few hours, but it will be automatically cleaned up once the system figures out that it no longer exists in-world.

I highly recommend locking your SUBSCRIBER IM machine once you have started sending messages to avoid an accidental deletion later on. Delete it via the menu only!

Excessive Messages Error

SL has a hard limit on the number of IMs/minute that scripted objects owned by a single avatar in one region that can send out IMs or objects. If you hit this limit, you will get this SL error:

Objects you own in [sim name] have sent out excessive messages and their messages have been temporarily deactivated.

If you get this error, you should stop sending. You can stop or remove the other scripted items sending out messages and wait 30 minutes for the problem to clear up, then resume sending.

The LL throttle does NOT apply to scripted objects owned by other avatars. The throttle is per avatar, per region.

If you (as in, one avatar) need to run multiple scripted objects (and the other objects can be ANY object that sends IMs, not just IM Machines), there is a config setting for the IM Machine called Delay that will add a delay inbetween messages to try to stop you from reaching the limit. Unfortunately it's a trial and error process to find the right delay. Start with 1, if you still get errors, try 2 or higher. You'll need to experiment to find the smallest delay value to avoid that error. It will take at least 30 minutes to see this error. The IM Machines are designed to send out IMs and/or objects at the maximum possible speed so having more than one object other than the IM Machine sending stuff out may cause the problem. It's easiest to just not use more than one IM machine or similar scripted object in the region at a time. But if you must, you can experiment with the Delay setting, or put IM Machines in other regions.

Also avoid using Turbo mode for multiple IM Machines running at the same time, there is a very good chance that will cause the error as well.

IM Machine Notes

You also have the ability to archive IM Machines from IM Machine page on the KioskNet website. This will remove it from the history menu and delete it in-world automatically.

You normally should not change the number in the description field for the IM Machines. It is used to start an IM session from somewhere else other than the start of the list of subscribers in your database. If you have to do an emergency abort halfway through a lengthy list, you can actually set this number to start somewhere in the middle and avoid spamming everyone multiple times. For example let's say it successfully IMs 100 people on your list then you stop it. You can make any changes you need and type in 100 into the description field to start at person #101 and avoid spamming 100 people again.

You can modify the contents of your IM machine during or after sending. You can add or remove items. Even though the IM Machine appears to reset after you make any changes, it is still working in "resend' mode, so everyone requesting a resend will get the updated contents of the IM machine.

You can calculate how long it will take an IM session using this forumula:

  1. Take the largest of a) number of IM lines x 0.75 or b) number of items (notecards, objects, LMs, etc.) to send out x 0.38

Your total is the number of seconds per person it will take.

Examples:

Your total is the total time per person. It will actually take a bit longer since this forumula does not take into account the script time itself so this is a bare minimum time. The most overhead will be the web requests to get batches of names from the web database. If the web requests are a bit slow this can make a real difference in your actual time.

Now multiply your total time per person by the size of your list. That gives you the total sending time for your IM machine, in seconds.

You can divide that by 60 to get total send time in minutes, and by 60 again to get total send time in hours.

Q: Why do you need to use one IM machine per send? Why not use just one IM Machine?

A: I had two choices when designing the IM machine - one machine with everything in it, or separate IM machines, one for each send (a "send" being some collection of messages and items to send). The problem I quickly ran into with lumping everything into one box was that it became a gigantic mess. I couldn't remember which items went with which messages. All messages would need to be stored in there, and all items. If any are missing, then resends from the history menu will completely break. The message won't be there, or the item is missing. Maintenance was a nightmare. Let's say I monday I had a sale that ends a week later. And I send one message per day with stuff. So a week later I want to remove the sale notice and notecard from the history menu. But I don't have a simple way to organize which message(s) goes with which item(s) to delete for that sale - it's all one big pile, and my messages are all lumped together in some notecard.

Furthermore things get just completely unuseable if you want to change settings for one specific send. Let's say on thursday you want to set up a send to start automatically at 12:01am for the day of the sale using the "sendOn" setting. Well you can't, I'd have to come up with some way of having multiple settings cards, one for each send, with all the various settings for that one send. With all the possibilities it just became too messy.

So I opted to organize things by box. It's much simpler. One box is one send. All the messages are in that one box, all the items for that send are in one box, all the special settings are in that one box. To remove that send from the history menu, it's one simple menu item "die" and poof it's gone.

If you never want things on your history menu, you can just use the same box over and over. Just change the IM, replace the stuff, and send. Very simple.

So that's why it is the way it is, just simpler to manage your various sends and keep them available as one simple physical unit for the history menu.

CRASH NOTIFIER

This gadget notifies you if any object near it crashes with a script error. If you don't happen to be standing next to your server or other objects and it blows up, you'll never know! So this will email you immediately if there is a problem. Just put your email name into the .Settings card and you are good to go. Set the notifier within 20m of your server. This box actually works for any object, not just KioskNet servers :) So sometimes you may get a false alarm from someone flying by with a defective HUD or from a neighboring parcel.

Crash notifiers can be picked up to be moved safely.

WATCHDOG

This gadget keeps an eye on the system and notifies you if there are ever any problems communicating to the SasTech website at //sasun.info or problems communicating with your in-world server (for example, if the sim it is in goes down). I recommend using this at a remote location (home) to keep an eye on a server that may be elsewhere.

This box also notifies your kiosk owners if their kiosk stops communicating with the server. This can happen for a number of reasons. Most commonly, they deleted their kiosk, or picked it up to remodel or move locations. This box gives them a warning that it hasn't heard from their kiosk and to re-rez it. In some cases, land owners will disable scripts on their parcel, and this will cause the kiosks to stop working as well.

If you do not want the kiosk warnings to go out (for example if YOU own all the kiosks), you can either disable the "Kiosk Checker" script inside the watchdog, or delete it.

Note that the kiosk checker will email kiosk owners somewhere between 4-6 hours after their kiosk stops communicating.

To configure it, edit the !settings notecard.

website: this should never be changed.

myID: should be the same as your setting in the server.

myServerIDs (V9 or later): Specify the myServerIDs (as a comma list) of all the servers you want to monitor within your server group (same myID)

alertmail: where you want errors to go in case the system stops working

message: these are the IMs to send out to your kiosk owners when the kiosks stop responding.

Watchdogs can be picked up to be moved safely.

Notes: The watchdogs error on the side of caution and if something unknown happens they just spew out a lot of information about the error. Sometimes there are transient errors just connecting to the inworld server, or connecting to the website. A huge majority of the time any connection issues with your inworld server and/or the web server will work fine a moment later. If there is a real problem, the watchdog will start giving those errors every few minutes, and after enough errors have happened, if you configured your email address in the watchdog, it will email you, so I wouldn't worry unless it detects a persistent error and emails you. You can just watch the watchdog and if the floating text goes back to green after a minute, all is well.

Tour HUD

The Tour HUD is a great way to get customers to visit your kiosk locations. It's very easy to set up and the HUD is always up-to-date automatically.

To configure your HUD to visit all your kiosk locations, wear the HUD and edit the .Settings notecard inside it. Here are the settings and what they do:

myID: This MUST match the same setting in the !Settings notecard in your KioskNet server

Server: This must be the key to your HUD Updater box. The Updater box will give out free updates to any HUD user that attaches an old HUD that you have updated. If you leave this blank or don't set this key, your HUDs will never be able to update themselves.

Version: Your tour HUD version number. When you release a new version of the HUD, you should change this version number. This should be an integer value (i.e. 1) and not a floation point value (i.e. 1.0).

defaultTexture: This is the UUID of the texture you want to show on your HUD.

website: On the HUD menu is a website button that will take users to a website of your choice. Specify that website URL here. Be sure to include "http://" in the URL.

You should have your kiosk owners drop a full perm texture into their kiosks to cause that texture to shoe up on the Tour HUD when their location is active on the HUD. I recommend customers put in a small (256x256) texture to keep HUD rezzing times fast. If they do not drop a texture into their kiosk, the defaultTexture setting above will be used instead.

Tour HUD Updater

The tour HUD Updater is used to automatically send out updated HUDs if you want to send out a new one to existing HUD owners. When they wear their old HUD, the HUD's version number is sent to your HUD updater and if the HUD version configured in your HUD Updater is higher, the HUD in the Updater will be sent out to the HUD owner.

To configure your tour HUD updater, follow these steps.

Your First HUD

This section is how to configure your HUD and Updater for your very FIRST HUD release.

  1. Rez the Tour HUD Updater. When it is rezzed, it will tell you its key. Save that. Or you can click it at any time to get the key.
  2. Edit your tour HUD and open the .Settings notecard. That Updater key you just copied goes into the "server" setting there. So now your HUDs know how to contact your Updater.
  3. Note the default version=1 setting there. Leave it alone, since this is your first release.

DONE! If you do an update in the future, you need to follow the instructions below instead of the FIRST HUD instructions above. You can skip them for now, until your first update is ready, if you ever need one.

Your First HUD Update

This section is how to configure your HUD and Updater for your first updated HUD you want to send out and any more HUD updates following that release.

  1. Edit your updated tour HUD and open the .Settings notecard. Make sure the Updater server key is correct. Click your Updater to verify the key.
  2. Check the version number there and make sure it is at least one higher than the version number in the HUDs you have already given out. So for example, if your HUDs were all sent out with version=1, make sure your new one has version=2 in the .Settings notecard. Save the notecard.
  3. Edit the HUD Updater and go to the contents tab. Copy your new HUD into the HUD Updater.
  4. Now edit the .Settings notecard in the HUD Updater. Set the version setting there to be the SAME as you just set in your new HUD that you dropped into the HUD Updater box. So for our example, it should be version=2.
  5. Make sure you name it correctly in the HUDname setting. If you don't, you will get an error when you save the notecard so you know there is a problem.

At this point your HUD Updater should be ready to give out new versions of the HUD. Here is how to test it. Wear an old copy of your HUD. You can edit the HUD .Settings notecard and make sure that the version number is an old one. Within a minute, you should get a new HUD from the HUD Updater. If you don't, feel free to contact me for help and I'd be glad to come out and verify all your Updater settings to get it to work.

IMPORTANT NOTE! The update server is NOT keyless—you can never pick up the updater once you rez it! If you ever need to move your tour HUD updater, you can, but you must follow these instructions carefully! I would recommend trying this first with a NEW HUD updater to make sure that this process works AND your updater has the same key before and after moving.

  1. Click the server to see the key.
  2. Pick up the server by right clicking, More, Wear. It will attach to your hand.
  3. Fly or teleport to your destination.
  4. Make sure your group is set to your land group.
  5. Right click on the attached server, and click DROP. !!DO NOT DETACH!! ONLY click DROP. If you can't drop it, check your parcel settings—turn off autoreturn temporarily, make sure you are in the correct land group, or set your land options to allow anyone to rez temporarily. Then try DROPPING. If you can't drop it, go back where you came from and DROP it. NEVER EVER DETACH!
  6. Click the server, compare it to the key in your chat history. It should be the same. If so, everything is fine.

Visitor Counter

The Visitor Counter is a powerful tool you can add to your kiosks that collects data on visitors. It is strictly a kiosk addon and is configured from the kiosk, not the server. It is primarily designed as a feature for your kiosk owners since they can get details on visitors to their location, however you as system owner can see a nice chart on which kiosks are getting the most visitors.

The other great benefit is that the visitor counter can integrate with the Subscriber Edition and automatically send subscribe requests to visitors without requiring them to touch the kiosk. When you configure your Subscriber server, the "Subscriber Invite Message" setting is used to give a message to every visitor is that is NOT already a member of your subscriber list to ask them to join.

To add the visitor counter functionality to your kiosks, simply drop the ~Visitors script into the kiosk along with the rest of the scripts (usually in the root prim). Then click Configure from the kiosk owner menu (remember, you may need to click the BACK of a Subscriber kiosk to get the owner menu). The new visitor counter settings will be on that config screen.

Each kiosk owner can configure the counter's range, a message to be sent, and even an item to give out (from the kiosk's inventory) to visitors. A menu item on the kiosk owner menu will allow kiosk owners to see their kiosk's visitor data in chart form. If the range is set to 0, the visitor counter is disabled. Note that the visitor counter will cause a very small bit of region lag since it is constantly scanning for visitors every so often.

SmartBot Addon

KioskNet is fully integrated with SmartBot to take advantage of a much more effective method of group join requesting. With a SmartBot account, you can now use your SmartBot for direct group join invites instead of the built-in chat box type of group join invite. To set this up, simply drop the "SmartBot AdminBot Professional" script into your server, which can be found in your Tools package that came with your KioskNet package. Then configure the server and you will notice new SmartBot settings. That's it! Note that you cannot replace the supplied Smartbot script with a newer version, you MUST use the one supplied in the KioskNet Tools box.

To get your SmartBotCode:

  1. Navigate to your account dashboard at http://mysmartbots.com/active/dashboard/
  2. Hover your mouse over "Members" and click on "Group Security Code"
  3. You will be able to set your Group Security Code on that page.

Please note that if you are already a member of the group, you will not be asked to join by your SmartBot. I recommend testing with an alt or friend who is not a member of your group. If you are a member, you will never be invited by your SmartBot.

Note that when you test, there is some very significant lag between when you join or leave a group and when your smartbot is updated with that fact. So it may think you are in a group when in fact you are not. This makes testing tricky, you need to wait quite a while for your smartbot to be updated with your current tester's group status.

MDOG Kiosk Dispenser

The "MDOG" (Menu Driven Object Giver) kiosk dispenser is a great way to distribute your kiosks. The basic concept is that instead of distributing kiosks, you distribute a requester gadget that gets kiosks from a server. The nice thing about this is that you can give people a menu-driven choice of kiosks, if you distribute different kinds and it is very simple to change what kiosks you are giving out via multiple distribution points (manually, SL Marketplace, in-world kiosks, etc.). Instead of giving out kiosks directly from all those places, you only need to give out ONE object - the kiosk requester, which never needs to be updated. Then all you need to do is put your kiosks into ONE place, the MDOG server, instead of all those different locations. It's a real time saver and is much less confusing to have ONE place to store your kiosks for distribution and ONE item to give out to people that want a kiosk. The requester never goes out of date, someone can re-rez it at any time and they will always get the latest version of your kiosks from your MDOG server. Note that the MDOG server is NOT KEYLESS - so like the old-fasioned servers, it CAN'T be picked up EVER or all of your kiosk requesters will stop working and there is no way to repair them. I would not consider this a major crisis since the easy way to fix this is to re-rez your MDOG server, make a new requester box, and just start giving that out instead of the old broken one. But if you keep your server in one place you will be fine.

The MDOG tool can also be used for another extremely useful function, giving customers a choice between "flavors" of the items you are giving out. For example, let's say you publish a magazine in 5 languages. Instead of giving people that click your kiosk 5 objects, or setting up your kiosk with 5 different buttons to click (which is a good alternative) instead what you can do is prepare a single MDOG object to give out to them from your KioskNet server. When they rez the MDOG object, they immediately get a menu that allows them to pick which language then want. With one click they are delivered the specific language issue they want.

Note that the server and requester are pre-configured as an example magazine kiosk requester so that you have a practical example of how it works. Here's how to do a quick config to see it in action with the sample setup:

  1. Rez the server. It will tell you the server key. Copy that key from the chat window.
  2. Rez the Kiosk Requester and dismiss the menu that pops up.
  3. Edit the .settings notecard in the Requester and paste your server's key over the key in the server setting. Save.
  4. Your system is now configured. Click the Requester to see what happens and how the Requester system works.

Here's how to set up your kiosks for distribution once they are ready using the MDOG Kiosk dispenser:

SERVER

  1. Remove all of the sample objects in the server ("Queen Magazine...") and put all of the kiosks you want to give out into the server.
  2. Check the permissions of the kiosks you just put into the server and make sure they are correct.
  3. Edit the .Settings notecard in your server and set up your menu items. For each menuitem setting, specify a button name - the text that you want to appear on each menu dialog button (make your choices very short strings - no more than about 8 characters will fit on a button). Following the button name, put a comma, then the actual name of the object in the server you want to give out when someone clicks that button.
  4. You can have up to 12 buttons defined MAXIMUM.

Example:

menuitem = Standard, Queen Magazine Kiosk
menuitem = Wall, Queen Magazine Kiosk - Wall

REQUESTER

  1. Click your server and copy the server key.
  2. Edit the .Settings notecard in the requester. Put your server key into the "server = " setting.
  3. Change your title to identify your server box - this is just so you know what it is when you put it with your other servers.
  4. Enter all of the button names you specified in your server settings card. Don't copy the entire line, just the button name. The items that are in the notecard are sample items. You can have up to 12 buttons defined MAXIMUM [New: KioskNet 9.3 release allows unlimited]. Example: menuitem = Standard
  5. Rename the Requester object to something more appropriate.

Please note that after a button is clicked from the requester dialog menu, it will take 20 seconds for the requester to respond to another click. This is because of the built-in delay for SL objects sending email. So be patient when testing :) green number above the server is the total number of objects given out since the .Settings notecard in the server was last modified.

It is important that you NEVER pick up your kiosk requester server. If you need to move your server, please follow these instructions.

Moving a Server

When it comes to moving a server, the KioskNet server and kiosks are a special case - they are keyless, which means they can easily be picked up and moved anywhere, any time. However, the other various servers in your system are NOT keyless - they depend on their key to never be changed so that the things that communicate to them can still do that (if you pick up any object in SL, and re-rez it, it gets a new key).

These gadgets require this special procedure to move. Other gadgets not listed are safe to just pick up and re-rez.

So here's how to move one of the above gadgets without changing its key. Follow these instructions VERY carefully. The trick is to pick up the gadget by wearing it directly from the ground, then dropping it directly to the ground at the new location. I HIGHLY recommend rezzing a prim and practicing on that.

  1. Pick up the gadget by right clicking, More, Wear. It will attach to your hand. Only move one gadget at a time.
  2. Fly or teleport to your destination.
  3. TURN OFF AUTORETURN at the destination parcel.
  4. Right click on the attached gadget, and select DROP. !!DO NOT DETACH!!
  5. Check the group on the gadget and make sure it is set to your land group to avoid autoreturn.
  6. DOUBLE CHECK your gadget's group setting and turn autoreturn back on.

Hunt Item Giver

Please note that there is no auto-udpater for the Hunt Item Giver. The current version is: 2.1. If you would like an update, please contact me directly.

Version 2.0 adds some experimental stealth features that guide your customers step by step through a simple process to replace the root prim, making them the creator.

Version 2.1 adds the ability to split payments (configured via the Fundraiser edition server settings).

The SasTech Hunt Item Giver saves hunt organizers using the SasTech KioskNet system a ton of time tracking and verifying required hunt items. What it does is create a list of all your hunt items across the grid, saving you the time-consuming hassle of teleporting out to every location to confirm that each of your designers has a hunt item out. It also sets the hunt item for sale for a price you control, automatically. In addition, when the hunt is over, you can automatically delete all the hunt items remotely. It is a HUGE time-saver running hunts.

To use the Hunt Item Giver, each of your designers MUST have your hunt's regular kiosk rezzed on their store parcel. The Hunt Item Giver must be rezzed on the same parcel to work, so that it can associate itself with that kiosk.

NOTE that more than one kiosk owned by an avatar on one parcel will NOT work. Both kiosks will not be visible on the tour HUD, and will not both be visible in the online directory. The ONLY supported workaround for this limitation is to have a separate alt own the kiosk + Hunt Item Giver for any additional store(s) on the same parcel.

Note that each myID can support ONE hunt. This means that you can't have multiple servers in a server group (using myServerID's) controlling separate networks of hunt item givers. The hunt item givers will use a RANDOM server using the configured myID for split settings in that case. If you have multiple servers with different fundraiser settings this will cause a big mess.

To get your Hunt Item Giver ready for your designers:

  1. Configure the .settings card inside it and set the card to No-Modify to avoid tampering.
  2. Make sure the Hunt Item Giver box is set to Modify, Copy, No-Transfer.
  3. Put your own texture on the Hunt Item Giver, if you prefer, and name your Hunt Item Giver something appropriate.
  4. Distribute the Hunt Item Giver out to your hunt participants. I highly recommend you use an IM Machine to do this - it's simple. Set your IM Machine to OWNER mode and it will automatically distribute to all your kiosk owners.
  5. Tell your hunt designers to simply put their items into it and hide it. When rezzed it automatically adds itself to your hunt item list, which you can find on the toolbar on your kiosk view. From there you can see all your hunt items, who owns it, a clickable SLURL to the Hunt Item Giver location, the parcel name and description, how long it has been since the Hunt Item Giver "checked in", the name of the Hunt Item Giver (in case you require a certain naming convention), and the names of all items your designers put into their Hunt Item Givers.

If your price setting is not 0, the Hunt Item Giver forces the default "Click to" action be "Pay object". Otherwise, the default action is forced to a normal "Click", and it will simply give out the contents of the Hunt Item Giver.

Note that the description field is set to show the number of sales made (or clicks, if price=0), which you can normally see by hovering your mouse over it. This may be useful for your designers to know in case they are interested.

Folder naming examples

Here are the rules used by the item giver to figure out the actual folder name when giving items:

if forced_giver_name is set, folder name is: folder_basename + forced_giver_name.
otherwise, if folderscheme is OBJECTNAME, folder name is: folder_basename + the actual object name.
otherwise, if folderscheme is OWNER, folder name is: folder_basename + owner name

Here are some examples of what your folder names and Item Giver Name in chat will be using various configurations of the folder name and stealth settings. In each case, the original Hunt Item Giver prim name when given out is "Holiday Hunt Giver" and the owner is Susie Designer.

Settings Actual Hunt Item Giver Name Name in Chat When Giving Items Folder Name in Inventory
folder_scheme = OBJECTNAME
folder_basename =
random_names = FALSE
forced_giver_name =
 Holiday Hunt Giver (no change) Holiday Hunt Giver Holiday Hunt Giver
folder_scheme = OWNER
folder_basename = Jane's Hunt -
random_names = FALSE
forced_giver_name =
 Holiday Hunt Giver (no change) Holiday Hunt Giver Jane's Hunt - Susie Designer
folder_scheme = OBJECTNAME
folder_basename =
random_names = TRUE
forced_giver_name =
 (a random name) (a random name) (a random name)
folder_scheme = OWNER
folder_basename = Jane's Hunt -
random_names = TRUE
forced_giver_name =
 (a random name) (a random name) Jane's Hunt - Susie Designer
folder_scheme (ignored)
folder_basename =
random_names = FALSE
forced_giver_name = Hunt Giver
 Holiday Hunt Giver (no change) Hunt Giver Hunt Giver
folder_scheme (ignored)
folder_basename =
random_names = TRUE
forced_giver_name = Hunt Giver
 (a random name) Hunt Giver Hunt Giver

NOTE: If random_names = TRUE and forced_giver_name is set, all your object names in your Hunt Item Giver list on the website will show the forced_giver_name as the object name, not the actual random stealthed name.

Notes and things to know: