Archive for July, 2009

Texture Change HUD

Completing my initial lineup of HUD scripts is my texture change HUD script pack. This script, intended for resale as part of finished products, allows an avatar to change textures on a prim by clicking HUD controls. It’s ideal for changing textures on hair, shoes, eyes, etc. (I also sell a complete texture, color and glow changing HUD script pack for L$1,000 if you need more functionality).

It supports almost unlimited textures (textures stored in prim inventory limited only by what the server will support, textures stored in-script limited by memory), and provides a preview of each texture. Although a sample HUD is provided, it is anticipated that must customers will want to build their own HUD, and full instructions are provided (HUD assembly is straight forward, with most of the configuration done by naming prims).

XStreetSL: https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1656704

inSL(tm): http://slurl.com/secondlife/Sunweaver%20Air/197/18/25

No Comments

Sample credit card bill

Just got my credit card bill through, which shows a live transaction I did while testing the PayPal vendor. For the curious, here’s what it looks like to the customer if they pay with a credit card:

heres one I charged earlier

To get it to show a meaningful store name, you need to set it with PayPal. Go to “Profile” (under “My Account”), then “Payment Receiving Preferences” under “Selling Preferences”, and finally look for “Credit Card Statement Name” at the bottom of the page.

No Comments

“Roomies” prim counter

Continuing my prim counter product refresh, I’ve just released a new counter for shared parcels. Unlike my first shared parcel counter, this one adds a whitelist of avatars who can see a detailed breakdown of prim usage for all avatars with prims on the parcel. It was designed for where several avatars “live together” as a group, and rent as a group. Avatars not on the whitelist can see their own prim allowance and usage, making it also suitable for non-shared rentals (and the detailed view could be used for rental managers or similar). Example output:

[2:07] “Roomies” prim counter demo whispers: Rita Mariner is using 1 prims.
[2:07] “Roomies” prim counter demo whispers: Xugu Madison is using 211 prims out of an allowance of 1000.

The script is configured purely through a notecard. You must have “owner-like” permissions on the parcel, to set up this script. That means either be parcel owner, or be an officer in the group the land is deeded to (apparently; have to admit I’m trusting the docs on that one).

What’s in the box?

  • A pre-made counter, with a simple grey texture, intended for wall mounting.
  • Full and detailed instructions

XStreetSL: https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1652122
inSL(tm): http://slurl.com/secondlife/Sunweaver%20Air/215/18/33

No Comments

Basic Prim Counter (freebie)

Just did a massive update to one of my freebies, as part of an overhaul of my prim counter range. It’s a prim counter to show prim usage across one or more parcels within the same region (sim/island). By default, it shows the parcel it is currently on, but can also show other parcels around the same region. It always shows total prims (excluding temp-on-rezz prims, which are a special case), but can optionally also show a breakdown of owner, group owned and other owned prims. Example output:

Basic prim counter 2.0: Usage report for parcel “Chess set at 400m” (http://slurl.com/secondlife/Sunweaver Air/27/40/403/):
Owner has used 44 prims.
Group have used 0 prims.
Other avatars have used 0 prims.
Total prim usage 44 out of a prim allowance of 500, leaving 456 prims spare.
Basic prim counter 2.0: Usage report for parcel “Xugu’s Script Store” (http://slurl.com/secondlife/Sunweaver Air/208/9/27/):
Owner has used 215 prims.
Group have used 0 prims.
Other avatars have used 1 prims.
Total prim usage 216 out of a prim allowance of 500, leaving 284 prims spare.

Configuration is entirely by landmarks and notecard. Comes as a pre-made counter, with a simple grey texture, intended for wall mounting.

Grab it from XStreetSL at https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=611783 or in-world at http://slurl.com/secondlife/Sunweaver%20Air/217/25/33 (top floor of my new shop is still work in progress, please don’t kick the clutter).

No Comments

PayPal vendor demo

Now up on XStreetSL, will be in-world (in my store) tomorrow: https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1645342

Free demo of my basic PayPal vendor. Supplied as copy-only, with a fixed transaction price of $1.49 (US), but is otherwise perfectly functional.

No Comments

PayPal vendors now available

The first two PayPal™ vendors are now available to buy in-world and from XStreetSL. In short, the versions are:

  • Basic: L$375, PayPal only (can’t take L$), one transaction at a time, configured by chat
  • Pro: L$750, PayPal and L$ vendor, concurrent transaction support, configured by notecard

You can buy them both at my new store being built at http://slurl.com/secondlife/Sunweaver%20Air/200/9/25, or from XStreetSL at https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1645342 (basic vendor) and https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1645351 (pro vendor).

These vendors allow you to take payments by PayPal(tm) or credit card (processed through PayPal), and have products in-world automatically delivered on receipt of payment. This has several advantages:

  • Customers don’t have to buy L$ and then buy your product, they can use their credit card directly.
  • For institutional customers (education, business, etc.) PayPal is likely to be much more compatible with their existing purchasing procedures.
  • Money arrives directly in your account in your currency of choice.
  • PayPal generates detailed receipts for both vendor and customer.

To use, customers click the vendor and are given a URL to complete the transaction, which they click in chat. This brings up a PayPay login page. The customer logs in, confirms the payment, and the vendor receives payment notification directly, and delivers the item.

There are drawbacks to PayPal, however. First of all, as with any method of making real money (for example, “cashing out”) from Second Life, use of this vendor may make you liable for income taxes and similar on money earnt. You should look into these matters for yourself, as I am not qualified to provide advice.

Secondly, PayPal will charge you fees on each payment received. The amounts depend on both your country and that of the purchaser. You can look up fees on PayPal’s website. For payments to the US, see: https://www.paypal.com/cgi-bin/webscr?cmd=_display-receiving-fees-outside&countries= and for the UK, https://www.paypal.com/uk/cgi-bin/webscr?cmd=_display-receiving-fees-outside.

You can realistically expect to pay $0.30+3.9% per transaction. Given this, it’s strongly recommended that you do not use this vendor for items cheaper than approximately $1.50. While these are very high fees compared to transactions in SL, or even on XStreetSL, they should be offset by higher sales from people not having to decide to convert money before they can buy from your store.

What’s In The Pack

Both vendors contain loosely the same components:

  • PayPal vendor script – with copy and modify permissions so you can even read the code; why trust a closed source product with your money?
  • Full and detailed documentation – and of course we support our products in case you find something we haven’t thought of
  • PayPal acceptance sign (subject to PayPal’s license on usage)
  • A sample vendor to get your started

What’s NOT In The Pack

A PayPal account; I’d strongly suggest that you have a PayPal account and have it associated with a bank account or credit card BEFORE you buy this vendor. No refunds will be given if you can’t get an account or have it disabled.

No Comments

BuilderBot is coming! Look busy…

Rezzable, having first announced they’re leaving the Second Life™ virtual world for OpenSim (y’know, I hadn’t even heard about them before they were leaving, how depressing is that), have now announced the release of BuilderBot, their toolset for converting Second Life content into OpenSim region ARchive (OAR) files ready for import into OpenSim. In short, this takes an entire sim, and converts it into a nicely packaged format ready for import into OpenSim. Unsurprisingly, content creators (especially those whose content you can copy, scripts are usually more resistant) are a little upset over this. I’m therefore going to make myself unpopular and say I think this is awesome.

Lets face facts here. The Second Life content controls have been cracked like an egg in a blender. Much bigger organisations with much better backing and “trusted hardware” have tried and failed to stop content being copied, I really can’t see LL tripping over some silver bullet.  Some people have argued they’re making it even easier to copy content, by making tools even easier to get at. I’m sure, of course, that it’s really hard to find copies of CopyBot. Okay, yes, it does make it easy to copy a sim wholesale, rather than in pieces. but I would like to point out you then need (at least, for now) a region to unpack the region archive in to.

What BuilderBot really means is:

  1. I don’t have to worry about being able to copy our sim at work, from SL into OpenSim. This is an epic time saver.
  2. Full sim backups become a realistic possibility. This is fantastic for if we want to let people loose on the island and just revert afterwards.
  3. People who want to copy content now have another tool to do it, with its own advantages and disadvantages.
  4. We might finally drill it into people’s heads that content controls don’t work, and are not going to solve this.

That last one is a particular pet peeve. I am fed up with features such as llGetLinkPrimitiveParams() being avoided because they would provide copying tools to people who are already have perfectly good copying tools. If you’ve ever seen shoes with tens or hundreds of tiny resize scripts, one per prim, that function is what we need to stop doing this. Instead of having individual scripts in each prim report size and handle re-adjustment, this would allow a single script in do the same job. It doesn’t make it possible to get any information out that you can’t get already, it just means you can do it with one script instead of one hundred. I’ve got tools which will already insert a script into every prim in a link set, having to use one script per prim is not hard, it’s just a giant source of lag (and of course you can delete them after copying, so the copiers never suffer this).

My stuff continues to go out almost universally with copy/mod. Given they’re scripts, that means anyone can cut & paste the entire script trivially. Some scripts are no-mod because it’s the only way to include security keys for accessing remote web apps, but that’s the only exception. A good number even ship full perms. I may lose sales, but I make a lot of sales back to people who like knowing they can always keep a backup.

We cannot beat the copiers by technology, we can only beat them by education. Get more people involved into creating digital content, let them see how much work is involved, and you’ll do far more good than any content controls will.

Oh, and can’t wait for BuilderBot!

No Comments

Item sales permission checker script – L$50

XStreetSL: https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1629539

Just a quick side-project completed today; this is a script to check permissions on items you’re selling. It looks for anything shipping with both copy & transfer permissions enabled for the next owner, and warns about them. It also dumps a list of permissions on all other items, just in case you want to look out for modify-enabled scripts, notecards etc.

Sample output:

[8:26] Permission checker 1.0 boxed: WARNING: “Hovertext” is copy and transfer enabled!
[8:26] Permission checker 1.0 boxed: WARNING: “Xugu’s Script Store, Sunweaver Air (194, 30, 141)” is copy and transfer enabled!
[8:26] Permission checker 1.0 boxed: 2 assets checked.

XStreetSL: https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1629539

No Comments

Non-LSL scripting

While I’m aware there are people who feel Linden™ Scripting Language (LSL) is the best thing since sliced bread (which, if you have a bread maker, is fairly damn awesome), I would tend to disagree. Given a medium that’s unlikely to come back and haunt me, I may even rant, but lets just say I feel it lacks some core language features such as error handling, complex data types (classes/structs) and library support. The Mono FAQ does reference writing scripts in non-LSL languages (search for “Will I be able to write scripts in languages besides LSL since Mono supports lots of languages?”), but doesn’t give much detail. I’ve been pestering Babbage Linden about this for a while now, and it’s becoming a recurring question at his office hours, so I’m going to wrap up what I know, here.

At the moment, LSL is uploaded to the simulator, where it is translated it into Common Intermediate Language (CIL), an assembly-like language that can be readily compiled into bytecode to run on Mono (or .Net) virtual machines. This is done on the server-side to ensure that dangerous/hostile code is not run by the server. While LSL is a safe language in that it lacks network/disk/etc. features to do real damage, CIL has no such constraints. Allowing CIL or bytecode uploads would theoretically allow a user to tell the server to wipe its own disks, for example. This is what we call a bad thing.

However, there are methods for allowing such code to be run without endangering the host system. Obvious examples include Javascript, Flash, Java and Silverlight (Microsoft’s equivalent of Flash). For the deeply techy, I know I mixed languages and file formats there, please just accept it. Silverlight is of particular interest, as it runs code under a .Net (same as Mono) virtual machine. In fact, the Mono project have their own version of the code needed for Silverlight, called Moonlight.

Moonlight 2.0 is the current major pre-requisite for non-LSL scripting. It’s due out in September 2009, at which point LL can start work on adapting its security controls for use with the SL™ simulators. C# scripting is likely to be first (although I’m hoping we’ll see bytecode upload so the geekier people can upload whatever we like).

So, what does non-LSL scripting mean for the average user? Well, hopefully more stable scripts. Right now, a lot of LSL can fail silently (meaning that the script has no indication of the failure, and in many cases neither does the user). Loading a notecard with a landmark in it, for example, will fail will no indication given to the script as to what’s happened, making it virtually impossible to provide help to the user.

Trying to do anything with complex data types is difficult and error prone. Lets say you wanted to store the name, key (UUID) and age of avatars you’ve seen recently (avatar age/height detector if you were wondering). In LSL, you can either have three lists (one containing keys, one containing names, one of ages) or one very long list containing all three items grouped together. If you have three lists, you need three commands to add data and three to remove. Use one big long list, and every time you access the data you have to remember which order you put them into the list. If you want to change the data later (say, to track inside leg measurement – yes, I’m being silly), you have to go over every bit of code and update it to know that there’s now four pieces of data for each avatar.

In comparison, in a language with complex data types you can put all four items into a class (or structure), and reference them by a meaningful name. Only one thing to add/remove to/from lists, and you can easily add new items because the language will track the details for you. Oh, and if you accidentally remove an item without fixing all the code that references it, the compiler will tell you at compile time. There are numerous other benefits of a more fully featured language, as well, but this is not the time or place for an exhuastive list.

We need your help, though. Firstly, the Moonlight project could do with your help testing their releases. Secondly,  we need to raise awareness that scripting is an issue that affects everyone. As much as the number of scripters may be relatively few, scripts are high impact. When someone clicks a door and it doesn’t open, it is jarring. When they pay a vendor and don’t get a product, it’s a serious deterrant from sticking with SL. Blog, tweet, plurk, and generally try to get the Lindens to understand that scripts are part of the user experience, and need some love too…

No Comments

PayPal™ vendor release schedule

Due to the changed rollout schedule for server version 1.27, and a desire to ensure that this release is not caught by a possibe rollback to 1.26 in case of any major issues with 1.27, I’m moving the previously announced release schedule for the PayPal™ vendors back slightly. The rollout should complete around 0900 SLT tomorrow (Thursday 16th), at which point the basic vendor will ship out to beta testers. Assuming no last minute problems, it will formally launch on Friday 24th July. The pro vendor is code complete, but not yet finished with internal testing, and should go out to beta testers over the weekend, for release on Friday as well. Work on all other vendors is currently paused pending feedback from the original two, but you can expect to see these in early August.

We’re doing a launch event on Saturday at 1700 SLT, location to be confirmed, with Madame Maracas DJing. Along with a variety of my more recent releases, preview copies of the PayPal vendor will be able to buy for 1/3rd off (with updates for life, as always).

Lastly, review copies; if you’d like a review copy please e-mail me (you can get my address from my SL profile) with:

  • Your name (the name you publish under).
  • The name of the avatar to deliver to, in SL.
  • The URL of the publication you work for.
  • A URL for a piece of work of yours at that publication.
  • If you’re not e-mailing from an address clearly part of the publication, some sort of proof you are who you claim to be. An e-mail listing in the publication, the address at someone clearly attached to the publication who can verify your identity…

No Comments