Quistess Alpha

if you read the details in the page linked from the main article further, note that there's a specific region where users have to go to pay an in-world kiosk with their L$. I highly doubt that's scalable.

vs 2.5% before I believe. but you're not seeing the full picture. If that's all it was, you could just raise all your prices by 2.5% and, assuming equal demand, you'd break even. But you can't assume equal demand, because the price for people to buy the L$ that they're paying you has gone up, meaning L$ is "more valuable" to them because they paid more for it, and in a nice neat and pretty world, you might expect a 5% decrease in sales, on top of the decreased sales from increasing your prices*. *probably a bit more nuanced because percentages, math and economics are hard.

Taking both together, I'd have to presume it's ~exactly one region then. Although, since case-by-case support is involved to set it up anyway, anyone wishing to use it can always ask for specifics.

Here's the fine print: you have it backwards, at least one region, not up to. I.E. land barons please apply.

The more I think about this, the more it seems like "trickle down economics" or, "tax the poor and give to the oh so benevolent rich". As has been pointed out above, it's still infeasible to own a full region unless you're a land baron or representative of an active community. L$ "taxes" will effect the cost of everything, and an increased cash out fee is going to lead to L$ price inflation.

I won't disagree that JSON message passing is very useful when the message complexity warrants it, but communication protocol design could probably take up its own thread. For most of my actual use-cases, I've only needed a single 'command' and a list of arguments, which fits nicely into a 'comma separated value' string. string message = llList2CSV(["CMD",arg,arg]); // fetched from a listen event, probably. // ... later, in the receiving script: { list message = llCSV2List(message); // TIP: variable name overloading. string CMD = llList2String(message,0); if("Turn"==CMD) { rotation r = (rotation)llList2String(message,1); // CSV correctly handles rotations and vectors! llSetRot(r*llGetRot()); }else if("Say"==CMD) { integer channel = (integer)llList2String(message,1); string msg = llList2String(message,2); llSay(channel,msg); }// etc. } doing that with JSON seems like added complexity for little benefit, but to each their own, and in a different context I could really see a benefit: string message; message = llJsonSetValue(message,["CMD"],"Turn"); message = llJsonSetValue(message,["rotation"],"<0,0,0.71,0.71>"); // ... { string CMD = llJsonGetValue(message,["CMD"]); if("Turn"==CMD) { rotation r = (rotation)llJsonGetValue(message,["rotation"]); llSetRot(r*llGetRot()); }else if("Say"==CMD) { integer channel = (integer)llJsonGetValue(message,["channel"]); string msg = llJsonGetValue(message,["msg"]); llSay(channel,msg); }// etc. } (JSON uses a lot of static lists for arguments; I don't think you'll see a performance upgrade using it this way for this example.)

are the random numbers to disambiguate speakers/conversation pipes? why not use llRegionSayTo instead of whisper after the initial message?

If you have RLV on, you could try a script like: default { attach(key ID) { if(ID) { llOwnerSay("@detach:Center=force,detach:Center 2=force,detach:Top Right=force,detach:Top Center=force,detach:Top Left=force,detach:Bottom Left=force,detach:Bottom=force,detach:Bottom Right=force"); llOwnerSay("@detachme=force"); // simpler than requesting permissions. } } }

(not really sure this is a good place to be having this discussion, but I'll play along) If you've ever done any semi-involved work with a stack language like postscript, stack manipulation operations like dup, roll and exch (swap top 2 on the stack) are invaluable when making user-defined functions take arguments in an order that makes sense, but use them in whatever order for their internal operations, although you can probably get around it by binding arguments to function-specific variables.

Pre-LinksetData, transferring script-only configuration information was a major pain, and god-forbid something changed while the transfer was taking place. Yeah, if the thing in question is just a HUD and doesn't need a lot of personal prim-fitting, you could just use llRegionSayTo communication to pass config info from old to new version if there is any.

there's a specific button in the texture select menu to select a default 32x32 full white texture, next to the buttons for the default and transparent textures. There's also a white disk texture in the library folder intended to be used as a sun image that works pretty well for spot lights.

When "We should hang out again sometime" is actually a "Yes, really, lets set a time and date." instead of a vague "Let's add each-other to our lists and hope we might be on again at the same time and not be busy and actually notice if the stars align."

No, it's worse than that. I suspect there's some local-vs-server-misalignment involved, or some 'random garbage messages mess things up' like with the alpha mode glitch, but it's too spurious to make a concrete test for, and catching it "in action" with a observer-avi would be hard without the doer-avi being very clear about what they're doing and when. and or recording both simultaneously. ETA: and yes, it also happens at ground level, not only in skyboxes. (not that it should matter for texture offsets.)

Oh, looking at the debug settings for HUDs, "HUDScaleFactor" set to 2.0 (or some arbitrarily high number) effectively removes all HUDs. Enable advanced and debug options if you haven't, then Advanced-> Show debug settings -> search for "HUD"

The obvious "solution" would be to move your huds off-screen, say, by adding or subtracting 1.5 or so (after testing, the largest allowed offset for me is something like +/- 2.85, so if you want to remember what it was previously, try and keep the result lower than that but absolute value greater than 1) to the y component of their position. To get them back, you would have to right-click edit from inventory.

I also made a HUD a while back, but the UI wasn't very friendly. If you own the land, keeping something rezzed nearby seems more intuitive than finding a HUD in your inventory, and then remembering which button is for the location you're capturing. I believe there's an option to remove HUDs when taking a snapshot, but it can be disabled in certain RLV situations.

.

I don't usually ask questions here, so I'm not sure how the interface looks to the asker. Is there a way to mark a specific response as the "correct" answer?

If you have a question that is likely to have a direct answer, then go to the answers section is not a question, it's a discussion starter. llAttachToAvatarTemp() ~without an experience, could possibly be used for this, but I forget if non-experience temp attachments survive teleport. (experience temp-attachments dissapear after leaving the experience enabled area)

You would have to somehow direct it through a in-world checker. For example: customer buys a voucher on the MP, voucher sends a message to a server, server gives the object to the customer if they're not on the 'has already bought' list, and adds them to said list.

There are (at least?) 3 ways of transferring ownership of an object to another avatar: give them the object with llGiveInventory(list) have them buy the object (perhaps for 0L$), perhaps with the option set to sell the in-world object and not a copy. temp-attach the object. 1. is viable if you 'give to RLV' BUT, auto-wearing a thing given that way has some timing issues (most viewers are set up to ask confirmation when receiving directly to #RLV, and there is no feedback to the script if/when that confirmation took place) 2. is what ~I would do, for an in-world terminal. rez a separate updater object that is set for sale for 0L$. 3. doesn't require the updated person to have touch allowed, and could be completely automatic with an experience. assuming some automatic communication of version number by the HUD. ETA: llDetachFromAvatar() while an object is 'locked' with llOwnerSay("@detach=n"); (and having been granted the perms) ~should "update" the inventory so that crashes are less likely to destroy the update. (There's always the slight possibility SL decides to restore your avatar state to before the update. Nothing is 100% safe from bad things happening.)

In that case, I would sensor, then cast a ray at any avatars found to check for an object in-between. ETA: which is basically what was said above. RIP my reading comprehension.

AFAIK the "copy of the item in user's inventory" only gets updated when the object is detached or when ~cleanly logging out. When you log in, you re-wear everything you were wearing when you (cleanly) logged out, from inventory. So, if the inventory copy wasn't updated, the attached version no longer exists, therefore you "lose" its changes. The key point, is that even for a "no copy" object, the inventory asset and the attachment are separate things that only share info in limited circumstances. (For example, too lazy to check myself, but notice what happens if you rename a worn attachment in the inventory window, vs the edit window, vs via llSetObjectName() )

Some of my products are exactly that >.>