Hi everybody
I'd like to hear thoughts from the FG community about setting up a system to
perform builds execute a suite of tests on FlightGear, all automatically.
Right now I've experimented a bit with buildbot, a neat continuous
integration tool used by Mozilla and other projects, and I have
On Tue, 4 Aug 2009 00:00:39 -0700, Tom wrote in message
c9e106b9090804l27fef105g5b047571a6c75...@mail.gmail.com:
Hi everybody
I'd like to hear thoughts from the FG community about setting up a
system to perform builds execute a suite of tests on FlightGear,
all automatically.
Right
Are we talking about validating the build process and checking that FG runs,
or about checking the validity of the simulation?
For the former the suggested buildbot , or similar, approach, perhaps with
a very simple autopilot guided flight, would be adequate.
Simulation validity checking
Jon S. Berndt wrote:
Erik Hofman wrote:
Apperently this was needed to compile with MSVC 9 (patch was added by
Fred twice). I probably should have made a test build before
committing
to CVS.
Which wouldn't have revealed the problem.. it might get picked up at
another location for me.
I'd
Hi all,
shape-decode has been crashing on me for a certain shapefile and I can
not figure out why. I am using terragear-cs downloaded today from the
GIT repository. The rest of the toolchain runs fine.
shape-decode runs for a while and stops with the following error:
[...]
distance = 239.828
On Tue, Aug 4, 2009 at 8:11 AM, Maxime Guillaud m...@mguillaud.net wrote:
Hi all,
shape-decode has been crashing on me for a certain shapefile and I can
not figure out why. I am using terragear-cs downloaded today from the
GIT repository. The rest of the toolchain runs fine.
shape-decode
Curtis Olson wrote:
A bucket coordinate of -593:2 suggests that this shapefile may contain
some bogus data. (or there could be a bug leading up to this) but I
believe the portion prior to the : represents a whole degree
coordinate of the bucket, so this should range from -180 to +179 for
On Monday 03 Aug 2009, Curtis Olson wrote:
I'll toss in a couple thoughts. Running on 4 processors
(quad-core AMD 64 bit machine) and 4 dual-head nvidia cards we
split the render task up into a bunch of subthreads. The overall
CPU load was pretty balanced and each CPU ran at about 40-60%
On Tue, Aug 4, 2009 at 11:05 AM, leee l...@spatial.plus.com wrote:
That's interesting. Could you elaborate on that a little more i.e.
did you split a single scene into 'render boxes' or were you, in
effect, running four discrete but 'collaborative' instances, each
just looking in a different
On Tue, 4 Aug 2009, leee wrote:
One of the big problems I had with FG was its pseudo asynchronous
operation, which still meant that the rates at which you could run
things like the FDM, autopilot and Nasal were effectively limited
by the frame rate and which could lead to an aircraft being
On Tuesday 04 Aug 2009, Curtis Olson wrote:
On Tue, Aug 4, 2009 at 11:05 AM, leee l...@spatial.plus.com
wrote:
That's interesting. Could you elaborate on that a little more
i.e. did you split a single scene into 'render boxes' or were
you, in effect, running four discrete but
Anders Gidenstam wrote:
IMHO the one important threading benefit is if we could get all of the
rendering off the main simulation loop, meaning that the model runs
independent of the presentation. (Ok, expensive environment eye candy
like the traffic manager or wild fire CA would also be
leee wrote:
I'm not really thinking in terms of 'threading' at all, which I
think is a very limited and half-house sort of technique. But
neither though do I think it needs to be thought of as a pure real
time system. Rather, I'm thinking in terms of the external FDM
mechanism
Hi,
I am currently playing with the input subsystem. This was triggered because I
have two devices that currently do not work with FlightGear, neither Linux nor
Windows.
1. A set of rudder pedals that does not get recognized as a joystick from
joydev, because it reports it's axes as RX,RY and
Hi Curt
That's very advanced stuff about FAA simulator certification tests and
testing all aspects of flight dynamics.
As a starter, I was thinking about something simpler than validating the
accuracy of the flight models.
And yes, it cannot be just a script replaying a sequence of commands
Hi Torsten,
Hi,
I am currently playing with the input subsystem. This was triggered because I
have two devices that currently do not work with FlightGear, neither Linux
nor
Windows.
1. A set of rudder pedals that does not get recognized as a joystick from
joydev, because it reports
On Tuesday 04 August 2009 19:54:23 Torsten Dreyer wrote:
I am currently playing with the input subsystem. This was triggered because
I have two devices that currently do not work with FlightGear, neither
Linux nor Windows.
My idea is to extend the FGInput class so it can use the devices
Hi Alan
The initial objective is to validate the build process and perform basic
checks on a running FG.
Checking the accuracy of the simulation, especially from the point of
view of flight models, is beyond the scope at this point, but it's not
impossible once the test infrastructure
I Just found out that my notebook's lid switch is an input device:
I: Bus=0019 Vendor= Product=0005 Version=
N: Name=Lid Switch
P: Phys=PNP0C0D/button/input0
S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input5
U: Uniq=
H: Handlers=event5
B: EV=21
B: SW=1
So - FlightGear now
That's very clever! No complaints from my end if you want to pursue this.
I suspect this would open up FlightGear to a lot of new and interesting
input hardware, and I bet many cockpit builders would welcome generic HID
support.
Regards,
Curt.
On Tue, Aug 4, 2009 at 3:37 PM, Torsten Dreyer
20 matches
Mail list logo
