I have been posting less than usual of recent, principally I suspect as result of a good dose of seasonal flu. I am starting so feel much better now however and standing on one of my islands just the other day, I began to recall the comment that I had once read in a blog or posting someplace about there not being much actual life in Second Life. Sure there are plenty of buildings and avatars, waving flags and swaying trees, but actual life, not so much. In the light of this comment I started to have a good look around and thought the criticism not so un-justified, where indeed is the life? at which point I began purchasing some roaming creatures from different places for my sim, it does produce a different feel and perception without doubt. Now that I am working more and more in OpenSim, I have once again started to sense the need for some background life features, but these are not so readily acquired at the moment in OS as they are in SL. Back in my early days of SL I had made a simple flying Parrot, so decided to start with that, except this time the parrot would become a seagull. The animation is simply a llTargetOmega() function placed in a central transparent hub that connects to the bird through an equally transparent rod, the whole thing just rotates. To make it a litle more interesting, I used some loops with random iterations within the main hub to drive it in x,y and z axis using llSetPos(). As a final touch I included a random script to play suitable bird sounds, and altogether not bad. Anyway I dropped my new creation in place, made a half dozen copies around the region set everything in motion, once again not bad, or so I thought.
Next, I decided to go for something a little different, something that I had not tried before, a walking bird, a stork. I put the prims together and after a suitable amount of stretching and trashing, I had something that looked OK, well from a short distance anyway. To begin, I decide that all I need was a preset rectangular path for testing and then use llSetPos() to get the thing going. I also rummaged and hacked around to produce a function to have the prim always face forward, for obvious reasons. Next I attached two thin poles for the legs, with profile cut to the center axis and made use of a variation to a door script to make them run from messages sent out from the main body, not the most elegant of solutions and one prone to lag dysfunction over long periods, but this was only a testing stage anyway and I can soon put a rotation reset function in later to keep things tidy. Ready to go, I touch the body and after a few surprising and physically impossible contortions for the poor stork, I finally make a few script changes and it runs, brilliant, or so I thought. Back it comes to the start point, I click again and touch_start sets it off once more around its small 12 by 12 metre circuit, marvellous, or so I thought. Then the moment comes, that would lead to the best part of a wasted afternoon. I decide to put the whole sequence into a loop, and get ready to sit back watching my new creation walking around with the occasional small departures from what could be otherwise described as synchronised marching to the sound of stork calls. Indeed everything went very well until just before completion of the third circuit, the bird stopped ! Not moving standing motionless, one leg pointing straight down, the other pointing out at an unexpectedly high angle reminiscent of a Nazi salute, curses. Whenever these things happen in programming, I find despite experience, I am always overcome by the optimism of the two minute fix phase, where I find things that while not strictly correct, actually have no baring on the problem whatsoever, and after numerous mods and tests, the problem all to often remains. At such times, trust me, always go for the manual, but no, no, hack on regardless, changing and testing changing and testing. I’m not sure now if was someone turning the lights on for me as I was by this point sitting in the dark, anyway, eventually I turn to Google and before long discover that there is a bug report in for llSetPos(). Apparently llSetPos() bombs out of loops at somewhere between 100 and 200 iterations, magic. But hey-ho we are made of sterner stuff, so what’s the fix, well obviously make sure that the number of calls to llSetPos() is well within limits. I setup a simple prim in a loop that moves and reports to me, and after 50 tests I had bomb outs at 146 as the lowest and 188 as the highest, worth baring in mind. This gave me some optimism as my stork only consumed 128, but such small test samples are just misleading and sure enough it failed, at 104, but 96 seems to be OK at the moment, but do read on.
So what do you do, set it running for the two small circuits and place a sign around its neck saying please touch me to witness a short walk, no not really. I just need to find a way to reset the script, and llScriptReset was not it, instead I devised this fiendish little approach, which seems to runs OK
default{
state_entry() {
}
link_message(integer sender_number, integer number, string message, key id){
if(message=="start") {
state back;
}
}
}
state back{
state_entry(){
//call movement function
state forward;
}
}
state forward{
state_entry(){
//call movement function
state back;
}
}
At the moment I am still testing the solution, though I must say that since starting to publish this blog posting I have just looked in on old storky and it has actually failed at 96, so onward and downward in the search for a stable number. Of course I could be missing the whole point somewhere here, so if you have experienced any problems with llSetPos() in OpenSim and found a work-around then please feel free to post you comments. Otherwise I at least hope that my experience will be of some help to you.
Kind regards Vega
