The processor determines a syntax of commands the control modules send and it can execute. Understanding of this syntax and how the processor works is essential for building the control device. In this post we handle the processor commands after a brief introducing how to message under MACS in common.
Common messaging with core services
As stated before, message transport service takes MACS messages to be sent and inserts them into the receiver device as if the sender and receiver were linked. Now let's look at this process closelly.
The MACS command is a single string containing the command name and none or multiple command parameters. The command name and parameters are glued together by colon. So, in the command "size:*:1.5" the command name is "size" and the parameters are "*" and "1.5". A control module can't decide who will be the receiving device. All it has to do is wrapping the command into a linked message which would reach at least the controller script.
Now it's turn of MTS (Message and data Transport Service)
As soon the linked message reaches the controller script, the MTS unwraps the caommand and passes the it over to all devices it is connected to. That can be a thousand or just one device. The original control module does not care about that detail.
Inside any device under control runs a connector script which checks if the message is valide and has to be accepted. If so, the connector script inserts the message into the device as a linked message similar to one sent by the control module. This linked message wraps the original command, in this case "size:*:1.5", and tells also what device sent the command and who pushed it's button. The processor scripts in the device under control receive this linked message, unwrap and execute the sent commmand.
Now it's turn of ARS (Auto Response Service)
Each command name can be assigned a status, one of "ok", "ko", "iw", "na" (command accepted, declined, busy waiting, access denied respectivelly). If for example the status "ok" was assigned to the command name "size", and the command, say "size:*:1.5" was received, than the connector script generates a reesponse message, in our case it will be "!resp:size:ok". This response is sent back via MTS to the control unit, i.e. the control modules in that device see the message response.
If no status was assigned to the command, no autoresponse is sent, than the processors have to send it themselves. The goal of ARS is to send the responses in time since the processors could be busy with something else. The right command status for the ARS they can update before they start any long-term operations and after completing them.
Private and public messages
MTS supports also private messages. For the control unit, if a message starts with an exclamation mark, the controller script does not send it, the message remains inside the control unit. Hence, all control messages meant for other control modules must start with the exclamation mark.
Inside the unit under control the picture is differnt: The only message meant to be sent towards the control unit is the response "!resp:..". It starts with the exclamation mark, but as no other message is sent to the control unit, all messages inside the unit under control are private if they do not start with "!resp:".
Now we continue with the special processor, included into the TASC SDK and commands it registers and executes. These are four transformation commands, three processor commands and one control command.
Transformation commands are those that change prim properties. They name a so-called command target. For example in the command "alpha:heel:0.75:-1" the command name is "alpha", the target is "heel" and "0.75", "-1" are parameters.
The four commands are:
- size - Rescaling the prim by providing a factor.
- alpha - Setting prims transparency to given value, and face. Omitted face means all faces.
- color - Colorizing of the prims, one or all faces if the face number is omitted.
- img - Texturing the prim, one or all faces. Takes one, two or five parameters after the target: The texture key (required), the side number to take texture (all sides if omitted), repeats, offset and rotation values.
- "size:*:1.5" - enlarge all prims by 50%, the factor 1.5 means 50%.
- "alpha:straps:0.0" - hide 'straps' by setting their prim's alpha of each side to 0.
- "color:heel:<0.9,0.75,0.1>:2" - render the side 2 of 'heel's prims in golden color.
- "img:base:d43c474c-..." - assign a texture with the (here shortened) key to all sides of 'base's prims. The texture key could folow the face number, than other texture parameters to use, i.e. repeats, offset and rotation.
- !remove - Removes the processor script. Notice the exclamation mark: It prevents the command from being sent to the UUC over the bridge (use the fix command instead).
- fix - The processor script sends the !remove command to all other processors. After the process is done, the object is almost free from MACS scripts (actually just the controller and one processor remain) and not changeable any more.
- unfix - The processor script reinstalls itself in every other prim of the device. After the process is done, the object is ready for being changed. Please note: Due the LSL restriction, installing the processors takes 3 seconds per prim (a 200 prim boot needs at least 10 minutes).
Prims of the unit under control
Ok, as stated, each prim of the UUC runs the same processor script. And all of them receive the command, say "alpha:straps:0.0". How can the processor of the straps prims understand that the command is meant for it's prim and not for some other? The idea is simple. Each prim of the device has a description field where we name the targets for commands meant to the prim. All we need is just edit description of prims that make shoe straps and put 'straps' into the description field of each prim.
Prims that make the shoe base will have 'base' as description and the processors run in them will run the command "img:base:d43c474c-...", but not the command "alpha:straps:0.0", as it is for wrong target. Unless we describe a prim with "base:straps" declaring it as belonging to base and also straps. If a prim must belong to two or more groups, we can glue the group names by colon in the prim description. Than each group name can be target of transformation command, meant for the prim. So, we can have for instance "base:base-front:base-border".
Extended command target
There is even more. Remember the asterisk as the target of the command "size:*:1.5"? The asterisk char is a joker. A command target may have it at least once. This char stands for none, one or as many chars as needed to turn the target string into the group name of the prim.
If a prim is noted by group "base", than commands with targets "base", "base*", "*base", "b*e" or just "*" will work on the prim. To address two prims, one with desription "base-front", another with "base-border", the command can have just the target "base-*"
Ok, as seen, some transformation commands can name the face number to work on. But, if we target multiple prims with same prim group, how we can be sure, theyr faces with same number belong together? We can't, as it is not possible at all.
Instead, the processors support a face replacement technique. It gives the faces new numbers. This way we can give the same number to prim faces belonging together. If we send than a command for this number, processors translate the command into those with right face number for each prim. The face replacement will be introduced more closelly in a later post.
In the next part
Grouping prims by giving them a description needs some planing work but it seems to be the simplest way to differ prims of the unit under control and to address multiple prims at once.
We've seen that the processor scripts need commands to be properly adressed and formated. Generating those commands requires some skripting skills. But a real shoe designer must not learn skripting. All the designer must know is how to make good shoes and how to play with prims. There must be a way to control the processor scripts without needs to write a line of LSL code.
The second part of the SDK provides this way. The SDK offers a number of modules, that one just have to arrange, configure and link together to create a running control unit. The configuration is mostly easy and means just setting the module name and description.
The usage of the modules is described in a very large help note inside the SDK package, and we wil not repeat that all here. We will simply work on our first real project: Equiping shoes with MACS scripts. But before we can start with it, we must take a short stop and look at the security of the MACS system. This will be the topic of the next tutorial post.