Techno Tip Cube - TipTracer - What to do if...

Cube Config Cube Operators

FAQ's Registration Basics What to know Data Transfer

TipTracer™ Considerations (technical stuff that might be helpful to know):

(Continued from TipTracer Introduction)

In order for your Techno Tip Cube to be working with the TipTracer system, it must be registered with the server and remain rezzed inworld. This enables the cube to "ping" the server. The purpose for this mechanism is to ensure the web server isn't holding abandoned data for people who -- for any variety of reasons -- are no longer using their Techno Tip Cube.

Q: What do you mean by a cube "pinging" the server?
A: It's a tap-on-the-shoulder to the server to tell it that a cube with a specific object key is still inworld, alive, and running.

Q: What do you mean by an object key?
A: Everything in SecondLife needs it's own fingerprint. That's what an object key (also called a UUID) is. Read Linden Lab's explanation by visiting http://wiki.secondlife.com/wiki/Key.

Q: So what happens when pinging stops?

A: When pinging stops, the data for that cube on the server side will begin to age. During this time, no new tip data is collected. And if no pinging is seen for 365 days, the data is erased. So it is important that all TipTracer users keep the following points in mind:

The TipTracer system only holds on to data for jars that are pinging the server. Anytime you or your operators click the cube to bring up the options dialog, the cube pings the server. Also, anytime someone tips into the cube, the server is pinged. As a safety measure, even if the cube isn't interacted with for an extended period, it pings the server every 12 hours. So with all that pinging going on, the TipTracer system is always aware of all your registered Techno Tip Cubes.
The server will automatically unregister a cube, and delete all underlying tip data associated with it, if a ping hasn't occurred for 1 year (365 days). Such a condition arises if a registered cube has undergone a reset and you forgot to re-register it with the TipTracer system within a year. Any of the following situations induces a cube reset:
- You took the cube into your inventory, and then re-rezzed it.
- You've updated the cube.
- You've selected to reset the cube for any number of reasons, most likely to reload the notecards.
- You got bored of Second Life and moved on to other things in life (shame on you!)
To re-sync your cube back with your TipTracer tip history, you'll need to re-register the cube within the 1 year grace period.

The TipTracer system keeps track of a cube's unique object key (also referred to as a "UUID"). If you take a cube into your inventory and then re-rez it, the cube will now have a completely different UUID. So after re-registering with the TipTracer system, it will be pinging the server under it's new UUID identity. From the server's perspective, it's an entirely different cube. How this effects you depends on whether you have the Copyable or No-Copy version of the Techno Tip Cube:

Owners of
Copyable
Version

Copyable tip jars that are re-rezzed from inventory have an entirely new UUID. This means that without any pinging from the original UUID, the server will eventually unregister it and delete it's older tip history after 365 days have passed. Directions below show how to re-link the data with the re-rezzed cube.

Owners of
No-Copy
Version

No-Copy jars have a recovery mechanism when they are re-rezzed with a new UUID, and it makes use of the cube's "Description" field. Whenever a No-Copy cube is registered with TipTracer, the Description field will be filled with text that looks like the following: "TipTracer [xxxxx]" (where xxxxx is some value). In contrast to an object's UUID, the description field remains intact after the cube is re-rezzed. When registering the cube with TipTracer, the description field is also sent to the server. When confronted with an unknown UUID, the server is then able to re-sync the existing TipTracer history with the new UUID.

Copyable tip jars do not have this mechanism, otherwise numerous jars could be rezzed with that same description. That would render discrepancies in your tip history data.

So to summarize, it's entirely possible for the TipTracer system to delete an entire history of tip information when:

If your cube is...	And you did this...	Then your resolution is...
Copy or No-Copy	You ran the cube's Reset function, perhaps because you changed something in a configuration notecard and need it to be reloaded.	Resetting a cube disables TipTracer. Re-Register the cube with TipTracer before the 1-year grace period expires. If a cube hasn't pinged the TipTracer system within that time, it's history is deleted.
No-Copy	You have used the Updater Object to upgrade your cube to the latest version. (click here for updater info).	Whether you update your cube or re-rez it from your inventory, either of those actions will reset your cube which, in turn, disables TipTracer registration. Re-Register the cube with TipTracer before the 1-year grace period expires. If a cube hasn't pinged the TipTracer system within that time, all of it's history is deleted.
No-Copy	You took a cube into inventory and then re-rezzed it, perhaps to move it to a new location.
Copyable	You took a cube into inventory and then re-rezzed it, perhaps to move it to a new location.	The cube is now inworld with a different UUID. From TipTracer's perspective, it's viewed as an entirely different cube. Here's what to do: Although not necessary, as an aid I recommend you rename your cube to distinguish it from it's prior existence. What's that mean? Well, if your cube is named "Joe's Tip Cube", then that's what the TipTracer system has it listed as. But now your cube has been re-rezzed with a new UUID. So rename* it to something like "Joe's Tip Cube -New". Re-Register the cube with TipTracer. At this point, TipTracer has two jars in it's system: "Joe's Tip Cube" and "Joe's Tip Cube -New". You will then need to use the Import utility to move all data from the original "Joe's Tip Cube" to it's newer incarnation now named "Joe's Tip Cube -New". Since the jars are named differently, you'll be able to easily distinguish them in the menu you'll see when clicking the Import button. (A picture of the import menu is shown in this page). After the history transfer, you can chop off "-New" from the cube's name. Then click the cube to bring up the options dialog. Doing that submits the cube's name to TipTracer, after which you can click Ignore to close the dialog. On the server side, there will now be two TipTracer entries named "Joe's Tip Cube", but the older one is no longer pinging the server (and, coincidentally, is now empty of historical data). For lack of pinging, TipTracer will eventually remove it.
	You have received an update and you want to replace your older cube with the new one without losing all the historical data for the old cube.	This is a similar situation to what's described above. So here's what to do... Rename* your new cube from it's default name "Techno Tip Cube". (I always forget to do this myself!)... Prep your Cube Config and MHS Operators notecards, then run Reset to load them. Now Register the new cube with TipTracer. Use the new cube's Import utility to move historical data from your old cube to your new cube. With no need for your old cube, you can simply delete it. There's no need to unregister your old cube. For lack of pinging, TipTracer will eventually remove it from the system.
	* When I say "rename" above, I'm referring to the SecondLife method of renaming objects. Right-click the cube, select "Edit", and change the value in the "Name" field.