Yes and no. The NATO/USAFE E3Bs should have TF33-PW-100 engines
producing 21000 lbs thrust(1), not JT3D engines which produce 18000 lbs
thrust. The JT3D engine is used on the 707-320B (2) which is the basis
of the E3B. An RAF, FAF or RSAF E3B should be using CFM56 turbofans
producing 24000 lbs t
On Monday 14 May 2007 04:38, Stuart Buchanan wrote:
> If what you are suggesting is that to use MP, we will have to run the FDM
> on a server and accept a much lower refresh rate on the client, then I
> don't think that is acceptable as it will make the civil MP experience
> much worse.
This isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Howdy,
This patch implements the option of using OpenSceneGraph's osgViewer
instead of SDL or glut. The major user visible difference is the
availability of OSG statistics, as seen in
http://www.bricoworks.com/moore/osgstats.png, which show the time sp
Hi,
the discussions ended that it would be nice to have texture filtering a
property which can be controlled by a commandline parameter. Experiments
showed that not only runways, but scenery textures will profit very much.
Included are patches to SimGear, FlightGear and data (for help).
IMHO
On Sunday 13 May 2007, Jonathan Wagner wrote:
> Maik,
>
> These are not "dogfight-only" problems. These are multiplayer problems
> which currently are not addressed well in the current multiplayer
> implementation. On the public servers with high latency, multiplayer
> flight can be choppy as a p
The E3B engines are currently defined as having a thrust of 18000 Lbs. A
google search indicates that the per engine thrust should be 21000 Lbs.
If this is verified as being true, the attached patch should correct the
associated E3B/Engines/JT3D.xml file.
--
Reagan Thomas
? E3B.diff
? E3B.ta
On Sunday 13 May 2007, Ampere K. Hardraade wrote:
> On Sunday 13 May 2007 13:18, Harald JOHNSEN wrote:
> > If the server does the fdm 100 times per second and send the data 10
> > times per second it's like if the client was running the fdm at 10 hz.
> > That's why I said it's not needed to run the
On Sunday 13 May 2007, Bill Galbraith wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Stefan Seifert
> > Sent: Saturday, May 12, 2007 10:38 PM
> > To: FlightGear developers discussions
> > Subject: Re: [Flightgear-devel] More ideas on
On Friday 11 May 2007, Gene Buckle wrote:
> The problem is one of network latency. This has been a major hurdle for
> games like Aces High, Air Warrior and WWII Online. The server should
> handle the collision to avoid situations where the shooter client sees a
> hit and the shootee client doesn'
Hi,
On Friday 11 May 2007, Martin Spott wrote:
> "Vivian Meazza" wrote:
> > Well, as the Irish would say, if you want to get there, you don't want to
> > start here. Good luck. And if you want to see how much work would be
> > involved, compare that task with the cutover to osg - now 6 months old
Hi,
On Saturday 12 May 2007, Ampere K. Hardraade wrote:
> While development over the past few years might give the preception that
> Flightgear is a game, Flightgear is actually meant to be a serious flight
> simulator. Things that go boom are cool in games, but they are also
> useless; more so
Looking at the replies posted up to now on "New Architecture for
Flightgear" and at the "More ideas on dogfighting" postings it seems to
me that a crucial common item is "inter process communications" or IPC.
There seems to be three main scenarios:
a) Flight gear running modular on a multiprocess
Hi all,
I use the property "sim/time/elapsed-sec" in the S76C to calculate fuel flow as
there is no helicopter engine yet ... and noticed a very inconsistant
behavior... dont know if its related to the 'framerate hesitation' problem ...
but would like to know if anyone else sees the 'un-smooth'
Since today there's a function systime() available. It returns
the Unix Epoch time in seconds. Even if that doesn't tell you much,
it's very useful for benchmarking:
var start = systime();
how_fast_am_I(123);
var end = systime();
print("took ", end - start, " seconds");
The function h
You guys might want to give this a read. I found it helpful as an
introduction when I was looking at this multiplayer stuff a few years ago:
http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html
Because of their "fast-paced" competitive nature, First Person Shooters have
extremely ti
On 5/14/07, Martin Spott wrote:
which appears now to have started. If nobody objects, then I'll go
ahead putting the current Airport and Navaid stuff into the base
package,
Double check there isn't any x-plane 8.50 bezier stuff in the version we use
since we really aren't setup to use th
"Curtis Olson" wrote:
> On 5/9/07, Martin Spott <[EMAIL PROTECTED]> wrote:
> >
> > Stuart Buchanan wrote:
> >
> > > Major Changes
> > > =
> > [...]
> > > Airport runway and taxi signs
> >
> > This reminds me of something related:
> >
> > For my taste it's time to put an update to the ai
Stuart Buchanan wrote:
> --- Melchior FRANZ wrote:
> > Maybe the changelog should be on the wiki for fixes/extensions?
>
> An excellent use of the wiki - done. I've merged the data and simgear logs
> together here along with the feedback I've seen so far:
>
> http://wiki.flightgear.org/flightgear
On 5/10/07, Stuart Buchanan wrote:
--- Melchior FRANZ wrote:
> Maybe the changelog should be on the wiki for fixes/extensions?
An excellent use of the wiki - done. I've merged the data and simgear logs
together here along with the feedback I've seen so far:
http://wiki.flightgear.org/flightge
Hi James,
"James Palmer" wrote:
> If it is overly burdensome on framerate due to latency, I see no reason why
> a server cannont support both architectures (single and split).
[...]
> -As I investigate this proposed architecture, I plan to avoid splitting the
> FG world. I do plan to allow easy
On 5/14/07, Bill Galbraith wrote:
If I remember correctly, the human eye can detect something less than
about
15-20 fps.
The number that comes to my mind is about 22? Movies that you'd see in a
theater run at 24 fps I believe.
One aditional element though that is *critical* is that this has
Removed leading slashes from gear properties.
Didn't have a chance to try it yet.
Greets,
Csaba
Index: data/Aircraft/747/Models/boeing747-400-jw.xml
===
RCS file:
/var/cvs/FlightGear-0.9/data/Aircraft/747/Models/boeing747-400-jw.xml
Sometime ago my radar patch introduced a "valid" property to ai models.
Attached patch updates the code drawing the HUD target circles to test
this flag so that invalid entries don't get displayed.
Thanks to AnMaster for reporting and testing.
Greets,
Csaba
Index: src/Instrumentation/HUD/HUD_lad
On Mon 14 May 2007 16:18, Martin Spott wrote:
> Emmanuel,
>
> Markus Zojer wrote:
> > I really enjoy the flight with this plane, especially the <110kts
> > landings :-)
> >
> > I noticed, that the sim model is not in sync with the 3d model, so I
> > changed Models/c130.xml to
> >
> > c130.ac
> >
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Ralf Gerlich
> Sent: Monday, May 14, 2007 10:23 AM
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] More ideas on dogfighting
>
> Hi,
>
> Gene Buckle wrote:
> >>> Martin
Hi,
Gene Buckle wrote:
>>> 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 exp
Emmanuel,
Markus Zojer wrote:
> I really enjoy the flight with this plane, especially the <110kts
> landings :-)
>
> I noticed, that the sim model is not in sync with the 3d model, so I
> changed Models/c130.xml to
>
> c130.ac
>
> 17.0 (was 0)
> 0.0
> -2.8
>
>
> of cour
> > 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 wou
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 t
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
--- Jonathan Wagner wrote:
> These are not "dogfight-only" problems. These are multiplayer problems
> which currently are not addressed well in the current multiplayer
> implementation. On the public servers with high latency, multiplayer
> flight can be choppy as a plane in your view "magical
31 matches
Mail list logo