The new multiplayer patch with an extension to transmit some properties with
the base package. The properties are transmitted in a way that will not
immediately brake the packet format if we need new ones.
Even if the maxmimum number needs to be limited somehow, that format might
work well until we have an improoved packet format which is even more compact
and that does not require to retransmit redundant information with each
packet.
That part is relatively fresh and based on that what Oliver provides on his
multiplayer server web page.
The properties are transferred to the client and I have modified the seahawks
rudder animation property to use a relative property path to verify that it
works appart from the fact that you can see it changing in the property
browser.
The movement is still a bit jerky, but that can be fixed/tuned later without
again braking the packet format.
* in some cases more specific sg exception types were used in place
of the more generic one, e.g., sg_io_exception instead of sg_exception
when the context of the error was an IO error
* in some cases, the error message was made more specific
* minor style fix for exception rethrowing --- using throw; whenever
a re-throw is made; sometimes optimizing away the exception symbol name
in the catch handler at all
* more specific catch handlers added in some places -- e.g.,
an sg_io_exception caught ahead of sg_exception
I stumbled across two memory errors with two wrong const references to
std::string.
As I fixed that, I also moved aircraft_dir which is only used from UIUC into
UIUC. With that uiuc_aircraftdir.h is empty and can be removed.
Changes
=======
- acmodel.cxx :
we now have an optional new property (/sim/model/texture-path) that is used
as the first path in wich aircraft textures are searched. If textures are not
found there then the usual texture path or model path is used ;
This allows to replace only needed textures for liveries ;
- options.cxx :
added a new --livery=xxx option for the user pleasure ;
this will just set the /sim/model/texture-path property with /livery/xxxx
- od_gauge.cxx, og_gauge.hxx, cockpit.cxx, cockpit.hxx,
generic-instrumentation.xml :
added an helper class that contain a rendering context for glass instrument
or any other opengl drawn instrument ;
- wxradar.cxx, instrument_mgr.cxx, wxradar.hxx :
first experimentation of a weather radar ;
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.
I have added a --aspect-ratio-multiplier=x.xx option to give some end user
control over the aspect ratio. (This may seem a little strange, but it's a
building block towards the capability of doing asymmetric view frustums in
FlightGear.)
After applying the attached patches (based on latest CVS) you should
have a new option available within your version that should also
show up using fgfs --help, the syntax is:
fgfs --min-status={level} --show-aircraft
whereas "level" can be anything between
"alpha","beta","early-production" and "production"
Of course running something like
fgfs --min-status=alpha --show-aircraft
should not return any aircraft right now, as none of the
current aircraft definition files in your base-package is using the
required
<status></status>
tag - but you can easily give it a try by adding something like
<status>alpha</status>
The tag should be placed as a sub-tag within <sim> - so directly behind
the <description> tag would be just fine and straight-forward.
I restored the output to cout / cerr
for the options and the warning for the version mismatch.
There is a dummy SG_LOG to allow the windows version to
popup the console.
The snapshot rendering use multipass now.
trying the --show-aircraft option, I noticed that I had
no output. This is because there are still output to
cout or cerr, that are not triggering my console patch
for windows. The patch attached use SG_LOG instead.
A request to hit a key is also added because otherwise,
the console window will disappear as soon as the program
stop.
This problem is minor though given the fact that fgfs.exe
is shipped with fgrun that do show the available aircraft
in a much nicer manner.
$FGROOT/data/Aircraft hierarchy. There could be some long term performance
concerns if a person has a *huge* collection of aircraft or a really slow
file system, but I see zero performance blip here from recursing the default
CVS tree. We should also allow the user to specify the whole path to the
-set.xml file if they don't want to recurse ... this way we could eventually
come up with an aircraft selection dialog box on the front end so the user
could manually walk the tree to the desired aircraft. There also the system
wouldn't have to search for the aircraft.
Square the normalized direction acceleration for the y and z axes, so
that turbulence predominantly affects pitch.
Bind to the /environment/turbulence/magnitude-norm and
/environment/turbulence/rate-hz properties in FlightGear.
