Board index FlightGear Development

FG 2019.1.1 problem with carrier scenario

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

FG 2019.1.1 problem with carrier scenario

Postby mhab » Sun Apr 12, 2020 9:55 pm

If in FG 2019.1.1 I use commandline switches:
    --ai-scenario=truman_demo
    --carrier=Truman
I end up with carrier Truman loaded 2 times in property tree under ai/models/carrier and ai/models/carrier[1]
If I don't use --carrier=Truman argument it is loaded one time, but the aircraft is not positioned on the carrier.

In FG 2018 that was working as expected, with the carrier present only once in property tree.
I found no change in scenario contents, no change in FG manual and so I think this seems to be a bug ?

Any thoughts on this ?

Thanks
Mike-DE
mhab
 
Posts: 418
Joined: Thu Apr 18, 2013 11:59 pm
Callsign: D-MIKE
Version: 2020.3.4
OS: Win10

Re: FG 2019.1.1 problem with carrier scenario

Postby wkitty42 » Mon Apr 13, 2020 3:41 pm

the manual is likely out of date... there was some talk about this on the dev list...

what happens if you use only "--carrier=Truman"?? i know there's been work in this area in the last week or two but i don't know if it has been back ported to 2019.1.1 from the "next" branch...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FG 2019.1.1 problem with carrier scenario

Postby mhab » Mon Apr 13, 2020 6:49 pm

If I use only "--carrier=Truman" as commandline argument the carrier is loaded and the aircraft is placed on deck.
So how am I supposed to get the whole scenario defined in "truman_demo.xml" ? Escorts, etc.

B.T.W.: I can understand that the manual is outdated. But if also the Wiki pages remain unchanged it seems to me FG is only to be used by those geeks who follow the developer mailing list ?
mhab
 
Posts: 418
Joined: Thu Apr 18, 2013 11:59 pm
Callsign: D-MIKE
Version: 2020.3.4
OS: Win10

Re: FG 2019.1.1 problem with carrier scenario

Postby stuart » Mon Apr 13, 2020 7:08 pm

Hi mhab,

I've just tested with the ufo on "next", and if I use the --carrier=Truman commandline argument I see the carrier and all the escort ships as well.

So I suspect some time before 2019.1 the code was changed to automatically load the full AI scenario if --carrier was used.

I've updated the wiki page accordingly. Note that anyone can update the wiki page, so feel free to make further updates.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: FG 2019.1.1 problem with carrier scenario

Postby mhab » Mon Apr 13, 2020 10:13 pm

OK
That would mean: It is only possible to have one scenario with the carrier of choice, because it is automatically loaded ?

I was used to having several scenarios depending on where I want to have the carrier ...

I can live with this limitation and will adapt my usage of this.
mhab
 
Posts: 418
Joined: Thu Apr 18, 2013 11:59 pm
Callsign: D-MIKE
Version: 2020.3.4
OS: Win10

Re: FG 2019.1.1 problem with carrier scenario

Postby wkitty42 » Tue Apr 14, 2020 1:34 am

is there no chance for the creation of, say, a truman2 scenario file that --carrier=truman2 would load?

i don't know if the load processing of --carrier is done by C code or nasal on startup... if done by nasal, adding more scenarios should be fairly easy...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FG 2019.1.1 problem with carrier scenario

Postby stuart » Tue Apr 14, 2020 8:53 am

@mhab - I don't think there's anything to stop you from enabling multiple scenarios (though you should test this), just that the launcher/startup will helpfully load the required scenario for you. Equally, you can create an AI scenario file that contains multiple carriers (in fact the Nimitz_demo does exactly this).

@wkitty - this is done by the core simulator.
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: FG 2019.1.1 problem with carrier scenario

Postby mhab » Tue Apr 14, 2020 11:47 am

Maybe I misinterprete what FG is doing when it loads the scenario for a given carrier.

My idea was, that it scans available scenarios and loads the first one which contains the carrier of choice.

If I cannot specify which scenario to use ( as the scenario commandline switch results in double loaded carrier) so how should I control which scenario of the given carrier to use ?
mhab
 
Posts: 418
Joined: Thu Apr 18, 2013 11:59 pm
Callsign: D-MIKE
Version: 2020.3.4
OS: Win10

Re: FG 2019.1.1 problem with carrier scenario

Postby Hooray » Sat Apr 18, 2020 3:48 pm

wkitty42 wrote in Tue Apr 14, 2020 1:34 am:is there no chance for the creation of, say, a truman2 scenario file that --carrier=truman2 would load?

i don't know if the load processing of --carrier is done by C code or nasal on startup... if done by nasal, adding more scenarios should be fairly easy...


Like Stuart said, this is implemented in C++ - I believe it was originally implemented by FredB in the early 2000s, i.e. it's all pre-dating Nasal by ~3-5 years.

For reference, options processing takes place in $FG_SRC/Main/options.cxx: https://sourceforge.net/p/flightgear/fl ... ptions.cxx

Specifically, you will want to look at the following array/table of hard-coded options (make sure to pay attention to the comments at the top): https://sourceforge.net/p/flightgear/fl ... .cxx#l1597

You will find the "ai-scenario" option being set up here: https://sourceforge.net/p/flightgear/fl ... .cxx#l1847

The final argument in that line said that a function is called for further processing, it's called fgOptScenario - which is to be found here: https://sourceforge.net/p/flightgear/fl ... .cxx#l1420

It would actually be relatively useful/easy to support Nasal for options processing purposes - and it was also discussed in the context of addons potentially coming with their own addon specific startup arguments. There is however the long-standing issue that Nasal initialization is taking place much later in the process, i.e. the Nasal interpreter is not yet available when options processing takes place. This is relatively easy to change, and we do have working patches for this, which were prototyped at the encouragement of James Turner who repeatedly expressed interest in being able to initialize Nasal earlier: http://wiki.flightgear.org/Initializing_Nasal_early

However, more recently this has no longer been a priority apparently - that being said, for this particular use-case (options processing in scripting space), a temporary Nasal instance would suffice, and would be really easy to set up - bugman (Edward) and James are already using this approach for unit testing purpose, i.e. they set up a standalone interpreter instance to test certain Nasal functionality outside of fgfs.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to Development

Who is online

Users browsing this forum: No registered users and 3 guests