Linking object to hyper link

Hi,

I like to know how to link a sign that one could click on and a browser window pops up to a certain web page Thank you

Not possible.

I think the best you can do would be to give them a notecard that has a URL on it that they could then copy and paste into their browser.

Tigs

or you could build a web browser in SL(using images and prims to control links)

I'm working on a project that might allow this to be done(kinda)

This wou,ld be a hard to do, nearly useless, yet cool.

It's not that hard - xyText + Linux + XMLRPC + Xvfb + Lynx + 20 email children (to send back to Lynx without an obstructively large delay). Would probably be _much_ harder on Windows, but who other than idiots use Windows for anything other than gaming?

It'd be a massive waste of prims, though (~400), and I have no idea why anyone would use it rather than a browser.

On a side note, prim limits for land are way too low. Grr!

Seconded.

Even with a measly 2048 m^2 of land, SL costs something like 3-4 times as much to play as major online worlds like EverQuest or SWG or CoH or Anarchy Online, mainly because of the effect of billionaire land barons decimating every single auction.

This just isn't working on the prim front.

The power of CPUs is rising continually, and their cost is in freefall. Those savings ought to be passed back to us by doubling prim allocations every few months. Please!

There's no point being here if one doesn't have the prims to build anymore ...

I wish the prim limit were higher, too. FYI, it is currently 50% higher than when SL started (15k per sim instead of 10k).

I don't expect them to double prim allocations every few months, though. It wouldn't be cost effective to replace hardware every few months, and anyway I doubt increases in CPU speed would translate linearly into higher prim limits. (There are presumably tasks involved in managing prims -- collision detection, etc. -- that are O(n logn) or O(n^2) scale problems.)

Collision detection is indeed one of the issues that creates overhead dependent on prim count, at least in theory. It varies from O(n) in the case of end-on encounters with constructs primarily in one dimnsion all the way up to O(n^3) for encounters with tiny constructs very highly packed in 3D with prims. My guess is that a dance floor packed with dancers wearing hypothetical 50-prim bracelets flailing about on their wrists would be tough on CPUs.

That said, most of the per-prim processing occurs in the client (since it's needed for rendering), not on the server, so the cost of high-O server-side scaling isn't a total showstopper: you'd expect the colllision bounding boxes to be vastly coarser than the prim complexity of objects. In fact, in most cases you lose one whole order of O and the limit becomes O(n^2), because the bounding box reduces interactions from volumetric to outer-area only.

Scalability ranging between O(n) and O(n^2) isn't too bad when you consider that the actual encounters between bounding boxes are rare rather than continuous, in most cases. And for all we know, they might be doing most of the actual collision processing on the clients, and only confirming close encounters with the help of the server.