Mathias Fröhlich wrote :
On Sonntag 27 November 2005 13:14, Frederic Bouvier wrote:
Why not installing an X11 error handler to trap this instead of letting the
default handler simply exiting ?
Well, ist this possible?
I was very excited about that idea, but found in the documentation
There is a Win32 binary that include the KLN89 here :
ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-win32-20051130.zip
As always, it needs a matching base package ( same date ) that you can
get via CVS.
-Fred
___
Flightgear-devel mailing
Carsten Hoefer wrote:
BTW: How do I play sounds by Nasal scripts?
The same way one would do animations using Nasal;
Adjust properties in Nasal (they may be private properties in your own
subtree of the property list, say /tmp/aircraft) and let the sound
configuration file act on those
Joacim Persson wrote:
On Thu, 1 Dec 2005, David Luff wrote:
I have no experience of plugin architectures, and don't feel competent to
attempt it at the moment.
First of all: there's obviously no panic. (If there were fifty-seven
hard-linked GPS models, AP's etc it would be a problem, ;)
On Wed, 2005-11-30 at 16:55, Jon Stockill wrote:
Steve Hosgood wrote:
3) It was broken in 0.9.8 but is fixed now. I *think* I may have tried
it in 0.9.9 with the same results. Not sure. Can't check right now.
It'll still be the same. The C172 doesn't use the generic autopilot code
- it
On Wed, 2005-11-30 at 20:25, Steve Knoblock wrote:
It'll still be the same. The C172 doesn't use the generic autopilot code
- it has a KAP140 autopilot model - which is controlled by clicking the
buttons on the device in the cockpit.
This confusion will raise its head every time a person
--- Steve Hosgood wrote:
snip
I propose then that every single instrument on the cockpit has the
ability to be double-clicked, and if so then a separate draggable window
appears containing a magnified view of that same instrument.
Hi Steve,
Personally I think this is a fine idea, and
Steve Hosgood writes:
Makes me wonder whether there's an excuse for some new thinking on the
subject of UI design, regardless of whether a cockpit is 3D or 2D.
Here's what I propose - please be kind with your comments, I'm not
trying to dictate terms or tread on anyone's toes:
Flightgear
Flightgear (and any other flight sim) is trying to reproduce the
experience of flying, both in terms of the flight dynamics and (to a
limited extent) the whole experience.
As such, many of the instruments in the virtual cockpit can be
configured with mouse-clicks on the instruments
I just struck me that it's already possible to get a better look at the
instruments, both 2D and 3D, in a very simple way: I think all OS's and
windowmanagers have a magnifier tool. It can't magnify beyond the screen
resolution of course (640x480 would still be 640x480), but it solves the
problem
Steve Hosgood wrote:
Makes me wonder whether there's an excuse for some new thinking on the
subject of UI design, regardless of whether a cockpit is 3D or 2D.
Here's what I propose - please be kind with your comments, I'm not
trying to dictate terms or tread on anyone's toes:
I propose
I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box.
Unfortunately,
now OpenGL apps give an application error - they don't even start up. I'm
trying to get
some answers out of the card and driver manufacturer, but if anyone here has any
suggestions, I'd appreciate hearing
On Thursday 01 December 2005 09:48, Steve Hosgood wrote:
I knew there was an autopilot on the cockpit display, but on my monitor
at home (1024x768) it was a bit difficult to read.
This is a problem for many instruments in many a/c - on higher resolution
screens too. The solution is to make
On Thu, 2005-12-01 at 11:52, Norman Vine wrote:
I agree that it would be nice to have all instruments etc have interactive
interfaces ala a mouse click, if that is at all realistic, but this does not
necessarily
mean that the dialog boxes should go.
[Flightgear has] a much broader vision
On Thu, 2005-12-01 at 11:56, Buchanan, Stuart wrote:
I propose then that every single instrument on the cockpit has the
ability to be double-clicked, and if so then a separate draggable window
appears containing a magnified view of that same instrument.
Personally I think this is a fine
I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box.
Unfortunately,
now OpenGL apps give an application error - they don't even start up. I'm
trying to get
some answers out of the card and driver manufacturer, but if anyone here has any
suggestions, I'd appreciate hearing
I just installed a new video card (eVGA GeForce 6800) on my Windows
2000 box and after installing the drivers I find that OpenGL
applications crash. I've uninstalled (in safe mode) and reinstalled
(in safe mode) earlier versions of the drivers, but no luck, so far. I
am trying to find the
On Thu, 2005-12-01 at 14:15, Josh Babcock wrote:
Just as a note, this functionality already exists. You can use the mouse
to look around and zoom in. Zoom in, click, zoom out. I do it all the time.
That's a very good trick (just tried it). Never thought of that one, and
yes, I can even read
Jon Berndt wrote:
I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box.
Unfortunately,
now OpenGL apps give an application error - they don't even start up. I'm
trying to get
some answers out of the card and driver manufacturer, but if anyone here has any
suggestions, I'd
Jon Berndt writes:
I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box.
Unfortunately,
now OpenGL apps give an application error - they don't even start up. I'm
trying to get
some answers out of the card and driver manufacturer, but if anyone here has
any
Use the latest drivers from the chipset manufacturer's website (nVidia
or ATI). The card manufacturers have been known to optimise the
drievrs that they ship on the CD.
Richard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jon S Berndt
Sent: 01
windowmanagers have a magnifier tool. It can't magnify beyond the screen
resolution of course (640x480 would still be 640x480), but it solves the
problem with blurred tiny characters on small weathered monitors, like
is it not the same effect as if the characters are rendered w/o
antialiasing?
Steve Hosgood writes:
Agreed, but if we've got a better scheme, why keep the dialog boxes?
Every disjoint aspect to the GUI is just another thing waiting to go
wrong, as with the Cessna autopilot where the dialog box is invisibly
disconnected from the real autopilot.
Steve
Apparently I
Norman Vine wrote:
Steve Hosgood writes:
Agreed, but if we've got a better scheme, why keep the dialog boxes?
Every disjoint aspect to the GUI is just another thing waiting to go
wrong, as with the Cessna autopilot where the dialog box is invisibly
disconnected from the real autopilot.
So I'm unsure if it is a good idea to include those patches.
They are harmless, but according to what Melchior has pointed out, some of
the code (what I added to the exceptions classes) is redundant (basically,
what is written there is auto-generated by the compiler unless it has
problems).
On Thursday 01 December 2005 11:12, Erik Hofman wrote:
Joacim Persson wrote:
On Thu, 1 Dec 2005, David Luff wrote:
I have no experience of plugin architectures, and don't feel competent
to attempt it at the moment.
First of all: there's obviously no panic. (If there were fifty-seven
Ralf Gerlich wrote:
Heh, I'd like to see you looking at the Autopilot _and_ out of the
window in a real plane. ;-)
As was mentioned, the nearest you could come to the flow in the
cockpit IRL - not looking at the instrument and still changing its
setting - is probably using the keyboard...at
On Wed, 30 Nov 2005 21:27:15 -0600, you wrote:
aircraft (like GPS in MSFS). Given that the wiring can be potentially
different with each aircraft, the autopilot code may need customizing
each time it is placed on a panel.
Ideally the instruments will be as multi-usable as possible, and
I've been short of time recently, but Curt is keen on getting the
twist/incidence fix into YASim in time for the next release. So I've
committed it more or less blind. :)
A quick grep through the source code gives a list of affected aircraft
configurations that I've attached below. The fix is
Curtis L. Olson wrote:
Ralf Gerlich wrote:
Heh, I'd like to see you looking at the Autopilot _and_ out of the
window in a real plane. ;-)
As was mentioned, the nearest you could come to the flow in the
cockpit IRL - not looking at the instrument and still changing its
setting - is
John Wojnaroski wrote:
One of the knocks from the May show ( which is totally my fault) was
the cheezy joystick. So here we were with a full scale 747 glass
cockpit with a large screen plasma OTW display running top of the line
flight dynamics (JSBSim), world class scenery (FlightGear), high
From: AJ MacLeod
Last night (using completely up-to-date CVS) I noticed that fgfs segfaults
reliably if one relocates the a/c to KOAK using the position a/c on ground
menu.
After a bit more investigation, it appears that this is caused by a nan in
the
yasim turbulence stuff,
On Thursday 01 Dec 2005 21:08, Andy Ross wrote:
I've been short of time recently, but Curt is keen on getting
the twist/incidence fix into YASim in time for the next
release. So I've committed it more or less blind. :)
A quick grep through the source code gives a list of affected
aircraft
From what I'm seeing, the Saitek X45 is almost identical to the Saitek
X36
joystick.
I own both of them and the only differences I'm seeing (from just
looking
at them) is the X45 has a candy blue decals along with more fancy red
lights.
All in all, they look and almost perform identical.
This
On Thu, 1 Dec 2005, Andy Ross wrote:
AN-225/AN-225-yasim.xml
The patched Yasim spitted it out again.
No twist set in that file, only incidence (4° positive).___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Curtis L. Olson wrote:
John Wojnaroski wrote:
One of the knocks from the May show ( which is totally my fault) was
the cheezy joystick. So here we were with a full scale 747 glass
cockpit with a large screen plasma OTW display running top of the
line flight dynamics (JSBSim), world class
On November 30, 2005 08:22 pm, Curtis L. Olson wrote:
Perhaps explain to them what our code is attempting to do, and then ask
if they know of a GLX supported way to do it.
I would do that if I can. However, I am not a programmer, and nothing in
RenderTexture.cpp makes any sense to me. :(
What
* Melchior Franz -- Friday 02 December 2005 01:10:
Modified Files:
tiny_xdr.cxx
Log Message:
returning addresses of auto vars is *dangerous* [...]
But ... we weren't really returning the address of an auto var.
Making dummy static fixes the problem, but the reason must be
another one.
On 12/1/05, Richard Bytheway [EMAIL PROTECTED] wrote:
Use the latest drivers from the chipset manufacturer's website (nVidia
or ATI). The card manufacturers have been known to optimise the
drievrs that they ship on the CD.
Richard
-Original Message-
From: [EMAIL PROTECTED]
* Melchior FRANZ -- Friday 02 December 2005 01:43:
But ... we weren't really returning the address of an auto var.
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
float
XDR_decode_float ( const xdr_data_t f_Val )
{
float* tmp;
xdr_data_t
Melchior FRANZ wrote:
* Melchior FRANZ -- Friday 02 December 2005 01:43:
But ... we weren't really returning the address of an auto var.
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
float
XDR_decode_float ( const xdr_data_t f_Val )
{
Take this back.. I'm playing with the X45 now and things are completely
different.
Might be best to have a seperate X36.xml file.
On Thu, 2005-12-01 at 14:42 -0800, [EMAIL PROTECTED] wrote:
From what I'm seeing, the Saitek X45 is almost identical to the Saitek
X36
joystick.
I own both
From: AJ MacLeod
Last night (using completely up-to-date CVS) I noticed that fgfs segfaults
reliably if one relocates the a/c to KOAK using the position a/c on ground
menu.
After a bit more investigation, it appears that this is caused by a nan in
the
yasim turbulence stuff, because
On 12/1/05, bass pumped [EMAIL PROTECTED] wrote:
Hi,
I'm glad to report that I am an idiot and that there is nothing wrong
with the data transmission code. It works fine except
when trying to write throttle over udp.
For some wierd reason it takes values of one or zero at
On Freitag 02 Dezember 2005 04:02, Jim Wilson wrote:
I just checked and this problem is in the 0.9.9 release.
August 14th there was a patch from Mathias:
- Introduces a FGScenery::get_elevation_m method which queries the altitude
at a given position. In constrast to the groundcache functions
On Freitag 02 Dezember 2005 02:29, Melchior FRANZ wrote:
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
float
XDR_decode_float ( const xdr_data_t f_Val )
{
float* tmp;
xdr_data_t dummy;
dummy = XDR_decode_int32 (f_Val);
By the way: the right fix would be:
float
XDR_decode_float ( const xdr_data_t f_Val )
{
union {
float f;
xdr_data_t x;
} tmp;
tmp.x = XDR_decode_int32 (f_Val);
return tmp.f;
}
Please use this one. And I believe, without looking into the code, that there
are likely
Selon Ampere K. Hardraade:
On November 30, 2005 08:22 pm, Curtis L. Olson wrote:
Perhaps explain to them what our code is attempting to do, and then ask
if they know of a GLX supported way to do it.
I would do that if I can. However, I am not a programmer, and nothing in
RenderTexture.cpp
Mathias Fröhlich [EMAIL PROTECTED] writes:
By the way: the right fix would be:
float
XDR_decode_float ( const xdr_data_t f_Val )
{
union {
float f;
xdr_data_t x;
} tmp;
tmp.x = XDR_decode_int32 (f_Val);
return tmp.f;
}
Please use this one. And I believe,
Mathias Fröhlich writes:
Please use this one. And I believe, without looking into the code,
that there are likely more of them ...
please apply the attached patch which uses static_cast:
Index: src/MultiPlayer/tiny_xdr.cxx
===
50 matches
Mail list logo
