Hi,
> Hello Heiko,
>
> does your local FDM still uses default approach fuel etc?
> But even if
> not, there should be no difference in the flight behavior.
> The only
> effect of the approach fuel level is (for a rotorcraft)
> within the gear
> solver.
> Heiko, and anyone else: if you think
I also have the flickering issue with shaders on. (ATI/AMD, Debian, fglrx)
On my system the problem occurs at low framerates (30-35 fps) caused by the
scenery.
On lighter airports I get 60-75 fps and the problem seems to be gone.
David, maybe someone of us should file a bug report here:
http://cod
Hello Heiko,
does your local FDM still uses default approach fuel etc? But even if
not, there should be no difference in the flight behavior. The only
effect of the approach fuel level is (for a rotorcraft) within the gear
solver.
By the way: I would prefer to use the old default values for th
On Monday, April 18, 2011 20:51:17 ThorstenB wrote:
> And you also checked that approach glide angle isn't used? Otherwise,
> the new default cruise angle (0.0) might not match the original approach
> angle setting...
>
No mention of approach glide angle either. I have no idea how this applies t
On Mon, 18 Apr 2011 19:20:59 +0200, Christian wrote in message
<20110418172059.cd1fe1318...@mail.sigmos.de>:
> Curtis Olson wrote:
>
> > Right, as said before, you crashed inside the gpc code. Have you
> > tried regenerating this airport using the --nudge option
> > (increasing the value in sma
On Mon, 18 Apr 2011 19:56:38 +0200, David wrote in message
:
> Hi developers,
>
> I have a new computer, installed FG on it and have a problem with the
> graphics.
>
> The problem (beside missing runway lights) is that surfaces generated
> by a shader will flicker. This applies to terrain and a
David Glowsky wrote:
> Hi developers,
>
> I have a new computer, installed FG on it and have a problem with the
> graphics.
>
> The problem (beside missing runway lights) is that surfaces generated
> by a shader will flicker. This applies to terrain and aircraft
Moin David,
while I have no sol
The first fault is inside the gpc code. As I said before, by my best
estimation, gpc is algorithmically correct, but when we throw arbitrary real
world numerical data at it, we can encounter some numerical degeneracies and
that can blow up the gpc routines.
I have no complaints if someone wants t
Hi developers,
I have a new computer, installed FG on it and have a problem with the graphics.
The problem (beside missing runway lights) is that surfaces generated
by a shader will flicker. This applies to terrain and aircraft
instruments, trees and the "Crop texture" however do not flicker. The
On 18.04.2011 14:51, Adrian Musceac wrote:
> On Monday, April 18, 2011 01:09:56 Heiko Schulz wrote:
>> I had a fix locally but with the patch fixing the YASim issue I have now to
>> begin again. I see the problem in the airfoil, but a change to this means
>> that I have to change a lot of other par
Curtis Olson wrote:
> Right, as said before, you crashed inside the gpc code. Have you tried
> regenerating this airport using the --nudge option (increasing the value
> in small increments until you find a value that allows the airport to be
> successfully built.)
>
> Regards,
>
> Curt.
Curt,
Right, as said before, you crashed inside the gpc code. Have you tried
regenerating this airport using the --nudge option (increasing the value in
small increments until you find a value that allows the airport to be
successfully built.)
Regards,
Curt.
On Mon, Apr 18, 2011 at 11:59 AM, Christi
Christian Schmitt wrote:
> Here you go (still on Atom), Phenom this evening.
Phenom:
(gdb) bt
#0 0x77bd4504 in merge_left (p=0x7c4f00, q=0x0, list=0x7c4f30) at
gpc.c:785
#1 0x77bd6861 in gpc_polygon_clip (op=GPC_UNION, subj=0x747fb0,
clip=0x770120, result=0x74edc0) at gpc.c:13
Hi Curt,
As far as I know, some of the early rocket models either had secondary attitude
thrusters or deflector plates placed inside the main rocket exhaust. Modern
types (i.e. anything from the 1950s onward) have used gimbaling main engines.
If you watch prelaunch space shuttle footage, you ca
I've never looked into it, but I've always wondered how (or how much)
control they have over those giant rockets. I know the space shuttle flies
a very precise profile and rolls over at a particular point, so they must
have some good control. But I have never thought about how that control is
imp
On Mon, 18 Apr 2011 06:31:09 -0700 (PDT), Gene wrote in message
:
> On Mon, 18 Apr 2011, AJ MacLeod wrote:
>
> > On Sun, 17 Apr 2011 00:39:52 +0200
> > Torsten Dreyer wrote:
> >
> >> 156MB!? Isn't that a bit - huge?
> >
> > Maybe... but it looks like a fantastic model. If only I had the
> > tim
On Mon, Apr 18, 2011 at 1:38 PM, Christian Schmitt wrote:
> Csaba Halász wrote:
>
>> Info registers, and something like x/10i $eip (or $rip on 64 bit)
>>
>
> Here you go (still on Atom), Phenom this evening.
>
> (gdb) info registers
> eax 0x0 0
>
> (gdb) x/10i $eip
> => 0xb7fb8fd
On Mon, 18 Apr 2011, AJ MacLeod wrote:
> On Sun, 17 Apr 2011 00:39:52 +0200
> Torsten Dreyer wrote:
>
>> 156MB!? Isn't that a bit - huge?
>
> Maybe... but it looks like a fantastic model. If only I had the time to
> actually work out how to fly it :-) Really impressive work though.
Fly it? I
On Monday, April 18, 2011 01:09:56 Heiko Schulz wrote:
>
> I had a fix locally but with the patch fixing the YASim issue I have now to
> begin again. I see the problem in the airfoil, but a change to this means
> that I have to change a lot of other parameters as well to keep the
> behavior 100%
Take a look at the J246 model in the JSBSim distribution or in our CVS
browser. That's a hypothetical heavy launch vehicle flight model that is
under (slow) development.
Jon
> -Original Message-
> From: AJ MacLeod [mailto:aj-li...@adeptopensource.co.uk]
> Sent: Monday, April 18, 2011 6:2
On Sun, 17 Apr 2011 00:39:52 +0200
Torsten Dreyer wrote:
> 156MB!? Isn't that a bit - huge?
Maybe... but it looks like a fantastic model. If only I had the time to
actually work out how to fly it :-) Really impressive work though.
--
-
Csaba Halász wrote:
> Info registers, and something like x/10i $eip (or $rip on 64 bit)
>
Here you go (still on Atom), Phenom this evening.
(gdb) info registers
eax0x0 0
ecx0xb7e67380 -1209633920
edx0x814aab0135572144
ebx0xb7f
On Mon, Apr 18, 2011 at 12:16 PM, Christian Schmitt wrote:
>
> I can get that for you, if you want. But what do you need?
> info registers? The whole coredump file?
Info registers, and something like x/10i $eip (or $rip on 64 bit)
--
Csaba/Jester
-
Csaba Halász wrote:
> It is certainly good advice to optimize for the correct processor, but
> using unsupported instructions typically result in a SIGILL not a
> SIGSEGV.
> It would help to see the actual disassembly around the fault and
> machine register contents. It smells like alignment prob
On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB wrote:
> On 16.04.2011 21:16, Anders Gidenstam wrote:
>> If I'm not mistaken the particles issue has been around since we got
>> particles, so it is apparently not that bad (leak and race
>> condition) in practice.
> Ok, thanks! I've create a bug issue as
25 matches
Mail list logo
