Christian Mayer wrote:
For our case that compressor must not rely on special optical
tricks (because these get destroyed when they are used as an
texture).
All lossy compressors rely on special optical tricks, that's the
point. If all the data was equally important, you
couldn't lose any of
Curtis L. Olson wrote:
If he has all these things, then that's wonderful, he has done an
impressive piece of work. I'm not trying to be critical here, I'm
just pointing out that this is *very* difficult stuff. It's one
thing to do a nice little demo, it's something else entirely to
tackle
Arnt Karlsen wrote:
..riiight, we all can agree on that, now try keeep in mind _none_ of
us are IBM, and The SCO Group is still running its 2 yr old 419
scam in the 9'th Circuit Court before Judge Kimball in SLC, Utah.
Relax. Under no circumstances will we be any more exposed than if we
Jim Wilson wrote:
Speaking of which, in the prop config, what exactly do the cruise
numbers do? If I'm not getting enough thrust still out of the prop,
what should I mess with first?
This is the black magic part, and could really use a redesign. The
cruise pitch (the RPM and an airspeed)
D Wysong wrote:
I'm using a custom texture that I created using OpenGL directly
(instead of via plib) and I'm getting HOSED when FG decides to go
load new textures
Are you sure you aren't picking texture names that collide with the
SSG loader? If you use glGenTextures(), you should be safe.
Jim Wilson wrote:
What should I look for then when mucking with the cruise numbers from
the prop definition? Or is there some way to just remove them?
One thing to try would be to remove the variable pitch settings
entirely and nail the prop down at your specified cruise setting
(which should
Jim Wilson wrote:
The min/max range, does that refer to engine RPM or propellor?
Propeller. It's a setting for the governor. With the newer syntax,
the engine and propeller are separate XML tags, so hopefully it should
be clearer which is which. If an attribute on the propeller tag takes
You're right, the picture shows a Projection field too. Complete infos are:
Datum: WGS84
Projection: NUTM33
Coordinate top left
x: 353620.2 y: 4225543.6
Coordinate bottom right
x: 354212.2 y: 4225976.1
Those are odd looking numbers. The WGS84 standard specifies a
datum, which is a
Jim Wilson wrote:
But those numbers you gave me seem to be engine RPM numbers. Sorry
for the confusion. The gear ratio is 0.479 and the merlin max rpm
is 3000 rpm.
Ah, I get it. Sorry for the confusion. :)
I guess the gauge in the cockpit shows engine speed, but the YASim
file wants
Vivian Meazza wrote:
Yes - perhaps Andy will recall our long discussion of a year ago?
Only vaguely, and I currently lack the time to crawl through the
archives. You keep hinting that you want something done. Can you be
more specific?
Andy
___
Jim Wilson wrote:
Now I'm finding that we're seeking the engine rpm instead of the
prop-rpm.
Andy Ross wrote:
If an attribute on the propeller tag takes engine RPM, then that
would be a bug.
See? I was exactly right. :)
Can you try the following fix to PropEngine.cpp? That should fix
Jim Wilson wrote:
Here is my local config for the p51d yasim propeller. Most of these
values are pretty much on target according to actual specifications.
The problem is that it appears to not produce sufficient thrust.
I did actually get started on this at one point. :)
The first problem I
Jim Wilson wrote:
So, let's assume you got a good manual. How does this RPM governor
control work? And how can I implement that in YASim?
Just set min-rpm and max-rpm properties to the RPMs in the handbook,
basically. The propeller will automatically modify its pitch to seek
to those values.
Jim Wilson wrote:
If you look at that manual the diagram in Section I that shows
the control box, indicates at #12 Prop Control (I've only got
about 6 pages from that manual). That's the blue knob with the
P on it in the model. The control box indicates Max RPM with
the blue knob all the way
Dave Martin wrote:
Something I noticed early on is that the mass needed distributing for things
like Engine+Gearbox sets and Maingear etc as Yasim just evenly places the dry
mass otherwise.
Yeah. Evenly placing the mass is a great way to get the overall mass
distribution (the inertia tensor,
Curtis L. Olson wrote:
Bear in mind that one thing that is commonly done on many
aircraft is to pop up a spoiler on the wing that should drop.
This can be a lot more effective than just deflecting airflow
with the aileron. To my knowledge, YAsim doesn't model this
directly [...]
Actually,
Christian Mayer wrote:
But I only want class A to be an interface that tells everybody what to
expect from it's derivated classes. And one of these things is, that
every child must have a member that is called foo and has one
parameter of the type of the child itself.
How do I achieve that?
Arnt Karlsen wrote:
..well, all good jokes can't come up with a potential like the
http://gpgpu.org; your average recent GPU chews code 6 times
faster than your average CPU. So, we can use part of the GPU
to show pretty pictures, and the remainder, say half, to say,
triple FG framerates?
Martin Spott wrote:
I wonder how you ever managed to make them accept patches of obvious
necessity. If I were you I'd already have lost my countenance
They're a little slow sometimes, but things get done eventually. I
checked to see that my set of GUI rendering fixes from last May made
it
Wolfram Kuss wrote:
However, CFD programs need a watertight geometry. I would
guess that far in excess of 90% of models are not. For example,
each edge needs to have two neighbour faces.
It's even worse than that. Real world aircraft performance is
sensitive to all sorts of details that are
Curtis L. Olson wrote:
Dumb question: do we want to investigate the possibility of adding
google adds to the FlightGear site?
FWIW, it's fine with me. If the worst thing FlightGear does in this
world is make Curt rich, I suspect I'll still be able to sleep at
night. :)
Seriously, having some
Martin Spott wrote:
Does anyone have experiences with portable GPS recievers ? Do they
tend to increase the precision of their coordinate output if you
remain at a location for several minutes ?
My wife have gotten into geocachine (www.geocaching.com) over the last
two years, so we've played
[bouncing replies to flightgear-devel]
David Megginson wrote:
I don't know if we're modelling this or not, but with full power you
often need a lot of rudder to keep a plane straight during the
takeoff roll even when there is no crosswind. During the landing
roll, with no power, it is a lot
Martin Spott wrote:
While I'm digging through the sources in the hope to find the cause
for some mislead header includes I wondered about notation of
several include statements. To my knowledge system includes should
be bordered by brackets:
It's not really well specified. Usually: using
Ed Baker wrote:
Does anyone know if there is a parametric plane generator for FlightGear.
I'd like to be able to play out what if simulations with a tool
like this.
The YASim solver is a parametric plane generator, but probably not in
the sense you want.
You seem to want a tool where you can
Some people may notice that I just announced a new Nasal version on
Freshmeat.net today. This release includes support for the
oft-requested recursive contexts feature. It uses it internally to
implement call() (a functional programming gadget that most people
don't care about) and eval()
Curtis L. Olson wrote:
Finally, I get to realize my dream of re-implimenting all FG
algorithms using recursion.
Not to ruin the joke, but you could do that already. Nasal has always
been a fully functional language, with recursion, lexical closures and
anonymous lambda expressions. :)
This
Gerhard Wesp wrote:
1. GNU C++ structure layout may _differ_ between different compiler
_minor_ versions. E.g., one sizeof() was 504 bytes on Linux with
g++ 3.3.3 and 520 bytes on Cygwin with g++ 3.3.1. Both on x86.
Are you sure? Starting with the 3.2.x releases, g++ is supposed to
have
Gerhard Wesp wrote:
I thought about Solaris. Seems to be absolutely straightforward to
install. But I don't know anything about OpenGL and GPU support.
Linux: X11 installation (especially GPU drivers) were a pain last time
I checked (requires kernel compile!). Has this changed in the
Lee Elliott wrote:
Just a thought... An alternative approach might be to make the
textures dynamic so that the roads could be overdrawn on them before
they're rendered.
Way back in the day (maybe 3-4 years ago, when I was at NextBus) I
wrote a parser for the TIGER database format, an
Curtis L. Olson wrote:
Is there any documentation that explains how the nasal scripting
system is integrated into FlightGear? I looked a bit, and can't
find anything.
Sure:
http://plausible.org/nasal/flightgear.html
This should probably move to the FlightGear site, I suppose.
If I
Matthias Froelich wrote:
This case kind of works for the arrester wires. The braking force is
just hacked into the gear code. But this is just to be able to test.
What would probably be a better idea (at least for YASim) would be to
model the braking force as a *distance* over which the
Melchior FRANZ wrote:
As you can see, Integrator::l2gVector() does not access its parameter
orient, but the object variable _s.orient!
Andy says that the code is correct.
Andy was wrong. :) I misinterpreted the diff you posted in chat to
indicate that the original code should use the
David Garcia Moreno wrote:
I´m trying to communicate the Flight Gear with a 2D-map display,
which works with cartesian coordinates instead of geodetics as the
Flight Gear works. What i was able to get only was the position in
cartesians (absolute_view_pos).
The only true cartesian coordinate
[Sorry I've been so long getting back to this; I had to go to Japan on
short notice and this is the first chance I've had in the hotel room
to catch up on personal stuff without jet-lag. :)]
Boris Koenig wrote:
I don't seem to be able to access a method like gui.Widget.new()
from an object
Boris Koenig wrote:
Thanks for the answers so far, I was already playing around with the
gui.nas file, will have to look into it in more detail in order to
see how to get the positioning part done, though.
Essentially, you can just set x and y properties on the top level gui
object. There is
Boris Koenig wrote:
1)I would like to be able to display a simple text string at
runtime in the upper left corner of the screen using
Nasal (in order to display simple in-flight information).
Check out gui.popupTip() to see if that does what you want. If not,
you can look at the
Matthew Churchill wrote:
Linked to my other post could anyone tell me if it is possible in
linux to share a stream of nmea data. On my Zaurus I've got a cf card
GPS sending NMEA data on /dev/ttyS3. What I'm trying to do is
simultaneously cat this to a file yet also have it available for use
Lee Elliott wrote:
In a/c that have one or more VC views there's a visible 'jitter'
when looking at parts of the a/c, most notably in my experience,
with the windshield/canopy frames.
This is a bug, not an intentional feature. :)
It's a precision problem with the view code. The current
David Culp wrote:
Does anyone know of where in the FG code base I can find a function that takes
a position in 3-space and gives the resulting position after a pitch/roll/yaw
set of rotations?
I assume this function already exists somewhere, either in SimGear or in an
FDM. From what I've
Vivian Meazza wrote:
This is, I believe, due to a bug at line 67 of the script
~/data/nasal/fuel.nas which improperly sets the tank property
kill-when-empty.
Haven't we already been here and thrown out this explanation? Here is
line 67:
if(t.getBoolValue(kill-when-empty)) { outOfFuel = 1;
Melchior FRANZ wrote:
Yes, I've seen these annoying bugs in both the Spitfire and the
p51d. Vivian's changes to fuel.nas fix them. I haven't seen any
negative side effects.
Could someone please replace fuel.nas?
Could someone *PLEASE* explain, from scratch, exactly what is wrong
with the
OK, Melchior helped to debug this via chat while I was working on cell
phone UI bugs at work. :)
It turns out to have been a pair of typos in fuel.nas that were
causing all the problems. What I *read* wasn't what the code was
actually doing, which explains all the confusion.
This one, though,
Dave Perry wrote:
End common FDM init
Aborted
Here is how I launched it.
XML parse errors in YASim files become aborts. I'd look very
carefully at your dc3.xml file and make sure it doesn't contain
extraneous information (cvs collision warnings, etc...)
Andy
Matthew Law wrote:
David Megginson wrote:
Matthew Law wrote:
It seems much, much better to me. However, I can sit at minimum
power with the brakes on in nil wind and rock from one main wheel to
the other using the ailerons. I can also lift the tail off the
ground at minimum power.
Vivian Meazza wrote:
Slightly higher would be the suggestion that out-of-fuel should not
be terminal though, since pilot error can end up with a full tank
not connected to the engine. In real life - reconnect - problem
solved (or nearly). So far as I can see that is not an option in our
sim.
Vivian Meazza wrote:
David Megginson wrote:
Vivian Meazza wrote:
Slightly higher would be the suggestion that out-of-fuel should not
be terminal though
That's not an uncommon occurrence on low-wing planes, from what I
hear: when Cessna pilots rent low-wing planes, you sometimes get
David Megginson wrote:
OK, try this: I'm flying on the left tank in my Warrior and not
switching.
The tank goes dry and the engine stops. I switch to the right tank,
and as
long as the prop is still windmilling, the engine springs to life
again in a
few seconds.
Is that the way things will
Innis Cunningham wrote:
As far as I can tell there is no property to simulate a stabilizer
trim system in flightgear. If this is not the case then maybe some
kind soul could point me to the said property.
What's wrong with /controls/flight/elevator-trim?
Stabilizer trim is an FDM
Jim Wilson wrote:
Have I had this backwards all along? I knew of the incidence angle
on the hstab, but always thought that positive values meant the
leading edge was higher than with a negative incidence angle
The number is a (conventional, right handed) rotation about the Y
axis, which in
Innis Cunningham wrote:
Andy Ross wrote:
What's wrong with /controls/flight/elevator-trim?
Because stab trim and elevator trim are not the same. It is like
saying a piston engine and a jet engine are the same. They are in the
fact that they both provide thrust to the aircraft.It is how
Vivian Meazza wrote:
The gotcha is that the engine stops when either tank is empty,
rather than when there is no fuel in any tank. I can't see a
way around that without tinkering with the logic of
fuel.nas.
No, there's actually a feature for exactly this situation:
That said, the logic of
Vivian Meazza wrote:
I was thrown at first by the comment, but on further analysis the
logic is fine, but the code doesn't seem to work correctly. When the
top tank is empty the logic requires that, if kill-when-empty is not
set, for it to be simply deselected. This isn't working: the
Vivian Meazza wrote:
I'm just working on the fuel gauge for the Spitfire, when I
ralised that I haven't modeled the fuel system correctly. At
present both tanks feed into the engine. What should happen is
that the upper tank feeds the lower tank which feeds the
engine. Is there any built-in
Jim Wilson wrote:
On my system (CVS), the xml dialogs keep shrinking, just like Mike
Teevee.
Confirmed. Unfortunately my analysis has been delayed by the need to
google the Mike Teevee reference. :)
Seriously, I'm really busy right now at work, so I'm hoping someone
else can hack at this for
CHANDRASEKHAR ACHALLA wrote:
I am doing a project for Boeing where I am trying to incorporate a
few additional features they want into Flightgear. Initially I need
to create a crater (hole) if a plane crashes (or a missile ).
Boing wants craters? :)
This is actually kind of hard. The
Boris Koenig wrote:
There seem to be some issues regarding the XML file processing
and FlightGear's stability:
#Nasal parse error: empty subexpression in command, line 3
#Failed to execute command nasal
#Segmentation fault
The XML you posted contains no Nasal script, so I'm at a
Erik Hofman wrote:
* The ability to load a set of sheets, one after each other.
* Be able to add the following to these sheets:
- Dynamic text at a static location (*)
- Static images (*)
- Animated instruments that react to actions of the user(*)
Most of this sounds like the
Boris Koenig wrote:
Erik Hofman wrote:
I'm still not convinced that a plugin system would be such a great
idea for FlightGear.
Well, I am just making suggestion :-)
I think most of the criticism centers on the idea that, even if you
had a nice plugin system available, it really isn't
Ampere K. Hardraade wrote:
Can someone please look through the code and tell me how
FlightGear handles ambient, diffuse, illumination, glossness, and
specular for 3ds files?
Not to pass the buck, but this is really a plib question. I
don't know who wroat the 3ds loader for ssg, but they're
David Megginson wrote:
Can anyone actually fly the Spitfire model in CVS? I wonder if there's something
wrong in the YASim
config file.
I know Vivian has had trouble getting it working with the gear ratio
stuff on the engine. This (along with tuning the p51d) has been on my
list for
Mathias Fröhlich wrote:
Which ssgBranch contains objects like an aircraft carrier?
Special-casing aircraft carrier is almost certainly the wrong way to
do this. There is no reason we can't do correct 3D intersection
against the whole scene graph, and the code will be cleaner and
simpler.
The
David Megginson wrote:
Once we support ground reactions with a moving surface (like the
deck of a ship), why not just model the catapult as a faster moving
surface?
Because the gear don't simply rest on the catapult to be pulled along
via friction, they're actually bolted to it during the
Jon S. Berndt wrote:
I thought initially that a spring was not the way to go, but I think
you are picturing a spring that (figuratively) goes from the bow of
the ship to the nose gear, no?
Actually, I was thinking about a spring centered on the point where
the cat harness would be based on a
Chris Metzler wrote:
[...] a different paint job/livery effectively means a new aircraft.
Is this right?
Pretty much. Although this wouldn't really be hard to fix, if anyone
wants to give it a shot. One way to go about it would be to provide a
mapping somehwere in the aircraft properties
Josh Babcock wrote:
Does anyone here know a better way to get ac3d_export.py to
recognize two sided polys in blender other than going into face mode
and individually selecting each one and setting it to twoside in the
texture face menu?
Is there a reason you absolutely need it? Using
Erik Hofman wrote:
Andy Ross wrote:
Seriously: consider the case where this symbol came out of a library
that we *don't* link to statically.
Why would I?
Then this would undeniably be a
bug, because the library would be unmapped before the function could
be called. Honestly
Erik Hofman wrote:
Since FlightGear is linked to libGL at link time, the number of
dlclose calls would always be one less than the number of dlopen
calls.
In which case the dlclose() is 100% guaranteed to be a noop anyway and
can be safely removed. :)
Seriously: consider the case where this
David Megginson wrote:
Some of these are using the bindings solely to set flap detents
we should find a better system than that.
We already do, actually. Take a look at the 747 configuration,
you basically just drop in a /sim/flaps section that looks like:
flaps
setting0.000/setting
Erik Hofman wrote:
Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't
supported in IRIX anyhow). I think that if what you describe is the
problem this really is a bug at your side. What happens is that the
function pointer is copied to ftpr. So dlcose() should never be able
David Megginson wrote:
Does anyone have code that depends on having bindings for the
keyboard, mouse, and joystick(s) visibile in the main property tree?
Some of the joysticks (at least the X45, maybe others) use a mode
property under /input/joysticks/js[0] to track switch positions. But
this
Durk Talsma wrote:
I just noticed that there seems to be a discrepancy between the way
the flap settings are handled by the keyboard vs. the joystick.
Some joysticks are still using the old bindings. When I did the Nasal
control stuff, I only changed the joysticks I could test and/or felt
Vivian Meazza wrote:
Curtis L. Olson wrote:
Right, but the aircraft I have seen have just one *switch* ... off,
both, left, right (and sometimes starter power is rolled in too.)
If the physical aircraft has a separate switch for each magneto, then
the underlying logic should just change
Vivian Meazza wrote:
This works:
setprop(controls/engines/engine/magneto-switch[0],1);
But this doesn't:
setprop(controls/engines/engine/magneto-switch[1],1);
I can work around it no problem, but I think that it should work. I
can see,
but can't access ../magneto-switch[1] in the Browse
Erik Hofman wrote:
No, 64-bit is by default a bit slower. It's on very special
occasions that 64-bit outperforms 32-bit (due to data transfer
rate...)
That's true in the general case, because the larger pointer size
effectively reduces the size of the L1 cache. But for this
particular
Curtis L. Olson wrote:
Is there any functionality currently built into FG to request that
the mouse pointer be turned off or hidden. This would be useful for
things like a dedicated visual channel.
This is soft-coded these days. In mice.xml, you can define a cursor
image for each mode. You
Vivian Meazza wrote:
It's sort of usable right now under -0.9.4 with an ungeared
propeller, but I would not be happy for that to be released.
And I can't fix it until I get something to test against, so we're at
an impass. :)
Seriously: I'd say just commit the FDM as-is, and we can play with
Ampere K. Hardraade wrote:
Does FlightGear support bones and inverse kinematics?
For... airplanes? No. :)
Those buzzwords refer to techniques for character animation. With
very few exceptions, the things we need to animate with are rigid and
don't require such treatment.
Andy
Ampere K. Hardraade wrote:
Shame... they are perfect for landing gear animations.
Honestly, no, they're not. Typically, you use bones to provide a
framework for mesh deformation of an articulated object like an elbow
or knee. Landing gear parts are rigid, they don't deform smoothly and
thus
Ampere K. Hardraade wrote:
If I apply a single texture and a single UVW map across three
objects, would the resulting performance be the same as
splitting the texture into three parts and applying three UVW
maps to each object?
I'm not sure exactly what the question is. If you are asking
Erik Hofman wrote:
The radar display is currently limited to three (or four, I can't
remember) aircraft hard coded in the configuration file. Changing that
requires Nasal to be able to position a textured quad somewhere in
screen space or additional C++ code to handle all situations.
Trust me,
Josh Babcock wrote:
What about putting a node in the model xml defining what type of radar
return the object would produce (cross section size and transponder
y/n) and then having whatever code positions the object in the scene
graph also register the radar data in the property tree? That
David Culp wrote:
There have been reports of rudder kick when climbing through
atmosphere layers, which might be the same problem you're
seeing. I don't think it was ever resolved though.
I didn't think it was a bug. That's just wind shear, isn't it?
Andy
Chris Metzler wrote:
Sometimes I run into issues with FlightGear -- fgfs, data, scenery,
whatever -- that I'm reluctant to report because I'm concerned that
the developers already know about them;
Indeed, that's a good idea. We've been known to kill and eat
reporters of known bugs. :)
As for
Frederic Bouvier wrote:
I am surprised --prop:/sim/rendering/bump-mapping=false don't work for
you. I am also able to turn it on and off with the property browser
during flight.
Someone should put this into the rendering options dialog before we
forget. It's
really easy, try it. :)
Andy
Richard Bytheway wrote:
I have noticed that if I open and close the autopilot setting dialog repeatedly, the grey panel behind the widgets gets a little smaller each time, eventually disappearing.
There was a similar bug with the layout code that got fixed a few weeks
back. Are you
on current
Roy Vegard Ovesen wrote:
I've also thought about using a textured needle instead of an object
colored one. The textured one might look a lot better with variable
alpha creating an anti-alias effect, but I'm concerned about
performance.
Alpha blending is almost free on modern hardware, so I
Lee Elliott wrote:
The problem with using spoilers for roll control in YASim is that
because the spoiler range is clamped to 0 to +1, when you 'split'
the input for differential control it only works on one side of
the a/c - through the 0 to +1 range - to get it to work on the
other side it
David Megginson wrote:
Curtis L. Olson wrote:
So I have made this configurable for those that trust the data more
than I do. Just set /sim/navdb/auto-align-localizers to
true/false in the preferences file to turn this feature on or off in
the code.
I'd be more comfortable fixing the
Roman Grigoriev wrote:
Here is my new VBO code but it's so strange that it doesn't work with
flightgear give me segfault
also notice that it doesn't work with ptherads (I don't know why too)
So I move all vertex,tex,norm,color to constructor from draw method
plib applications work fine but
Josh Babcock wrote:
So maybe airplanes shouldn't be in the interface business. Maybe we
should spend our energy agreeing on property conventions and Nasal
scripts.
Even better would be to take a big audit of all the existing bindings
and re-assign them from scratch. We've accumulated all
Melchior FRANZ wrote:
hh ... now that makes sense. I couldn't read the word PERCENT. I guess
one needs to be native English speaker to be able to decipher that. OK, I'll
do this instrument now -- only the rotor hand, though, because there's no
turbine RPM in YASim (?). Maybe I'll make the
David Megginson wrote:
The worst b*ds in this whole mess are [...] the enterprise
anti-virus software vendors, who sell systems that automatically
send useless virus warnings every time a message like this comes.
Either
(a) they're complete idiots who couldn't be trusted with the
Vivian Meazza wrote:
Performance: max = 437mph at combat emergency power at 25000ft,
413mph at 15000ft, 395mph at 5000ft, cruising speed 362mph,
climb rate 3475 ft/min. Service ceiling 41,900ft.
How much is combat emergency power? The trick is getting the actual
numbers right, is it possible
Jon S. Berndt wrote:
Please do. It will be interesting to see what kind of relationship
there is between F-15D numbers and P-51D numbers, and how you relate
the two ...
Heh, oops. :)
For folks who didn't get the joke in my typo: the manual I ordered is
a post-war one for the North American
Jim Wilson wrote:
It'd be great if someone else could look at the P51D fdm. I'm
lost. Flight dynamics is neither my area of expertise or
interest. The only reason I did it in the first place is I had a
3D model that Jon supposedly had a JSBsim config for that never
materialized.
In
Curtis L. Olson wrote:
I don't want to over engineer an ultimate solution right now, I just
want a flag specifying wing icing or not.
You might want to make that a number, specifying a normalized
thickness in millimeters or whatnot. Ice is a progressive effect.
I suppose one could argue
Lee Elliott wrote:
Production Typhoons could exceed 530 mph in dives, with bombs/RPs, and
Tempests could overhaul V1s. I thought the Sea Fury was even faster,
but I don't have a figure off-hand.
The key words being in dives. The solver values are specified in
level flight. And dives can
Bo Shi wrote:
I need to stream information to some custom software
(pitch/yaw/roll) at frequencies on the order of 10 Hz -- what's the
best way to do this? I originally added some code in the main game
loop to dump this but that solution was an ugly hack at best.
There are lots of options.
One of the really cool features of the layout management code is that
it opens up the possibility of automatically generating GUIs according
to dynamic configuration.
This hack turned out just too well: do a rebuild (you'll need a bugfix
in dialog.cxx), update your base package and load up the
301 - 400 of 1282 matches
Mail list logo
