- work around plib bug that crashes fgfs if no airport was found (empty
list) and the arrows are clicked (patch sent to plib; workaround it to
be removed once fgfs officially depends on a plib version that includes
the fix)
- fix (very unlikely) crash in case the widget is redrawn between list
destruction and setting of the new list.
aircraft are often in several state lists at the same time, and they can
even be more than once in the same list. We need to remove all such instances,
or the a pointer to TowerPlaneRec may become invalid and cause crashes.
The proper fix would, of course, be to be careful with state changes and
to prevent *any* duplication of entries. [OK'ed by David]
rename OBJECT_TAXI_SIGN to OBJECT_SIGN. This isn't about taxi signs any
more, but all sorts of signs. Now is the best time to get rid of a
misleading name.
allow to not only set a general widget <color>, but also specific element
colors: <color-{{back,fore}ground,highlight,label,legend,misc,editfield}>
<input-misc>, for example, sets the input field cursor color, <input-legend>
the input field text color. (This feature was always planned as part of the
'theming' capabilities, and most code is already in place. Only this line
was apparently fogotten. :-)
only call occluder if the shadows were already initialized. This lead to
a crash when using the model manager from XML files (which apparently
nobody does, anyway ;-) Now those models work (again), but have no
shadows. Those placed at runtime (e.g. via ufo) still have a shadow.
<input> elements that are <live> always update their input field from the
<property>, except if they are activated, in which case the user input
should, of course, not get overwritten. But if such an input was active and
the user selected a different widget, then its contents were dropped.
Fix that by setting the "DownCallback" for live input fields.
fredb [Thu, 30 Mar 2006 20:37:34 +0000 (20:37 +0000)]
Don't restore initial screen geometry because there is nothing in fg_os* to resize an existing window.
Old behavior was to just resize the GL viewport, which doesn't necessarily match the fg window size.
curt [Tue, 28 Mar 2006 21:18:32 +0000 (21:18 +0000)]
Marc Frajola:
Here is one patch that to make FlightGear run without floating point
exceptions on FreeBSD. Apparently, if we do not ignore floating point
exceptions per this patch, there is some occasional condition where the
nvidia driver is involved in delivering spurious floating point exceptions
to the fgfs process, causing it to core-dump occasionally without the patch.
With only this patch, FlightGear will compile and run properly on
FreeBSD 6.X as long as the nvidia accelerated driver is installed,
modulo proper switches to the SimGear and FlightGear configure script
executions.
Again, kudos to your team for the great work on the big release
push; it is super to see things come together like this!
durk [Sun, 26 Mar 2006 21:40:35 +0000 (21:40 +0000)]
Bugfix in the ai initialization randomization procedure. Randomly
removing waypoints could cause the AIFlightPlan to run out of waypoints.
This patch prevents that by retaining at least two waypoints.
mfranz [Sat, 25 Mar 2006 08:47:53 +0000 (08:47 +0000)]
- don't crash if user clicked "Apply" but hasn't selected an airport
- re-order information from "LOXT Tulln" to "Tulln (LOXT)".
The list is sorted by airport name and columns aren't aligned, so this
looks way cleaner.
mfranz [Thu, 23 Mar 2006 23:02:48 +0000 (23:02 +0000)]
- set size, otherwise the widget doesn't expand to the size that the layouter
found desirable
- set slider width default correctly (parentHeight? Huh?)
mfranz [Thu, 23 Mar 2006 23:00:31 +0000 (23:00 +0000)]
- implement setSize(): We can't just use puObject::setSize() -- we do, of
course, have to re-layout all sub-widgets on resizing
- make slider size configurable, like it's done for the close relative
puLargeInput
mfranz [Thu, 23 Mar 2006 19:51:38 +0000 (19:51 +0000)]
- abstract out box slider width (should probably be settable)
- reduce it to 20 (30 is excessive and didn't match the property brower look)
- call puSlider with this size explicitly (otherwise its size is derived
from the font size, unlike the arrow buttons!)
mfranz [Thu, 23 Mar 2006 19:03:31 +0000 (19:03 +0000)]
make puList actually useful: call back on list entry selection.
(again: I'll submit all the changes to plib's puaList as soon as
possibe. Just needs a few more fixes first ... :-)
mfranz [Thu, 23 Mar 2006 17:44:10 +0000 (17:44 +0000)]
make puListBox inherit puList colors (otherwise the GUI style isn't
respected, and black text on dark grey is a bit hard to read).
TODO: - submit that for inclusion in plib's puAuxList
- drop custom version and use plib's (after 0.9.10)
ehofman [Wed, 22 Mar 2006 13:32:32 +0000 (13:32 +0000)]
Jon Berndt:
I had inadvertently terminated a data line when reaching a tab character after
initial data was supplied. I tested the lightning file and it now appears to
read in correctly.
mfranz [Wed, 22 Mar 2006 10:56:49 +0000 (10:56 +0000)]
puList.cxx: _list_box->getIntegerValue() returns -1 as long as no list
entry was selected. Return 0 in this case, not an invalid string address
(causing segfaults).
dialogs.cxx: don't set property if no list entry was chosen.
daveluff [Tue, 21 Mar 2006 23:33:54 +0000 (23:33 +0000)]
This innocuous looking typo was crashing the sim whenever an AI plane was asked to follow the user whilst the user was flying a circuit (non straight-in) approach
mfranz [Mon, 20 Mar 2006 12:10:20 +0000 (12:10 +0000)]
extract loop body into separate function to later allow model addition
at runtime; remove Nasal support for now (the model loader is currently
initialized before the Nasal subsystem is available)
durk [Sun, 19 Mar 2006 07:41:48 +0000 (07:41 +0000)]
Bugfixes and feature improvements related to AI auto flightplan generation.
When AIFlightPlanCreateTaxi() function is called with the firstFlight
argument set to true, this is supposed to handle situations where the
the aircraft's timetable indicates it should have left between about 5 to
20 minutes earlier. In the previous version, all these aircraft started
taxiing from the first parking location available in the network, due
to the fact that the variable gateId was not assigned a value. In this
patch, route tracing starts from an assigned gate and the network node
following code is fast forwarded to a random location along the taxiways
to give a more realistic and natural distribution of taxiing aircraft
after startup.
This patch further addresses some weird ballet-dancing behavior that
aircraft were showing just prior to/right after parking and which was
related to a number of more or less duplicate waypoints in the transition
from createTaxi() to createParking() to createPushBack() to createTaxi().
Finally, a blatant typing error in the getParking() function was fixed.
durk [Sat, 11 Mar 2006 18:14:48 +0000 (18:14 +0000)]
Bugfix: Non-existent AIModels could trigger a request to load scenery tiles
at (lon, lat) coordinates -1000,0. This patch fixes the AIModels/Traffic
Manager side of things. The AIModels subsystems allowed the creation of
AIAircraft with non-existent 3D models. If such a model didn't exist, the
aip class didn't get initialized, resulting in the above-mentioned bogus
position information. Here I circumvent this problem by a) only interacting
with the tile loader if the model is visible (and hence has succesfully been
initialized) and b) by disallowing the traffic manager to create AIAircraft
objects if the path to the 3D model doesn't exist.
andy [Fri, 10 Mar 2006 22:21:42 +0000 (22:21 +0000)]
While I had the valgrind rig set up, I took the opportunity to plug a
bunch of memory leaks that had accumulated over the years. FlightGear
doesn't currently bother to destroy and recreate a YASim context, but
at least it can do so now without worry.
andy [Fri, 10 Mar 2006 19:47:23 +0000 (19:47 +0000)]
Fix an uninitialized data condition that crept in during the recent
groundcache addition -- the ground callback doesn't do anything at
solution time, so the ground plane was unset. Valgrind was whining
about this; it's not clear that it was actually causing a problem.
andy [Fri, 10 Mar 2006 19:46:16 +0000 (19:46 +0000)]
When we are asked to produce no force on a Surface (e.g. a weight that
is "off"), make sure the force is actually zero. Kind of a hack -- a
better idea would be flag to set at a higher level.