#2768 Double name of Eisenhower carrier in scenarios conflicts with each other

[Roman Ludwicki]

In the scenarios we have two Eisenhower aircraft carriers, the first in eisenhower_demo and the second in nimitz_demo. The Launcher recognises these carriers and picks up two positions with the Eisenhower carrier, but with different location descriptions: Norfolk VA (eisenhower_demo) and Toulon, France (nimitz_demo) and this is OK.

However, no matter which Eisenhower we select, the one from nimitz_demo will always be used, i.e. even if we indicate Eisenhower near Norfolk VA, we will still land in the Mediterranean next to France.
The problem seems to be that we have the same name Eisenhower in different scenarios, making me think that FG is content with the first better find of the name Eisenhower, which apparently always falls in the nimitz_demo scenario.

The simplest solution to the problem would be to change the names of the aircraft carriers in the XML files of the scenarios, e.g. to Eisenhower1 and Eisenhower2, or Eisenhower and Eisenhower-Toulon (whatever), then FG will not have conflicts in the scenario search and will load the correct one, i.e. according to the indication in the Launcher. But will such a solution be OK?

[eatdirt]

Check this out too:

https://sourceforge.net/p/flightgear/codetickets/2767/

When you're reposition on the carrier, another scenario is created as well. I had the same understanding at first, removed the eisenhower entry from the nimitz_demo, but still have a multiplication of scenarios using the Aircraft repositioning launcher.

[Roman Ludwicki]

This is probably a different case, however. Here it's not a case of duplicate scenario loading, it's the inability to find the right aircraft carrier by having its name duplicated in two scenarios (XML files).

[James Turner]

Ah this is my bad assumption when adding carrier support to the launcher, that carrier names were unique and hence would be sufficient to identify the carrier from the scenaraio. We would need to add an internal ID I guess, to allow the launcher to specify the object it means, same as we already do for VORs with duplicate idents.

[James Turner]

Do the internal UI pieces handle the duplicate name ok, or do we actually have several UI bugs in this area I wonder?

[Roman Ludwicki]

I debugged the code a bit to see how it looks. When we click on an carrier in the Launcher, it runs the LocationController::setCarrierLocation(QString name) method where the name parameter is the name of the carrier, e.g. Eisenhower. This name is then searched in the CarriersLocationModel structure to finally get a CarriersLocationModel::Carrier object from CarrierVec that contains, for example, mScenario as the scenario file name (e.g. eisenhower_demo). I thought this could be our identifier.

However, at this point I don't know how to change the call LocationController::setCarrierLocation(QString name) so that in name we get the name of the scenario and not the name of the carrier. Or maybe even better if we got the carrier index right away from the GUI carriers list which seems to be adequate with the list in CarrierVec mCarriers; so we wouldn't have to search in CarrierVec by any name.

In addition, we also need to properly handle the --carrier=Eisenhower command line option, which also only accepts the name of the carrier (right?) and adding the --ai-scenario=eisenhower_demo option does not fix the problem and the Eisenhower is still loaded from nimitz_demo.

At the moment, this is beyond me.

[James Turner]

Fixing the CarriersLocationModel to use an index is quite doable, but we get the string from the menu, so would need to rely on the index indeed.

However, a scenario can contain multiple carriers, so neither the scenario name /or/ the carrier name is sufficient to gurantee which carrier you get, we would need some index.

As for the --carrier command line option, indeed I think it doesn't check the scenarios list, so again it just searches based on name.