Increase Script memory Limit
tracked
Christina Riederer
With the introduction of PBR and new features in SL the The 64k memory limit is becoming increasingly hard to work with and not suitable for modern designs. When designing more feature intensive HUDS its hard not to keep running out of memory, suggestion to double or increase the limit would be very much welcome for 2024.
Log In
Arlequin Carter
Has Linden evolved on this subject?
Indeed 64 KB was what existed on the machine of the 1980s.
It's really misery if you want to work seriously.
The 128KB DataLinkSet partially saves the day, but we still need evolving lists that are growing and sometimes we have collisions.
You must then cut the script into small pieces and use llMessageLinked for data exchanges.
It's a real hassle if you want to do serious work.
I made a Geeter for a DJ and a store, look what we have to do to get it running.
Christina Riederer
Arlequin Carter Nothing has been done, its been like this for so long now, nothing important ever gets fixed or improved.
Arlequin Carter
Christina Riederer With the arrival of SluA, which is supposed to take up less memory than mono, Linden does not plan to expand the memory by 64KB.
I tested SluA, everything needs to be reviewed and some functions are not yet implemented or do not work on the Beta grid.
Coaldust Numbers
I fully agree.
64KB RAM was usable, barely, when we were programming in assembly language. Second Life insists we use high-level, garbage collected programming languages that make this limit impractical.
if good video games or virtual pets are ever to exist in second life, without excessive lag to farm out all the scripting to 'real' programming languages and environments elsewhere, this must be fixed. And farming out the scripting to elsewhere is a great way to make all instances of something break when that external server goes down, and it will go down.
Ratany Resident
My first computer in 1980ies had 64kb of memory. It's 2024 already and we still struggle with 64kb 40 years later. My computer now is rather old already and has 128GB of RAM. Come on, you can't be serious with your 64kb --- or with only 128kb. Make it least 16MB and 32MB for linkset data. That would take us to the 90ies then.
Daemonika Nightfire
The projects have become more and more complex since we started using mono scripts. We often reach the limits of what is possible because the memory is not sufficient. That's why we are often forced to add more scripts to the object. The internal communication between the scripts then also consumes script code, which we could actually save.
I would also like to see a limit of 128 Kb per script, which would currently correspond to 2 scripts. I am certain that increasing the limit would significantly reduce the number of running scripts on the grid.
LG
Dae
BruderTack Rothlisberger
No more Memory ?
I write an chess Skript, and all will be works fine, but i have only 2Kb left free memeory from 65K ! That is to less for my complex algorythmn, and i wich me more memory in my single skript. like 128K
Tapple Gao
(cross-posted to https://feedback.secondlife.com/scripting-features/p/add-llmessagelinkedscript-integer-link-string-script-name-integer-num-string-str)
I have a vehicle script I've been working on for 12 years. It started out as a single script, with control event setting vehicle parameters. I have expanded it a lot since then. It now includes AI (control keys simulateed by another script, 7 vehicle mode controlers (ground, swim, fly, each with a physical and nonphysical option, plus attached mode), security features for restricting it to moving within a user-defined area.
It ran beyond the capabilities of one script a long time ago. The most obvious way to split it was at the control boundary: put all the code that takes user control and modifies that into one script (pilot for manual, autopilot for not), and put the different vehicle modes (ground vs flying vs attached) into seperate scripts. However, after using that for a while and comparing that with the old script, I realized I'd lost something important:
input responsiveness.
Just having a link message on the critical path from control event to vehicle parameters made the vehicle harder to steer due to input responsiveness. And people use it for racing. So, I redesigned the scripts again, and went with a design I still dislike: I duplicated the pilot script (input handling) into all 3 motion scripts (ground, flying, attached). I got back input responsiveness, but, now with duplicated code (and now I get to deal with obscure bugs with multiple scripts having llTakeControls active at once)
The script was actually better when it was split: I could use dedicated timers in each script at optimal frequencies for each one, and they don't actually share a lot of state. However, link messages are NOT a great way to split scripts:
- They do cause delay, usually 1 sim frame between send and wakeup, which is bad for vehicles
- They broadcast to every script in the prim. This is ok for some uses, but it's not great when there are 20 or so scripts in the prim, and every link message causes 20 script wakeups
- They require serializing to string at the sender, and parsing from string at the sender, which adds unnecessary cpu usage
We really need a better way to send one message to one other script in the prim. It should ideally be:
- immediate. It is processed as soon as it is called, or, at latest, immediately when the current script ends its active event. No putting it in a queue until the next frame, unless the script would be pre-empted anyway
- synchronous. It would be best if the remote call was an rpc, and did not resume the calling script until the callee script finished. The callee script could possibly even return a value to the caller, making it a remote function and not a remote procedure. This would make it possible to share functions between scripts
- typed, so I can pass things other than strings. I'd like to pass a list and get back a list, without serializing/parsing in the middle, since that's the only typed variable type in LSL
something like:
// sender
list returnValue = llRPC(string scriptName, integer fn, list params);
// receiver
RPC(integer fn, list params) {
if (fn == ECHO) {
llRPCResponse(params);
}
}
Link messages can stay; they are good for shared state updates to all scripts in the prim. But, splitting scripts to deal with exhausted memory needs a finer grained control like a remote procedure call, that addresses the issues with link messages
Send Starlight
Thank you for suggesting this. To naysayers claiming that less memory makes us more efficient and therefore we shouldn't have access to more, you are all just creating multiple scripts to get around the issue when it suits you. I keep my code pretty tight, usually most of my devices only have 1 script. But, having to send messages back and forth between scripts when I have to work with something more complicated or having to develop a webserver app to compensate is a pain and a time waster. In one case, I made a Zelda-clone where I stored the entire collision matrix for the map as a stream of bits. In just 1 script I also implemented the entire card game of Arkanoid (all 31 levels + boss... it has 1k left of ram, any more features and it crashes.. i can't even add a h.s. board), Splendor, a Trivia game, etc. And in another, I developed a complete client-side 2D Nethack for SL that has magic scroll reading, going upstairs/downstairs, potion drinking, supports dozens of types of weapons and monsters, fighting, chest storage, walking inside houses, entering caves that are cellular generated, cutting down trees, mining for ore, picking up torches, dropping items, a full inventory system and it was multiplayer with up to eight people in about 2 scripts. But, it was so tedious acquiring more memory for it (it would have taken another rewrite) that I gave up adding features to it and it isn't really finished as a result. I have many more projects like that where the uphill battle is the lack of memory. My AI image generator for example is running really close to running out of script memory, preventing people from typing longer prompts. Yea, I can expand to more scripts but then it requires wasting time rewriting it all, it's exhausting and tedious. I'd rather focus on developing features and not spend time with frivolous rewrites. The key/value system they added recently has helped a bit if you use the protected mode and set an empty string for the passcode so that it doesn't waste the main script's memory by double fetching, but it is a far cry from what we really need. I have so many interesting things I could develop, if only more memory existed. It isn't 2003 anymore.
rhet0rica Resident
Mishelle Rayna
I'm the scripter Christina is talking about and I assure you that I know how to code efficiently. However, I do like to code things that can be more dynamically configured, adapt to changes, be used in more than one product, etc. The flexibility to read and adapt to the environment does take a little more code than something that has absolutely everything embedded into a script that has a single purpose and can't be easily leveraged for the next product.
What's more, I like to embed some textual help and descriptions into those things that have menus. Strings take a lot of space. If you read the documentation, SL says they use 8-bit Unicode. It doesn't look like that is the case in reality. Microsoft .Net, which is where Mono comes from is 16-bit Unicode. So even if LSL is 8, once it gets to mono, it is likely 16-bit. Also, code takes up a lot more memory than you'd think if you compare it to something from years ago that was compiled into bytes for use on an 8-bit microprocessor. I don't know why. Maybe once again, it's Mono.
If you'll recall, when they went to Mono script memory grew from 16k to 64k. They didn't do that because they were being nice. They did it because Mono is just bigger.
I also like to leave 4k to 8k free, because LSL doesn't run the same way twice. If you don't believe me look at it.
To compensate for a 1980s memory model, I end up splitting functions out, which means more scripts and more script memory. Things that region owners don't like. Splitting something apart that barely fits in 64k doesn't equal two new 32k scripts. You get overhead for whatever you have to include for communication and synchronization. You also get a cpu time hit for every extra script, even if it has nothing currently to do. And, SL counts every few scripts as one LI. I don't know the formula, but I know it happens.
This problem has existed for a long time. It became more pronounced because of the number of possible things you might have to store and swap for lighting changes to faces with PBR.
So, please. More memory so I can stop some of this foolishness.
Zi Ree
Better fix the PBR scripting calls than increase memory to mask the real issue.
Mishelle Rayna
Zi Ree it's not so much the scripting calls, although they can be cumbersome because they are all llSetPrimitiveParam functions and you may want to change just one thing, but have to set 3 or 4 other things with that one thing. So, all of that has to be maintained in the script. Then since every side has it's own PBR options, you may have to do this for every visible side. Again, that's more memory to represent different effects that you may want to flip through on demand.
Anyway, it was just this discussion about PBR and builder desires of what they wanted to do with PBR that added to the memory issues. Memory for anything very complicated has been an issue for a long time.
Load More
→