Wanted: your top 5 ways to improve scripting

For this to be visited and commented by a Linden in charge of making it happen.
No offense, but I've seen these abandoned o.o

1. Some form of large storage device (be it a Notecard or some Textcard).
2. Sending for RPC.
3. Increased memory.
4. Object Global variables (though not mine, I could get behind that)
5. Possibly a smaller send format than XML, maybe http post events as well?

1. llList2Notecard(integer startLine, key notecard);

Obvious functionality.


2. Sensor Return "Not" Commands

Example:

string name1 = "Jeffrey Gomez";
string name2 = "Someone Else";
key the_key = "fffff-fffff-fffff-fffff"

llSensor(!name1 & !name2,!the_key,"","");

... to return everyone BUT those keys. Useful in environments of 17+ returns. Let me know if that's already in existence.


3. list llSim2List(integer start, integer end);

Returns list of sim edges starting at return start and ending with return end. Logic being this would allow for pathfinding algorithms that work all of the time, and not just prior to any sim changes.


4. list llName2Key(integer total_number);

Blatant rip of Al Bravo's good idea. Returns first 16 key values for target name in the sim the object is in.


5. llTextureRepeat(integer face, float X, float Y, float top_size, float shear);

Modifies texture behavior on integer face by scale X and Y, as well as shear. Logic behind this being, residents currently have no control over the way textures "warp" based on the X and Y scale of a prim's face. Sure, we have control over the size of S and T, as rotated, but we currently have no control of the behavior of those faces if S and T are at an odd angle. Floats top_size and shear are runners to this, since that's already done with existing textures with top shear and top size.

1) Macro Substitution ... i.e temp&[test] equals the variable temp1 if test == 1 etc.
2) Lock Camera Controls
3) Find/Replace ability on script window
4) llRnd(x) function - a simple random number generator
5) Local Window - A means of displaying text and/or graphics to a single user. This would allow for some neat programmes such as card games

My 2 cents -)

1)



This has to be one of the best suggestions I've seen in the entire list... I have made a few objects that have well over 100 prims just so I can know where they click on the object. Man, it can be a REAL pain too... then I have to make a replicating object that can recreate them for me whenever I have to change the script inside each one of them... which brings me to my second one.

2) The ability to insert a pointer object to a script into an object or something so editing the master copy will edit all the child copies. This would also be extremely good for AUTOMATIC UPDATES of people's objects. I hate having to go find the person that made something to get an update.

3) Multi-dimensional arrays and possibly custom structures!!! SOOOOO important, and would help so much. Dare I suggest classes as well? (although I don't want it to go too far into OOP as it messed up PHP pretty bad when PHP5 came out) DO WHATEVER YOU CAN TO KILL THE IDEA OF A STRIDED LIST! I feel like a caveman with the way I have to retain information here... it's like the good ol' days of PUSH and POP in Assembly. NO STACKS PLEASE! geesh.

4) Ability to write to a notecard would be an extremely nice feature, I must agree...

5) MAKE THE OUTGOING RPC CALLS WORK, OR DROP THE DELAY ON THE llEmail FUNCTION! Until this happens, I'm going to continue to multithread the hell out of the scripts that require it. Just so you know.

That's my list. Hope to see some of these soon... if they do appear, I'll be the first to experiment and write all about them in the wiki. Keep up the good work Linden Labs! If you wouldn't have asked what we want added, I probably never would've suggested anything.

WOOT.

#4 can be done with llFrand(x). Check out the wiki page for it. http://secondlife.com/badgeo/wakka.php?wakka=llFrand

Neat. Someone from my home town.

Point 2 has been done in some capacity by select scripters. The most simplistic example is venders that store individual purchases and, when the vending machine's contents is updated, send the new copy to existing list(s) of customers. It may also be possible in some capacity to utilize script keys as an update "feature" - but methinks this would be more buggy, given how llRemoteScriptPin and llGiveInventory work.

As for point 3, why is this not possible with lists and a little math? At least, I would think it's doable...

Edit: Err, yeah. Strided list. Got it. But... still?

This, I think, is why LSL-based "languages" have gained some popularity. I'm happily oblivious to most of them, but give one a try?

Strided lists are indeed useful.

However, Lists - by virtue of being heterogeneous in their contents - are very memory-intensive (owing to the fact that they must store data-type information in addition to each value).

Arrays could lower the memory requirements quite a bit, by being a mechanism to store homogenous sets of data (as the data-type must only be stored once for the whole array).

Plus, there are some non-O(n) actions with Lists that could be more efficient with Arrays.

The reason IMHO that we don't have arrays in LSL, is because typical arrays don't have bounds-checking; which can lead to buffer under-runs and over-runs and other crashes & exploits.

But proper implementation can get around that - look at the C++ STL "vector" template class (basically a bounds-checked dynamically-sized array). C# also has some similar solutions.

Finally, Arrays (even these dynamic ones I speak of) can typically contain other arrays - to support multi-dimensionality. Lists cannot do this. Not as big a point as my others; but still a useful attribute. However, I think the "pass-ONLY-by-value" (no pass-by-reference) structure of LSL is more to blame for this not being a possibility.

Ah, well - I'm just sore about this because my game program just ran out of memory space again; and is only holding about 100 keys in a list, with 600 lines of code. The List is gobbling up by far the biggest portion of memory! But since its storing the keys for the various board-spaces, I don't know how I'm going to "split" this up into any more/smaller scripts! *sigh*

Take care,

--Noel "HB" Wade
(Tread Whiplash)

Oops. I didn't realize I was resurrecting a long dead thread... Sorry folks. I found this thread while searching the forums.

Aaaaaaaargh!

Well, let's hope the Lindens don't ignore this thread, anyway.
It's got a ton of neat ideas in it, stuff that really needs to be implemented and a whole lot of nice to haves, I think.

*meow*
Leopard Loveless

ahahah. And you got everyone so excited.

I only want one thing: sim debugging / griefer detection tools.

Ways to find out who's listening in, who's lagging the sim, who's scanning and spamming and then a way to eject them AND their objects.

I'd also like to see some sort of command, that allows an avatar to type command, that will only be sent to the object linked to them. So attachments would not have to use listens.

llFrand will only give you 24 random bits if you convert it to an integer. so if you want 32 random bits you have to merge two floats. Not optimal.

I've posted on Linden Blogs, Feature Request Forum & Script Tip Forum as to what would need to be done to make LSL better.

Kurt -

Several others have suggested IM reception capability on scripted objects... Think this would fill your need?

Take care,

--Noel "HB" Wade
(Tread Whiplash)

More memory. Period. Even QBASIC allows you 64kb of memory. Either that, or make link messages GUARANTEED to be received, because I'm having MAJOR trouble with a multiple script object sending link messages between scripts and those link messages not being heard half the time under high bandwidth conditions (which is the condition I require my object to function under).

Tread Whiplash can back me up on this, he hears me whining all the time about such things.. which he also happens to be working on something with a high number of scripts as well ;p Dunno if you tested it out yet in high bandwidth Tread, but it's a good idea to do so.

Hey Spuz,

I'd be cool with 32kb of memory for scripts! I just had to split my system up even more; its now 5 scripts on the game-board; 2 scripts on each game-board space, and 2 more scripts on each game-piece. And I've had to store more and more data in the pieces and tiles, because the main board scripts just can't hold 144 items in a list (72 tiles, so 72 possible pieces as well)... At least not when each script also needs about 500 lines of code.

Storing more data on the individual pieces means more Whisper() comms between them and the main board; and performance is slowing down noticeably! The game itself is still relatively quick; but still these delays are putting my "Beat The Clock" game mode in jeopardy. *sigh*

I still think Arrays would solve a lot of my problems - because of their lower memory requirements... Almost all of my lists are homogenous now anyways... They started out as bigger, strided lists; but the system just can't handle storing 72 big ol' keys + 72 integers. So the keys had to go; and calls had to go out based on the "index" of the integer in the list... Which forces all the items to listen and check to see if they match every "index" value in a bunch of Whisper() messages, and again slows things down... Argghhh!

In Short: Arrays would be nice; and more memory would surely be a nice thing! But how you'd expand memory allowances without taking the grid to its knees is another thing entirely...

Take care,

--Noel "HB" Wade
(Tread Whiplash)

1) A RUNTIME ERROR HANDLER with the ability to throw user exceptions
2) Objects can receive instant messages
3) Create new notecard in object inventory / write to notecard in object inventory
4) Arrays would be super
5) 32k would be nice, but is not necessary, and would be bad in some ways. I can think of some very good reasons to leave it at 16k. Also, I've not experienced a dropped linkmessage yet.

And some suggestions for the editor: The drop-down list with all the functions & declarations & constants, etc... If that thing would actually insert a full function/event declaration with arguments i would weep with joy. Also SEARCH & REPLACE!!! Probably too much to ask for, but the ability to run scripts in a step mode would be massively helpful for debugging.

All these suggestions are great, but all I want is more functions. All these nifty little doodads are great, but I am perfectly capable of coding around them. I'd much rather be able to do more with my avatar and objects in the world and in my inventory.

As a community, we would all benefit more from that sort of thing than we would from arrays or includes or what have you. (not that those aren't cool, too. I'm just sayin'...)

My #1 pick: Add to the 'channel' used by llSay etc. '-1 = message is sent to the owner of the object only'. At present there is only 0 = sent to all Avs within 20M, and 1 - 2million odd = sent to other objects running scripts. The result is that any scripted object that outputs a message for the owner has to use channel 0, which results in spamming all local Av screens!
So llSay(-1,"Jepack initialized" would result in a message seen oly by the owner Av.

#1: A return code for llGiveMoney().
#2: A return code for llGiveMoney().
#3: ...

Zep

The script editor we have does not support many things.
Top of my list are:

1) script single stepping (line-by-line execution)
2) scrollable list of all present variable values assigned at present line of execution
two lists. One local variables, one global.
3) breakpoint setting. executes until hits line, then enters single stepping mode.

Definitely needed, along with a return code for llGiveInventory.

No sure this will happen....

ARRAYS
Object orriented
functions (kinda like the include() function in PHP load functions for various scripts!)

male/female variable - something to indicate if the AV is a male av or a female av.

Lol, this thread began 06-10-2003, 06:03 PM. Is Aaron still working on this project?