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.
or write to the color properties in /sim/screen/. If this Nasal/GUI
implementation turns out to be too slow, we'll write a generic OpenGL/plib
version simliar to the ATCdisplay code. (OK'ed by Andy and Stuart)
- Provide a Nasal interface to display simple text messages on the screen
like the ATC display. In fact, I copied the code from the ATCDisplay.cxx
and simply shifted it further down the screen.
Erik:
TODO: Integrate the two pieces of code.
This adds a TACAN instrument to the inventory. Range and bearing are calculated
to the TACAN or VORTAC beacon selected by means of the Channel Selector in the E
quipment/Radio pull-down menu.
A TACAN beacon has also been added to the aircraft carrier Nimitz (channel #029Y
).
ssgSetNearFar(). This by default creates a symmetric view frustum which is
typically what an application wants.
However, to get control of the view frustum in order to build support for
asymmetric view frustums, we need to wrap these calls with a bit of our own
logic.
This set of changes wraps all calls to ssgSetFOV() and ssgSetNearFar() with
FGRenderer methods.
I also standardized how the FGRenderer class is handled in globals.[ch]xx.
This led to some cascading changes in a variety of source files.
As I was working my way through the changes, I fixed a few warnings along
the way.
Split up main.cxx into a program manegement part (which remains in
main.cxx) and a render part (the new renderer.?xx files). Also turn
the renderer into a small class of it's own. At this time not really
exctining because most of the stuff is still global, but it allows us
to slowly migrate some of the global definitions into the new class.
The FGRenderer class is now managed by globals, so to get the renderer
just call gloabals->get_renderer()
At some pijt it might be a good idea to also turn the remaining code in
main into a class of it's own. With a bit of luck we end up with a more
robust, and better maintainable code.
Wouldn't it be better to prepare the whole list of paths (or two
separate ones for Terrain/Objects if necessary) in FGGlobals::set_fg_scenery,
and to pass the vector<string>s to FGTileEntry::load? It doesn't seem to make
a lot of sense to split the path up, modify it, mount it together to one string
again, and then let FGTileEntry::load split it up again.
Here we go:
Main/globals.cxx
================
As fg_scenery is now a string_list, we don't need initialization. Furthermore,
this list is cleared with every set_fg_scenery() call.
ctor: create default dir from fg_root if necessary. Otherwise check all paths
of --fg-scenery/FG_SCENERY: If the path doesn't exist, ignore it. If it contains
a dir Terrain and/or Objects, then only add that to the list. If it contains
neither, then use the path as is.
Scenery/tileentry.cxx
=====================
Trivial: don't split a "base path", but use the given path_list as is.
(I considered a variable name "path_list" better suited than "search".)
Scenery/FGTileLoader.cxx
========================
No more fiddling with sub-paths. This has to be delivered by get_fg_scenery
already.
- FG now directly supports Robin's native nav database file format.
- His latest data now separates out dme, gs, loc, and marker beacon
transmitters rather than lumping them all into a single "ILS" record.
- These new data structure changes prompted me to do some code restructuring
so that internally these different types of navaids are all kept as
separate lists and searched and handled separately.
- This structural change had a cascading affect on any code that
references or uses the nav databases. I've gone and "touched" a lot of
nav related code in a lot of places.
- As an added bonus, the new data (and code) adds DME bias so these will
all now read as they do in real life.
- Added Navaids/navdb.cxx and Navaids/navdb.hxx which provide a front
end loaders for the nav data.
- Added Navaids/navrecord.hxx which is a new "generic" nav data record.
- Removed Navaids/ils.hxx, Navaids/ilslist.cxx, Navaids/ilslist.hxx,
Navaids/mkrbeacons.cxx, and Navaids/mkrbeacons.hxx which are all now
depricated.
etc.
Improved the weather system to interpolate between different
elevations and deal with boundary-layer conditions. The configuration
properties are now different (see $FG_ROOT/preferences.xml).
the ascii scenery file format has actually worked in quite some time, and the
ADA runway light code has been supersceded by a slightly different mechanism.
(I thought I'd slip this in along with David's change to the default menu
configure option. I believe that will cause a new config.h to be generated
which will cause a near complete rebuild of FG (as will this globals.hxx
change) so it shouldn't cause additional grief to have these happen at the
same time.)
Here is a FGIO class derived from FGSubsystem that replaces the fgIOInit()
and fgIOProcess() functions. The FGIO::update(double delta) doesn't use the
delta argument yet. I suspect it could be used as a replacement for the
calculated interval value but I'm not familiar enough with that piece of code
just yet.
I've also added two "command properties" to fg_commands.cxx that select the
next or previous view. Writing any value to these properties triggers the
corresponding action. As an example I modified my keyboard.xml:
<key n="118">
<name>v</name>
<desc>Next view</desc>
<binding>
<command>property-assign</command>
<property>/command/view/next</property>
<value type="bool">true</value>
</binding>
</key>
<key n="86">
<name>V</name>
<desc>Prev view</desc>
<binding>
<command>property-assign</command>
<property>/command/view/prev</property>
<value type="bool">true</value>
</binding>
</key>
And of course these actions can also be triggered from external scripts via
the props server.
Animations are now contained within the scene graph itself and are
updated whenever the graph is traversed -- that saves time by not
updating animations not currently in sight, and it allows animations
to be used for static objects and random objects as well.
Added new FGModelLoader and FGTextureLoader classes. These are intern
tables for models, to guarantee (mostly) that no model is loaded more
than once. FGTextureLoader is not yet used anywhere, but
FGModelLoader is now in place everywhere that ssgLoad* used to be
used (thus adding the ability to use animations).
In the future, FGModelLoader will add some interesting functionality,
including the ability to reload 3D models on the fly.
