SasTech KioskNet

Object and Information Distribution System
Skip Navigation Links

KioskNet V9 Documentation

For info on the new 9.41 release, see the V9.41 notes.

For info on the new 9.44 release, see the V9.44 notes.

Congratulations on purchasing the most advanced, powerful system for distributing items, information, and grid advertising in the world of Second Life. There is a LOT to this system and I have worked hard to make it as easy as possible to set up and use. With all the power and features comes some complexity, so be patient and scan through the manual here to get an idea of what it can do and where information can be found on specific features once you are ready to use them. Product support is a keystone of my business success, so after doing your best to read the manual, don't hesitate to contact me for help. I'll be there for you!


The easiest way to get familiar with the system and the various kiosk modes is to check out the Sample Networks section to see how to quickly set up some pre-configured example networks. They are very easy to set up and give you a good taste of what the various kiosk modes look like and are a great reference to see how the different kiosk modes are configured. The Setup Instructions section below is a step-by-step walkthrough of the process of setting up one of the pre-configured sample kiosk networks, so go through those steps first.

Help and Support

Your primary channel of support is this documentation. If you can find your answer here, then IM Sasun Steinbeck in-world. If I am offline, don't worry, I'll get back to you (please do not notecard me for short messages, I'll get them).

Setup Instructions

Note that the server communicates by whispering to avoid spamming the surrounding area. This means you need to be within 10m of the server to hear it, so stand close!

This step-by-step guide will walk you through the configuration of one of the pre-configured sample systems. Once you are familiar with the process, you can easily configure other sample systems or start with the generic KioskNet Server in your package and configure it. Or just use the server from one of the pre-configured sample networks and use that as your own permanent server, it's up to you.

Step 1: Configure a server:

  1. Look in your KioskNet package and find the object named "KioskNet Fully configured sample - SIMPLEARROW mode". Rez it and edit it and look inside it. There is a sample server and a sample kiosk inside that box. Rez the server named "Sample Server - SIMPLEARROW" from that box.
  2. Edit the "!Settings" notecard inside the server.
  3. Find the "myID" setting, right near the top. This needs to be set to a unique short identifier or phrase that you create to identify your kiosk network and link everything together. It can contain spaces if you want to use a short phrase. It cannot be more than 36 characters long, and case is ignored.
  4. Save the notecard and the server will load all the settings.

NOTE: You will get some errors that your server is not registered. This is normal, since it's not registered quite yet.

Step 2: Create an account at the website

  1. Click your KioskNet server and click Dashboard from the menu.
  2. On the web page that it takes you to, in the Login box, click the Create New User link to create a new account. Note! If you do not see a dialog pop up that takes you to the website, make sure you have not muted yourself.
  3. When that is done, click your server and click Reg Avatar (or Connect Me). This permanently links your SL avatar to your new account. This only needs to be done once, ever. Once done, it will send you to your Dashboard page, which at this point shows nothing.

Step 3: Register your new server with the website

  1. Click the server again, and this time click Reg Server or Save from the menu. What this does is save your server information on the website. So now that server will show up under your list of servers that you own on your Dashboard page.
  2. Go back to the webpage and click Dashboard from the menu to refresh the page (or click Dashboard from the server menu again). You should see your server on your Dashboard page now.

Step 4: Configure your kiosk:

  1. Go back to your pre-configured sample box and find the kiosk named "Sample Kiosk - SIMPLEARROW)" and rez it.
  2. Edit the kiosk and edit the "!Kiosk Settings" notecard inside it.
  3. You will see a "myID" setting in there as well. Set the value to your myID setting - it must be the same as your myID setting in your server. Save the notecard.
  4. Your kiosk will now register with the system.

At this point your system should be working. The kiosk will display the sample texture that's in the server and give out the sample notecard that can be found in the server. Note that when you click a kiosk, you get a menu. That is because you are the owner of that kiosk. No one else except the kiosk owner sees a menu when they click a kiosk, they just get the stuff. So when you give out these kiosks, the new kiosk owner is the only person that will see the menu on their kiosk. If you want to see what happens when a non-owner clicks a kiosk, select "Click" from the kiosk menu. That puts you into "non-owner" mode for the next click. Click the kiosk again to get your stuff from the server.

SIMPLE mode is easiest to setup and configure. Try changing the kioskmode setting in the server to "SIMPLE" then refresh your kiosk to see what changes.

For info on how to update your kiosk textures and what you give out, see the Changing the Notecard, Texture, and Objects section for details.

Sample Networks

Included in your package are some other fully configured networks you can use as examples to see some of the various combinations of kiosk + server configurations working together in real samples. I recommend you rez them and play with them to get familiar with the various kiosk modes.

To set one up, look in your KioskNet package and rez one of the boxes named "KioskNet Fully configured sample - …" and look inside that box. Inside each one is a server, a matching kiosk, and a notecard. Rez the server and kiosk. If you have not followed the step-by-step instructions in the Setup section above, just go there now and once those are done, your sample network will be up and running. After that, read the included notecard in the sample package for any notes specific to that particular sample.

If you have already done at least one server + kiosk setup, then all that needs to be done for each of the pre-configured networks is to give the server and kiosk a unique "myID" setting value in their configuration notecards and they will connect and be fully functional.

Once you have the sample network running, you can play around with various kiosk and server settings to see what they do, with no danger of messing anything up. If you do, you can just re-rez the server or kiosk, enter in the unique ID you created, and they will continue to work.

You can actually use one of the fully configured networks as a basis for your own network. Be aware that in order to keep things as simple as possible, many of the config notecards not needed for that specific mode that the server is currently configured for have been removed. If you do decide to change modes you will be missing some of the necessary configuration notecards in the server. For this reason I'd recommend that you build a new network with the regular KioskNet server rather than one of the pre-configured servers, though it is also possible to simply add the missing configuration notecards for the mode you want to set in the future. So other than a few missing config notecards, those sample servers are fully functional.

Kiosk Configuration

The most important kiosk configuration decision you need to make is what mode your kiosk will be in. If you are just learning the system, I would stick with SIMPLE mode for learning, but you should be aware of all the various kiosk modes. I highly recommend you go there and just read up on what each mode does so you are familiar with them. The kiosk mode is set by the kioskmode setting in the server's !Settings notecard. Note that it can be changed at any time and the kiosks will automatically morph into the new mode, with a few caveats — read the details on kiosk modes for more. So after you send out some kiosks, it's possible to change the kiosk mode and all your kiosks will automatically change modes without you needing to send out new kiosks.

Here are the settings in the !Kiosk Settings notecard you need to configure:

Note: I recommend setting next owner permissions for this notecard to NO MODIFY before making your kiosks public to avoid people hacking with your settings.

KioskVer: This should be an integer number. It is defined by you so that you can set version numbers of your kiosks as you release new kiosks. This number shows up in the version column of your kiosk list on your Kiosk View web page. This is also used by the script upgrader. When you update your kiosks, you should update your kioskVer number as well.

myID: This is defined by you and must be a unique keyword that matches the myID value you set in your kiosk server. This value is what ties all the kiosks together to the server and the website. Case is ignored.

myServerID: This is again defined by you and must match the setting in your server. See the Server Groups feature for more info on myServerIDs. This setting may be blank if it is blank in your server, that's ok.

Texturefaces: This tells the system which faces of the main display kiosk to put your texture(s) on. If you want to texture more than just face 2 (for example, all sides of a box), you can use the Texturefaces setting. Simply specify all the face numbers in a comma separated list. For Version 9.41 and below, face 2 MUST ALWAYS be the first face in the list!

Example: to texture all faces, set texturefaces=2,0,1,3,4,5

kioskprims: This tells the system how many prims your kiosk is. This is important to set accurately or some prims may become automatically unlinked!

kioskstyle: This is a short description to help identify your specific kiosk model for the script upgrader, if script upgrades ever become necessary. This is very important to set, otherwise someone else's kiosk script updater object might upgrade your kiosk and essentially turn it into one of theirs if both of you leave it at the default setting!

ignoreparcel: By default, the system is designed to automatically replace a kiosk record in the database if another kiosk with the same myID value shows up on the same parcel and is owned by the same person. This is very helpful in keeping your kiosk list clean and avoiding duplicate records. By default this value is FALSE which means that only one kiosk, per owner, is allowed per parcel. Any additional kiosks will replace the one already there, in the database. If you DO need to allow more than one kiosk per owner per parcel, you can set this to TRUE. What you will see is quite a lot more "dead" kiosks in your kiosk list, since a new record is created every time someone rezzes a new (or re-rezzes the same) kiosk, requiring more work to keep your list clean and accurate by deleting those missing kiosks. For more important details, see the FAQ entry at the bottom of this help file.

teamName: This setting is used if you are using the Donation Mode feature to assign this kiosk to one of your donation teams. After you configure your team names on the website, assign this kiosk to one team by putting that team name for this setting.

giveMessageMethod: (V9.4 or later) When someone clicks the kiosk, it can either SAY or IM the give message (givemessge setting in your server). To Say the givemessage out loud, set giveMessageMethod = SAY. To IM the givemessage privately, set giveMessageMethod = IM giveMessageMethod = IM

subscribeFace/unsubscribeFace: (9.44 or later) You can designate a specific face on your subscriber prim to be either a dual-function subscribe/unsubscribe button, or have one face for a subscribe button and different face for an unsubscribe button. If you want both functions on one face, specify the same face number for both settings. This is especially useful for mesh kiosks. For a basic single-prim subscriber kiosk, or if you have a separate subscriber prim button, you should probably leave these blank so that a click on any face will work.

Kiosk Details

Included in the KioskNet package are lots of custom designed, FULL-MOD sample kiosks. You are free to use them as part of your kiosk network as-is or modify as you like. All of the sample kiosks are ready to configure and use with all scripts pre-installed.

IMPORTANT NOTE! The sample full-perm kiosks provided as part of the KioskNet product package are for you to use as part of a configured KioskNet network system ONLY. You MAY NEVER sell them as part of a competing kiosk product. You may ONLY distribute them if it they fully configured kiosks that are part of YOUR kiosk network used to distribute items or information, or subscribe people to your subscriber list. If that is true, you can give your network kiosks away for free or sell them if you wish. You can use any permissions you want, including full perms. NEVER give them away if they are not part of a configured kiosk network!

Display Face: (9.41 and below) Due to technical limitations of the various kiosk modes, the main display face of your kiosk must be face 2. Use the tip below to figure out what face 2 is. Make sure that the display prim is oriented correctly with face 0 on the top, so it's not upside down.

If you want to texture more than just face 2 (for example, all sides of a box), you must specify the faces by setting the Texturefaces setting in the "!Kiosk Settings" notecard. Simply specify all the face numbers in a comma separated list. Face 2 MUST ALWAYS be the first face in the list! This is an important setting to get right since you cannot change it from the server—a mistake here will cause the kiosk to not be able to display your textures if you change them!

Example: to texture all faces, set texturefaces=2,0,1,3,4,5

  •  Tip: One way to get texture faces: Edit your kiosk, use the "Select Texture" edit tool, select the face, and press Ctrl+Shift+Alt+T. This will tell you the the face number you currently have selected.

Kiosk Refresh cycles: Your kiosks will automatically connect to your server every 2 hours and check to see if they are out of sync with the server and update themselves at that point. If you make any kind of change to the server, and someone clicks a kiosk before it has checked in on it's normal update cycle, no problem. The kiosk will immediately refresh wilth the data from the server, which is pretty quick.

Remove Modify on settings card: I HIGHLY recommend REMOVING modify rights on your "!Kiosk Settings" notecard so that the people you give/sell kiosks to can't mess with it.

Double-sided kiosks: Note that certain kiosk modes are NOT able to be used in a "double-sided" kiosk manner. The SIMPLEARROW and CYCLEARROW modes do really strange things to the main display prim to layer the arrow texture on top of your texture, so you cannot view it from the back side. They will also permenently resize the display prim it to be very thin, which may really mess up certain kiosk designs.

Description field: The description field of the kiosks stores the cumulative kiosk click counts. Make sure that the DESCRIPTION field of your master kiosk is always set to 0 (the number zero) before you give it out. That way your total kiosk click counts will remain accurate. After you are done testing your master kiosk, be sure to set this field to zero before picking it up and giving out copies of it. Don't worry about this being changed by a kiosk owner, if they set it to some random text, it will be reset to 0 the first time someone clicks one.

Kiosk Name: Feel free to name your kiosk anything you want. Also, note that the name of the kiosk object has nothing to do with the "kioskstyle" setting in the !Kiosk Settings notecard, they don't need to be the same.

Texturing your kiosk: When you texture your kiosk, there are two critical things to be aware of. The banner prim MUST have both Repeats Per Face set to 1.0 and both Offsets set to 0 (all default values—in other words, don't change them!). You will need to do any offsets or adjustments in your original texture, not with your texture settings. The same thing applies to your main display prim if you are using VIRTUAL mode. If you change these, VIRTUAL mode will not work!

Multiple kiosk designs: Note that the kiosk mode and many other kiosk settings are controlled by the server, which means that it is very easy to update these things on the fly, but that limits you to certain kiosk designs for that particular server. You can have have different kiosk designs connected to one server, as long as they are compatible with the kiosk settings in the server, so for example you can have very different kiosk builds as long as things like the layout of the banner prim, the kiosk mode and display size are the same.

"Allow anyone to copy" permission: I would recommend you do not check "Allow anyone to copy". Though this is a good (though non-intuitive way) to virally spread kiosks, you can run into major problems with controlling how many kiosks are attached to your server. Instead, I recommend you distribute your kiosks via your server, as well as on the SL Marketplace or your favorite SL shopping site. For example, in VIRTUAL mode (see below) you could have a "get this kiosk" button so that people can click that button on your kiosk to get a copy of the kiosk. in SIMPLE mode, just stick a copy of the kiosk into the server with your stuff, and everyone will get a kiosk. Using these techniques you have complete control of the kiosks that you give out in case you need or want to update your kiosks. If "Allow anyone to copy" is checked, you have zero control over the spread of your kiosks. If you ever update your kiosks, the old kiosks will proliferate forever.

Testing: I can't stress the importance of testing your kiosks before you release them! Make sure that kiosk texture updates work as expected, since the face to texture is set in your kiosk, not the server, so that can't be fixed if you make a mistake.

Modify: Please note that no-mod kiosks are incompatible with AUTO mode. This is because AUTO mode needs to be able to link and de-link buttons on the kiosk, which requires modify permissions. In addition, no-mod kiosks cannot be upgraded if a script bug is found. I would reccommend that you always give out kiosk with Modify permissions so that customers can resize them as needed to fit in the space they have available and to allow script upgrades. You do run the risk of someone modifying the textures on your kiosk or moving some prims around, but in my experience that is very rare and it's really appreciated to be able to resize the kiosks.

Kiosk Parcel Group Setting: The kiosks require the kiosk owner to set the group setting on the kiosk to match the group setting on the parcel. There is an important reason for this. In my experience I've found many a kiosk that was dead and not working because the parcel owner unchecked "All Residents" for the Run Scripts option. If the kiosk doesn't have the same group tag as the parcel, the scripts stop working and the kiosk is dead in the water. However if the kiosk group tag is set to the land group, then the parcel owner can safely uncheck "All Residents" for Run Scripts and as long as they leave Group checked, then the kiosk will work fine. This requirement can cause you a little pain explaining to your kiosk customers, but will save you long term problems with many dead kiosks in the future, trust me.

New! V9.3: You can now have your customers (kiosk owners) drop a full perm texture into their kiosks to cause that texture to show 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.

The top prim of your kiosk contains two special functions, besides displaying your logo on it. You can define up to two "virtual" buttons (clickable areas) on this prim to define your special teleport button and your special website button. The website virtual button will send the clickee to a website of your choice. The teleport virtual button will teleport people to a location of your choice. This is all done with one prim. There are two different ways to set up your banner prim.

The most important banner settings you must set regardless of the method below is the bannertexture and bannerfaces settings in your server !Settings notecard. The first should be the UUID key of the banner texture you want to use and the second a list of faces on your banner prim that you want to texture with it. This texture should have the (optional) special buttons drawn right on your texture.

Before you define your buttons, you should set your "website" setting to be your website's URL and your TP setting to be the SLURL to where you want to teleport people. This can be in one of two formats: secondlife://region/x/y/z, or DO NOT substitute "%20" for spaces in your SLURLs! Use spaces in your sim name if it is more than one word.

Template Method

The easiest way to configure your custom banner texture and settings is to modify a standard template that I have used in all of the servers in your KioskNet package. If you simply use the same exact layout, there is no need to change most of the Banner prim settings in the server's !Settings notecard, all you need to do in this case is change the bannertexture setting to specify your custom banner texture's UUID that you upload into SL. Here's how to do that:

I have provided a sample banner texture in a few formats to download, all in lossless format except for .jpg:

I highly recommend getting a Photoshop or Paintshop version if your graphics editor supports layers and those formats, since it will be much easier to change individual layers in the image.

Once you have your template downloaded, you can simply erase one of the layers corresponding to the text or the buttons. Note that the standard layout is as follows: 20% of the image on the left is the website button, the next 60% is the text, and the last 20% on the right is the website button. As long as you stick with that format, you'll be compatible with the defaults settings for the banner prim. Since the sample textures are 640 pixels wide, that's 0 – 128 pixels horizontally for the web icon, 128 – 512 for the text, and 512 – 640 for the TP icon.

When you are done editing, save your texture as a png (avoid jpg if at all possible since you will lose some quality unless you use jpg lossless) and upload into SL. When your texture shows up, right click it to get the UUID value and paste that after the "bannertexture=" setting in your server's !Settings file. At this point you are done. Save your !Settings notecard, wait for the server to register, then click an attached kiosk and click refresh. You should see your new banner texture show up.

If you are using a 2-sided banner, you'll need to add a few lines to your server's !Settings notecard. By default, the server will have the teleport and web page buttons defined on face 2 in the manner described above. The default button definitions in your !Settings card will be:

webButton=2, 0.0, 0.0, 0.2, 1.0
TPbutton=2, 0.8, 0.0, 1.0, 1.0

This defines the webButton and TPbutton for face 2 (the first parameter for each line). What you need to do is define two more buttons for the back side (face 4) so add these lines right below those two in your !Settings card:

webButton=4, 0.0, 0.0, 0.2, 1.0
TPbutton=4, 0.8, 0.0, 1.0, 1.0

Save your settings and refresh your kiosk, and the buttons on both sides of the banner prim should now be functional.

Buttonmaker Method

This is the most flexible method for defining buttons on your banner prim. You can place your buttons anywhere you want using this method. Use this method if you want to use a banner texture/buttons that are not laid out exactly the same as the standard template above.

To set the clickable areas for the virutal buttons on your banner prim, you specify the "webButton" and "TPbutton" settings in your server's !Settings notecard. To get these special defintions, use the special buttonmaker tool included in your KioskNet package to create your virtual button definitions. There is a special buttonMaker tool optimized for defining your banner prim textures, so use that one.

Once you have your buttons defined with the buttonMaker tool, you can set the webButton and TPbutton settings to specify the clickable area on your banner texture. Note that you can give multiple definitions of both webButton and TPbutton if you texture multiple faces of your logo prim for different faces. The first number in the list after the '=' is the face number. Make sure you have that correct.

For example, let's say you have a banner prim that has faces 2 and 4 textured (which is the case for some of the sample kiosks in the kit). In your !Settings notecard you should have something similar to this:

bannerfaces=2, 4
webButton=2, 0.0, 0.0, 0.2, 1.0
TPbutton=2, 0.8, 0.0, 1.0, 1.0
webButton=4, 0.0, 0.0, 0.2, 1.0
TPbutton=4, 0.8, 0.0, 1.0, 1.0

Here is what all those numbers mean. bannerfaces tells the kiosk which faces to put your banner texture on—faces 2 and 4 (front and back for the sample kiosks). The first webButton setting says that you have a web button defined on face 2 from (0.0, 0.0) to (0.2, 1.0). The TPbutton setting means you have a TP button defined on face 2 from (0.8, 0.0) to (1.0, 1.0). The next two lines defined the same buttons but on face 4 (the back).

You can use non-box prims for your banner prim (i.e. a flattened cylinder as is used in kiosk #17), but you must do something a little different to get the correct button definitions. Instead of using the buttonmaker tool, you must drop the script from the buttonmaker tool in your banner prim (don't forget to edit linked parts first and open the contents of the banner prim!), texture it with the banner texture you plan on using, get your button definitions, then delete the buttonmaker scripts from your banner prim. Remember, your banner texture will always be replaced with the bannertexture setting in your server's !Settings notecard. Note that the existing .Banner script in there may interfere by popping up your web page or a map! Just ignore those and continue defining your two buttons. Don't forget to define buttons for the back side if you are showing the texture on both sides, too. Note that you can click the "flip" texture options if needed, in case your texture is showing upside down/mirrored on the back side.

Make absolutely sure you TEST your kiosk to make sure you have all your buttons working (front and back if you have a 2-sided kiosk) before sending it out! The good news is that if you screw it up, it can always be fixed later since it is a server setting; no need to replace any kiosks in this case.

Changing the Notecard, Texture, and Objects

This is the process you use when you want to update what items the kiosk gives out and what textures it shows. These instructions only pertain to the SIMPLE kiosk mode, which is the default for a new KioskNet system. For more advanced modes, see below. I recommend going through this configuration exercise before diving into the more advanced kiosk modes.

  1. Right Click and edit the KioskNet Server. Look in the contents. The server contains a sample notecard and texture. The texture is what will be sent to the kiosks to display and the notecard is what will be given to anyone clicking a kiosk.
  2. Delete the sample notecard and replace it with your own notecard (or any object to give out, instead).
  3. Delete the sample texture and replace it with your own texture. This texture is what will be shown on the kiosks.
  4. Add any optional Objects that you want to dispense.
  5. Test by clicking a kiosk and selecting "Refresh" from the menu. Wait for the kiosk to udpate.
  6. Click the kiosk and select "Click" from the menu. Click the kiosk again. You should receive your notecard and objects immediately.
  7. Every 2 hours the kiosks will check with the server to see if they need to update anything. If your server has been updated but your kiosk has not received an update yet, and a kiosk is clicked, it will do an immediate update. The person can then click the kiosk again once it has finished updating.

Note that there are a number of "special objects" found in the server that will never be given out. They include the following items:

  • System scripts, which all start with '~'
  • System notecards, which all start with '!'.
  • Any special object/notecard specified in the .settings notecard, such as items specified in the groupgivenew and kioskInstructions settings.
  • Any textures found in the server unless explicitly specified in a settings notecard for the CYCLE, VIRTUAL and AUTO modes.

Kiosk Subscriber Groups

Your SasTech KioskNet system comes with a full-featured subscriber messaging system so that customers can click a subscriber button on your kiosk to join your subscriber group and you can send them messages and any objects any time you want. Customers can click the subscriber button to have old messages/IMs resent, or unsubscribe at any time. You won't need to buy an external subscriber system for your customers—it's all built into KioskNet.

Note that the texture showing on your subscriber button on your kiosks is not configured from the server—just texture your subscriber button with whatever you want and remember that it can't be changed from the server—it's a static texture.

To send messages, you use the IM Machine. Your IM machine acts as a permanent storage box for each message with its associated notecards/object. So each message you send out needs one IM Machine rezzed and left alone until you no longer want that message to be in the message archives to be re-sent. This makes it very easy to organize your messages and items. Instead of piling them all into one box, making a big confusing mess, each message and the stuff you gave out with is in a separate prim.

To send a message to your subscriber group, rez an "IM Machine - subscribers" box and edit the .settings notecard inside. For details click the IM Machine link above.

Here are the different ways someone can subscribe to your subscriber group:

  1. Subscriber invite via kiosk click, either on the main kiosk (if the ~subscriber script is in the root prim) or via a separate linked subscriber prim (which contains just the ~subscriber script).
  2. The subscriber HUD, which can be given out when someone clicks the kiosk.
  3. There are special stand-alone special purpose subscriber kiosks in the kit. They are pretty much exactly the same as the subscriber HUD, just built as a kiosk that gets rezzed by you. People click it and get the same results as the HUD. Since it is not a normal kiosk, it will not show up on your kiosk list, and there are no click stats stored, and the SLURL location shown on your subscriber list will always be blank.

You can always do #1 and #2 together for best effect, just set up your kiosk to give out the subscriber HUDs when it greets someone.

TIP: If you want to set up an "invite-only" type subscriber group, you can. The Kisok.Net Subscriber HUD can be set to NO TRANSFER and by default it only responds to clicks by the owner, so you can control who gets invited by only sending out the subscriber HUD to people you are inviting. To add someone directly, simply go to your subscriber list online and click Add Single to add a single person, and you can easily remove people from the same screen as well. For version 9.44 and above, you can also set subscribe = FALSE in your server to stop anyone from subscribing at all your kiosks, and yuo can make the entire kiosk ignore anyone but subscribers by setting subscriberOnly = TRUE there as well.

Subscriber HUD

Included in your package is a special HUD that you can distribute to encourage people to join your group. To configure it, simply set your myID in the subscriber HUD's settings card, then drop in a notecard describing your group and listing the benefits of subscribing. HUD owners can then get info on your group (via that notecard), subscribe, unsubscribe, and get old messages very easily.

I highly recommend periodically sending out your subscriber HUD to your subscribers to give them an easy way to get old messages, invite their friends to join, and unsubscribe without pestering or complaining to you.

One-Prim Subscriber Kiosks

If your primary goal with your kiosks is to subscribe people to your subscriber group, one option is to create a specialized single-prim subscriber kiosk. This is an alternative to having a separate subscriber button. In most cases I would recommend having a separate subscriber button, but it is possible to skip the separate button and just drop the .subscriber script (from that button on the sample kiosks) into your main display prim, which makes the main display prim perform double-duty - it not only gives your stuff out on click, but will subscribe people as well, all in one click.

Please note that this feature requires scripts version 9.31 or above in the server and the kiosks.

There are some special things to understand when setting up a single-prim subscriber.

  • (9.41 and below) When a kiosk owner clicks their kiosk, if the .subscriber script is in the main display prim, TWO menus pop up. One is the normal owner menu, the other, the subscriber menu (if they are already subscribed). This can be a little confusing to kiosk owners, so just be aware of that.
  • You have a few different ways to give out items when the kiosk is clicked - these can be a little confusing.
    • To give out items whenever the kiosk is clicked for any reason, put items in your server as normal.
    • To give out items to new subscribers only, use the groupgivenew setting in the server.
    • To give out items to kiosk owners when they rez your kiosk (or click Help from the owner menu) use the kioskInstructions setting in the server.
    So using various combos of those options you can give out items when certain things happen. Note that subscribing in this case also means a normal click, unlike a kiosk that has a separate subscriber button.
  • I recommend that you remove the givemessage setting in the server, otherwise that message is given every time someone clicks the kiosk.
  • I highly recommend you take a look at the sample One Prim Subscriber in the kit. It is configured as a simple working example you can use to get started.

(9.41 and below) NOTE: Do not confuse this configuration with the special SasTech Special Subscriber Kiosk! That special kiosk is NOT a normal kiosk, which means, it does not show up in your kiosk list online, and you cannot update the textures on it, ever. I highly recommend you stick with a normal kiosk so that you get all the tracking and benefits of a normal kiosk.

Building a Custom Kiosk

If you are building a kiosk from scratch, all you need to do is copy all the scripts from any of the sample kiosks in the package into your kiosk, then configure your "!Kiosk Settings" notecard correctly, and you'll be up and running. There are three steps to copying all the scripts from a sample kiosk to your custom kiosk:

  1. Copy everything from the root (display) prim of the sample kiosk into your display prim. I highly recommend linking your kiosk so that the display prim is the root prim to make things easier. If you ever plan on using the payments feature to collect money, you must link the display prim to be the root prim. Also, drop the scripts in one by one, not all at once. I have seen very weird things happen when too many scripts are dropped into a prim at once.
  2. Copy everything from the sample banner prim into your banner prim, if you have one.
  3. Copy everything from the sample subscriber button into your subscriber button, if you have one.
  4. Now edit the !Kiosk Settings notecard in your display prim and customize the appropriate settings. Be sure to give your new kiosk your own unique kioskStyle setting. As you add/remove prims, be sure to change the prims setting as well to keep the number of prims accurate. If it is not, the kiosk may attempt to unlink some prims! if you are ever asked for link permissions and your kiosk is NOT in AUTO mode, click NO and go check your prims setting in your kiosk notecard, it's probably wrong.

For KioskNet Versions 9.3 or lower, do not put the following scripts into your root prim. They must be in a separate prim. The .Banner and .Visitors scripts should be together, in a separate prim, and the .Subscriber script must be in a different prim as well, or these scripts will not work correctly.

For KioskNet versions 9.4 and above, the .Visitors and .Subscriber scripts can be put into the root prim with the other kiosk scripts.

Where Do They Go? Here is a quick summary of which scripts go where:

  • .Main Kiosk - root prim. Required.
  • .Settings - root prim. Required.
  • .Touch - root prim. Required.
  • .Textures - root prim. Required.
  • .DataProcessing - root prim. Required.
  • .Linker - root prim. Required.
  • .Payment - root prim. Only required if you want the kiosk to take any kind of payments. I would suggest leaving it in just in case you decide to run a donation drive of some sort. It can be turned on and off at will, but can't ever be turned on if the script isn't in there :) It remains completely inactive and will not contribute to sim lag other than the fact that it is a non-active script.
  • .Visitors - banner prim. Only required if you want your kiosk owners to be able to use the visitor counter. I'd highly recommend leaving it in so that they can take advantage of this free feature.
  • .Banner - banner prim. Only required if you have a banner prim and want to use the teleport and/or website buttons. One very good alternative to usingn a banner prim is to set up your kiosk in VIRTUAL mode and design all your teleport/website buttons (such as social media website buttons) on a single prim.
  • .Subscriber - subscriber button prim. Only required if you want people to subscribe to your subscriber list. For KioskNet 9.4 or higher, you can put the .subscriber script into your main display prim. This essentially converts the kiosk into a fancy, dedicated subscriber kiosk. I highly recommend you do not give out any items on click if you put the .subscriber script into the main kiosk - if you do, whenever someone clicks the kiosk to get the subscriber menu (for example to get previous messages resent) they will get the kiosk items every single time. I'd recommend using the "groupgivenew" setting in the server to give out items only after someone subscribes. You should also make the server "givemessage" setting blank, or they'll get that mtessage on every click as well. See the "KioskNet Fully configured sample - Single Prim Subscriber" object in your kit for an example of how to set up a single-prim subscriber kiosk.

(9.41 and below) Don't forget, the main display face of your kiosk must be face 2. Use the tip above to figure out what face 2 is. Make sure face 0 is on top so it is "right side up".

Tip: One way to get texture faces: Edit your kiosk, use the "Select Texture" edit tool, select the face, and press Ctrl+Shift+Alt+T. This will tell you the the face number you currently have selected.

One last crucial step I highly recommend you do once you are happy with your kiosk and ready to send it out—do a Reboot from the kiosk menu to reset the scripts, wait a minute for it to settle, then pick it up as your master kiosk ready for distribution. This ensures the scripts are all in a known, fresh state when rezzed by your customers.

I do recommend building your own kiosk from scratch, or at a minimum, replacing the display prim of one of the sample kiosks with YOUR prim. The reason for this is that I am contacted frequently to supply kiosks that are not mine, because the kiosk builder used one of my prims as the root prim, so I show up as the kiosk creator. If you use one of your prims for the root prim, you will show up as the kiosk creator instead of me, which will make it easier for people to contact you for a kiosk.

As you manually texture your other kiosk parts, keep prims to a minimum and texture sizes in mind. If you texture everything on your kiosk with 1024x1024 textures, it's going to take a long time for people to see your kiosk. If your kiosk has a lot of prims, you will get pushback from your customers that have tiny shops and limited prims. Always offer a "low prim" 1-2 prim poster version of your kiosk for those on tight prim budgets on small parcels.

If you would like me to personally review you kiosk before shipping, I'd be happy to! Simply send me a kiosk and I'd be glad to check it for any potential problems and give you some suggestions to consider to improve your kiosks. This can help you avoid big problems down the road so don't hesitate to send me a kiosk to review before you release them!

Kiosk Lag

I have extensive experience managing lag on a sim so I'm well aware of the causes of lag. I've tested the kiosks extensively for lag issues, however there are certain inherently laggy things, primarily scanners (the visitor counter) and texture loading that cause lag.

I have about 30 kiosks set up at my store, all of them connected and fully functional, and the sim right now is running at .99 time dilation. A blank sim with absolutely nothing on it runs at 1.0 time dialation, so there is just about zero lag caused by all the kiosks (and a few servers to boot). The kiosks are usually doing absolutly nothing until they report in once every 2 hours, then there might, if the server has been updated, some activity as the kiosk updates, but other than that it's not doing anything.

The visitor counter can cause a very slight amount of script resource usage. If the visitor counter is on, it does one scan, but only every 60 seconds, so maybe a tiny bit of script resource usages every 60 seconds in that case.

You can also see exactly how much script resource usage a kiosk is using by using the estate manager debug menu. Any other gadget or method to measure script resource "lag" by a specific object will not give you accurate results.

 Another cause of lag is texture flipping with huge textures. As you know it really lags a sim to load huge textures, and it's certainly possible you could load up a server with a ton of huge textures then set the texture flip time to a small number so that the kiosk is contstantly rotating to unloaded textures that need to be loaded, especially on a kiosk in MULTI mode with lots of display faces. That would be a really bad kiosk design :) but it's really the most likely cause of lag  by the kiosks. This also includes the textures/sculptie maps used on the kiosk itself. If you have a kiosk with 20 prims that all use 1024x1024 textures on it, the sim is definitely going to lag as soon as anyone gets near that kiosk. In a few minutes (literally, it may take that long) after all the textures are loaded, the load on the sim should decrease. You can watch textures load by hitting control+shift+3 if you ever suspect you are causing texture lag on the sim.

So to sum up, make sure that all textures on your kiosk are as SMALL as possible without sacrificing quality, don't use 1024x1024 textures in your server unless absolutely necessary—again as small as possible without looking all blurry. Don't use the visitor counter—it is OFF by default (for lag consideration), your users need to explicity turn it on, so they make a conscious decision to add a bit more lag for the benefits of the visitor counter. Use plain prims instead of sculpties if possible, that's one less texture to load, and your kiosk will look pretty weird while the sculpt map is loading.

Kiosk Menus

By default, the kiosks will show a MENU to the owner of the kiosk so that they can carry out basic maintenance tasks. This menu is DISABLED when the kiosk is in test mode, which you can set in the !Kiosk Settings notecard. In that way you can see exactly what the kiosk does when a normal user (not the owner) clicks it. Here are the kiosk menu functions from the owner menu. These have proven to be extremely helpful when maintaining a large network of kiosks owned by other people:

Help: gives the kiosk owner custom instructions (as defined by you) from your server on how to configure their kiosk, or any other help info you want to give them. This help is just a notecard that you drop into your server. You specify the name of the notecard with the kioskInstructions setting in your server.

Refresh: forces the kiosk to get updated data from the server. This will also happen automatically, if needed, when the kiosk receives a normal click, and every two hours when the kiosks check in with the server.

Click: Lets the owner do a "non-owner" (normal) click to see how the kiosk works for a non-owner.

Payments: This is only used if your system is set up in SUBSCRIPTION payment mode. This is how your customers will find out how much their weekly subscription payment amount is based on the number of kiosks they own.

Reboot: reboots all the scripts, in case something has gone haywire.

Version: Tells you what the version number of the kiosk is.

Memory: shows free script memory.

Click Counts

The kiosks each keep a count of clicks in the description field of the kiosk object. This number can be zeroed out at any time the kiosk owner wishes to reset the counter. This will not affect the global click count displayed in floating text above the KioskNet server.

This data is available on the website as well in your kiosk list so you can see how many clicks each kiosk has gotten since being rezzed.

The Server also keeps a running count of ALL kiosk clicks in the description field of the Server. Just set this field to zero if you want to start counting all over. As an example you might want to zero this out every time you publish a new issue of your magazine so that you can see how many total magazines you have distributed since you published the last issue.

Advanced Kiosk Modes

The KioskNet kiosks are very powerful and operate in multiple modes to fit almost any need. The kiosks will literally morph into different types of kiosks on the fly, so you never need to go replace any kiosks if you try different modes. To enable these modes, just set the kioskmode setting in the !Settings notecard of your server and the kiosk will automatically reconfigure themselves as appropriate.

Here are all the different kiosk modes. Expand the Advanced Kiosk Modes topic on the left to jump around to the various descriptions.

  • SIMPLE - gives out everything in the server on kiosk click. Multiple textures will rotate as a slideshow on a timer.
  • SIMPLEARROW - same as SIMPLE, but you can click the arrow buttons to cycle through the textures manually as well.
  • CYCLE - same as SIMPLE but can be configured to give out different things depending on which texture is clicked.
  • CYCLEARROW - same as CYCLE but you can click the arrow buttons to cycle through the textures manually.
  • AUTO - will rez prim buttons and arrange them on the kiosk automatically. Each button can have one or more textures shown like a slideshow. Each texture on each button may give out different objects.
  • MULTI - like AUTO but the buttons are not automatic, you create the kiosk with a fixed number of clickable, textured buttons. In effect this is a kiosk with multiple display faces. Each display face can have one or more textures shown like a slideshow. Each texture on each button gives out different objects.
  • VIRTUAL - The most powerful and flexible mode. Buttons are defined as "virtual" clickable areas on the display. You can have up to about 100 clickable areas on the kiosk. This mode also supports buttons that are URLs, SLURLs, or any secondlife:// style URIs.

The best way to see these kiosks to help you decide which mode is best for you is to either rez some of the fully configured kiosk networks in the package and see how they work, or visit my store to see what they look like and get an idea of how they work.


In simple mode, the kiosks will display the textures found in inventory in the server and give out all objects in the server's inventory when the kiosk is clicked. Textures will automatically cycle based on the cycletime setting in the server. This is the best mode for simple applications such as a basic magazine distribution kiosk that gets updated once a month with a new magazine issue object and a new texture for the kiosk. All that needs to be done is to change the items in inventory when you want to update the texture shown and the objects given out. No additional notecard configuration is needed.


This mode is the same as SIMPLE mode with one difference, it allows you to show two user-defined navigation arrows so that kiosk users can cycle through the available textures manually. The textures are read from the server contents so there is no special additional notecards to configure for the textures. The arrows are not prims, they are a special texture defined in the !Settings notecard with the arrowtexture setting. This texture should be a transparent texture with whatever kind of arrow graphics you want to put on there.

In order for this mode to work, you MUST have face 2 be your forward facing display face on your kiosk.

This mode causes the kiosk to morph into a special object that allows the two texture laters—the arrow texture and the regular display texture—to be layered on top of each other, so that your normal display texture shows behind the arrows on the top layer.

Note that this mode cannot be used in a "double-sided" kiosk. Due to the texture layering trick, you cannot view it from the back side, so you will be limited to single-sided kiosks.

Here is an example of a kiosk in SIMPLEARROW mode with the special arrow texture overlaid on top of the display:

The user can simply click the left and right arrows to pick the different textures. Clicking on that texture above the arrows causes the server to send all of the items in the server inventory, just like SIMPLE mode.

Your special transparent arrow texture is set by putting the UUID key of the arrow texture in the "arrowtexture" setting in the !Settings notecard.

To define the two vitual arrow button regions on your arrowtexture, you set the "leftarrow" and "rightarrow" settings in the server. To define these buttons, use the special buttonMaker tool. Rez the buttonMaker tool and click Help for details.

Note that the first number in the parameter lists after the '=' for leftarrow and rightarrow is the face number, which must be 2.

IMPORTANT NOTE!! In order for this mode to work, the main display prim will automatically reize itself to .02m thick. This CANNOT be undone. The height and width of your display surface will not change but the horizontal width will *appear* to be slightly narrower, though in reality it is not. What this means is that if you are using mutiple faces on your main prim to display textures, you should NEVER use this mode or your main prim will be permanently resized to .02m thick!

Simplearrow mode also has one option to allow you to tell the kiosks to automatically return to the LAST texture found in your server's inventory after a set amount of time. So for example that could be your main display texture that tells people to click the arrow buttons to see more information, and the kiosk will automatically return to that last texture after a few minutes of inactivity (no clicking). To turn this mode on, set the backtofirst setting to TRUE. When this is TRUE, then the cycletime is not used for automatic texture cycling, but is instead used to specify the timeout value to return to the last texture after that much time of inactivity has passed.


Use this mode if you want the kiosk to cycle through multiple textures on the kiosks on a timer but give out different objects depending on which texture is clicked. In order for this to work, some configuration is needed. See the !Cycle notecard in your server to associate lists of objects to give out with specific textures for this mode.

The data in the !Cycle notecard is in the following format:

#, texture_name,(object list/URL)

Where (object list) is a comma separated list of objects to give out for that texture or a single URL to a website. For example, to give out objects named myLandmark, myFreebie, and myFreebie2:


This will cause the items in the server named myLandmark, myFreebie, and myFreebie2 to be given out when myTexture is clicked.

Another example (V9.3 or later):


That will send  people to that website when myTexture is clicked.

 You need one line for each texture that is in your server.

To configure how fast your textures will flip on the kiosks, go set the cycletime setting in your server's !Settings notecard. You might experiment with a quick flip time like 15 seconds while testing, to make sure things work.


This mode is a variant of the CYCLE mode and is configured exactly the same as the CYCLE mode above, also using the !Cycle configuration notecard. In addition to the textures changing on a timer, they are also controlled manually by the kiosk user by clicking on the left and right arrows shown on the kiosk. The arrows are not prims, they are a special texture defined in the !Settings notecard with the arrowtexture setting. This texture should be a transparent texture with whatever kind of arrow graphics you want to put on there. This texture will be laid on top of the normal display texture using a special technique so you will see both layers—the normal display texture on the bottom with the mostly transparent arrow texture on top.

In order for this mode to work, you MUST have face 2 be your forward facing display face on your kiosk. Note that this mode cannot be used in a "double-sided" kiosk. Due to the texture layering trick, you cannot view it from the back side, so you will be limited to single-sided kiosks.

The user can simply click the left and right arrows to pick the different textures. Clicking on that texture above the arrows causes the server to send all of the items in the server inventory, just like SIMPLE mode.

Your special transparent arrow texture is set by putting key of the arrow texture in the "arrowtexture" setting in the !Settings notecard.

To define the two vitual arrow buttons on your arrowtexture, you set the "leftarrow" and "rightarrow" settings in the server. To define these buttons, use the special buttonMaker tool. Rez the buttonMaker tool and click Help for details.

Note that the first number in the parameter lists after the '=' for leftarrow and rightarrow is the face number, which must be 2.

IMPORTANT NOTE!! In order for this to work, the main display prim will automatically reize itself to .02m thick. This CANNOT be undone. The height and width of your display surface will not change but the width will *appear* to be slightly narrower, though in reality it is not. What this means is that if you are using mutiple faces on your main prim to display textures, you should NEVER use this mode or your main prim will be permanently resized to .02m thick!

Cyclearrow mode also has one option to allow you to tell the kiosks to automatically return to the FIRST texture defined in your !Cycle notecard after a set amount of time. So for example that could be your main display texture that tells people to click the arrow buttons to see more information, and the kiosk will automatically return to the main texture after a few minutes of inactivity (no clicking). To turn this mode on, set the backtofirst setting to TRUE. When this is TRUE, then the cycletime is not used for automatic texture cycling, but is instead used to specify the timeout value to return to the first texture after that much time of inactivity has passed.


In this mode, the kiosk will rez actual prim buttons that can be clicked on. In this mode, you can display up to a maximum of 64 items, all showing on the kiosk at once, that can be clicked to give out different things. This is a great mode to use for a freebie vendor if you have lots of items you want to be able to give out. In addition since each button has its own texture, you can have some great looking buttons on your kiosk that can show a lot of detail as users zoom in if you use a decent size texture on each button.

The data in the !Auto, notecard is in the following format:

button_name, texture_name,(object list/URL)

Where (object list) is a comma separated list of objects to give out for that texture on that button, or a single URL to a website. For example, to give out objects named myLandmark, myFreebie, and myFreebie2 when the texture myTexture is clicked on the button named button1:


This will cause the texture named myTexture to be put on the button named button1 and the items myLandmark, myFreebie, and myFreebie2 will be given out when myTexture is clicked on that button.

Another example (V9.3 or later):


That will send  people to that website when that texture on that button is clicked.

You can use any button names you want. Short names are better—using long names will take up more kiosk memory.

Note that you can actually have more than one texture per button—just define another line for that button with a different texture and objects to give out.

The buttons are rezzed, named, and arranged on the kiosks automatically. This is very useful if you will be changing the number of items you plan on showing on a frequent basis. Be aware that in this mode, your kiosks need one prim per button defined, so with a lot of items (buttons) you can start to use a lot of prims. This mode is just as easy to configure as the other modes, just drop in all the textures and objects just like the previous modes and configure everything with the !Auto notecard. The advantage is that all of your objects are all shown on your kiosk, there's no page flipping to see all the items. You can resize your kiosk in any direction and the buttons will automatically be rezzed in the right shape.

NOTE: in this mode, the prim buttons are ONLY rezzed in front of FACE 2 on your main display prim (where the kiosk scripts are stored).

There are some important things to consider if you want to use this mode:

  1. There may not be enough prims on the parcel for the buttons to rez. In this case it will fill up the parcel and the kiosk will be missing buttons. If this happens, the kiosk will keep trying to rez more buttons every two hours. If you give these kiosks out to other people, and they don't have enough prims to support the kiosk, you will have problems.
  2. The kiosks require LINK permissions to work. The kiosk will ask the owner for link permissions every 2 hours until they click YES on the link permissions request dialog.
  3. The land parcel MUST have the Groups checkbox for "Create Objects" in the parcel options dialog on the Options tab checked. If the kiosk, which must be a member of the land group, doesn't have rez permissions, no buttons will rez and the kiosk will not work at all. The kiosk owner will get an error every two hours if this option isn't set and the kiosk is set to Auto mode.


MULTI mode is very similar to AUTO mode, except that the kiosk does not manage rezzing, resizing, and arranging of the buttons for you. Instead, the kiosk looks for existing buttons with specific object names matching those defined in your !Auto card in your server. This is very handy for building a kiosk that has multiple display faces that are arranged any way you want and anywhere on the kiosk. You can have up to 63 display prims in a MULTI mode kiosk, and like AUTO mode, each can rotate textures and give out different things depending on what texture is clicked.

The data in the !Auto notecards is in the following format:

button_name, texture_name,(object list/URL)

Where (object list) is a comma separated list of objects to give out for that texture or a single URL to a website. For example, to give out objects named myLandmark, myFreebie, and myFreebie2:


This will cause the texture named myTexture to be put on the button (prim) named button1 and the items myLandmark, myFreebie, and myFreebie2 will be given out when myTexture is clicked on button1.

Another example (V9.3 or later):


That will send  people to that website when that texture is clicked on button1.

To make this mode work, you must have one or more display prims that have object names that match the button names in your !Auto card in your server. You can simply edit links on your kiosk and name the individual display prims to match those button names. Be sure keep aware of which face is going to be textured on each of your display prims! That setting is controlled by the Texturefaces setting in your kiosk.

One important setting to note that is different than other modes is the kioskprims setting in your kiosk's settings notecard. In MULTI mode kioskprims should be set to the total number of prims minus the number of display prims. For example if you look at the preconfigured sample MULTI kiosk network in your KioskNet kit, in the kiosk settings notecard kisokprims is set to 2. This is because of the 18 total prims on the kiosk, 16 of them are display prims, leaving 2 prims for the "base" of the kiosk.


In this mode, you get the best of both worlds—low prim kiosks and as many buttons as you want to show with as many sets of objects as you want, all on a SINGLE prim, but with a little bit more work.

There are two steps you must complete to set up this mode. First, your virtual buttons (clickable areas) must be defined on your texture, which should contain buttons drawn right on it, anywhere you want. Secondly, you define what to give out when that virtual button is clicked. The Virtual buttons are defined in the !Virtualbuttons notecard in the server, and the defintions of what to give out when they are clicked are in the !Virtual notecard in the server.

Defining Virtual Buttons

To define your virtual buttons, you need to use the special virtual button designer gadget called the buttonMaker tool included in your package to give you your definitions that go into your !Virtualbuttons notecard. The !Virtualbuttons notecard defines the specific areas on your texture that can be clicked, and gives those areas names. Please read the documentation on the buttonMaker for details on how to define your buttons.

Defining What To Give

To define what you give out for each virtual button, you use the !Virtual notecard in the server. The data in the !Virtual notecard is in the following format:

button_name,#,(object list/URL)

Where button_name is taken from your !Virtualbuttons notecard, and (object list) is a comma separated list of objects to give out for that texture or a single URL to a website. For example, to give out objects named myLandmark, myFreebie, and myFreebie2 when the virtual button named button1 is clicked:


Another example (V9.3 or later):


That will send people to that website when button1 is clicked.

Once you have your virtual buttons defined, don't forget to drop your texture with your buttons on it into the server so that the kiosks will be textured with that texture, and remove all other textures in the server. The server will simply use the first texture it finds for the kiosks in this mode.

Note that although it is not possible to texture your kiosk with different textures on each face (which faces are textured is controlled by the settings card in the kiosk), you can actually configure the virtual buttons on different faces of your display prim to give out different things. Each face can have unique buttons, unlike all the other modes above. The only catch is that each face must use the same texture.

NOTE! The very first parameter for each button in the !Virtualbuttons notecard is the FACE of the prim. Be careful, if the face you are putting your virtual button textures on is different than the face you textured on your buttonMaker tool, you will need to manually correct the face. For example if you texture face 2 of the buttonMaker tool and define a button, then on your kiosk you texture face 3, you'll need to manually change that 2 to a 3 in the button definition so that the correct face is specfied. In short, make sure the face numbers for all the settings are always correct!

(9.44 and above) You are required to define a button named DEFAULT in your !Virtual card. Put some kind of default item or URL there to give out if someone clicks a random spot on your kiosk that is not part of a defined virtual button.

(9.44) In-world Group Join Virtual Button

A new pre-defined button is available to use in VIRTUAL mode to cause an in-world group join message to be sent by the kiosk. With this feature, instead of forcing everyone to get a group join request with every click, they can just click a specific button you define for the request. To define this button, you first defined the button corrdinates as usual in your !VirtualButtons card in the server. Then for that button in your !Virtual card, you give it a pre-defined action of GROUPJOIN. For example, if your button is defined as "myGroupJoin=2, 0.314730, 0.033019, 0.693193, 0.100495" in !VirtualButtons, then in your !Virtual card, you set the action like this: "myGroupJoin, GROUPJOIN".

And now when that button is clicked, you'll get a normal in-world group invite as defined in your server !Settings card (groupJoinMsg setting).

Common Items Setting

There is ONE exception to the common notecard format for the CYCLE, CYCLETEXTURE, AUTO, and VIRTUAL modes. For these modes, you can define one special line at the TOP of the list of button/texture lines in your notecard to supply a list of items to be given out regardless of which button/texture is clicked. In other words, a common item that will ALWAYS be given out no matter what button or texture is clicked, in addition to the items defined for that specific button/texture. This line must have a button name of "common", followed by a comma, then a comma-separated list of objects to give out.

For example, let's say you want a notecard named welcome_note and a landmark named LM1 to be given out for all textures defined in your notecard. Then you would define your common line like:


Let's say that one of your many lines defined for CYCLE mode is the following:


This line means that if the January_texture is clicked on the kiosk, you want the January_issue and January_freebie objects to be given out. Now since you have 2 common items defined, that means that both the common items (welcome_note and LM1) and the January_issue and January_freebie objects will ALSO be given out to the clickee in this case, so he will get a total of 4 items.

Shared Media Support

You can display ANY web resource on your kiosks for customers to interact with directly on the kiosk. Websites, videos, Google documents, spreadsheets, games, ANYTHING. Using the CYCLE mode, you can now specify a mix of textures, URLs, and even inline HTTP in your "!Cycle" configuration notecard in the server. Normally the !Cycle config card has the following format:


To show shared media, the format is very similar, except that you can simply replace everything after "#," above with an HTTP URL. So for example to show HTTPS:// on your kiosks, you would merely add a line to your !Cycle config card like this:


and now that web page will be on rotation with the rest of your textures, so you can cleanly have a combination of textures and web pages to show.

Instead of a texture name or URL, you can also put actual HTTP code right into your !Cycle notecard and it will be displayed on your kiosks. This is great for a very simple message that you want to display on the koisks. To do this, use the special "data:" tag instead of the texture name. For example:

#,data:text/html,<p style="font-size:10em;color:Green;text-align:center">Hello World!</p><p style="font-size:3em">This is an example of some inline HTML inserted directly into the <b>!Cycle</b> configuration notecard.</p>

What this will do is display all the HTML after "data:text/html," right on the kiosk as if it were a web page.

A new server .settings notecard setting has been added named "noSharedMedia" which is a UUID of a texture to display to avatars that are either running a client with no Shared Media support or have Shared Media turned off. You can rez the new fully configured "Shared Media" sample to see the texture (turn off shared media in your client to see it).

There are a few limitations of this new Shared Media feature to be aware of:

  • Since a prim face that has Shared Media displaying on it cannot react to touch events, it is not possible to give out items from the server when someone clicks the display face showing Shared Media. What the kiosk does is zoom and center on the first click, and any clicks after that will interact directly with the web page displayed. No touch event is sent to the scripts in the kiosk at all. This means that the object_list parameters are invalid in your !Cycle card entry if an http: or data: entry is there.
  • Shared Media will not let you navigate to "external" web pages, so if you display a web page that contains a link to another domain, that link will not work, but you can navigate to pages in the same domain.
  • Due to limitations of the Shared Media LSL functions, it is not possible to set shared media on other prims in the kiosk other than the one containing the main KioskNet scripts. In other words, for the KioskNet system, you can ONLY show shared media on the MAIN display prim on face 2. You can't use Auto or Multi mode to show multiple web pages on one kiosk. Remember, Shared Media ONLY works in CYCLE mode!
  • Because of the limitations with Shared Media reacting to touch events, and the tricks used to show the arrows in CYCLEMODE without using additional prims, you CANNOT use standard CYCLEMODE arrows to allow people to flip Shared Media on the kiosk. However there is a solution! You must use CYCLE mode, which normally does not show any arrow buttons, but I have supplied two scripts in the Shared Media sample kiosk that you can use to create a set of prim navigation arrows. So the cost is two more prims to add to your kiosk, but they will allow users to flip textures on your kiosk in CYCLE mode using Shared Media. I would highly recommend using the new arrow prim buttons and a cycletime=0 (no automatic cycling) setting in your server if you display interactive web pages. The last thing you want to happen is to have a web page someone is clicking disappear on them!

Visitor Counter

A powerful visitor counter is included in the standard kiosk scripts (in the banner prim). This is a great feature for your customers. The downside to this feature is that if one of your customers wants to use it, they need to do a little configuration. The good news is that it's easy and doesn't use messy and confusing notecards, but a simple bullet-proof web page. The kiosk owner menu has two related buttons: Configure and Visitors. They must click the Configure button that takes them to a simple configuration web form to set up their visitor counter, the counter range, the IM they want to give visitors, the list of gifts they want to give out from their kiosk, and an optional folder name to put the gifts into. When a customer rezzes a kiosk, they will NOT be forced to configure their kiosk, it's entirely optional, so be sure to tell your customers about that, ideally in the notecard you give out on kiosk rez.

The Visitor button will take each kiosk owner to their own custom web page to see their visitor stats. By default the kiosks will be configured with the visitor counter off. The reason I think it's best to have the visitor counter off by default is lag. With the default being on, you'll wind up with a bunch of people that don't care about the visitor counter and probably have no idea it's even there (it will only spam the kiosk owner once after a reboot). But if any of your customers wants to use it, they can easily turn it on and take advantage of the visitor counter and the nice reports. Network admins can also see consolidated visitor data for all their kiosks out in the field.

The visitor counter uploads all visitor data between midnight and 2am SLT so after 2am all your visitor stats will be updated.

NOTE that I highly recommend you give your banner prim a new name—edit the banner prim link (using "edit links") and set the prim name like "Joe's Greeter" so that the IMs that visitors get will be coming from a prim with a customized and recognizeable/branded name

Kiosk Script Compatibility and Integration Guide

In general, it is most likely a very bad idea to add additional scripts to your KioskNet system kiosks or server. If you want to add some additional functionality, and you have the source code to the scripts, please send me a copy and I'd be glad to see if there are any compatibility problems.

There are quite a few things that may cause very bad problems with the KioskNet scripts. For this reason there is a very good chance that the scripts you want to add (which includes scripts in linked prims!) will cause serious problems with the KioskNet scripts.

Here are all the things any additional scripts must never do:

  • The scripts cannot send any link messages in the 100-200 range to any prim.
  • You must not add any textures to the kiosk contents.
  • The scripts must NOT set the script access PIN.
  • They must not set any prim parameters whatsoever, this will interfere with the "arrow" modes.
  • They must not set any textures, alpha, or color on the display prim.
  • They must not make any HTTP calls.
  • They must not set floating text—it will be turned off.
  • If they do a listen or a menu, there is a very small chance there will be a listen channel collision. This can usually be fixed by rebooting the kiosk.
  • They must be able to survive a script reset with no ill effects. The reboot menu item will reset ALL scripts in the main kiosk prim.
  • The must NOT require group ownership (deeding to group)—this is not allowed by the KioskNet scripts.
  • They must not receive email.
  • They must NOT call llAllowInventoryDrop().
  • They must not create or break links with other prims (lllBreakLink() and llCreateLink()).
  • They must not set or get the object description (llSetObjectDesc()).
  • If you are using the Payments module (for kiosk donations or subscription payments) they cannot accept money, request debit permissions, or call llSetPayPrice().

If you absolutely must integrate some no-mod scripts in the kiosk, you can send the list above to the scripts to the script writer and have them check their scripts for compatibility.

If you want to integrate another product's scripts into your kiosk, it may be possible if those scripts are in a linked prim. In that case there is a much smaller set of no-no's for scripts in linked prims:

  • The scripts cannot send any link messages in the 100-200 range to any prim.
  • If they do a listen or a menu, there is a very small chance there will be a listen channel collision. This can usually be fixed by rebooting the kiosk.
  • The must NOT require group ownership (deeding to group)—this is not allowed by the KioskNet scripts.
  • They must not create or break links with other prims (lllBreakLink() and llCreateLink()).
  • If you are using the Payments module (for kiosk donations or subscription payments) they cannot accept money, request debit permissions, or call llSetPayPrice().

Texture Pre-Loading

If you link in a fully transparent prim named "preLoader", it will automatically be used to pre-load textures so that your texture flipping for customers is instant - no more blurry textures as they rez on your kiosk! To test that it's working, you'll need to flush your SL cache and relog to see that the textures are not showing up blurry any longer when you switch textures.

Be sure to note the following tips on making a good preloader:

  • Don't make your preloader prim too small—make it at least half the size of your kiosk display area, otherwise the texture may not load.
  • Put your preloader right next to your kiosk display prim.
  • Always make sure your kiosk is phantom, then it doesn't matter where your preloader prim is, avatars will just walk right through it. Phantom prims reduce lag, too.
  • Make your preloader prim fully transparent so no one sees it, this will not affect texture loading.
  • Preloader prims only work with kiosks with a single display surface, so don't bother with kiosks in MULTI or AUTO mode.

"Ring" Add-on Kiosk

This allows you to create a traditional "ring", where one location leads customers to the next one, with a free gift provided for each customer at each location. For this to work, each location needs two kiosks—the "main" regular kiosk, and the special additional ring kiosk.

The general idea of how this works is as follows. Your main KioskNet kiosk is like the "welcome" kiosk at each location. Every time someone teleports to the next location in the ring, they will land in front of the main kiosk (unless the parcel has a forced landing point, of course). From there the customers search for the special ring kiosk, which might be placed at the building exit, or on the back side of the entrance wall so it can be seen on the way out, or perhaps hidden for a hunt. The special ring kiosk contains a freebie that the location owner has put into it. When the customer finds the ring kiosk, they click it. When clicked, the ring kiosk gives out the freebie inside it and pops up a map to the next location in the ring. The customer clicks the teleport button and off they go!

There are no Landmarks needed for this system. Landmarks are bad, they can't be automatically updated, so do not bother putting landmarks into anything. The system will always send customers to a valid location when they click the special ring kiosk—it's all automatic!

For your ring to work, both the main kiosk and the special ring kiosk must be rezzed on the same parcel. If a location has a main kiosk and no ring kiosk, the ring will be broken at that point since there is no obvious way for people to get to the next location (however see below about the Emergency Teleport Donut).

The ring membership is all automatic and controlled by the main kiosk. To add someone to the ring, all they need to do is rez the main kiosk and the special ring kiosk. If the main kiosk is ever removed, that location will be removed from the ring after a few hours, so the ring automatically "heals" itself if a kiosk disappears or if the sim goes offline, etc. Likewise if someone rezzes a main kiosk on their parcel, they are immediately inserted into a random location in the ring.

There is no special configuration needed for the main kiosk at each location. You can use any standard kiosk configuration/mode for that kiosk. For the special addon ring kiosk, here are the settings in the .settings notecard found in that kiosk:

  • floatingText: This is the floating text to show above the addon kiosk.
  • notify: this will cause the kiosk owner to be IM'd if someone clicks the kiosk.
  • parcel_key: this is a special setting if you have a location that needs to place the addon kiosk on a different parcel than the one the main kiosk is on. What you need to do in this case is have the kiosk owner put the parcel key where their main kiosk is located into this setting for all addon ring kiosks that are not on the same parcel. To get the parcel key, go the parcel containing the main kiosk and rez the included "Your Parcel Key" object and it will tell you the parcel key. I highly recommend you look at the sample "Help" notecard included in the Ring addon box for an example explanation you can give to your kiosk owners.
  • website: an optional URL to give users that click the addon kiosk
  • groupKey: an optional group key to invite users to join when the click the addon kiosk
  • server: this is the key to your Ring update server (see below)
  • myID: this must match the myID value from your server(s). Note that you can have multiple kiosk networks in the gallery ring (see Server Groups below). The ring will be composed of all kiosks with this myID value.
  • version: your addon kiosk version (used by the addon kiosk updater, see below)
  • giftRequired: if set to TRUE this will pester the addon kiosk owner if they have not put an object into the addon kiosk for the free gift.

The Ring Kit also contains an update server so that you can easily update the Addon kiosk if necessary. To set up updates properly, you need to rez your Ring Updater server somewhere safe where it will not be picked up (it is not keyless like the KioskNet servers are). Click the updater to get the updater's key, and put that into the Addon kiosk's "server" setting in the .settings notecard. Now the Addon kiosk can communicate to the Update server to find out if there is an updated Addon kiosk or not.

When your first Addon kiosk update is ready, make sure the version setting in the kiosk is one more than the current released version, drop it into your updater, then update the Updater's .settings card with the Addon kiosk name and the new version number and the Updater will start sending out updates automatically.

Also included in the kit is an "Emergency Teleporter Donut" object that can be given out to ring users on the small chance that they wind up on a parcel that is missing either the main kiosk or the special ring kiosk to get to the next location. They can use the Emergency Teleporter Donut to get to the next location easily. Simply put your myID value into the .settings card of the Donut and it will be ready to go, and you can give that out to your ring users so they never get stranded.

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.

New! V9.3: You can now have your customers (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.

Kiosk Donation Mode Settings

By setting your payment_mode setting to DONATION in your server, you can enable your kiosks to accept payments. This is idea for collection donations for a fund drive or charitable organization. All of the settings are documented directly in your server's !Settings notecard, please see that for details. Using those settings, you can set the $L amounts you want to show up on the standard pay dialog, who will receive the donations (one or more people using any percetages you want), the message that people will receive when they pay money, the floating text (which can show total donations and is updated every 2 hours) and an optional item to give to donors when they pay the kiosk.

This mode can be turned on and off from the server as well as any of the above settings, and all of your kiosks will update within 2 hours with your new settings.

Full reports of each payment are available on the KioskNet website, and if you have any requirements to match up all the payments from that report with the standard LL transaction history, please contact me for help, I have some Excel/Google spreadsheet macros that can make that audit almost totally automatic.

I have taken great pains to avoid any hacking or fraud with the kiosks, however there are certain limitations with LSL scripting and the way that money payments work that can't guarantee that everything will work perfectly with any payment system. But these kiosks are as safe and reliable as you can get and will stop accepting payments immediately if anything wrong is detected to avoid fraud or loss of payments.

New! Support for Teams has been added. To enable teams, first you need to define some teams. Go to your kiosk view and on the Reports menu is a Payments menu item. Go there. That page is where you will see reports of all payments made to your kiosks. On the Payments page is a "Teams" menu item. Click that to define some teams.

Now you need to configure a specific kiosk to be a member of that team. Simply add a "teamname" parameter to that kiosk's !Kiosk Settings notecard. For example:

teamname = Sasun's Raiders

Will create a new donation team named Sasun's Raiders. All donations made by anyone to a kiosk with that setting will be tagged with that team name in your payments listing online. From the Payments page you can see all the donations and team names in the Team column there. You can click on the Team Totals menu to see totals by team, and also you can click Teams to add and delete teams.

(9.44) Payment Mode Settings

A simple, single-item vendor mode has been integrated into the system. You can have your kiosk owners drop an item into the kiosk to sell. This is a great way to run a charitable donation drive where your kiosk owners can put an item in to sell and have all of the proceeds to go the avatars you have configured in your payeeInfo setting in the server (split percentages).

To enable vendor mode, set payment_mode = VENDOR in your server settings card. When you do that, the amounts setting is ignored, and the kiosk owner must set the price they want to sell their item at by clicking the kiosk to get the owner menu and clicking the new Set Price button.

You can also attach another prim to the kiosk that can act as a "click here to pay" type button, which works in all payment modes. In the kit is a sample kiosk set up in Vendor mode. If you look in the attached prim on the left, there is a very simple script named ~Vendor in there that simply changes the default click behavior to "pay". Drop that in your optional "pay" button/prim on your own kiosk and all buyers need to do is click that button to see the pay dialog, very simple and effective. If you do not have a separate pay prim, anyone can always pay the kiosk by clicking "Pay" from the pie menu, so a separate pay prim is never required. A separate pay button is very convenient since your kiosk owners can texture it with an ad for the item for sale so buyers can see exactly what they are getting.

Note that in VENDOR mode, the system does not report any money donated that is paid to the kiosk owner. So for example if you set: "payInfo = OWNER, 50%, <your key>, 50%" So that the kiosk owner keeps 50% of any payment, and someone pays L$100, then in your payment reports online, you will see a payment of L$50, not L$100, since the kiosk owner retained half of the money paid in. That way you can see the actual amount you've earned, and not money paid to the kiosk owner that you never see.

Kiosk Subscription Mode Settings

The new subscription mode allows you to charge a weekly fee for "value added" services you provide to a set of customers. Membership in your service is determined by kiosk ownersip—each kiosk owner can be charged an ongoing fee for your services. The kiosks make it very easy to know who is current with their subscription payments and who is not, so you can take appropriate action. For example, let's say that you maintain a list of fashion stores that you publish on your website. As a value added service, the stores in your network can post advertisements to your group and enjoy group events and fashion shows that you organize. Each customer must have one of your kiosks advertising the network on display and must be current on their subscription fees to enjoy the membership benefits. Your kiosk list will show you exactly who is up to date on their subscription payments and who is behind to help you manage the services you provide.

Do not confuse this with the Subscriber Group feature, this is very different! There are no way to collect fees for someone simply subscribing to your kiosk subscriber group.

To set up to collect subscription fees, set the payment_mode setting in your server's !Settings notecard to SUBSCRIPTION. For the amounts setting, you need to decide on three important numbers for your fees:

Base amount: This is a "flat fee" for all subscribers. Use this if you want to charge every kiosk owner the same weekly rate, no matter how many kiosks (locations) they have.

Per additional Kiosk: This how much you want to charge for someone that owns more than one kiosk. For each kiosk (location) you can charge an additional fee.

Cap: This is the maximum amount anyone will pay.

You can combine these values in any way you like in your amounts setting to structure your subscription payments however you like. For example if you want to charge a base rate of 50L/week, with 25L for each additional kiosk, but a max weekly rate of 200L, your amounts setting would look like:


If you want to charge a simple flat rate of 100L, it would look like:


If you want to charge 25L per kiosk with no max, set up a base rate of 25 (one kiosk) with 25 additional per kiosk. It would look like:


One important concept to realize is that the system assigns subscriptions to PEOPLE, not kiosks. It doesn't matter where the kiosks are, or even if any kiosks are rezzed for that subscriber. Once someone pays a subscription fee, time is tracked for that PERSON. If they pay for one week, pick up their kiosk, and rez it 6 days later, they will show up on the kiosk list as having one day left in their subscription. If they delete their kiosk that day and rez it somewhere else, they show up the same exact way in the kiosk list—one day left.

What happens when someone rezzes a kiosk connected to a server configured in subscription mode? Since they have not made an initial payment, they will immediately get this message:

"Warning! Your subscription has expired! Please click Payments from the menu to extend your services asap, thank you. You must now activate your subscription system by clicking Payments from the kiosk menu".

What they must do is exactly what it says, click their kiosk to get a menu then click Payments. What happens at this point is that the kiosk immediately receives information from the server about the kiosk owner's subscription, expiration date, and weekly fees based on your server settings and then gives this information to the kiosk owner, so they can see how much it costs per week to start their subscription. To do that, they simply pay the kiosk. The amounts shown on the standard pay menu are based on your server settings. The best way to see how this works is to try it yourself with one of the sample networks. Once they make a payment, they will be told when their subscription expires, and the number of days left will be updated on your kiosk list online.

Q: What happens when a subscription expires?

A: Every two hours, they will get this message if they are online: "Warning! Your subscription has expired! Please click Payments from the menu to extend your services asap, thank you." Other than that, the kiosk will continue to operate normally, giving out items when clicked, etc. It is up to you to check your kiosk list and chase down delinquent subscribers or discontinue services.

Q: What if I change my mind and want to stop charging subscription fees?

A: You can simply set payment_mode to blank ("payment_mode=") to turn off all subscription services. If you turn it back on again, everything will be back to subscription mode as if you never turned it off. No subscription information or days remaining is lost if you do.

Your KioskNet Server

This section contains information about your KioskNet server. All the configuration options are documented right in the !Settings notecard. Refer to that card to see what each setting means.

Your KioskNet servers are "keyless" servers—you can pick up your servers and kiosks and move them or re-rez them anywhere, any time. Everything will just reconnect after a moment and just work. You simply can't destroy the system. In case you lose your main server completely, you just rez another server, configure it, and with one click from the menu it will instantly take over as the main server for your network. You CAN'T screw it up beyond repair :)

Disaster Recovery

There is no possibility of disasters with the KioskNet system. If your KioskNet Server is ever returned to your inventory, just re-rez it, and click "Reg Server" or "Save". Disaster averted! If you completely lose your server, just configure a new one with the same myID value as your original, click the Reg Server or Save button, and you're back in business.

Make sure you pick up a copy of your server now and then to make disaster recovery extremely simple.

Server Automatic Fail-Over Redundancy

In order to avoid any down-time with your system in case the sim hosting your server goes offline for extended lengths of time, the system supports an automatic "fail-over" redundancy system using multiple servers that can take over automatically if any one server goes down or offline. How this works is very simple to set up, all you need to do is take a copy of your server and rez it somewhere else. That's it! If you have more than one server with the same myID and myServerID values, what happens is that they will each "take turns" as the main server in a round-robin fashion. The time that each server is actually the active main server is random, some servers may be the active server longer than others. What each server does each hour is check in with the website and assume control of the network, setting itself up as the active server. From that point on, all kiosk communication goes to that active server. So if a sim goes offline containing one of your servers, no problem—the other servers will continue checking in and assuming control of the network.

What I would recommend you do is get your primary server all set up and when you are happy with the configuration and changes, just take a copy of it into inventory, go to your "backup" location, delete the old backup server there, and rez a fresh copy of your main server. You can rez more than one "backup" server if you like, for more redundancy.

Since each server checks in once an hour, if currently-active server is in a sim that goes offline, your system may be down for an hour at the most, but sometime within the next 1-60 minutes, one of your other servers will assume control as the active server and your network will be back up and running. If you notice that one of the sims containing one of your servers is down and your network is not working, you or any admin can go to one of the other servers and click Reg Server or Save from the menu and it will take over as the active server and your network will immediately be back in operation.

Please note that your Watchdog timer will not alert you if one of your servers is down—as long as at least one of your network servers is up and running, your watchdog server will report "OK" for your kiosk network status.

It is absolutely critical that each server is an exact copy of your main server. If they are configured differently, this will result in your kiosks updating excessively over and over every 2 hours, which is an enormous amount of traffic going to and from your server over the long run, so make sure the servers are identical. It's easier to just make a copy of your server and replace the old ones with new copies than to try to keep each one configured the same, unless the changes are very simple. Just make you don't get bit by autoreturn when you are rezzing copies of your server!

There is one important caveat to remember, and that is that the server click counts shown in floating text above each server are NOT reset when you rez a copy of a server. If you want to maintain accurate total click counts, you need to remember that each server will be keeping click counts separate from the other servers (it is not some kind of shared number). I recommend you zero them out (set the server description field to 0) when you rez a backup copy, then if you ever delete a backup server, save it's click count so you have a record of all the clicks that individual server handled since it was last reset to 0.

Another thing to be aware of is that the only server in your set of redundant servers that shows on your dashboard is the currently active (registered) server. The other servers do not show on your dashboard. If you want to make sure that each server is working correctly, you can simply manually register each by clicking Reg Server from the server menu. If it registers with no errors, it's working.

Moving a Server

You may simply pick up your server at any time and rez it somewhere else. Just rez, wait for it to reload all the settings, and when the server says "SERVER READY" click the Reg Server or Save button and you're back in business.

Adding Server Admins

You can have multiple people help manage your server and network of kiosks online. They will have full power to manage your kiosk system, just like you. Here is how you add someone:

  1. Configure your server and add your admin avatar names to the "Other Managers" setting. List more than one person by separating their avatar names with commas. Note! all names are case sensitive!
  2. Wait for the server to read all the settings and say "SERVER READY".
  3. Now have your new admin click your server and click Dashboard from the menu and go to the Dashboard page.
  4. It will ask them to log in. They need to create an account by clicking the Create New User link under the User Name and Password boxes.
  5. Once their account is created, have them go back to the server and click Reg Avatar or Connect Me from the server menu to link their avatar to their account. It will take them to their new dashboard page.
  6. Now click on the server again and click Reg Server (or Save). This adds them as an admin for that specific server.
  7. They should then be able to see that server in the "My Servers" list of servers after refreshing that web page, and you should see them in your "My Admins" section of your dashboard for that server as well. They can now see that server's kiosks as well in the Kiosk View.

If there are additional servers that your admin needs to administer, all you need to do is the following steps to register them on additional servers:

  1. Edit the !Settings notecard and add them as an admin.
  2. Have the new admin click that server after it reboots and select "Reg Server" or "Save".

Note: only the server owner or people listed in the server "Other managers" setting will get a menu when they click the server. No one else can operate it at all.

Tip: you can have members of an SL group manage your in-world server (changing contents, settings, etc.) by doing the following:

  1. Edit your server and set the server's group setting to the group you want to give rights to edit your server.
  2. Make sure "Share with group" is checked on the server.
  3. Set the properties on all the items in the server and set "share with group", including any server settings notecards or anything else you want them to be able to update. Now, if your admin is wearing that same group tag, then can edit the server, update items in the server, and edit any server notecards that are shared with that group.
  4. Be careful that you don't cause the server to autoreturn by setting the group on the server to something other than your land group. I recommend sharing the server with your land group if possible so that the server won't autoreturn, otherwise you'll need to turn autoreturn off if the server is shared with a different group.

To delete other admins:

  1. Configure your server and remove them from the "Other managers" setting and save.
  2. Go to your Dashboard and look at your kiosks for that server. The admins are all listed just above the kiosks.
  3. Click the red X button to the left of the admin you want to remove.

Server Groups

A Server Group is a logical cluster of servers that all use one database on the website. Each server in the group shares the same subscriber group, the same click statistics, and everything else connected with that particular myID value.

Server groups are very handy in a few situations, for example, you can run two incompatible network (server + kiosks) versions side by side using the same database. So for example you can migrate your V8 network to a V9 network by adding a V9 server to the Server Group. The two servers, and the kiosks connected to them, are incompatible, but the systems can run side-by-side using the same set of data stored on the server.

It can also be very useful for expanding past the 1000 kiosk limit (or in some cases, the limit may be lower if you show a lot of textures on the kiosks). If your server shows a consistent red light on the front, that means the machine is maxed out on the number of HTTP requests it can make and is overloaded. The way to fix this is to simply rez another server, add it to the Server Group (by giving it the same myID value) and stop giving out kiosks connected to the old server. That will help spread the load across mutiple servers, and using this technique you can grow limitlessly.

Another reason to use it is this allows you to distribute more than one kiosk using a specific mode. For example you can have one kiosk style that uses CYCLEARROW and another that uses VIRTUAL. Just set up two servers, set them to the two different modes, and add them to the same server group.

To set up a server group, all you need to do is make sure they have the same myID value and different myServerID values. That's all there is to it. All kiosks that connect to those servers need to have the same myID and myServerID values. Note that this is a new feature of the V9 system, however, you CAN put an older V8 system into a server group. For a V8 system, you can't specify a myServerID - but the system uses that server's myID value as the myServerID. So if you had two servers, one a V8 and one a V9, and set them both to myID=Joe's Real Estate, then the myServerID for the V8 server is automatically set to Joe's Real Estate. So then you can give your V9 server a unique myServerID (say, Joe's Real Estate 2) and they are now in the same server group.

HTTP Throttling

The KioskNet system can handle any amount of incoming communication from the kiosks, but there is an SL limitation on the frequency of outgoing communication that the server can send to the kiosks. The system is designed to NOT lose any data in this case. What the server will do is throttle responses to the kiosks so as not to send too much data in a short period of time (which will fail due to the SL limitation). When this happens, the green light on the front of your server case will start to turn red. The redder the light on the left is, the more throttling is being applied, which means you have a lot of communication being sent from your server for some reason. Also, a number will show up above the server showing the amount of throttling going on. As time goes on, if communication traffic decreases, the system will slowly lower the throttle amount to speed things up. If you had a temporary spike, the throttle will eventually go back to zero (no response delay), which is the idea situation.

There are a few things that can cause throttling. The primary cause is too many kiosks attached to that server. If you are consistently being throttled, you may need to split your network into two servers. See the Server Groups section above on how to set up a new server and put it into the same Server Group so you can split your network load across two servers.

The other cause is too many textures. In order to be able to flip textures very quickly on the server, the server has to send a complete list of all the texture keys to each kiosk. Due to size limitations in the amount of data that the server can send to each kiosk in one shot, it may need to split up the data into 2, 3, or even 4 chunks and send them as separate messages to the kiosk due to the number of texture keys and other data it needs to send. This can impact the maximum number of kiosks you can have attached to your server. The only way to know when you're at the limit is if your server throttling is consistently above zero. In that case your server is just overloaded and your network needs to be split.

The good news is that periods of high data traffic are usually temporary, and caused by you making a change in your server. Over the course of the next few hours after you update your server, as all the kiosks check in, there will be a lot of communication as the server sends out data to all the kiosks with the changes. However once a few hours have passed and all the kiosks have received the changes, the amount of traffic will slow dramatically and the server should be able to handle a lot of kiosks with no problems.

Other Server Notes

Q: What happens if I delete a server from my Dashboard web page?

A: Your system will stop working. This is easy to fix, though, simply click your server for the menu and click Reg Server or Save. You will be back to normal. No data will be lost.

Putting Kiosk Data on Your Website

You can put various lists and charts on your own website by following the instructions below. If you'd like to show some data on your own website that can't be done with one of the following, please let me know!

Kiosk Listings

You can easily show a list of all your kiosks on your website, like this example. Using the following HTML code you can include a simple automatically updated list of your locations on your own web page. A location will disappear if a kiosk is gone more than 5 hours so you never need to worry about keeping it accurate.

<iframe scrolling="auto" width="1000" height="500" marginwidth="0"
marginheight="0" frameborder="1"

Replace the word YOURID above with your myID value for your system.

You can also replace the default font color "black" above with another color, and the background-color value of "LightGrey" with another background color. You can use color names or standard CSS color hex values from that color chart, however you must replace the '#' symbol with '%23', for example Blue would be specified as color=%230000FF.

You can control how many kiosks are returned with the count parameter, and the width with the width setting. You can also turn the frame border off with a frameborder value of 0 instead of 1.

Set your font size with the font-size parameter. Any valid HTML font size setting will work.

New! You can also take advantage of a new web listing format. This format is much more graphical in nature, and requires all your kiosk owners to drop a FULL PERM texture into their kiosks. That texture will be displayed on the web listing.

See the LEA Land Endowment list for an example of what your kiosk list could look like.

To use this fromat, use the following html on your web page:

<iframe scrolling="auto" width="100%" height="800" marginwidth="0"
marginheight="0" frameborder="0"
src="// TITLE&subtitle=YOUR SUBTITLE">

Replace "YOURID" above with your myID setting, and YOUR TITLE with whatever title text you want on your page, and the same for YOUR SUBTITLE. Optionally you can remove the &title and/or &subtitle options completely.

Alternatively, you can skip the iframe and simply link to that page directly:


Showing a Tiny Kiosk List

You can show a very simple list of your kiosk locations on your own website or blog by using the following HTML. This is ideal for a very small list of kiosk locations in a sidebar on your website. For example, if you have a Blogspot blog, just create a gadget in layout mode with the following code:

<iframe scrolling="auto" width="220" marginwidth="0" marginheight="0" frameborder="1" src="//"></iframe>

Do not copy the HTML source on this page for that line above! Your HTML source that you paste must have the '&' symbols in it just like it looks above. If they are all replaced with "%amp;", then it's wrong!

Replace the word YOURID above with your myID value for your system.

You can also replace the default font color "black" above with another color, and the background-color value of "white" with another background color. You can use color names or standard CSS color hex values from that color chart, however you must replace the '#' symbol with '%23', for example Blue would be specified as color=%230000FF.

You can control how many kiosks are returned with the count parameter, and the width with the width setting. You can also turn the frame border off with a frameborder value of 0 instead of 1.

This will allow you to have a small, clickable list of kiosks on your website or your Blogspot blog. This is a great way to help support the locations hosting your kiosks by sending customers to them.

Example: How To Show Your Kiosks on a Blog

You don't need a dedicated website to show your kiosk list. You can use a blog.  Here is an example on how to use the two techniques above to set up a permanent link to your kiosk lists on your blog. Other blogging systems may not allow you to use your own HTML in a gadget, so your mileage may vary with other blogging systems.

  1. Make a new post. Click the "Edit HTML" tag. Give it a title like "my Kiosk List".
  2. Grab the HTML in "Kiosk Listings" section above and paste that into your post.
  3. Replace YOURID in that HTML you just pasted with your actual myID setting.
  4. Click Publish Post.

Now we will make a mini-list in a new gadget.

  1. Click Design to get your blog layout screen.
  2. Click Add a Gadget in one of your layout's columns.
  3. Click '+' on the HTML/Javascript gadget to add it.
  4. Grab the HTML in "Showing a Tiny Kiosk List" above and paste it into your gadget.
  5. Replace YOURID in that HTML you just pasted with your actual myID setting.
  6. Click Save, then Save your template.

Now add one more gadget with a permanent link to your post of your kiosks.

  1. Click View Blog to see your kiosk list (there must be at least one existing kiosk rezzed and working properly for the list to show).
  2. Click on the title of the blog post that contains your kiosk list ("my Kiosk List" in the example above). This takes you to that post with no other posts below it showing. This is the "permalink" to that post. Copy the http address out of your address bar.
  3. Now go back to Design and add another gadget.
  4. Add the "Link List" gadget.
  5. Paste the URL you just copied into the "New Site URL" field.
  6. For the Site Name give it something like "Full Kiosk List".
  7. Click Save.
  8. Now in your Design view, arrage your gadgets so that the tiny list is just above your new Link List gadget.
  9. Save your template and view your blog.
  10. To give out a link to your permanent kiosk list, copy the link right under your tiny kiosk list and give that out. That is your permanent kiosk list page.

You can customize the colors and fonts in your kiosk listings to match your blog - see details in the sections above on how to color and font options. Just click the little tool icon next to your gadget to customize it.

Kiosk Payments

You can show a simple bar chart of all payments made to all your kiosks when you are using the Donation feature. This is great for encouraging competition with your kiosk owners helping with your charitable drive to see who can get the most donations, for example. To install a clickable chart of donation totals by kiosk, use this HTML:

<iframe scrolling="auto" width="800" height="600" marginwidth="0" marginheight="0" frameborder="1" src="//"></iframe>

If you are using Teams, you can show a chart of payments by team by using this HTML:

<iframe scrolling="auto" width="800" height="600" marginwidth="0" marginheight="0" frameborder="1" src="//"></iframe>

You can control the width of the colored bars on your page with the "graphwidth" parameter if you need to fit it into a smaller space. You can also replace the default font color "black" above with another color, and the background-color value of "white" with another background color. You can use color names or standard CSS color hex values from that color chart, however you must replace the '#' symbol with '%23', for example Blue would be specified as color=%230000FF. You can control the font-size by using one of the standard font-size settings.

Note that any kiosks that have been deleted or moved to another parcel will show up as "kiosk missing" in the bar chart. When a kiosk is deleted or picked up, the system loses the ability to uniquely identify that kiosk (which is done by kiosk key) so that contribution data tied to that specific kiosk becomes "stranded". If a kiosk owner picks up a kiosk and re-rezzes the same (or a new) kiosk on the same parcel, the system will automatically reconnect all the stranded data associated with the old kiosk that was on that parcel to the new one so the kiosk payment history will be connected to the newly rezzed kiosk. However if a kiosk owner moves the kiosk to another parcel, the system has no idea where the old kiosk was and from that moment on that old data shows up with "no kiosk" in the chart.

Known Issues/Bugs

Error: WARNING! I can't find when setting up a server in VIRTUAL mode and using a URL for a button

There is a known issue with https style URLs for VIRTUAL mode buttons. This requires a fixed script; please contact me for a fix. This bug was fixed in V9.4.

When designing a VIRTUAL mode system, you get an error: WARNING! A virtual button coordinate has been defined for button XYZ but that button is not referenced anywhere

There is a bug that causes any button names defined on your !Virtual and !Virtual Buttons notecards in your server that has upper case letters to be unrecognized. Fix: make sure all button names are lower case. Fixed in V9.4.

Server Error 404, 499, or 503 after a sim containing your kiosk restarts

Solution: upgrade your master kiosks to the 9.3 or later scripts and stop sending out pre-9.3 kiosks.

This is a long-running problem that has been affecting the system for years. After many many many hours of tracking this down, I have concluded it is a rare SL bug. The problem is that when a sim restarts, in some rare cases it does not send out notifications to all scripts on the sim (which it should). This is vital because when a sim restarts, all the URLs assigned to objects using HTTP to communicate (which the kisoks do) get invalidated, and all scripts are sent a special notification so that they can request a new, working URL from the sim. In rare cases this notification does not happen and the kiosk keeps the old (bad) URL. When the kiosk eventually reports in to the in-world server, the server can't reply because the kiosk's URL is bad, and whispers that there as been an error 404, 499, or 503 trying to communicate with a kiosk.

What I have done in the 9.3 release is to have the kiosks regularly check to see if they have a valid URL by sending an HTTP message to itself. If it fails, the kiosk will automatically get a new URL, fixing the problem next time the kiosk reports in. I have confirmed that this work-around does work and should greatly reduce the amount of 404, 499, and 503 errors you see being whispered by the server. For this reason I highly recommend you update your master kiosk to the 9.3 scripts and stop sending out kiosks with pre-9.3 scripts!

Floating text with no banner prim

Unfortuantely it's not possible to have floating text in DONATION or SUBSCRIPTION mode without a separate banner prim. One option you can use is to just link a very small or transparent prim above your main display prim for the .visitor and .banner scripts, and in your server !Settings notecard, remove all the settings in the Banner Prim settings section (by remove, I mean delete everything after the '='). That will stop the banner prim from being textured so it remains functional for floating text display. Note that in the initial V9.3 release you will get a script error with this configuration, please contact me for a hotfix to get it working.

Problem with '&' in myID setting

In some older releases there were various problems when using '&' as part of your myID name. As of the 9.41 release all known problems have been fixed except for one - if you are subscribing people via your kiosk, and have a '&' in your myID, please contact me for a patch to fix a known problem.


If you have any problems with your kiosks not updating, please read this FAQ:

Q: Why is there no hovertext option? I want hovertext over my kiosks!

A: Hovertext is usually a very poor option over putting the text on your kiosk texture or on the banner prim on top. Hovertext is just plain ugly, it doesn't look professional, it's impossible to position well, it bleeds through walls which completely annoys neighbors, it's impossible to adjust the height at all without using a separate prim... my earnest advice is... just don't do it! If you absolutely need it, you can drop in a simple hovertext script. But if you want your kiosks to look good, don't spoil a well-designed, classy, professional kiosk with hovertext.

Q: I need to shut down my kiosk network and I want all my kiosks to be deleted.

A: Please contact me directly for a special script I can give you that will cause all of your kiosks to delete themselves in-world.

Q: When I put my system into SIMPLEARROW or CYCLEARROW, my main display prim seems narrower and my transparent arrow texture hangs off the sides of the main prim. What is going on?

A: The reason it appears to be narrower is a side-effect of the special prim trick I'm using to get TWO textures to display on one side of one prim. The prim is not physically narrower, but the two sides of the display prim are a bit transparent. Your transparent arrow texture, however, extends the full width of the prim so it appears to "hang" off the edge. This issue is really visible with any of the framed kiosks that have prim borders around them. What I'd recommend you do is stick another prim that's the same exact size of the display prim immediately behind it, but make sure it not actually intersecting the display prim or the textures may not show correctly. That will help hide those gaps on the sides of the framed kiosks.

Q: Why does the "ignoreparcel" setting exist? I don't get it.

A: The kiosk system normally only allows ONE kiosk, per owner, per parcel. If another kiosk appears, the system attempts to merge the two kiosks in the database into one record—thereby preserving all the kiosk data. This will help you from seeing gobs of "duplicate" kiosks in your database, which would happen every single time someone picks up a kiosk and rezzes it again. When this happens, the kiosk owner gets this warning:

"This location has another kiosk registered in the database for the same parcel. If you just replaced your kiosk within the last two hours, everything is fine. If not, then you have multiple active kiosks on one parcel. You cannot have more than one kiosk per parcel owned by the same person. You MUST remove one, or contact the person you got this kiosk from for help."

Now the reason I send them to YOU for help is because there are cases where multiple kiosks owned by the same person on the same parcel may make sense. For example you may have someone that owns 3 kinds of stores on a sim that is just one huge single parcel. If they want your kiosk in front of all 3 stores, then you don't want them getting this warning every 2 hours per kiosk. So there is a setting in the kiosk's !Kiosk Settings notecard called ignoreparcel. What this does is basically turn off this multiple kiosk merge checking completely, which allows more than one kiosk per owner per parcel. So what you could do is, for special cases like this (and they are fairly rare), is set up a prepared kiosk specially for this case with ignoreparcel = TRUE set in the !Kiosk Settings notecard and have them just replace their kiosks.

The reason that this setting is worth all this trouble is because it saves you a ton of time in keeping your database of kiosks free of duplicate kiosks. However it is up to you to decide if you want to distribute ALL your kiosks all with ignoreparcel=TRUE already set, then there will never be any errors sent to people with more than one kiosk per person per parcel. There are downsides to doing this! If you do this, all click data, website link tracking data, vistor data, and payment SLURL data is immediately lost when a kisk with ignoreparcel=TRUE is picked up.

Q: What is the "time" column on my kiosk list?

A: That is the time since that kiosk last reported in. Under normal circumstances, it should not be more than 2 hours. Anything longer than that means something is wrong. There are quite a few reasons that a kiosk can stop communicating to the system:

  1. It was deleted.
  2. The owner didn't set the group on the kiosk to the land group and group scripts are off.
  3. The parcel owner turned off scripts completely.
  4. There was a random glitch, perhaps an HTTP call failed for random reasons. In this case the kiosk will get caught up at the next two hour cycle.
  5. The sim, or SL, is having problems.
  6. The kiosk owner deleted all the scripts out of the kiosk (it's happened) or set them all to "not running".

Here's how to troubleshoot a "dead" kiosk.

  1. The first thing to do is to click on the little blue "i" button for the kiosk on your kiosk list, which takes you to a kiosk detail screen. From there, click the URL entry. This is the URL of the kiosk itself. If it is working normally, you will be sent to a screen that says either "unknown command" (for older KioskNet versions) or "Kiosk is OK!" (for newer KioskNet versions). This means the kiosk is there and is communicating correctly.
  2. If this fails, the kiosk may have been deleted. Teleport out and see. Remember that fixed landing points and telehubs can make you land far away from the kiosk location - look for the red circle on the map and fly there.
  3. If you click the green Reboot button, the kiosk will reboot, usually immediately, but in some cases it can take a minute or two. This is a good thing to try if it's acting weird in any way. After a successful reboot, step one SHOULD work.
  4. If the kiosk is there but is not communicating, check the group tag on the kiosk, then compare that to the land group. Then check the parcel options and see what the script settings are. Are group scripts enabled? They must be enabled for the kiosk to work correctly, and the kiosk must be in the land group (if one is set).

Note that if you do not keep your kiosk list clean by deleting dead/missing kiosks from time to time, if you have a single kiosk that hasn't reported in for over a month, it will trigger a cleanup routine that will cause all of your kiosks that have not reported in within 5 hours to automatically be deleted from the database in order to keep clutter to a minimum. So if you want to follow up on any missing kiosks, do it before 30 days have gone by.

Q: Whenever my KioskNet server gives something to someone, if they decline it, they can see exactly where my server is! People keep dropping into my office, is there any way to hide that SLURL when someone gets something from the server?

A: Unfortuantely, no. That's an SL anti-griefing feature so that people can find bad objects that are spamming them and abuse report them. There is just no way to turn that off. What I'd suggest doing is moving your server to a private parcel, private sim, or stick it in a skybox with a security orb to keep out unwanted surprise visitors.

Q: Can I change my server's myID or myServerID setting? How can I "rename" my system?

A: You can't. The myID + myServerID settings are the unique identifier for your system, not the server object UUID. If you rename either one in your server settings, the system will see it as a NEW server and add it to the database. If you do that, you will see both the old myID/myServerID and the new ones on your dashboard. Remember that all your network data, such as click statistics and subscribers, are attached to your myID value. If you change that, all that data says with the old myID. The other problem is that you can't change all the myID/myServerID settings in all the kiosks, so once you set those values in the kiosk settings notecards and send out kiosks with those settings, you are stuck with them. So don't rename your server. During testing of a new network, you certainly can, just be aware that the net effect is that you're creating a new network and all data will be essentially lost. And be sure to delete your old servers from your dashboard :)

Q: I have a server group with two servers in it with myServerID = A and the other myServerID = B. Server A has a set of textures that are different from Server B. Is there any way to "swap" the servers so that network A will show the textures from server B and network B will show the textures from server A?

A: Yes, all you need to do is simply swap the myServerIDs in server A and B's settings notecard. Then all the kiosks attached to server A will switch over to server B and all the kiosks attached to server B will switch over to server A, effectively swapping what each kiosk will show. This is a nice way to sort of manually "chain" together sets of textures on the same kiosks once in a while. For example you could have all the content from server A show on A's kiosks for a week, then swap them to server B for the next week, and the same kiosks will show server B's contents that week. You could do this with any number of servers/networks. Even if the kiosks are using different kiosk modes (with some exceptions!), the kiosks will simply morph into the new mode on the fly!

V8 -> 9 Migration Guide

This guide will help you migrate from your V8 system to a new V9 system. Unfortuantely, there were some fundamental changes made to the underlying communication protocol to fix some bugs and add some new features that make the V9 system incompatible with the V8 system in terms of the kiosks talking to the servers. What this means is that a V8 kiosk can't talk to a V9 server and a V9 kiosk can't talk to a V8 server. So this means you can't just swap out your existing V8 server with a V9 server, which will cause your  old V8 kiosks to try to talk to the new V9 server, and they just can't. Very weird things will happen.

The V8 system is no longer receiving bug fixes of any kind and any issues should be resolved by immediately migrating to V9 as per this guide. I strongly recommend you start this migration now to start getting the new V9 kiosks out to your customers and deprecating the old V8 kiosks.

Note that on the website database, the V8 and V9 systems can coexist perfectly with your existing data (kiosk lists, subscriber lists, admin lists, click data, payment data, and texture click data). Using the new Server Groups feature you can easily run a V9 system in parallel with your V8 system and they will both "feed" the same database—on the website, everything will look the same—one list of subscribers, one list of kiosks, etc. Slowly over time you can migrate everyone to the V9 kiosks and eventually retire the V8 system. Just stop giving out the old V8 kiosks, only give out the V9 kiosks, and over time the V8 kiosks will slowly go away as they are deleted or upgraded by your users.

To do this, you'll need to run two servers (V8 and V9) in parallel for a while until you can retire the old V8 server. To configure an old V8 server and new V9 server to be in the same server group, simply set the V9 server "myID" value to be the same as your V8 server, and give the V9 server a unique "myServerID" value (it must not be the same as your myID in this case). Your two servers are now "Grouped" and will work with the same set of data on the website, so any new kiosks added that are attached to the V9 server will just show up in your existing list. I'd recommend giving your new V9 kiosks a new version number so you can see at a glance at your kiosk list how many new kiosks you have vs. the old kiosks.

Note that you can use an IM machine and set the kioskMode to OWNER to send out an IM specficially to your kiosk owners. So you can inform them about the kiosk upgrade and send them a new V9 kiosk from time to time to encourage them to delete their old V8 kiosk and rez the new V9 kiosk, which will essentially switch them over from the V8 server to the V9 server. You can use the kioskversion setting in your IM machine to only send notices to customers with old kiosk versions, so people that have already upgraded their kiosk won't get the IM.

Note that you can also take advantage of the new Server Redundancy feature to have multiple, redundant V9 servers, but this feature does not work with the V8 server, so in effect, the additional copies of your V9 server will be backing up only the V9 server, not the V8 server.

Version 9.4 Notes

Please see Known Issues for info on some bugs encountered with 9.x systems that are fixed in 9.4.

What's new:

  • IM notifications (first released in the 9.31 update). This feature gives you the option of getting an IM whenever someone subscribes to your subscriber list. It does not notify you when someone unsubscribes, however.
  • The groupKey setting has been deprecated (and ignored in 9.4) and a new setting replaces it: groupJoinMsg. This setting gives you more flexibility in giving someone a message to join your in-world group - you can now specify the entire message instead of being limited to just the key being customized. For example, this will ask people to join a sample group with the group key 8aa64b67-bebf-f81a-cb76-45260601a58f:

    groupJoinMsg = Please open your Local Chat window and click this link to our fabulous fashion group and get plugged into Fashion, Your Way! secondlife:///app/group/8aa64b67-bebf-f81a-cb76-45260601a58f/about

  • You can now specify the kiosk owner in a payment/donation split.
  • Added a reboot option on the server menu.

How To Upgrade Your Server

  1. Rez the Server upgrader from your KioskNet package next to your V9.0 - 9.31 server. This will not upgrade a V8 server!! Do not do that! If you do, you can just delete the scripts in your server and copy the old V8 scripts back into your server and you'll be fine.
  2. Click Upgrade from your V9 server menu.
  3. If you have multiple servers to upgrade, wait until the first server is done upgrading.
  4. Then edit the !Settings notecard in your server and add the following lines somewhere in there:
    //If you want an IM every time someone subscribes to your subscriber group, set this to TRUE. If not, set to FALSE.
    newSubscriberNotification = TRUE
    //Optional message to give people to join your in-world group.
    //Substitute your own group's UUID in this example string. Please note that groupJoinMsg is all ONE LINE
    //and may be wordwrapped! This line cannot be longer than 255 characters total.
    groupJoinMsg = Please open your Local Chat window and click this link to my fabulous group and stay informed about upcoming activities! secondlife:///app/group/d37357ae-ee38-719e-5604-49543f6d3c9d/about

  5. Delete everything after "groupJoinMsg =" if you don't want to ask people to join a group.
  6. Customize the message above for your group join message. To get your group key, find the old groupKey setting and copy it from there. Be sure to leave the "/about" part of the URL above where it is - just replace the UUID part.
  7. Now delete the following lines, which include the old groupKey setting, which are no longer needed:
    //Your group ID to display to clickers to ask them to join your in-world group when they click.
    //To get your group key, search for your group and click on your group name in the results.
    //Your group key is in the URL at the bottom immediately after "group/"
    //For example the key to the Art Gallery Owners group is 202c41c5-bde1-5e69-fa07-3aa9b0fde39b.

  8. Go to step 1 and repeat for each server.

If you don't know your group UUID, just use the search box on the upper right of any page anywhere on //, click on Groups on the left if you need to narrow it down, click on the name of the group in the search results, click the green More Info button, then look for "Link to this page:" and the group UUID is the last part following the last slash ('/'). For example if you see: "Link to this page: //", the group UUID is: 8aa64b67-bebf-f81a-cb76-45260601a58f.

Note that the server upgrade is compatible with old 9.x kiosks, you can upgrade the server and your old kiosks will continue to work just fine, so you are not REQUIRED to upgrade your kiosks if you upgrade your server. It is ok to have a mix of V9.x and V9.4 kiosks attached to a 9.4 server.

However the 9.4 kiosks are not compatible older servers, so you can't upgrade the kiosks and not the server. I highly recommend you upgrade all your 9.x servers, then simply rev your master kiosk by updating the scripts in your master kiosk, incrementing the version number in your kiosk settings notecard, and stop distributing the old kiosks. If you are using the MDOG kiosk requester, simply replace the old kiosk(s) in your MDOG server with the new ones. If you are not using the MDOG server to distribute your kiosks, I highly recommend you do so to make it real easy to simplify and consolidate all the various ways your kiosks are being distributed.

Your custom master kiosk must be manually updated. Remove all scripts from all prims in your kiosk. Grab the new scripts from any sample kiosk in the kit. Drop the scripts into the following locations:

  • .DataProcessing—display (root) prim
  • .Linker—same
  • .Main Kiosk—same
  • .Settings (new!)—same
  • .Payment—same
  • .Textures—same
  • .Touch—same
  • .Subscriber—your subscriber prim if you have one
  • .Banner—banner prim
  • .Visitors—banner prim.

After you upgrade your master kiosk, what I'd recommend is setting up an IM machine, put it in kiosk owner mode, and send out the new kiosk to all your existing kiosk owners with a version lower than your new master kiosk version to give them the option of replacing their old kiosk with the new one.

Version 9.41 Notes

This is a maintenance release to add a few features and fix a few bugs. Here is what is new and changed:

  1. Fixed a kiosk bug that causes donation messages and donation floating text to fail when one of the two replaceable parameters (<total> or <avg>) is removed from the message.
  2. New kiosk setting: Subscribe = FALSE stops people from subscribing via a kiosk. This is useful for invite-only private groups where you will be adding individuals manually. When Subscribe = FALSE the subscriber button works, but only for existing subscribers, so they can get resends or leave the group, but no one can add themselves to your subscriber group.
  3. Fixed kiosk bug that caused errors when a non-scripted prim linked to your kiosk was clicked, i.e. part of your custom kiosk structure.
  4. Fixed an obscure kiosk problem detecting virtual button clicks if the buttons are defined "upside down" with the buttonmaker tool.
  5. The Tour HUD can now support multiple kiosk networks, which can be chosen as different "categories" on the tour HUD.

SmartBot Integration

With the 9.41 release, integration with SmartBot has been added 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, please look in your original KioskNet package and look for the "KioskNet Smartbot addon" object and rez that. Inside is a notecard telling you exactly what to do:

  1. Delete the ".Settings" script in your server
  2. Drop in the new .Settings script from the addon box
  3. Drop the ".SmartBot" script into your server
  4. Drop the "SmartBots AdminBot Professional v1.6" script into your server
  5. (9.41 or earlier) Add all these lines to your !Settings notecard in your server (doesn't matter where):
    //Specify your group UUID here:
    SmartBotGroupUUID = 
    //This is your smartbot security code, go to //
    SmartBotCode = 
    //If you want to invite clickers into a specific role, specify that role name (not title!) here.
    //This setting is case sensitive and must be exact!
    SmartBotGroupRole = 

    To get your SmartBotCode, go to your SmartBot admin page and search for "security code" on that page to find the link to set it.

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.

Transferring A Kiosk Network to Someone Else

It is easy to "give" an entire kiosk network to someone else. If the system is a V8 system, however, it CANNOT be transferred over to a V9 server. What I will do in that case is give the new owner that just purchased a KioskNet V9 system an old V8 system so that you can transfer the system over intact. Once you have ownership you can then begin migration to a V9 system if you so prefer, or just keep the existing system as-is.

  1. The new owner must buy a KioskNet system so that they can have ownership of the new server and all the additional tools to run the network. If the system to transfer is an older version than the current retail release version you buy, contact me for help, there are complications with changes in settings, and compatibility issues, between various versions that I can help you with.
  2. The new owner sets up a server exactly like the current owner's server:
    1. Current owner: copy everything in the server except for the scripts to inventory. Give everything to the new owner.
    2. New owner: rez a new server and delete everything in it except for the scripts. Then paste everything the current owner gave you into the new server. When you do this, after all the settings are read, you will get errors about the myID being owned by someone else. Ignore that for now.
  3. Current owner: go to your Dashboard page by clicking Dashboard on your server menu.
  4. The current owner now picks up their server into inventory.
  5. The current owner, on their dashboard page, must delete the server.
  6. The new owner now must click Reg Server or Save on their new server to register that server as the active server. The entire network and all data is now attached to the new server.
  7. If this is a V9 system, make sure that there are no backup servers rezzed anywhere - once the old owner is no longer an admin, those servers will not be able to register as the active server, so there is no danger of them "taking" the network back. However if the new owner sets up the old owner as an admin, note that the old owner's servers could take the network back, sokn any backup servers sitting around should be removed asap.
  8. If there are other servers in the same Server Group (same myID but different myServerID values) those must be transferred in the exact same way since those are separate networks attached to a separate server.

Version 9.44 Notes

Version 9.44 is a major update that breaks kiosk compatibility with previous releases. This means that, unlike all previous releases, you cannot upgrade a 9.41 or earlier server with the 9.44 scripts, since your kiosks cannot communicate with your server. 9.44 servers require 9.44 kiosks or above. Version 9.5 servers are compatible with 9.44 kiosks, so in that case they do not need to be updated.

Many other changes have been noted throughout the documentation, just search on "9.44" to find version-specific notes on 9.44 changes.

KioskNet and Display Names

This is some important information on the new Display Names feature in Second LIfe.

First, a few definitions:

  • Username: For old users, it is your first name + "." + last name, all lowercase . New users DO NOT have a last name so their username is just the single name they set up when the signed up for SecondLife.
  • Display name: whatever you want. Does not have to be unique. Shows in the Name field for someone's profile in viewers that support Display Names.
  •  Legacy name: "firstname lastname". For old users, it's your old name exactly as it was before. For new users, this is Username + space + "Resident". So a new user with Username of Joe123 would have a Legacy name of "Joe123 Resident".

Currently, all of the existing LSL script functions in use by KioskNet use the Legacy names.

This change does not affect the operation of the kiosks. They will continue to work just fine with no changes at all.

Currently the KioskNet subscriber system only understands legacy names. It does NOT understand Display names or Usernames. So trying to add a subscriber manually, or via importing a list of subscribers, with a username only, i.e. "Joe123", will not work. However if you tack on "Resident" on the end of the Username, it will work, so the username "Joe123" would need to be added as "Joe123 Resident". I'm sure all existing subscriber systems in use today also use the Legacy Names so will most likely be totally compatible as far as importing lists of names from other systems into KioskNet. As usual the best way to import is via keys if possible, that way there is no discrepancy between names.

When looking at your list of subscribers at the KioskNet website, you will NOT see Display names or Usernames but the Legacy names only.

Avatar names anywhere else in the system, such as on charts, your dashboard, or any reports, follow the same rule—it is all legacy names.

In the latest release of the IM machine (V4 or greater), you can have the avatar's Legacy first name substituted for <fn> in your IM message. The name used will be the legacy first name, which for new residents is identical to their username. So if their username is "Joe123", then "Joe123" will be their first name for the purposes of the IM substitution.

More info on Usernames.

More info on Display names.

More info on Legacy names.

Linden Advertising Policy

LL has an advertising policy that you should be aware of. I've copied the specific rules I'm familiar with below with a discussion of some of the points as they related to the KioskNet System.

* We will allow no more than 50 advertising locations owned by a single individual, whether personally owned or via groups in which you are a member, unless you have written permission from Linden Lab to exceed this limit. Use of Alt accounts/groups to circumvent this restriction will be considered a violation.

In most cases, you will be distributing kiosks to other people, so unless you actually own all the kiosks yourself, this will not be a problem.

* In addition to the cap, we will allow no more than 1 advertising placement by an individual in any single region.

This might be an issue if your kiosk is considered an ad and you own a few of them in one region. See the official LL policy for definitions.

* We will not allow the land parcel containing the advertising placement to be set for sale.

This rule is very confusing, I am not clear if this means that real estate agents, for example, can't advertise their land parcels for sale or not.

* Adverts should be grounded to the terrain, not floating.

* Adverts should extend no higher than 8m from the ground.

* No rotating, no flashing content and no particles.

There is a potential issue with rotating textures, but the rule is unclear—I take this to mean "rotating" as applies to prims. So for example if you look at the kiosk sample with the scrolling text, I would not consider that "rotating" ads.

* No unsolicited dispensing of IMs, notecards, landmarks or content.

This may be a problem with the visitor greeter. The kiosk will only give out welcome gifts to people on the same parcel as the kiosk, so if you own or rent a store on your own parcel, this could be construed as a violation, but visitor greeters are extremely common and are usually for the purpose of giving visitors information about your location. Be careful you do not spam people with advertising with the visitor counter.

If your location is NOT on a single parcel, I highly recommend you set the range of the visitor counter to something appropriate so you are not spamming people far from your kiosk. If you are giving the kiosks out to other people, it will be up to them to turn on the visitor counter and configure it appropriately. They will be held accountable for any advertising they are spamming with your kiosk.

* No light sources or glow (full bright is acceptable however).

* Advertising boardings should be Phantom.

All KioskNet Sample kiosks are phantom by default. I highly recommend you make your custom kiosks phantom. This helps reduce lag.

* Adverts must be clearly PG in nature.

It is not clear to me whether non-PG ads are allowed on non-PG land. I don't see why not.

* No sound and no temp-on-rez content.

The sample kiosks do not make any sound or rez anything temp-on-rez. The kiosks in AUTO mode to rez prims (buttons) but those prims are linked to the kiosk and become a permanent part of the kiosk—they are not temp.

* Ban lines should be switched off.