Is event driven programming in LSL dead?

[Kayaker Magic]

I am always debating whether to make a scripted object non-physical and put up with jerky motion, or physical with smooth motion but put up with the physics engine running away from me from time to time.

I bumped into a guy who had some smoothly moving scripted critters (birds in this case). I assumed they were physical objects but he said no. So how did he do it? Well he was cagey about his “valuable proprietary script” but from some of his comments I believe this is what he is doing: Somewhere in his script he has code that looks like this:

	while(TRUE)
	{
		vector pos = calcnew();	//calculate a new x,y,z position
		llSetLinkPrimitiveParamsFast(1,[PRIM_POSITION,pos]);
		llSleep(0.01);
	}

 No other events can be processed during the sleep. Since he never returns from this event, I suspect that no other events can ever run again in this script. So you can't have timers, listens, or dialog boxes, etc any more. Perhaps you can put in a second script for those things and implement some form of communication that you check for in that big while loop.

This guy CLAIMED that his scripts were LOW LAG. I think he was thinking something like this: “The physics engine is laggy, I'm not using the physics engine so therefore I am not laggy. Scripts are the lowest priority thing done by the sim so it doesn't matter if I loop forever”.

So if this is a good way to get smooth motion in LSL, then should good event driven programming methods now be tossed out the window?

In lots of non-physical scripts that I have written, before llSetLinkPrimitiveParamsFast, I had a timer event that called llSetPos or llSetPrimitiveParams. Because both of these had a 0.2 second delay, I could not move my objects more often than 5 times a second. Is it now reasonable to set timers for very short periods of time, like 0.02 seconds, and call llSetLinkPrimitiveParamsFast in the timer event? What is the shortest reasonable time step I can use? I'm assuming 45 server frames per second limits me to 0.02 seconds or so. But is that REASONABLE? Will several objects doing this bog down the server? Will they interfere with each other? Will my timer events actually be called reasonably often? Can good event driven programming style still compete against the guy with a while(TRUE)?

 



[Darrius Gothly]

You raise a very valid concern Kayaker. I think most everyone is aware how laggy the new craze with breedable pets has made some sims, and I suspect it's due to the same type of programming construct you present. But rather than beat that dead horse (no pun intended .. honest!), I'd like to toss out an idea born from your OP:

What about a new Parameter to the Primitive Param calls? It would have one integer parameter that defines how long to "sleep" before executing the next command in the list. It *should* be pretty easy to implement and it sure would come in handy.

I haven't researched the JIRA for it yet .. does anyone know if this idea has been submitted via JIRA yet?

[Void Singer]

the smaller the movements the smoother the motion but also generally the slower the motion. you could even do it event driven by using certain events.

it's actually often more effective to stick another do nothing operation in instead of a sleep to pad time if you want, and in some cases it's effective to use the older set prim params, for instance on posJump teleporters, the .2sec delay prevents the physics engine from acting on the avatar when immediately unseated after a jump.

[Kayaker Magic]

If I understand you correctly Darrius, you want to add something like:

llSetLinkPrimitiveParamsFast(1,[PRIM_POSITION,pos,PRIM_SLEEP,0.01]);

But if we add that, my “friend” will just use this to save him having to call llSleep(0.01);. He will still have a while(TRUE) in his code. Either that, or he will do something even more horrid like:

	list parms=[];	for(i=0;i<1000;i++)	{		vector pos=calcnew();		parms = parms + [PRIM_POS,pos,PRIM_SLEEP,0.01];	}	llSetLinkPrimitiveParamsFast(1,parms);

 I shudder to think how that will behave if he calls it more than once every 10 seconds!

Either way, I don't see how this encourages good programming style. Good style in this case means “doesn't bog down the sim”. Not that I know what good style is, I'm hoping for enlightenment about this...



[Cerise Sorbet]

Do not worry too much about tiny llSleep, the scheduler is brutal with them. They usually deny you time until the next frame even when the sleep is small. There was a rumor that llSleep used up lots of script time, but that came from a faulty display in the estate tools. That is mostly fixed now.

[Darrius Gothly]

Yup, you understand me correctly. By embedding the llSleep within the parameter list to the Primitive Params call, you remove the handcuffs from the interpreter and push the time/code/resource management down inside a system routine. That frees it to make better decisions about when the sleep and when to send prim parameter changes onward. Also since it's down inside the interpreter library, it can better manage other events in that script/thread.

I'm assuming that the entire action (like opening a door for example) is contained in the params list and it is only "run" upon an event. That would make his myOpenTheDoor() routine as simple as calling PrimParams with the prebuilt params list.

As Cerise pointed out, the llSleep(0.01) call is just a way of saying "next frame" (next time slice), but it still carries the overhead of interpeting the loop and PrimParams call bytecodes. Prebuilding a scripted params list with delays embedded removes that interpreter overhead. More than likely, it would still only delay one frame at each small increment sleep param, but it wouldn't return to the interpreter to continue, it would just return to the PrimParams library routine.

[Void Singer]

actually most things in prim params are also interpreted, they just use a different passthough

[Darrius Gothly]

---

Void Singer wrote:

actually most things in prim params are also interpreted, they just use a different passthough

---

Yup .. and don't "pop up" to the LSL bytecode level to fetch the next line of script.

[Cerise Sorbet]

It can be revealing to watch object updates on things like that. Sometimes less is more, the viewer interpolation is simplistic but it can work well when it is exploited.