Scripting standards?

So, after two months in SL, one of the things that I've noticed that I don't appreciate about the current scripting environment, bot as a coder and a user is the lack of standardization on the communications channels for scripts. Yes its possible to write good code that can avoid crosstalk, but it takes work, as the entire chat channel system seems to be generally treated as an audible endocrine system; an object can't send a specific message to a specific object, but rather everything in the area, and it's up to the end listener to filter useful data from non. And from a user perspective, I've now got objects that need commands in the "/## command" form, "/## object command", "/## object=command", and "/## object:command". Not to mention all the channels (the "##" above) are all different.

Which has led me to wonder if there's a calling for a coding standards group in Second Life. I envision something similar to Underwriters Labs in that scriptwriters could get their scripts tested, and if they comply with certain generic standards of coding and communication (i.e. all "approved" scripts use the "/## object:command" syntax for communication, use no empty llListen commands to reduce lag, and comply to a [yet uncreated] channel map to minimize crosstalk), they can display the group's "badge", so concerned consumers could look for the badge as a symbol of quality and could expect a standard of performance from the item.

Does something like that exist yet, or do you think one would be useful if I founded?

Regulating programmers is often likened to herding cats for good reason.

Why would someone bother to submit scripts to such an agency? How many of their possible buyers care if the product complies with such standards?

Most buyers are interested in price, ease of use, and features. The object:command syntax violates ease of use, and only a few buyers would care about the standard.

What does the average consumer care about crosstalk? As long as the objects work and don't cause noticeable amounts of lag, most consumers don't care whether it's done with one sleek, streamlined script that doesn't pollute the chatwaves, or twenty scripts that open multiple listens and communicate constantly.

Admittedly, coders care about such things, but we are in the minority. The most that could be expected of the average user is concern about lag, but that is an issue different from input syntax.

It is much simpler to write an llListen() on a different channel along with a series of if-else statements than it would be to listen on one channel and have to correctly parse commands that may be intended for other objects. Besides, it is easier to type "/5 action" than "/42 gadget:action".

Thus, the primary producers of products wouldn't feel sufficient need to comply with such a standard. Not enough of their consumers would care about it to justify the additional work that it would take to change the communication handlers. There is no way to require compliance either-- SL has no such governing body.

Overall, such an organization would, in the end, have very little real effect.

This is not to say that I am against such standards. I am all for clean coding and standard compliance, but it is hard to force it upon people. Perhaps what would be more helpful would be to write an abundance of code samples that use the objectyntax format for their listens, thus making compliance the easiest path.

It would be great to have a single document with "recommended practices" and script examples for coding, but certification seems ineffectual to me.

Thanks for your reply, Keknehv! And while I agree with many of your points, I think you missed the main goal of such a venture. Are you familiar with Underwriters Labs (or read the Wikipedia reference in my first post)? No maker of electronic components are required (at least in the US) to submit their product to UL; its a completely voluntary action by the producers of a product indicating that they're willing to put forth more effort to create a quality product (as judged by UL). Hence, submitting a script to "LSL Labs" (actually, I was thinking of "Moonlighters Labs" as a name, both in reference to scripters moonlighting in SL, and the Real World UL) by an SL coder would be a totally voluntary action, and indeed not a lot of people may see the need for it at first. But my hope would be that it would eventually gain a reputation as a collection of stable scripts that people can rely on certain functionality being there, and for the coders, it's a community of like-minded coders who care about cleanliness and efficiency of their code. And of course with standardization would come coding samples/libraries that perform the standard functions to help new coders get off the ground. I wouldn't think that many existing scripts would be submitted, but coders writing new code may see the benefits of conforming to a group standard.

Some ideas I had for the Standard that would be laid out were like this:

Chat Channels
To ensure clarity of communication between scripts and other scripts, and avatars and scripts, as well as to ensure that all MLL scripts will function properly, even when many are placed physically close to each other in-world, the following chat channel standards will be met:

If a Moonlighters Labs script (MLL script) needs to listen to communication from an avatar, they will do so on at least two channels. They will listen on channel zero for commands of the format "object:command", and to channel 65522 ("MLLAB") for commands in the format "object:command". These are "all MLL" channels that all MLL-compliant scripts utilize. In addition, each MLL script author will be given a section of the chat channel spectrum (which will be documented somewhere for perusal), where scripts can optionally listen to for commands in the format "command".

If an MLL script needs to send data to another script, it will do so over channel -65522 (notice the negative symbol) in the format "object:command", or over the negative version of the author's subsection of the spectrum in the format "command".

Basic Commands
To ensure ease of user use when dealing with a MLL script, the following commands must be able to be understood by all MLL scripts that have the indicated capability. If the command is broadcast over channel 65522, all MLL scripts within hearing distance must respond if the speaker is their owner.

on Lights/lamps/glows turn on, vehicles/machines/sensors engage, etc.
off Lights/lamps/glows turn off, vehicles/machines/sensors go dormant, etc.
open Doors/windows/vehicle cockpits open (if user has permission)
close Doors/windows/vehicle cockpits close
show Poseballs/Hidden/debugging/translucent aspects of item become fully visible
hide Poseballs/Debugging/translucent/guide aspects of item return to hidden state
minimal Particle effects/Animation overrides/extraneous scripts turn off (everything the object can to reduce lag while still functioning)
effects Particle effects/Animation overrides/other effects enable (we're not worried about lag at the moment).
identify Script must respond with a one-line IM to the speaker giving the name of the MLL object that heard this message.
object:help (Where "object" is the objects MLL name) Script IMs help information to the particular avatar who spoke this command.

Configuration notecards
If a script is to use notecards to configure its performance, those notecards are to conform to the Windows INI file syntax. Meaning, comment lines are indicated by a ";" appearing at the beginning of the line, the configuration can be divided into sections, by placing section headers on their own line enclosed in square brackets (i.e. "[SECTION_NAME]"), and all other lines of the configuration are defined as "variable=value".

With these standards, there could also be a primer posted for users of MLL scripts, letting them know that if they purchase several MLL items (say, a door and several lamps), they can enable them all with a "\65522 on", and if they forget how to use an item, a "\65522 Lamp:help" will get them help. It also gives them the simple user interface of "\65522 command" if they only have one or a few MLL items, or more advanced commands if the user wants more customizability. It also means that a standard users' guide could exist to teach people how to use the items so that object creators don't have to re-explain everything each time they make a new item.

For coders, a listen event handler code snippet could exist that parses out the handful of generic commands and calls specific functions for them.

This assumes that most of the scripts are written and/or modified by actual programers. I am no where near a programer but I love experimenting with my own scripts and chopped up scripts from others. Why would I, as a "hobbiest", care to join a group like this?
I bet I'm just one in hundreds that feel the same way.
On another point, I do use listens and always use some other channel as I do hate those open channel listens too. One thing to concider is maybe have more example scripts with ways to reduce lag like the best way to use listens, the best way to turn off a script when not in use...or are these already out there?

Well, by my book, if you have written a program, or at least looked at source code enough to make sense of it and cobbled together something else, you're a programmer, though I'd agree with you that there are some degrees of knowledge in the area.



Hobbyists like yourself wouldn't need to "join" the group, but rather the group would already be comprised of a group of experienced coders. Then if you, as a hobbyist who can appreciate the benefits of a low-lag script and would like to make yours as lag-free as possible or avoid open llListen calls, you could approach the Labs looking to get a critique on how your script could be made to conform to the Lab's standards, and you'd be able to work with an experienced coder on how to modify your script. If you did take their advice and went back and modified your script, you could re-submit it and probably get a certification badge for your script from the Lab.

How's that sound for benefits for "non-programmers"?

I like the idea of the "best" ways of doing things being kept somewhere, though I can see there being at least 3 standards for most things, but I think a certification agency would be getting ahead of ourselves. I can't even find a good reference of how various things are handled server-side (recent examples: having to run tests to establish where it's best to filter chat, relative speeds of functions) so I think something in that area would be a better place to start if you want to regulate scripting more, then once that's down it could be used to establish best practices.


Using chat for anything other than data-entry violates ease of use. But then, SL makes keeping to those guidelines practically impossible anyway: No more than 200ms before feedback from any command? Interface transparency? Accurate displays of how long something will take? Ha! Hell, we don't even have proper access to the tools, you have to ask someone to mess around with a separate interface before you can even establish one yourself.

Something you've overlooked is that a number of items out there are specifically written so that they are "unknown", Frequency; or at least channel, agile communications gear for war gaming as an example.

There are also systems in use where the manufacturer want to keep it as a closed market.

I've created a protocol page to list used chat channels.
https://wiki.secondlife.com/wiki/LSL_Protocol

Since chat channel scanners exist, there is not foolproof way of preventing someone from finding the channel number.

The best defense is to channel hop and check the owner of who is talking.

Manufacturers are required by law to comply with certain product safety standards. For many companies, submitting products for testing by an accredited laboratory (such as UL) is an essential step in ensuring compliance. That is, UL testing takes into account the laws of each country where the product will be sold. UL tests products intended for sale in the US differently from products meant for sale in only Canada, Japan or the European Union, for example.

Also, in our increasingly litigious society, often third-party testing is required by insurance companies.

In SL, on the other hand, scripters & builders are not subject to national safety laws, crippling civil liabilities, or insurance company mandates. The incentive of submitting scripts to a third-party for formal testing (and having to pay for such service) is practically nonexistent.

-peekay

Standards often have a bad habit of incorporating cruft into their designs. Take, for example, your "MLL" standard above, which mandates using channel 0 listens. Personally, I don't use channel 0, except very rarely, and only when it makes absolute sense to do so. As such, any standard which would mandate its use for anything and everything, I would avoid like the plague.

Instead, I would form my own set of standards I adhere to. You seem mainly concerned about crosstalk issues on chat channels. Why not adopt a standard mandating a configurable channel for all objects via command, notecard, or other persistent setting? That way, if someone buys an item which has conflicting channel use, they can configure one of the conflicting objects to use a different channel and, thus, resolve the conflict. See? Another good idea which is no less valid of a way of dealing with the issue than yours.

While I agree there may be one or a few "best ways" of doing something specific at any given time, there are no shortage of provably correct ways of doing something. Hence, "standardization" should not necessarily be about specifying "right ways" of implementation, but about pitfalls to avoid, thus not limiting the expression of doing so via implementation. In that way, it becomes more of a "best practices" deal than some kind of unenforceable "standard".

While I do agree that listening on channel zero can be done very wrongly and lag the sim hard, I would presume that most all scripts would filter to their Owner, cutting through most of the junk. But perhaps that was a bad standard to include; the goal of that standard, and the /65522 channel was to avoid an issue I see with your customizable chat channels: What if I forget the custom channel? The object's main documentation will indicate the standard channel, but likely not the custom one I chose. If I gave a wrong setting in a notecard, I now have to re-edit it, which can be a pain for flying pets, or super-small/invisible prims, and if it was set with a chat command, if I have no means to reset the script, I'm SOL. So, the 65522 channel was intended to be used as a sort of ILO access; a back door that's always open (to those with the right permission) in case of things blowing up.

Also, a lot of people have some strong opinions about chat standards, but what about config card standards? Are those less controversial?

1) Take notes, either in a notebook or in a notecard, to help you remember better.
2) Have the item llOwnerSay its current channel every time it is rezzed or worn.
3) Take another copy of the object out of its packaging and rez it, reconfigure it, then follow #1 above.



*shrug* I don't have issues editing notecards in any kind/size of object. Drag-select works great for catching pets, or finding small prims.

I also use another system for notecards. I created a standardized notecard configurator object that people can wear to configure no-mod objects which need it. The main object talks to the configurator via a chat channel, and requests its config, which is read back to it, from a notecard, on that channel. Can do multiple objects that way very easily. If the information is sensitve, or needs to be authenticated, I can do that, too. It is trivial to locate/edit the object the notecards are contained within, too. Just rez it on the ground, and it is right there, ready for some edit love.



I think what people are saying is that they have strong opinions on IMPLEMENTATION standards. It is fine if you are designing something that everyone has to adhere to, like an Internet protocol suite, but for implementing virtual toys in a virtual world at the application layer, where there are many good ways to do it, no one standard is going to be a one-size-fits-all solution.

Basically, make a standard to help you make good products, but don't get bogged down into trying to make standards for other people, unless you get their consensus and participation in the process first. I know I would be unlikely to adopt a standard for something that I already have a personal standard for implementing a particular function or feature set. Best practices documents work good for that, though.