Martin Dressler wrote:
So it mean that gimp use bad antialiasing or render lines in some
bad way. Because Gimp scale with the same quality as ImageMagic.
But are you starting with an image of 1024x1024 or higher? If you try
to edit at the final resolution, you really can't avoid seeing
Melchior FRANZ wrote:
Get into an aircraft with autopilot (preferably one with 2D panel,
e.g. the c182), climb to some safe altitude, then switch the
autopilot to altitude lock. Now pitch up or down manually and watch
the elevator trim go to the opposite direction. While it is off,
unlock
Jim Wilson wrote:
Shading is done per object (normals generated on the fly). If you
need a square edge, split the adjacent sides into individual objects.
For example on the P-51D and AFAIK Lee's models, the blunt edges of
the control surfaces (e.g. flaps, ailerons) are separate objects.
That
Jim Wilson wrote:
Any reason that yasim needs to report heading-deg as -180 through
180 instead of 0 thru 360?
None. It probably just returns the output from an atan2() call. It
doesn't use the value internally at all.
Andy
--
Andrew J. RossBeyond the OrdinaryPlausibility
Martin Spott wrote:
Lee Elliott [EMAIL PROTECTED] wrote:
YASim doesn't support speedbrakes or have a speedbrake control [...]
Aaaah, so it would probably worth adding before the release ? Most of
the aircraft that profit noticeably from a speed brake run with
YASim,
YASim's author has
Matthew Johnson wrote:
Thought I'd take a stab at this, decided to try and make a 3D
rendition of the Sea Harrier, especially since we have the Harrier in
FG, but without a 3D model (I think it needs one!).
So far I have started by looking for a plan that I can follow, but have
only found
[Woo hoo! Check it out: two posts in two days! I'm back in the game!
Amusingly, I'm also employed again. I wonder if there's a connection?]
Maik Justus wrote:
I am not sure if the stabs are working correct without the solver. I
tried to use fixed values if you specify no wing and hstab, but
Maik Justus wrote:
I am using this code instead the solver:
applyDragFactor(Math::pow(15.7/1000, 1/SOLVE_TWEAK));
applyLiftRatio(Math::pow(104, 1/SOLVE_TWEAK));
I took the values from the c172.
Don't include the SOLVE_TWEAK bit. That exists to slow down the
convergence of the
OK, I finally had time over the weekend to update my tree, rebuild,
and start investigating the new Helicopter code in YASim. What
follows are the notes that occurred to me on first reading, in roughly
order of importance (most important first). Obviously some of this
criticism may be due to
Lee Elliott wrote:
Would it be a) possible, and b) a good idea, for YASim to use an
'external' engine model - i.e. the JSBSim engine model?
It would take some work, but yes, this could definitely be possible.
The engine (and attached propeller) are used in the solver only as
data sources. The
Jim Wilson wrote:
That might be difficult to implement in plib anyway. I did a little
looking into this recently (as a parameter setting by the app, not a
ac3d 4.0 attribute). Basically my investigation revealed that plib
would have to split vertices (create duplicates on adjacent
polygons)
I wrote:
Jim Wilson wrote:
Wolfram Kuss wrote:
I can even guess what the new info does: It says edges less than
45 degrees are smooth and more than 45 degrees are sharp.
That might be difficult to implement in plib anyway. I did a
little looking into this recently (as a parameter
Jim Wilson wrote:
I'm not sure the patch is a good idea as it stands. It has to add
overhead for scenery models and it actually makes the underlying plib
problem worse...that of plib messing with the geometry data.
It is easy to make models that look right in AC3D, the problem is that
plib
Erik Hofman wrote:
Andy Ross wrote:
Anyway, try doing a remove duplicate vertices pass on the
weird-looking models and see if that fixes the problem. I'll take
a look to see if I can find and reenable the old merging code.
I am pretty sure I don't have them in the Fokker 50. I do
Innis Cunningham wrote:
As far as I am aware the throttle and the collective are two different
things.Sure the throttle control is part of the collective
lever(usually a pistol grip like a motor bike).But one controls the
engine speed and one controls the rotor blade angle. Maybe on modern
Seamus Thomas Carroll wrote (on flightgear-devel):
I am trying to load a 3D object using sgLoad3DModel. I have created
a simple cube and when I try to load it I get the following error:
FATAL: ac_to_gl: Unrecognised token 'crease 45.00
The new version of AC3D emits a new token, crease,
I wrote:
But I'm still working on it. I finished another iteration this
morning before work, which I'm maybe 95% sure is correct. It's still
mismapping the newly split normals, but I think that's just a bug and
not another algorithm goof.
Nope, it was an algorithm goof. So was the one
Melchior FRANZ wrote:
Unfortunately, I've now run into a problem: while the model
looks OK from outside, the cockpit view looks quite ugly,
because all the rounded window frames come out too angular.
I would have to use a lot of vertices to make this look
good. I'd like to avoid a LOD cockpit
it look any
different.
Andy Ross wrote:
At worst, you could simply identify the objects that you want
smooth and set their thresholds to 180?.
Still better than having to provide a high-res copckpit.
Ah, I see the misunderstanding. The new code only affects lighting.
It creates new vertices
Jim Wilson wrote:
Ok the problem shows up with objects triangulated as follows: Picture
a diamond shape. Split it vertically so that you now have two
triangles, one on the left and the other on the right. Split the one
on the right horizontally. Now you have three triangles.
Yup. And one
Jim Wilson wrote:
So are you saying that the currently coded 46 value means that
angles between non averaged normals of greater than 134 degrees
(180-46) will be considered sharp? This appears to be the case, but
I want to be sure.
Right. Except I've stated it incorrectly twice now. :)
Richard Hornby wrote:
The test-up error message (ref undefined reference) refers to a line
in /math/point3d.hxx which does not look as if it contains anything
to do with the problem.
I give 100:1 odds this means you have two versions of SimGear
installed to different places. The one being
Jim Wilson wrote:
Alright...so that _is_ an interesting value. It would require a good
deal of precision on the modelers part in order to round a corner with
3 sides. I wonder now if this coincides with the default crease 45
in ac3d's implementation.
FWIW, I'd argue that exactly 45° is a
Richard Hornby wrote:
I have also tried searching for sg_geodesy.cxx with the same result
- apparently only one installation on /usr/local/.. lib ..include
and ..source (orig download).
That's a source file; but you're problem is with the linker. You
should be looking for the libsgmath.a that
Lee Elliott wrote:
ODBC would be better than making it DB specific. Msql has it's pros
cons.
Not to be too much of a curmudgeon*, but let me point out that full
double precision positions and orientations for every aircraft in the
air at one time** over the planet earth would fit easily in
John Barrett wrote:
Here is the patch and source files for the preliminary wire protocol
implementation -- comments and suggestions welcome
This sounds fun, so I grabbed it and had a peek. One bug report in
messagebuf.cxx, which has some code that I can't figure out:
void
[Starting a new thread, since the original is getting a little strung
out. :)]
In an attempt to depoliticize the combat flame war as much as
possible, it's worth pointing out that, irrespective of people's
opinions on the matter, there are not a lot of combat features we
can really avoid
Gene Buckle wrote:
Paul Surgeon wrote:
Why does C++ scare you?
Well scare is probably too strong a word. :) I'm just unfamiliar
with it. I can follow C ok, but the object references tangle me for
some odd reason.
If C++ doesn't scare you, you have no business using it.
Sorry, but that
Gene Buckle wrote:
/bin/sh ../../libtool ...
../../libtool: s%^.*/%%: No such file or directory
../../libtool: -e: command not found
First off, everyone else's suggestions of using your distribution's
glut are probably the right way to go (unless you are using the glut
from Red Hat 9 with the
Gene Buckle wrote:
Andy Ross wrote:
Nonetheless, it's actually not hard to compile by hand. If I didn't
goof up the line endings below, you should be able to get into the
src-glut directory and paste the following two commands:
There is no src-glut directory. src-glu is the closest
Dave Luff wrote:
Thanks for posting those. As you say, the time spent in
DoGroundElev() looks quite frightening. I'm afraid I have no idea how
to make the function call more efficient - walking hit lists and so
forth isn't really my forte.
However, it does look as though you are hitting it
David Luff wrote:
I'm not entirely clear on this - are mipmaps pre-built and available
on disk for FG to load, or are they built from the main texture at
runtime?
The latter. I believe in our case it's done by plib, but there's a
standard gluBuild2DMipmaps() routine in OpenGL too. The time
Curtis L. Olson wrote:
This can get to be a really complicated subject if we let it. But,
as it works now, a single full res texture is stored on the disk.
It is loaded at run time, and the mipmaps are generated using a
simple 2x2 - 1x1 averaging scheme. (I think this is called a box
John Barrett wrote:
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 9:24 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
[Dave's message]
--
[Starting a new thread. John's reply was burried in the parent thread]
John Barret wrote:
I would like to request your ideas and wishes for an aircraft AI
scripting language sufficiently generic in scope to handle piloting
any aircraft running on FG.
There is some support already in place
Norman Vine wrote:
Somethng like this is easy enough to implement with the current
hitlist code but ... I don't understand why the compressability of
the gear has any bearing on the point of contact. It is the AC that is
changing not the Terrain
Gear don't always compress perpendicular to
John Barrett wrote:
Why is an interactive session by default generating AI aircraft
without a loaded scenario to control those aircraft ??
David Luff wrote:
Um, my plan was actually to have the sim spawn appropriate random
aircraft as the user gets near, and to have each airport populated
Jim Howarth wrote:
Ahhh... Well.. I got to it.. Started to fly under it and flightgear
crapped out..
No. It just flagged a collision. The FDMs can only ask FlightGear
how high above sea level is the ground at this location?. This is
fine for doing ground handling on runways.
But the
John Barrett wrote:
I've got some code from another project that I'm trying to hook into
FG...
[which turns out to be:]
I'm integrating the SpiderMonkey JS engine
Into the client? Yikes. There was a big flame war the last time this
was mentioned. That interpreter is almost bigger than
Erik Hofman wrote:
BTW. Does Nasal work like PSL, int that one has to initiate each step?
I've done a script manager for PSL that I've laying around somewhere
that would allow multiple scripts to work simultaneously and can
expand over multiple frames (instead of needing to run the whole
David Megginson wrote:
Paul Surgeon writes:
I don't know about everyone else's experience but I haven't found
one aircraft in FG that wants to sit still on the ground even with
the engine off.
It might be that the problem is not ground reactions but
aerodynamics.
It's the ground
Nick wrote:
I just remembered another trick about zero-speed rolling models.
Below a threshold speed (say 1 m/s) you make the force proportional to
the velocity. That way you'll get zero force at zero speed. The
other thing that can happen if you don't is that you'll oscillate
about the
Martin Spott wrote:
Simulating friction on the ground should be quite easy as long as you
know some parameters: You have to know about position as well as
horizontal and vertical forces of _each_ wheel. Probably this is
already there for a C172 (as mentioned above, I don't know), the rest
is
Erik Hofman wrote:
Now the resulting moments and forces should be added by the results
of the individual wheels, not by averaging it, but rather by vector
mathematics.
The FDMs already do this. Each gear gets its own force application,
which is a sum of compressive force along the strut and
David Megginson wrote:
Andy Ross writes:
JSBSim and YASim do things pretty much the same way, using a
coefficient of friction for gear as they slide over the ground. This
integration works fine for a moving aircraft,
Unfortunately, not -- when the JSBSim and YASim aircraft are rolling
matt wrote:
Is there a way to have specular effects on the models in FG? Using
Blender or AC3D? I suppose there is some Plib issue but I thought
I'd ask...
It depends on what you mean. Plib support a specular exponent (Phong
model) in the lighting computations just fine. This gets you
matt wrote:
Can this be specified per object or in the header for the entire
model?
It's per-material. AC3D puts all the materal formats together in the
header of the document.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
David Megginson wrote:
I was amazed at how tricky this got a year or so ago when I was
experimenting with it. I agree that we need some kind of damping at
slow speed. Essentially, the gear forces have to become a special
case, reducing forces and moments towards zero but never beyond into
OK, I had some time over the weekend to carry out my threat of hacking
the Nasal interpreter into FlightGear. So now we have another
language to flame about. :)
http://www.plausible.org/andy/fg-nasal-1.0.tar.gz
[This touches SimGear, FlightGear and the base package, so you'll
see
Jon S. Bertdt wrote:
I just want to know: why nasal?
Because, sir, I am a marketing genius. :)
Actually, it start out life as Nasl, which was an acronym for Not
Another Scripting Language. There wasn't much purpose behind that
name either, but it was reasonably descriptive. And similar
David Megginson wrote:
Again, I'm wondering if this is an aerodynamic problem (aside from
the bouncing-around-sitting-still thing). [...] I expect that the
same applies to the assumptions made by YASim's solver.
I'll take a look. By design, at least, YASim should be reasonably
immune to
Gerhard Wesp wrote:
On the contrary. I haven't followed this discussion too closely and
I'm no physicist either, but this sounds to me exactly like static vs.
gliding friction.
Yes, there are separate coefficients of friction for the static
vs. dynamic case. But these are only different
It's that time again. More stuff:
http://www.plausible.org/andy/fg-nasal-1.1.tar.gz
As before, you'll find source, data, and SimGear directories
inside the tarball. They go exactly where you might think. Rebuild
SimGear, then FlightGear, and run it against a base package with the
stuff from
I wrote:
This drop includes a new, non-Nasal FlightGear subsystem:
FGTimerMgr. This is a heap-based priority queue implementation that
manages timeout callbacks for anyone that asks.
Curt rapidly pointed out that I'd missed the existence of the
SGEventMgr class, which does very similar
Melchior FRANZ wrote:
Doesn't compile. Fix:
Does compile. You didn't make install your SimGear and are trying
to compile against the source tree instead. :)
But the variant directory structure (nasal.h installs to a different
location than it has in the source tree) is probably a bug. The
Melchior FRANZ wrote:
I never make install in SimGear, but have a link to the simgear dir
from /usr/local/include. This has always worked. But it cannot work
when the source refers to simgear/nasal.h, although the file is
actually in simgear/nasal/nasal.h.
You misunderstand. The build system
Frederic Bouvier wrote:
There are people that don't use automake to build flightgear and
they would be gratefull if they could continue to build without
having to duplicate stuff.
I'm going to have to start writing clearer, I guess. Let me say it
again:
I *want* to put the nasal.h file into
David Megginson wrote:
I agree that the gravity feed thing is important. For example,
high-wing Cessna singles usually have a both fuel-selector
position, because the fuel flows down via gravity, while low-wing
Piper singles do not, because the fuel is pumped (imagine sucking
through two
Erik Hofman wrote:
While compiling on IRIX I get the following error:
[...]
To be honnest I'm not quite sure what you're trying to do here.
The hash table needs two blocks allocated: one to hold the table nodes
and one to hold the top-level table of column pointers. For
efficiency, it packs
Jon Berndt wrote:
I tried looking for some docs on EasyXML, but so far the only things I
have been able to find are the auto-generated API docs. That's the
second thing I'd like to see. Is there an EasyXML Quick-start sort
of document somewhere, or do I just need to dig into the code? If
David Megginson wrote:
By the way, I always have to put on the parking brake (!!) to stop the
skids from acting like wheels. Is there an easy fix to the YASim
model?
First off, we should stop mapping a brakes property to something that
doesn't have brakes. Put a value of 1 somewhere in the
Erik Hofman wrote:
Both seem to work well (in which case I prefer the later solution).
But then I get a problem with the test.nas script which runs fine from
0 to 93 and then seems to hang ...
Works for me, obviously. Stack trace?
Andy
___
Andy Ross wrote:
First off, we should stop mapping a brakes property to something that
doesn't have brakes. Put a value of 1 somewhere in the property
tree using the -set.xml file, and map that to the brakes instead. :)
With just a little code work, we could add a stump attribute (or
whatever
Andy Ross wrote:
Works for me, obviously. Stack trace?
Not yet, I haven't looked into that part yet (at first I was under the
impression that this was C(++) code until I discovered I was already
running a script :-)
I think it might be a big-/little endian problem.
There *is* an endian
Curtis L. Olson wrote:
I believe that plib has some endiannes tests. Also simgear, have a
look at simgear/io/lowlevel.hxx (towards the end)
Right. But those are runtime tests. What Nasal needs to modify is a
structure order, which can only be done at compile time. Simplified,
the naRef
OK, more code at:
http://www.plausible.org/andy/fg-nasal-1.3.tar.gz
This one is essentially bug fixes to the engine, mostly with garbage
collection issues: making sure that everything is findable when the
collector runs and that important stuff (like, heh, the global
namespace) doesn't get
I wrote:
The new code does everything the old does except for the warping of
the mouse cursor at mode change (no API for that from either Nasal
or the property tree) and mouse cursor changing (I was too lazy to
put the list of Glut cursor names into the Nasal script).
That's one of those
Erik Hofman wrote:
There is a compiler directive:
#if BYTE_ORDER == BIG_ENDIAN
#else
#endif
I've never heard of this one. Is it a standard thing, or a common
extension?
It works fine under my copy of gcc, but oddly it does *not* appear to
act like a preprocessor define. It doesn't show up
David Megginson wrote:
I've just checked in a few changes to start cutting down the noise:
No! But... but... if you do this, then no one will remember that the
default type for a panel layer is texture, or that bindings are read
during initialization. Just think what will happen when everyone
David Megginson wrote:
I'm controlling the (simulated) bo105 helicopter much better by
picking an airspeed (say, 10 kt when maneuvering for a landing) and
holding it as closely as possible with the cyclic.
Out of curiosity, how do pilots do this in real helicopters? I
wouldn't think a
David Megginson wrote:
Maik Justus wrote:
Also the rolling tendency in translational lift is missing.
That is a very complicate thing. Allways if I think about I run into
confusion.
Is it just a gyroscopic effect?
If I'm not misunderstanding the terminology, this is the rolling
moment
David Megginson wrote:
When you're all done ooing and awing at the elegant simplicity of the
absence of console output, you can pitch in and help hunt down noise
with other FDMs, aircraft, etc. My next target will be a simple YASim
aircraft, and then a YASim helicopter.
Other than the
David Megginson wrote:
This one happens with single-engine airplanes as well. If you yank
the nose up suddenly, you get a yaw to the left; if you push the nose
down suddenly, you get a yaw to the right. I can imagine, though,
that the effect is much more dramatic with that big gyro spinning
Maik Justus wrote:
By the way: With this changes the heli is not anylonger parallel to
ground (while hovering). It is tiltet to the left to compensate the
tail rotor force.
That sounds wrong to me. The *rotor* should be tilted, but the
airframe is experiencing no net force and should be
I promised Curt earlier today that I would write up some integration
documentation for Nasal. There is a draft available at:
http://www.plausible.org/andy/fg-nasal.html
This isn't documentation for the language itself. That requirement is
covered (albeit poorly) by some pages and sample code
Martin Spott wrote:
No, because the BO105 - contrary to the 'usual' Bell's for example -
has a rigid rotor. Please have a look here:
http://www.b-domke.de/AviationImages/Rotorhead.html#Eurocopter
Well, that explains my confusion... I guess this just shows my
helicopter ignorance. My belief
David Megginson wrote:
Great. Let me know when you have time to port it from vim to an
editor.
:)
There's already a nasal-mode.el, actually. It's attached; it's
previously been hidden in the source tarball on the nasal project
website.
It mostly works. I did it by taking a chainsaw to
David Megginson wrote:
Originally, I defined actions using XML mainly because we didn't have
a scripting language, but ideally, we should share up the labour like
this:
XML = declarative
NASAL = imperative
Completely agree. Although it should be pointed out that there's
significant gray
Matevz Jekovec wrote:
I was just thinking (actually would be proud:)) if someone could add
our Slovenian flag to the FlightGear logo
I, for one, think it would be immensely cool if the flag bar grew over
time. If any revisions are going to be done to the list, though, it
should be pointed out
Brandon Craig Rhodes wrote:
(1) Joystick file authors have to decide how many engines the
throttle will control. Most authors seem to have chosen eight,
which will break once ten-engine planes start appearing in
FlightGear; the author of the default four-axis-joystick.xml file
John Barrett wrote:
radiostack.cxx: In member function `virtual void FGRadioStack::init()':
radiostack.cxx:81: error: `addTask' undeclared (first use this function)
You need to update your SimGear. The SGEventManager API changed a
little bit recently, and radiostack.cxx was updated along with
Erik Hofman wrote:
I've put the current code, slightly modified on one or two places,
into CVS. The next step would be adding support for NASAL scripts to
controll the vehicles and after that we need some code the add dynamic
objects to scenery locations to make it possible for ferries to
OK, more stuff at:
http://www.plausible.org/andy/fg-nasal-1.4.tar.gz
Core Nasal changes:
New ghost facility for wrapping C pointers in a GC-friendly way.
Lexer fixes from Melchior to properly handle \x escaping.
Lexer fixes to correctly handle _ in symbol names.
Bug with the string
Andy Ross wrote:
OK, more stuff at:
http://www.plausible.org/andy/fg-nasal-1.4.tar.gz
And of course my DSL modem apparently locked up not two hours after I
sent that. :)
It's back up now. Sorry.
Andy
___
Flightgear-devel mailing list
[EMAIL
Another update is available at:
http://www.plausible.org/andy/fg-nasal-1.5.tar.gz
This contains all the new features from yesterday, plus the ability to
load code from the /nasal subtree of the global properties at
initialization time. Basically, you can now do:
nasal
c172
I just did my first CVS checkin in over a year. :)
I need to fix a bug with YASim's slip angle reporting*, but before
that I thought I'd commit some cleanups to the helicopter code that
I've had sitting around. My account still seems to work.
Anyway: no behavior should have changed with this
Paul Surgeon wrote:
Detail textures help but I they are not the answer.
What is needed is new terrain rendering engine. :D
I'm sure there will be protesters but this polygonal looking
scenery is not very nice in my opinion. Yes it works but it doesn't
even begin to resemble real life
Paul Surgeon wrote:
Think along the lines of about 57MB for 400 km2 with the terrain
directly under the aircraft at 1 meter/pixel resolution and then
gradually tappering off to 8 meters/pixel in 5 steps to a distance
of 10 km in all directions from the aircraft.
That was my thinking when I
Oliver C. wrote:
Couldn't we load the whole data into RAM before?
1 GB Ram are cheap today.
It's not nearly that simple. If you want to draw something on the
screen, it has to get into the video card's memory at some point
during the frame. Even 256MB Übercards are going to thrash* with a
1GB
Oliver C. wrote:
Does dumping plib mean that we can choose something like the SDL
library for the OpenGL initialization?
No, that means dumping glut. Earlier plib versions had a glut
dependency, but I believe that has been removed from current versions.
We can keep the plib parts that we use
These typos were in the version of props.nas that got checked into the
base package. I'm sure that's my fault, sorry. Nonetheless, the file
won't parse as is. Could someone fix? Thanks. :)
Andy
+++ props.nas 2 Dec 2003 16:25:49 -
@@ -33,10 +33,10 @@
# Static constructor. Accepts a
[Heh, this turned out longer than I expected when I started writing...]
Curtis L. Olson wrote:
I would recommend doing a net search for CLOD (continuous level of
detail) and ROAM (I forget what that stands for.) There are a lot of
spiffy demos out there. However, there are some non-trivial
Lee Elliott wrote:
A couple of things about modelling sea-planes in FG though - a) unless
you start in the air, you have to start on a runway, and b) with
YASim, at least, you can't define the fuselage properly because part
of it has to start below the surface and you get a collision at
Erik Hofman wrote:
Not at this moment, no. That would require intervention from a
Nasal script (which isn't implemented yet).
Actually, if you guys used property ties to wrap your internal
variables, you could drive it with Nasal right now. You can either
tie a pointer to the actual data, or
Marco Gugel wrote:
d:\Flightgear\SimGear-0.3.4\simgear\screen\jpgfactory.hxx(30) : fatal
error
C1083: Cannot open include file: 'jpeglib.h': No such file or directory
Where I Can find this file? It isn't in plib, glut, simgear, flightgear!!
The simple answer is: It's in libjpeg.
Erik Hofman wrote:
Even for (say) a dozen of simultaneously active dynamic models? I'm
not sure, but it would be a good thing to look into.
Even for hundreds. The overhead for a property tie is pretty close to
zero. You pay the cost only when the property is accessed -- to your
internal C++
Melchior FRANZ wrote:
But only if the animation was triggered and as long as the movement
lasts, which is a time where the operator watches the animation,
anyway, and couldn't care less about a few extra cycles. Apart from
that there should be zero overhead. Have I misunderstood the
settimer
I wrote:
It's easy to see every model (maybe a few dozen around a busy
aircraft)
^
port
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Melchior FRANZ wrote:
How will this sample code react, if the door has already opened half
way and a second trigger happens? Will it stop immediately (like the
current code does) and start to close?
Yes. I forgot to mention that feature of your original: it was very
slick. If all you want to
OK, time for more stuff, mostly Nasal or Nasal related. Curt gave me
write access to the CVS repository so I've checked it in myself.
Shout if I broke something.
The FGNasalSys subsystem now has a parseScript() method that returns a
pointer to a FGNasalScript object. You can use this to hold
501 - 600 of 1282 matches
Mail list logo
