Hi,
FWIW passing along an idea, perhaps someone has already thought of it. ;-)
Have been trying to develop a realistic rendition of engine sounds for my 737
cockpit; in particular, the fading of the engine noise as airspeed and altitude
increase from takeoff to altitude and the roar when
Dear sir/madam
I am a great fan of flightgear. I would like to point out that crashes in
flightgear is not simulated. so add simulated crashes in the next
flightgear version.
--
ASHIRWADA WIJERATHNA
--
This SF.net
Hi Ashirwada,
this feature is implemented but disabled by default in FG's source code.
To enable it, if you really want that (think twice), edit file
src/AIModel/AIMultiplayer.cxx and alter the false to true in
FGAIMultiplayer::FGAIMultiplayer() :
FGAIBase(otMultiplayer, false)
This action,
On Wed, 31 Mar 2010, Pete Morgan wrote:
comment please.. need cool list ..
http://fg-master.appspot.com/
and its yes its hard coded and statick atmo.. ;-)
It looks fantastic Pete. Thanks for doing the work. :)
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of
comment please.. need cool list ..
http://fg-master.appspot.com/
and its yes its hard coded and statick atmo.. ;-)
pete
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed
* Melchior FRANZ -- Sunday 22 February 2009:
To make listeners work as expected the solution is to make *listeners*
work as expected, not to change dialog-apply in a way that makes them
not work as expected. ;-)
This should now work. A dialog-apply change might come later. Or not.
(I'm still
* Melchior FRANZ -- 2/23/2009 10:18 AM:
the node value shall not be read twice
Disregard! You aren't doing that, and why should you?!
But also don't read the widget value twice, please. :-)
m.
--
Open Source Business
Hi Melchior,
you can find the patch with, I hope, the correct improvement you asked.
I wanted to add that I really agree your point of view: To make
listeners work as expected the solution is to make *listeners*
work as expected, not to change dialog-apply in a way that makes them
not work as
I object to the proposed change. (Reasons below.)
* Sébastien MARQUE -- 2/21/2009 2:39 AM:
In this script you'll find several listeners linked to several
properties that can be modified using instrument-failures.xml or
system-failures.xml.
Except that these are *not* change-only
* Melchior FRANZ -- 2/21/2009 9:33 AM:
You should have used:
setlistener(f ~ /serviceable, failure[f], 0, 1);
Whoops. Of course, I meant:
setlistener(f ~ /serviceable, failure[f], 0, 0);
The meaning of the first optional argument is:
0 ... just attach (default)
1 ...
Hi Csaba and Melchior,
oops, sorry, I've made a mistake attaching the failures.nas script, but
please believe me that I've first tried
setlistener(f ~ /serviceable, failure[f], 0, 0);
in order to behave as written in setlistener doc (wiki and globals.nas).
I've just write back to correct
On Sat, Feb 21, 2009 at 11:32 AM, Melchior FRANZ mfr...@aon.at wrote:
setlistener(f ~ /serviceable, failure[f], 0, 0);
0 ... trigger on change only
As I wrote in my other email, this doesn't work as expected. The
listener is triggered initially even if the property doesn't change.
Yes, I will be obliged to check the value to avoid the instrument fix in
some cases. But as I discover this problem I wanted to try a solution
for every dialog-apply, to make the listeners work as expected, for
future uses, not only the failures system I'm trying to write.
If the fix is
On Sat, Feb 21, 2009 at 2:39 AM, Sébastien MARQUE seb.mar...@free.fr wrote:
no problem. I've attached a nasal script to put in whatever aircraft you
want. In this script you'll find several listeners linked to several
properties that can be modified using instrument-failures.xml or
Hi all,
I'm still trying to get failures implemented specifically for one
aircraft (before finding a better way for global solution). I've got a
problem with the dialogs instrument-failures.xml and
system-failures.xml, using the check boxes.
Indeed, it seems like the dialog-apply command
On Fri, Feb 20, 2009 at 1:23 AM, Sébastien MARQUE seb.mar...@free.fr wrote:
Indeed, it seems like the dialog-apply command changes every single
property linked to a checkbox causing the listeners set on these
properties to be triggered even if the property hadn't be changed by the
user. The
Hi Csaba,
actually I already use a listener that only fires then the value really
change. I've looked in Nasal scripting wiki page and globals.nas to be
sure, and tried the other possible values for the fourth argument of
setlistener, with no more succes, that's why I looked in FG sources. If
Hello,
Can be that I did not find and that that already exists :-[ . But it
would be possible, in the property of FlightGear, to have a flag who
indicates which launched version (Plib or OSG) ?
Thus, the planes, scenery etc... could be automatically adapted to the
version.
Something like:
On jeu 20 septembre 2007, BARANGER Emmanuel wrote:
Hello,
Can be that I did not find and that that already exists :-[ . But it
would be possible, in the property of FlightGear, to have a flag who
indicates which launched version (Plib or OSG) ?
Thus, the planes, scenery etc... could be
It seems however that version only OSG are not yet really on the agenda.
Much will keep a version 0.9.10 or 0.9.11 to see 0.9.1, all using Plib,
for still some time.
But much would like or will like to have access to planes CVS. Is thus
necessary it to prohibit to them simply because they wish to
20 matches
Mail list logo
