Unfortunately, we don't have an easy way to access the puObjects
only by knowing the respective XML property node, because the
menu structure was built by plib from string lists. That's why
we walk the puMenuBar tree and store {property node}->{puObject*}
pairs in a map. With this infrastructure in place we can now
easily enable/disable entries, but we can also make other changes
to menu buttons as we see need. The structure of puMenuBar is
described in the pui documentation, so it's less of a hack than
it looks. :-)
to other color than "Yeukky Pink"; #undef'ed for older plib versions; plib
patch will be made available in case fgfs 0.9.9 is released before plib 0.8.5
redraw(): redraw gui without distroying dialogs (fgcommand "gui-redaw"/Shift-F10)
This change makes sure that Nasal-generated and dynamic dialogs can be
re-opened correctly when cycling through themes.
because this creates an empty entry if it didn't exist. This made the
activation of the dialog mandatory before the next gui subsystem update()
happened. Otherwise fgfs segfaulted.
right/upper screen edge (analogous to the --geometry spec), assuming
that we never want to draw outside the screen area; for this to work
we need to write the original x/y coords back to overwrite the absolute,
positive values that the layouter stored there
property (e.g. <keynum>49</keynum>). The numbers are the same as in
keyboard.xml. (Could later be replaced/enhanced with <key>Ctrl-a</key>
notation.) This does, of course, only work for widgets with assigned
bindings.
there was the situation where four directories contained jst two files,
of which three directories were aircraft related, and one directory contained
test code from Curt that might be better of in SimGear anyhow.
This is just a patch to move a bunch of files to new locations. In case of
local changes to any of them you can do the following:
move replay.[ch]xx from src/Replay to src/Aircraft
move control.[ch]xx from src/Control to src/Aircraft
move ssgEntityArray.[ch]xx from src/Objects to simgear/screen
In addition it has been decided only to use .[ch]xx files in all directories
unless it's contained within an FDM specific directory, in which case the
author is free to do whatever (s)he wants.
In this repspect the following files have been renamed in src/Multiplayer:
tiny_xdr.[ch]pp has become tiny_xdr.[ch]xx
multiplaymgr.[ch]pp has become multiplaymgr.[ch]xx
it isn't there, this is a bug. Thus centralize the error message so that it
doesn't have to be repeated everywhere. Of course, the calling code should
still consider that a returned property node may be 0.
CygWin/gcc-3.4.4 updates.
I replaced my cygwin compiler with 3.4.4, did a make clean of plib, simgear,
and flightgear, then did a make install of all three. With the included changes,
everything builds fine, and runs fine.
or data blocks) from layouter and dialog creator. This is required for
dynamically generated/modified dialogs. Parts in the XML file can be
hidden and turned on by the C++ code. Other hidden parts can be used
as templates that are multiply used. Hidden datablocks can contain
strings that are used in dialog context, that are easier to translate
or modify in the XML file.
I have done a valgrind run in flightgear. Just start it up and close it at the
fist change I had about half an hour later.
source-leak.diff:
Also two minor ones, but leaks ...
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
).
Attached is a patch to the airport data storage that I would like committed
after review if acceptable. Currently the storage of airports mapped by ID
is by locally created objects - about 12 Meg or so created on the stack if
I am not mistaken. I've changed this to creating the airports on the heap,
and storing pointers to them - see FGAirportList.add(...) in
src/Airports/simple.cxx. I believe that this is probably better practice,
and it's certainly cured some strange problems I was seeing when accessing
the airport data with some gps unit code. Changes resulting from this have
cascaded through a few files which access the data - 11 files are modified
in all. Melchior and Durk - you might want to test this and shout if there
are problems since the metar and traffic code are probably the biggest
users of the airport data. I've also added a fuzzy search function that
returns the next matching airport code in ASCII sequence in order to
support gps units that have autocompletion of partially entered codes.
More generally, the simple airport class seems to have grown a lot with the
fairly recent addition of the parking, runway preference and schedule time
code. It is no longer just an encapsulation of the global airport data
file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!).
My personal opinion is that we should look to just store the basic data in
apt.dat for all global airports in a simple airport class, plus globally
needed data (metar available?), and then have the traffic, AI and ATC
subsystems create more advanced airports for themselves as needed in the
area of interest. Once a significant number of airports worldwide have
ground networks and parking defined, it will be impractical and unnecessary
to store them all in memory. That's just a thought for the future though.
Somehow the MIPSpro compiler doesn't like an STL map entry being called
using a variable when the reference is an object and not a pointer to an
object.
Preliminary support for a fontcache is added which prevents fonts from
being loaded more than once and takes care of freeing them up again.
The fontcache isn't used yet since there seems to be a problem somewhere.
I have traced that reset on carrier problem down to several problems. One of
them is the fact that on reset the carrier is updated while the aircraft is
not. That made the aircraft drop down an elevator sometimes. Depending on the
passed realtime while loading some parts of the scenery.
LayoutWidget::setDefaultFont() wants puFont* /and/ pointsize as extra
parameters, when puFont knows its pointsize anyway. Didn't want to change
that yet, though.) Now the HELVETICA_10 font makes actually sense. :-)
font similar to Helvetica/Swiss. The license doesn't allow to redistribute
modified fonts under the original name. While it's only a converted font,
and not manually modified, it can no longer be seen as original. Changes
so far are (a) conversion from vector to bitmap, (b) different empty space
width, (c) different & constant gap value, without other kerning information.
Further changes may be necessary in the future.
[new_gui is] "using copies of puFont objects that are not yet initialized, I
think that dependant of link order (and so tor execution order) it can
work or not. Changing puFont font by puFont *font should work in all cases."
hardcodes the text color as black, which makes them a bit hard to read
on dark backgrounds; fix sent to the plib list; (the added code isn't
pretty and hence fits the existing style quite well ;-)
colors from /sim/gui/colors/ into map;
- set default color scheme
- handle fonts
- implement color class
- close all dialogs on reinit, set up style again, and then reopen all
(non-nasal generated) dialogs again
generated by freeglut's genfont utility. That application also generates
a copyright message that I did not copy into this file, because it is
wrong: the author of genfont claims copyright for data that *I* generated
using his program; this doesn't fly. Of course, the copyright will remain
in the (heavily edited) version of *his* code. I'll commit that, too.
no longer save inaccessible bindings copies, but only pointer to the
bindings in the property tree (which was desirable to get accurate
error messages for Nasal bindings).
- add <vrule>
- allow elements to default to foreground color (black)
- remove redundant if (foo) delete foo;
The rules do currently need a dummy child for the layouter to work correctly,
(<hrule><foo/></hrule>). The goal is to make a simple <hrule/> work.
showDialog() is careful not to create a new FGDialog() if a dialog with the
same name is already open (active). But at this point it is already too late:
newDialog(), which was called shortly before, has already overwritten the
dialog properties. This leads to animated garbage in the best case, and a
segfault in format_callback() in the worst case.
- GUI::newDialog(): Don't you overwrite properties of an active dialog!
- GUI::readDir(): You may do that, but delete the old dialog first!
(necessary for reloading the GUI)
- FGDialog::makeObject(): only set format_callback() with setRenderCallback()
if the property is "live". Otherwise, only call it once at construction
time. This isn't only a performance improvement. Without this the label
was growing until it hit the limit (256).
The previous message wasn't totally correct. Strings are now allowed, too. And
the pattern is now '[ -+#]?\d*(\.\d*)?l?[fs]' and *may* be embedded in a string.
There may only be one %s or %f, though. %% is allowed in the preamble/postamble.
(Yes, %ls is allowed, too, and treated as %s.)
Also, "end" is superfluous now.
Printing floats in dialogs with 8 digits after the comma is inappropriate
for most cases.
- implement a "format" property for "text" gui elements (a.k.a. pui label).
Number formats are set by strtod/snprintf, while formats on non-numbers
are replaced by "%s". Practical example in the upcoming material.nas update.
Valid formats regex: '%[ -]?\d*(\.\d*)?l?f' (IOW: the format must begin
with '%' and end with 'f').
# Nasal:
number = dialog.addChild("text");
number.set("label", "3.1415926");
number.set("format", "%.3f");
The dialog handling has been written at a time when only one dialog was
shown at the same time, and dialogs were shallow -- with only children, but
no grand-children. This makes finding a draggable spot on modern, dialogs
with nested objects quite a challenge. The patches fixes this, and other things:
- check full object tree on button press, not only the outmost layer;
and don't give up just because we are in *something* (which could well be
something harmless, like a group); only ignore a few, sensible objects
(we don't want to drag after a click on a button or into an input field)
- don't lose dialogs as easily when dragging too fast (it does still happen
if one manages to enter an editable field while dragging, but this is
a plib problem and I don't feel like fixing that now :-)
- don't "live"-update input fields while they are in edit mode
- remove some "if (foo) delete foo;" redundancy
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.
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.
I have made the
'Select Airport from List' option in FlightGear work
(I think) properly. I have some concerns about the
solution, which could be broken by changes to plib (if
they re-use the value I have assigned to
PUCLASS_LIST), but for the moment it seems to work OK.
Erik Hofman:
A request has been sent to John Fay to include the puList
code in the puAux subdirectory of plib so expect some
changes for future version of FlightGear.
a seperate explicite call or the io channels will be forced to try to shutdown
twice which could cause problems for some IO modules (i.e. attempting to
close an invalid file descriptor the second time ...)
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.
This will modify menubar.cxx/hxx so that it exports the
entire menubar (from menubar.xml) to the property tree, so that it can
now be changed dynamically using Nasal's setprop() instruction and
afterwards running a newly added fgcommand to update the menubar
based on those changes using the appropriate menubar path within
the property tree.
By default the menubar from menubar.xml will be stored within:
/sim/menubar/default
Erik:
I have moved the loading of menubar.xml into preferences.xml and
made sure that the menubar is destroyed every time a new menubar
is created.
a working state. I still see an anomoly when taking a screen shot from inside
a 3d cockpit, but external (chase/tower) views seem to work well. I also
added a property to control how many screen-res tiles are generated in the
output. Theoretically, you can now generate unlimited resolution screen shots,
or limited only by your disk space and patience.
Today I successfully generated a 20*1024 x 20*768 (20480x15360) resolution
screen shot. If you rendered that at 100 dpi it would cover a poster of
about 17 feet by 12.8 feet.
Good luck trying to display something that big or convert it to anything
useful on a typical PC. :-)
I'm attaching a small change to Andy's dialog.cxx that I needed
to make so that it enables XML/Nasal-dialogs to also contain
puLargeInput boxes.
The text will be retrieved/buffered from/within a specified
property tree, like:
<textbox>
<x>100</x>
<y>100</y>
<width>200</width>
<height>100</height>
<property>/gui/path-to-text-node/contents</property>
<slider>15</slider>
<editable>true</editable>
</textbox>
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.
This is a workaround for an issue where the xml dialogs were shrinking on
subsequent pops.
Andy Ross says:
That looks like it should be fine for a release-time workaround. The
2 pixel border on dialogs is at best a minor feature, and probably
invisible since the sub-frames all have their own padding.
Clearly the right fix would be to find out where the code is getting
confused by the previous layout. In principle, the layout should be
idempotent: if you don't change the layout constraints, it shouldn't
change its layout. There's still a bug in there somewhere.
little larger.
The text widget can now be meaningfully associated with a property; in
PUI, it's "value" isn't the same thing as its label, but we can hack
things to treat them symmetrically.
Commit an experimental "live" property that can be set on widgets to
cause them to update their values every frame. This works great for
text widgets, as above. Note that this synchronization is input-only:
no support is provided (or needed -- the GUI only changes when the
user does something) for writing those properties out every frame.
for a while, it turned out to be pretty easy to implement. Also, the
property picker is now non-modal, I presume the modality wasn't an
intentional feature.
configure and compile out-of-the-box on a MinGW target:
Use -lSDL instead of -lglut32 on windows builds when --enable-sdl
is set.
Link against alut.dll in addition to openal32.dll.
Replace BSD bcopy() with ANSI C memmove() in a few places. This is
simpler than trying to abstract it out as a platform dependency in a
header file; bcopy() has never been standard.
The ENABLE_THREADS handling has changed to be set to 0 when threads
are not in use. This breaks expressions like #ifdef ENABLE_THREADS.
Replace with a slightly more complicated expression. It might have
been better to fix the configure.ac script, but I didn't know how and
this whole setting is likely to go away soon anyway.
The MinGW C runtime actually does include snprintf, so only MSVC
builds (and not all WIN32 ones) need _snprintf in JSBSim/FGState.cpp
Building on a platform with no glut at all exposed some spots where
plib/pu.h was being included without a toolkit setting (it defaults to
glut). Include fg_os.hxx first.
And when still using glut, glut.h has a bizarre dependency on a
_WCHAR_T_DEFINED symbol. It it's not defined, it tries to redefine
(!!) wchar_t to disasterous effect.
this patch is to clear a problem that I sometimes
encounter : FG locks when hitting the cancel button
of a dialog. In fact, an interator is always invalid
when it was used to erase a member of a collection.
The braces are here to help my debugger, and I also
removed a warning about unused variable.
controls in the cockpit vs. which wheels they apply to. FlightGear now
sets /controls/gear/brake-left, /controls/gear/brake-right, and
/controls/gear/brake-parking. It should be up to the FDM to sort out
which wheels under which circumstances are affected by these controls
and ultimately what happens to the physical motion of the aircraft.
scripts) to create dialogs at runtime. Augment "dialog-close" to take
a name argument, allowing code other than PUI callbacks to close
dialogs.
The changes to the GUI directory to enable this are actually minor,
basically amounting to using SGPropertyNode_ptr reference counting
(the GUI subsystem no longer "controls" the dialog property trees, so
it can't delete them).
immediate end to glut, only that I'm going through and cleaning up (and
taking inventory of the actual glut dependencies in case I want to investigate
SDL.)
TITLE: Using delete [] versus delete
The extra "[]" warns the compiler that there is a whole array of objects here so that P's destructor must be called on each element of the array rather than just on P itself (which would be equivalent to the first element only).
scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
arrays of insufficient size are allocated in prop_picker.cxx ( size()
don't count the null char ) and strcpy is writing outside the allocated
array. A patch follow.
Here's a change to the GUI property picker I did a few weeks back.
It makes the values in the property pick 'live' (and also re-factors
the picker code to use less arrays, this should be obvious from the
diffs). A good demo is to open up the engine node and observe the rpm,
cylinder head temp, oil pressure and so on while playing with the
throttle and airspeed. It's pretty rough (some rounding of digits would
help) but useful for testing (at least I think so). I'm not sure about
the performance implications either, but it seems fine for me.
Fix memory leaks (PUI doesn't make copies of lists, so we have to make
our own copies and keep pointers to them).
Adjust for new method names in NewGUI.
Move the GUIInfo struct into the cxx file so that it's not part of the
public interface.
Fix memory leaks (PUI doesn't make copies of lists, so we have to make
our own copies and keep pointers to them).
Adjust for new method names in NewGUI.
Move the GUIInfo struct into the cxx file so that it's not part of the
public interface.
menubar. This one allows regular command bindings, with the
(temporary) condition that every menu item must have a unique text
label. The new menubar is disabled by default; to enable it,
configure --with-new-menubar.
Some more cmall changes to the SimGear header files and removed the
SG_HAVE_NATIVE_SGI_COMPILERS dependancies from FlightGear.
I've added a seperate JSBSim patch for the JSBSim source tree.
The general idea is to help clean up some aspects of the FDM init and be
able to provide startup conditions in a less ambiguous manner.
Previously, things like positions, orientations, and velocites were set on
"the bus". These had to be read by the FDMs which then were supposed to
initialized themselves to those values and turn write around and start
modifying those values. It was messy and cumbersome.
Now, all the initial fdm conditions are written to a sub-[property-]tree
under /sim/presets/
The values in /sim/presets/ always stay set to what the user has specified.
The user can change these at his/her liesure, and then request a "reset"
which will reset to the new conditions. I don't even want to say how this
worked before. :-)
Now, an script, or gui interface can stage a set of initial conditions while
the sim is running (without disrupting it), and then call "reset" to commit
the change.
People who should worry about all this are FDM writters, and a small few
others who care about over all program structure and flow.
This adds supports for a language specific font, defined in locale.xml
I've also moved the fgInitLocale() routine from main.cxx to fg_init.cxx
to prevent an ungly extern definition in options.cxx.
When the scroll bar slider is dragged, the list scrolls only far
enough to see all items; only the arrow buttons can scroll it so far
that the last item goes to the top of the view.
Fix scroll bar proportional size: was wrong when the list was only
a little longer than the visible area.
Minor fixes such as "delete files[i];" -> "delete[] files[i];"
(where the item being deleted is an array of characters) and removal of
global variables.
Smooth scrolling when dragging the slider: one item at a time,
rather than one tenth of the list at a time.
Fix a bug that would have occurred if instantiated with arrows=2.
Sort properties primarily by name and then by numerical index
order, rather than a simple ASCII string order. E.g. "js[1]", "js[2]",
"js[10]" rather than "js[1]", "js[10]", "js[2]".
Avoid crashing if the selected property path does not exist;
display an empty list instead. This cannot happen when the property
picker is working properly, but did happen due to missing indices prior
to this patch, and could happen if the user is allowed to type a
pathname, as in the http and telnet interfaces.
Fix truncation of strings to PUSTRING_MAX: was wrong when string
length was exactly 80.
Fix: move the scroll bar to the top each time a new list is
displayed. It was left at its previous position, while the top of the
new list was displayed, not corresponding to the slider.
Use getDisplayName instead of duplicated code: gives a better
decision on whether to display the index, and avoids invalid property
paths being generated which would previously crash find_props().
Replace unnecessary node lookups by name with direct access: tidier
and more efficient. E.g. "getValueTypeString
(node->getNode(name.c_str()))" -> "getValueTypeString (child)".
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.
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
When the scroll bar slider is dragged, the list scrolls only far enough to see all items; only the arrow buttons can scroll it so far that the last item goes to the top of the view.
Fix scroll bar proportional size: was wrong when the list was only a little longer than the visible area.
Minor fixes such as "delete files[i];" -> "delete[] files[i];" (where the item being deleted is an array of characters) and removal of global variables.
Smooth scrolling when dragging the slider: one item at a time, rather than one tenth of the list at a time.
Fix a bug that would have occurred if instantiated with arrows=2.
Sort properties primarily by name and then by numerical index order, rather than a simple ASCII string order. E.g. "js[1]", "js[2]", "js[10]" rather than "js[1]", "js[10]", "js[2]".
Avoid crashing if the selected property path does not exist; display an empty list instead. This cannot happen when the property picker is working properly, but did happen due to missing indices prior to this patch, and could happen if the user is allowed to type a pathname, as in the http and telnet interfaces.
Fix truncation of strings to PUSTRING_MAX: was wrong when string length was exactly 80.
Fix: move the scroll bar to the top each time a new list is displayed. It was left at its previous position, while the top of the new list was displayed, not corresponding to the slider.
Use getDisplayName instead of duplicated code: gives a better decision on whether to display the index, and avoids invalid property paths being generated which would previously crash find_props().
Replace unnecessary node lookups by name with direct access: tidier and more efficient. E.g. "getValueTypeString (node->getNode(name.c_str()))" -> "getValueTypeString (child)".
Turns out it was a problem with a long string, not the font. Plib is limited
to 80 characters in things like this listbox. BTW I checked and all the fonts
are missing those characters. So, no point in changing.
Description:
Fixed segfault caused by long string.
These are the updates for the View manager properties. Removed the last of
items (within the viewer/viewmgr) hard coded to view number. Added support
for per view configuration of ground level nearplane value. Tower views look
very nice with little or no z-buffer problem in the models. Pilot offset
dialog can be used to move eye in all views.
Description:
This update includes the new viewer interface as proposed by David M. and
a first pass at cleaning up the viewer/view manager code by Jim W.
Note that I have dropped Main/viewer_lookat.?xx and Main/viewer_rph.?xx and
modified the Makefile.am accordingly.
Detail of work:
Overall:
The code reads a little easier. There are still some unnecessary bits in
there and I'd like to supplement the comments in the viewer.hxx with a tiny
bit on each interface group and what the groupings mean (similar but briefer
than what you emailed me the other day). I tried not to mess up the style,
but there is an occasional inconsistency. In general I wouldn't call it done
(especially since there's no tower yet! :)), but I'd like to get this out
there so others can comment, and test.
In Viewer:
The interface as you suggested has been implemented. Basically everything
seems to work as it did visually. There is no difference that I can see in
performance, although some things might be a tiny bit faster.
I've merged the lookat and rph (pilot view) code into the recalc for the
viewer. There is still some redundancy between the two, but a lot has been
removed. In some cases I've taken some code that we'd likely want to inline
anyway and left it in there in duplicate. You'll see that the code for both
looks a little cleaner. I need to take a closer look at the rotations in
particular. I've cleaned up a little there, but I suspect more can be done
to streamline this.
The external declaration to the Quat_mat in mouse.cxx has been removed. IMHO
the quat doesn't serve any intrinsic purpose in mouse.cxx, but I'm not about
to rip it out. It would seem that there more conventional ways to get
spherical data that are just as fast. In any case all the viewer was pulling
from the quat matrix was the pitch value so I modified mouse.cxx to output to
our pitchOffset input and that works fine.
I've changed the native values to degrees from radians where appropriate.
This required a conversion from degrees to radians in a couple modules that
access the interface. Perhaps we should add interface calls that do the
conversion, e.g. a getHeadingOffset_rad() to go along with the
getHeadingOffset_deg().
On the view_offset (now headingOffset) thing there are two entry points
because of the ability to instantly switch views or to scroll to a new view
angle (by hitting the numeric keys for example). This leaves an anomaly in
the interface which should be resolved by adding "goal" settings to the
interface, e.g. a setGoalHeadingOffset_deg(), setGoalPitchOffset_deg(), etc.
Other than these two issues, the next step here will be to look at some
further optimizations, and to write support code for a tower view. That
should be fairly simple at this point. I was considering creating a
"simulated tower view" or "pedestrian view" that defaulted to a position off
to the right of whereever the plane is at the moment you switch to the tower
view. This could be a fall back when we don't have an actual tower location
at hand (as would be the case with rural airports).
ViewManager:
Basically all I did here was neaten things up by ripping out excess crap and
made it compatible as is with the new interface.
The result is that viewmanager is now ready to be developed. The two
preexisting views are still hardcoded into the view manager. The next step
would be to design configuration xml (eg /sim/view[x]/config/blahblah) that
could be used to set up as many views as we want. If we want to take the easy
way out, we might want to insist that view[0] be a pilot-view and have
viewmanager check for that.
interface instead of string. This will result in a lot more
efficiency later, once I add in a simple hash table for caching
lookups, since it will avoid creating a lot of temporary string
objects. The major considerations for users will be that they cannot
use
node->getName() == "foo";
any more, and will have to use c_str() when setting a string value
from a C++ string.
separate header file. This change will help integrate properties into
JSBSim.
Also, I (David Megginson) removed most of the SimGear include
statements from globals.hxx, reducing the amount of recompilation
every time SimGear changes. This required making minor changes to a
lot of files that were depending on the side-effects of the inclusions
in globals.hxx.
- implement the standard FGSubsystem interface, for consistency
- eliminate current_autopilot and add get/set_autopilot to FGGlobals,
for consistency
- use private methods rather than static functions for tying
properties
There should be no change in functionality.
OK, attached is a replacement for mouse.cxx that works the view using
the view-offset/tilt interface, rather than the (kinda odd) GuiQuat
stuff. It's kind of a hack job, as I left the hooks to GuiQuat in in
other places for fear of breaking something. Still, it removed more
code from mouse.cxx than it added, which has to count for some
elegance points.
max(width, height) by default (easily changeable) rather than just width.
(src/GUI/gui.cxx, src/Main/main.cxx, src/Main/viewer.cxx, src/Main/viewer.hxx)
I've attached 3 diffs against files in FlightGear to fix some printf
format strings. The changes are pretty straight forward. Let me know
if you have any questions. (BTW, I'm using gcc 2.95.4)
/sim/freeze/master (implimented)
/sim/freeze/fuel (implimented)
/sim/freeze/position (not implimented)
/sim/freeze/time-of-day (not implimented)
/sim/freeze/master is bound to the 'p' key via keyboard.xml, however,
/sim/freeze/fuel is not bound to anything at the moment so you must
change it via the external property interface, or specify an initial
value on the command line.
- automake-1.4 sets default values for INCLUDES which we can't
overwrite.
- automake-1.5 renames this to DEFAULT_INCLUDES and leaves INCLUDES
open for the developer to use.
Thus for automake-1.4 we are forced to 'append' to INCLUDES and in
automake-1.5 we can just set the value to whatever we like.
Unfortunately, the behaviors of the two versions are mutually
incompatible.
The solution I am committing now works for both versions but
automake-1.5 generates a lot of spurious warning messages that are
annoying, but not fatal.
Here's an unusual patch for FlightGear -- I've created .cvsignore
files for every source directory, to make CVS output more informative.
This is especially nice when using cvs-examine from (X)Emacs to look
for changes.
Note there is still a problem when doing a 'reset' after doing
a 'goto'. Curt says: I also see that doing two subsequent reset's on a
JSBSim model results in a segfault in a deconstructor deep inside JSBSim.
Heres an update to the ATIS stuff. In brief:
The possible buffer overflow in the display with wind should
hopefully be fixed.
Temperature is taken from the global temperature property instead
of being hardwired.
The display class now includes an implementation of the member
function to change the repeating message.
The message callsign is no longer hardwired. The first message
from each station is generated with a random callsign.
Subsequent messages from the same station have the callsign
incremented every hour. A map of airport-id vs. last callsign and
transmission time is kept for each station that has transmitted for
the duration of the FlightGear session. The logic might be flaky if
FlightGear is run for more than 24 hours at a stretch between
visiting the same ATIS station though! (ie I don't check the day.)
This map is kept in the atislist class. This might not be the best
long-term place for it (in an ATC class of some sort might be
better), but it works for now.
What was happening was that we screwed up and scheduled tiles for
(lon,lon) rather than (lon,lat) ... note the typo. This generated
bogus tile id's which the system happily accepted, put into the tile
cache system, and attempted to load. The problem was that these bogus
tile id's were negative where as all valid tile id's should be >= 0.
These negative tile id's up the logic used to remove tiles from the
cache. When identifying tiles for removal, we look for the furthest
tile away from us by starting out the furthest id at -1 and if we find
something further, we update the furthest tile id. Then at the end we
check if the furthest tile id >= 0 to see if we found anything we
could remove. However, the furthest tile id was these bogus tiles
with negative tile id's so the system always assumed there was nothing
appropriate for removal. This made it impossible to ever remove a
tile from the cache meaning it quickly filled up and no more tiles
could be loaded.
I fixed the one instance of scheduling tiles for a bogus location, and
added a sanity check so if it ever happens again we'll bomb with an
appropriate error message.
