Activity for Bjoern K
-
Bjoern K posted a comment on ticket #2365
Seems to work for me as well. Even if the FG session itself hangs (upon loading) and needs to be closed (which happened after the third or fourth repeated "launcher -> run session -> quit session -> launcher, etc." loop), the launcher reopens. Good work, James!
-
Still getting crashes. Aerostar 700 at BIKF. Multiple resets at the location were okay, but changing the airport to EDAH and then resetting crashed FG. P.S: Do you know how to pass that "handle SIG32 nostop" command at startup? Having to look it up and copy and paste it for each debugging session is highly annoying.
-
Still getting crashes. Aerostar 700 at BIKF. Multiple resets at the location were okay, but changing the airport to EDAH and then resetting
-
The primary "Linuxisms" I can think of is differing directory separators for paths and too strict handling of folder naming (as in capitalization). Or it's an OSG bug. I've got all FG files with me this week, so I can build it on my laptop to rule our graphics driver related issues (laptop: NVidia, desktop: AMD).
-
Alright then. Did my log files yield anything useful?
-
OS: Arch Linux SG HEAD: a49619fa6c23bf7ad8839de63d8454291cb29cf3 FG HEAD: 083d364f9c2e809716f4cceb634ed41b836ac725
-
The top of my "installed aircraft" list when using the normal launcher:
-
Aircraft Center: Missing default aircraft and custrom folders
-
Stupid question: Wouldn't it make more sense to have the launcher as a separate binary that just sets arguments for fgfs and then starts it as a forked process? To my understanding, this would make it easier to avoid initiailization loops and offer cleaner fgfs session launches and exits. Or is this not possible due to some OSG limitations?
-
FGFS.log
-
Same result when issuing "File" --> "Reset".
-
No dice. :( 1) Launch FG session 2) Wait until everything has finished loading 3) "File" --> "Aircraft Center" 4) Pick new aircraft 5) Hit "Fly" 6) FG freezes after a short while and has to be forcefully terminated GDB backtrace:
-
FGFS log:
-
No dice. :( 1) Launch FG session 2) Wait until everything has finished loading 3) Menu --> "Aircraft Center" 4) Pick new aircraft 5) Hit "Fly" 6) FG freezes after a short while and has to be forcefully terminated GDB backtrace:
-
FGFS.log:
-
It sadly doesn't work. As soon as I click "Exit", Flightgear just hangs dead cold and its process has to be terminated. See the attached GDB backtrace.
-
Will do tomorrow. Thanks for the quick fix!
-
No, that short bit of silence wasn't intentional. Either Audacity tricked me or I overlooked it or it's a quirk of the WAV exporter. Anyway, feel free to commit your fixed version instead. Once it's accepted, I'll reject/withdraw this merge request. No hard feelings. :)
-
And the "Apply" button actually triggers a write to the preferences/autosave file? Is there a method to debug file I/O (logfile or stdout in a terinal)?
-
I'm not at my FG PC at the moment (and won't be till the weekend), so I can't test it right now. Is this a menu item or command line flag? If there's a status flag for "FG's OSG Window is open" that the launcher can check, avoiding endless loops shouldn't be a problem, should it?
-
I'm not at my FG PC at the moment (and won't be till the weekend), so I can't test it right now. Is this a menu item or command line flag?
-
I'm not at my FG PC at the moment (and won't be till the weekend), so I can't testit right now. Is this a menu item or command line flag?
-
I've taken extra care to make the spectrum produce a seamless loop and it does do so for me in the Citation 550 (from FGAddon) that uses the WAV. At least I could not hear any popping between the end and beginning point of the audio sample. If the author refers to the pulsing "woosh" somewhere in the sample, that's part of the audio file itself. I've tried to cut it out, but the loop gets worse, the shorter the sample gets. I've also tried to find a replacement file that's GPLv2/3 licensed, but to...
-
Good question. I'm not at my FG PC, so I can't check my habit. I think it's usually the method with the confirmation box ("Menu" --> "Quit")? Shouldn't the setting be saved by the "Apply" button regardless of how the FG session is terminated?
-
Good question. I'm not at my FG PC, so I can't check my habit. I think it's usually the method with the confirmation box, ("Menu" --> "Quit")? Shouldn't the setting be saved by the "Apply" button regardless of how the FG session is terminated?
-
Fixed cracks/pops in turbojet_fan.wav
-
FGFS.log:
-
I've compiled a debug build (FG HEAD c8d5296f7bef162311a303ff904577b4010c5e80, SG HEAD 9ec9d8e4233f9f8a03e3ad6a0525ce47d34d4c9d), but when trying to reproduce this bug now, all FG does is hang at "Finalizing Position", requiring issuing a SIGINT (CTRL+C). Not sure if the associated backtrace yields something useful:
-
FGFS log:
-
Sure, here you go. Nota bene: This uses --prop:/sim/rendering/multithreading-mode=CullDrawThreadPerContext to check if it's a potential fix for this segfault.
-
Thanks! I think this may just be a GUI bug or oversicht.
-
I'd really like to have item #6 from v s' list implemented as a workaround until #2127 is fixed. Exiting a FG session does not mean that relaunching a new one is completely out of the question. This could be an optional "Keep launcher open" setting in the Launcher itself or a startup flag (e.g. "--laucher_always_open").
-
I'd really like to have item #6 from v s' list implemented as a workaround until #2127 is fixed. Just because I want to exit a FG session does not mean that I do not want to relaunch a new one. This could be an optional "Keep launcher open" setting in the Launcher itself or a startup flag (e.g. "--laucher_always_open").
-
Since I can't edit the original ticket: Milestone is 2020.4 ("Next" branch) I've clicked "Apply", so I assume that the sound settings get written to Autosave or wherever else FG saves its settings. The corresponding checkbox also remains checked. FG HEAD: c8d5296f7bef162311a303ff904577b4010c5e80 SG HEAD: 9ec9d8e4233f9f8a03e3ad6a0525ce47d34d4c9d
-
Since I can't edit this: Milestone 2020.4 I've clicked "Apply", so I assume that the sound settings get written to Autosave or wherever else FG saves its settings. The corresponding checkbox also remains checked. FG HEAD: c8d5296f7bef162311a303ff904577b4010c5e80 SG HEAD: 9ec9d8e4233f9f8a03e3ad6a0525ce47d34d4c9d
-
Since I can't edit this: Milestone 2020.4 The corresponding checkbox also remains checked. FG HEAD: c8d5296f7bef162311a303ff904577b4010c5e80 SG HEAD: 9ec9d8e4233f9f8a03e3ad6a0525ce47d34d4c9d
-
"Use voice synthesis" setting is not saved
-
Fgfs.log for my last report.
-
Still not fixed. The aircraft in use does not matter. FG commit: c8d5296f7bef162311a303ff904577b4010c5e80 SG commit: 9ec9d8e4233f9f8a03e3ad6a0525ce47d34d4c9d GDB log: See attachment. P.S: I also noticed that, when called from within a session, the Aircraft Center does not list all my installed aircraft, only those downloaded from the launcher. It's as if the path to my add-on airecraft folder is completely ignored. But this is probably another bug.
-
OSG 3.6.5 is the only release in Arch's repositories. The Git package is at version 3.7.0+ by now.
-
I've just rebuilt SG and FG and I do not see this issue reoccur. Thanks for the fix!
-
QT Launcher "forgets" default aircraft folders
-
Here you go. Note that I repulled and rebuilt OSG and FG before I tested.
-
Just recompiled the latest Next and the problem persists. Tested in two different ways. GDB output files, including "bt full" info, are attached. 1) Started flight; hit "Reset" from the menu (gdb.log) 2) Started flight; selected "Aircraft Center" from the menu; picked a new starting location; hit "Fly" button (gdb_launcher.log)
-
Just recompiled the latest Next and the problem persists. Tested in two different ways. GDB output files are attached. 1) Started flight; hit "Reset" from the menu (gdb.log) 2) Started flight; selected "Aircraft Center" from the menu; picked a new starting location; hit "Fly" button (gdb_launcher.log)
-
Issue resolved. I pulled the Git snapshop from the Github mirror instead of Sourceforge. While the Simgear mirror on Github seems to be up-to-date, the Flightgear mirror is several months behind in terms of commits, which produced a commit level discrepancy and the compilation error.
-
I can confirm that Erik's latest commit fixes the issue. Monitoring the joystick axis values with jstest, I did not encounter the bug across four FG launches with one reboot after the first two. (See attached screenshot) I guess this ticked can now be marked closed.
-
I can confirm that Erik's latest commit fixes the issue. Monitoring the joystick axis values with jstest, I did not encounter the bug across four FG launches with one reboot after the first two. (See attached screenshot)
-
I can confirm that Erik's code fixes the issue. Monitoring the joystick axis values with jstest, I did not encounter the bug across four FG launches with one reboot after the first two. (See attached screenshot)
-
FG compile fails (SGConfigureDirectionalLights.cxx)
-
Thanks, but will only be able to test this next weekend with my T16000M. Or maybe I can simulate initial, excessive input with my XBox 360 pad.
-
The funny thing is that Erik's fix works sometimes, but I am unable to determine a pattern. Out of 10 tries, all by "Start launcher -> Click "Fly" -> Wait for loading process to finish and observe result -> Quit by ESC or ALT+F4": 01: Okay 02: Not okay 03: Not okay 04: Okay 05: Not okay 06: Not okay 07: Not okay 08: Okay 09: Not okay 10: Not okay The quitting method (ESC/ALT+F4) did not have an effect.
-
The funny thing is that Erik's fix works sometimes, but I am unable to determine a pattern. Out of 10 launches, all by "Start launcher -> Click "Fly" -> Wait for loading process to finish and observe result -> Quit by ESC or ALT+F4: 01: Okay 02: Not okay 03: Not okay 04: Okay 05: Not okay 06: Not okay 07: Not okay 08: Okay 09: Not okay 10: Not okay The quitting method (ESC/ALT+F4) did not have an effect.
-
No luck despite @ehofman 's commit.
-
Put fgjs.diff into "$fgsource/src/Input" and patched it with patch < fgjs.diff patching file FGJoystickInput.cxx patching file FGJoystickInput.hxx Rebuilt FG Launched FG I'm sadly not seeing any improvement. The "unplug, replug, start FG" method still produces full control deflections.
-
Put fgjs.diff into "$fgsource/src/Input" and patched it with patch < fgjs.diff patching file FGJoystickInput.cxx patching file FGJoystickInput.hxx Rebuilt FG Launched FG I'm sadly not seeing much improvement.
-
Put fgjs.diff into "$fgsource/src/Input" and patched it with patch < fgjs.diff patching file FGJoystickInput.cxx patching file FGJoystickInput.hxx Rebuilt FG Launched FG Erik's patch works, but not reliably.
-
Put fgjs.diff into "$fgsource/src/Input" and patched it with patch < fgjs.diff patching file FGJoystickInput.cxx patching file FGJoystickInput.hxx Rebuilt FG Launched FG Did NOT observe the issue (see attached screenshot with concurrent jstest output) So Erik's patch fixed it. I'd say get it pushed ASAP.
-
Patched with patch < fgjs.diff patching file FGJoystickInput.cxx patching file FGJoystickInput.hxx Rebuilt FG Launched FG Did NOT observe the issue (see attached screenshot with concurrent jstest output)
-
Yup, I need help. patch --dry-run "/media/Simulators/FlightGear-git/fgsource/src/Input/FGJoystickInput.cxx" "/home/bjoern/Downloads/fgjs.diff" checking file /media/Simulators/FlightGear-git/fgsource/src/Input/FGJoystickInput.cxx checking file /media/Simulators/FlightGear-git/fgsource/src/Input/FGJoystickInput.cxx Hunk #1 FAILED at 105. 1 out of 1 hunk FAILED
-
I tried to wrap this into something usable, but ended up cursing out Nasal, so the patch is probably the way to go.
-
I tried to wrap this into something usable, but ended up cursing out Nasal, so the patch will hit the Next branch way before i am able to work.
-
It would of course have to be designed to self-terminate after the controller is "woken up". ;)
-
I can cancel out the effects of the axis input in fgfs by forcing the output to the corresponding flight control to zero with a Nasal script. Example for the aileron axis: var id = setlistener("/devices/status/joysticks/joystick/axis", func(n){ # create listener if (n.getValue() == -1) { setprop("/controls/flight/aileron", 0); } }); I have an idea how to turn this into a workaround script, but I'm only starting out with Nasal and still have to learn the entire syntax and such.
-
Funnily enough, running FlightGear, fixing the initial deflection by moving and recentering the stick, then unplugging the controller and replugging it into the same USB port will produce a -32767 output in jstest, but will not affect /devices/status/joysticks/joystick/axis[n] (which duly stays at zero).
-
Funnily enough, running FlightGear, fixing the initial deflection by moving and recentering the stick, then unplugging the controller and replugging it into the same USB port will produce a -32767 output in jstest, but will not affect /devices/status/joysticks/joystick/axis[n] (which duly stays at whatever the last known value was).
-
Funnily enough, fixing the initial deflection by moving and recentering the stick in FlightGear, then unplugging and replugging the controller from/into its USB port produces a -32767 output in jstest, but will not affect /devices/status/joysticks/joystick/axis[n].
-
T16000M on desktop PC: jstest --event /dev/input/js0 Driver version is 2.1.0. Joystick (Thrustmaster T.16000M) has 6 axes (X, Y, Rz, Throttle, Hat0X, Hat0Y) and 16 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn, BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6, ?, ?, ?, BtnDead). Testing ... (interrupt to exit) Event: type 129, time 1439342239, number 0, value 0 Event: type 129, time 1439342239, number 1, value 0 Event: type 129, time 1439342239, number 2, value 0 Event:...
-
T16000M on desktop PC: jstest --event /dev/input/js0 Driver version is 2.1.0. Joystick (Thrustmaster T.16000M) has 6 axes (X, Y, Rz, Throttle, Hat0X, Hat0Y) and 16 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn, BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6, ?, ?, ?, BtnDead). Testing ... (interrupt to exit) Event: type 129, time 1439342239, number 0, value 0 Event: type 129, time 1439342239, number 1, value 0 Event: type 129, time 1439342239, number 2, value 0 Event:...
-
As promised, some more testing with the T16000M and the XBox 360 Pad on both my desktop PC and laptop. Both have different hardware (AMD and Intel), but almost the exact same Arch Linux configuration. Conditions: Plugged in controller with the computer off Booted into Arch Linux * Ran "jstest /dev/input/js0" and monitored output Desktop PC (Ryzen 3700X on X570 UD) - T16000M Shows the symptom already reported (rolling to the left after fgfs start) jstest /dev/input/js0 Driver version is 2.1.0. Joystick...
-
As promised, some more testing with the T16000M and the XBox 360 Pad on both my desktop PC and laptop. Both have different hardware (AMD and Intel), but almost the exact same Arch Linux configuration. Conditions: Plugged in controller with the computer off Booted into Arch Linux * Ran "jstest /dev/input/js0" and monitored output Desktop PC (Ryzen 3700X on X570 UD) - T16000M Shows the symptom already reported (rolling to the left after fgfs start) jstest /dev/input/js0 Driver version is 2.1.0. Joystick...
-
As promised, some more testing with the T16000M and the XBox 360 Pad on both my desktop PC and laptop. Both have different hardware (AMD and Intel), but almost the exact same Arch Linux configuration. Conditions: Plugged in controller with the computer off Booted into Arch Linux * Ran "jstest /dev/input/js0" and monitored output Desktop PC (Ryzen 3700X on X570 UD) - T16000M Shows the symptom already reported (rolling to the left after fgfs start) jstest /dev/input/js0 Driver version is 2.1.0. Joystick...
-
As promised, some more testing with the T16000M and the XBox 360 Pad on both my desktop PC and laptop. Both have different hardware (AMD and Intel), but almost the exact same Arch Linux configuration. Conditions: Plugged in controller with the computer off Booted into Arch Linux * Ran "jstest /dev/input/js0" and monitored output Desktop PC (Ryzen 3700X on X570 UD) - T16000M Shows the symptom already reported (rolling to the left after fgfs start) jstest /dev/input/js0 Driver version is 2.1.0. Joystick...
-
Tested with an XBox 360 pad on my laptop running Arch Linux. Controls initialize just fine after a cold boot. Might be an issue specific to a controller or driver. Will retest on my desktop PC once I get home again.
-
Aircraft controls initialize with full left deflection after the first fgfs launch
-
This is still happening with 2019.2.0 (on Linux). Reproduced with anything that involves resetting like changing to the Launcher from the simulator and clicking "Fly Now" or hitting Shift+ESC. Git log output: fg: commit 22de9d30b518646894ac190cc6b04371daa6d5c2 (HEAD -> next, origin/next, origin/HEAD) sg: commit d5957b8c5f2188674eb6b3d480bd8eb70d253f79 (HEAD -> next, origin/next, origin/HEAD) Built against OSG 3.6.4. Attached is the fgfs.log and a GDB trace.
-
This is still happening with 2019.2.0. Reproduced with anything that involves resetting like changing to the Launcher from the simulator and clicking "Fly Now" or hitting Shift+ESC. Git log output: fg: commit 22de9d30b518646894ac190cc6b04371daa6d5c2 (HEAD -> next, origin/next, origin/HEAD) sg: commit d5957b8c5f2188674eb6b3d480bd8eb70d253f79 (HEAD -> next, origin/next, origin/HEAD) Built against OSG 3.6.4. Attached is the fgfs.log and a GDB trace.
1