On 23.04.2012 13:52, Christian Schmitt wrote:
We could, if the xml parser would not simply discard any new runways that
are not already in the apt.dat file.
If I understood a comment of James in the bug tracker correctly, this,
however, always has been and still is the normal behaviour, since
I've just pulled and compiled simgear and flightgear and pulled a fresh FGData
to start package the next lightfield shader version, but it turns out the
resulting binary is unstable.
I get segfaults about 10 seconds after startup with the master branch, no other
errors written to the console,
On 24 Apr 2012, at 09:04, Renk Thorsten wrote:
I've just pulled and compiled simgear and flightgear and pulled a fresh
FGData to start package the next lightfield shader version, but it turns out
the resulting binary is unstable.
I get segfaults about 10 seconds after startup with the
Am 23.04.12 17:40, schrieb Stuart Buchanan:
On Mon, Apr 23, 2012 at 1:17 AM, HB-GRAL wrote:
Just a small question because I’m currently looking to OSM street data
and try to use it for scenery creation ... in your last screenshot of
your improvements I still see buildings on streets (not the
Just so people know, I made a change to how AI traffic is started (so you can
ignore this email if you run with traffic turned off) to avoid the long pause
during 'initialising subsytems' when all the XML schedules are parsed and
loaded.
This has a few effects - the app doesn't go unresponsive
On 24 Apr 2012, at 08:28, ThorstenB wrote:
If data needs to be loaded anyway (airport codes/positions), then
distributing it to tons of individual files may not help with start-up
delays either.
James really needs to comment on nav data things though, since I never
touched this area.
Hi Thorsten,
Can you get a backtrace?
I can try if you tell me what I need to do...
I've made a change to the startup sequence,
yesterday, but I would expect it to crash later (after scenery
loading),
ten seconds sounds too early.
Misunderstanding: After scenery loading and I
On 24 Apr 2012, at 09:20, Renk Thorsten wrote:
Can you get a backtrace?
I can try if you tell me what I need to do...
(re-)Build fgfs with debug symbols:
-DCMAKE_BUILD_TYPE=Debug
when running cmake, might need to make clean + make again
then run fgfs
gdb fgfs
run
On 24 Apr 2012, at 10:24, James Turner wrote:
This is still at the 'hack' state, it's be trivial to revert to the old
method.
I'll have a look at it later today. I guess this change was slowly but
increasingly becoming necessary. I'll let you know if I see any undesirable
side effects.
I had similar problem this weekend, and a full rebuild (simgear +
flightgear) solved the issue. I have the sentiment that changes
to SGReferenced (in simgear) could have created this instability
I pulled everything fresh and compiled both simgear and flightgear new, so
things shouldn't be out
Hi Thorsten,
ThorstenB wrote:
On 23.04.2012 13:52, Christian Schmitt wrote:
We could, if the xml parser would not simply discard any new runways that
are not already in the apt.dat file.
If I understood a comment of James in the bug tracker correctly, this,
however, always has been and
Martin Spott wrote:
Indeed, the XML structure was primarily meant to override incorrect
values of pre-existing airfields.
BTW, here's the initial announcement:
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17407.html
Cheers,
Martin.
--
Unix _IS_ user
On 24 Apr 2012, at 09:45, Durk Talsma wrote:
I'll have a look at it later today. I guess this change was slowly but
increasingly becoming necessary. I'll let you know if I see any undesirable
side effects.
Well, the main thing needed is to break apart the 'finishInit' into more steps,
to
Can you get a backtrace?
Okay, following your instructions I did make clean in any of my build folders,
ran cmake with -DCMAKE_BUILD_TYPE=Debug added, recompiled simgear and
flightgear, and did
gdb ./fgfs
run --log-level=info --airport=KSFO --disable-real-weather-fetch
--disable-fullscreen
On 24 Apr 2012, at 11:31, Renk Thorsten wrote:
Program received signal SIGSEGV, Segmentation fault.
0x5e3d9a08 in ?? ()
Missing separate debuginfos, use: debuginfo-install e2fsprogs.i386 gcc.i386
glibc.i686 libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXcursor.i386
libXdmcp.i386
Oops, missed that part of the instructions *blush*
Here's the output:
(gdb) bt
#0 0x5e3d9a08 in ?? ()
#1 0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
#2 0x088ddc29 in f_airportinfo (c=0x13bedd28, me=
On 24 Apr 2012, at 11:41, Renk Thorsten wrote:
Here's the output:
(gdb) bt
#0 0x5e3d9a08 in ?? ()
#1 0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
#2 0x088ddc29 in f_airportinfo (c=0x13bedd28, me=
Okay, this is my fault, but I don't know why / how it's crashing for
you. Presumably you have some aircraft or nasal that makes additional
airportinfo() calls, and you've managed to find a test-case that my
testing has not encountered. Unfortunately we need to find out the
relevant
On 24 Apr 2012, at 08:28, ThorstenB wrote:
If data needs to be loaded anyway (airport codes/positions), then
distributing it to tons of individual files may not help with start-up
delays either.
James really needs to comment on nav data things though, since I never
touched this area.
Hi Thorsten,
ThorstenB wrote:
On 23.04.2012 13:52, Christian Schmitt wrote:
We could, if the xml parser would not simply discard any new runways
that
are not already in the apt.dat file.
If I understood a comment of James in the bug tracker correctly, this,
however, always has been and
On 24 Apr 2012, at 12:07, Renk Thorsten wrote:
It doesn't depend - I got a crash at TNCM as well, also using both c172p and
the ufo. So this must be something more generic.
Just to check, you have updated simgear as well? There's a bugfix in
there I applied at the same time.
I did
On Tue, Apr 24, 2012 at 7:39 AM, James Turner zakal...@mac.com wrote:
On 24 Apr 2012, at 12:07, Renk Thorsten wrote:
It doesn't depend - I got a crash at TNCM as well, also using both c172p
and the ufo. So this must be something more generic.
Just to check, you have updated simgear as
On 24 Apr 2012, at 14:39, Curtis Olson wrote:
For what it's worth, I'm seeing nearly the same thing ... similar back
trace-- crashing in hashforairport() about 10-15 seconds after the splash
screen has been removed and the sim presented for use.
Okay, that's good news since it rules out
On Tue, Apr 24, 2012 at 9:19 AM, HB-GRALwrote:
Maybe just another dumb question, but wouldn’t it be possible to
dynamically create a generalized mask with .stg point coords from the
custom objects?
Yes, but the current architecture separates the .stg loading from the .btg
loading in such a way
See if this makes sense??
(gdb) frame 1
#1 0x0088fb79 in
hashForAirport (c=0x19e62860, apt=0x6a128d0) at
/home/scotth/Download/Flightgear/git-repo/flightgear/src/Scripting/NasalPositioned.cxx:113
113
std::string name = apt-name();
(gdb) print apt
$1 = (const FGAirport
*) 0x6a128d0
Hi James,
Here is a bit more information.
I added some printf's before the call to findClosest(pos, maxRange,
filter) in f_airportinfo()
The first time through, this seems to work, it returns a valid pointer,
which gets passed to hashForAirport(c, apt) a few lines later.
In hashForAirport() I
On 24 Apr 2012, at 15:57, Curtis Olson wrote:
I tried running with valgrind and the error didn't happen -- hmmm...
Trying it again, but a valgrind startup is excruciatingly slow ...
It's probably a reference counting issue. FGAirport is a FGPositioned and hence
reference counted. The Nasal
On Tue, Apr 24, 2012 at 10:06 AM, James Turner zakal...@mac.com wrote:
It's probably a reference counting issue. FGAirport is a FGPositioned and
hence reference counted. The Nasal Ghost is supposed to deal with this -
when we create a ghost around the airport, we take a reference
On 24 Apr 2012, at 16:31, Curtis Olson wrote:
Based on two runs with out crashing, that seems to prevent the crash ...
Okay, so that's good but leaves me wondering why it doesn't crash on Mac
the same way. And also, how I've got the ref-counting wrong.
James
On Tue, Apr 24, 2012 at 10:35 AM, James Turner zakal...@mac.com wrote:
On 24 Apr 2012, at 16:31, Curtis Olson wrote:
Based on two runs with out crashing, that seems to prevent the crash ...
Okay, so that's good but leaves me wondering why it doesn't crash on
Mac the same way. And
Hi James,
just a guess here, but in the past, I had to fix issues brought when converting
raw pointers to smart pointers and ending up deleting the pointer given by the
smart pointer explicitly. For example :
SGSharedPtrMyClass myPtr = new MyClass;
then
delete myPtr;
or
delete myPtr.get();
flightg...@sablonier.ch wrote:
Is the code/the queries to produce the xml output from the postgres
apt/nav.dat database available for public somewhere?
It's a simple Bash/PostgreSQL proof of concept which has seen
'evolutionary' development, looping through the list of ICAO codes,
collecting
On 24 Apr 2012, at 16:50, Curtis Olson wrote:
If an FGAirport object was ref-counted and deleted because the ref-count went
to zero, then why would FGAirport::findClosest() still be returning a
pointer to it it as the closest airport? Is it not getting fully/properly
deleted or removed
On Tue, Apr 24, 2012 at 11:09 AM, James Turner wrote:
As far as the FGPositioned Octree is concerned (which is what findClosest
uses internally), it's holding an owning ref and hence things can't be
removed from it, for the moment.
So what I guess is happening, is that I'm breaking the
Im assuming my crash is related, but it only happens when i open the
route-manager dialog...
Syd
On Tue, Apr 24, 2012 at 10:24 AM, Curtis Olson curtol...@gmail.com wrote:
On Tue, Apr 24, 2012 at 11:09 AM, James Turner wrote:
As far as the FGPositioned Octree is concerned (which is what
I want to ask the question of what is the future with Multiplayer?
Its sems that the flavour and future is openRTI? but what is that about...
So where are we going with the multiplayer stuff?
Is there a plan, is there a vatsim replace?
Whats the MP protocl, or is it Open/RTI ?
are there json
Now this is really interesting..
http://mapserver.flightgear.org/git/gitweb.pl?p=sceneryweb;a=blob;f=mapserver/Threshold_ILS_TWR.sh
I'm kinda moving into django land after lots of screaming and whining to
myself.. but it does seem to be a platform of sorts.. and sql alchemy
compat etc..
So can
To add furtheer..
http://mapserver.flightgear.org/git/gitweb.pl?p=sceneryweb;a=blob;f=mapserver/Threshold_ILS_TWR.sh
Were all reinventing a wheel..
I think there is a lo of data in blobs, and we converting one blob to
another..
Indeed after some reasearch..
robin sppol out the apt table with a
James,
I wasn't affected by a crash until I realized that hashForAirport was never
called. Then I enabled animated jetways and the segfault came, after few
successful calls.
I am not able to tell why though
HTH
-Fred
The initial commit of the random buildings is now available in git.
To enable this, you'll need to set
/sim/rendiner/random-buildings=true. This is available through the
Rendering Options dialog, and requires the scenery tile to be reloaded
to take effect (via the Reload Scenery button on that
Hi,
On Tuesday, April 24, 2012 13:39:59 James Turner wrote:
Okay, then I realise this isn't useful for you, but I'm stumped why it
crashes for you. In particular, the hashForAirport function is being passed
something that looks like a valid pointer (I think), and it crashing on a
line that
On 24 Apr 2012, at 22:33, Mathias Fröhlich wrote:
I could by the length of the thread not exactly find what is going wrong and
how to reproduce this. But jut having a quick look at NasalPositiond.cxx, I
can see that this does not match the intented use of SGReferenced.
I have checked in
On Thu, Apr 19, 2012 at 9:11 PM, Stuart Buchanan wrote:
On Fri, Feb 24, 2012 at 7:38 PM, Stuart Buchanan wrote:
On Fri, Feb 24, 2012 at 8:42 AM, Torsten Dreyer wrote:
What about having a sub-subdirectory structure to avoid name mangeling, like
Materials/base/ (contains all common files and
On Tue, Apr 24, 2012 at 10:09 PM, Stuart Buchanan wrote:
The initial commit of the random buildings is now available in git.
One thing I forgot to mention: you need to be running with
data/materials/default/materials.xml or data/materials/dds/materials.xml.
The data/materials[-dds],xml are
On Tue, 24 Apr 2012 15:56:50 + (UTC), Martin wrote in message
jn6ig2$n84o$1...@osprey.mgras.de:
flightg...@sablonier.ch wrote:
Is the code/the queries to produce the xml output from the postgres
apt/nav.dat database available for public somewhere?
It's a simple Bash/PostgreSQL
Yves:
Towns are not point features. The vmap0 represents towns as points, but these
particular points are parsed by terragear and turned into 1km by 1km polygons
which are burned into the terrain. That gives the square appearance in the
default scenery.
In custom scenery, medium to low
As an aside: When working on the codebase, I maintain a local script
that launches FGFS by disabling whatever features prevent the
simulation from being flyable on my development machine. When I am
unable to turn off features that prevent the simulator from running,
and disabling them in source
Hi,
On Tuesday, April 24, 2012 22:51:34 James Turner wrote:
Okay, I guess I was assuming I can use SGreferenced the same way I use
release/retain in Cocoa, or addRef/decRef in COM/XPCOM. But it seems as if
this is not the case, from looking at your commit - I can't use
SGreferenced as a
48 matches
Mail list logo
