Wanted: your top 5 ways to improve scripting

Already happens. Every time you hit save (even if you have a compile error) the script does get uploaded/saved.

-Adam

Nice idea. Let me just run back in time and get it set up. *poof* Here you go!

http://secondlife.com/badgeo/wakka.php?wakka=HomePage

Now all LL has to do is link to it from the scripting help page.

Heh.. I found the wiki independantly after writing that. But, yes, it would be nice if the wiki pages were linked from within the installed script help.

Hmm... I wonder if there's a way to submit the file back to Linden for inclusion in 1.6 when it comes out.

Something I have always wanted was a way the Wear things and attach things through the use of text commands. Things like llWear(Item) and llAttach(Item,location) would be real useful. Maybe something like this exists in present LSL... if it does, I couldn't find it.

I wanted to write a script so I could type:

/989Shape Mouse

and the script would make SL think I had just draged the folder called 'Mouse' in my 'Avatars' folder onto myself.

Or

/989Wear "Yellow Poka Dot Bikini"

And it would find the item in my Clothing directory called 'Yellow Poka Dot Bikini" and have me wear it just like I had just right-clicked on it and selected wear or dragged it onto myself.

or

/989Wear -d "My Favorite Dress"

and it would act like I selected wear for the whole folder called My Favorite Dress

So, having a LSL function that would let me apply a folder to myself would allow two of those cases. Perhaps the same command could take more or less arguements to derive the third form of that.

Once I had something like that, I could write my custom shapechanging and clotheschanging scripts.

-KQ

First post... only in SL 2 days... programmer in RL... usually make whole sentences...

1. OOP model (ala c#)..

2. prim and graphics creation / manipulation library (didn't see anything in the docs)... something similar in function to Java's awt... allow scripts to generate prims (or flat graphics) and manipulate sizes etc.. and the spawned prims could be "impregnated" with their own scripts. Many amazing effects and programs could be achieved with this. Perhaps a regulation mechanism to only allow "certified" scripts to access this prim generation library (this has 'virus' potential if the prim creation is stuck in a loop)..

3. publish a visual designer!! either in-game or separate studio, allowing rapid development would do nothing but increase the amount of people that script and increase the profoundness and power of those scripts that do get created. property view, event wiring, toolboxes, etc... (I may tackle this on my own anyway; I can envision .NET controls that spit out code blocks on a dime)

4. some sort of an interfacing mechanism for exposing functionality across scripts (kind of covered in the OOP model, but more specifically deals with interfacing)... this could be handy for creating a monitoring device to ensure casino machines are on the up and up, or for a vehicle tuning and management program that can be applied to any vehicle that exposes standard functions but behind the scenes does really cool stuff with the physics engine (RyeDinEngine.rmSuspensionSystemEngage() or RyeDinEngine.rmAutoPilotNavigate(vector destination))

4 and a half. I know it's really number 5 and number 5 is really going to just be a plug for myself, but this one is so important for sustaining really useful scripts and scaling them to ever bigger and more useful proportions... allow writing to notecards (or perhaps some other type of file object). I may have missed the boat because honestly I haven't written a single script in-game yet (but plan to do big things).. but it seems like people are asking for that one pretty heavily and if it's truly not supported in any capacity then something is missing. I suppose in reality there MUST be a way to persist data (like the XML-RPC interface for one), but having access to something within the physical and logical layer/scope of the running script is in my mind essential. Again, disregard this one if I'm just missing something...

5. Hire me.



-if you want to save something to a database somewhere you should look into the XML-RPC interface they expose (which I utterly applaude). This is about the equivalent of sending SOAP messages from a web service. All you need to do is have your site listen for those messages and act on the resulting data (i.e. INSERT INTO...) (how do you think the GOM ATMs work?) To make that interface more intuitive, just create a working function first (called fcMyXMLFunction(list myList) or something) and then copy that function into any script that needs it, where the function would take the list and issue a series of xml-rpc sends to your listening URL...

2. prim and graphics creation / manipulation library

llRezObject and llSetPrimitiveParams

3. publish a visual designer!!
I've always been confused by the concept of a 'visual' designer for TEXT, the raw letters aren't good enough? But this is getting into politics, so shouldn't be here

possibly something at the wiki is what you're looking for?

4. some sort of an interfacing mechanism for exposing functionality across scripts

llMessageLinked, or for unlinked things llWhisper

Does llRezObject actually create a new prim or is it for rezzing an existing object from your inventory? I believe it's the latter, but what I'm talking about is something like llCreateCube(list primparams) or llCreateTorus(list primparams)... does something like that exist?

A visual designer for text...lol. It's not a political thing, it's a power and productivity and rapid development thing. I checked out that wiki link, nope just a bunch of text editors. Ever use Visual Studio? anyway... scripting is scripting and visual designers are more for object oriented programming, which scripting is not, so it might be a long putt. But at the very least there could be a series of wizards to help more people get into scripting. For instance a dialogue with a bunch of sliders for setting all the vehicle properties that spits out a vehicle script...

um... llmessagelink and llwhisper. My understanding is it just sends a message to a specific channel, which can be listened for in another script. That's great for passing data and parameters back and forth, but interfacing is much more than that. Say you create a script that defines all the behaviors of a ball. You got everything in there, the way it should spin when thrown, how that affects it's velocity in all directions, how it should bounce, how force is transferred from external objects through its core and transferred to forward velocity (useful for creating a golf or baseball sim)... Well an interface would allow you to create 4 different balls, each with their own unique properties (baseball, golfball, basketball, tennisball), and then in the "custom" scripts for each ball you have something like #implements IBall interface#

Then you can define similar functions for each of the balls, each with slightly different results. That way you can easily swap out balls and the other interacting objects' code never needs to change. The ball example is a bit trite, but let's say it's a bowling program. You can have different balls that spin and grip the lanes differently, and the lanes and pins never need to know the difference, just that they were hit by a "ball". And each ball doesn't have to have ALL the bowling ball code as part of it's script, just the part that makes it unique from the other ones...

Actually, I'm willing to bet Linden Labs is using some sort of interface for vehicles.


Sorry so long... I'll try to refrain, I'm just really excited about SL.

Hahaha, yeah you are. Welcome to SL; It gets even better!

Why don't you try... logging in?

I think your going to find the Linden's arn't after making your scripts for you and that includes visual designers and scripting wizards. If your interested in llCreateFoo make it yourself. Create each of the prim shapes in its basic form with a small script that listens for new primitive params and drag them into the contents of a "master object" that also includes the actual object cloning script and spits out proper dimensions. I liked some of your ideas, but as spuds mentioned, llRezObject and llSetPrimitiveParams will do what your asking already so it might be a good idea if you actually play and create a few things before you decide what is and is not possible or needed.

yea.. i know... I'm going in right now. I can't play from work (obviously), so I must tide myself over by reading the forums in the morning and at lunch... thought I'd just jump right in

Thanks for the tips. I'll come back here in a while when I know more stuff, heh.

ooo i can't wait.

Here's a really really trivial thing. Either allow globals/constants to be defined by something that's evaluated as an expression at compile time (ideally), or include one of MINUS_PI_BY_TWO or THREE_BY_PI_TWO as a constant. Currently I have to manually write out -1.57...etc to define lists of rotations for use in a script.

It'd also be really nice if the seemingly arbitrarily limit on constant-defined lists was removed and you could just define them up to the normal memory limits. I just had to jump through hoops to split a script into two, as I needed a list of 81 strides, each stride having four items in it, so I had to define it as six separate parts which are then added together in the default state_entry, which ends up causing some extremely inefficient memory usage (there seems to be no way to 'free up' the space used by the parts, setting them back to []; made no difference), and so little space in the script for anything else.

I want a thread that deals w/this.

I haven't read through this whole thread yet (though I did several searches with no results), so sorry if I'm bringing up something that's been dealt with already.

I've just recently started scripting and I've noticed from talking to other scripters, reading the documentation, and my own experience that there's a lot of annoyance with llSetPos and llSetRot functions not working when the object is attached to an avatar.

Maybe it's just childish, but I think I could make a lot of cool things if I could make an attached object animate in a non-discrete way. One wouldn't have to rotate or position the whole object - just changing the pos and rot of a child object relative to its parent (which could be just an invisible alignment marker) in an attachment would let you get that effect, as well as many others.

So, rotation and positioning control within an attached object would be #1 on my wish list for scripting.

Just what we need- Rotating, Flying objects that can be attached and worn in the hundreds.

llDialog()... it uses a listen... what i often do is randomly generate the listen channel and then remove the listen when a choice is made... Also, it seems that the voice of the person when they choose emenates from the object itself... For instance... you can be in another sim on the other side of the grid and the object will still hear the button press just fine...

not many people seem to know about llDialog()

1.
integer succeeded llGiveMoney

llGiveMoney already returns an integer = 0;
so adding this would not break any existing scripts.

2.
integer amount llGetWalletSize(key id);
Would hafto have PERMISSION_DEBIT on id.

Now I know your thinking,, but what about
llGiveMoney(L337Haxor, llGetWalletSize);
But cmon. like thats not already possable.

integer i;
for(i = 0; i < 10000000; i ++){
llGiveMoney(L337Haxor, 1);
}

3.
include key or script name.

4.
llSetLinkTexture !!!!!!! please.

5.
llDoWhatIMeanNotWhatISay(integer enabled);
If enabled = TRUE
The script will assume psychic mode, where it will preform all functions exactly as the creator is thinking they should rather than preforming them as they are typed.

Here is a valuable feature not likely to make it.
Because it is too subtle, and difficult and long-winded to describe.

I'll try.

What's needed can be done several ways. The long outstanding feature request thread from 2003 calls it:

llGiveSelf or llGiveMySelf

This allows a script to put the object it is in into another object's inventory (contents folder).

Why?

It really is long winded but bear with me........

To avoid confusion, note first that none of this has ANYTHING whatever to do with an AVATAR'S or agents inventory.

Using scripts we can rezz an object into the world. We can then modify that object by script, either directly using a script inside it, or indirectly by giving it commands from another (like maybe the script that just rezzed it).

What we can NOT do by script is to get it back where it came from (in object inventory) after it has been modified. Only a person present at the time can do this.

What this means is that we CANNOT AUTOMATICALLY MODIFY an object which is stored inside another. We need to be able to do

rezz -> modify -> retrieve.

The last step is missing. So nothing inside an objects inventory can be auto-modified at all. We need human intervention to retrieve it after auto-modification in-world.

Either llGiveSelf, or llTakeObject, would give us the last step. They would therefore give us the new power of automatically modifying in-object-inventory objects. llGiveSelf seems better because it raises fewer permissions issues.

If you can't think of a use for this, do a forum search on llGiveSelf and llGiveMyself to find threads-worth of people who have been requesting it since 2003, and why.

Personally, I want to do things that are absolutely impossible without it. When you need it, you really need it. If you think carefully, you might find you do too. Opens up all sorts of auto-rezzing, product customizing capabilities, as well as the more subtle stuff in the threads.

Clever vendors for instance.

Bear in mind, when you auto-customise something (in a clever vendor, after maybe auto-discussing it with the purchaser), you may need to change MORE than the externals of the object (easy). Changing things INSIDE its contents folder before you deliver it to the customer is currently IMPOSSIBLE. You need more than just
rezz->modify object ->deliver.

This feature would also give us, as a side bonus, a solution to the problem of a persistent data storage mechanism, which other feature requests here address. An object can hold (and MODIFY) a pile of objects which hold persistent data for it. In their name and description fields, and even coded into their prim characteristics. This is not the main reason for the feature, but it does kill two birds with one stone.

If you want, Lindens, go much much further and give us a mechanism for modifying objects (and running their scripts ?) without rezzing them, whilst they are still in inventory. But that seems far too much to ask.

Rezz -> modify -> retrieve
would be fine.

Good idea

This is an ancient thread, but its nice to see it all in one place so I'll add my 2c.

1) Hash/Associative Array/Map/Dictionary type.. whatever you call it, a key=>value structure for easier and faster lookups.
2) Data persistance - be it in notecards or whatever, and with per-prim limits - whatever it takes to safely store some data
2a) maybe Linden Lab could provide an external xml-rpc capable server (with db) to this end (possibly with an additional fee) for those who cant provide their own, or would rather leave server uptime etc. to the lindens. (not that I like spending money, but someones got to pay for this stuff)
3) State scoped variables. Not seen this one (I read the whole thread). I'd like to scope a variable to a state block - so it would be in scope and available for all the event handlers in that state, but out of scope (and garbage collected) for any other states.
4) Ditto functions. It would be nice to be able to overload.. and if scoping is working correctly that should just happen - to have a function or variable of the same name in each state.
5) Multiple timers, with timerID.

thanks for llOwnerSay.. despite the silence, I'm confident someone's reading this thread and cherry picking the more practical ideas.

Hi everyone,
I ditto the normal requests:
-- Switch/Case
-- Arrays
-- Structs
-- C type string handling char[], strcmp(), strncmp(), isalpha(), etc.
-- writing to notecards
-- I may be pushing the limit here, but pointers would be nice too. Not sure how hard that would be to implement. But that would allow (with structs) linked lists.

-- llDistanceToGround()... unless there's already a way to do this; a function that indicates the vertical distance that an object is from the ground. An example would be if a scripted object was is travelling across an area at an altitude of 100M and it encountered a hill that was 80M high then llDistanceToGround if called at that time would return 20.0M when the object passed over the Hill.

I thought this was a good idea.


Even though the improvements to the building interface have made it a lot easier to make stuff. I totally agree with Piprr on just about everything.


This is probably the most HUGE hot button for me.


I live far away from a major city. I do most of my development work from my home and I commute into the city one or two days a week.

There is no broadband access where I live and none planned for at least a year or so.

My SL experience is very limited in the sense I can never really get anything accomplished. The little time I do have I like to socialize with my friends (who have access 24/7) When I'm in world and they're in world we talk and have fun. But when I am gone, they can get on with the business of creating stuff and scripting. Since I spend most of my time socializing there are weeks that go by that I don't create anything or even try to script anything. I get "rusty" just trying to remember the interface let alone the various scripting commands and how to implement them.

For me I have to spend time in a language to get comfortable, to be able to just code what I see in my mind that I want to do. I spend most of my time looking up language specifics (how do I implement this or that) By the time I have sort of figured something to try I wind up having to put it away till next time. So the process repeats over again then next time I'm on. Looking up what I forgot from two or three weeks ago.

I have longed for something what would resemble a single sim local to my machine where I could create objects and run scripts. This would allow anyone (who might have a similar situation) to build stuff during the the time they are off world. It would be a much better SL experience for me if I could create something (objects, scripts, clothes); get the bugs out and then either upload it or recreate it online. The scripts could easily be uploaded (copy / paste). If the prims couldn't be uploaded I could easily recreate the object dynmically in world. Clothing textures could be uploaded because they have already been tested on the local machine sim.

The sim could be a non terraform generic sim with a few hills and some water so that one could test various functions for hovering etc.

If this were possible I could still socialize and actually have the satisfaction of creating some stuff too.

The offline scripting would be a huge benefit because of the "extra" time I would have to work with it.

Many regards,

wizzie

Oh yes, wizzie, yes.

An offline sim for prototyping and testing, with direct exchange of objects to the online world.

Even for those with 24/7 access, how great to get on with some work without the knowledge you are offending your g/f by preferrng this to her company !

The other way is to have one alt for socialising, and one for work. But the bright girls soon catch on !

I've not done much with scripting so far but have run into a few issues currently that result from scripting permissions. Even if a script is no-modify and therefore hidden it should be possible to view and edit the channel it responds/listens on and the commands it accepts. I've run into many instances where mutliple objects listen on the same channel and if they are both no-modify I can't get them to play nice. Also some scripts share commands to activate and it would be nice to customize the commands to avoid conflicts. I feel this would not endanger the IP of the script itself as it only affects how the user activates the script and doesn't not reveal how the script works to the user.

Tied to this (and being new there may be a way to do this and I just haven't found it yet) is the ability to scan your attached objects and find out what channels they are listening on. Especially in cases where the scripts are no-modify and don't provide useful help dialog it can be hard to figure out what channel to send commands on (poor scripting but when you pay a good chunk for something then can't get it working it gets annoying).

Change the default behavior for script output (command/help usage messages) to IM mode rather than say. Again this is to cover up for sloppy script work where many make objects who spam the area with lengthy usage messages when worn.

The ability to surpress a scripts 'help' feedback. This is a minor thing but it does annoy me at times that everytime I TP or change outfits I get about ten usage messages from my attachments that have scripts.

The ability to supress a voice command that triggers a script in the way you can create a gesture that replaces the trigger text with an empty string (although I prefer it when an item uses a channel to listen for that very reason).

Sorry if some of this is already there as I've not yet gotten to working on scripts beyond a few basic tweaks on modifiable ones that came with purchases. These are based on my observations of how scripts appear to be commonly implemented.

All of these have been mentioned by others, I'm just adding my vote(s)

Sounds like you've just been exposed to some sloppy scripting. The non-editable therefore non-configurable scripts just need to use a notecard to get their user configurable parameters.
The spamming script output is already fixed with llOwnerSay().
The script voice commands should be using a private channel, e.g. "/7 do something"

The scanning for channels/ports concerns me a little, as the inability to do this (easily) is currently the only measure that assures some privacy and security for av to script communication.

Contact me in world, or check in the script library for examples of reading from a notecard for doing script configuration, or any of the above.

*WARNING* Newbie Scripter.


I Don't know enough about to make suggestions on any ssl but i would like to see some changes in the way we could edit scripts.

1. Cut and past form right click, without having to go to the menu bar
2. Find and replace
3. Auto formatting And/or an format checker
4. an drop down menu of some frequently used commands
5. A bigger scripting library
6. More classes and in world interactive tutorials
7. A Method of Downloading the entire scripting library directly into my brain.