Black Box: Thinking out loud

The "Resizing a matched pair of things" problem.

The HUD is dumb. really dumb. When you press ( + ), it sends the message "hood.z=1" Now that's all well and good, as it tells all objects with prims named "hood.z" to scale by 1x their step factor. (if the step factor is .05, for example, then this command says "scale to (1 x 0.05) + your current scale factor in relation to the default scale.. so if it's at 2x the default scale, now it will resize to 2.05x).

That's cool, except where it involves a pair of shoes, for example. Ideally you want both shoes to scale together as a single item, that is to say, with a single set of buttons telling both shoes to scale together.

The Problem comes in that a pair of shoes is actually two separate attachments. One shoe could get unworn, or lost in inventory.. and it's possible (thanks to COPY permissions) that you might have two pairs of shoes, or let's just say two shoes that you might try to wear together, that were sized to fit differently.

These two shoes of different sizes, would continue to receive resize commands from the HUD, and would scale in relation to those commands, but they would not match. The larger shoe would always stay larger than the small shoe.

Fact: there *IS* a reset button to reset the shoes to the factory '1.0' scale. That's certainly useful in this case.

But Ideally, I'd want a way to command the left shoe to sync up with the right shoe.

Do I need a button for that? or should that action be default behaviour?

Creating a "Master" and "Slave" version of the receiver scripts is an option here. The Master would respond to .z commands, while the slave wouldn't. On receiving a .z command, the Master script could calculate the desired scale factor, and spit out a .y command, that the slave script would react to AS IF IT WAS A .Z COMMAND, searching out .z prims.

This approach would add a minor amount of delay to the process, but not too much, I don't think.

The downside is that now there would be two slightly different versions of the script that would need updating.

Perhaps this could be mitigated, by turning this into a simple integer flag in the script's header. "isSlave". I can then do a simple check on the whole "if message contains ".z"" bit, with a && !isSlave. That would effectively shut this function off in the slave.

This however belies a much more sinister problem intrinsic to the way the script is written thus far. The product script is programmed to ignore all messages that don't have the correct productID as a header. that's great, but what of the Siren av, where 5 objects all would be on the same hud, they'd all need the same product ID.

The problem is that every command meant for the shoes, would have to be checked by the gauntlets... causing a runthrough of the linkset for every command made for the boots, on every part in the set. Is there a practical way to add a 'partID' to targetted controls? So that things that affect all parts get a "part=*&" while targeted controls (like the aforementioned resizers) would get a "part=boots&" appended to each message? Or maybe skip the part=* bit, and if the part header is absent, then proceed with the assumption the message is meant for that object.