Hi List,
I released a new patch which can be found here:
http://www.o-schroeder.de/fg_server/mp-os3.patch
It is mainly an intermediate patch. I've restructured the network code. You
can savely remove the following files from src/Multiplayer after the patch:
multiplayrxmgr.cxx
Hi Oliver,
On Sonntag 23 Oktober 2005 23:56, Oliver Schroeder wrote:
after some discussions here on the list, but most of the time on irc, I
have drawn some conclusions on how to improve the multiplayer mode. So,
here they are. Feel free to flame me on any part which might be awfully
wrong.
Mathias Fröhlich wrote
Oliver Schroeder wrote:
...snip
3) sending properties for the carrier (Nimitz)
In order to prepare flightgear to send abitary properties, I think the
carrier is predestined. Everything we need is almost already there. What
we
need is a method in FGAICarrier
Hi List,
after some discussions here on the list, but most of the time on irc, I have
drawn some conclusions on how to improve the multiplayer mode. So, here they
are. Feel free to flame me on any part which might be awfully wrong.
1) I'm currently restructoring the network code. There will
Am Saturday 15 October 2005 11:30 schrieb Jim Campbell:
Anyone transmitting un-encrypted data across a world wide internet (as
opposed to a private intranet) needs to think ahead a little. Every
hacker will be rubbing their hands with glee before trying to hit you
on these ports you have just
Anyone transmitting un-encrypted data across a world wide internet (as
opposed to a private intranet) needs to think ahead a little. Every
hacker will be rubbing their hands with glee before trying to hit you
on these ports you have just announced. A server/client or even
peer-to-peer
Jim Campbell wrote:
Anyone transmitting un-encrypted data across a world wide
internet needs to think ahead a little. Every hacker will be
rubbing their hands with glee before trying to hit you on these
ports you have just announced.
[...]
This really isn't much of an issue. The attack you
Hi guys,
Without wishing to start a flame war and perhaps starting another
thread!!
Anyone transmitting un-encrypted data across a world wide internet (as
opposed to a private intranet) needs to think ahead a little. Every
hacker will be rubbing their hands with glee before trying to hit you
On Sat, 15 Oct 2005 10:30:44 +0100, Jim wrote in message
[EMAIL PROTECTED]:
Hi guys,
Without wishing to start a flame war and perhaps starting another
thread!!
Anyone transmitting un-encrypted data across a world wide internet (as
opposed to a private intranet) needs to think ahead a
Ok, this is *way* better than what was there before!
Thanks so far!
What I have problems with is that, as long as you use a struct for the whole
message, the compiler is free to do alignment decisions different than your
expectations on it.
I posted, at the time of the first attempts to fix
Hi,
Is there a plan to switch to OSG? Just wondering. I didn't know.
I do not know of concrete plans, but here and then there are roumors.
I for my own would apprecheate that, since it looks very promising.
... also a few weeks ago a small cvs checkin with some 'flightgear' path in it
Hi.
[EMAIL PROTECTED] wrote:
Hi all!
Yes, I know this topic has already been discussed and I know
also that someone of you is working on the FG multiplayer code...
anyway I think that it will be an advantage to the FG comunity to
interface to IVAO and/or VATSIM networks.
To implement
Hi,
I've written a patch that _should_ solve issues with endianess in
multiplayermode, which can be found at:
http://www.o-schroeder.de/fg_server/patch.php
Please try it out. Multiplayermode will still be broken on non
IEEE-encoding platforms (eg. Motorola 68XXX, vax, some DEC-alphas).
Well, if my hackery here must server as a reference for that, I think we
should improove the framework around that stuff and we should
document that
better.
By improoving that framework, I can well imagine to abstract from
the vector
classes provided from plib, so that for that time we
Hi all!
Yes, I know this topic has already been discussed and I know
also that someone of you is working on the FG multiplayer code...
anyway I think that it will be an advantage to the FG comunity to
interface to IVAO and/or VATSIM networks. Ok, They don't want that a
GPL tools is used to
[EMAIL PROTECTED] wrote:
Hi all!
Yes, I know this topic has already been discussed and I know
also that someone of you is working on the FG multiplayer code...
anyway I think that it will be an advantage to the FG comunity to
interface to IVAO and/or VATSIM networks. Ok, They don't want that
On Sunday 14 August 2005 21:56, Erik Hofman wrote:
[EMAIL PROTECTED] wrote:
Hi all!
Yes, I know this topic has already been discussed and I know
also that someone of you is working on the FG multiplayer code...
anyway I think that it will be an advantage to the FG comunity to
interface
[EMAIL PROTECTED] wrote:
[...] I think that it will be an advantage to the FG comunity to
interface to IVAO and/or VATSIM networks. Ok, They don't want that a
GPL tools is used to interface their network for secutity reasons
For security reasons ? What a joke Indeed, participating in
It's not about security
jvrvez wrote:
Ok, They don't want that a GPL tools is used to interface their
network for secutity reasons (I think this is understandable)
anyway why can't we join their network with their own code?
This is a non-starter. There is simply no way to make this work,
You might want to go back and check the email archives almost a year
ago. We had discussions with the VATSIMfolks and it went nowhere. There
was some thought of starting a development for FG using the TNL
libraries, set up a small network test, but it all faded away due to
lack of interest...
On Donnerstag 11 August 2005 13:26, Vivian Meazza wrote:
Look in src/AIModel/AICarrier.cxx - there are several examples of
conversions from Cartesian co-ordinates to geodetic and vice versa.
There are a wide range of utilities in simgear/math.cxx. The comments are
in the most part
Alberico Family
Jim Wilson did a good job of pointing me in the right direction toward
making views attached to players in a multiplayer scenario.
I attack it today and made good progress, but remain bogged down by the
transformations required. Bottom line is I need to take the 4x4 player
From: Vivian Meazza [EMAIL PROTECTED]
Date: 2005/08/11 Thu AM 07:26:23 EDT
To: 'FlightGear developers discussions' flightgear-devel@flightgear.org
Subject: RE: [Flightgear-devel] Multiplayer Location Transformation to
Lat/Lon/Alt
Alberico Family
Jim Wilson did a good job
Good evening from GMT-6.
Jim Wilson did a good job of pointing me in the right direction toward
making views attached to players in a multiplayer scenario.
I attack it today and made good progress, but remain bogged down by the
transformations required. Bottom line is I need to take the 4x4
Hi, I was playing with Oliver Schroeder's multiplayer FGFS server. I
like this stuff :-)
But FGFS crashes every time a new user joins the server with an aircraft
which is not in my dir tree. The problem is common to many people who
used this multiplayer mode.
Is there any chance we can get a
On Wed, 9 Jun 2004 17:39:08 -0400
Ampere K. Hardraade wrote:
Could there be a connection between this and the problem pointed out by Dave
in the Air Refueling thread?
There probably is a connection. Actually, to be more precise than in my
last post, it's not the delay itself that causes the
I wouldn't say that multiplayer doesn't work properly, I'd rather say
that it's still in early stages of development. The effect you see is
probably due to the delay due to sending packets across the network. You
see movement of the other aircraft along its axis because you try and
match the
Could there be a connection between this and the problem pointed out by Dave
in the Air Refueling thread?
Regards,
Ampere
On June 9, 2004 02:02 pm, Jorge Van Hemelryck wrote:
I wouldn't say that multiplayer doesn't work properly, I'd rather say
that it's still in early stages of development.
I'm not sure if this is an isolated problem I'm experiencing, or is
every flightgear user (using multiplayer) quietly in denial about the
poor performance of the multiplayer option???
I speak of the jittery, unstable presence of the 'other plane' when
using flightgear on one PC or across the
Gents,
Has anyone tried multiplayer?
I haven't, but wondered if any representation of other a/c was in the property
tree?
Thanks,
Chris.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Chris Horler wrote:
Gents,
Has anyone tried multiplayer?
I haven't, but wondered if any representation of other a/c was in the property
tree?
Not yet, but if the multiplayer code starts using the AIModel code it
will. This hasn't been done and (although I would like to) I don't think
I can
Hello folks,
I have been interested in working on a multiplayer server for
FlightGear. Apparently there is a huge amount of interest in such
a thing, but I haven't found anything functional yet. I did a little
bit of research on what is out there. here's a summary of what I
found, let me
Im not sure if I posted this question once before... well here it goes
again :-D
Using the --multiplay option I've tried having 2 planes fly closely in
formation. My version of flightgear has been changed so that at each
frame, a seperate controlling program (via socket connection) issues a
Hi,
I'm new here. I'm trying to use FlightGear as the core of a distribuited flight
simulator. I've a great problem about the loading of more then one aircraft (I've read
something about it in the developers digest, but I didn't understand much) and the
lack of documentation about multiplayer
* Luca Masera wrote:
I'm new here.
Welcome
I'm trying to use FlightGear as the core of a distribuited
flight simulator. I've a great problem about the loading
of more then one aircraft (I've read something about it in
the developers digest, but I didn't understand much) and
the lack
- Original Message -
From: Gerhard Wesp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 9:29 AM
Subject: Re: [Flightgear-devel] Multiplayer RFC -- wire protocol
spec --preliminary
Unless there are objections, byte order
Unless there are objections, byte order is little endian, and floats
are intel FPU standard (ok -- i'm making it easy on the PCs that will
likely be used to run display clients :)
Is there any specific reason not to use human readable messages (i.e.,
ASCII)?
It's a waste of bandwidth.
I'm pretty much done with the client/server startup handshake -- ready to do
the code at the peer to register active aircraft with the server (active =
aircraft for which this FG peer is responsible for FDM calcs, the protocol
supports the idea of multiple aircraft sharing a single server
John Barrett wrote:
I'm pretty much done with the client/server startup handshake -- ready to do
the code at the peer to register active aircraft with the server (active =
aircraft for which this FG peer is responsible for FDM calcs, the protocol
supports the idea of multiple aircraft sharing a
Erik Hofman wrote:
John Barrett wrote:
I'm pretty much done with the client/server startup handshake -- ready
to do
the code at the peer to register active aircraft with the server
(active =
aircraft for which this FG peer is responsible for FDM calcs, the
protocol
supports the idea of
- Original Message -
From: Erik Hofman [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 4:22 AM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ...
Erik Hofman wrote:
John Barrett wrote:
I'm pretty
- Original Message -
From: John Barrett [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 8:50 AM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ...
- Original Message -
From: Erik Hofman [EMAIL
(if its just the one plane, once I get it to fly multiplayer, my focus will
be to add multiple/AI plane support to the code, so comments towards
achieving that goal will be welcome also)
I think it would make sense to have the server handle any non-human
controlled vehicles. It would keep
John Barrett writes:
when you say null fdm + autopilot -- it doenst appear the null FDM is a
plane at all - wouldnt it make more sense to use the full FDM code with
scripting to drive the existing autopilot code ?? i.e. script sets desired
altitude, heading, speed, limits on pitch yaw roll
- Original Message -
From: Gene Buckle [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 10:48 AM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ...
(if its just the one plane, once I get it to fly
Andy Ross wrote:
Erik Hofman wrote:
I think that needs a bit more thought. Most FDM's are just too heavy
for having a lot of them work together. I think we need a NULL FDM
with autopilot support for that.
Exactly. It seems to me like we're swimming in half-finished
Erik Hofman writes:
I vote for pushing NetworkOLK to the bitkeeper by now.
Yes, I'll second that, with appropriate thanks to Oliver for being the
first one forge his way down that path.
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at'
In the current code -- there is just the single airplane being simulated on
the display ?? or where could I find a list/array of a/c that are being
managed so I can register each plane with the server and have the server
relay updates for all of them ??
Look in the src/ATC directory. There
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 7:51 PM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ...
In the current code -- there is just the single airplane
On 11/12/03 at 8:08 PM John Barrett wrote:
Sounds good -- like most of what I'm looking for is there -- would
definitly
like to look over the code and see how much work to hook it into my
network
setup
Sorry - I thought you were looking for an fdm-autopilot based solution,
else I'd have
Gene Buckle wrote:
Well I feel like a total idiot right now. Everything I'm thinking about
that needs to be done has already had the core done. *slaps forehead*
The entire groundwork has been laid by the contents of the src/Network
directory. The work done for OpenGC stands as a great example
Well I feel like a total idiot right now. Everything I'm thinking about
that needs to be done has already had the core done. *slaps forehead*
The entire groundwork has been laid by the contents of the src/Network
directory. The work done for OpenGC stands as a great example of building
OK, while I'm an avowed lurker, I find that this thread has even more
possibilities
While I certainly want realistic flight performance of A/C to be the
priority (I hope to learn to fly a real plane someday -- probably in my
next life 8-( -- and I'd love it if my FG experience could translate
On Tuesday 11 November 2003 09:46 am, Ima Sudonim wrote:
OK, while I'm an avowed lurker, I find that this thread has even more
possibilities
Wow, is Sudonim our first troll, or have there been others?
Dave
___
Flightgear-devel mailing list
[EMAIL
John Barrett wrote:
Hmm... perhaps the person who was thinking about puting some life on the
ground might like to try shipping first as it might be easier than trying
to follow roads;)
Keep going -- lotsa other things that can be added :)
One issue is consistency of display -- I would say making
John Barrett wrote:
headless would be without any graphical display at all
multiplayer does multiple planes in the scene, but expects the controlling
logic for all but the local plane (none in the case of headless) to be
handled by processes over the network
I would VERY much like to see the
John Barrett [EMAIL PROTECTED] wrote:
What this gets us:
[...]
2. running headless connected to a multiplayer server, the FGFS instance can
handle multiple AI driven planes in the world on behalf of the server,
creating a distributed server environment for larger simulations
[...]
I'd like
Jon Berndt [EMAIL PROTECTED] said:
I would propose that the server be structured so that a purely
civilian/non-combat version could be run. I don't want it to be
possible for some idiot to come and blow me out of the sky when I'm
practicing ILS approaches in my C172 at my local airport.
- Original Message -
From: Erik Hofman [EMAIL PROTECTED]
I'm not sure I like the idea of FlightGear set up as a server. This will
however keeps the code between the server and the client as close as
possible.
I felt there were too many instances where the current simulation code
Gene Buckle [EMAIL PROTECTED] said:
it offensive to even have source code included that discusses in weapon terms,
To me this is absurd to the extreme.
To you maybe. This may not be the proper forum for you to be asserting
judgements like that anyway (see alt.politics.*) :-D
And in case
it offensive to even have source code included that discusses in weapon terms,
To me this is absurd to the extreme.
To you maybe. This may not be the proper forum for you to be asserting
judgements like that anyway (see alt.politics.*) :-D
...with cross-posts to
- Original Message -
From: Gene Buckle [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Monday, November 10, 2003 2:14 PM
Subject: RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
it offensive to even have source code included
On Monday, 10 November 2003 21:14, Gene Buckle wrote:
BTW, I know a group of virtual F-16 drivers that would practically wet
themselves over software they could use to drive their cockpits with. :)
Falcon 4.0 doesn't go far enough with their data exports.
I like the idea of FlightGear being
Gene Buckle writes:
I guess my problem is that I'm totally unable to understand why
someone would object to just the _presense_ of munitions code even
being present. It completely baffles me. Even as I sit here
pondering the why, all I can come up with is pejorative commentary
and that's
Gene Buckle writes:
I read the whole post. Really! :)
Hey Gene since I am the one who initially brought up the issue
I guess you are the one responsible for my ears burning :-)
However note I never objected to the presence of munitions in FlightGear.
On Monday, 10 November 2003 21:14, Gene Buckle wrote:
BTW, I know a group of virtual F-16 drivers that would practically wet
themselves over software they could use to drive their cockpits with. :)
Falcon 4.0 doesn't go far enough with their data exports.
I like the idea of FlightGear
- Original Message -
From: Gene Buckle [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Monday, November 10, 2003 3:40 PM
Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Monday, 10 November 2003 21:14, Gene Buckle wrote
Hey Gene since I am the one who initially brought up the issue
I guess you are the one responsible for my ears burning :-)
Wasn't me. I'd chase down the guy with the matches. :)
What I *was* objecting to and *will* continue to object to is a 'primary goal'
of 'blow them out of the sky'
I think a dynamic shared library system that lets an a/c load up a module of
its particular code when it is loaded needs to be added to the system -- be
a nice place to stick information unique to that plane that is dynamic in
nature -- can handle specialized panel displays, hud, etc
In
On Monday, 10 November 2003 22:40, Gene Buckle wrote:
Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need
it. *g*
Not sure if you're just kidding or serious ...
There's plenty of free C++ info online but here are a couple of free books :
Bruce Eckel's Thinking in C++, 2nd
Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need
it. *g*
Not sure if you're just kidding or serious ...
There's plenty of free C++ info online but here are a couple of free books :
Thanks Paul. I pay my mortage with Delphi, VB Pick. My C/C++ skills
are just
Gene Buckle writes:
Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need
it. *g*
Not sure if you're just kidding or serious ...
There's plenty of free C++ info online but here are a couple of free books :
Thanks Paul. I pay my mortage with Delphi, VB Pick. My
On Monday, 10 November 2003 23:40, Gene Buckle wrote:
Thanks Paul. I pay my mortage with Delphi, VB Pick. My C/C++ skills
are just enough to be able to identify it on sight and begin running the
other way. :)
I also come from a Delphi background but find the switch very easy.
Both support
- Original Message -
From: Gene Buckle [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Monday, November 10, 2003 4:29 PM
Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
I think a dynamic shared library system that lets an a/c
Thanks Paul. I pay my mortage with Delphi, VB Pick. My C/C++ skills
are just enough to be able to identify it on sight and begin running the
other way. :)
Sounds like you need a varient of the following t-shirt (credit to
Mark Barry.)
I also come from a Delphi background but find the switch very easy.
Great! I'll help you write the server in Delphi. We can cross compile
with FPC. *laughs*
Why does C++ scare you?
Well scare is probably too strong a word. :) I'm just unfamiliar with
it. I can follow C ok, but the object
a nice place to stick information unique to that plane that is dynamic
in
nature -- can handle specialized panel displays, hud, etc
In that case, some kind of framework should be built so that the plug-in
could run on a seperate machine if needed.
um ?? for code/data local to
- Original Message -
From: Gene Buckle [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Monday, November 10, 2003 5:37 PM
Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
a nice place to stick information unique to that plane
um ?? for code/data local to an a/c instance ?? remoting that would slow
down the response time to realtime events
For virtual cockpits, you're correct. however, when you're working with a
physical cockpit, you need to have your displays on separate physical
hardware.
If the
- Original Message -
From: Gene Buckle [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Monday, November 10, 2003 6:19 PM
Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
um ?? for code/data local to an a/c instance ?? remoting
I'm just getting back into rooting around in the code and I don't yet have
a solid grasp on all the parts. AFAIK, the only native support for an
external module is OpenGC from what I've seen so far. I was referring the
creation of a universal method of obtaining data from the sim via
Gene Buckle [EMAIL PROTECTED] said:
And in case someone didn't read my earlier post, I do not hold this opinion
myself, but I do think that a topical RFC should be posted before any war
related code is committed, even with a configuration flag. This _is_ a hot
button whether anyone
Gene Buckle wrote:
Paul Surgeon wrote:
Why does C++ scare you?
Well scare is probably too strong a word. :) I'm just unfamiliar
with it. I can follow C ok, but the object references tangle me for
some odd reason.
If C++ doesn't scare you, you have no business using it.
Sorry, but that
If C++ doesn't scare you, you have no business using it.
Sorry, but that was just too open. I had to take the shot. But
seriously, there's more truth in that statement than a sarcastic
retort like it deserves. The time to run screaming from a project is
the moment the architect declares
If you start a project and need OO features, either do it properly (in
Python or Objective-C), or do it the hard way with GLib/GObject.
Naw, Object Pascal is my first love. :)
I'd better shut up on the mailing list of a giant project written in
C++... I still admire you folks for getting it
http://www.camelot-software.com/fgfs/fgmps.tar
Here is the patch and source files for the preliminary wire protocol
implementation -- comments and suggestions welcome -- untar in the directory
containing the FGFS source directory, apply the patch, autogen,
configure --with-multiserver, and make
John Barrett wrote:
At the moment, I'm planning to build in my own socket classes to handle the
net connections, as they are designed to handle multiple connections in a
polling environment -- unless someone can point me at existing code in FG /
SimGear / PLib thats up to handling multiple socket
John Barrett writes:
At the moment, I'm planning to build in my own socket classes to handle the
net connections, as they are designed to handle multiple connections in a
polling environment -- unless someone can point me at existing code in FG /
SimGear / PLib thats up to handling multiple
- Original Message -
From: Norman Vine [EMAIL PROTECTED]
PLib/src/net is a 'reasonably' efficient implementation of using
polling in a multiple connection environment :-)
The 'loop' is in netChanel.cxx
SimGear sockets and are built ontop of PLib/Net as is the FGFS
http server,
John Barrett writes:
From: Norman Vine [EMAIL PROTECTED]
PLib/src/net is a 'reasonably' efficient implementation of using
polling in a multiple connection environment :-)
Guess I have enuf to do the server framework and initial handshake between
client and server
Might want to ask any
John Barrett wrote:
Here is the patch and source files for the preliminary wire protocol
implementation -- comments and suggestions welcome
This sounds fun, so I grabbed it and had a peek. One bug report in
messagebuf.cxx, which has some code that I can't figure out:
void
- Original Message -
From: Andy Ross [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Sunday, November 09, 2003 11:59 AM
Subject: Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
John Barrett wrote:
Here is the patch and source files
- Original Message -
From: Norman Vine [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Sunday, November 09, 2003 11:58 AM
Subject: RE: [Flightgear-devel] Multiplayer -- wire protocol implementation
John Barrett writes:
From: Norman Vine [EMAIL
Jonathan Richards writes:
What I value about FlightGear is that it attempts to *simulate* the
real world
and aviation in it. The landscapes and the airports are realistic, the
weather is (can be made) realistic, the celestial objects are realistic, the
flight dynamics themselves are
I would propose that the server be structured so that a purely
civilian/non-combat version could be run. I don't want it to be
possible for some idiot to come and blow me out of the sky when I'm
practicing ILS approaches in my C172 at my local airport.
I guess there ought to be an explicit
- Original Message -
From: Curtis L. Olson [EMAIL PROTECTED]
I would propose that the server be structured so that a purely
civilian/non-combat version could be run. I don't want it to be
possible for some idiot to come and blow me out of the sky when I'm
practicing ILS approaches
John Barrett writes:
Would a --no-combat option on the server be acceptable ??
(i.e. someone can pull the trigger, but it wont do anything to the
multiplayer world -- they could still use you for a target, but you would
never see the ordinance)
That sounds reasonable. I would add the
John Barrett writes:
Would a --no-combat option on the server be acceptable ??
(i.e. someone can pull the trigger, but it wont do anything to the
multiplayer world -- they could still use you for a target, but
you would
never see the ordinance)
That sounds reasonable. I would add
- Original Message -
From: Jon Berndt [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Sunday, November 09, 2003 4:24 PM
Subject: RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
John Barrett writes:
Would a --no-combat option
- Original Message -
From: Curtis L. Olson [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Sunday, November 09, 2003 4:16 PM
Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
John Barrett writes:
Would a --no-combat option
1 - 100 of 232 matches
Mail list logo
