Not only that, when I moved the model to another spot, that created a problem since I tried an end run around some issues by using object keys. Well as I was afraid, keys are useless once the model is rezzed , since Second Life generates a new key every time an object as rezzed.
So here is what I did. I set up those parts that need to know where other things are to detect those parts using a sensor event as partly shown here:
The llSensor statement tells the object (in this case a proton) to scan a 10 meter radius for what ever objects are around and then the if statements within the sensor event enable the proton to "tell" Of course real protons move randomly but in Second Life having lots of randomly moving protons presents some problems...so this is a compromise.
Also I could have done the protons as particles, but you can't control where particles go and since they are generated client side, can't interact with the model.
There are always design compromises in modeling and that is true in Second Life as well as in other modeling systems and the modeler has to pick the right compromises for the level of modeling being used for the audience.
The Calvin cycle will be much easier...far fewer moving parts and coordination problems especially since I have dealt with some of the issues involved in the Calvin cycle in Photosynthesis Engine I and II.
If you have Second Life installed you can visit the light reaction model in its temporary home at:
On tap this week:
- Calvin cycle.
- Look at Max Chatnoir's pedigree program. Max has graciously sent me a copy to study.
- Faculty meeting - in person no less...that's so 20th century.
- Also in the middle of Angel training.
- Friday I am going to be at the Stepping to Science workshop. I was supposed to go to the first iteration of the workshop but my registration got messed up.
- Oh yes one more thing: change the cats' litter boxes. Now that really is so 20th century.