[Opensim-dev] another little can of worms: attachments :-)

Fri Jan 4 21:00:43 UTC 2008

And a happy new 2008 to you!
I've actually not looked at attachments in detail, but for discussions sake, I'll offer my pre-grok thoughts; 1) attachments == sceneobjects (but we need to work on sceneobjects) - we already have a mechanism in place to exempt objects from backup, but that need to be worked on some more. Yes, LL has been very thorough with regards to the viewer being authoritative on avatar appearance; the server can't initiate _anything_ to happen to the clients avatar.MW and I has been fretting over the LL avatar/prim model (that is, that everything is listed in a 'flat' model, with 'root prims' and 'the avatar becomes the root') as we (maybe mostly me) leads to all kinds of perverse workarounds for the system, application or script programmer alike, where the code has to take into account whether the prim is a standalone, root or child in a link set, attached or not, which leads to a hell of a lot of if-cases if you're writing generic code. (Or server code)The Group/Part architecture was our last approach to creating a compromise; it's in NO WAY ideal, and needs to be re-thought when we're talking about attachments. I think the avatar should be thought of as a type of objectgroup, holding attachments that are a type of objectgroups as well; and that everything is represented as offsets, with helper functions to find and work with world coordinates. This hybrid thing we have now as a SL legacy is a pain in the butt.

After discussing things with MW I'm willing to kill my pet peeve (that the children shouldn't have links to their parents) so the calculations should be easy enough.

2) There is really nothing saying we can't send Region.Environment types into the Client Stack; the ObjectUpdate could get a ref to the Avatar and a list of Objects that should change, and build the packet from that.

Then again, that packet builder thing (would probably work something like a stringbuilder) could be a nice generalized way to build combined packets. In that case, only the interface would be public, and the concrete class would be internal to the Client Stack. (We want to keep the Packets well hidden; our long-term goal is to have libsl types confined to the Client Stack)

We have two things that we should revise in the Client Stack (for 0.6, as I think attachments is a worthy 0.6 goal) ; we should introduce EventArgs for the events, and normalize the API so that it uses a set of base objects instead of long parameter lists.

Yes, I was the one to advocate long parameter lists, as that is a great way of enumerating what is ACTUALLY used by a function (decouples the method from the types, helps you see what is affected by a certain change, and lets you dodge type changes that don't really concern the method) but at some point, you need to introduce a 'parameter object'; and over time, that grows into something very similar to the base objects that you tried to avoid to begin with. I think we are at that point now; and at this point, normalization is more important than decoupling.

(Also, we need to start breaking our base objects apart; scene, group and part are doing way too much)

/Stefan

Date: Thu, 3 Jan 2008 01:51:01 +0100From: dalienta at gmail.comTo: opensim-dev at lists.berlios.deSubject: [Opensim-dev] another little can of worms: attachments :-)hi all, first of all - happy 2008! as I've had a bit of time today, I decided to dig into the intrinsics of attaching stuff. The AttachObject method which is somewhere in the code is incorrect -  the packet it tries to send to client is originated by the client in the first place, the command to "attach stuff" to the viewer is the ObjectUpdate packet with not one but two elements of ObjectData - the first one being the one for Avatar, and the second one being for the Thing being attached (suspected: root prim :). (there's also "attach multiple prims" which i did not dig yet). The result of these experiments is a super ugly proof of concept which is not worth committing, but which I think shows up a problem... : http://opensim.be/dalien/attachment-proof-of-concept.patch Actually, two problems:1) attachments != sceneobjects (I think) - well, at least they should not be saved into backups, etc... (and not sure how they should interact with the ODE & all - I think they should not) For the "wear from the ground" it is less of a problem - but for wearing from inventory (which i did not write anywhere beyond pointless junk) - reusing the existing rezz code might be a plus - otherwise there is a loooot of copypaste. 2) the ObjectUpdate needs to combine low-level update for both Avatar and Prim - which with layered approach (packet sending stuff being in lower layer relative to InnerScene) will result in a function with a bazillion parameters. A lesser evil that I was thinking about is to expose the "partial builder" functions on the IClientAPI level, which would return parts of the packets, which could subsequently passed to other IClientAPI packet building functions. Thoughts ?/d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080104/120756b2/attachment-0001.html>