Erik Hofman:
This patch contains an update to net_ctrls.hxx that adds an extra 100 bytes
(or an equivalent of 25 (u)int32_t types) of reserved space. This could be
used to make the protocol forward and backward compatibel within a certain
scope. Be sure to read the instructions at the begining of the header file
when addinf new variables.
it's also possible to enable/disable menu/item entries with higher numbers.
This can be useful for adding entries from other config files (aircraft
specific or local). I'd say aircraft files can use indices starting with
[100] and local files starting with [1000]. Such high number will never
collide with an entry in menubar.xml, even if entries are added/removed
there.
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.
