PrinceSeverus Slade

I see... Yet theres one other thing i dont understand. I have one object rezzed several times in a sim. This object works great while only one of it is operating. as soon the copy of that object is operating along with the "original" one, it runs to a stack heap collision. Both objects contain the same script and operate in the same way, but the copy keeps gettig memory issues. Why is the other not? It follows the same rules and this only happens while both objects operate at the same time. Is it some issue with the sims memory?

Well, I do use mono scripts... I still get the stack heap collision when it reaches 16 k though... I wonder why that is. Is it me being dumb? lol

THank you, Cerise, for pointing out that this bug is already reported.. I hope that even though its considered a minor thing, the linden labs will fix this soon. Ill see how to delay the accessing of the off turned script a little, so it wont return the error. Yet a general fixing would be preferred. There are surely some ways to help reduce the lag on functions, yet i would still prefer larger memory. Sorry for being so stubborn there, im just a damn perfectionalist and hate to get the stack heap collision as a runtime error. Especially if you have data saved in strings it will pile up to 16k soon. I was given the advise to convert it into a system of numbers and save as integers instead, which would work, but that would aslo enhance the runtime as it needs to convert letters to strings and vice versa every time.

Hey there. I finally -think- to have found the right location to post a thaught I have since a good while now. First: I keep having a problem with the script memory. 16KB is not much if you think about it, and I tend to get Stack-Heap Collisions often while working on larger projects. Fact is you can split your script into several scripts to get extra memory, or even use a few hacks to enhance the memory a little. But lets look at it from the lag side: Every script in your object causes runtime lag. You can make it work in a clever way, so that you don't have to pass too many llMessageLinked through your prims, but that will still cause more lag then without too many scripts at all. Also the objects inventory folder loads slower with much content, plus its harder to script if the scripts need to communicate with each other. Yes, not many do these way large projects, but I am sure that everyone who does, knows the Stack-Heap Collision well. Wouldn't it be awesome to just have a few KB more then that? Even if that needs to introduce some special-kind-script, like "Megascript", or whatever, I dont mind. As long it works for everyone im happy ^^ Scond: I noticed that inworld objects have a problem finding not running scripts in their inventory. With some attachment I have, I noticed something fun. I attach it, a script is started to look for other scripts inside the same prim and turn their run on. I find them by number, not by name. However it tells me it can't find the script named XYZ, while the XYZ script is inside the prim, the name was found, but it returns the error of missing inventory as soon the script runs llSetScriptState! If it can find the scripts name by number, then why can't it find the script? Well, if I detatch the object and re-attach it, it has a chance to return the same error again, but usually it runs correct then. The error llSetScriptState returns should be by chance, as I tried this several times and came to this conclusion. Could it be that now and then inventory updates are too slow at some point? It would be awesome if there was some function like llUpdateInventory(); for the prim to give it time to realise if the inventory is inside... I don't like llSleep much as it won't react on touches or chat while sleeping.Also such a function might be great for inworld rezzed/ attached prims, whenever their inventory changes.