Multiple Timer and Multiple User - Concurrent programming

Hi:

I am having trouble understanding how LSL can be used as an object oriented or for concurrent programming. Please help me get over this LSL hill.

I am currently trying to create a script that would allow multiple users to click and pay. Once they pay the object, a blue dialog screen will pop up for certain action. I want the user to have 5 minutes to complete their task. If they don't complete the task within 5 minutes, I want to refund their money. So here are my questions.

1) How do I make sure that multiple users can pay and use the script at the same time. I am trying to get around this using lists. Is this the only way to get this done OR can I use states that I can initate a state when a user successfully pays the machine?

2) How do I set multiple timer() within my machine? For example, if user X pays the machine at 10:30PM, I want the timer to run out at 10:35PM. And if user Y pays at 10:31PM then I want the timer to run out at 10:36PM. Do I just throw in a timer() function in a state and initiate it when he/she successfully pay the machine?

3) Please help me understand states. As you can see from my above questions, I am trying to allow this machine to support multiple users at the same time. Are the states is like a class object in an object oriented programming language such as Java? How do I make sure that one user's input don't manipulate the other user's results?

I know this may be a lot of questions but I think the fundamental is just behind the concurrent use.

Please let me know if I am not clear. Thank you very much.

-Homer

Well, these are all good questions, and it is clear that you are an experienced programmer. My advice is to stop trying to see LSL as a version of Java or whatever, and learn to live with it the way it is.

1) I have a demo dance floor, and multiple people can use it at the same time. It contains multiple copies of a script. When a user starts dancing, the master script sends a message to the other scripts, and one of them takes over that dancer. IM me in world for a copy, though it is based on some previously available script. Sort of like a boss/worker multi-thread approach.

2) each script/thread can have it's own timers.

3) Are you familiar with state/transition diagrams? The states in LSL implement that model. A script is in anyone state, and it processes inputs according to that state.

As you suggest, another approach is to use lists. Keep the information about each user is a string or something, and keep them in a list. Set a timer to go off every minute, an scan for things taht need to be done that minute, sort of like cron jobs or event/simulation languages.

Or, kep a list of all the hings that need to be done in the future, with the time to do it. Keep the list sorted. Check the list every minute tosee if anything needs to be done.

babble babble babble.

You've hit the nail right on the head. I will now begin to think just about LSL in SL. Well that is the great thing about SL anyways, an another way of living.



I would love to get this from you. I will IM you inworld.




Thank you for all this. I will look into the state/transition model instead of my list model that I was working on. List will just take too long to sort and search as concurrent users grow.


Another quick question to you, would you choose between listening() or email() to make a server/client based system within SL? Which one is lag friendly? Or is there a better way than this that I am not aware of?

Thank you.

-Homer

My guess is multi-threading is the best approach.

To answer your question about multiple timers: you can't. You have to use a single timer and implement multiple timeouts yourself.

Wouldn't this work if I take Lee's approach about state/transition? I thought I can initiate a state for each user.

Yes, that works because you have a copy of the script for each user. A given copy of the script is in exactly one state at any time. So, with multiple threads (multiple copies of the script), you don't need multiple timers.

So, you don't have a state per user, you have a script copy (thread) per user.

Just a note re: multi-threading with LSL. One aspect to watch for with multiple copies of the same script in the same prim is, they pretty much all receive the same event(s) at the same time. Meaning for example, if you put 5 scripts in prim to handle 5 payment transactions, when someone pays your item *all* copies will have their money() event triggered. Etc.

Using list of open transactions can be probably easier overall, just need to watch for memory limits...

One method you could use would be to have the master console rez a "client interface" at the client's position, a little negotiation to tell the client interface whom to send the llDialog's to (and set up the llListen's for).

Payment would go to the interface, if the interface doesn't rez, no payment received, nothing to refund.

The interface could also have a slow sensor repeat as well as the 5 minute expiration, if the client takes off, it issues the refund and removes itself.

And of course upon successful completion it removes itself as well.

Good point, Joannah. The way around that is to ignore all events unless llDetectKey() returns that thread's user.

I assume that timer events are local to a thread -- in other words, your comment applies to "touch_start" but not "timer" events.

This thread might well be dead now, but..


http://www.lslwiki.com/lslwiki/wakka.php?wakka=LibraryTimerEnhancer

That would be exactly what you would need to implement a single timer/multi counter solution to this problem.