openHUD Project

[revochen Mayne]

Hello and greetings!

I would like to share the free and full perms HUD for anyone interested in. It's quite advanced and got delivered about 100 times now through the SL marketplace.
Anyway i would rather want to provide a link to the marketplace item than publishing its script if nobody minds.

https://marketplace.secondlife.com/p/openHUD-Beta-Release/3400001

For anyone interested in the new version there is a short introduction video about on Youtube as usual.
http://www.youtube.com/watch?v=rgs3rpGQimg&feature=youtu.be

For more information feel free to join the developer group in SL called Open HUD LSL or visit the websites at:
http://www.openhud.org and
http://www.wiki.openhud.org

Any help and feedback for is also much appreciated either here, at the SL group or the project websites.

Thank You! =)

[xtc4u]

I have taken a look at your HUD and have a few questions.  I'm not an experienced SL scripter so these may be dumb questions, as I'm still learning the mechanics of the SL remote servers.  I will say I have been coding software for quite some time however, but pretty much exclusivly local Winform style exe's.

Is there an advantage to breaking things up into so many scripts from a performance standpoint, or is there some other reason?  I have build a few HUD's and pretty much jammed all I could into one (or two scripts if memory became an issue), assuming that giving the SL server one or two scripts was better than 7.  I thought I read somewhere that less scripts were "better".

It seems to me that a lot of the scripts that you have in your design are very specific and basically tell the Core script what to do.  What is the advantage of this design?  Is it just to break-out the various functionality and make it modular so you only use what you want?  

I realize that the concept is that this HUD will grow in functionalitly and thus eventually require more than a single monolitic script (do to memory again), so maybe my questions are premature.  

Anyway please enlighten me as to why you have the design the way it is.

Thanks

 

[revochen Mayne]

Hello xtc4u,

The reason for having separate scripts for the HUD and its extensions is mainly the script memory limit and also to have it modular. That way it's easier to maintain its code, remove or add more extension modules to it without messing to much with the HUDs main scripts.

In general i wont say having less scripts as possible nor having them as separate scripts is the best way to do. It just depends on the purposes and processes they have to take care of. Both ways having its advantages and disadvantages for sure. Especially as LSL is a procedural scripting language it's adviced to not overload a single script by having to many simultaneous processes but rather having indivual scripts depending on its purpose and let them communicate via link messages.

The advantage of the HUDs design is to let the core script process common tasks like user input, layout and updates. That way the core is processing a touch input by a user only in the single core script rather than to have multiple module scripts and each having its own touch event. Any further and specific task of a module extension belongs into the module script itself to help keeping script memory usage low and process performance high.

Hope i brought some light into it, if not just ask on. I'll try to answer further questions but might takes a few days, as i'm not checking the forum each day.


Greetings

 

revochen =)

[xtc4u]

Thanks for the giving me the rational for your design.  I can understand the advantage of having all user click events in one script as one of my larger HUD's has two scripts and both have those events.  Sometimes tracking down what is going on can be a challenge.  I thought I read somewhere about how many if else statements can chew up memory and with all the options I have going on the original single script ran out of memory well before I was done.

At this point I don't have anymore questions, thanks again for the explanation.

Cheers