Jump to content

Light switch on the vehicle. Script


Sunbleached
 Share

You are about to reply to a thread that has been inactive for 1749 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hello! my vehicle has a light system called from the menu. how to add to the script also the option to turn on the light when you click on a specific prim/face in the vehicle linkset? and how resource-consuming is this change? is it worth doing?

Edited by Sunbleached
Link to comment
Share on other sites

On its own, a change like this would likely be trivial as far as resources are concerned. I imagine a single if-statement in your touch_start event would suffice. You'd check if llDetectedLinkNumber and llDetectedTouchFace return the desired link and face index respectively and if so, toggle the light as demonstrated by Rolig's example.

  • Thanks 1
Link to comment
Share on other sites

3 hours ago, Rolig Loon said:

if ( message == "Light" )
{
     iSwitch = !iSwitch;
     llSetLinkPrimitiveParamsFast( iLightBulb,[ PRIM_GLOW, ALL_SIDES,0.1*iSwitch]);
}

or words to that effect.

 

 

1 hour ago, Fenix Eldritch said:

On its own, a change like this would likely be trivial as far as resources are concerned. I imagine a single if-statement in your touch_start event would suffice. You'd check if llDetectedLinkNumber and llDetectedTouchFace return the desired link and face index respectively and if so, toggle the light as demonstrated by Rolig's example.

Hello! Thank you very much for your answers!

I started with

    touch_start(integer total_number)
    {
        integer face = llDetectedTouchFace(0);
        if 
        (face == 2)
        {        
        llSay(0, "Light is on");
        }
    }

but how to add llDetectedLinkNumber?

And one more thing, i noticed that in my script only touch_end is used, will it still work? (Edit: yes it will, just checked).

Edited by Sunbleached
Link to comment
Share on other sites

Yes it will still work. Clicking on a scripted object is divided into three stages:

  • the touch_start event triggers once, right as the user initially presses the mouse button
  • the touch event triggers continually as long as the user is holding down the mouse button (in other words it will loop)
  • the touch_end event triggers once, right after the user lets go of the mouse button

All this means is that your existing menu code apparently triggers at the end of a click, and your new code as currently written will trigger right at the start of a click. There's nothing necessarily "wrong" with that, though from a user experience, it may or may not feel intuitive - but that's subjective. You could just as easily put the new code in the touch_end event along with the other stuff. Or not - It's entirely up to you.

In order to work with llDetectedLinkNumber, you need to know what the desired number is, similar to what you have done with the face index when using llDetectedTouchFace.  The way I usually do is is to give the target child-prim a unique name and then run a loop to scan each item in the linkset for that name. Once found, store the index in a global variable and test against that where needed. The drawback to this is that you must re-run that loop if a new prim is linked or unlinked from the set - because it's then possible the target link index might change.

However, Rolig's example above bypasses that completely. Instead of saving the link number in a global variable, she just checks if the child-prim that was just clicked has a name equal to whatever unique one you setup earlier. If so, continue on with the other stuff. If not, do nothing since it wasn't the desired child-prim.

I never considered doing it that way before, so thanks for that, Rolig!

  • Thanks 1
Link to comment
Share on other sites

@Rolig Loon @Fenix Eldritch

Thank you very much again!
And if I turn on the light first through the menu, and then want to turn it off by pressing the switch button, will such a circuit work? How to make the script "understand" whether the light is on or not, and it needs to be brought into the opposite state?
And yet, Houston I have a problem!.. It turned out that my touch event with menu and the procedure for turning on the light are in different scripts. is it possible to continue in this case?

Edit: if it were possible to make the script recognize the state of light, then everything would be in order and both switch options would coexist peacefully, right?

 

Edited by Sunbleached
Link to comment
Share on other sites

I’ll explain a bit what I'm working with. two scripts. The first one contains a menu, a touch event. the second script contains a system of particles, rotation of parts, sounds, and the light system itself.

And I'm trying to add this new option to first script with the menu. since there is already a touch event.

 

 

Edited by Sunbleached
Link to comment
Share on other sites

I was operating under the assumption that you had access to the menu script and were trying to augment it with the manual light switch code. If you do have access to the script, study how the menu controls the light status (it will most likely be a global variable) and use the same hooks in your manual trigger code - and of course, add the code to the menu script.

If on the other hand you do not have access to the menu script and are adding this functionality with a completely separate script, that changes things considerably. There will be an obvious disconnect between the two systems. Without knowing how the menu works, it may not be possible to make them coexist nicely. It might be possible, but you need to provide more information on how the existing script works. For example, is the menu using llDialog?

  • Thanks 1
Link to comment
Share on other sites

41 minutes ago, Fenix Eldritch said:

I was operating under the assumption that you had access to the menu script and were trying to augment it with the manual light switch code. If you do have access to the script, study how the menu controls the light status (it will most likely be a global variable) and use the same hooks in your manual trigger code - and of course, add the code to the menu script.

If on the other hand you do not have access to the menu script and are adding this functionality with a completely separate script, that changes things considerably. There will be an obvious disconnect between the two systems. Without knowing how the menu works, it may not be possible to make them coexist nicely. It might be possible, but you need to provide more information on how the existing script works. For example, is the menu using llDialog?

Yes, I have access to the menu script and it uses llDialog.

Looking ahead, can i simply create an additional touch_end event in the menu script, and not to integrate into existing one?

(I guess not - just made this silly experiment:

    touch_end(integer total_number)
    {
        llSay(0, "Hello!");
    }
        touch_end(integer total_number)
    {
        llSay(0, "Goodbye!");
    }

)

But i can use touch_start and touch_end.

Edited by Sunbleached
Link to comment
Share on other sites

42 minutes ago, Sunbleached said:

And if I turn on the light first through the menu, and then want to turn it off by pressing the switch button, will such a circuit work? How to make the script "understand" whether the light is on or not, and it needs to be brought into the opposite state?
And yet, Houston I have a problem!.. It turned out that my touch event with menu and the procedure for turning on the light are in different scripts. is it possible to continue in this case?

At the risk of sounding unhelpful, let me point out as I have in the past that you need to step back and ask yourself what the script should be doing instead of leaping quickly to ask how to do it. Scripting is not a mechanical exercise of gluing statements together.  It is an exercise in logic. 

Until you develop an intuitive feel for how a script can flow (if you ever do), get in the habit of drawing a map for yourself, just as if you were about to take a road trip. The easy points on the map are the starting point and the goal(s) at the other end.  Sit down with paper and a pencil and draw in all of the roads between those points.  Mark every intersection where you will have to make a decision about which way to turn.  Identify places where you will need to stop and ask for more information.  Anticipate places where you may need to make a detour if something goes wrong.  Create the shortest, cleanest map that you can, just as if you were giving your grandmother directions to your new home. When you are finished, you will have a "logic map" that tells your  script what to do. Then you can set your mind to the relatively easy job of writing the commands so the script knows how to do it.

I have been scripting long enough that I have long since given up needing to create an actual map on paper, but I always start by visualizing its basic structure in this way.  As I develop the script and begin to understand things that I didn't give enough thought to earlier, I adjust my mental map. I start to fill in side roads and add directional signs so that the end user will trust that the script knows where it's going.  I never forget that I am making a logical puzzle come to life.  I only begin to worry when I catch myself asking how to make a script do something that I haven't figured out in my own head first.  

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

13 minutes ago, Rolig Loon said:

At the risk of sounding unhelpful, let me point out as I have in the past that you need to step back and ask yourself what the script should be doing instead of leaping quickly to ask how to do it. Scripting is not a mechanical exercise of gluing statements together.  It is an exercise in logic. 

Until you develop an intuitive feel for how a script can flow (if you ever do), get in the habit of drawing a map for yourself, just as if you were about to take a road trip. The easy points on the map are the starting point and the goal(s) at the other end.  Sit down with paper and a pencil and draw in all of the roads between those points.  Mark every intersection where you will have to make a decision about which way to turn.  Identify places where you will need to stop and ask for more information.  Anticipate places where you may need to make a detour if something goes wrong.  Create the shortest, cleanest map that you can, just as if you were giving your grandmother directions to your new home. When you are finished, you will have a "logic map" that tells your  script what to do. Then you can set your mind to the relatively easy job of writing the commands so the script knows how to do it.

I have been scripting long enough that I have long since given up needing to create an actual map on paper, but I always start by visualizing its basic structure in this way.  As I develop the script and begin to understand things that I didn't give enough thought to earlier, I adjust my mental map. I start to fill in side roads and add directional signs so that the end user will trust that the script knows where it's going.  I never forget that I am making a logical puzzle come to life.  I only begin to worry when I catch myself asking how to make a script do something that I haven't figured out in my own head first.  

Thanks a lot, Rolig!
I'm trying to imagine a map or scheme in my head. (I'm afraid if I try to draw it I get a big collider or an atomic bomb!)

So far i stuck with

    touch_start(integer total_number)
    {
        integer face = llDetectedTouchFace(0);
        if (face == 2 && llGetLinkName( llDetectedLinkNumber(0) ) == "my_nice_light_bulb" )
    {
    // toggle the light
    }
    }

and i still have no idea how to make both options coexist...

Link to comment
Share on other sites

Here my lighting system from the second (not menu) script

setLight(integer switch)
{
    string msg = "ON"; if(switch) msg = "OFF"; llMessageLinked(LINK_THIS,-707071,"[LIGHT "+msg+"]","light");
    llSetLinkPrimitiveParamsFast( LIGHT_PRIM, [PRIM_POINT_LIGHT,switch,<1.0, 1.0, 0.5>,0.5,2,1.0, PRIM_GLOW, 1, 1 * switch,
                    PRIM_LINK_TARGET, LIGHT_PRIM_2,PRIM_POINT_LIGHT,switch,<1.0, 1.0, 0.5>,0.5,5.0,1.0, PRIM_GLOW, 1, 1 * switch,
                    PRIM_LINK_TARGET, LIGHT_PRIM_3,PRIM_POINT_LIGHT,switch,<1.0, 1.0, 0.5>,0.5,5.0,1.0, PRIM_GLOW, 1, 1 * switch,
                    PRIM_LINK_TARGET, LIGHT_PRIM_4,PRIM_POINT_LIGHT,switch,<1.0, 1.0, 0.5>,0.5,5.0,1.0, PRIM_GLOW, 1, 1 * switch
]);
}

 

Edited by Sunbleached
Link to comment
Share on other sites

@Fenix Eldritch

Hello! Sorry to bother you again.
but why did you ask about llDialog? it is important?
this code turned out to work fine, but I can’t understand how now to make the scripts coexist together. Please help! (i have access to both scripts)

@Rolig Loon

And here's another question. when I click on the button, a menu pops out. is it possible to avoid? because why push a button if the menu still pops up?

integer face = llDetectedTouchFace(0);
if (face == 2 && llGetLinkName(llDetectedLinkNumber(0)) == "button")
{
  if (
    switch)
  {
    switch = FALSE;
    llSetLinkPrimitiveParamsFast(LIGHT_PRIM, [PRIM_POINT_LIGHT, FALSE, ZERO_VECTOR, 0.0, 0, 0.0, PRIM_GLOW, ALL_SIDES, FALSE,
      PRIM_LINK_TARGET, LIGHT_PRIM_2, PRIM_POINT_LIGHT, FALSE, ZERO_VECTOR, 0.0, 0, 0.0, PRIM_GLOW, ALL_SIDES, FALSE,
      PRIM_LINK_TARGET, LIGHT_PRIM_3, PRIM_POINT_LIGHT, FALSE, ZERO_VECTOR, 0.0, 0, 0.0, PRIM_GLOW, ALL_SIDES, FALSE,
      PRIM_LINK_TARGET, LIGHT_PRIM_4, PRIM_POINT_LIGHT, FALSE, ZERO_VECTOR, 0.0, 0, 0.0, PRIM_GLOW, ALL_SIDES, FALSE
    ]);
  }
  else
  {
    switch = TRUE;
    llSetLinkPrimitiveParamsFast(LIGHT_PRIM, [PRIM_POINT_LIGHT, TRUE, < 1.0, 1.0, 0.5 > , 0.5, 2, 1.0, PRIM_GLOW, 1, 1,
      PRIM_LINK_TARGET, LIGHT_PRIM_2, PRIM_POINT_LIGHT, TRUE, < 1.0, 1.0, 0.5 > , 0.5, 5.0, 1.0, PRIM_GLOW, 1, 1,
      PRIM_LINK_TARGET, LIGHT_PRIM_3, PRIM_POINT_LIGHT, TRUE, < 1.0, 1.0, 0.5 > , 0.5, 5.0, 1.0, PRIM_GLOW, 1, 1,
      PRIM_LINK_TARGET, LIGHT_PRIM_4, PRIM_POINT_LIGHT, TRUE, < 1.0, 1.0, 0.5 > , 0.5, 5.0, 1.0, PRIM_GLOW, 1, 1
    ]);
  }
}

 

Edited by Sunbleached
Link to comment
Share on other sites

17 hours ago, Sunbleached said:

And here's another question. when I click on the button, a menu pops out. is it possible to avoid? because why push a button if the menu still pops up?

I'm sorry.  You totally lost me with that one.  You pushed the button to make the menu come up.  Why are you trying to avoid it?

  • Thanks 1
Link to comment
Share on other sites

17 hours ago, Sunbleached said:

but why did you ask about llDialog? it is important?

It was an attempt to think of a possible workaround in the event that you didn't have edit access to the menu script. llDialog works by sending out the button text from the user and the script listens for that to act on. If that listen filter was broad enough, there is a slim chance that you could inject your own message from another script. But that depends on the menu script having a less restrictive (read: less secure) filter setup. Anyway it is moot since you do have edit access to the menu script after all.

You will be making much more work for yourself in trying to slam two different scripts together. Since you already have edit access to the main menu script, I would advise you work towards adding your code to the menu script instead of using a secondary script. But before you can do that, you NEED to have an understanding on how the menu script is working in the first place.

Study its touch_end event to see how it reacts to a user click. Step through each line of the code to follow where it goes. Understand how the menu script keeps track of the light's state and how it modifies it. When you understand all that, I believe it should become clearer how you can incorporate you additional code to the script.

23 minutes ago, Rolig Loon said:

I'm sorry.  You totally lost me with that one.  You pushed the button to make the menu come up.  Why are you trying to avoid it?

I'm guessing Sunbleached wants to have two different outcomes depending on what part of the vehicle is clicked. I suspect the current menu works when any part of the vehicle is clicked on - and they want to suppress that menu only when the specific prim/face to toggle the light is clicked. A simple branch (or short circuit return out of the touch_end event) would likely do the job. Providing they understand what the script is doing in the first place and map out what they want to do as you rightfully suggested.

Edited by Fenix Eldritch
  • Thanks 1
Link to comment
Share on other sites

17 minutes ago, Fenix Eldritch said:
38 minutes ago, Rolig Loon said:

I'm sorry.  You totally lost me with that one.  You pushed the button to make the menu come up.  Why are you trying to avoid it?

I'm guessing Sunbleached wants to have two different outcomes depending on what part of the vehicle is clicked. I suspect the current menu works when any part of the vehicle is clicked on - and they want to suppress that menu only when the specific prim/face to toggle the light is clicked. A simple branch (or short circuit return out of the touch_end event) would likely do the job. Providing they understand what the script is doing in the first place and map out what they want to do as you rightfully suggested.

This is exactly why I said that it's wise to start a scripting project by figuring out what you want to do, instead of leaping to figure out how to do it.  Any scripter ends up re-using parts of her own scripts that have worked in the past.  Most scripters that I know are very cautious about re-using bits of other people's scripts, however, mostly because they are based on someone else's mental map of the problem. Mashing together someone else's scripts is more trouble than it's worth. 

  • Thanks 1
Link to comment
Share on other sites

@Rolig Loonsorry to confuse you.
yes, @Fenix Eldritch right, now the menu appears when you click on any part of the vehicle. I'm trying to add an additional option - a mesh button, when clicked, the light will turn on, but the menu will not drop out (good example - bandit's boats light switch) so far, thanks to you, I managed to make the first part, but the menu still drops out. and i also need a button or menu to bring the light into the opposite state. for example, if i turn on the light with a button, the menu still says "turn on the light".

Of course, you are right to draw a map.
this is how i see it in my own words.


if clicking on the mesh button.

-- the script checks the state of the light and puts it in the opposite state.


if clicking on another part of the vehicle.
-- the menu pops up

-- script checks the state of the light

-- i see menu button "turn light on (or off)"

-- menu button pressed

-- script puts light in the opposite state.

 

Edited by Sunbleached
Link to comment
Share on other sites

1 hour ago, Fenix Eldritch said:

You will be making much more work for yourself in trying to slam two different scripts together. Since you already have edit access to the main menu script, I would advise you work towards adding your code to the menu script instead of using a secondary script. But before you can do that, you NEED to have an understanding on how the menu script is working in the first place.

Yes, this is the best option, I will do so.

But menu script is obfuscated and I understand little of it...

in any case I am already very happy with the result of the work, as I learned a lot! Thank you again!

Link to comment
Share on other sites

@Sunbleached The issues you're having are because you're trying to use two scripts that were never designed to work side-by-side. Making a button that tells a light to turn on a simple. Stopping a dialog window from poping up would some modification to the menu script. You'd like to add a custom check/if like..

if(llGetLinkName(llDetectedLinkNumber(0)) != "buttonsName")

{

// Do the dialog

}

So everytime you click the script checks to make sure the light button was NOT clicked. You could even add an else if() to this script to send the command to turn on the lights.

  • Thanks 1
Link to comment
Share on other sites

4 hours ago, Scaler Rexen said:

@Sunbleached The issues you're having are because you're trying to use two scripts that were never designed to work side-by-side. Making a button that tells a light to turn on a simple. Stopping a dialog window from poping up would some modification to the menu script. You'd like to add a custom check/if like..


if(llGetLinkName(llDetectedLinkNumber(0)) != "buttonsName")

{

// Do the dialog

}

So everytime you click the script checks to make sure the light button was NOT clicked. You could even add an else if() to this script to send the command to turn on the lights.

Thank you so much! the script has advanced significantly! it remains only to understand how to make the menu script bring the light into the opposite state.

because for example, if I turned on the light with a mesh button and want to turn it off through the menu, it still displays "turn on the light". until I click it and only then i am able to "turn off the light".

Any help greatly appreciated!

 

integer toggle;
setLight(integer switch)
{
  llSetLinkPrimitiveParamsFast(LIGHT_PRIM, [PRIM_POINT_LIGHT,
    switch, < 1.0, 1.0, 0.5 > , 0.5, 2, 1.0, PRIM_GLOW, 1, 1 *
    switch,
    PRIM_LINK_TARGET, LIGHT_PRIM_2, PRIM_POINT_LIGHT,
    switch, < 1.0, 1.0, 0.5 > , 0.5, 5.0, 1.0, PRIM_GLOW, 1, 1 *
    switch,
    PRIM_LINK_TARGET, LIGHT_PRIM_3, PRIM_POINT_LIGHT,
    switch, < 1.0, 1.0, 0.5 > , 0.5, 5.0, 1.0, PRIM_GLOW, 1, 1 *
    switch,
    PRIM_LINK_TARGET, LIGHT_PRIM_4, PRIM_POINT_LIGHT,
    switch, < 1.0, 1.0, 0.5 > , 0.5, 5.0, 1.0, PRIM_GLOW, 1, 1 *
    switch
  ]);
}
/////////////////////...........................////////////////////////


if (llGetLinkName(llDetectedLinkNumber(0)) != "button")
{
  //dialog
}
integer face = llDetectedTouchFace(0);
if (face == 2 && llGetLinkName(llDetectedLinkNumber(0)) == "button")
{
  if (toggle)
  {
    toggle = FALSE;
    setLight(0);
  }
  else
  {
    toggle = TRUE;
    setLight(1);
  }
}

 

Edited by Sunbleached
Link to comment
Share on other sites

If you're looking for the menu to display "Lights on" When they're off and "Lights Off" when they're on it'll take a decent bit of changes. If you don't understand your menu script or how list work this would be very confusing. You'd just be adding  to the list once clicked and checking if the light is On or Off..

myListName = ["Option 1","Option 2","Option 3"];

lightsOn = TRUE;

if(lightOn == TRUE) // The light is currently on

{

myListName += "Lights Off"; // Add the option to turn the lights off.

}

else

{

myListName += "Lights On"; // Else the lights must be off add turn on.
}

The code above would add to the list a 4th option to turn the lights on or off like so below.

myListName = ["Option 1","Option 2","Option 3", "Lights On"];

 

  • Thanks 1
Link to comment
Share on other sites

This may or not be helpful here, but when I'm faced with a situation where a dialog button text needs to differ depending on a flag, I tend to do something like this:

llDialog (id, "Click:", ["This", "That", llList2String (["Lights on", "Lights off"], lightsOn)], channel);

 

  • Like 1
  • Thanks 2
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1749 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...