Clothing four-way interaction

[KT Kingsley]

So, I have four towels I use with my beachwear.

I have a wrap towel, fitted and worn. I have a modesty towel, clutched against my chest, attached. I have a towel, held in my hand, attached, and I have a sunbathing towel, rezzed on the ground.

When I detach either the wrap towel or the modesty towel they attach the towel held in my hand. When I attach either of those the towel held in my hand is detached. When I detach the towel held in my hand, that's it.

When I rez the sunbathing towel, at my feet and ready to be sat upon, all three other variations are detached.

When I stand up from the sunbathing towel it kills itself, but not before attaching the towel held in my hand.

But what I don't want is for the modesty or wrap towels to attach the hand-held towel when they're detached because of the rezzing of the sunbathing towel. Also, I don't want to have either the wrap towel or the modesty towel to attach the hand held towel when either replaces the other. And I don't want the wrap and modesty towels to attach the hand-held towel when they're detached because I'm changing to a completely different outfit.

I'm currently using a manually triggered gesture to detach the spurious hand-held towel.

If that makes any sense to you, can you suggest a strategy that handles all my requirements? It's the "don't wants" I'm trying to figure out.

Yes, I'm using RLV for most of this. And there is a HUD with the capacity for scripts (or for additional code to be incorporated into existing scripts) available.

[Wulfie Reanimator]

You've laid out the functionality in a pretty straight-forward manner, and you're already using RLV which is almost required for this functionality (unless you were to toggle the animations/visibility of each attached towel instead of actually detaching them). What exactly is the issue?

[KT Kingsley]

I guess, more specifically, I want to be able to distinguish between a clothing item being detached because it's being replaced by another specific individual clothing item that told RLV to detach it, because it's being detached because an in-world object told RLV to detach it, and because it's being detached because it's now redundant because a completely different outfit is being applied.

What I've done so far is to put single RLV llOwnerSay commands in the (de-)attach event (I don't think I should be risking more than a single simple command when it's a detach rather than an attach situation) that attach the replacement object.

Though now that you've put it the way you have, maybe I should be thinking in terms of the various items sending messages to a HUD script, which then decides what to detach or attach in consequence. And maybe the relevant outfit should include an object that gets detached only as part of that entire outfit and sends its own message when that happens, telling the HUD not to attach the replacement.

Actually, I suspect I'm thinking myself into knots over this. As in there's no simple one-liners that'll do the job: it'll take a proper messaging and logic system, including a race umpire, to do the job. Also as in I probably need a good night's sleep before I come back to this.

[Wulfie Reanimator]

10 hours ago, KT Kingsley said:

I guess, more specifically, I want to be able to distinguish between a clothing item being detached because it's being replaced by another specific individual clothing item that told RLV to detach it, because it's being detached because an in-world object told RLV to detach it, and because it's being detached because it's now redundant because a completely different outfit is being applied.

To what end? Why is this distinction important? The best implementation depends entirely on what root problem you're trying to solve.

Edited October 31, 2019 by Wulfie Reanimator

[Nova Convair]

Maybe make a state driven machine for that.
Usually you draw a diagram - bubbles for the states and arrows for the state changes
Can be made infinite complicated. You define states and the conditions that make you change to another state.

 

State 1 : wrap towel on / others off
Entering : send off commands for the other towels
Change : modesty towel on -> State 2
Change : hand towel on -> State 3
Change : beach towel on -> State 4
Change : wrap towel off -> State 5

....

State 4 : beach towel on / others off
Entering : send off commands for the other towels
Change : wrap towel on -> State 1
Change : modesty towel on -> State 2
Change : hand towel on -> State 3
Change : beach towel off -> State 5

In code:

integer state;

enter_state (integer st) {
    state = st;
    if (st==1) {
        detach commands
        attach commands
    }
    else if (st==2) {
        detach commands
        attach commands
    }
    ...
}

llListen( ....
    // receive messages from towels

    if (state==1) {
        if (msg=="modestyon") enter_state(2);
        else if (msg=="handon") enter_state(3);
        else if (msg=="beachon") enter_state(4);
        else if (msg=="wrapoff") enter_state(5);
    }
    else if (state==2) {
    ...
    }
    else if (state==3) {
    ...
    }
    ...
}

You probably need a function to find out in what state you are.
Then you need to send a ping to the towels and evaluate the answers

get_state() {
    if (modesty) enter_state(2);
    else if (wrap) enter_state(1);
    ....
    else enter_state(5);
}

[Rolig Loon]

The other standard alternative is to set a flag like your state variable and then use it to route logic within the touch_start, attached, or other events within a script that has a single state.  Either approach works, and I'm not sure that you can make an argument that either is always "better."  Personally, I tend to avoid creating new states but only because I have a deathly fear of getting my script trapped in one of them and unable to get back.  That says more about my own confidence level than about the approach.  

[Mollymews]

this is a pretty interesting project

some thoughts on how this might be done

a engine for attaching/detaching items, with a rez and sit capability, and with appropriate animations. A engine that interprets/plays a sequence of commands. Human readable typed sequences that could be stored in a notecard

engine would consist of a console HUD script. And a script in each attachment/rezzed object, at minimum signalling to the console that the attachment/object is successfully attached/detached

example sequence format:

sequence Hand
{
   attach "Hand towel"
   detach ALL_OTHERS
   animate "handtowel"
}

sequence Sunbathe
{
   rez "Sunbathing towel"
   sit avatar_uuid
   detach ALL
   attach "cigarette"
   animate "smoking"
   on_stand
     stop "smoking"
     detach "cigarette"
     de_rez "Sunbathing towel"
     play Hand
   end_stand
}

sequence Modesty
{
   attach "Modesty towel"
   detach ALL_OTHERS
   animate "modesty"
   on_detach
      stop "modesty"
      play Hand
   end_detach
}

sequence Wrap
{
   attach "Wrap towel"
   detach ALL_OTHERS
   animate "wrap"
   on_detach
      play Hand
   end_detach
}

a sequence could be read into a list, interpreted and processed. example

list sequence = [SEQUENCE, "Hand", ATTACH, "Hand towel", DETACH, ALL_OTHERS, ANIMATE, "handtowel"];

list sequence = [SEQUENCE, "Sunbathe", REZ, "Sunbathing towel", SIT, llGetOwner(), 
  DETACH, ALL, ATTACH, "cigarette", ANIMATE, "smoking",
  ON_STAND, STOP, "smoking", DETACH, "cigarette", DE_REZ, "Sunbathing towel", PLAY, "Hand", END_STAND];

list sequence = [SEQUENCE, "Modesty", ATTACH, "Modesty towel", DETACH, ALL_OTHERS, ANIMATE_MODESTY, 
  ON_DETACH, STOP, "modesty", PLAY, "hand", END_DETACH];

a time pause could also be included, a hud show/hide menu command as well. Example: Coffee then a cigarette

sequence Coffee
{
   attach "Coffeemug"
   detach ALL_OTHERS
   animate "drinking"
   pause 300  // 5 minutes
   detach "Coffemug"
   on_detach
      stop "drinking"
      play Smoking
   end_detach
}

sequence Smoking
{
   attach "Cigarette"
   detach ALL_OTHERS
   animate "smoking"
   pause 240  // 4 minutes
   detach "Cigarette"
   on_detach
      stop "smoking"
      hud SHOWMENU
   end_detach
}

with animations it can be that they are in the console HUD or they can be in the item. When in item then item secures permissions, stops/starts animation. When not the HUD handles the animation. From the sequence writer's pov the engine works this out for itself   

 

Edited November 1, 2019 by Mollymews
misplaced quote

[KT Kingsley]

Yes, @Mollymews, that's kind of where my thinking has been going. Rather than attaching and detaching specific items and trying to get them to attach or detach any associated items, I should attach a "towel controller" object that does all that. And yes, making the configuration as flexible as possible would be the smart thing to do: I can see this being useful for a few other things of mine.

[Mollymews]

KT, you have the experience and ability to make this kind of engine. Had I not believed so then I wouldn't have proposed it

writing these kinds of interpretive engines can be quite satisfying. As you say there are lots of uses to which it can be applied.  When bundled as a kit then it can also open doors for non-scripters to create interactive experiences of their own. Just by writing a sequence. Non-scripter for example can include people who know how to make gestures. As this kind of sequence format is structurally/logically similar to a gesture

it will be interesting for me to see how far you might take this.  And anyone else who might have a go at it