1.7 Preview - Lagginess of HUD

Having enthusiastically explored the 1.7 Preview (congratulations on the amazing work done with it, even despite the lack of the promised features...), I have now a question on the "new feature" that we have to experiment with: HUD attachments.

While the obvious use of this feature will sadly be not used - a replacement for voice interfaces/dialogue boxes to card/board games, weapons, and other remotely controlled devices, which would only make sense using the promised inter-object communication - there are still plenty of devices that will benefit from the HUD attachment by getting rid of at least one open llListen() channel (ie. using touch buttons on the HUD attachment to give commands to your device).

However, the question remains: how laggy is the HUD device? This is mostly an implementation issue. Let's assume the worst-case scenario: 40 avatars using a 40-prim HUD attachment replacing, say, a Tringo board. Will that be more laggy or less laggy than having the very same 40-prim boards on display, one per person, visible by everybody?

If we disregard the obvious advantage - textures and prims for the HUD display will not be shown to other people, so there is a slight economy there (on the above Tringo example, textures would only be loaded once anyway) - the question is, how do the sim servers track the prims on the HUD attachment? (1) If the answer is: "it's just like any other attachment", it means that HUD attachments will create server lag. (2) If the answer is: "HUD attachments are pre-loaded prims on the client computer which are able to run scripts, so any eventual lag is not on the HUD itself, just on the scripts running inside it" then we can expect a big increase in performance as attached objects slowly migrate towards HUDs.

Just by mere chance I found out that I actually have half a dozen objects that could benefit of the HUD attachment, if it works as described under (2). Most of these objects are one-prim attachments with open voice channels; replacing it by a HUD attachment with, say, some 20 buttons or so, is something I would gladly consider to do just to get rid of open voice channels, but I would very much like to understand how HUDs are really implemented, sim-wise, to make sure I'm not aggravating a problem (doing a voice command parser is much more compact, in terms of code, than a complex system dealing with multiply linked buttons; but linked messages are so much less laggy that it's worth rewriting all the code).

Thanks for time and patience for replying, Kelly Yes, I think that I'm always enthusiastic about any "new features" and willing to tinker with them a bit, until someone finds out The Ultimate Use for it and sells a billion items In the mean time I'll rewrite one of the objects I've got (a dance bracelet) to use the HUD interface instead. It has a rather long-winded parser for multiple-word commands (yes, although 99.999% of the people just use 3 of those - myself included!) so it'll be a challenge to turn it into a 40- or 50-prim HUD just to make a few tests, and as an exercise

I like the idea of only a single avatar receiving the updates. So, I guess I'll be able to do nifty cool tricks like changing the buttons to use the new "bright prims" parameter (doing a two-in-one test, hehe ) to show which feature is "active". Or even do a slider to adjust one timer - I always wanted to do one of those, but prim limitations/fear of causing too much lag prevented to experiment much with those

And then I guess it's time to see what happens.

In the mean time, I'm still very impressed with the new script scheduler. So, in a sense, "script lag" is something of the past. Hmm. And now that I was half-way replacing all the freebie scripts for less laggy ones Anyway, my original question was also related to understanding how we could test both approaches (HUD without open listens vs. listen channels on "normal" attached devices)

I'm still interested to understand your approach of having HUDs communicating with remote devices with shout/listens in a low-lag way, and I hope to get in touch with you soon about that. Should I assume that your approach to inter-object communication was to make sure that chat in private channels would work as efficiently and as fast as linked messages? If your answer is "yes", I'm amazed and impressed again, and I'll certainly be using that a lot more myself... and hopefully report on any results!

Thanks once more!

I tried to use the preview last night but it locked up a lot and was unuseable for me. I possibly just need to do some computer cleanup/tweaking...

Anyway, what I'm really interested in is the HUD feature. I always thought there should be some form of client-side scripting to allow us to create full feature dialogs for large scale applications. I'm talking about dialogs that could snap-in to the SL client (and look like the current built in dialogs for preferences etc..) but interact with the server object/prims/scripts... much like javascript dialogs can make instant changes to a web page (and can still interact with the server via XMLHTTP callbacks). So... does the HUD thing give us something like that? Gwyneth you mentioned sliders... can we now create autonymous dialogs and controls more easily because of the HUD feature? Can I grab a prim attached this way and glide it from left to right (smoothly) and get it to report a value to some other (non-attached) system?

Sorry... I'd like to try all this on my own, but 1.7 currently doesn't like my comp...

No no, sadly, the HUD attachment is "just that" - a normal object that gets attached to your viewscreen and that nobody else sees.

We had promises on having something similar to what you're describing - a floating window, similar to the Find or Inventory dialogue boxes, but which you could freely send HTML to it from an object. With the proper CSS, you could integrate it fully and seamlessly into SL's environment, and this would be a drastic change in the way we interact with all scripted objects in SL. Actually, this was my hope for 1.7 - but alas, sadly, that's not what we got. More months of patience in waiting.

When I meant "sliders" I meant "primmed sliders". Philip Linden himself has built a very peculiar "sound machine" (I think it was 2 years ago!) that had several sliders for emitting different sounds, according to the setting. The way you do these things is track the movement of the slider inside LSL. It's a bit complex, but very seldom used, because it really needs a few extra prims and so much extra code that it's hardly worth the effort of that "nicety" (so, you just give a voice command to enable a setting - much easier to do!).

And unless I'm very mistaken, the only way to pass the values of those sliders to other objects (or other attachments) is either by llShout() or sending emails

Ahh. Ok, well it's still something. Games like Primmies can benefit from it at least. And in fact it will take a lot of work from me on something I'm working on where I was worried about how to make the "control panel" always follow the AV and face the right way so people could get to the controls at all times.

Well, I'll try to get in again tonight...

I read your article... very insightful. I agree it's all possible. If we were to assume it's headed that way though, I'd say we are currently in the very early "text-based" stages of the analogy. Pretty interesting to think about though.

Aaah well - what saddens me is just that I was not writing about "future speculation". At the time I wrote that article (as well as several others did, like Hiro Pendragon at his own blog), we were just freshly digesting the latest technical Town Hall meeting where we got the information that 1.7 would be out by the end of July with many bug fixes and the four major changes:

- HTML on floating windows (eventually on prims as well, but later, not necessarily for 1.7.0)
- Havok 2
- Inter-object communication
- Linux client

We speculated about how drastic all this would change our interaction with Second Life. The truth is, 1.7 would probably be -- we speculated -- the biggest change in SL since the meshed avatar (even 2.0, with its new renderer, would pale in comparison - 2.0 would be mostly a "technology update", while 1.7 would be a paradigm change). 1.8 would add things like the new Mono engine, which would allow scripts to run much faster and use, in the future, other languages besides LSL (thus, it would be also more a "technology update" than a drastic paradigm change).

HTML on floating windows would address several issues:
- a way to seamless communicate with off-world servers, thus allowing things that have ever been demanded (like persistent in-world database storage!) to be done on external servers. Also, it would enable XML-RPC to work much better, despite the current crippled implementation
- the above would allow SL to become a front-end for zillions of applications - just like the WWW became a "standard interface" for what really are just "online applications", using a common browser interface to access them
- a completely different way to interact with scripted objects
- a way to redesign your user interface, without needing a major rewrite on that (you would just add floating windows and display HTML on them)
- revolutionize the way information is presented in SL (no more notecard-based systems!)

Havok 2 would remove so many limitations that they're too much to list here. Let's just say that things like real-time games (including or not vehicles) would get a boost up. Instead, we're still limited to "cute" things instead (e.g. Portal Wars).

Inter-object communication would simply cut down lag and allow incredibly more complex objects. Right now, all sorts of communications between objects are too slow (and often too laggy) to be good for anything that is real-time. Contrast that to the blindingly fast linked messages inside the same object. If this were extended to inter-object communications - even if only inside the same sim - this would revolutionize the way objects are manipulated.

Instead, this is what we got:

- HUD attachments. Ok, this was a thingy a few people asked, mostly to be able to control vehicles or weapons, or for things that have "hidden" knowledge, like card games or similar games. Of course, I assume people thought you would be able to communicate better between HUD attachments and other objects Still, with HTML on prims on HUD attachments, while cumbersome, I guess it would work, although I'm not surprised if HTML-in-world will work just like video in-world - one URL per parcel. That means that HUD attachments will hardly be good to display complex, structured information, but only interesting to activate objects without voice commands. Ah well. I expect dozens of items to start getting "HUD enabled" soon

- A new way to handle shining objects. Ah well, I'm not much impressed visually, but I guess that better lighting options are part of the roadmap of SL (since the "competition" is much more advanced on those areas - they're lucky, they work with static content). For SL overall as a dynamic platform for communication and edutainment, I don't think shininess is that important. As a platform that should compete with other entertainment-focused 3D virtual worlds, these changes may be crucial to LL, to be able to show that SL, despite having streamed, dynamic content, is able to cope with the latest tricks in terms of graphical rendering. As said, I fully understand how important that is.

- The most important technical breakthrough: no more script lag (new scheduler). This is something totally and completely unexpected, and I fully agree with Kelly Linden: this is the technical breakthrough that 1.7 will bring to us! Just imagine: now you can have dozens of thousands of incredibly lagging scripts in the most densely packed malls - but you won't notice a difference! The mind boggles In a way, this will also mean that people will write more complex LSL scripts and do more creative things instead of focusing on good, lagfree programming, just because that concept won't exist any more. Yes, I truly expect dramatic changes. Although I wonder if all this work will be reproducible on the Mono engine, or if the idea to port to Mono was already dropped by Linden Lab, or if they will simply replicate all the work they've done.

- A slightly important social change: no more negative ratings. This will mean a considerable drop in Abuse Reports due to "injustly received" negative ratings. I wonder what will happen in the long run - will people AR others instead of negrating them? Will people misbehave just because they know they're "safe" from negrates? In my case, as a Mentor, working very often in "dangerous environments", where a "wrong" comment (like: "sorry to inform you, but you can't run naked in the WA..." attracts dozens of coordinated negrating attacks, this will be a thing of the past. The very same comments can safely go to Abuse Reports - people will just look silly. So, I'm eager to see what comes out of it!

So, as you see, none of the "new features" have anything to do with Cory Linden's roadmap for SL in April. Although, to be honest, nobody did expect the breakthrough on the new "no script lag" functionality, which far surpasses anything promised so far.

All in all, we got some tradeoffs. No dramatic paradigm changes with 1.7, but a significant technological one. And we can't forget that "literally hundreds of bugs" were corrected (quoting Pathfinder). That, also, is very very important, since LL's policy has been stamping out bugs and just slowly introduce a few features here and there.

The main problem with the new shiny is--it makes your current objects look bad. Sure, it's more accurate with the definition of "shiny", but I hate it when LL goes around breaking current functionality.

Personally i like the new shiny compared to the old, which seemed to turn anything you made black, often people didnt realise they had it on and for people with shiny on it made builds looks really ugly.

I wasnt really able to use the old, but have already manage to make objects look chrome shiny and yes black shiny, they are still doing some tweaking but if you set the prim color to what the color you want the shiny to be, or just add a texture and also fiddle with the color, i really like how we now have a configurable shiny that takes into account of the setting of the object and reflects the sky too.

Good news on the HUD attachment communicating through either voice channels or linked messages After completing my first 20-button HUD attachment, I couldn't found a statistical difference between both approaches. Actually, I have added a button to open a listen channel and close it, so that I can watch the new statistics for the running scripts to change.

So, I really don't know what kind of magic LL has done with the scheduling of voice commands on the new "script scheduler", but it looks like it works wonderfully now.

Question for Kelly: does this mean you actually recommend us to use llSay/llShout more, since this seems not to affect script lag at all any more? (of course, it's far slower than linked messages, but still fast enough for most purposes, when considering the alternatives)

If the answer is "yes", I may very well believe that HUD attachments will be a much greater success than I first thought!

Also, I found out the neat trick of zooming in/out of the viewport for positioning the HUD attachment (I only found that out by mistake!). It surely allows for a lot of flexibility when overestimating the size/position a simple object will have when attached to the screen. Yay!

Of course, the "real test" would be having 40 people with HUD attachments on as opposed to normal attachments, doing the same thing, and compare both approaches. Theoretically, I would expect that the HUD attachments would be much lighter on the sim server (less updates, I guess). I can only hope that's true

Now I wonder how long it will take until all my screen gets cluttered with HUD attachments until I can't see anything - hehehe.

And I can't forget to make a backup of the scripts before the preview grid is closed... oops

Good question, im not too clear if the whole script is one giant pool or if each script has its own set amount of resources, whatever the case its away from the sims resources i think, my interpretation on the info is that say anything that is laggy now, will be laggy in the future but it will only lag down the script pool, and slow down the execution of scripts, ie scripts will run slower, so i would guess in a crowded or laggy sim using a linked message would be better, simply to speed up the speed that scripts are run at?

Of course i could be totally wrong lolol

Raise your hand if you think the new sim scheduler will give everyone an excuse to indulge in wildy inefficient scripting

Awesome, I have a number of scripts that will benefit from this better scheduling

Can we hope to see the script built-in delays reduced some time in the future ?

I agree eggy, it really depends if they are all in the same queue or are each assigned time per person (which would be much better and fair)

the Ctrl-shift-1 menu does have some new displays for script perfomance on the sim like script ips which i presume is instructions per second?

Yes, that's what I fear also.

Well i think its sim wide for the script scheduler, im sitting in ahern trying to play mahjong, and its laggy as well slingo at an 30 sim full even, but, i can walk round totally normally, the sim is reporting 820 active scripts but thats on an old machine so not too bad, script time is 4.4ms with total frame time 5.2ms

So i think the conclusion is you still gotta write good scripts but at least you wont walk around them as crazy if you dont

Heh. I intend to push the gospel of "THOU SHALT NOT USE OPEN LISTENS!" even after 1.7.

I've heard this sentiment expressed in other threads too, and I'm not so sure. OK, so the new scheduler will ensure that the whole sim doesn't run slow because of bad scripts. But each script is still running its own timeslice(s), right, so a poorly written script will still run slower than a more efficient script. So maybe the others around you won't notice lag, but if you're wearing/using something that's badly written, your script(s) will still run slow, so *you* will experience lag when it comes to the scripts' functionality.

So I think inefficient scripting will still come back to bite the person running the script. It'll save everyone else from having to feel the effects, which is good, but I don't see it removing the need for efficient scripting, or even letting poorly written scripts get away with it completely.

Of coure, I could be wrong in my understanding of how the new scheduler works, so please correct me if that's the case

I'll probably still be a perfectionist. Just because you have near-infinite resources doesn't mean that you should use them. Besides, you can laugh at other people's horribly inefficient scripts if yours are very clean.

But do you really have near-infinite resources? That's my question. Having large resources that are handed to you one small piece at a time isn't much better than having limited resources. The difference is that you'll only lag yourself down, and not everyone around you. Right?

AGREE! That's so on the mark. Reminds me of those peeps who decided to cram CD-ROMs full of bloated, and still-ugly FullMotionVideo instead of researching efficient codecs that would look almost as good as a 10th the size. I'm a believer in limiting myself with resources sometimes, just to see what I can do, and then that makes me so much mightier when working with a larger tool palette. I did this lots with synthesizers, coming up with many parts on one machine and really tweaking and refining them. It always is a horror to me how some lazy people will be incredibly sloppy if you hand them the whole room of goodies.

If it can't be done any tighter, then up the ante, but otherwise, I say scroo it!

Heh, you should see this older game that I have. SimAnt. 7MB, on a CD. It's a great game though, you should try it some time.

The SimAnt game can be found on this page: http://www.geocities.com/markjenkins666/abware.html
707kb

There are a few other Sim games, too. I loved those things.

By near-infinite resources, I mean that you can't see the horizon, really. It's like running on a salt flat in the fog, you don't know where it ends.

I played many sim games, including SimAnt. Liked them all, with the exception of latter-day, bloated SimCities.

Of note, Robin Linden (Harper) used to work at Maxis!