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?
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 tri
> > 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
http:
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
Josh Babcock wrote:
> Looks like the latest CVS version of FG is hanging:
>
>
> Anybody else seeing this?
>
> Josh
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-deve
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
> ===-===-===-==
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 tryi
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 a
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
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 happe
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?
_
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 numbe
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 le
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 $
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 -O0
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
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 m
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
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
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 FG
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 s
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
* 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:
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, origin
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
2f5
* 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, wit
* 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
opti
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
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 th
This patch reshuffles parts of FGTileEntry::load() to allow mere
sea tiles to contain objects (oil rigs, nav-, weather-buoys, stuff,
etc.), and to prevent fgfs from dropping objects listed in *.stg
files that were loaded before the one containing the first
terrain.btg.gz (-> FG_SCENERY).
The curre
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(
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 instrumen
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:
> 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 channe
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 lik
* 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 %
* 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 _Z16XD
-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
* 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 (stat
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
RenderTexture
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 d
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
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 )
{
floa
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 f
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
contro
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 o
* 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
Flightgear-devel@flightg
* 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 <
* 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
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
50 matches
Mail list logo