Jason Cox wrote:
Is there a Howto on using PostGIS to create Scenery ?
No, as there is no use for PostGIS in _creating_ scenery. I'm running a
PostGIS database that stores our landcover data from VMAP0 and which
soon will contain manual improvements as well, but PostgreSQL/PostGIS
is for
* Alex Romosan -- Friday 02 December 2005 08:16:
Mathias Fröhlich writes:
Please use this one. And I believe, without looking into the code,
that there are likely more of them ...
I'll try all solutions later today. But I don't understand why
any of them should be necessary. The code may
* Alex Romosan -- Friday 02 December 2005 08:16:
please apply the attached patch which uses static_cast:
Haven't yet tested, but it looks good. At least it calls
_Z16XDR_decode_int32RKj. :-)
(gdb) disass XDR_decode_float
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x0831086e
* Melchior FRANZ -- Friday 02 December 2005 09:57:
* Alex Romosan -- Friday 02 December 2005 08:16:
please apply the attached patch which uses static_cast:
No, this patch doesn't work.
m.
___
Flightgear-devel mailing list
On 2 Dec 2005, at 00:32, John Wojnaroski wrote:Just a question of time and energy. The design issue is how to keep it portable so we can haul the gear around to shows like Scale4x coming up in Feb 06. Same problem with putting everything into a shell, fantastic for a fixed installation but kind
Having seen the recent request to try out a list of yasim-based aircraft
from the current CVS, I've tried out the TU154. Here are 3 things I've
noticed:
1) by hand-flying, I was able to get supersonic, pretty low and the
aircraft flew all right, with no fluttering or reaching limits of some
James Turner wrote:
On 2 Dec 2005, at 00:32, John Wojnaroski wrote:
Just a question of time and energy. The design issue is how to keep
it portable so we can haul the gear around to shows like Scale4x
coming up in Feb 06. Same problem with putting everything into a
shell, fantastic for a
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 )
{
On Thu, 2005-12-01 at 17:29, Curtis L. Olson wrote:
Norman Vine wrote:
FlightGear is more then just a first person sim
These other uses may have reasons to want
dialog box displays.
Again if you don't ike the dialog boxes don't use them
but please do not advocate taking them away.
On Thu, 2005-12-01 at 22:47, Josh Babcock wrote:
Steve Hosgood wrote:
Also, have you considered looking into OpenGC? It won't give you the
MSFS like functionality of dragable sub windows, but I think it would
allow you to make arbitrary windows to display instruments in cutouts.
I was
Ampere K. Hardraade wrote:
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
* Harald JOHNSEN -- Friday 02 December 2005 11:36:
Melchior FRANZ wrote:
(why does it not call _Z16XDR_decode_int32RKj? Optimized away?):
decode_int32 is a nop on a x86 anyway
Huh? Looks like a nop for big-endian:
int32_t
XDR_decode_int32 ( const xdr_data_t n_Val )
{
return
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Hosgood schrieb:
I was deliberately thinking that you **don't** want to use OpenGL for
that sort of thing. The GPU has enough work to do rendering the view out
of the windows, it would be a waste of its time rendering instruments
for the
* Mathias Fröhlich -- Friday 02 December 2005 07:35:
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;
}
This works.
Dump of assembler code for function
* Harald JOHNSEN -- Friday 02 December 2005 11:36:
Perhaps adding a volatile modifier on the tmp pointer
could do the trick (of course doing that disables optimisations).
It doesn't.
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x08310816 _Z16XDR_decode_floatRKj+0: push %ebp
On Thu, 2005-12-01 at 20:23, Curtis L. Olson wrote:
This is why all those oddball home/hobby cockpit builders aren't as far
off their rockers as it might first appear. They are taking a huge step
towards a more realistic simulation environment.
Dead right. I'd never knock them - more like
Steve Hosgood wrote:
Not sure about whether FlightGear currently allows for force feedback,
Sure it does - if it actually works only depends on the intelligence of
your actuator subsystem. All data that might have impact on the
respective force is available for being written to an output
On Wed, 2005-11-30 at 20:25, Steve Knoblock wrote:
If an aircraft has its own autopilot, the default dialog
does not come up, but if it does not specify an autopilot, the default
dialog comes up.
Not quite. I've just discovered that the autopilot works(*) with the
Colditz Glider!
Let's
Steve Hosgood wrote:
On Thu, 2005-12-01 at 22:47, Josh Babcock wrote:
Steve Hosgood wrote:
Also, have you considered looking into OpenGC? It won't give you the
MSFS like functionality of dragable sub windows, but I think it would
allow you to make arbitrary windows to display instruments in
Steve Hosgood wrote:
On Wed, 2005-11-30 at 20:25, Steve Knoblock wrote:
If an aircraft has its own autopilot, the default dialog
does not come up, but if it does not specify an autopilot, the default
dialog comes up.
Not quite. I've just discovered that the autopilot works(*) with the
Harald JOHNSEN wrote:
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
dummy = XDR_decode_int32 (f_Val);
tmp = (float*) dummy;
return (*tmp);
This violates the strict aliasing rules that are the default for
gcc 4.x -- I believe it issues a warning to that
Melchior,
One of the original intentions of the scenery path was to search until
you found something and then stop. From what you wrote, it sounds like
the entire scenery path is searched and objects pulled from anything
that is found.
The original intention was that you could have smaller
* Andy Ross -- Friday 02 December 2005 16:36:
This violates the strict aliasing rules that are the default for
gcc 4.x -- I believe it issues a warning to that effect.
There's is no warning (using -Wall), and info man page claim
that strict aliasing is turned off by default, even if the
* Curtis L. Olson -- Friday 02 December 2005 16:57:
One of the original intentions of the scenery path was to search until
you found something and then stop.
This is still the case for terrain.btg.gz files and airports, just as it
was before. But objects are always set from all stg files, with
On Fri, 2005-12-02 at 14:28, Josh Babcock wrote:
No, OpenGC
^
http://www.opengc.org/
Oops. Sorry.
Steve
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Melchior FRANZ wrote:
This is still the case for terrain.btg.gz files and airports, just as it
was before. But objects are always set from all stg files, with or without
this patch. The difference is that objects aren't set at center of Earth,
especially in sea tiles.
That's too bad,
* Curtis L. Olson -- Friday 02 December 2005 18:09:
Again, it's a shame that original functionality is lost when people come
later and make changes to complex code without fully understanding the
intent.
Isn't that one of the reasons why we have flightgear-cvslogs? For
code review? Like in
Melchior FRANZ wrote:
Is the following behavior OK?
Generate all objects from all FG_SCENERY paths until we found the
first OBJECTS_BASE entry (including the other object entries in this
*.stg file). Then read the matching Objects/ directory, too.
But *then* stop scanning.
That makes
Jon Stockill wrote:
Melchior FRANZ wrote:
Is the following behavior OK?
Generate all objects from all FG_SCENERY paths until we found the
first OBJECTS_BASE entry (including the other object entries in this
*.stg file). Then read the matching Objects/ directory, too.
But *then* stop
I'm having trouble with opengc connecting to flightgear 99 (windows)
I THINK opengc is working, not sure how to check as I can't get FG to
talk to it. It just seems to be listening to port 5800
FG is set up
socket, out, (my ip), 5800, udp
I think everything is setup properly, but I'm new to
On 12/2/05, Bruce Benneke [EMAIL PROTECTED] wrote:
I'm having trouble with opengc connecting to flightgear 99 (windows)
I THINK opengc is working, not sure how to check as I can't get FG to
talk to it. It just seems to be listening to port 5800
FG is set up
socket, out, (my ip), 5800, udp
Thanks for the quick reply
I just found out the problem lies with there not being any provision to
do this setup in the windows port of FG.
I'm gonna move this over to linux and try again...
Bruce
bass pumped wrote:
On 12/2/05, Bruce Benneke [EMAIL PROTECTED] wrote:
I'm having trouble
are you saying that you can't get FG to transmit UDP on WinXP. It
works for me.
On 12/2/05, Bruce Benneke [EMAIL PROTECTED] wrote:
Thanks for the quick reply
I just found out the problem lies with there not being any provision to
do this setup in the windows port of FG.
I'm gonna move
I can't figure out why this is happening. If anyone has any ideas,
please let me know. To me it seems that I have everything I need in all
the right places. Here's the situation:
*brand spanking new Debian sid install*
Package Installed PreviousNow
State
Hi,
as discussed already on IRC, there seems to be another gcc 4.0.2/SUSE
1.0 problem:
engine sounds on the 737, Concorde and every other plane that uses
thrust_lb[0] as base for the engine sound calculation don't work on this
platform.
Builds from SuSE 9.3 and from SUSE 10.0 compiled with
Steve Hosgood writes:
Do the current crop of cockpit builders happen to use real simulated
physical instruments wired to USB or something?
There are several vendors out there who have simulated instruments
with needles and the like, often driven by RC servos. Granted, this
runs your price up
The very first thing I would check is the contents of the config.log
file. That shows the details of the test and the compiler error
signaling a failure. That often can be quite helpful.
Curt.
Josh Babcock wrote:
I can't figure out why this is happening. If anyone has any ideas,
please
On December 2, 2005 05:50 am, Harald JOHNSEN wrote:
The code creates a pbuffer the standard way, there is nothing special in
rendertexture, the only things
special is the choice of the api, using glx pre or post 1.3 - and this
code won't work well for long
since mesa lies on version numbers.
I've discovered a difference between how fgfs calls the yasim solver, and
how the yasim binary (aka yasim-test) does it. I have a -yasim.xml which
doesn't pass yasim(-test) but which fgfs accepts... ?:-P
So what is the difference? Number of iterations?
Curtis L. Olson wrote:
The very first thing I would check is the contents of the config.log
file. That shows the details of the test and the compiler error
signaling a failure. That often can be quite helpful.
Curt.
Josh Babcock wrote:
I can't figure out why this is happening. If
Josh Babcock wrote:
Curtis L. Olson wrote:
The very first thing I would check is the contents of the config.log
file. That shows the details of the test and the compiler error
signaling a failure. That often can be quite helpful.
Curt.
Josh Babcock wrote:
I can't figure out why this is
The attached patch does the following things:
1) it's really difficult to fly a helicopter with the yoke,
but one can make good use of the throttle as the collective.
If one wants to fly and use the mouse as the cyclic control,
it's impossible unless the yoke doesn't send the axis0/1 position
as
k... got it fixed :-)
On 12/2/05, bass pumped [EMAIL PROTECTED] wrote:
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
Josh Babcock writes:
looks like debian is broken. There was no link from libXmu.so to
libXmu.so.6 in /usr/X11R6/lib.
Thanks for the tip.
For you Debian guys:
Package Installed PreviousNow
State
Josh Babcock wrote:
Looks like the latest CVS version of FG is hanging:
SNIP
Anybody else seeing this?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
On Friday 02 December 2005 04:18 am, Vassilii Khachaturov wrote:
2) when I hit the F3 to generate the above snapshot, I got an unusual
attitude, from which it was very difficult to recover
Are you flying using the mouse?
Dave
___
Flightgear-devel
2) when I hit the F3 to generate the above snapshot, I got an unusual
attitude, from which it was very difficult to recover
Are you flying using the mouse?
Affirmative.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Last night I noticed that a couple of the yasim-related updates happened
later after my prev. pull. This time tu154 doesn't want to load up at all
(btw this time I am not flying using the mouse, having the CH Products
USB yoke+pedals connected):
YASim SOLUTION FAILURE:
Insufficient elevator to
On Samstag 03 Dezember 2005 01:57, Joacim Persson wrote:
I've discovered a difference between how fgfs calls the yasim solver, and
how the yasim binary (aka yasim-test) does it. I have a -yasim.xml which
doesn't pass yasim(-test) but which fgfs accepts... ?:-P
So what is the difference?
49 matches
Mail list logo
