/sim/startup/splash-progress)
- a string in /sim/startup/splash-title is displayed on top of the screen
and by default empty
- the splash image is scaled down if 512x512 is too big
- code cleanup
have a "property" mode as well as the original "binary" mode. The property mode
will allow the remote module to request any set of properties, and it will send
those properties each frame. The remote module can reply with a list of arbitrary
property name/value pairs to update on the FlightGear side.
This is a first stab, so it's not the cleanest, most well concieved code, but it
allows an external module (communicating via a pipe) to have a huge amount of
flexibility in the data in can access and update.
I just heard from John Wojnaroski that you and he are going to work on getting
a flightgear demo machine up for the linux expo thursday and Friday. John
indicated that he would very much like to get a CVS version with the new
traffic code up and running before the expo.
RE: --aircraft=ufo in system.fgfsrc is ignored
To change a 'feature', one that has been mentioned here many
times, and again recently, place the following code block
into fgInitFGAircraft.
In its favour, I would argue this means FG can be run without
a command line, provided FG_ROOT has been set in the
environment, and that seems to me, as it should be ... ;=))
Perhaps the only counter, is that system.fgfsrc is read twice,
but so are others, like .fgfsrc, for other (local) options ...
or system.fgfsrc should .nt. be used for 'aircraft' ?
a single apt.dat.gz file which is in the native X-Plane format.
To do this I wrote a front end loader than builds the airport and runway
list. Some of the changes I needed to make had a cascading effect, so there
are minor naming changes scattered throughout the code.
I've finished the emigration of the radiostack, and I've also removed it
completely. It turned out that the comm radio is completely implemented in
the ATC subsystem. I've changed the affected ATC files to point
to /instrumentation/com, but I guess that the maintainer of the ATC code
should decide wether to make it configureable, and how.
I also had to change some files in Network and Main. The changes in network
should be obvious, but the changes in Main were a bit suspect. The files
included radiostack.hxx, but they weren't directly depending on
radiostack-hxx. They were depending on other files that were included by
radiostack.hxx. I got it to compile, but I'm not sure if I included the
correct directly depending file.
For the data directory I changed every occurrence of /radios/
with /instrumentation/ with this simple one-liner that I found on the net:
find -name '*.xml' -type f | xargs perl -pi -e
's/\/radios\//\/instrumentation\//g'
Instead of me sending all the files that got changed by this I suggest that
you execute the one-liner yourself. Of course I can not guarantee that this
will work perfectly, but I considered hand editing to be not an option (I'm
lazy). I don't want to test every aircraft to see if everything still works,
I think it's better to wait and see if anyone complaints about broken nav
radios/instruments.
Don't overwrite user settings from config files.
fgfs had in any case set bump-mapping to false, no matter if this
node did already exist (because it was defined in a config file).
A good elevation is critical for proper glide slope modeling. This patch
assigns the average field elevation to any ILS component that doesn't have
a valid elevation.
Also, for an ILS approach, use the GS transmitter elevation for glide slope
calculations rather than the localizer elevation, in some cases this can
make a big difference.
These change add some code that at initialization time will snap all
localizers into perfect alignment with their runways. It's my experience
that the DAFIF/FAA data reports runway and localizer headings to a level
of precision that is great for making charts, or adjusting your OBS, etc.
But the level of precision of this data can be far enough off to make you
visibly *un*aligned with the runway when the CDI needle is centered.
There are probably cases where the localizer isn't really perfectly
aligned with the runway, or intentionally misaligned to avoid obstacles
or terrain. So I have made this configurable for those that trust the
data more than I do. Just set "/sim/navdb/auto-align-localizers" to
true/false in the preferences file to turn this feature on or off in the
code.
- 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.
are many recognized limitations and inefficiencies with this entire approach,
however, it's a quick and dirty way to get something working, where before
we didn't.
Here's a patch to locate the base package inside the application bundle on OS-X. The patch also disables the CPSForeground hack in boostrap.cxx, which is unnecessary if the we're running as a proper bundle rather than a Unix command line program.
Both of these changes are only compiled if OSX_BUNDLE is defined (I'm doing this via a setting in ProjectBuilder), so if you're building on OS-X using configure + make, you shouldn't see any chance.
