03 May 2012
24 March 2012
Lowering script time when moving child prims
If you move child prims around in a link set, it used to be very expensive in terms of script time. Think animated prim animals.
Change the Physics Shape Type of all the child prims to None. It dramatically drops the script time.
Change the Physics Shape Type of all the child prims to None. It dramatically drops the script time.
25 February 2012
Third Party Viewer Policy Drama
I'm watching the Third Party Viewer Policy Drama (there's a good round up of it here.)
10 February 2012
Change of scene
I swapped out the garden sky-globe for a cave of dark stone with little areas of sunlit garden. It's peaceful like the garden, but sometimes one needs a change of scene.
I reused a couple elements from the Vernian Deep build (the geodes, the smokers, etc.) The three stone textures are generated with Filter Forge. The glowing balls are my papillon wisp pets.
I reused a couple elements from the Vernian Deep build (the geodes, the smokers, etc.) The three stone textures are generated with Filter Forge. The glowing balls are my papillon wisp pets.
07 February 2012
Restarting a looped animation
I have a vehicle where the avatar does a looping animation that's in sync with some of the prim animations... When I cross sim boundaries they fall out of sync.
I thought that restarting both when the vehicle crosses a sim boundary would put them both in sync. It turns out that stopping and restarting a looping animation is more difficult that it sounds.
I tried llStopAnimation(A) followed by llStartAnimation(A). The animation continued looping like I'd done nothing. I tried adding a short llSleep() between the stop and start. No effect. I tried briefly starting and stopping a different animation between the stop and start. That interestingly did nothing as well.
What finally worked was a combination of the two.
I suspect it's related to a change intended to prevent griefing via bombing someone's viewer with animations.
I thought that restarting both when the vehicle crosses a sim boundary would put them both in sync. It turns out that stopping and restarting a looping animation is more difficult that it sounds.
I tried llStopAnimation(A) followed by llStartAnimation(A). The animation continued looping like I'd done nothing. I tried adding a short llSleep() between the stop and start. No effect. I tried briefly starting and stopping a different animation between the stop and start. That interestingly did nothing as well.
What finally worked was a combination of the two.
llStopAnimation(A);
llStartAnimation(B);
llSleep( 0.1 );
llStopAnimation(B);
llStartAnimation(A);I suspect it's related to a change intended to prevent griefing via bombing someone's viewer with animations.
14 January 2012
Map hijinks continue
Well, the 40% alpha prim didn't do what I hoped.
It does appear on the map, but as translucent. It tints the sim map square.
It does appear on the map, but as translucent. It tints the sim map square.
12 January 2012
Hiding from the map + shadows = one dark sim
Sometimes when I'm building a sim, the owner wants things kept hidden from the world map until they're ready to reveal. The map pics the highest objects that are under 400M to display. Taking advantage of the ancient SL art of skywriting, we can protect an island sim from prying eyes.
The easiest covering is a 256x256x1 phantom prim with this script in it.
default
{
on_rez( integer p )
{
vector targetposition = < 128, 128, 390 >;
while (llVecDist(llGetPos(), targetposition) > 0.001)
llSetPos(targetposition);
}
}
When the prim is rezzed, it walks its way into position. And after the next mapper pass, curious eyes will only see that big boring prim.
Unfortunately, 400M is low enough to shadow the whole sim at ground level. A prim has to be 40% or more transparent to not cast shadows. After another mapper pass, I should know whether or not skywriting will still work at that transparency.
The easiest covering is a 256x256x1 phantom prim with this script in it.
default
{
on_rez( integer p )
{
vector targetposition = < 128, 128, 390 >;
while (llVecDist(llGetPos(), targetposition) > 0.001)
llSetPos(targetposition);
}
}
When the prim is rezzed, it walks its way into position. And after the next mapper pass, curious eyes will only see that big boring prim.
Unfortunately, 400M is low enough to shadow the whole sim at ground level. A prim has to be 40% or more transparent to not cast shadows. After another mapper pass, I should know whether or not skywriting will still work at that transparency.
27 November 2011
Doings
I've spent most of my time running around as a micro lately. The virtual world's a different place when you're only a foot tall. There's sculpted versions available, but I prefer the mesh version - if you've got skin and clothing textures you like you can apply them to the avatar. There's also prim wearables, vehicles, and furniture available for them.

I'm still enjoying the papillon breedables I got last month. The community group is very friendly, the toys are low lag and attractive, and if you set up the environment right you can pretty much ignore them and they'll still thrive. They're also good company while you're scripting. *grin*
The train-based project I've been working on with some friends has entered beta. I'm excited! I made a lot of the art assets on it. Sometimes the beta grid is down, so I've changed my workflow when doing sculpt/texture combos to include using sim-on-a-stick as a free way to check out how they look.
I purged several old products. Deleting entries from the current SLMarketplace is a painful process. First you have to remove the items from your magic box(es), then refresh so the delete option is available on that listing. Then you have to delete each listing one by one, since the page refuses to let you use the checkboxes to group command the listings. I'm still musing about which products I want to freshen up or rearrange and which I want to leave as-is.
I finally seem to be getting comfortable making mesh models with Blender. I'm still working on getting rigged models to work, but there were some changes made to Blender 2.6 that are supposed to help.
09 November 2011
Copy viewer toolbars from one account to another
To copy toolbar positions from one account to another in Viewer 3.2:
Shut down the viewer. Copy the toolbars.xml file from one acct to the other's folder. Restart.
Shut down the viewer. Copy the toolbars.xml file from one acct to the other's folder. Restart.
Public Service Scripting Message
Only the most recent sensor event is queued.
Previous sensor events are replaced.
So, what does this mean to you? If you're using sensors, and you're sending sensor messages fairly quickly one after another, and the sim starts to lag... Your script appears to stop.
Every script has an event queue that holds up to 64 events. Normally these are given to your script in more or less a first come, first served order. If you do something that adds a sensor event ( a llSensor() or llSensorRepeat() call ) then the queue adds it to the end and removes any other sensor events in the queue.
I repeat: If you make a sensor call while you're still waiting for the results of previous calls, you will never see the results of the first call.
Scriptors often talk about problems or look over each others' code when it isn't working as expected. Sometimes another set of eyes can spot whatever it is that's driving you nuts. I've spotted this one in several "broken" bits of code this month, so I figure it's time to write it up somewhere. LSL has its quirks, and at least in a SL environment this is one of them.
Previous sensor events are replaced.
So, what does this mean to you? If you're using sensors, and you're sending sensor messages fairly quickly one after another, and the sim starts to lag... Your script appears to stop.
Every script has an event queue that holds up to 64 events. Normally these are given to your script in more or less a first come, first served order. If you do something that adds a sensor event ( a llSensor() or llSensorRepeat() call ) then the queue adds it to the end and removes any other sensor events in the queue.
I repeat: If you make a sensor call while you're still waiting for the results of previous calls, you will never see the results of the first call.
Scriptors often talk about problems or look over each others' code when it isn't working as expected. Sometimes another set of eyes can spot whatever it is that's driving you nuts. I've spotted this one in several "broken" bits of code this month, so I figure it's time to write it up somewhere. LSL has its quirks, and at least in a SL environment this is one of them.
Subscribe to:
Posts (Atom)

