Toni, > Hm, trying to get what you are saying exactly .. are you saying this is > something that applies to both the server and clients?
no, only the clients > Where do you create the shared python objects? On either end, and then > those are sent across and deserialized? I know how pickles work and how > those can be used for sharing state, but am actually very surprised to > hear that x-plane would use them in the protocol. I don't know > basically anything about x-plane before. maybe we have a misunderstanding of the term 'shared object'. I see you mean a serialized object which is marshalled through the network. I simply meant a dynamically linked library, called shared object in the UNIX world (extension usually .so or .dynlib on Mac, .dll on Windows) basically the point is that one has to have a client library in languages that compile to native code, most preferably C and C++. > Well I thought that if you write an x-plane protocol implementation as > an OpenSim plugin, a XplaneClientView or something, it would support > any client that talks that protocol. Like the SL, MXP and IRC > ClientViews do support any compatible clients. yes, but I don't see why I'd have to write a new protocol. why can't I just use existing ones? after all, the only information that would be send about is like: 'there's an object at this-and-that coordinate, heading this-and-that way', with some metadata like type, etc. isn't this what a virtual world environment would provide? > For that it may not actually be much of a problem. As you can see in > the viewers now, the horizon can span far. In ones that talk sl > protocol the viewers can know about several regions at a time, so they > can draw the neighbouring ones too, and they draw sky and sea etc. > however they want of course. sounds good.. > And there needs to be LOD (level of detail) systems for all usages, in > many ways (for movement update detail amount, for 3d data resolution > etc.). yes.. > Again, I thought that this was about a server implementation, as > OpenSim is a server platform / SDK, and that you'd use existing Xplane > clients. Or do you mean that the server also communicates expected > trajectories, so the client can draw based on the 'future' info too? > Should be doable, if it's done elsewhere too.. yes, that's the idea > Client side movement interpolation is implemented in the current > viewers, even in our Realxtend Naal which in very early stages still > (0.0.1 dev preview was published in June after 4 months of dev work, > 0.0.2 is targeted in october or so and something like 0.1 perhaps by > the end of the year). So I don't know how much of that you need on the > server with xplane, but certainly sounds like something that flight > servers could do .. and again very cool if they do. yes, would be cool indeed.. > May be, could be tested .. I think they are floats, at least in our > viewer, and floats are IIRC accurate near 1.0 .. hmhm well we can see, > or someone wiser can tell, am too tired to do any math right now here. :) my experience is that when talking real world coordinates, one needs double precision for sufficiently accurate positioning. > Yes, both server and client need to be smart about that. Server to know > what to send I guess, and client for what to draw (or what to request > from server, when server can be dummier? Dunno, but there probably are > solutions to this in places). thanks, I'll look around.. Akos _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
