|
Jaynius Shaftoe
Automated User
Join date: 9 Jan 2005
Posts: 29
|
04-14-2005 20:21
For some days now i've been thinking about client-side prims. The new voting system seems to accept links to message board threads, so if people are interested I'll suggest it. At first I wanted to control client side dialogs, but I realized that using in-world objects would allow richer interaction. The idea is to create an object with an additional flag "client-side", basically a ghosted object that each person can modify in their own world independantly of each other. The server don't know and don't care about them. If those local objects want to communicate with the world, they simply email a "normal" prim on the server. This would allow an object to "run" a virtual user interface that only the operator would see. If scripts could be run client-side too it would be awesome, but those "ghosted" objects could also be managed by server-side scripts, just like llTargetOmega. (And it would allow us to handle that bug ourselves  ) How does it sound? |
|
Jeffrey Gomez
Cubed™
Join date: 11 Jun 2004
Posts: 3,522
|
04-14-2005 21:21
I suggested it last night. Vote for it. Should be in the 50s. 
_____________________
---
|
|
Jaynius Shaftoe
Automated User
Join date: 9 Jan 2005
Posts: 29
|
04-14-2005 22:06
Just to provide URLs, Jeffrey's proposition is discussed here /13/d6/36705/1.html and you can vote https://secondlife.com/vote/get_feature.php?get_id=61If I understand correctly we are indeed talking about the same thing. |
|
Jeffrey Gomez
Cubed™
Join date: 11 Jun 2004
Posts: 3,522
|
04-14-2005 22:36
I think we are. Thanks for the links!
_____________________
---
|
|
Cienna Rand
Inside Joke
Join date: 20 Sep 2003
Posts: 489
|
04-15-2005 07:27
From: Jaynius Shaftoe At first I wanted to control client side dialogs, but I realized that using in-world objects would allow richer interaction. The idea is to create an object with an additional flag "client-side", basically a ghosted object that each person can modify in their own world independantly of each other. The server don't know and don't care about them. If those local objects want to communicate with the world, they simply email a "normal" prim on the server. This would allow an object to "run" a virtual user interface that only the operator would see. If scripts could be run client-side too it would be awesome, but those "ghosted" objects could also be managed by server-side scripts, just like llTargetOmega. (And it would allow us to handle that bug ourselves ) How do you propose that the server control these prims if it isn't supposed to know about them? I'm sure this would be beneficial in a few cases but there are still issues. 1) The server will still need to keep track of them to tell the client when to show them. 2) The asset server will still need to keep track of them so they exist and are modified. 3) You'd still be taking up script resources on the server to control these prims. 4) You can't modify the base UI (personal goal ) In the spirit of fairness, since this thread is linked from my own; balance this suggestion against my own suggestion ( Prop 120) for a fully customizable and extensible UI which would really be something the server doesn't care about once it's on the client.
_____________________
You can't spell have traffic without FIC. Primcrafters (Mocha 180,90) : Fine eyewear for all avatars SLOPCO (Barcola 180, 180) : Second Life Oil & Petroleum Company Landmarker : Social landmarking software Conversation : Coming soon!
|
|
Jaynius Shaftoe
Automated User
Join date: 9 Jan 2005
Posts: 29
|
Proposition 8 - HUD Attachment point.
04-15-2005 16:59
http://secondlife.com/vote/get_feature.php?get_id=8This is interesting, and is very similar to what I am asking, but my proposition is a little different: Local objects could still be aligned with world coordinates, or screen coordinates if prefered. But the key point of both propositions is to use in-world elements to build the client side user interface.
|