Re: [Flightgear-devel] Kansai International Airport was renewed.
Hello Tetsu, tetsu wrote: http://envtech.hp.infoseek.co.jp/737kix/apt_RJBB.dat [...] Please anyone tell me how to convert to the FlightGear format? This already _is_ the format as used by FlightGear - simply remove the TaxiDraw 'header' (the first _four_ lines) from your airport file and add it to your default apt.dat.gz Someone recently wrote that you can use the uncompressed apt.dat with FlightGear as well, which makes it easier to add modifications. And, please, convince David Luff to add your update to his collection ! Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] AI Ships (was: Airports Data + Zoom + SHIPs)
On Wednesday 08 June 2005 10:36 pm, Ampere K. Hardraade wrote: Perhaps seperating land and water would be the next thing on the agenda? If this is in regard to the AI ships driving onto land, the AI ships and AI carrier can accept a flight plan, but the ability to follow the flight plan has not yet been implemented. I won't be hard to do. Once that is done, the carrier will follow a pre-defined path, and stay off of land. There are then two options: 1) make a race-track pattern 2) go straight to the flightplan end, then vanish and reappear at the start (like in the movie :) Of course option 1 is more realistic, but the ship will be going in the wrong direction over half the time. Option two would give you more fun with your entertainment dollar/euro, but you don't want to be on the ship when it teleports to the start again. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FG-JSB Carrier Landing Patch
Waiting for a permanent release which include the Carrier JSB property, from the original Mathias Froehlich Patch which insert the Hook and Launchbar Functionalities (it apply on FG 9.8) I have ( for my personal use ), rebuild a Patch which can be applied to the last release (today 12 GMT) of /FlightGear/source/src/FDM/JSBSim. If Jon, Mathias, JSB development team, FG development team agree with, and if anybody interested on I can deliver it. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] Re: animation bug
* Josh Babcock -- Thursday 09 June 2005 05:39:
It looks like rotate animations require an x-m coord for center tags
even though you can get away without y-m or z-m. What's worse, it
not only fails silently, it grabs the y-m value for x-m and then
uses the z-m value for y-m. Here comes the code.
That's apparently by design. :-)
The attached path should make it more consistent: if there's at least one
of axis/{x,y,z}, then use the axis notation. And there's at least one of
center/{x,y,z}-m then use the defined center. (Only tested with *important*
aircraft ... and the bo105 worked well with it. ;-)
m.
Index: animation.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/model/animation.cxx,v
retrieving revision 1.35
diff -u -p -r1.35 animation.cxx
--- animation.cxx 24 May 2005 08:13:09 - 1.35
+++ animation.cxx 9 Jun 2005 14:37:42 -
@@ -630,14 +630,18 @@ SGRotateAnimation::SGRotateAnimation( SG
_center[0] = 0;
_center[1] = 0;
_center[2] = 0;
-if (props-hasValue(axis/x1-m)) {
+if (props-hasValue(axis/x) || props-hasValue(axis/y) || props-hasValue(axis/z)) {
+ _axis[0] = props-getFloatValue(axis/x, 0);
+ _axis[1] = props-getFloatValue(axis/y, 0);
+ _axis[2] = props-getFloatValue(axis/z, 0);
+} else {
double x1,y1,z1,x2,y2,z2;
-x1 = props-getFloatValue(axis/x1-m);
-y1 = props-getFloatValue(axis/y1-m);
-z1 = props-getFloatValue(axis/z1-m);
-x2 = props-getFloatValue(axis/x2-m);
-y2 = props-getFloatValue(axis/y2-m);
-z2 = props-getFloatValue(axis/z2-m);
+x1 = props-getFloatValue(axis/x1-m, 0);
+y1 = props-getFloatValue(axis/y1-m, 0);
+z1 = props-getFloatValue(axis/z1-m, 0);
+x2 = props-getFloatValue(axis/x2-m, 0);
+y2 = props-getFloatValue(axis/y2-m, 0);
+z2 = props-getFloatValue(axis/z2-m, 0);
_center[0] = (x1+x2)/2;
_center[1]= (y1+y2)/2;
_center[2] = (z1+z2)/2;
@@ -645,15 +649,12 @@ SGRotateAnimation::SGRotateAnimation( SG
_axis[0] = (x2-x1)/vector_length;
_axis[1] = (y2-y1)/vector_length;
_axis[2] = (z2-z1)/vector_length;
-} else {
- _axis[0] = props-getFloatValue(axis/x, 0);
- _axis[1] = props-getFloatValue(axis/y, 0);
- _axis[2] = props-getFloatValue(axis/z, 0);
}
-if (props-hasValue(center/x-m)) {
- _center[0] = props-getFloatValue(center/x-m, 0);
- _center[1] = props-getFloatValue(center/y-m, 0);
- _center[2] = props-getFloatValue(center/z-m, 0);
+if (props-hasValue(center/x-m) || props-hasValue(center/y-m)
+|| props-hasValue(center/z-m)) {
+_center[0] = props-getFloatValue(center/x-m, 0);
+_center[1] = props-getFloatValue(center/y-m, 0);
+_center[2] = props-getFloatValue(center/z-m, 0);
}
sgNormalizeVec3(_axis);
}
@@ -1152,7 +1153,11 @@ SGMaterialAnimation::SGMaterialAnimation
_trans.factor = group-getFloatValue(factor, 1.0);
_trans.offset = group-getFloatValue(offset, 0.0);
_trans.min = group-getFloatValue(min, 0.0);
+if (_trans.min 0.0)
+_trans.min = 0.0;
_trans.max = group-getFloatValue(max, 1.0);
+if (_trans.max 1.0)
+_trans.max = 1.0;
if (_trans.dirty())
_update |= TRANSPARENCY;
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Ships
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Culp schrieb: If this is in regard to the AI ships driving onto land, the AI ships and AI carrier can accept a flight plan, but the ability to follow the flight plan has not yet been implemented. I won't be hard to do. Once that is done, the carrier will follow a pre-defined path, and stay off of land. There are then two options: 1) make a race-track pattern 2) go straight to the flightplan end, then vanish and reappear at the start (like in the movie :) Of course option 1 is more realistic, but the ship will be going in the wrong direction over half the time. Option two would give you more fun with your entertainment dollar/euro, but you don't want to be on the ship when it teleports to the start again. If you specify a path that ends where it starts, number 2 becomes the best and realistic choice. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCqGEIlhWtxOxWNFcRAn0qAJ9tMzweZKmKzG3t3KeL07UZ1mJZ9QCfcqzC PRf28OxFdc+ZD+iIz3bk9Kk= =qrNK -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] After crash , Restart ?
Erik Hofman wrote: Martin Spott wrote: Wouldn't be there a method to avoid planes floating below the surface ? I remember having the PC-7 sitting at one end of the runway, rotating back around a point somewhere behind the main gear and disappearing afterwards. I think this case is coupled to strong wind, Yes, by specifying more contact points (wingtips, tip of the vertical tail, tip of the spinner, etc). I'm curious if it is possible to 'simply' define the whole model as a contact point and let the OpenGL subsystem detect terrain collision. This would require some return channel from the OpenGL system back to the application and I have no idea if this is achievable, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] After crash , Restart ?
On June 9, 2005 05:28 pm, Martin Spott wrote: I'm curious if it is possible to 'simply' define the whole model as a contact point and let the OpenGL subsystem detect terrain collision. This would require some return channel from the OpenGL system back to the application and I have no idea if this is achievable, Martin. If it is achievable, how will that work for aircrafts that use seperated models, such as the A380? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] My thoughts regarding aircraft system or hardware simulations
Ampere, It's interesting that you should bring up this subject since the electrical system is something I've been beating my head on this week. Let me share my thoughts (which go in a bit of a different direction from yours.) 1. The current electrical system is data driven rather than hardcoded, but it was designed before nasal existed in FG. 2. Electrical systems can vary widely from airplane to airplane. It makes sense to have a few representative examples, but for accurately modeling the particular system on a particular aircraft, you are really going to have to dig in and do some work. 3. The current electrical system model has some serious problems due to short sighted design and the designer (me) not fully understanding the problem I was trying to solve. This week I've been taking the Microsoft big hammer approach of trying to beat something of dubious quality and poor design into something that actually works and is useful ... using overwhelming force. I'm ready to give up and trash the whole subsystem. 3a. The system is very complex with a lot of subtle interactions and side effects. It's unclear for someone new coming into the project exactly how it works and what you have to do to build a successful electrical system model. 3b. The system can't handle things like battery charging without introducing horrible hacks. 3c. The system can't do things like balance loads between two alternators, again without horrible hacks. 3d. Try extracting the information you need to accurately drive an ammeter gauge from the current system ... we will need even more horrible hacks. :-( 4a. What we really need is someone who actually understands all this stuff to build a better data driven electrical system model using a better, more flexible approach. I am told that SPICE is a good example of doing this right, but I'm a computer scientist with very little EE knowledge or ability. Circuits strike fear into my heart. 4b. An alternate approach would be to write a procedural electrical system model for each specific aircraft using nasal. But is there a way to have a default nasal function that can be overwritten by an aircraft specific function? I am almost favoring the nasal approach here for many of these aircraft specific subsystems. I realize this expands the discussion rather than focussing it, but I'm getting really frustrated with the inabilities of the current electrical system to do things like model battery charging (without trying to charge itself and other goofy things), model ammeter gauges (i.e. measure current flow between two different points in the network), do load balancing between multiple alternators and a host of more complex things. I like the idea of a v2.0 electrical system that is similar to the current system, but designed by someone who knows what the H-E-double toothpicks they are doing (obviously not me.) But in the mean time, nasal would be a quick and dirty approach to getting a fairly functional electrical system up and running pretty quickly. Regards, Curt. Ampere K. Hardraade wrote: A propsal regarding the generalization of aircraft systems Abstract: Currently, the electrical system seems to be the only system that can be configured by the user. Other systems are either fully hardcoded into Flightgear, or have yet to be modelled. Since dedication to code that simulates such thing as hydraulic or bleed air system isn't going to appear anytime soon, it is my opinion that it might be a good idea to modify the electrical system into a more abstract/generic form. The idea is to make the simulation of other aircraft systems easier. Of course, instead of being hardcoded into Flightgear, unique behaviours to individual system may have to make user-configurable somehow. Problems: Why should the electrical system be made generic? Take the electrical system, hydraulic system, and bleed air system as the examples. All these system are basically different forms of moving something from point A, through medium B, to point C. That battery on the electrical system is similar in function to the hydraulic fluid accumlator, or the air tank in the bleed air system. In fact, they can all be modelled using a Queue... or a Stack, storing a table of values. The electrical bus, hydraulic and bleed air lines are similar in functions, and its implementation can be as simple as *b = a; (in C's terms). Because there are so many commonalities between these systems, it would be wise to combine them into one piece of code, and implements the behaviours of a specific system using extensions. Possible benfitis: By generalizing systems, a framework is created which will make life easier for other developers who wish to create new aircraft systems. I guess what I am trying to advocate here is OOP for aircraft systems. To make this approach more flexible and worthwhile, Nasal should be allowed to
[Flightgear-devel] Re: My thoughts regarding aircraft system or hardware simulations
* Curtis L. Olson -- Thursday 09 June 2005 19:52: 4b. [...] But is there a way to have a default nasal function that can be overwritten by an aircraft specific function? Sure. AFAIK, every nasal context can write into any nasal namespace. This does include to overwrite an existing function there. I for one am overwriting view.stepView() from my personal $FG_ROOT/Nasal/local.nas. I've redefined controls.throttleAxis() to grab the joystick throttle lever position on occasions. m. -- /\ ASCII Ribbon Campaign \ / - Say NO to HTML in email x - Say NO to Word documents in email / \ - Say NO to full-quoting and top-posting ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] After crash , Restart ?
Martin Spott wrote: I'm curious if it is possible to 'simply' define the whole model as a contact point and let the OpenGL subsystem detect terrain collision. Not meaningfully. The 3D geometry can tell you collision points between polygons. It can't tell you whether those polygons are landing gear, or in what direction they will compress, or what the generated forces are. All that information has to be passed to the FDM separately, it can't be computed from the 3D model. The only way to prevent the model intersects ground issue for the common case is to make sure the 3D artists and FDM modellers are 100% agreed on their choices of coordinates. Note that YASim will automatically generate contact points for wing and fuselage endpoints, so you should get acceptable behavior as long as the FDM and polygon numbers match. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: My thoughts regarding aircraft system or hardware simulations
Melchior FRANZ wrote: Sure. AFAIK, every nasal context can write into any nasal namespace. This does include to overwrite an existing function there. I for one am overwriting view.stepView() from my personal $FG_ROOT/Nasal/local.nas. I've redefined controls.throttleAxis() to grab the joystick throttle lever position on occasions. Indeed. Note that more conventional approaches are also possible, like providing a registerElectricalHandler() function, or defining a ElectricalSystem interface class with a default implementation that the user can replace with something like setElectricalSystem(), etc... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] NASAL error
OK, this works great: (other than the fact that it doesn't actually do
anything yet)
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) == 0 ) {
print(off);
} else {
print(red);
}
}
settimer(gearLightCheck, 5);
}
but this
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) 1 ) { Line 143
print(red);
} else {
print(off);
}
}
settimer(gearLightCheck, 5);
}
produces this error:
Nasal runtime error: nil used in numeric context
at /usr/local/share/FlightGear/data/Aircraft/b29/b29.nas, line 143
I know these props are set, because I put the following in the set.xml file:
controls
gear
nosewheel-caster type=bool archive=ytrue/nosewheel-caster
antiskid type=bool archive=yfalse/antiskid
gear num=0
position-norm0/position-norm
/gear
gear num=1
position-norm0/position-norm
/gear
gear num=2
position-norm0/position-norm
/gear
gear num=3
position-norm0/position-norm
/gear
/gear
/controls
As an aside, the initial output looks like this:
b29-common.xml initialized
0: red
1: red
2: red
3: red
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
0: green
1: green
2: green
3: green
0: green
1: green
2: green
3: green
Any thoughts?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASAL error
Josh Babcock wrote:
OK, this works great: (other than the fact that it doesn't actually do
anything yet)
if ( getprop(thisProp) == 1 ) {
but this
} elsif ( getprop(thisProp) 1 ) { Line 143
produces this error:
Nasal runtime error: nil used in numeric context
at /usr/local/share/FlightGear/data/Aircraft/b29/b29.nas, line 143
Property initialization rules are complicated. You are creating
proprties with a type of UNDEFINED from an XML file, which are
then being set from within the YASim code using setFloatValue().
Something is producing a nil value when you read it, or perhaps
when it is being converted from a string. In general, you should
always ready to handle the case where a property is not yet
initialized, or is deleted and/or changes type at runtime.
As to why your example fails with but works with ==, that
is correct behavior. The less-than operator is obviously
numeric, and dies if one of the arguments (nil, in this case)
cannot be converted to a number. The equality operator is more
general, and returns false under those circumstances. It is
perfectly legal to compare nil with another object for
equality (e.g. if(list.next == nil) { ... }).
Can you try to pare the example down to something I can run and
reproduce?
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASAL error
Josh Babcock wrote:
OK, this works great: (other than the fact that it doesn't actually do
anything yet)
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) == 0 ) {
print(off);
} else {
print(red);
}
}
settimer(gearLightCheck, 5);
}
but this
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) 1 ) { Line 143
print(red);
} else {
print(off);
}
}
settimer(gearLightCheck, 5);
}
produces this error:
Nasal runtime error: nil used in numeric context
at /usr/local/share/FlightGear/data/Aircraft/b29/b29.nas, line 143
I know these props are set, because I put the following in the set.xml file:
controls
gear
nosewheel-caster type=bool archive=ytrue/nosewheel-caster
antiskid type=bool archive=yfalse/antiskid
gear num=0
position-norm0/position-norm
/gear
gear num=1
position-norm0/position-norm
/gear
gear num=2
position-norm0/position-norm
/gear
gear num=3
position-norm0/position-norm
/gear
/gear
/controls
As an aside, the initial output looks like this:
b29-common.xml initialized
0: red
1: red
2: red
3: red
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
WARNING: Legacy engine definition in YASim configuration file. Please fix.
0: green
1: green
2: green
3: green
0: green
1: green
2: green
3: green
Any thoughts?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Umm, never mind. I was setting /controls/gear/... instead of /gear/...
I had the solution a while ago, just typoed it away. Just a case of
NASAL starting up before YASim gets a chance to create the node.
Mea culpa.
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASAL error
I know this is an incredibly dumb question.. but in Nasal an elseif
conditon is expressed as elsif?
- Original Message -
From: Josh Babcock [EMAIL PROTECTED]
To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Thursday, June 09, 2005 3:59 PM
Subject: [Flightgear-devel] NASAL error
OK, this works great: (other than the fact that it doesn't actually do
anything yet)
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) == 0 ) {
print(off);
} else {
print(red);
}
}
settimer(gearLightCheck, 5);
}
but this
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) 1 ) { Line 143
print(red);
} else {
print(off);
}
}
settimer(gearLightCheck, 5);
}
produces this error:
Nasal runtime error: nil used in numeric context
at /usr/local/share/FlightGear/data/Aircraft/b29/b29.nas, line 143
I know these props are set, because I put the following in the set.xml
file:
controls
gear
nosewheel-caster type=bool archive=ytrue/nosewheel-caster
antiskid type=bool archive=yfalse/antiskid
gear num=0
position-norm0/position-norm
/gear
gear num=1
position-norm0/position-norm
/gear
gear num=2
position-norm0/position-norm
/gear
gear num=3
position-norm0/position-norm
/gear
/gear
/controls
As an aside, the initial output looks like this:
b29-common.xml initialized
0: red
1: red
2: red
3: red
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
0: green
1: green
2: green
3: green
0: green
1: green
2: green
3: green
Any thoughts?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASAL error
[EMAIL PROTECTED] wrote: I know this is an incredibly dumb question.. but in Nasal an elseif conditon is expressed as elsif? Perl uses elsif like Nasal. C and derivatives (and Javascript) use else if only because they hack their parser grammers to handle the inherent ambiguity. The bourne shell is a little terser and uses elif, at the expense of pronouncing the resulting syntax wrong, a bug that Python inherited. So... what on earth is an elseif? No language designer in their right mind would choose THAT. :) Seriously: if you're looking for obvious standards here, it's going to be a looong search... One picks ones brain damage and moves on. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NASAL error
Nevermind. I found the Nasal docs.
- Original Message -
From: [EMAIL PROTECTED]
To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Thursday, June 09, 2005 4:26 PM
Subject: Re: [Flightgear-devel] NASAL error
I know this is an incredibly dumb question.. but in Nasal an elseif
conditon is expressed as elsif?
- Original Message -
From: Josh Babcock [EMAIL PROTECTED]
To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Thursday, June 09, 2005 3:59 PM
Subject: [Flightgear-devel] NASAL error
OK, this works great: (other than the fact that it doesn't actually do
anything yet)
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) == 0 ) {
print(off);
} else {
print(red);
}
}
settimer(gearLightCheck, 5);
}
but this
gearLightCheck = func {
for (i=0; i3; i=i+1) {
thisProp = /gear/gear[ ~ i ~ ]/position-norm;
if ( getprop(thisProp) == 1 ) {
print(green);
} elsif ( getprop(thisProp) 1 ) { Line 143
print(red);
} else {
print(off);
}
}
settimer(gearLightCheck, 5);
}
produces this error:
Nasal runtime error: nil used in numeric context
at /usr/local/share/FlightGear/data/Aircraft/b29/b29.nas, line 143
I know these props are set, because I put the following in the set.xml
file:
controls
gear
nosewheel-caster type=bool archive=ytrue/nosewheel-caster
antiskid type=bool archive=yfalse/antiskid
gear num=0
position-norm0/position-norm
/gear
gear num=1
position-norm0/position-norm
/gear
gear num=2
position-norm0/position-norm
/gear
gear num=3
position-norm0/position-norm
/gear
/gear
/controls
As an aside, the initial output looks like this:
b29-common.xml initialized
0: red
1: red
2: red
3: red
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
WARNING: Legacy engine definition in YASim configuration file. Please
fix.
0: green
1: green
2: green
3: green
0: green
1: green
2: green
3: green
Any thoughts?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] crash handling options for JSBSim in FlightGear
Just checked in a JSBSim.hxx and JSBSim.cxx to JSBSim CVS that makes crash handling user-configurable. The default behavior is the current subterranean flying behavior. If the user sets the property /sim/pause-on-crash to true, then the sim will pause on crash, which is the same behavior Yasim has, so this should be the default for FlightGear. If the user sets the property /sim/reset-on-crash to true, then the sim will reset on crash. As for the /fdm/jsbsim property cloning problem, this has been around for some time now. Any reset of FlightGear while using a JSBSim aircraft will cause another /fdm/jsbsim node to be created. I've tried stopping that but have had no luck. There are several people using properties from /fdm/jsbsim to drive instruments and they are possibly used in some nasal scripts, so this problem breaks some of their panels, and maybe more things. I'm copying this to the flightgear-devel list. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Systems modelling
From: Ampere K. Hardraade [EMAIL PROTECTED] Why should the electrical system be made generic? It shouldn't. There is a whole class of physical systems that act as a network with two valued paths. Voltage/Current, Pressure/Velocity, Density/Massflow, some aerodynamics, etc etc. All of these systems need to be solved as a network in order to capture interactions, without hard coding solution paths. All these system are basically different forms of moving something from point A, through medium B, to point C. The problem with that approach is that you have to allow for (a) the amount of thing being used at B varying when C turns off, (b) sometimes, stuff can be flowing from C to A and to B, etc. implementation can be as simple as *b = a; (in C's terms). I don't think so ... one of the reasons I gave up on FGFS as a failure modelling simulation for training purposes is that the various buses do not manage combinatorial failures and side effects right. You can hard code the stuff, but it may not cover all cases. From: Curtis L. Olson [EMAIL PROTECTED] 3a. The system is very complex with a lot of subtle interactions and side effects. It's unclear for someone new coming into the project exactly how it works and what you have to do to build a successful electrical system model. I think the most important thing is to capture the network that drives the interactions for the general case, so we have confidence that the model will be correct for any situation, and then leave it to a dedicated solver to infer what the decision tree is at any time. 4a. What we really need is someone who actually understands all this stuff to build a better data driven electrical system model using a better, more flexible approach. I am told that SPICE is a good example of doing this right, but I'm a computer scientist with very little EE knowledge or ability. Circuits strike fear into my heart. If the developers want to do it using a circuit solver, which I think is probably the right way to go, I'd be happy to provide an object oriented definition of what we need to have in the property tree. Separately to that, I can write up what the circuit solver has to do. It isn't particularly complicated, providing you're not trying to cover all the things that can happen to semiconductors/transistors when designing logic chips that run reliably at gigahertz speeds. It's that high end stuff that makes a SPICE codebase complicated. 4b. An alternate approach would be to write a procedural electrical system model for each specific aircraft using nasal. But is there a way to have a default nasal function that can be overwritten by an aircraft specific function? I am almost favoring the nasal approach here for many of these aircraft specific subsystems. I don't have an opinion about this, having not used nasal seriously. Can it be used to write a modular solver that propagates both ways? I realize this expands the discussion rather than focussing it, but I'm getting really frustrated with the inabilities of the current electrical system to do things like model battery charging (without trying to charge itself and other goofy things), model ammeter gauges (i.e. measure current flow between two different points in the network), do load balancing between multiple alternators and a host of more complex things. I like the idea of a v2.0 electrical system that is similar to the current system, but designed by someone who knows what the H-E-double toothpicks they are doing (obviously not me.) But in the mean time, nasal would be a quick and dirty approach to getting a fairly functional electrical system up and running pretty quickly. A final thought that might help y'all decide what to do ... As I see it, the _most_ important thing is to ensure that the method used to describe how the model works will be understandable to aircraft mechanics who have no programming experience. Those are the people who really know what the electrical system wiring looks like and what has to be added into a model. If they cannot read the computer parsable description in the aircraft file, they will be unable to find mistakes. Now: _if_ you decide that this should be the driving consideration and there are no technical obstacles that inherently for the decision for us, please build two versions of the same electrical system and I'll collaborate with the FAA to get the local avionics shops to let us know which they can understand better. They should be interested in supporting us because it's in their interests to have a good training tool. Both their techs (who can look through our files) and for their pilot customers (who persist in operating stuff wrongly). I suggest the C172 electrical system, with _all_ switches, breakers, interior lights, and all avionics loading their respective bus. C172s have a really simple system; fits on a single sheet of paper. It's a handy test case before trying
