Pull request with the fix is on the mailing list.
I've fixed that now... is there a way to test this instrument? (I've never encountered it my self) And how am I supposed to find the nasal uses? Take fgaddon trunk unpack everything, from their zip files and then grep in there?
I've fixed that now... is there a way to test this instrument? (I've never encountered it my self)
Okay, so looking into fixing this rn.. I notice we also define codes 6 and 7 which are no longer in the spec, instead the helipads, which this was for before, use the same codes as the runways now How to go about this... cause I'm sure it will break eventually...
Oh, that problem (once again)... already fixed that in terragear Here's the spec: https://developer.x-plane.com/article/airport-data-apt-dat-12-00-file-format-specification/ Thanks for looking into this
findAirportsByICAO doesn't return all airports it should find
Yes, it's about the issue from the mailing list you've mentioned. I'll open a new ticket.
Tried both patches, the problem persists. Thanks for mentioning us tho
SIGSEGV: simgear::EffectGeode::DrawablesIterator::dereference (this=<synthetic pointer>) at /games/flightgear/flightgear-nix-new/simgear/simgear/scene/material/EffectGeode.hxx:58
SIGSEGV
Thread 1 "fgfs" received signal SIGSEGV, Segmentation fault. 0x00007ffff74653a4 in osgDB::SharedStateManager::share(osg::Node*, OpenThreads::Mutex*) () from ../../openscenegraph/lib/libosgDB.so.162 (gdb) bt apply all full No symbol "apply" in current context. (gdb) bt thread all full A syntax error in expression, near `all full'. (gdb) bt full #0 0x00007ffff74653a4 in osgDB::SharedStateManager::share(osg::Node*, OpenThreads::Mutex*) () from ../../openscenegraph/lib/libosgDB.so.162 No symbol table...
SIGSEGV osgDB::SharedStateManager::share(osg::Node*, OpenThreads::Mutex*)
Status is still on NeedInfo... What info do you need?
Status is still on NeedInfo... What info do you need?
Status is still on NeedInfo... What info do you need?
SIGSEGV std::_Rb_tree_insert_and_rebalance
works, thanks
not quite sure... Before I've used an older version of the alphaelectro which I've downloaded from somewhere (don't remember where). That version worked. Then I've switched to the fgaddon version (and unfortunately deleted the other version) and the segfaults started... on the very same fg build.
That was with FGCom on... If I turn it of it doesn't crash. Command line args: --enable-sentry --httpd=8080 --telnet=8081 --generic=socket,in,52,,5542,udp,opentrack --allow-nasal-from-sockets --fg-aircraft=/home/fly/.fgfs/Aircraft --fg-aircraft=/home/fly/.fgfs/Aircraft/org.flightgear.fgaddon.trunk/Aircraft/ --enable-fullscreen --disable-terrasync --disable-ai-traffic --prop:/sim/nasal-gc-threaded=false --timeofday=noon --prop:bool:/sim/rendering/als/shadows/enabled=true --prop:int:/sim/rendering/als/shadows/sun-atlas-size=16384...
SIGSEGV in FGCom::valueChanged
From what I've seen, it works now as well.
Still there as of fg: 740193a3785292fdd8acda0734e0cfd650518468 sg: 9ecb90eddafe90dbca4c86bffaa8c8f3edaccd12
Sounds good. Not sure tho, if that solves the gap, between the shadow cascades, when the aircraft shadow gets near the shadow of a building.
James, I then assume me == {} :P On 2020.2.1, the menu option for 3d is disabled. I was unable to build 2018.3 so I couldn't checkt that...
video showing the issue
sure, use what ever model you want... just make sure, that the xml has the enable-hot...
Since the walker works in the C172, do the following. Add the stairs to the scenery as usual. Then start with the C172. In the nasal console run the following code (adjust the path to where your stairs.xml is) to place the stairs about 20m ahead (I know it's sunk into the ground...). pos = geo.aircraft_position(); pos.apply_course_distance(geo.normdeg(getprop("/orientation/heading-deg")), 20); geo.put_model("Aircraft/A320-family/Models/Services/Stairs/stairs.xml", pos); Take the walker, the scenery...
The black-flashing sky reminds me of the issue, when you change to walker view without the walker being outside. In this case, there's also some white shape in the middle of the screen and no terrain visible (if I'm not mis). I've managed to drop "through" the ground... just cause it hasn't loaded yet in walker view. A second later I stood again on the apron.
This time with the ufo, after hitting the ground with the walker
No, the shadow is there... even without flashlight. The flashlight just makes it much more visible.
Yes, seen that on the A350... removing the lightmap effect fixed that
One thing to note is, that WITH anaglyph, the osgText works while WITHOUT it's invisible
The include should add the walker menu to the menu bar. On the right hand side. It has an item called "Toggle Walker outside" I know, that the stairs are sunk into the ground. I just used that model for my tests are it was the one, I've initially played with.
Correction: Nvidia seems to be affected too
Crash on radeon GPUs
enable-hot only works on scenery load
Happened again... as well with the A320. This time just after hitting "FUEL" on the ECAM control panel
well... after a fg restart it works... but the loading screen is anaglyph as well... and the rendering is more or less broken while it looked correct while it was frozen
Compositor rendering freezes when enabeling anaglyph 3d
Compositor shadow at night
Compositor shadow lod transition
Z layer issues in compositor
SIGSEGV std::_Rb_tree<SGVec2<unsigned long>
SIGSEGV simgear::Effect::getGenerator
I've got two more different crashes caused by the same situation. (Files attached)
I've got two more different crashes caused by the same situation. (Files attached
Default scenery and disableding vegitation both fix the issue. While testing I've got a similar crash... might be the same cause since it happened as well only here. Thread 42 "fgfs" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff1fbfa700 (LWP 75540)] 0x00007ffff73947b2 in osg::BufferData::~BufferData() () from /lib/x86_64-linux-gnu/libosg.so.160 (gdb) bt full #0 0x00007ffff73947b2 in osg::BufferData::~BufferData() () from /lib/x86_64-linux-gnu/libosg.so.160 No symbol table...
SIGSEGV simgear::QuadTreeCleaner::apply
SIGSEGV _int_free
Basically I can do the same... it just seems to increase the likelyhood....
I use i3wm, if that helps...
Idk... I don't use that... Somehow I've got the feeling, that it almost only occures when I start fg and put it in the background.
occured again... this time with the debian osg
It's just sometimes... I couldn't figure out a pattern yet. Windowmanger update... I've got no clue. Yes, I've started using a dnc osg build from mid-end march cause I had trouble with the osg from the distro.
I remember having some for quite some time (iirc since I've started using next builds again -> end of november) but they became frequent about Mid February... Note that disabeling the nasal gc has reduced the number os segfaults I get significantly so in there, it certainly some issue.
Revert that.... Just had this one with an up-to-date build. Just started FG with the default c172p and then I've switched window. When I've looked back, it had crashed.
Yes.... just FYI... so far since I've disabled the Nasal GC thing, I haven't had a single SIGSEGV...
Happend after flightgear start, in the A320 selected "Ready for engine start" state. But didn't crash immedeatly, took a few seconds...
SIGSEGV flightgear::eventToWindowCoords
nasal gc is the default... aircraft A320
Yep, happend on exit.
I've set it... I'll see if it keeps happening.
/sim/nasal-gc-threaded: true /sim/nasal-gc-threded-wait: false
SIGSEGV osg::ObserverSet::signalObjectDeleted
SIGSEGV nasal::shared_ptr_storage
SIGSEGV SGWeakReferenced::put