[Flightgear-devel] Default QT_launcher aircraft library storage location

[Wayne Bragg]

A user wants to change the QT-launcher's default storage location for
fgaddon aircraft. Is this possible?

Please see
https://forum.flightgear.org/viewtopic.php?f=11&t=32259&p=313736#p313736

Thanks,
Wayne

[Hamza Alloush]

On 2017-07-06 1:59 AM, Parnikkapore via Flightgear-devel wrote:
> On 2017-07-05 6:18 PM, Wayne Bragg wrote:
>> A user wants to change the QT-launcher's default storage location for
>> fgaddon aircraft. Is this possible?
>>
>> Please see
>> https://forum.flightgear.org/viewtopic.php?f=11&t=32259&p=313736#p313736
>
> Shouldn't the Download Location setting work?
>

Since 2017.2.1, explicit download-dir will no longer create catalog to
that location, unlike scenery, aircraft will still download to the
default location regardless, additionally in Windows(clean OS install,
same drive), if explicit download-dir is set, starting catalog aircraft
from the default location will report reading permission problem for
Nasal files, unless --allow-nasal-read is passed and set to where
catalog /Aircraft folder is located[1], user will report the issue as
blank Canvas displays, missing huds from aircraft, etc for catalog
fgaddon aircraft on Flightgear 2017.2.1

[1] in Windows 10, if i specify explicit path for download-dir, i must
pass
--allow-nasal-read=C:/Users/Hamza/Documents/FlightGear/Aircraft/org.flightgear.fgaddon/
for Nasal to work on catalog aircraft.

* I can also work around this by passing
--fg-aircraft=C:/Users/Hamza/Documents/FlightGear/Aircraft/org.flightgear.fgaddon/
, this will add an /Aircraft postfix to that path, under
"/sim/fg-aircraft[1]"

Hamza

[James Turner]

> On 6 Jul 2017, at 16:53, Hamza Alloush <***@live.com> wrote:
>
> Since 2017.2.1, explicit download-dir will no longer create catalog to
> that location, unlike scenery, aircraft will still download to the
> default location regardless, additionally in Windows(clean OS install,
> same drive), if explicit download-dir is set, starting catalog aircraft
> from the default location will report reading permission problem for
> Nasal files, unless --allow-nasal-read is passed and set to where
> catalog /Aircraft folder is located[1], user will report the issue as
> blank Canvas displays, missing huds from aircraft, etc for catalog
> fgaddon aircraft on Flightgear 2017.2.1

This is a bug, not sure how it got messed up. Will fix before the next release.

However, I’m unsure if ‘explicit download dir’ means in the launcher GUI, or on the command line?

If you could detail the configurations you’ve tried, and what result, it would help.

Kind regards,
James

[Hamza Alloush]

On 2017-07-18 5:30 PM, James Turner wrote:

On 6 Jul 2017, at 16:53, Hamza Alloush <***@live.com<mailto:***@live.com>> wrote:

Since 2017.2.1, explicit download-dir will no longer create catalog to
that location, unlike scenery, aircraft will still download to the
default location regardless, additionally in Windows(clean OS install,
same drive), if explicit download-dir is set, starting catalog aircraft
from the default location will report reading permission problem for
Nasal files, unless --allow-nasal-read is passed and set to where
catalog /Aircraft folder is located[1], user will report the issue as
blank Canvas displays, missing huds from aircraft, etc for catalog
fgaddon aircraft on Flightgear 2017.2.1

This is a bug, not sure how it got messed up. Will fix before the next release.

However, I’m unsure if ‘explicit download dir’ means in the launcher GUI, or on the command line?

If you could detail the configurations you’ve tried, and what result, it would help.


For both of my platforms tested(a machine that has both Windows 10 and Linux Mint in dual boot), I found that passing '$fgfs --launcher --download-dir' set to my desired location worked on both of the Flightgear versions[1] to allow create a catalog to that location when pressed "Restore default aircraft hangar" under the Add-ons tab in Launcher[2], omitting passing that command line option, the FGFS 2017.2.1 Launcher option under Downloads seems to be just a place holder, and would create catalog to the default location or whatever what was set in the Flightgear.ini file in the "download-dir" under the [General] section, from previous installations[3].

I should also mention there's a segfault occurring after you've created and removed a catalog in the same session using the Launcher.

I have not mentioned the Nasal problem because i have not looked for it in testing at this time, let me know if you want me to test it but i might have to find some time.

[1] I haven't tested if the option under Downloads in the launcher for the working version, would override the settings passed from the command line.

[2] FGFS 2017.1.3(working) and 2017.2.1(non-working)

[3] In Flightgear.ini, the launcher in FGFS 2017.1.3 would set "download-dir=" under the [General] section, which worked, while in 2017.2.1 it would set "downloadDir=" under the [downloadSettings] section and does not apply for change your desired download location.

Best,
Hamza

[James Turner]

> On 19 Jul 2017, at 16:08, Hamza Alloush <***@live.com> wrote:
>
> For both of my platforms tested(a machine that has both Windows 10 and Linux Mint in dual boot), I found that passing '$fgfs --launcher --download-dir' set to my desired location worked on both of the Flightgear versions[1] to allow create a catalog to that location when pressed "Restore default aircraft hangar" under the Add-ons tab in Launcher[2], omitting passing that command line option, the FGFS 2017.2.1 Launcher option under Downloads seems to be just a place holder, and would create catalog to the default location or whatever what was set in the Flightgear.ini file in the "download-dir" under the [General] section, from previous installations[3].

Uh, this is somewhat a confusing sentence to understand! Apologies, maybe I am simply tired, but I need some help to understand what you mean. Being a programmer I prefer lists and bullet-points :)

I /think/ you are saying, but please correct me:

- on both Linux and Windows 10, passing $fgfs --launcher --download-dir works in both 2017.1 *and* 2017.2

- *without* the option (so as a normal user would run the sim, simply with —launcher), downloads occur to the default download directory

The default download dir is:

$FG_HOME on Linux and Mac, i.e $HOME/.fgfs on Linux
$USERDIR\Documents\FlightGear on Windows, e.g C:\Users\James\Documents\FlightGear

If this is what you are saying, what do you see as the problem here? Because based on my understanding, this is working correctly, and should be the same for 2017.1 *and* 2017.2

I have not tested how setting —download-dir on the command line, and also setting the value inside the launcher interact, BTW.

Kind regards,
James

[Hamza Alloush]

On 2017-07-19 6:34 PM, James Turner wrote:

Uh, this is somewhat a confusing sentence to understand! Apologies, maybe I am simply tired, but I need some help to understand what you mean. Being a programmer I prefer lists and bullet-points :)

I /think/ you are saying, but please correct me:

- on both Linux and Windows 10, passing $fgfs --launcher --download-dir works in both 2017.1 *and* 2017.2

- *without* the option (so as a normal user would run the sim, simply with —launcher), downloads occur to the default download directory

The default download dir is:

$FG_HOME on Linux and Mac, i.e $HOME/.fgfs on Linux
$USERDIR\Documents\FlightGear on Windows, e.g C:\Users\James\Documents\FlightGear

If this is what you are saying, what do you see as the problem here? Because based on my understanding, this is working correctly, and should be the same for 2017.1 *and* 2017.2

I have not tested how setting —download-dir on the command line, and also setting the value inside the launcher interact, BTW.

The problem is that in FG 2017.2.1 aircraft are only downloading to the default location regardless of what the Download Location settings is set to in the launcher.

It is "always' downloading to the default location or what whatever is set in the Flightgear.ini file under the [General] section.

Best,
Hamza

[James Turner]

> On 19 Jul 2017, at 16:45, Hamza Alloush <***@live.com> wrote:
>
> The problem is that in FG 2017.2.1 aircraft are only downloading to the default location regardless of what the Download Location settings is set to in the launcher.
>
> It is "always' downloading to the default location or what whatever is set in the Flightgear.ini file under the [General] section.

Okay, so to be clear:

- passing —download-dir works fine
- using the default download location works fine
- changing the download location fro the launcher doesn’t work? (But did work in 2017.1)

Correct?

Kind regards,
James

[Hamza Alloush]

On 2017-07-19 6:57 PM, James Turner wrote:

On 19 Jul 2017, at 16:45, Hamza Alloush <***@live.com<mailto:***@live.com>> wrote:

The problem is that in FG 2017.2.1 aircraft are only downloading to the default location regardless of what the Download Location settings is set to in the launcher.

It is "always' downloading to the default location or what whatever is set in the Flightgear.ini file under the [General] section.

Okay, so to be clear:

- passing —download-dir works fine
- using the default download location works fine
- changing the download location fro the launcher doesn’t work? (But did work in 2017.1)

Correct?

That's correct :)

Best,
Hamza

[James Turner]

> On 19 Jul 2017, at 17:02, Hamza Alloush <***@live.com> wrote:
>
>> Okay, so to be clear:
>>
>> - passing —download-dir works fine
>> - using the default download location works fine
>> - changing the download location fro the launcher doesn’t work? (But did work in 2017.1)
>>
>> Correct?
>
> That's correct :)

Excellent, thank you for your patience in helping me understand!

Now, hopefully it will be easy to fix
.

James

[James Turner]

> On 19 Jul 2017, at 17:12, James Turner <***@kdab.com> wrote:
>
> Excellent, thank you for your patience in helping me understand!
>
> Now, hopefully it will be easy to fix
.

I pushed some fixes for this, it should work again. I also made the interaction of command-line and launcher-setting more robust; if you set download-dir on the command line, the launcher won’t interfere, and disables its own UI to edit download-dir, to avoid any confusion.

Only on next for now, I’m not sure if we would make a 2017.2.2 for this?

Kind regards,
James

[Pui Lau]

This post might be inappropriate. Click to display it.

[w***@gmail.com]

On 07/19/2017 11:48 AM, Pui Lau wrote:
> Dear Hamza
>
>
> As I need to download the Spitfire zip folder from:
> http://mirrors.ibiblio.org/flightgear/ftp/Aircraft/, so I can install in to
> FlightGear and being able to use in Simulink.

please don't hijack existing topics :(


--
NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list unless*
*a signed and pre-paid contract is in effect with us.*

[Wayne Bragg]

> On 2017-07-06 1:59 AM, Parnikkapore via Flightgear-devel wrote:
> > On 2017-07-05 6:18 PM, Wayne Bragg wrote:
> >> A user wants to change the QT-launcher's default storage location for
> >> fgaddon aircraft. Is this possible?
> >>
> >> Please see
> >>https://forum.flightgear.org/viewtopic.php?f=11&t=32259&p=313736#p313736
> >
> > Shouldn't the Download Location setting work?
> >
>
> Since 2017.2.1, explicit download-dir will no longer create catalog to
> that location, unlike scenery, aircraft will still download to the
> default location regardless, additionally in Windows(clean OS install,
> same drive), if explicit download-dir is set, starting catalog aircraft
> from the default location will report reading permission problem for
> Nasal files, unless --allow-nasal-read is passed and set to where
> catalog /Aircraft folder is located[1], user will report the issue as
> blank Canvas displays, missing huds from aircraft, etc for catalog
> fgaddon aircraft on Flightgear 2017.2.1
>
> [1] in Windows 10, if i specify explicit path for download-dir, i must
> pass
> --allow-nasal-read=C:/Users/Hamza/Documents/FlightGear/Aircraft/org.flightgear.fgaddon/
> for Nasal to work on catalog aircraft.
>
> * I can also work around this by passing
> --fg-aircraft=C:/Users/Hamza/Documents/FlightGear/Aircraft/org.flightgear.fgaddon/
> , this will add an /Aircraft postfix to that path, under
> "/sim/fg-aircraft[1]"
>
> Hamza

Thank you Hamza for the information and workaround.

As a follow up from the forum and the user that brought this issue up...

>by *Flyngo
<https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=20129>*
» Fri Jul 07, 2017 3:50 am
> Okay, thanks very much, mystery solved.
>
> So (if I understand this right) in FG 2017.2.1 the possibility to have
> the fgaddon aircraft on a different drive than C: is no more. Reason
> unclear, logic same. Good to know that it is not that I am crazy or
> Windows is crazy (normally it is Windows that does the Kindergarden
> user always new restrictions thing 8) ).
>
> [snip]
>
> Suggestion: As changes like this in new FG versions can throw off
> users who have non-standard installations (e.g. out of drive size
> issues in my case), wouldn't it be nice if the launcher warned? The
> launcher should say (under the Settings/Downloads in the QT menu,
> "Show more", "Download location") that the dl location for aircraft
> can only be on C:. And it should give separate aircraft and scenery
> location paths, as scenery CAN be on a different drive.
>
> Else there may be some users who sit there with a shiny new FG like
> the ox in front of the mountain (as we say in Germany for "being
> reasonably irritated") and give up (in case they don't persist to
> bother others like Flyngo did :mrgreen: ).

My response to @*Flyngo
<https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=20129>

*
>
> by *wlbragg
> <https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=13472>*
> » Fri Jul 07, 2017 9:36 pm
>
> Yeah, I'm not privy as to the why it behaves this way or if the change
> was intentional. I guess it really needs to be addressed on the
> developers list at some point.
> One thing I do understand is that there are less than a small handful
> of programmers that work on this portion of logic and that they also
> are working on many other issues and features. So this is probably on
> the lower priority TODO list.
>
> I passed this on to the dev list just now. Maybe they can explain the
> what and whys.
> *
> *

Thanks for your attention,

Wayne
*
*