MACS, Part 5.3 - Extended control HUD

Last time we build a simple hud for our shoes. This time we will extend it by some more usefull features. The extension will take again several steps.

Step 1: Planing the hud extensions

• We add a collapsing feature by using another hud base. It has also an advantage to remember it's position for every onscreen attachment point
• By now we have three color libraries of 5 colors each, each changes color of just one element, the diamond, upper and lower base sides. Instead, we will use a color library of 20 colors, a HLS and a gray scale color pikers
• We will use a command module to decide if the color libraries and pikers change the colors of diamonds or base sides, so we do not need that color modules three time
• We add two buttons that remove or reinstall the processor scripts. The shoes have not many prims, but even removing of 30 scripts saves sim resources and we also will learn on this example how to do in other, more prim-intensive projects

We reuse prims and modules of our hud and rezz new modules:

 Picture1: Modules for the new HUD

• The "HUDB 4P" base module
• One more "SCIB 5F 1P" color selector module, additional to used three
• The "HLS B 1P" and "HLS C 1P" color pikers
• And three the "CMD 1F 1P" command modules. We could use a single module with three active faces, but the highlighting of selected options loks nicer if we use three single-face modules.

Step 2: Configuring and reconfiguring modules

The resize buttons stay as they are, also the texture selector. What we could better do is, we unlink and move away the hud base, we unlink and link together prims of the size button row (so we can move them all more easy), and the prim of the texture selector, making them temporary another object.

The color library

We unlink the three color selectors and use an additional color selector to build a 20 colors library, the prims get same dimensions and we arrange them in two rows á two selector. Each active face gets the texture "bw field sq" from the resources package, and we set each face another useful color. For example like this:

Picture2: Color library

The color selectors will run in selectional mode, i.e. they need a command module to say what part of the shoe will receive the color. To do so, the selectors need just a short name. We set each color selector the name "xclr". We can link them together temporary.

Color pikers

Now the HLS and grayscale color pikers (modules "HLS B 1P" and "HLS C 1P". The color and grayscale modules get same hight, so we can arange them side by side. Both will run in selectional mode, and because we want reconfigure them synchronously to the color library, they both get the same name, "xclr". We can arrange them over the color library, making it look like in a commonly seen color dialog.

Command modules

This modules will reconfigure our color modules to change right part of the shoes. Last time we uploaded an image of shoe parts for icons. We reuse it turning the command modules to icons showing which of them how reconfigures the color modules.

To improve the view, we even highlight the icons by yellow border around it. To do so we change the tapper and turn the leant faces yellow. We arrange further the modules right to the HLS modules above the color library. By now it looks as if all icons are highlighted but it will change later if they read the configuration.

To group the color modules and command modules visually, we can also use a black background prim behind them. Linking all together and we are ready by now:

 Picture3: The complete color block

Configuring command modules

The configuration is a bit trikky. First we must know which face is the icon face and what are numbers of faces around it. We can look in the LSL wiki or use a script, we used by configuring shoes. We find out: The icon face has the number 0, the border faces are 1, 2, 3, 4. Since we do not see the back face of the module, we could even use the keyword 'all' for the border faces. Now we must tell the module how to change the faces in highlightet and not highlighted states.

To highlight the icon we use blank texture and yellow color for the border faces, and we set them invisible othrwise. The best way is to set it yellow permanently and use just blank and invisible textures. We use those from ressources package, we need just the asset uuid:

• Texture "invisible", "f54a0c32-3cd1-d49a-5b4f-7b792bebc204".
• Texture "blank", "72a7b646-2c43-2a6a-46c3-6250a8b30312"

Now we are ready for the configuration. It is done by editing a notecard inside the module content. A notecard is already there, called "macs.mod.cmd.config". We edit for instance the module with the diamond icon, and the notecard inside and replace its content by this one:

face  0:active
sel   xclr:color:diamond

face  all
img   72a7b646-2c43-2a6a-46c3-6250a8b30312 : »
        f54a0c32-3cd1-d49a-5b4f-7b792bebc204

The char "»" means line forward, used for this post and is not the part of notecard text: The 'img' line has two UUID entries. What do our settings say?

The face 0 (the icon) is active (we can click on it) and change neither the color nor texture at all. If we click the icon, an action "sel xclr:color:diamond" is triggered telling each module with name "xclr" (each color module in our case) to start changing diamond color on the shoes.

Each other face is passive. We can't click it, but it becomes blank (and stil yellow) if the icon face was clicked, and invisible if the icon face of other two modules was clicked.

In the other command modules we have also to edit the notecard inside. We can use almost the same settings, the difference is just the action: Each module reconfigures color modules for other target and face. The difference is thus the second line of the notecard:

• Upper base icon: sel xclr:color:*base:100
• Lower base icon: sel xclr:color:*base:102

Remember the names of color selectors we used in hud last time?

Script removal buttons

Processor scripts support a removal and reinstallation feature. The feature uses two commands, which the HUD can send: The command "fix" removes all processor scripts except one, and the comand "unfix" forces this remaining script to reinstall itself in each other shoe prim.

So what we do now. We take two old hud's prims we do not use, set their shape to cylinder, change dimensions, slice, set all faces invisible, except the front one. For this face we use the texture "(un)fix" from the ressources package. The texture has two icons inside, so we have to change the texture repeats and offset to show right icon.

Now we rename the prims: One for deleting scripts (red arrow) will get the name "fix", one for reinstalling scripts (green arow) gets the name "unfix". The prims should not have any scripts inside.

Status module

We need two. We have one already, so we could rez another one or unlink and copy the module we have. The copy we reshape to a cylinder and change the tapper and slice. We set all sides of the module invisible, but the front face gets the texture "bw field rnd" from the resources package. There are four borders inside wo we need to change repeats and offsets of the texture too.

New hud base

The new base cann collaps or uncollaps the hud by rotating it and showing a large side in uncollapsed state and a small side if collapsed. Because most modules will be visible from the side, the base has a thin plane hiding them.

Now we arrange all elements in front of the hud base. It's size must be changed of course. The upper horizontal bar we turn in a cylinder with proper tapper and slice values and the "lower 64" texture on the front face. It wil become the background for the OFF button.

In front of the small face (for collapsed state) we place the ON button, both fix and unfix buttons and the copy of the status module. They all are thin and invisible rom the side, so we do not need any plane to hide them if looking from the front. To improve the look, we use remaining prims as button backgrounds. They get the same "lower64" texture on the front face.

Also we change the hud background. Now we link every thing together and remove assorted prims:

Picture4: Ready control HUD from the side and front.

Step 3: Instaling MACS

This step is thesame as for the last time: Edit the notecard, than add the controller script. Wait for completing the configuration. Ready.

Step 4: Positioning the hud

The hud remembers it's alignment for every attachment point on screen. So this is the best idea to configure them all. How to do. First we attach the hud. Somewhere, say on center. The hud does not know what position it is actually, so we just touch the OFF button.

Now the hud knows, if we touch the ON button next time, the actual alignment will be the OFF alignment. Thus we rotate and move the hud into the collapsed state and touch the ON button. The hud saves the actual alignment as off alignment and is ready to save the ON alignment.

We rotate and move the HUD into the uncollapsed state and touch the OFF button again. The HUD saves the actual alignment as ON and switches to the OFF alignment.

Everytime later we touch the ON or OFF button, the HUD will change into collapsed or uncollapsed state after saving the alignment corrections. This is our result on screen:

Picture 5: HUD on screen in collapsed and uncollapsed states

Repeat thesame steps for each other attachment point on screen.

Step 5: System test

The resize buttons stil work: The shoes change the size. The texture selector was also not changed in any means, so it does work too. What we have to test are the command and color modules.

First time the color modules do not know what to do and nothing hapens if we click them. But as soon we click, say the diamond icon, it is framed and now, any clicked color in the library will go over to the diamonds on the shoe, same if we touch the HLS or grayscale color pikers.

If we click now another icon, the frame switch to this icon and from now on the associated shoe part will change colors if the library or color piker is clicked. While the diamond will keep its color. Exactly as intended.

In the next part

Well this was the last part where we used the MACS and the SDK to control atachments, especially shoes. This was the origin goal to develop the system at all. This three posts were thus interesting for designer who do not want to use any skripting skills.

Next posts will become interesting for scripters again: The pover of MACS is an ability to remote control devices in common, without of any concrete application in mind. A concrete application is the job of a SDK. The supplied TASC SDK is made primary for attachment transformation but it is not the only possible SDK. MACS actually gives a simple API for writing own SDKs and does not restrict much their behaviour.

The topics of next tutorial posts is the developing of own SDKs. As an example we take a task that is far away of resizing attachments. We will build a control system for street lamps and lighted fountains, by using familar buttons to click and also by a day light timer.

This tasks require real development of processor scripts and control modules.