Oliver Schroeder > Am Tuesday 19 July 2005 18:05 schrieb Vivian Meazza: > > Oliver Schroeder > > > 3) artificial life at airports > > > [...] > > Would a dedicated instance of FlightGear running all the AI traffic > needed > > and passing them to the server for distribution to all players do the > > trick? (filtering by range if that's how you decide to do it). > > I *think* that the flightgear client is kind of to big and this kind of > program (lets call it "injector") does not need all of its functions. Eg. > there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a > stripped down version of the flightgear client would be just what we need.
Yes FG is big, and would have unused functions. Against this has to be balanced the time and risk in developing and maintaining a stripped down version. I don't have a handle on the size of that task or the risks involved. I suggested some time ago that the first player's system might handle all the admin tasks - that way you get the AI traffic, carrier movements etc. virtually free. However, there are significant questions surrounding that idea: in particular what happens when the first player leaves. It ought to be possible for the 2nd player to take up the task, because both systems should be aligned. There is also the load on the individual client to be taken into account. This is beginning to look like some of the NATO data links where there was no central server, but each unit contributed to the whole environment. Hmm ... > > We should be aiming for the server to co-ordinate the whole environment > - > > traffic, weather, time. We need to be clever about bandwidth though - > and > > only send this kind of background data strictly when needed. The client > > FGFS will have to do much of the work, I suppose. > > There are arising some questions about it. > First of all: what can and what should be handled by the server? > Currently it knows only very few things about what it is actually serving. > It > knows a little bit about callsigns, will know a bit about distances and > different kinds of clients in the near future. > Adding "knowledge" to the server adds lines of code which have to be > changed > in order to improve things (code changes have to be done in the client > _and_ > the server). > What about letting a scriptable client (i.e. a striped down version of > fgfs) > do most of such things? > I'm not sure exactly what you mean by a scriptable client. Does this mean that it has pre-scripted AI traffic, carrier movements, weather etc.? A little crude perhaps, but effective, but see my comments above. On the other hand we could tell each client what the AI traffic should be and let the client do all the updating. Less bandwidth required, at the trade-off of a build up of errors. Good enough for AI traffic, but perhaps not for the carrier. Of course, this is what happens with the player aircraft - they must already exist on the client system, and this could also be the case for the AI traffic flightplan. If you are saying that the server should have as little "knowledge" as possible, then I would go along with that. I think the server probably needs to coordinate the network time but beyond that ... there is a case for the server to filter by range, but this could also be done by the client. I have no strong view on how this should be achieved. We should build on what we already have in order to achieve a fully coordinated environment. We should not be re-inventing wheels, flaps or anything else :-) Vivian _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
