llWait(float seconds)

The summary of this post is that i want a function that i call and it just lets time pass while the script is still running.

llSleep completely stops a script, and any activity related to that script. So if you are say setting a force, and then you tell it to sleep for the time required for the force to do what you want it to, it turns off the force, which is bad. the work around is writing a timer funtion like this one

{
    ...
    llSetForce(<0,0,9.8*llGetMass(),FALSE);
    llResetTime();
    while(llGetTime()<desired_time)
    { 
        //empty loop that cycles until the desired time has elapsed;
    }
    llSetForce(<0,0,0>,FALSE);
    ...
}

so now you ask why didn't i write my own little neWait function so that i could call it whenever i want, well its because I have been having problems calling functions i have written from within other functions i have written(it maybe the order that i have written them, i.e. the function i write that i call in other function i write need to be ahead of everything else, i haven't tested it).

If llWait existed I would use it.

On the other hand llSetTimerEvent can do what you want, almost. I do this:

// stuff I wanna start
count = 10;
llSetTimer(1);

.....

timer()
{
  count = count - 1;
  if (count <= 0)
  {
    llSetTimerEvent(0);
    // do the finishing stuff
  }
}

Although I don't think its much smoother than your while loop, except it is interruptable.

yeah, i have done that before, it just seemed silly to use an event to pause for the 2 seconds i needed to apply the force to the object. now if we can just get some more people to agree... this will make physics related scripts so much easier!!!

Heh anytime an event and 6 lines of code can be replaced by one library call, it gets my vote.

This simple request actually sounds like a request for an asynch, multi-threaded programming environment. Which wouldn't be simple at all.

lol tc, no i want a single thread, i just want to be able to pause the script without having it to put it to sleep, because if you put it to sleep the script stops working. seriously what i want the llWait to do is basically the empty loop that i created, so it counts to whatever time and then executes the next line of code. i do not want independent threads acting (lucky me i read all about java this past weekend) silmutaneously, although that would be sweet.

I assume:
while(llGetTime<desired_time)
should be
while(llGetTime()<desired_time)

lol Mark gotcha there Nada

you are right of course. nit-picker!!!! hehe

<cough> Um, TC .... what kinda system do you think is already in place? Ther servers run on *nix which is by default asynch and multi-threaded. The scripts are all compiled into byte code which are run by the same virtual machine (per sim). If those aren't running multi-threaded then I am very obviously confused as to the meaning of multi-threaded. Which would be very sad considering I aced my course last semester where we built a multithreaded OS from scratch.

The only way we would not be dealing with a multithreaded system is if each time a script was running all other scripts were stopped while it ran.

Now what I asked for was for it to be able to interrupt itself, I guess, kinda. Although I really wasn't asking or expecting that. I just gave the example of what I use in the case Nada gave, which is interruptable. Given how the current system works then I would not expect a wait() call to be interruptable.

Although I did post somewhere, burried deep in some thread, the desire for an action handler that is interruptable.

Just to be clear...are you all saying that in your scripts, you have the ability to spawn a thread of execution that will continue operation while a different one is paused/running? And that you later have the ability to lock, and synch, these threads independently?

I would * cough * point out that the runtime environment for the game itself might be a little more complex than the runtime script parser you use in game. You can not code SL in LSL.

Please send me any and all docs you have on spawning an arbitrary thread, pausing/locking it, and synching it, in LSL.

Edit: Example, VB is not a free threaded environment (though it is in .Net). But VB runtime runs on Windows, which is multi threaded. So many VB apps can run on Windows. But none of them are free threaded.

Multi-threading means that more than one thread can be run at a time.

I can run several scripts on one object at one time, not to mention all the other scripts on the sim running at the same time.

Being able to spawn a thread isn't necesary to make it multi threaded.

But yes, I can have a script that pauses while another does something. Sure. They can also both run simultaniously.

In fact I can spawn another thread ... llRezObject() ... communicate with it ... llWhisper() ... pause while it does stuff and listen for info back ... listen() ... and even terminate the other thread ... llDie().

And sure I could 'synch' them through communication. It becomes smoother if I link them, but hey that can be done in script too I think....(sorry havn't tried).

So yes, I am saying that the scripting system is multi-threaded.

And of course the script engine is simpler than the game engine, but the two are -very- intertwined.

If the environment was multithreaded, you would have...

thread myThread = llSpawnThread(id, etc.)
thread myOtherThread = llSpawnThread(id, etc.);

myThread.Start;
myOtherThread.Start;
myOtherThread.Sleep(10);
// MyThread keeps working until completion, then they synch etc.

There is no way to grab the id of an independently running thread and manage it. What you are talking about is more the equivalent of remoting, where two objects communicate via externally delivered data (ala DCOM/RMI).

You are extending the definition of multi-threading.

There are two things missing from doing what you ask in SL:
- llRezObject returning the key of the rezed object.
- Obj -> Obj IM.

Even then it is a pipe. You specific example differs only in semantics.

The system is multi-threaded - more than one script is running at any given time. That can't be done in a non multi threaded environment. So the scripting environment is multi threaded.

I can spawn a new thread - via llRezObject

I can communicate with that thread to give it commands. It would be smoother if I could do Obj -> Obj IM, and more in line with what you are saying.

And I have no way of knowing but what you write looks like a simplistic version of what the scripting engine itself is doing. Just cuz the threads themselves don't have that syntax doesn't mean the engine isn't doing it. The engine makes a new thread and can issue commands (calls action handlers) on those threads. I can, via work around I admit, have the engine spawn a new thread / process and communicate with it.

How is any of this not meeting your requirements for a multi-threaded system? It has to be your syntax?

You are confusing what I'm saying. Of course the game is multithreaded. We are discussing the in-game capability of LSL.

The game will run the scripts independently. Just like two VB6 apps can run independently. And one of them can pass data to another one. But neither application is multithreaded. The developer of either of the VB6 apps is considered to be working in a single apartment threaded environment, even though the underlying OS is multithreaded. By your definition, VB6 is a multithreaded environment becuase two VB apps can run independently on Windows and pass data to one another.

This discussion is easily cleared by producing any method that shows how you can grab the id of a currently running path of execution (not the main one, which you can sleep), and stopping and starting it independent of another one, and then synch it in the same script. The key of a seperate object and the integer you pass in is the equivalent of a remoting call (an encapsulated externally delivered packet of data that requires a specific use of the API), not of multithreading.

Ah, edit...if the environment API was multithreaded, you would not have to run more than one script on any object. You could just spawn the thread in your current one.

In this case I don't see the seperation of game and scripting language.

I see the Scripting engine as a process on the server, and each script it runs as a thread. Because of this I do not think a library call to wait X time while anything the script has already started to do continues, is out of the scope of the existing framework.

Hows that for a jump back to topic?

I think we are talking about different things. Because the scripts exist -in- a multi-threaded environment, and because of the close ties to that environment they have in this case, I hardly see a seperation. But seperation or not, because we are asking for a linden library call, that call -is- part of the multi-threaded system.

And anyways, as Nada said, this can be done with just a loop sitting there, which is in no way multi-threaded .... or does it prove my point? The actions already started can continue durring the execution of the loop.

Anyways, I digress, what is being asked can be done without multi threading. He is asking for a call that does an empty loop for a specific amount of time rather than stops the script completely for a specific amount of time as sleep does.

Fair enough. We'll have to agree to disagree. I maintain that no one script can run more than one manageable thread of execution. Nada's technique is the exact same one used by VB programmers to get this result.