Scriptmemory and Inventory list update

[PrinceSeverus Slade]

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.

[Kwakkelde Kwak]

Maybe i am cursing in the church of script here, but if a 16k lsl scripts memory is all used, I normally just switch it to mono....

And fully packed prims do have problems loading everyting in time in my experience yes...but that's just my experience, i have nothing but that to back this up:)

[Rolig Loon]

It's hard for me to remember the last time I left a "not running" script in something, so I can't offer much comment on item #2.  As far as #1 is concerned, though, that's why the Linden gods created Mono. (Well, one reason anyway.... )

[Kerhop Seattle]

For #2, you may want to use llGetInventoryType to check for the existence of an item which will simply return a -1 instead of showing an error. Instead of llSleep you might want to perhaps put this within a timer, or within a change() event that checks for the CHANGED_INVENTORY flag.

llGetInventoryType

change()

[Cerise Sorbet]

Hi, that error is the bug SCR-98. It only happens with some object setups, and not every time, so workarounds will be with you. llSetScriptScate does not release script memory, and the CPU saving can be negligible if the script receives few events, so it will be good to look hard at now necessary it is to start and stop that script.

If the script is in a prim that has lots of other link message traffic, and that is how you pass messages to it, that will be a good reason to keep using the state flips. An alternative would be to move the helpers to a separate prim and direct link messages there only when needed.

[PrinceSeverus Slade]

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.

[Rolig Loon]

I still wonder why you are trying to deal with LSO instead of Mono.  You don't have to work in a 16K limit

[PeterCanessa Oh]

16k is a lot of memory when you think about it differently.  My first professional computer was an Apple IIe - with 16k of RAM.

The thing is there is always a limit to resources and if you really can't survive in 16k then you have at least two other choices:

• Mono scripts = 64k
• Web server = ? probably a couple of MB RAM and several MB database at least?

I've found that web response is generally quick enough that shifting almost all processing off-world is practical, except that which is directly related to prim-manipulation.

[Kwakkelde Kwak]

Don't change to integers or whatever..just use a mono script All it takes is a click.

[PrinceSeverus Slade]

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

[Ela Talaj]

As I mentioned a few times before, LSL does not have a concept of pointer, it puts a whole object on the stack instead of a reference to it. So if your Mono script calls a user function with a 10K list as an argument and from inside the user function calls another one with the same argument you end up using 30K, not 10. Then if your script calls an LSL list methods from the inner user function, you need 40K to process the original 10K list. Considering that the execution code takes memory too, a stack-heap collision is almost inevitable when operating on just a 10K list unless the program is designed very carefully with a full understanding of this limitation.

[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?