[sldev] Implementing extensions in the Open Source client only.

[Fairlight]

Hi!

Well, it would be doable server side, making the client send out soemthing  
on a special channel.. but that'd be a, pardon my words, pain in the ass  
way to do it, not the proper way.. the proper way would be to do it just  
like the other llDetected...() commands, as this would make the most  
sense.. but the downside of it is that it'd definitively require linden  
support on implementation...

Woot! It's weekend!
  Fairlight Lake!


On Fri, 26 Jan 2007 23:36:49 +0100, Argent Stonecutter  
<secret.argent at gmail.com> wrote:

> Sorry about the last digest being mostly my responses, they were delayed  
> an "crossed in the post".
>
> Getting back to the Open Source client... :)
>
>> I got a new Feature Request about getting feedback of the touched  
>> coordinates on a side of a prim. This would enable to save prims on  
>> HUDs and other control panel-like objects.
>>
>> (Think "imagemap" in html.. basically.)
>>
>> https://wiki.secondlife.com/wiki/Feature_Request_Touch_Coordinates
>>
>> Please discuss there and feel free to add to the pros and cons.
>
> Can you think of a way that this could be implemented using the open  
> source client code only?
>
> I don't see a way to do it using the ClickAction message, perhaps the  
> client could detect clicks on a special tagged texture (shared common  
> UUID, like the invisiprim UUIDs) and send a formatted message to a well  
> known channel?
>
> I was thinking of special tagged textures like that today for  
> implementing mirrors, using a variant on the freeze-frame snapshot  
> mechanism.
>
> When a texture with a specific UUID was displayed on a flat face (to  
> simplify things, you wouldn't allow curved mirrors), each frame the  
> client would run a rendering pass from the mirrored viewpoint clipped to  
> the mirror's bounds, and render the resulting texture in place of the  
> mirror. This should take significantly less time than a full frame  
> unless the mirror is almost filling the frame... in which case most of  
> the frame would be masked. The case of multiple mirrors could be  
> ignored... only the closest mirror to the avatar would be rendered as a  
> mirror, the rest would show the underlying texture.
>
> This could be done without any changes to the sim-side software.
>
> What are the downsides of this approach?
>
> 1. Getting Linden Labs to pick up the code after it's done. If it's cool  
> enough that shouldn't be a problem.
>
> 2... ?
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html



-- 
                         (`.-,')  
--------------------------------------------
                      .-'     ;               F a i r l i g h t
                  _.-'   , `,-          t h e   w h i t e   l i o n
            _ _.-'     .'  /._
          .' `  _.-.  /  ,'._;)   E-mail:              fairlight at tigress.com
         (       .  )-| (         Homepage: http://www.tigress.com/fairlight
          )`,_ ,'_,'  \_;)  fL    Puppetry          E-Mail: pawpet at pawpet.de
  ('_  _,'.'  (___,))             Puppetry Homepage:    http://www.pawpet.de
   `-:;.-'                        
--------------------------------------------