fly/fgdata
1
0
Fork 0
Code Activity
fgdata/Data/AI/nimitz_demo.xml

60 lines
1.9 KiB
XML
Raw Normal View History

fix DOS line ending
2005-07-01 06:23:13 +00:00
<?xml version="1.0"?>
<!--
x, y, z-offset-m The distance in meters of the Fresnel Lens Optical Landing System
(FLOLS) from the carrier model origin.
-->
<PropertyList>
<scenario>
<entry>
<type>carrier</type>
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the
2005-03-19 09:56:35 +00:00
<name>Nimitz</name>
<pennant-number>CVN-68</pennant-number>
fix DOS line ending
2005-07-01 06:23:13 +00:00
<model>Models/Geometry/Nimitz/carrier.xml</model>
<wire>wire-1</wire>
<wire>wire-2</wire>
<wire>wire-3</wire>
<wire>wire-4</wire>
<catapult>cat-1</catapult>
<catapult>cat-2</catapult>
<catapult>cat-3</catapult>
<catapult>cat-4</catapult>
<solid>Deck</solid>
<solid>Round-down</solid>
<solid>Elevator-3-Deck</solid>
<solid>Elevator-4-Deck</solid>
Mathias Fröhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:42:09 +00:00
<latitude>37.689</latitude>
<longitude>-122.683</longitude>
fix DOS line ending
2005-07-01 06:23:13 +00:00
<speed>10</speed>
Mathias Fröhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:42:09 +00:00
<heading>180</heading>
fix DOS line ending
2005-07-01 06:23:13 +00:00
<rudder>0</rudder>
<turn-radius-ft>3000</turn-radius-ft>
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the
2005-03-19 09:56:35 +00:00
<flols-pos>
<x-offset-m>69.84</x-offset-m>
<y-offset-m>-39.67</y-offset-m>
<z-offset-m>21.47</z-offset-m>
</flols-pos>
<parking-pos>
Mathias Fröhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:42:09 +00:00
<name>cat-2</name>
<heading-offset-deg>-1</heading-offset-deg>
<x-offset-m>5</x-offset-m>
<y-offset-m>26</y-offset-m>
<z-offset-m>-3.26</z-offset-m>
</parking-pos>
<parking-pos>
<name>cat-1</name>
<heading-offset-deg>-9</heading-offset-deg>
<x-offset-m>0.0401001</x-offset-m>
<y-offset-m>26</y-offset-m>
<z-offset-m>17</z-offset-m>
</parking-pos>
<parking-pos>
<name>park-1</name>
<heading-offset-deg>-90</heading-offset-deg>
<x-offset-m>54.33</x-offset-m>
<y-offset-m>26</y-offset-m>
<z-offset-m>20</z-offset-m>
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the
2005-03-19 09:56:35 +00:00
</parking-pos>
fix DOS line ending
2005-07-01 06:23:13 +00:00
</entry>
</scenario>
</PropertyList>
Copy permalink