Wanted: your top 5 ways to improve scripting

Alot of the stuff in your post is already implimentd

I believe the moon is always opposite the sun, it makes sence, ill code up a test and get back to you.

llGround(<0,0,0>; gets the height of the ground underneath the object that called it.

Many psuedo-multidimensional array implimentations are available in the script library/Scripts and Scripting forum, I *would* still like to see true arrays though

llEdgeOfWorld(vector pos, vector dest)

Checks to see if the line from pos to dest goes offworld. I coded an extention to the function, Ill post it to the script library ASAP.

Multiple timers are implimentable, but very cumbersome.

lets see:

llSetTimerEvent(0,1);
llSetTimerEvent(3,5);

timer(integer num)
{
if(num == 0) //1 sec passed!
if(num == 3) //5 sec passed!
}

Ooh, I like that idea, still, you can do it with the current language.

To be even more pedantic, wildcards are a subset of regular expressions.

E.g. the wildcard pattern "foo*" is equivalent to the regular expression "foo.*", while the common interpretation of "foo?" (foo followed by exactly one character) is "foo."

ZHugh wrote:

"For the medium-term: migrate to high-level scripting language
We've looked at a lot of the detailed concrete changes in this thread. I'd like to take a broad big-picture view and look at the language itself.

"The SL graphical and MMORPG engine is the best I've ever seen. The dynamic content loading, and the quality of the graphics and physics are staggering.

"In parallel, the stunning artistic creativity in the world is evident everywhere one looks.

"Still, there is something missing, which could loosely be defined as 'active content', and more precisely as scripting.

"Dynamic worlds represent the future of the MMORPG genre. They simplify content generation and allow players to generate the content that they want. But it's not enough that the world looks awesome, it has to live and breathe, and this is where scripting comes in.

"Lsl script is a powerful, highly-optimized language based on C. For developers it is fairly easy to pick it up and use it to mold the world.

"To enhance content-production, I think we really need to make scripting accessible to non-developers. It's nice to have non-developers ask for our help, but it would be nicer to have some great Active worlds to explore!"


Just to bump this, there is a very interesting article in ACM Queue entitled Multi-Language Development"

http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=116

"Computer games (or "electronic games" if you encompass those games played on console-class hardware) comprise one of the fastest-growing application markets in the world. Within the development community that creates these entertaining marvels, multi-language development is becoming more commonplace as games become more and more complex. Today, asking a development team to construct a database-enabled Web site with the requirement that it be written entirely in C++ would earn scornful looks and rolled eyes, but not long ago the idea that multiple languages were needed to accomplish a given task was scoffed at.

[...]

"The games community has embraced the trend of multi-language development and undergone what could almost be described as a revolution in the past few years. Gone are the days of hardcore assembly number crunching and small teams of developers throwing out thousands of lines of C-header files. Instead, the gaming community is using several languages large and small, some off-the-shelf and some of their own design, for a variety of purposes. The fundamental tenet of when to use what is now a choice based on developer audience and specific capability—as opposed to raw performance power."

[...]

"In addition to custom language development, other popular choices are Java, Lua, Python, Ruby, and Lisp. Python in particular has been used in a number of recent projects including Toontown (Disney Interactive, 2003), Eve Online (CCP, 2003), Blade of Darkness (Codemasters, 2001), Star Trek Bridge Commander (Totally Games, 2002), and Earth and Beyond (Electronic Arts, 2002)."

Azelda

1. real arrays
2. real boolean
3. switch/case
4. search/replace feature
5. double script memory

So lets see... this thread is 10 months old... How much of this stuff has gotten done yet?

I realize that 1.4 or 1.5 is intended to be the LSL upgrade, but... *sigh* I'm impatient. And I wasn't even around when this thread started.

1. llList2Notecard
2. llList2Notecard
3. llNotecard2List, asynchronous using an event when finished
4. Ability to directly write text to a prim face: llDrawText("Hello World!", ALL_SIDES);
5. Debugger: step debug, call stack, watches

> Ability to directly write text to a prim face: llDrawText("Hello World!", ALL_SIDES);

- Hank, check out XyText. It's terrific, and it provides you with a ton of flexibility. Yes, it's a "little" prim heavy but it's just great for things like scoreboards and stuff.

> llList2Notecard

- We really should be able to write to notecards. This is a critical functionality

Azelda

#1 thru #5 - write to notecard...

...or other means of persistant data storage. Even if there's a hard limit on the data size, SOME method of saving information so we can actually do things beyond temporary data games/thingers/widgets. Even if it's slow, I don't care, I can wait for the dataserver to wind up (although, naturally, fast would be nice).

1) Camera Controls - especially rotations

2) Arrays - I imagine once you're past 2-dimentional, it's all the same at your end... but anything more than lists would be appreciated.

3) Write to notecard - if not actual notecards, some form of persistant, editable, retrievable data storage.

4) llEmail to include multiple stings (emails longer than 512 characters, or what ever the current limit is)

5) Some form of incoming sound control (detection would be nice, too)

PS: the moon is always opposite the sun, even though that's not the case IRL, i.e. SL cannot have a solar eclipse.

There is a slight, very slight difference in the speeds of our sun and moon, but at this rate, there will not be a solar eclipse for another five hundred years. The last one occurred during the time Shakespeare's Othello was first presented and Tsar Ivan IV defeated False Dmitri, who claimed to be the true tsar.


Lumi

I don't want to hijack the tread, but:

Lumiere Noir said:



There are roughly 2 solar eclipses a year. Not all of them total; given any single location, they are indeed exceedingly rare. However, the earth as a whole experiences a great number of them - including 1 to 4 total eclipses every 5 years.

Even without an eclipse, you can observe the moon and sun in the sky at the same time twice a year (or so) - which isn't possible in SL (save Linden involvement). Given SL's day/night cycle, it should occur even more often, but it's hardly worth the effort, imo.

If you doubt me, perhaps you'll take NASA's word for it here.

(edited to add) There is a huge difference between the speed at which the earth revolves around the sun, and the speed that the moon revolves around the earth - but that's almost irrelavent, because it's different centers and sizes of orbits.

1. Switches/case
2. arrays
3. recieving ims
4. more control of prim aspects/properties.. i.e. being able to lock/unlock.
5. Perhaps instead of #includes as was suggested, a java import might be a bit simpler for the uses we would have. Perhaps something like

import scriptA;

///we're in scriptB

default
{
     integer hoot;
     on_rez(integer a)
      {
         hoot = scriptA.getNumOfBannanas();
          // or
          string name = scriptA.strg_banannaName;  //global var access.
       }
}

Though I'm not sure how well that would fit in.


One final thing that I would love to have.. A rudimentary pseudo compiler/debugger that runs on my pc. There are times when I'm away from home on my lappie(no sl on that) and I'd like to tinker with some of my scripts. Right now I write up a bunch of code, get back later, paste it all in and debug. If I could at least see if it would compile... fixing those syntax errors while bored at whatever rl function I'm at would be mint.


grrr typos

1) Improved particle system controls (see post)
2) Dialog window creation with slider, radio button, check boxes and buttons.
3) Write to notecard
4) Better scripted object animation control (bezier spline type movement functions)
5) Improved string parsing.

Thats my top five.

Yeah, I could definitely go for a Switch/Case statement.

I finally get it --the name.


How bout a llGetNecroPoster()?

looks like that'll take at least a year for them to put in... since few of these have been added yet...

1) Read and write from/to notecards MORE THAN 1 LINE AT A TIME
2) User editable variables (without script mod)
3) Real-time editing of variables
4) Errors that DONT CRASH OUR SCRIPTS
5) Some special type of script with more memory... maybe even pay-per-script if its necessary, but really

1) Arrays
2) Includes
3) Easier 2-way communication with the outside world than XML-RPC/llEmail()... its klugey. Check out this proposal:

The problem, as I see it, is that currently you need to use XML-RPC for inbound communications to Second Life, and email for outbound communications. This creates a situation where you have far too many points of failure, and creates a significant amount of work for anyone using Java/JSP, PHP, and so on.

What I propose is a function:

string llTouchURL(string url, integer length)

Basically, the Second Life server would go to the URL provided (say, “http://foo.com?this=1&that=SL%20Rules!”) and return up “length” characters from the URL. By using the web, this creates a simple 2-way communication device invoked from within SL to any web server out there, without having to set up something involving, for example, compiling PHP-IMAP and XML-RPC into PHP, which is a long, arduous, tedious process. Also, many shared web servers out there do not provide anything close to this functionality “out of the box”, so if you don’t have root, you’re up the creek without a paddle.

This function raises the problem of possible spam / DOS attacks. Here’s my solution. From the web site, under MY ACCOUNT, create another link, “White listed URLs” (or something to that effect – I’m not a copy editor!) It would be empty by default, with an ADD URL button.

If I click ADD URL, and enter http://foo.com/bar/, SL would look for a file, http://foo.com/bar/sl_key.txt

Within that file would be, one per line, the names or keys of any avatars who are allowed to send and receive using llTouchURL from http://foo.com/bar/* URLs. Any time a user tries to add this URL to his or her “White List”, it would check that file to verify that the key or name is present in that file, thus creating a situation where you can verify that the URL being used WANTS to communicate with Second Life. Then when the function is called, simply do a “SELECT * FROM white_list_url WHERE avatar_key = ‘ “ + object_owner_key + “’ and url = ‘” + passed_url_from_llTouchURL + “’”

If it returns true, you will know to execute the function otherwise, perhaps pop a “Communication with URL not permitted. Check your white list.” error.

I can’t really think of any cons, other than requiring a fair amount of work on the Linden Lab end.

For pros, I see a much easier way to provide 2-way communication, a much lower entry level, a much quicker deployment time, and a much more stable environment. Instead of having many potential points of failure (SL itself, SL’s inbound/outbound communication, XML-RPC, email server, email parser, programming language/web server) you have two (SL itself and your programming language/web server).

1) Write to notecard!
2) Direct object-to-object inventory transfer
3) #Includes!
4) More script memory
5) Prime-wide variables storage (like a 'global' variable available to all scripts in prim)

Me too!

xml-rpc send
xml-rpc defining what will make up the xml document ie what's being sent
llTeport ( avatar, sim, pos, rotation )
be able to update the set sit position, while an avatar is seated, and have the change take effect.
land pass dosen't work, but I wish it did
point dosen't work, but I wish it did
localVec to simVec, simVec to localVec
localRot to simRot, simRot to localRot
be able to cancel permistions
sensor being able to detect more then 15 avatars
Being able to make copys of a script
being able to revoke permistions ether by ui or by scripting. and posible After that global range for animation
ie:
llGetScriptPerm
llGetAllScriptsWithPerm
llRevokeScriptPerm
Being able to modify the avatar via sls scripting, specifically hair color
script to script comunication , with out link sets, and with out llSay or Shout, or e-mail
two way comunication between a script and an avatar, via private instant message
html post
hmtl send


long term or short term
variable type: type
classes
arrays
overloading operators
overloading funtions
# include
write to note card
longer note cards
I like the idea of changed ( integer change, key id ) Asumming it is only triggered when the

arrays would be okay, but List's pretty much cover that (perhaps just [ ] overloads for lists?)

#include/import would be cool, but I think it should only be extended to global functions/variables and should not support state/state changing of its own unless Linden is willing to go the full OOP model and support overloading/inheritance.

and out of SL script debugger/edit would be ideal. The in-client text edit is okay, but it's missing too much I take for granted (Textpad/Ultraedit functionality, or any uber notpad for that matter) and pretty much code all of my stuff external from the game. Why not just expose a webservice that takes a string of LSL in, and returns the compile result out. No testing, no runtime debugging, just general syntax logic checking for now?

Built in string formatting, be it via an sprintf() like function or whatever, a quick easy way to format strings. (yes there is a sprintf like clone on the wiki, but without #include support its a pain to have to copy/paste a ton of 'utility' code into each script and it ends up burning memory as it requires some support globals)


Don't really have a #5

1. IM Object-to-Object anywhere on the grid

2. Ability to rent/purchase/claim semi-permanent keys (so objects can continue to read an updated notecard or an object can be taken to inventory and re-rezzed without losing it's key.) This would lessen the need for object-to-object sim-wide communications.

3. Write data to a notecard and faster reading of a notecard

4. Ability to keyframe the camera with interpolated motion

5. Simple degree-based rotations... I've read Bad Geometry yet still rely on trial and error for all of my rotational scripting needs. My brain doesn't visualize in radians and quaternions.

1. Data Storage Object
People have been wanting to write to a notecard for that, but that'd be a workaround. What is needed, tho, is some way to permanently store data somehow.

2. Hashes/Arrays
For easier data handling, also might be uf use for these data storage objects I mentioned above.

3. Touch Event Coordinates
It'd save people many prims and scripts and problems if we could get a feedback exactly which prim and which face and, on that face, on which coordinates the user has clicked on. This enables to create user interfaces with multiple hotspots without the need for tons of prims. Even better, we'd see dynamic interfaces pretty soon, I'd think.

4. "starts with" with llListen
Most voice commands for an object start with a static command, followed by some parameters. Right now, the only way to do it is listen to everything and check yourself if the message starts with a specific string. This sure is far slower than if the server would filter that.

5. Documentation Issue: 3D Math
Most people don't really know anything about vectors and how to manipulate them. it would be neat to see a documentation about what do do to, for example, rotate an object from one angle to another, detect which direction the object is facing, etc.

Take care,
Leopard Loveless

1. offline LSL compiler with more intelligent responses for errors
2. variable passing between objects that is more efficient than llSay
3. variable/state viewer for scripts in world - debug menu?
4. fix the rounding errors
5. move single prim in linked object without unlinking

Native HSV color.
I would like native support for an HSV (hue, saturation, value) color model.
It can be done with a function, but with added sim overhead. RGB is not that
intuitive for many people, and HSV can be much more useful in many 2L contexts.

A simple surface patch.
Something simple like a 4x4. Or driven by the new array type when it's implemented(!)
Would provide a huge number of building possibilities that we can't do with quadrics.

A directional light source.

URL specified texture maps.

URL to notecard.

#include <notecard>

Text to Speech, using AT&T's Natural Voices.