Hello Justin, This is one situation where having an an on_die() could be useful. Let us say we have a linked object, with a root script that contains the llDie() command. This llDie is triggered by some third party object through some trivial say-listen 'talk' protocol. Now, we can have multiple other scripts in the children of the object with the llDie command. These other scripts might need to do specific things if they knew that the llDie command is being triggered in root. These other scripts can be informed about their imminent demise, which can be done through llMessageLinked to all children .. I see a lot extra internal communications needed here before the linked object dies.
Where as state_exit() for eg works well. I could have a code to execute on state_exit() in a child script, and a different piece of code to execute on a different state_exit in a root script. This seems to work well. So when I take the linked object back into inventory, the various commands to be executed on state_exit() work as expected. I was just thinking it would be great if there were a similar on_die() event. Ramesh st On Wed, May 15, 2013 at 4:15 PM, Justin Clark-Casey < [email protected]> wrote: > Hi Ramesh. I'm not entirely sure what you mean here. As a script has to > execute llDie() on itself, can it not just do whatever needs to be done > before it triggers llDie()? > > > On 14/05/13 21:54, Dr Ramesh Ramloll wrote: > >> Hello, >> Recently I ve been trying to find a simple way for dying objects that >> those that forced to llDie() to do something >> before they get deleted. Note that a deleted object does not trigger >> state_exit() which is used for other known >> purposes. Please share your ideas regarding a possible solution ... right >> now I cannot think of anything else other than >> triggering events just before the llDie command is executed in a given >> script. Problem is that this approach quickly >> escalate resource consumption if the behavior before an object dies is >> defined in other scripts .. have to >> llmessagelinked or listens etc.. >> Anyway let me know what you think. >> Ramesh >> >> -- >> 'Consider how the lilies grow. They do not labor or spin.' >> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate >> /Research Associate Professor/, Idaho State University, >> >> Pocatello, ID 83209 Tel: 208-240-0040 >> Blog >> <http://deepsemaphore.**posterous.com/<http://deepsemaphore.posterous.com/>>, >> LinkedIn >> <http://www.linkedin.com/in/**rameshramloll<http://www.linkedin.com/in/rameshramloll>>, >> DeepSemaphore LLC >> <http://www.deepsemaphore.com>**, Google+ profile < >> https://plus.google.com/**103652369558830540272/about<https://plus.google.com/103652369558830540272/about> >> > >> >> >> ______________________________**_________________ >> Opensim-users mailing list >> [email protected] >> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >> >> > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > ______________________________**_________________ > Opensim-users mailing list > [email protected] > https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> > -- 'Consider how the lilies grow. They do not labor or spin.' *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: 208-240-0040 Blog <http://deepsemaphore.posterous.com/>, LinkedIn<http://www.linkedin.com/in/rameshramloll> , DeepSemaphore LLC <http://www.deepsemaphore.com>, Google+ profile<https://plus.google.com/103652369558830540272/about>
_______________________________________________ Opensim-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-users
