control to piston engines that allows external scripts to control the
turbo/supercharger boost programatically by setting this axis to
values in the range [0:1]. It also adds a "turbo-lag" attribute (a
time in seconds) to engines implementing turbocharger spooling delays.
This isn't terribly well tested, but doesn't seem to have broken
anything.
I am attaching a trivial patch that changes the normalization from 24 to
12 in turn_indicator.cxx. With this change, the pa24 tc has a turn
indicator spin value in the property tree of 0.9996 and the same value
for the pa28-161 is 1.0, so there is no harm to a 24 volt electrical
system in this change. Should the battery or alternator put out a lower
voltage than 12 volts, the spin value goes down and the tc shows a
negative turn that increases as the voltage gets less. This file shows
you as the author. If you are comfortable with this change, commit it
to cvs and the tc will be correct even for 12 volt systems.
propeller pitch stops for constant speed propellers. The default
values are the same as the previous hard-coded values. The new
attributes, "fine-stop" and "coarse-stop", are documented in the base
package, Docs/README.yasim.
- remove cleanup handler that unlocks unused mutex
- make the result_queue a locking queue (blocking is only done in the
pop() anyway, and this isn't used in the thread at all)
- don't disallow thread cancelling in the request_queue's pop(), which
is the only cancellation point in this thread
This patch makes use of the vectors now available in simgear with that past
patch. And using that it simplyfies the carrier code somehow.
- Small additional factory's to the quaternion code are done in the simgear
part. Also more explicit unit names in the factory functions.
- The flightgear part makes use of them and simplyfies some computations
especially in the carrier code.
- The data part fixes the coordinate frames I used for the park positions in
the carrier to match the usual ones. I believed that I had done so, but it
was definitly different. Also there are more parking positions avaliable now.
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.
This patch makes FlightGear at least compile on MSVC. I hope I have removed
reference of my other local changes. DSP and DSW files are included for
reference. They have been reconstructed with am2dsp.pl. I had to introduce a
change to am2dsp because of the need of filenames with embedded spaces. (Yuck)
The major direction is to remove clutter like the _USE_MATH_DEFINES and have it
on the compiler command line sice there is no central include file. You will
have to put it on the command line for your locale Project files, if it not
there, already. I added the _CRT_SECURE_NO_DEPRECATE define for 2005, since it
does no harm to other VC version.
the mouse pointer to a new position. Otherwise it can happen that the new
position is first set, but then come a few still unprocessed events for the
old position. This makes ugly jumps in mouse view mode.
the mouse rather than wrapping it. Wrapping around to the other side
of the screen has very bad consequences when using the mouse for
flying or viewing -- it can result in sudden jumps in the controls or
the viewpoint when the mouse jumps to another side of the screen.
Right now, the mouse is constrained to stay between 25% and 75% of the
screen on both the X and Y axis -- whenever it hits an edge, it jumps
back to the centre of the screen again (which causes no control or
view jump).
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)
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)
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)
scripts that load/write user specific data that shouldn't go to PWD, and
can't go to $FG_ROOT (due to permissions and clean separation of 'official'
data and local modifications)
right corner, not those that are result of centering a dialog if no x/y are
given. This centers screen.log messages correctly. But maybe we have to
rethink that special meaning of negative coords altogether.
This patch removes some useless indirection when creating AIModels. It
obsolets AIScenario*.
AIEntities are just an intermediate copy of an other intermediate copy of an
xml file on the way from the ai scenario configuration file to the AIModels.
As such the AImodels can now be created directly from the property tree read
from the scenario file.
This reduces the amount of work needed to add an other AIModel and reduces the
amount of copy operations done during initialization.
It also moves internal knowledge of special AI models into these special AI
models class instead of spreading that into the whole AIModel subdirectory
which in turn enables to use carrier internal data structures for carrier
internal data ...
Also some unused variables are removed from the AIModel classes.
I believe that there are still more of them, but that is what I stumbled
accross ...
Tested, like the other splitouts these days in a seperate tree and using the
autopilot for some time, and in this case with a carrier start ...
problems because a lot of people already have their *real* preferences
set in ~/.fgfs/preferences.xml (and don't want fgfs to stomp over them),
because the name doesn't tell people that their data aren't save there
(comments!), and because this is inconsistent with the global preferences.xml
file, where user changes *are* respected.
This patch is a combined effort by Gregor Richards, Oliver Schroeder, and
Vivian Meazza (and code cleanups and improvements by Erik Hofman). It corrects
the bug in which a Multiplayer model responds to local inputs, and the view
number bug which caused certain aircraft to appear as cockpit only models. It
passes remote properties over the net, and all major control surfaces and gear
are now animated correctly, providing that the local ~model.xml file contains
no leading "/" in the <property></property> data entries. MP objects
are now extrapolated using 1st and 2nd derivatives to make their movement
appear more smooth. The sim is now halted while a new client joins the net.
Known problems with MP are non-display of the remote client under certain
circumstances of starting/resetting, and a freeze on starting. These bugs are
long standing, and are not addressed by this patch.
Special thanks must go to AJ Macleod for his patient testing of this patch over many evenings.
We have also moved part of multiplayer into AIModels as part of the ongoing
development of MP.
because a dialog button can get pressed when its callback isn't available
any more. Ideally, we would close the dialog or update its buttons when
this happens. But this requires bigger changes.
/sim/messages/{atc,pilot,ai-plane,ground,approach}
These can the be used for differenct screen.log colors and for different
voices. (Aircraft & tutoruals may want to write to /sim/messages/copilot)
Fix the current buggy rain orientation behaviour for the views attached to the
aircraft (while still inheriting bugs with the views attached to anything else).
I had massive problems with tower.cxx, so I decided to doublecheck all
containers and iterators in order and found lot of potential problems.
Now I can fly with "debug on" of KSFO for minutes without problems.
The fix for AIMgr is from Mathias, but I reworked it. So blame me, not him.
- Feet to meter conversion mistake (in AI getGround elev)
- Improved ground following code (not yet perfect, but for now no one will
notice it within the marginal altitiude differences at the taxitrack or
runway)
- Exclusion of the "AI" directory witihin data/Aircraft in
main/init/fgSearchAircraft, to prevent AI aircraft to be picked up by the
aircraft search function
Jon Stockill wrote:
> I've just discovered that when using the null fdm I'm not getting
> updates to /position/ground-elev-m any more. So I can't actually
> retrieve the terrain elevation. Is there somewhere else in the property
> tree I could read this from?
The attached patch fixes this problem.
This patch limits the maximum simtime we do simulation computations for.
That is highly sensible if you run flightgear in valgrind or some realy slow
debug build. In such a case it is possible that flightgear gets totally
unresponsible, because simulation time might increase slower than real time.
That patch introduces a maximum simulation time per rendered frame to limit
that effect.
If the property /sim/max-simtime-per-frame is set to something strictly
positive, the simulation time is limited to that value.
The default is unchanged - no limit.
Anyway, from the point of view of gui responsiveness and responsiveness to
realtime controls like joystick inputs it might be a good idea to limit that
by default to say 1 second. If you have less than 1fps, flightgear is
unplayable anyway and I believe we do not longer need to care for realtime
correctness for that case ...
though the window wasn't resized. I'm just not adventurous enough for
a cleaner solution in the light of the upcoming release. At least the
xsize/ysize properties aren't set each frame any more, so listeners
work now properly.
Incorporating the shared ptr code:
- All scenegraph references from SimGear
- SGMaterial which already had a reference counter uses now that common
infrastructure.
- SGMatModel is now counted.
- SGSoundSample from SimGear
- And the corresponding change for the sound samples in flightgear which fixes
a latent crash if FGBeacon would evern be deleted.
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.
"play-audio-function" command. This function can be called from internal
code, from nasal scripts, or from external scripts to play a single one-off
wav file. File/audio data is loaded and unloaded on the fly automatically.
Create a queue of one-off wav files. Calling layer can request the system
to play any wav file. The request is thrown at the end of a play queue.
The queue is serviced sequentially so that queued wav files will no longer
overlap. When a sample is finished playing. It is removed from the queue
and deleted from memory. The next remaining request in the queue is then
played.
- 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.
anything in the nav tree is valid or not.
- Fix an order problem between caching data values and searching for a new
station that could cause odd and unexpected and hard to reproduce results.
Added a convenience function to estimate the time to intercept the selected
radial give the current heading and speed. This can be useful to a flight
directory to compute the point to switch from armed to coupled mode at just
the right time so the pilot can roll out onto the desired heading on the
desired radial.
Add a first whack at estimating a ground track heading error (difference
between aircraft heading and ground track directon.) This needs more work
and testing.
The prototype of update_metar_properties does not match overridden func.
trafficmgr: iterators below begin() and after end().
tower.cxx : iterator incrementing beyond end().
replaced with efficient listener callbacks. One use is the new FPS display.
This is reviewed and OK'ed by Andy, relatively trivial and separated from
the rest of Nasal, so problems are quite unlikely and confined to users of
this function.
The callback is executed whenever the property is written to -- even if
the value didn't change. The triggering Node is available via cmdarg().
Examples: _setlistener("/sim/crashed", func {print("haha!")});
_setlistener("/foo/bar", func { print(cmdarg().getPath() ~ " changed")})
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.
Display the ground intersection point on mouse click (if click not consumed
by the gui or the panel.) This should eventually get stuffed into the
property tree.
Computes the pick direction and starting point. This is code that translates
a screen coordinate into a vector in the FlightGear world (between the eye and
the on-screen coordinate.) Armed with this vector in FG world coordinates,
you could call a scenery intersection routine and lookup the lon/lat/elev of
the point in the world that was clicked on.
* in some cases more specific sg exception types were used in place
of the more generic one, e.g., sg_io_exception instead of sg_exception
when the context of the error was an IO error
* in some cases, the error message was made more specific
* minor style fix for exception rethrowing --- using throw; whenever
a re-throw is made; sometimes optimizing away the exception symbol name
in the catch handler at all
* more specific catch handlers added in some places -- e.g.,
an sg_io_exception caught ahead of sg_exception
- fix indentation (there were 2, 3, 4, 7(!) space indents as well as tab
indents, all mixed together)
- no code changes, except one "if (foo) {}" changed to "if (!foo) return; ..."
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. :-)
remove a hack and do it properly: if the requested elevation is for some
reason below the surface and the intersection test fails (as it appears
to be the case in EGLL), try again from 10000m ASL
mf: typos
Insert empty string as marker between FG_SCENERY path elements.
FG_SCENERY=A:B expands to [A/Terrain, A/Objects, "", B/Terrain, B/Objects, ""]
(assuming that both A/ and B/ have Terrain/ and Objects/ subdirs).
tileentry.cxx -- FGTileEntry::load():
Check all tile dirs in FG_SCENERY from left to right: add all objects
to the scenery until a terrain tile was found: In this case read the
rest of that group (i.e. the Objects/ twin dir) and then stop scanning.
Better structuring of log messages & fix warnings.
sea tile, and finally process the objects. This guarantees that all objects
are placed relative to a valid tile center, rather than to the origin (0/0/0).
This is important for objects in sea tiles, and allows to display objects
of *.stg files that came sooner in FG_SCENERY.
This was the reason why some people (especially SuSE10.0/gcc 4.0.2
users) couldn't see others in MP. I don't even know why I'm committing
that. It's less important than taxi lights ...
metar fetcher. Effectively this caused the metar thread and the main
thread to both attempt to fetch weather data. This could lead to long pauses
when the main thread decided to fetch the weather, and introduced a race
condition that could cause a segfault/crash.
Investigating this issue, I discovered that even longer ago, someone confused
#defines and #ifdef symbols with C/C++ variables. If I #define XYZ 0 it is
defined so #ifdef XYZ is true, not false like a variable. Our thread
detection made this mistake and there were follow up patches to work around
it.
So I fixed the configure script (ahhh, reading the autoconf manual is highly
recommended excercise for people editing the configure.ac file.) I also
discovered that we were hardwiring with_threads=yes with no way via configure
options to disable threads from the build so I fixed that.
Then I patched up the #ifdef's scattered through the code to match the
configure script changes, oh and by the way, I stumbled upon a past typo
that led to the race condition in the metar fetching thread and fixed that.
Here's a fix for a bug I introduced when I updated the AIStorm with
turbulence. The change I made to the FGAIEntity struct was overriding the
thermal <strength-fps> data.
too old (wrong system time or broken proxy): stops after 10 stale reports
were fetched in a row. This should simply stop further fetching, but due
to a bug in the threading system(?) it does currently lead to abortion,
just like any other exception in the fetcher.
each other out. The problem is this: if we press, for example, "Ctrl-a", but
release the "Ctrl" modifier button *before* the "a" button (which nobody does
intentionally, but which happens all the time), then we don't get the RELEASE
signal on "Ctrl-a" (keycode 1), but on the "a" (79). But "a" hasn't been
pressed, so the signal is dropped. And who releases "Ctrl-a"? Nobody!
So the next PRESSED signal for "Ctrl-a" is ignored, too. It is still
"pressed" after all, isn't it? That's the reason for the occasional
non-functioning of keys.
Due to the nearing 0.9.9 release, I only commit a crude last-minute fix.
It's not as intrusive as it looks, and shouldn't be "dangerous" at all.
It only makes sure that when we get an unexpected RELEASE for one letter
key ("a") that the two twins "A" and "Ctrl-A" are released if they are
still in "pressed" state.
The proper fix will be to let fg_os{,_sdl}.cxx always report presses on the
same key ("a", "Shift-a", "Ctrl-a", "Alt-a", and other combinations of
modifiers) as the *same* key (97), only with modifiers appropriately set.
