Stuart wrote:
I think our current MP architecture is superb for the following reasons:
- Setting it up is straightforward
- it is light-weight. The load on the client and server is low -
personally I have it switched on permanently - so people are encouraged to
use it for general flying, even if they are not flying specific MP
missions
- The environment is global - there is a single virtual airspace, no
matter which server you connect to (except for CVS vs. release ports)
.....................
My conclusion is that the dog-fighting MP protocol (using a server FDM) is
going to have to be completely separate from the civil MP protocol (usign
a client FDM).
End Quote.
I think we can still achieve these goals in the proposed architecture.
-Easy set up can be achieved.... not a problem.
-Over the next several weeks, I plan to do some benchmarking to determine
how "heavy" the FDM really is.
If it is overly burdensome on framerate due to latency, I see no reason why
a server cannont support both architectures (single and split). It could
simply pass UDP packets as it does now, but also support clients requesting
FDM services. If a user is too distance (latency wise) from a server to
find the serverside FDM useful, then they can switch to the system as it is,
run the FDM locally and probably suffer from MP "jumpiness". However, if
the latency is not a framerate killer then they will benefit from better MP
sync .... not a problem.
-As I investigate this proposed architecture, I plan to avoid splitting the
FG world. I do plan to allow easy avoidance between fighters and
non-fighters (at various levels), but I think the FG community as a whole
benefits from a single set of servers. There are problems associated with
distributing the FDM of several craft over servers geographically spaced
out, but I am confident enough that it can be overcome to warrant more
research.
Jonathan and I have a fair amount of hardware at our disposal. When we have
a test architecture (don't have a time estimate yet) we plan to test client
and server on single, dual, quad and eight core machines. We have a high
speed connection into our NOC (read high speed fiber) and will likely host a
server here.
The new architecture we are proposing will not be useful if it does not meet
or exceed the performance of the current architecture. We are well aware of
this.
If the new version fails to outperform the current implementation in
benchmark testing we will not proceed further. We may go back to the
drawing board, or we may focus our effort elsewhere.
I may be wrong, but I think alot of people here are getting wound up over
the fact that dogfighting may be implemented, without seeing the inherent
improvements that it offers FG.
The technical problems associated with DF could foreseeably offer:
-improved response to future hardware parallelism
-better sync for formation flying
-real world consequenses for hitting your formation partner (air-air
collision)
-real world modeling for aircraft damage (how bad was that air-air collision
during formation flying?)
-improved interaction between AI and users (SAR could be implemented coast
guard style)
Regards,
James
On 5/14/07, Martin Spott <[EMAIL PROTECTED]> wrote:
Gene Buckle wrote:
> > Personally I'd go crazy in the real Cessna if it would take me one
> > third of a second until the beast starts !! responding to a control
> > movement - this would turn almost every landing at gusty crosswind
into
> > a really difficult situation ....
>
> Martin, the 300ms figure is really only applicable to a Level A
simulator
> which is basically equivalent to a cockpit procedures trainer with no
> visuals.
Ok - that one makes sense. On the other hand, any type of 'tricky' VFR
flight with 300 ms delay, I'd expect even with 150 ms would ruin every
pilot's nerves .... :-)
> BTW, sorry for being such a jerk. You were able to (likely
> unintentionally) wind me up like a clock-spring connected to a gas
> turbine. :)
;-)
You're welcome, it's ok,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
James Palmer
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
