Reaching the limits?

I am in the course of developing what will be an interesting implementation of a traditional game, Chinese Checkers. This involves the assembling of a large number of prims (144) all of which contain scripts.

I appear to have come unstuck because the linked object refuses to repeat a simple command to initialise the piece prims (121). As part of the initialising script a linked message is sent sequentially to all the prims to assume a specific Color and Alpha by changing their state. They sometimes will correctly respond to the command but at other times there is a significant delay in responding and sometimes not all the prims respond. Each piece prim can be in one of 5 states which may be causing the problem.

Is there some limit I don't know about which is causing this effect?

In the course of play there is a limited interaction between a single piece prim and a base prim which contains the coding for the game. It itself has had to devolve the calculations to another base prim, to find out to which position the player can move a selected piece, because of limits on memory in a single prim. This means that under normal play the communication between prims is limited to at most 6 responses to a single prompt link message.

I am adopting an alternative approach which might solve the problem but I would like to know the answer to my question.

Are you using a linked Message or the linked commands that change prim states?

lsl is slow. Wait for mono!

Giving each prim its own script is essentially the obvious object-oriented way to doing this, but I believe that approach breaks down with lsl. The problem is that each script is running inside its own virtual machine, so you have a huge amount of thrashing going on. If it were Java or C#, the virtual machines could at least share the object code of the script, so only the data would have to swap. I haven't seen any suggestion that lsl will maintain a single copy of the bytecode if a single script is duplicated in multiple prims. With all this thrashing, even if everything were functionally correct, it's possible you'd never be able to get the response time down to acceptable levels.

It's possible that with this many you're triggering limits within the lsl engine, so messages may be getting dropped. I wouldn't know what to do about that directly, but a compromise approach that comes to mind is to divide the board into sections, and let each section have its own script to control all the pieces in that section. The six outside triangles could all use identical copies of a script, and the central hex could probably share most of the code. By doing things this way, you're reducing the total number of scripts dramatically, reducing the swaps between virtual machines, and at the same time, reducing the amount of data in each script to a manageable level. If necessary, the central hex could be further subdivided. Of course, this makes the programming problem more difficult.

Another question that comes to mind is how are you synchronizing states (both explicit and any implicit state) among the prims? There's no control or guarantee over the order in which scripts get their time slices, so it's conceivable the master controller script could issue thre different state changes to a prim before that prim has had a chance to respond to the first one. You'd need to make sure the master script waits until all the piece scripts have completed their moves. It's conceivable to me that this is the entire problem, and the lag is a red herring. (Sorry if this is obvious to you, but there are many people who dive into scripting without knowing the basics of multithreaded programming.)

Good luck

Yes I am using the linked message too trigger the state change.




What is mono?



I am skilled in multithreaded performance problems but not where the performing engine is restricted both in memory and scope. Background ex-IBM process control.

As for dropping messages God Help Us!

There does not seem to be a problem while the game is playing as a prim can issue a linked message saying it has been touched (selected by player) to the game script which then issues a change state command in response before working out where the player could move to. When that is done it can issue up to six link message to those different prims to change state. Then it waits for one of those prims to be selected by the player which triggers a change of state of all the affected pieces individually. So the multi thread is limited and the queue depth to be handled is at maximum 6. I admit that under some circumstances the number of revert to empty message issued can be more tha that but they go to different prims.

Thanks to all for responses. Version 2 is coming on apace. I have taken the opportunity to streamline the coding as well.

Try rewriting it so you use the Linked texture/alpha commands. That way only one script is running and may well help.