Important Notice: Reduced support for kimmscripts

•October 7, 2015 • Leave a Comment

I’m not going to be around much for the foreseeable future, consequently support for kimmscripts products is going to be very limited.  If you have a query or question, I’ll endeavour to respond to IMs by return of email when possible, but anything that requires in-world support is unlikely to happen in any sensible time frame I’m afraid.

My scripts are still available with help and supporting information via this website and I’ve left them on the marketplace.

If you purchase one of my products but then find lack of support a major issue, drop me a line in-world and I’ll attempt to get back to you within a couple of weeks.




Happy New Year for 2015 from Kimmscripts

•January 2, 2015 • Leave a Comment

May I wish all visitors to kimmscripts a very Happy New Year.

I’m not in-world much at present, and as is evident from this blog, haven’t published anything new for a while, but I am still very interested in seeing how people get on with my scripts and am actively supporting them as time allows, so feel free to drop me a line via IM and I’ll reply via email when I can if not directly in-world.

I hope to get an in-world store back up and running at some point this year, so watch this space.  In the mean time, I hope you find something useful in my free scripts, scripts for builders and guides.

Best wishes for 2015.


Non-mesh up-down-rotate Script

•December 28, 2012 • Leave a Comment

Since publishing my up/down script (that uses physics) and then following it with my up/down/rotate script (that uses llSetKeyframedMotion) I’ve had a few requests for a similar script that doesn’t need mesh – one of the conditions of the up/down/rotate script.  Well, its not easy and all the ways I have found so far have a limitation.

This post describes my experiments so far.

Adding rotation to physical movement

My first attempt was to simply use llTargetOmega with my up/down script, but unfortunately the llMoveToTarget function that is essential to the smooth physical movement appears to cancel out all llTargetOmega rotations.

Next, I took at look at the physical rotation function – llRotLookAt.  This stated to work a little, but whatever values I used for the strength and damping parameters, the rotation was unpredictable and tended to jump from 100 degrees or so straight over to 270-300+ degrees.  I never did find out why.

Then I took a different track, could an impulse be provided on each timer trigger to keep the object rotating?  Well yes, for small objects.  The resulting script used llSetAngularVelocity and worked ok, but when I tried new values for larger objects, it was very unpredictable.  If this might be of use, you can see it here:

Mixing non-physical movement with rotation

My final attempt rewrote my up/down script using non-physical movement, which is jerky as it involves periodically updating the position on a timer and the triggering of the timer introduces a minimum step motion each time.  The non-physical up/down is combined with a llTargetOmega rotation.  It kind of works, but will be affected by server lag and the rotation is not very smooth.

If this sounds of potential use, see it here:

Other ideas

There may be some option of combining llTargetOmega with real prim rotation setting (llSetRot, etc) to link smooth rotating with real position changing (like the smooth rotating door script), but that is a project for another day.


None of these touches the smoothness of the llSetKeyframedMotion script – but having to link your primset to a mesh object can seriously affect your prim count.  But then I guess LL would like things to be going this way.  So in summary you have the following choices of script from me so far:

  • Smooth up/down, no rotate
  • Mesh smooth up/down/rotate
  • Smooth, non-mesh, for small objects up/down/rotate
  • Jerky, non-mesh, non-physical objects up/down/rotate


HTTP Server and Client Test Scripts

•November 17, 2012 • Leave a Comment

I have a couple of simple scripts that are based on the advice on the wikis that show how to do simple prim to prim communications using HTTP but without requiring an external webserver.  The advantages of prim to prim HTTP is that the prims can be anywhere inworld.  Alternatives to communicating this way are to use XML-RPC or llEmail (all the details you need are on the wiki).

There are two pairs of demo scripts.  The first is the simplest and sets up a prim-based webserver that returns a simple message whenever a client – which can be a normal webbrowser or another prim – requests it.  This shows one-way server to client communications when requested by the client.

The second shows the communications the other way round – the client ‘posts’ a message to the server, which the webserver then displays in local chat.

These are proof of concept scripts and so probably not a lot of use on their own, but they should show enough of the basic principles of using prim-based HTTP communications to get you started.

They do not attempt to show how to do HTTP communications to an external webserver – for that, I recommend taking a look at


Simple Channel or Chat Relay

•November 5, 2012 • Leave a Comment

This is a very simple script – it listens on one channel and relays anything it hears to another.

You can set the two channels using variables at the top.  This might be useful if, for example, you have a script that uses negative channels (as is often usual for script-to-script communications or for dialogs) but you’d like to send it some messages for testing.  Just use this script to listen on an easy channel and relay messages onto the other channel.

Note of course, that if your test script using filtering for its llListen() call on avatar key (as you might if you are using a dialog) then you can’t relay via a prim.

There are options to use whisper, say, shout or regionsay – just uncomment which you’d like to use in the relayMessage() function.


Alarm Script

•October 22, 2012 • Leave a Comment

This was script was in response to a request for help on the SL wanted forums.  The poster wanted a script that would send an IM at a certain time of day, every day.  This script is the result.

It calculates the difference in time between the required time and now (taking care of midnight of course) and then sets a timer event to trigger at that point.  When the alarm triggers the next alarm is set for 24 hours time (less whatever time it takes for the script to operate).  This allows for any lag and drift in the timers too.

There is an option for touch to control the enabling/disabling of the alarm.  Time can be set in either GMT or SLT using the variables at the top of the script.


Be sure to set the UUID of the avatar to IM at the top and update your message.

If you want a different action, then add the appropriate code in the alarm() function.


Kimm’s Pocket Money Guides – Productising your Scripts

•September 10, 2012 • 1 Comment

This is one of my “pocket money” guides for running a business in Second Life, and this is another one about my favourite topic – scripting.  This guide is all about turning your scripts into products.  I’m not talking about finding a great idea, more the things to think about one you’ve had your idea, written it and would like to unleash it on the world.


  • Finishing your script
  • Testing your script
  • Releasing your script
  • Updating your script

Want an in-world copy of this guide?

Or you can read it for free online here.