Again: increase script size!

I know it's been requested many times, but I'll ask again: please increase script size!!!
I'm working hard on the new DarkLife and it's going pretty well, until I encountered a script-heap collision in the stat-script. That problem is solved by moving parts of it to another script, so it won't crash again.
But there's one script that gives a bigger problem: the magic-list script.
I've tested it and it crashes around 25 magics. I will take a little while before we made 25 magic-types but that day will surely come.
I can move a few functions to a new script but that would cost me more time, plus the limit will probably not move much further than 35 magics. Another thing I could do is not remember a special particle effect for each magic but create a set of basic particle effects and only remember the type of effect and the color for each magic... but that sucks! I'm was just very happy with the system as it is now, and it will cost me a lot of work to migrate to that other system
so basically it would be GREAT if you could at least double the script-size, the code would not be doubled so all that 16k could be used for spells, which would give me about 150 spells or something, that's plenty
And if you can't increase the script-size could you at least explain why that is, or why it is so hard to do that you still haven't done it after all those requests???

I think you just need to rework how you use multi script scripting. When I design a project to use many scripts at the same time, I make things 'push' (send data out when data is changed) as much as I can instead of scripts having to 'pull' (request data from a storage) information from another script. That way, I can just insert more push scripts.

Its kind of hard to explain...

How does your magic get called? If its just particle effect paramaters, thats easy.

==Chris

First and foremost, I need larger script space. I don't want it, I need it for the projects I am working on. Multi-scripting is fun and good, I have been using that for the last year, and am even using it in this script. However there is a breaking point where so much of each script is spent on handling script communications that very little can actually be done in the script.

Second: I would create a dedicated particle effect script. Have it listen for the magic type, same call as the magic script maybe, and decide which particle effect to use. Particle systems take a lot of memory (long list). Putting those in their own script seperate from the magic will probably help alot.

I know you said you wanted a different effect for each effect but here is something to consider. Lets assume you can get 20 really different effects in an effects only script. Then allow for modifications to that effect. For example, you could call EffectA, colors x to y. Just changing the color will give you a large range of effects. I don't know if I'm explaining it well, but its a way to get a lot of effects by having X number of different effects and Y number of variations on each. Personally I would just require that all link messages to trigger an event be of the following format:
llMessageLinked( LINK_SET, effectNum, "EFFECT", "<startcolor>,<endcolor>" ); or something similar. That would only have 1 variation (color), and would require it with every message so processing would be low.

Back to the point though, I need more script memory. Or to not crash with 8k free.

I've used a lot of techniques including the one you described to create a system that uses a lot of scripts (I have about 30 scripts already )
The magic-list is a list of strings, that includes all the effect info and about 30 parameters that describe the shooting-particle and the end-particle effect for that magic.

I already moved most of the functions to other scripts (those that execute the magic etc.) but the functions to add magic and those that send magic info to other scripts can not be moved.

Maybe there are still a few functions that could be moved to other scripts, but those functions really need the list of magic. In the stat-scripts I've duplicated some stats to other scripts with the method you describe, but the magic system works with a list of magic so I'de have to duplicate that whole list. It's possible and it could save me a few functions, but probably not enough to ensure enough space to go over 50 magic types...

Yeah I see what you mean Ama, but as I said:

"Another thing I could do is not remember a special particle effect for each magic but create a set of basic particle effects and only remember the type of effect and the color for each magic... but that sucks! I'm was just very happy with the system as it is "

yeah I could choose diffrent levels of variations in the particle effects, one with only the type and the color, another with the type and a few speed- and particle_count-parameters and the color and so on until the one I have now where I can almost desribe all the parameters of the particle effects.

Basically I choose for the system with the most freedom, because I don't want to change the backpack to much afterwards. I just finished the part of the system that can transfer all the stats, potions and magic to another backpack, so I can bring out new versions of DarkLife without people losing stats, but basically I want to be able to alter and add things to the game as much as possible without changing the backpack which is probably already bought by a lot of people who would all have to visit the transfer station and get a new version of the backpack (not even thinking about what would happen if I made an error in the transfer-code don't worry I've tested it well )

You get my point?

Erm .. yes, you did say that. hrm I should learn to read better.

I like the idea of dynamically changing an effect ... ie, you have 20 different effects, and for each one you are allowed to change say, two elements of it. Any two of a list. You could change the size and the color, or the color and the texture, or the flags and the you get the point.

But you are right in any case, as I said your preaching to the choir, I agree with you and am in a similar situation. My auction house system is 4 scripts big on one object, 1 script on a remote object. The smallest script is an inventory maintenance script at about 200 lines of code, and the main window script rings in at around 450. The problem is that so much of my code as it is relys on LOTS of data being available that I can't easily split the methods up. I tried and besides being ugly and breaking my code, it didn't save me that much memory. :/

Yeah but making and testing and implementing those 20 diffrent effects would cost me a lot of time. I think darklife has been delayed long enough

So everyone who wants bigger scripts or supports DarkLife or Ama's auction system, reply now to get this to lindens attention! topic is already moving to the bottom there are way to much feature suggestions here

Mark, why not move the magic parameters into a notecard?

because you still can't write lines to a notecard as far as I know?

More memory would be great. Have like a malloc pre-compiler ordeal to set the size so that one could still save the sim's memory (mini=2k, small=8k, normal = 16k, large = 32k, huge = 64k, microsoft = 128m, etc.).

However, I can't say I have ran into the strain too much, as of late. But also, mind you, my main project I am working on is using at the moment around 93 scripts within a single object. I completely dig Mark's dynamic ordeal also. I am in a similar situation where once deployed, it would be a royal pain to update each "client" object, however, due to the nature of the project, I must be able to. Pretty much, to remedy a lot of these situations, I created a sort of language interpreter which has each "set" of functions running in sepertae scripts, with enough room for any concevable temporary memory. As a result, I can basically make it do whatever, since again, it is a sub-language. While it does loose a _lot_ of speed on some functions, due to the constant need to send a hoard linked messages, many aspects, and as a whole, I feel it is faster than straight LSL. I think we can basically do a lot with our current memory situation, at least until LL gets pissy about 100+ scripted object, and thus, for overall sim performance, allowing more memory per script would stop the need for a large quantity of running (and probably less than ideal in optimization) scripts.

yeah I like the idea of a few predefined sized for scripts. I was thinking about why they haven't changed the size of the scripts and it was either "too difficult" or "will eat too much memory".
Maybe even let the user choose between normal script (16 k) and big script (64k) and set the default to normal.
I wouldn't mind paying extra for big scripts too...

What project are you working on that has 93 scripts in 1 object?

When you think LSL, think UNIX. The UNIX philosophy revolves around having a lot of tiny independent components that you can combine through shell scripting.
If your project isnt heavily dependent on real-time interaction, and it isnt, then its probably even possible to have a single function per script and a separate set of scripts just to hold data.

Link messages only work one-way... that's the problem

and still you could read the posts before you try a smart answer, I already said that even the data alone will get to big for one script...

Had a similar problem with one of my projects Mark. I'd for one would LOVE if they doubled mem size. If you have to store information about lots of players or whatever, you can run out of memory pretty quick. There are other solutions, like rezzing an object for every player and storing the data in the new object... But then any operation you need to perform on all the data takes longer because of the object->object communication.

More mem for data please!!

I disagree - while UNIX is designed to consist of lots of small eeeny-weeny little programs, that is not a suitable analogy. With UNIX you can call any of those programs on a whim, easily. LSL doesnt allow you to import functions from another script, so simply execting "y(x(z));" wont work, you need to screw around with all this link messages/etc which are really just a dumb method of communication to begin with, and certainly most of the time unnessecary.

-Adam

Expanding script memory will save overall sim memory because less script code will be written for communications.

It will also save CPU cycles because there will be less events triggered and less data handling and less if..else chains.

A variable system would save even more memory because small scripts wouldn't waste as much. I like Small (8k), Normal (16k), Large (32k) and Huge (64k) personally.

I'd be very happy with that

Consider this bumped . . . I need to poke around a bit to see if I was smart enough to make this easy to do !

Whee!

I like Ama's suggestion of variable script memory size selection.

While I cannot reveal the end product(s) that will utilize the codebase, basically what the 92 scripts (and growing) are forming is something between an API of functions and full fledge interpreted language, with a large focus on 2D displays and user interaction.

As a suggestion as to how to store a quantity of data that exceeds the 16k allowable in a single script, I have used scripts that only giant datamaps. By datamap, I am referring using a list that is the keys and list that contain the data. (See my array functions in the script forum). To call data, it is just a matter of sending a query down the linked message pipe, and the datamap script that contains the data responds. To set a variable, you have a master datamap script that tracks the estimated amount of free space in the datamaps, and then sends the data to a particular datamap script. Of course, it would probably not be overly useful in your application, since it would require a huge re-write.

NO! NO NO NO NO NO...

If only I had a valid point....

YES!