Why can't scripting be done via a "gui"?

Computers as a whole are too far advanced for a lot of people to even be able to turn on.
Yet if you want to use second life, your going to have to figure out how to use a computer.

We could have a big sign that says push here to turn on on the computer. And then have an operating system with only one button, "start second life"....

But, that's not really worth it is it, because the computer is not good for anything else then. You will still have to go learn how to use the real computer.

Some of which are in your library. If dropping the rotate one in a prim is too much like brain surgery I doubt sliders will be much of an improvement.

Thing is, it will only take you maybe two days to learn how to do all these "simple" things in real scripting.

If all you want ui for is the basic things, as many in this thread has stated. Then just take an hour or two to look at how to do it in a script on the wiki.

If what you wanted to make was complicated things, then I would understand why everyone feels it is impossible. That is reasonable. But not being able to find an example of a door script or similar on the wiki is not a good excuse for making the dev team implement UI for scripting.

Most of the AOs I have seen already use zhao, which is free. The real AO work is in creating the animations, not the scripting. Even with built-in ones (like emerald) again you are concerned with the animations.

I think (at least part of) the point is that if these things were natively supported by the sim instead of requiring scripts, they'd probably work at least as well and require less resources.

It's not that the scripts are tough to write, it's that having to have yet another script is overkill for a lot of these sorta things.

edit: see also: floaty text.. How many scripts are there that just set an objects text then sit there forever more, doing nothing but chewing up a bit of sim memory?

please tell me you've since moved on, and built much more efficient works? please?

@Topic:
someone already built a visual script builder, that worked like little puzzle pieces, you added a block for each action you wanted... in the end it spit out the code and you pasted into a script. link:

the higher the language level, the more inefficiently it runs. why? because abstract concepts are hard to optimize into literal code, especially for a computer that really only understands literal instructions. now one day when we have AI compilers, you can just tell it what you want and it'll build it... until then we actually have to learn.

I agree with that. I'm unsure how feasible it actually is though. Or whether switching from one system to yet another would really help out with the sim. It's still a system with information that needs to be stored and processed.

On floaty text, I do know there are some improvements coming to it soon

Yes I'm familiar with Scratch for SL. I've tried that one too. Problem is it generates huge scripts.

As for the linked door script, I've pulled some stuff out of it that I don't use, and they no longer listen to everyone on channel 0. Believe it or not, I'm not stupid.

I've done some time with Ed, Vi, Emacs. . .I've even fat fingered "read from tape" bootloaders onto toggle switches to applications loaded into core memory.

And I'm a pretty good typist. Dvorak layout, if anyone's interested.

But hey--I can drive a stick too. Doesn't mean I don't appreciate automatic.

I wasn't trying to insult anybody, and yes scripting is like repairing cars or carving wood, it's something you have to learn and if you don't want to, find someone that do and make a deal or something.

As someone else said most high level descriptive languages tend to spurt bloated code.

I apologize. I really wasn't trying to be snarky. My point is, people are always finding easier ways to do things. Once upon a time, people reprogrammed computers by unsoldering/resoldering the positions of diodes in the circuitry. For them toggle switches and front panel register display lamps were an advance. Then the teletype terminal, and paper tape came along. The history of computers has been about nothing if not making it easier and faster. I mean, fergodsake folks--you want to compare bloat--in terms of memory required, a simple rotation script wouldn't even fit into the Apples, Commodores, Atari's and PC's many of us started out on.

It's a USER INTERFACE. We all know the code we type into the editor isn't what the simulator actually sees. What's the difference if the microcode gets parsed from a script, or created piece by piece from drop down menus that we get from the edit window of a prim?

Ha!

Well, speaking as a "real" programmer (would my W2 tax forms lie to you?) I would absolutelyfreekingly love to see something like that. But much as with everything else at Linden Labs our scripting language is a totally half-assed thing, created (so goes the story) by Cory Linden over a weekend mostly be writing wrapper functions to programming interfaces which were an integral part to the various parts Second Life was cobbled together from.

Seriously, it would give the average user more control over their SL experience, and I don't really give a flying fig about money in SL because that's what I spend 45 hours a week on and I don't want to work when I'm supposed to be having fun (even if it is scripting, at least its a script I want to work on). I think most scripters with professional software experience are the same way - they're in it for the challenge and the chance to create something really cool - not rip people off by repackaging freebie scripts (which I've contributed to) with a minor tweak or two - but I guess they're only responding to the market.

So look me up in-world and I'll show you a few really cool scripted thingies. Just don't ask me to customize a door script or a rotating texture script. Boring.

The way I see it, Second Life is a lot like the old Ultima Online, which paved the way for games like EverQuest and World of Warcraft by (1) establishing there was a market, and (2) showing that a game could even survive an endless procession of mistakes, bad calls and outright managerial arrogance. Its not time to move on yet, but...

I have seen "GUI programming" starting with Warnier-Orr diagrams and Amigavision, 25 years ago... and while I still devoutly believe that it's possible to create something useful with it, I've yet to see an implementation that wasn't harder to use than a well designed text language.

If you want to make things easy for people to understand, provide a Logo front end to Mono. Logo is an easy to learn, easy to understand, lisp-like language that is much easier to learn (and more efficient than) LSL. Get something like this:

DOOR_IS_OPEN = FALSE.
TO OPEN_DOOR [
ROTATE DOOR 90 DEGREES X.
DOOR_IS_OPEN = TRUE.
]
TO CLOSE_DOOR [
ROTATE DOOR -90 DEGREES X.
DOOR_IS_OPEN = FALSE.
]
WHEN CLICKED [
IF DOOR_IS_OPEN THEN CLOSE_DOOR ELSE OPEN_DOOR.
]

Default all operations to the objects own frame of reference, and you blow away 99% of the quaternion operations people have to deal with.

Doing the same thing with a GUI, you would need at least 8 boxes and they'd all have to have the right things in them.

Easier than has Void Singer, of this parish? /54/a7/220597/1.html#post1742076

I'd be very interested to see your comments on Revolution--which was linked in my original post.

THAT one started a flame war in some programmers journal that scorched my eyes to read it.

It's just another variation of hypercard/applescript/logo/... with a bit of GUI salt to spice it up for sale, and a lot of mechanical magic number manipulation that you shoudln't need to do. It's far from the best such program I've seen, and the GUI is the least important part of it.

See my logo door example a couple of messages up.

Of course it wouldn't work for everything. I said that at the start.

But what if you could click your way to a build window that was something like the "all" panel of the Particle Magic hud? There have been dozens of particle scripting gadgets, and what they really do is create a script that ends up (somewhat permanently) the parameters of a prim.

And I appreciate well presented arguments like this. Frankly, I'm aware than most of you here are an order of magnitude smarter than I am. But I still think that many, if not all, common things we do to prims could be turned into a clickable interface that has nothing to do with scripting as we know it.

Sure it can. You can see that in the "texture" and "features" tab of the edit box. You can change the texture trough a script, or by editing properties of the object. There's no reason you couldn't do the same thing with ANY static property of an object, including particle systems, texture animation, and so on. But to make the objects reactive, like a door that opens when you run into it, you need to actually write some kind of code. That's the border between "what a GUI is appropriate for" and "what a GUI is in the way of". When you start having to define behavior, we still haven't come up with anything better than a command language.

In revolution, for example, as soon as you want a display to do something, you have to start writing code, and THAT code looks a lot more complex than LSL to get right. The example videos show the guy lining things up by using ids instead of names, so where in SL you can use an ID or you can just drag an image to the prim's contents and reference it by name, the ONLY option is to copy the ID into the fields in the button. Instead of having the textures just dragged into the face of a prim, you have to copy absolute coordinates from the workspace into the code. It really looks quite primitive compared to some tools I've used.

that's kinda my point... the simpler the interface, the more complex the code, and the more optimizations are likely to be missed (or the more the compiler needs to do just to keep up)


but we all make mistakes, for instance I wasn't being down on you, I just want to scream every time I see that script in use. it's a good learning tool (I learned from it too) but there are so many easier/better ways to do it.

my whole point is that the best solutions aren't always linear or literal, and that's the best we can get out of the kind of drag and drop gui you're suggesting right now.

I saw your hinge script. I get the point.

the thing about S4SL tho, is that it adds SO much other stuff that just isn't necessary, like it's line drawing functions functions--even if you don't use it. I used it to duplicate the default script that appears every time you start a new script. It was very easy and very straightforward--But the script it created was hundreds of lines long.

I was thinking more along the lines of what you see on the features tab of the build window. Or the "All" menu of the Particle Magic Hud. Or Jopsy's texture animation toy in the basement of the Particle Laboratory.

And it doesn't necessarily have to generate a script. Even setting more static parameters, as Argent pointed out, without the use of a script could be a good start.

Not a good start, a good continuation.

Real programmers dont like it because it makes things too easy for non programmers??? That just nuts. Programming requires knowledge and effort, and people who don't want to put forth the effort hire people regardless of how 'easy' it's made by check boxes. I've been scripting in SL for 3 years now, and I've not found it difficult to code at all. You can't get the level of complexity you get with a full blown scripting language like LSL with check boxes and tick boxes, and connecting crap together with lines and stuff like that. If typing is such an issue, I suggest perhaps you visit this site:

http://www.powertyping.com/

very similar to my complaint on prim properties... if it can be set and/or read, it should be available by both edit window, and script with only one shing exception I can think of: script pin. scripted behaviors, I'm a little more iffy on, because I don't trust LL to make anything resembling an efficient action compiler for even the simplest of scripted behaviors.

Another grid (starts with Open ends with Life) was going to implement a thing called SSO's - Server Side Objects. There are a couple that are inworld atm. Region renewal and a PotOfGold game is all I know of but never used. You name the prim SSO.Region.Renewal, then click it and pay the amount. The renewal is then done. Delete prim.
More of these SSO's were supposed to be implemented but not much has happened in the year or so since they were announced.

The idea is: You simply rez a prim and name it SSO: Door.slide and it becomes a sliding door. The prim has no script and is run by/from the server as a SSO.

As for the GUI aspect... Once in edit mode, options would then become available such as speed, slide length etc. You would size and texture any way you wish which would not effect the SSO state.

Other SSO ideas that were 'on the drawing board' were SSOlant.Tree, SSO:Vehicle.Boat etc and many more.

ETA: I don't like OL or go there because nothing works.

Server Side Objects?

1. Stupid name, all objects are server-side.
2. It's so obviously a hack around the UI issue, it's not funny. It's like their workaround for the lack of Mono support in the client when they started... you compiled a script by putting it in a prim.

The right way to do this kind of thing is to add user interface objects, Javascript or Lua editor plugins you could download from the server to add new kinds of editing panes for prims. Like a particle pane, or an animated texture pane. Or a custom plant pane, that you'd use to add Linden plant system parameters to a prim so it'd render as a plant.

This isn't replacing scripting, this is filling in user interface gaps that are currently papered over by letting people use scripts to set parameters. It's a good thing, but you'll still need scripts to control your door, helicopter, or any other reactive object.

Being someone who has taken 3 years worth of LabView http://www.ni.com/labview/ courses in order to socially qualify as a Test Engineer for my company... All I can say is "Ick". (>_<

Graphically representing code not only adds a degree of separation from the function you're actually manipulating, it also openly invites inefficiency because each graphical "code" item typically has to carry more bulk so that it can match all the typical varieties that the text code item would already be capable of. (>_<

And... Graphical method development is NOT easier than text coding for a number of reasons, including ergonomic ones:

1) Drag and drop creation - Seems easy, but far from it. Yes, all of what you want is visible in a tools library so you know what you're getting into... If you have a big enough screen... And if each item has some sort of tooltip associated with it. Ergonomically, you're now stuck to using one hand on the mouse while the other is idle... Or holding down Shift or Control keys. In either case; you're straining, constantly hunting for the function you want, and possibly settling for whatever is on the screen at the moment only to correct yourself later... Wasting time. (>_<

2) Icon size - Graphical function items need to have pictures to describe themselves. Will a 32x32 icon suffice? 64x64? At what point will you have enough information in the graphic to genuinely have a mental image of what the function does? To be effective in programming in this method, you'd need to memorize paragraphs of descriptive elements for each item. In text code, you'd be doing this anyway and the name can quite telling. (^_^)

3) Sequence - In LabView they use a "thread". Threads go in the right side and come out the left. They indicate the data being transferred to and from each function and are color coded accordingly. The problem is, they can go in ANY BLOODY DIRECTION! DX ... So, unless you are going to follow a very rigid schema along the path of your coding, coming back the next day to read what you've created may lead to utter confusion to the point of frustration and giving up on the project. (>_<

4) Inserting - Referencing LabView again... To insert something new into a sequence usually means cutting a thread, grabbing a pile of objects, dragging them over, and re-threading the new item in the sequence... Or placing the new item in some remote location of the design page and drawing a long thread to reach it. Either way, this gets big and messy fast.

So... After spending 3 years in LabView courses and writing a dozen test applications for devices ranging from GPS equipment to embedded solenoid valve controllers... I now create all my new projects in C#. (=_=)

Graphical programming looks easy and nice on the surface. But, to me, the "easy" way to do anything often winds up simply being the way you prefer. There is no intelligence gap between graphical and textual programming. The benefits and pitfalls of each both need to be addressed with the same level of education, and in the end, the benefits in textual programming far outweigh what can be done graphically. (^_^)y