[Opensim-dev] client API bindings?

[Maróy Ákos]

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