Martin Spott wrote:
Just my personal view,
Please forgive me all those typos, it's a bit early in the morning,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
On Mon, Nov 22, 2004 at 02:55:15PM -0600, Curtis L. Olson wrote:
What's wrong with network byte order?
Nothing, I guess. Doesn't define floating point representation, though.
What's wrong with ASCII?
Cheers
-Gerhard
___
Flightgear-devel mailing
So, one would really need to define a corresponding network
interface.
This does already exist and is specified in the ``400/500 Series Flight
Sim ICD.'', a proprietary Garmin document. It describes the RS232
interface of their _hardware_ simulator units. I guess Bill Stone would
give it to
Vivian Meazza wrote:
Dale E. Edmons wrote
[EMAIL PROTECTED] wrote:
Hi, all,
I encountered a compile error when make the simgear-0.3.7 for
FlightGear-0.9.6. I am working with Cygwin in windows 2000 and I have
plib and Zlib done.
... snip ...
Got to /etc/ld.so.conf and see if it
Gerhard Wesp wrote:
On Mon, Nov 22, 2004 at 02:55:15PM -0600, Curtis L. Olson wrote:
What's wrong with network byte order?
Nothing, I guess. Doesn't define floating point representation, though.
Ah, this gives me a hint. There are functions called htond() and htonf()
in the following files
When Curt introduced OpenAL to fgfs, he wrote[1]:
| 2. The plib sound system was set to play at 8000 hz no matter what the
| sample was recorded at. So a 22000 hz sample wouldn't play at the right
| pitch by default. We compensated in our sound config files for this by
| offsetting the pitch
On Tuesday 23 November 2004 01:16, Alex Perry wrote:
From: Boris Koenig [EMAIL PROTECTED]
David Megginson wrote:
I understand
that there are USB devices that you can wear on your head to control
the view in games, and those would probably work in FlightGear, but it
would be hard to
* Melchior FRANZ -- Tuesday 23 November 2004 13:20:
(I remember that I changed the wind pitch in the bo105 sound config,
but this would then only be an ugly workaround.)
Too humble. Actually, this would have been a correct fix. It's just the
question if I go the new numbers right. And if all
* Roy Vegard Ovesen -- Tuesday 23 November 2004 13:41:
I've attached a patch to mice.xml that lets you move the camera/viewport with
the middle mouse button pressed in mouse view mode. Useful for looking at the
compass head on.
Very cool. There are two problems, though: I can move my 'head'
On Tue, 23 Nov 2004 09:50:14 +0100, Gerhard wrote in message
[EMAIL PROTECTED]:
So, one would really need to define a corresponding network
interface.
This does already exist and is specified in the ``400/500 Series
Flight Sim ICD.'', a proprietary Garmin document. It describes the
Gerhard Wesp wrote:
So, one would really need to define a corresponding network
interface.
This does already exist and is specified in the ``400/500 Series Flight
Sim ICD.'', a proprietary Garmin document. It describes the RS232
interface of their _hardware_ simulator units. I guess Bill Stone
From: Lee Elliott
On Thursday 18 November 2004 21:03, Martin Spott wrote:
Lee Elliott wrote:
um, yes - the TSR-2 probably isn't the best a/c for carrier
stuff. The FDM needs really an overhaul because the
take-off performance isn't right - it currently lifts off at
a lower speed
On Tuesday 23 November 2004 14:18, Melchior FRANZ wrote:
* Roy Vegard Ovesen -- Tuesday 23 November 2004 13:41:
I've attached a patch to mice.xml that lets you move the camera/viewport
with the middle mouse button pressed in mouse view mode. Useful for
looking at the compass head on.
Very
* Roy Vegard Ovesen -- Tuesday 23 November 2004 15:51:
I only tested it in the default cessna where max and min limits of 0.5 meters
from the origin seemed reasonable, you can imagine what happened when I tried
the A320 where the initial y-offset is way above 0.5 meters :-(. Perhaps the
* Roy Vegard Ovesen -- Tuesday 23 November 2004 15:51:
I only tested it in the default cessna where max and min limits of 0.5 meters
from the origin seemed reasonable,
Should have tried the FA-18A. Completely unusable there. You immediately
end up between the pilot's legs and there's no way to
On Tuesday 23 November 2004 16:30, Melchior FRANZ wrote:
Should have tried the FA-18A. Completely unusable there. You immediately
end up between the pilot's legs and there's no way to get back up. But can
go further down and watch the scenery through the open front wheel bay.
Resetting fgfs
Melchior FRANZ writes:
* Melchior FRANZ -- Tuesday 23 November 2004 17:14:
I'm volunteering already
No, I take that back. Mouse properties are (like kbd * js bindings)
fixed at the beginning. min/max can't easily be changed afterwards,
and I don't feel like re-writing the whole input
On Tuesday 23 November 2004 17:31, Boris Koenig wrote:
I haven't yet really played with 3D cockpits: what exactly would be
involved in adding such support ?
The support is already there: it is possible to set the view position at
runtime through the /sim/current-view/{x,y,z}-offset-m
* Norman Vine -- Tuesday 23 November 2004 18:19:
* * Melchior FRANZ writes:
Mouse properties are (like kbd * js bindings)
fixed at the beginning. min/max can't easily be changed afterwards,
and I don't feel like re-writing the whole input module. Better set
the default to +/- 5m.
Can't
On Tuesday 23 November 2004 18:05, Melchior FRANZ wrote:
No, I take that back. Mouse properties are (like kbd * js bindings)
fixed at the beginning. min/max can't easily be changed afterwards,
and I don't feel like re-writing the whole input module. Better set
the default to +/- 5m.
You can
Roy Vegard Ovesen wrote:
On Tuesday 23 November 2004 17:31, Boris Koenig wrote:
I haven't yet really played with 3D cockpits: what exactly would be
involved in adding such support ?
The support is already there: it is possible to set the view position at
runtime through the
Roy Vegard Ovesen wrote:
On Tuesday 23 November 2004 18:05, Melchior FRANZ wrote:
No, I take that back. Mouse properties are (like kbd * js bindings)
fixed at the beginning. min/max can't easily be changed afterwards,
and I don't feel like re-writing the whole input module. Better set
the default
On Tuesday 23 November 2004 19:46, Boris Koenig wrote:
I think it was Melchior who mentioned that the min/max values are
specific to certain aircrafts or rather cockpits ?
Taking into consideration that the a3c files are plain text and hence
readable for simple shell scripting, I wonder now
On Tuesday 23 November 2004 00:16, Alex Perry wrote:
From: Boris Koenig [EMAIL PROTECTED]
David Megginson wrote:
I understand
that there are USB devices that you can wear on your head
to control the view in games, and those would probably
work in FlightGear, but it would be hard to
On Monday, 22 November 2004 22:37, Boris Koenig wrote:
David Megginson wrote:
I understand
that there are USB devices that you can wear on your head to control
the view in games, and those would probably work in FlightGear, but it
would be hard to survive the ridicule from family,
On Tuesday 23 November 2004 19:55, Melchior FRANZ wrote:
Sure, but that's yet another ugly hack. I'd prefer a *solution*. I don't
use a standard mice.xml, and I would really hate if every aircraft designer
messes with mouse settings and overwrites my stuff. What's next? Aircrafts
overwriting
* Roy Vegard Ovesen -- Tuesday 23 November 2004 20:39:
I really thought that overriding defaults from preferences.xml was a good
solution. *-set.xml is used to override all kinds of other stuff, including
keyboard and joystick settings, so why not override mouse settings too!?
Aircrafts
On Tuesday 23 November 2004 13:59, Richard Bytheway wrote:
From: Lee Elliott
On Thursday 18 November 2004 21:03, Martin Spott wrote:
Lee Elliott wrote:
um, yes - the TSR-2 probably isn't the best a/c for
carrier stuff. The FDM needs really an overhaul because
the take-off
Here are my suggestions:
In the aircraft's directory (meaning directory such as
$FG_ROOT/data/Aircraft/MD11/), there should be a directory named textures
where all the textures for that aircraft reside. This should allow the
aircraft's home directroy to stay organized as more liveries are
Hi Folks,
Following up on Curt's question about the aircraft directory layout, I would
like to bring up a slightly different but related issue, that of aircraft
models for use in AI traffic.
Over the past summer, we've had to deal with many inconsistencies that were
related to the AI traffic
Durk Talsma wrote:
[...]
For this and other reasons, I'm currently leaning toward favoring having a
separate set of low-polygon count models for AI aircraft. The basic idea
would then be to have a directory looking like this:
data/Aircraft/AI/
I like the idea of having such a low-polygon
31 matches
Mail list logo
