Adding URL

Hi

how to add a URL to billboard so that If anyone clicks the URL (not the billboard object) it directs to the URL web page.

touch_start() {
vector touched = llDetectedTouchUV(0);
if(touched.x < urlmin.x || touched.x > urlmax.x || touched.y < urlmin.y || touched.y > urlmax.y) return;
llLoadUrl(llDetectedKey(0), "I dare you touch me again!", "http://goatse.cx/"; }

I've found that the "llLoadURL" won't get clicked as much because some people have an issue with the internal browser and some people have issues (or lack of desire) to load something in the external browser (usually because it lags out the whole system while it's trying to load the new browser). With the loadURL function, the user has no choice how the URL is loaded (despite the fact that they have made a choice in their user preferences).

After doing a poll of my users, I have found that the generally more tolerated and approved and effective way to do it is to do a

llInstantMessage(llDetectedKey(0),"Click this link: http://www.link.com";

This will put a message in chat and when they click it, it will load in the user's CHOSEN web browser (internal or external). LL "broke" it in the loadURL one as a new "feature" several viewer versions ago.

Argent's info on detecting the touch position is good though. Might be a bit complex for a novice scripter, but... that's the only way to do it without it being a separate prim.

that's a bit convoluted, why go with the exclusion model when LSL doesn't short circuit?

I'm not sure what you're getting at, Void.

Do you mean, why didn't I write

if(touched.x >= urlmin.x && touched.x <= urlmax.x && touched.y >= urlmin.y && touched.y <= urlmax.y) llLoadUrl(llDetectedKey(0), "I dare you touch me again!", "http://goatse.cx/";

?

Well... hmmm... because Mr Karnaugh and Mr Veitch say it comes out the same either way?

Or do you mean I should have written

if(touched.x < urlmin.x) return;
if(touched.x > urlmax.x) return;
if(touched.y < urlmin.y) return;
if(touched.y > urlmax.y) return;

?

I don't know. I was being terse.

yeah I was pretty much there (the long short circuited example is... well... long, as you pointed out... (and there's an argument against short circuiting in this case, because the url is the likely click target)

I was mostly thinking of the inherent logic, which is inclusion of the url space, and execution of the code for that space. (ok I'd have been lazy and dropped the ='s). but also, what if they wanted to include other code after that execution (not likely here, but similar uses might allow for it) then they'd be exiting the event before they could get to it in some cases, and it doesn't reflect the logic in the visual structure of the code.

I guess it depends on whether you're thinking "short circuit" or "guard".

I tend to use early return from functions for guard code quite a bit, because it makes the body of the function easier to read. If there were multiple possible target areas on the prim I might go the other way, or I might separate the code into multiple guarded functions. Eg:

if(check_url()) return;
if(check_next()) return;
if(check_prev()) return;

With each check_xxx() a guarded function.

ok, I see better why you were going that route, I'm just more used to using encapsulation to guard, rather than early returns. thanks for the answer =)