On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB bre...@gmail.com 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
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 problem.
On Mon, Apr 18, 2011 at 12:16 PM, Christian Schmitt ch...@ilovelinux.de 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:
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
ebx
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.
--
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:24
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%
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 thought
On Mon, Apr 18, 2011 at 1:38 PM, Christian Schmitt ch...@ilovelinux.de 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
=
On Mon, 18 Apr 2011 06:31:09 -0700 (PDT), Gene wrote in message
alpine.lfd.2.00.1104180630330.13...@grumble.deltasoft.com:
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
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
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
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
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,
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, it's
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
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
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
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 solution
On Mon, 18 Apr 2011 19:56:38 +0200, David wrote in message
banlktimbxl03ofww5qsvqoygszwybhs...@mail.gmail.com:
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
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 small
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 to
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
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:
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 there is
25 matches
Mail list logo
