Jump to content

llDetectedTouchFace and llDetectedTouchST


Yurtiel
 Share

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

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

Recommended Posts

Okay, I got a lot of stuff figured out and as to my prior stuff I've gotten them fixed so I'll explain a bit before this one.

 

On my HUD I'm using llDetectedTouchST and ll DetectedTouchFace to cut down on prims, and this is working amazingly well, everything does what it's supposed to.

 

Well I noticed that llDetectedTouchFace and LlDetectedTouchST affect not only the prim it's in (Root Prim) but also all child prims so whenever I click them in the vectors specificed on the child prims it hides/shows my prims as if I was doing it on the main prim.

Rather than rescripting an entire thing AGAIN, I decided I would be sly as hell and just change the script within the child prims to work on face 2 rather than face 4, and then set my vectors to work therin, so when I click on the area between vector x and vector y it should say "Touched".


However, whenever I click on the vectors where the "Button" would be, it does absolutely nothing as if it doesn't even know that face 2 exists.

 

Is this some sort of bug or something, or can I not simply use llDetectedTouchFace in a child prims script to utilize other faces while the root prim is using it for face 4?

Link to comment
Share on other sites

A script in the root prim detects touch events in all the prims in the linkset, so if you want to identify which prim has been touched, you need to call llDetectedLinkNumber., something like this (but don't do it this way.. see below):

 

	touch_start(integer total_number)	{		integer n = llDetectedLinkNumber(0);		if (1 == n){			//touched the root prim			//do llDetectedTouchFace and llDetectedTouchUV for the root		}		else if (2==n){			//touched link number 2			//do llDetectedTouchFace and llDetectedTouchUV for link number 2		}	}

 

However, I would strongly suggest that, rather than using link numbers, you use link names or descriptions, like this:

	touch_start(integer total_number)	{		string str = llGetLinkName(llDetectedLinkNumber(0));		integer n = llDetectedTouchFace(0);		vector v = llDetectedTouchUV(0);		if ("button 1"==str){//touched the prim called "button 1", whatever its link number			if (4 == n){//the root prim of a hud should always have face 4 facing the user, by default.  This ensures it's at ZERO_ROTATION				if (v.x<=0.5){//and so on				}			}		}		else if ("button 2" == str){		}	}

 That way you can move and relink the prims without needing to keep track of the actual link numbers, which will drive you into tears of rage and frustration before long, trust me.

Link to comment
Share on other sites

Let me be sure I understand the setup.  You have a linkset that has a script in each prim, and each script has a touch_start event in it, right?   If that's the case, each prim should respond to a click by doing whatever its own script tells it to.  If a child prim's script is deactivated, then it should respond to a click as if you had clicked the root prim.

Try this.  Link two cubes.  Put this script in the root prim

default{    touch_start(integer total_number)    {        llSay(0, "ROOT: " + (string)llDetectedLinkNumber(0) + "  " + (string)llDetectedTouchFace(0));    }}

 and this one in the child prim

default{    touch_start(integer total_number)    {        llSay(0, "CHILD: " + (string)llDetectedLinkNumber(0) + "  " + (string)llDetectedTouchFace(0));    }}

 If both scripts are active, then you can click on either prim and its script will tell you that you have clicked a face on its own prim.  If you deactivate the script in the child prim, then the script in the root prim will respond to a click anywhere, and it will always tell you which face was touched and which prim was touched.  If you reactivate the child prim's script and deactivate the one in the root prim, then the child prim's script will only respond if you click the child prim.  Clicking the root prim will do nothing at all.

 

 

Link to comment
Share on other sites

Innuza helped me with the problem, but yeah, when you have llDetectedTouchFace in the root prim it effects all child prims.

apparently this also overrides the child prims personal scripts as they started to work when I combined the scripts with the main script, or when I actually defined their keys.

Link to comment
Share on other sites

Now for my last question (And should be the last one I need to ask for a while.)

 

I need to know how to set up a system where, when you click on a prim, it will have the default value of 0

It will then tick up to 1 when clicked.

And will then tick up to 2 when clicked again.

up to a max of 10

So on and so forth.

I then need to make it so that when another prim is clicked, it will take that value and subtract 1.

So on 1st click total = 9

2nd: total = 8

etc etc.


I don't want people to think that I'm just requesting a script I'm going to use, I just need examples of this because I can't seem to find any anywhere. And all the ones I see use it in a loop instance of num_detected ++i.

However I'd like to refrain from using num_detected if at all possible because I'm not entirely sure if it will do the equations right that I need it too.

Link to comment
Share on other sites

I think  a better way to look at it is that if someone touches any prim in a linkset, that registers with a touch event in a script in the root.   So if in the root prim you say, in a touch_start event, if (llDetectedTouchFace(0)==4), without specifying what the link number or name is, then that means "if someone touches face 4 of any prim in the linkset".   

If you have a touch event in the root, LSL assumes you want it to fire if any part of any face of any prim in the linkset is touched.   If you want to filter it in any way, you have to specify that with a condition or conditions.

Link to comment
Share on other sites

I'm not quite sure what you have in mind, but if gCount is a global integer, initially = 0,

touch_start(integer num){    llSay(0,(string)(++gCount));}

 will increase gCount by 1 each time you click: "1, 2, 3, 4, ...."

And if gCount is initially = 10,

touch_start(integer num){    llSay(0,(string)(--gCount));}

 will count down by 1 with each click: "9, 8, 7, 6, ..."

 

 

Link to comment
Share on other sites

The answer, as always, is "it depends".  My general rule is to define any variable within the scope in which I intend to use it, and no larger.  If you need a global scope, because you are going to be using a variable in more than one event or state or because you need to save its value from one time that you use in an event to the next time that the event is triggered, then do it.  If your scope will be more limited, do not use a global variable.  It's probably best if you spend some time pondering the discussion at http://wiki.secondlife.com/wiki/LSL_Variables

Link to comment
Share on other sites


Charlotte Holmeforth wrote:

You may find this function of use 
. It can prevent touches on a child prim being passed to a script in the root prim.

A tiny clarification:

It turns out that the default behavior is for touches not to be passed to the root prim if the child prim has a script containing a touch event.  llPassTouches (per the WIKI caveats) has no effect if there is no touch event in the child.  It's unneeded if you don't want the touches passed & have a child touch event.  It does nothing if used and the child has no touch event.  It does nothing in a root prim script.

Link to comment
Share on other sites

I can't say I often (ever?) use llPassTouches, but am I correct in thinking that I would consider using it only if I've got scripts in both the root and a child prim, both scripts contain touch events, and I don't want the touch event in the root to fire if someone touches the child prim?

It's an old function, and, to my mind, it's now pretty much obsolete since there's very circumstances in which I would need a separate script, let alone one containing a touch event, in a child prim.

 

Link to comment
Share on other sites

I agree, Innula.  Almost any situation I can think of that might have once needed llPassTouches can now be done better with a single script in the root that uses llDetectedLinkNumber (or, better, llGetLinkName(llDetectedLinkNumber(0)) ), possibly in combination with one of the llDetectedTouch* functions.

Link to comment
Share on other sites


Innula Zenovka wrote:

I can't say I often (ever?) use llPassTouches, but am I correct in thinking that I would consider using it only if I've got scripts in both the root and a child prim, both scripts contain touch events, and I don't want the touch event in the root to fire if someone touches the child prim?

It's an old function, and, to my mind, it's now pretty much obsolete since there's very circumstances in which I would need a separate script, let alone one containing a touch event, in a child prim.

 

I think when I first came across llPassTouches I wanted to ignore all child touches in the root prim script.  However it didn't do anything in Root.  So I never found a use for it.  It's only needed if both root and child have touch events and you sometimes or always want Root to detect the child touches. 

Default behaviour is the same as llPassTouches(FALSE) when there is a touch event in the child prim.

It's confusing because it does nothing if not in a child prim script containing a touch event.

 

Link to comment
Share on other sites


Innula Zenovka wrote:

I can't say I often (ever?) use llPassTouches, but am I correct in thinking that I would consider using it only if I've got scripts in both the root and a child prim, both scripts contain touch events, and I don't want the touch event in the root to fire if someone touches the child prim?

It's an old function, and, to my mind, it's now pretty much obsolete since there's very circumstances in which I would need a separate script, let alone one containing a touch event, in a child prim.

 

You'd use it if you DID want the touch event passed on. Default is FALSE.

 

Say one did a HUD with buttons that each had distinct functionality that you wanted to toggle on and off as needed. Using llPassTouches(TRUE) in each button (child prim) script then the background prim (root) script could then highlight (with color, scaling or texture changes) the active button(s) at any moment.

 

And, yes, it could be done in one huge script in root but this approach would modularize everything and give the scripter much more room to work within in developing the functionalities of the buttons.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3692 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...