Jim Wilson wrote:
The problem with putting the turbo multiplier up in that range
is the manifold pressure output is directly multiplied by that
number. So full throttle produces an output of 164 inHG
manifold pressure. We should be seeing about 61 inHG at sea
level for this engine.
But
I wrote:
at sea level the wastegate setting*
Sorry, forgot to write this note to go with that asterix:
* Superchargers don't have wastegates, of course. Instead, their
behavior is generally an altitude-independent mapping of RPM to
manifold pressure added to ambient. But the wastegate
Mathias Fröhlich wrote:
At first I need to know how this local frame is meant.
What I have found from the code is that it is meant to be the *geodetic*
horizontal local frame.
But is is meant to be fixed at the aircraft and thus rotates due to the
aircrafts velocity or is it fixed at the
James Turner wrote:
Umm - I am not sure about the reason for making the change, but the
fact is that on Tiger, GLuint is a typedef for 'unsigned
long'. Hence, the code has to be changed to use the portable names,
or GCC 4.0 chokes.
Hrm... that sounds like a bug in the Apple headers. The
Mike wrote:
Andy Ross wrote:
Or if you really want to cheat: use the Cessna 3D model with the Piper
FDM configuration. :)
I think that's how this whole thing started... YASim FDM with c172
model results in a YASim solution error - insufficient elevator
trim.
Not the C172 model (which
Mike wrote:
Could you send me some specifics on the above procedure? I'm
playing around within the pa28-set.xml without much success.
In your Aircraft/c172p directory, edit the c172p-set.xml file and
replace these lines:
flight-model archive=yjsb/flight-model
aero archive=yc172p/aero
Jonathan Polley wrote:
configure: error: cannot run /bin/sh ./config.sub
and config.sub was not generated by ./autogen.sh. Any ideas as to
what needs to be done?
This is an automake file, and under normal circumstances it is a
symbolic link to a file in the automake distribution on your
Michael G. Grizansky wrote:
I noticed an earlier post regarding the A-10 yasim model with the
same error and the repair seemed a simple typo repair, ( filght
vs. light) in the control area. Is there some way I could perform
some maintennance on this model or am I bumping up against a steep
Erik Hofman wrote:
No, removeChild isn't broken, the GUI code was broken.
Erik, you seem to have missed the point. Sorry, but this call is
definitely bugged. Call removeChild() on a node, fetch the node
again, it should return null, but you get the old node even after it
was removed.
The
I wrote:
Erik Hofman wrote:
The removeChild() code was used because we wanted the dialog to appear
with the same dimension and location after loading the configuration
file again. But we don't do that anymore, the settings remain in the
property tree so the removeChild calls should have
Erik Hofman wrote:
The way the code works is like this (I show it only
for width, but it's almost the same for x, y,
and height:
Er... no. I wrote it (the layout support we are talking about),
remember? :)
The layout manager is a preprocessor. It takes the
x/y/width/height properties as
MICHAEL G KRIZANSKY wrote:
I'm getting a YASim Solution Error when I try to run the c172r-yasim. The
error states insufficient elevator for trim and FG then aborts. Is there
anyone that can point me in the right direction.
This particular configuration isn't maintained. I did it long ago when
Melchior FRANZ wrote:
Sure. I was you who said we'd be better off reverting. I'm all for
fixing it. I just don't know how to do this without breaking
everything. Or I would have fixed it already.
Give the attached patch a try. It removed the whole idea of saving
removed nodes for future use*
Melchior FRANZ wrote:
I've found the bug already. In dialog.cxx:
// Remove automatically generated properties, so the layout looks
// the same next time around.
if(!userx) props-removeChild(x);
if(!usery) props-removeChild(y);
if(!userw) props-removeChild(width);
Melchior FRANZ wrote:
Only Nasal dialogs are generated new every time. The ones in
$FG_ROOT/gui/dialogs/ are only read once and then remain in the
property tree, no? When such a dialog is displayed next time, it will
again read x/y/width/height ... which were removed at the end of the
first
Melchior FRANZ wrote:
For example, the removed x value on second display is read again:
Both of those circumstances have a default value specified, for
precicely the reason that the nodes may not exist.
Calling getIntValue(node, default) on a node that had previously been
deleted with
Melchior FRANZ wrote:
(0) removeChild() didn't *really* remove the node, but only mark it as REMOVED
(which is OK and done for performance reasons)
Well, that's the bug certainly. In fact, a quick grep through the
property code shows that flagging the node as removed is, in fact, the
sole
Melchior FRANZ wrote:
Curtis L. Olson wrote:
I think this is a very minor issue
Agreed. I wouldn't have asked if I had thought that this even is a
controversial topic. I though it's clear which of both are preferred
by the majority of *users*.
Maybe an elegant solution would be to write an
Melchior FRANZ wrote:
One that desperately waits for a 3D model is the Harrier.
Yes, please. :)
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Melchior FRANZ wrote:
To fix that I added a clear() method to SGPropertyNode, which does
first call private clear_node() and then sets the type to NONE. Only
now a new type can get assigned. This new method is called from the
XML handler's startElement()
This looks good to me. It only does
Tymoteusz Puciek Paul wrote:
Well i know that, but let's look at cessna, when engines turned on,
brakes on so it stay in place but turn controler (as whole plain)
shake as he wan't to go but he can't (throttle set to 0)
JSBSim planes* shake a little when they are on the ground due to the
way
Martin Spott wrote:
If there's no suitable replacement for 'finite' then I'd suggest the
following patch:
Alternatively we can just use something like the following (untested)
code. All modern CPUs (and certainly all the ones we support) use
IEEE format for their floating point values.
int
Ben Morrison wrote:
I am trying to display the HUD in the center of the screen no matter
which way the viewer is looking. Currently in the center of the
screen if the viewer is facing straight forward. Can anyone point
me in the right direction?
Try toggling /sim/hud/enable3d. The original
Martin Spott wrote:
Can anyone give me a hint on how to determine the defines that are
set by the compiler itself ?
With a gcc variant, you can do something like:
echo | gcc -E -dM -
This is kinda fun, you can watch how the built-in defines changes as
you vary the optimization switches and
Mathias Fröhlich wrote:
I have done a patch to eliminate the jitter of 3D-objects near
the viewpoint (for example 3D cockpit objects).
Excellent. This bug has been annoying me for a long, long time.
I think the solution should be simpler, though. Right now, the
scene graph looks (from
Just nocied this on the simgear-cvslogs list. If I read this
correctly, this is still a terrible bug, and even worse because it
will be much harder to detect and correct in the future. The FOV is a
dynamically settable property. Hardcoding a particular value is going
to cause very odd behavior
Melchior FRANZ wrote:
Wouldn't work in my case. Would only make it even less
elegant. Then I better stick with this:
Only if you don't want to write your own functions (in which case
every feature I don't want to support is going to be inelegant
and you'll never win until I turn Nasal into
I wrote:
Write a function to [...]. Compose them appropriately to set bits
in numbers. Probably four lines of code,
Turns out it's three lines of code:
n2s = func(n) { var s = buf(6); setfld(s, 0, 48, n); return s; }
getbit = func(n, b) { getfld(var s = n2s(n), b, 1) }
setbit = func(n,
Erik Hofman wrote:
I have added the new 3d clouds code from Harald Johnson to CVS.
Should we then remove the previous implementation? Ultimately, there
is only space for one cloud implementation; if the existing clouds3d
stuff isn't going to be the current target of development, it is only
More not-quite-FlightGear subject matter ahead. But I need advice:
Nasal needs a character constant syntax. That is, the ability to
write an ASCII charactrer as a numerical constant. In C/C++, you use
single quotes to do this (e.g. the token 'A' is just a synonym for the
integer value 65).
Erik Hofman wrote:
At first I was thinking using #'A' since # represents a number
already in most cases, but then again; how about just using a
new function?
Just to be clear, there is a function to do this already: strc()
returns the value of the Nth byte in a string. The index
defaults to
Vivian Meazza wrote:
y = -0.25x3 + 0.15x2 + 1.11x
Thinking about the over-speed situation overnight, the Merlin was
allowed to go to 3600 rpm for brief periods, and even then damage to
the engine was possible. This is a normalised value of 1.2. The K
Series will go to 9000 (don't try this on
Heh, it's been a fun day. I woke up with one of those great insights
where you realize that something you thought was difficult just isn't.
In this case, it was the lack of += syntax (and -=, *=, /= and ~= of
course) in Nasal. They're checked in now.
I also threw in a forindex(i; list) loop
I wrote:
Finally, there's now a slight esoteric bind() function
Which sounds weird, I know. But here's an application:
Languages like Perl and Ruby have a really useful syntax (which they
got from the shell) for interpolating variables into strings, so
that for simple output you don't have to
Drew wrote:
IMHO, it's best to use interpolation tables rather than equations if
you're trying to curve fit empirical data.
Not in this context. The data here isn't being used to model a
specific engine, but to provide sane parameters for all
(super/turbochared) engines. The performance and
Drew wrote:
I tried downloading the tar archive of the latest CVS flightear, but
it doesn't compile with the latest release of SimGear. Is there an
archive somewhere of a development SimGear version, or will I have
to install a CVS client to get this code? I'm using Windows, and
have never
Vivian Meazza wrote:
The attached diff models the output of a gear-driven
supercharger
I just now got a chance to sit down and puzzle this out. I see where
it's going: instead of ignoring the RPM contribution to boost, it adds
an extra factor that reduces the boost at lower RPMs. It works by
Vivian Meazza wrote:
I used the power form because it is easier to read, but if the other
form produces a performance advantage, then of course we must use
it.
It's actually not so much about performance, really. Readability can
mean different things. The problem is that when I see a
Erik Hofman wrote:
When I start FlightGear I get the following list of errors on IRIX
(big-Endian) (Linux doesn't have this problem):
This looks like the GC is cleaning up objects incorrectly. On the
assumption that this is an endianness issue: Is this for a 32 or 64
bit target (Nasal has
Dave Culp wrote:
Are tabbed dialogs possible?
Not really, although you could simulate something like that by
destroying and recreating a different dialog with a button press.
You'd need to play some complicated games with the layout to make it
the same size, though.
Andy
Oliver C. wrote:
How does X-Plane 8.1 solve that?
It's not that terribly hard: store the texture mesh (2D, from the land
use data) and polygon mesh (3D, from the elevation data) separately
and do an intersection test when generating them (or even at load
time).
If the textures are allowed to
Martin Spott wrote:
Andy Ross wrote:
Can anyone else on a big endian system (Mac, Sparc) see the same
or a similar problem?
I would do if I could - I'm still busy with digging through Port
me! Platforms that don't have stdint.h errors in
src/FDM/ExternalNet/ on Solaris
Curtis L. Olson wrote:
Hmmm, I wonder if this is a way to hide the cursor so it doesn't
appear in the screen shots?
I'm pretty sure there's a null cursor you can set. I remember
dealing with that stuff when doing the SDL port. This won't move or
change the mouse cursor, but it will make it
Melchior FRANZ wrote:
Improved dialog nasal file attached. Just drop it into
$FG_ROOT/Nasal/ again. It does monitor the property
/sim/rendering/blackout and turns the screen black accordingly. And
it offers three commands for Nasal context:
Cool, now animate the alpha value and tie it to the
Melchior FRANZ wrote:
Drew wrote:
switch = props.globals.getNode(/sim/rendering/blackout, 1);
Does this property need to be declared somewhere?
No. The line is OK. But maybe your version of fgfs isn't? The Nasal code
is for fgfs CVS/HEAD. It uses Nasal syntax that was added to CVS
Frederic Bouvier wrote:
I found where it is not C : you don't always declare local
variables at the beginning of functions but you have the C++
habit to declare them as you need them.
... which is a well-established feature of the (now 6-year-old!)
C99 standard. It's not a C++ thing. And GCC
Erik Hofman wrote:
It is, in fact MIPSpro supported c99 before gcc did, but you need a
compiler option to enable it which is the only valid way to enable
it. Just face it, gcc behaved bad (again).
I don't follow the logic. If that were the true, then the only
valid result of running a C
Erik Hofman wrote:
It's quite simple, SGI has the zero warning compiling philosophy; No
build will be shipped if it generates a warning. It has gained them
the reputation of being one of the most stable UNIX variants
available.
Now I'm even more confused. What warning are you talking about?
Vivian Meazza wrote:
It won't compile under Cygwin using gcc either. Fails with:
NasalSys.cxx:292: error: invalid conversion from `naRef (*)(Context*, naRef,
int, naRef*)' to `naRef (*)(Context*, naRef)'
You forgot to update your SimGear, or have an old one still
installed somewhere. The
Vivian Meazza wrote:
The attached diff models the output of a gear-driven
supercharger. I've used a 3rd order polynomial which matches the few
examples I have been able to find, giving near-linear output up to the
max-power rpm of the engine, with a little tail-off below this point,
and a
OK, I *finally* got the last of the (known) bugs fixed over the
weekend, so it's time to make a new Nasal release. Enough has changed
(all the advertised features are now present and working) that I think
this will be a 1.0 release.
I'm not finished doing the documentation and website work for
I wrote:
Here's a quick overview of the changes (or at least all of the ones
I can remember at the moment):
Yup, forgot one:
The C syntax for conditional expressions (A ? B : C) now works in
Nasal like you expect. This is 100% identical to writing
if(A){B}else{C}, and I had originally planned
Frederic Bouvier wrote:
2. MSVC use file extensions to choose the right language to
compile. So in misc.c the syntax of C not C++ apply. This file
should definitively be named misc.cxx, like lib.c should be lib.cxx.
Definitely not. I promise you that it's a C file. The only C99
feature that
I wrote:
4. I have a warning on a non standard extension used on
naRef array[];
This one is new, but I honestly thought it was a standard C89 feature.
Can you post the warning? Or is there a #pragma I can use to turn it
off?
I just looked it up. This one is actually a C99 feature, not
Jim Wilson wrote:
Melchior FRANZ wrote:
Not done, because it's not needed yet. The respective aircraft
maintainers are expected to keep their text column narrow enough.
This will work ok at 640x480 without a scroll-able wrap-able text
widget?
FWIW, we also need word wrapping to support
Lee Elliott wrote:
I've got two flight models in development that use the YASim turbine
engine and [...] the fuel flow figures are of the order of several
hundred million gallons/hour.
There was a units bug with the default (and currently untunable) BSFC
number. Try it now and see if that
Arnt Karlsen wrote:
Andy Ross wrote:
There was a units bug with the default (and currently untunable) BSFC
number.
..could the BSFC figure be moved to the config tree? (Would allow
modelling exotic fuels etc too.)
I lied. You actually *can* set the fuel consumption on the turbine
engine
Steve Hosgood probed:
However, we can't ignore the fact that, good though it may be,
FlightGear is basically a video game.
Don't feed the trolls, folks.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
BONNEVILLE David wrote:
I think I see what you mean, but my intention is to make a .NET
project that is coherent with the GNU makefiles so that I could
fully use all the wonderful .NET functionnalities is it too
much ?
Don't feed the trolls, folks. :)
(OK, that probably wasn't an
Steve Hogood wrote:
Some of the folk on this list are private pilots from what I see being
discussed. How well do those pilots reckon the simulated aircraft in
FlightGear mimic the real ones, given that the FDMs are (apparently)
empirically created from the aircraft's basic layout and physical
Vivian Meazza wrote:
However (and there's always a however), I can't land the
thing. Closing the throttle and pulling back the propeller pitch
control doesn't reduce the power enough. I reasoned that there was too
much boost with the throttle closed, (currently set at 10%,
AFAICS). 10% of the
Josh Babcock wrote:
The Superfort's flaps and gear are electrically powered, and the
controls for both are instantaneous switches. ie. you have to hold the
switch the whole cycle to keep the motor running. Can anyone think of
a way to do this? For all I can tell, there's no way to tell YASim
Melchior FRANZ wrote:
Normally, the g key turns on /controls/gear/gear-down, and YASim
watches this property and moves /gear/gear[n]/position-norm
accordingly. You just need to override the g/G key bindings in your
*-set.xml file:
Since this is obviously going to be a common issue, maybe it's
Erik Hofman wrote:
Martin Spott wrote:
Josh Babcock wrote:
The Superfort's flaps and gear are electrically powered, and the
controls for both are instantaneous switches. ie. you have to hold
the switch the whole cycle to keep the motor running.
BTW, if someone attempts to create a
Melchior FRANZ wrote:
Yes, we want motion over time. slew sets the property only once. So we
are again back at interpolate()? That's what aircraft.nas does already.
Or would you suggest to write a loop that runs as long as the key
is held down? Would be slower, wouldn't it? And doesn't
Fridtjof Busse wrote:
I'd say the X52 then has exactly this problem. One bit is always on,
since it has a mode-switch (doesn't do anything without the
windows-software) which always has a bit set.
You can write a joystick definition to use that mode switch however
you want; on all systems.
Curtis L. Olson wrote:
Hmmm, for myself (linux) these things were working correctly until
just very recently (the last week or few days.) I wonder if the
changes to Nasal surrounding it's concept of 0 vs. false has broken
portions of the script in controls.nas?
I kinda doubt it. The bugs
Curt wrote:
It looks like /autopilot/locks/speed is a string field. It appears
that no longer equals 0. My assumption when I wrote the script
(hehe, I think I wrote that script, apologies to whoever if I
didn't) was that for the comparison with zero, auto.getValue() would
be converted to a
Curt wrote:
FWIW, testing against instead of 0 works with the latest nasal
changes.
Indeed. Actually, with the fix as of a few minutes ago you should be
able to do just:
if ( !auto.getValue() ) { ... }
The empty string and zero numeric values are both false, as is the nil
reference.
Andy
Vivian Meazza wrote:
I have the same problem with Main/renderer.cxx. Your solution (or
one very like it) solves the problem. I guess near/far are reserved
words in Cygwin?
Goodness, that brings back memories. The near and far keywords are
holdovers from 16 bit DOS compilers. They are still
Curtis L. Olson wrote:
Hmmm, I see write away that even if I use int8_t or int16_t, they still
get padded out to 4 bytes in the structure that is sent across the net
(on 32bit Linux.) Does that mean we always want to use int32_t to avoid
potential confusion, or is this situation ok?
Most
Curtis L. Olson wrote:
I see that Linux (C99) has an inttypes.h include that defines: int8_t,
int16_t, int32_t, int64_t and uint8_t, uint16_t, uint32_t, uint64_t
I looked this stuff up recently while doing some work on Nasal. The
header you really want is stdint.h, which is where the C99
I wrote:
Jim Wilson wrote:
4) Fixed rpm/power numbers under the prop tags. They need to be
scaled back according to the gear ratio. Someone with a better
understanding of mech engineering might be able to explain why the
BHP on the prop shaft is reduced by a factor of 0.35 when
Jim Wilson wrote:
4) Fixed rpm/power numbers under the prop tags. They need to be
scaled back according to the gear ratio. Someone with a better
understanding of mech engineering might be able to explain why the
BHP on the prop shaft is reduced by a factor of 0.35 when that's
Arnt Karlsen wrote:
..what had me wondering is the eng-rpm in the turbine-engine section,
where these word of wisdom appears: ;o)
And what would you propose? Turbine RPM is almost never quoted in
real units, but in percentages. Where is appropriate, the
documentation tells you to specify
Josh Babcock wrote:
Jim Wilson wrote:
It means you've found a bug in the solver. I don't recall it doing
that. Maybe it is just a missing sanity check. Post what you have.
It looks like it's only getting one line into the file. I'll muck with the
first few lines and see what I can do.
Josh Babcock wrote:
OK, here's the file:
http://home.comcast.net/~jrbabcock/superfort/b29-yasim.xml
Some random notes, before I start running it:
The inbord and outboard engines don't match. Your inbord ones are
defined to produce 2200 HP at 1000 RPM (which is *monster* engine),
while your
Arnt Karlsen wrote:
..very good question! Comparing the notes on piston engines and
turboprops, is confusing, is the eng-rpm the prop shaft rpm?
[...]
..we're back to checking the source, to see what Andy meant here. ;o)
Uh, the lines in the README.yasim document read, exactly:
Curtis L. Olson wrote:
1. FlightGear has a property called /velocities/airspeed-kt; does anyone
know if this was originally intended to be VCAS, VIAS, VTAS, or what?
2. The pitot system uses /velocities/airspeed-kt as it's input (and
seems to assume this value is VIAS.)
This value looks like
Curtis L. Olson wrote:
The conversion between VCAS and VIAS is aircraft specific and is often
shown in a table in the POH (and depends on things like flap position.)
So FG can't come up with a nice tidy formula to convert between the two
values. Thus FlightGear leaves everything as VCAS
Josh Babcock wrote:
My problem is that I apparently am genetically incapable of
getting a YASim config to converge.
XML file? Output?
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Curtis L. Olson wrote:
Maybe we need separate options, such as
--cpu-friendly-inaccurate-throttle-with-sleep-hz= and
--frame-rate-accurate-throttle=
Thoughts? I think we need to tread a bit more carefully on this one,
especially since I have a side project that employs this option (well,
I asked:
What is the application that needs extra CPU, and are we sure that
it's not being performance limited in some other way?
Aha!
Drew wrote:
In Windows, adding this code did absolutely nothing to the
processing time...it remains at 99% usage whether I throttle back to
60, 30, or 1 Hz.
Drew wrote:
The program runs great, it's just that FlightGear gets interrupted
easily by other programs, and is jumpy in my particular application.
If you open and close a window, you can see how FlightGear freezes
momentarily.
I don't wonder, though, if that isn't due to locking inside GDI
Drew wrote:
I'm not really interested in how other 3D apps, including games,
work...I have a specific application, and I want to optimize the
code for this purpose, regardless of what the status quo is.
And the proper way to do that optimization is to figure out what the
actual symptom is.
Melchior FRANZ wrote:
Some of the digits after the comma may be stripped. Nasal doesn't
seem to support that.
Indeed, there is no formatted text mechanism in Nasal right now.
Everything is printed to the precision of a full double.
Doing this the right way (say, a printf-like format string) is
Melchior FRANZ wrote:
Unfortunately, I can't avoid the silly double-0. No idea why.
As you pointed out on the IRC channel (which more folks should be on,
it's kinda fun sometimes), this is a Nasal bug. Or two, actually.
The simple bug is that the string - converts to a numerical zero due
to
Curtis L. Olson wrote:
Frederic Bouvier wrote:
There is the property /sim/frame-rate-throttle-hz that could be
used to limit the framerate but the source should be modified
to call a system sleep method ( with a fine resolution, for
example pthread_cond_timedwait ) instead of looping
Frederic Bouvier wrote:
Quoting Andy Ross:
* Hopefully in a CPU-friendly way. I know that older versions of
the NVidia drivers did this by spinning in a polling loop
inside the driver. I'm not sure if this has been fixed or not.
From my experience, the latest non-beta Windows NVidia
Don Oliver wrote:
fgfs --prop:/sim/model/path=Models/my-cessna.wrl
There are no .wrl files in my FlightGear installation, so where do I
find this information?
FlightGear's model loader (part of plib) supports many different file
formats. The best supported is currently AC3D (.ac) format,
Seamus Thomas Carroll wrote:
The fuel levels seem to retrieve correctly.
I then added the following code to set the fuel levels for when the
c172 aircraft starts:
fgSetDouble( /consumables/fuel/tank[0]/level-gal_us, tank1 );
fgSetDouble( /consumables/fuel/tank[1]/level-gal_us, tank2 );
The
Giles Robertson wrote:
Working out gravitational and kinetic energy is trivial; accounting
for energy in the fuel not hard - but I don't think you'll be able
to account for elastic energy stored in the airframe.
It's a pilot's tool, not a design thing. It's designed for glider
pilots to show
Erik Hofman wrote:
Frederic once wrote a plib patch to add multitexturing by someone
thought it was an ancient technology and everything should be done by
shaders in the future. First I don't think we ;live in the future end
secondly I don't think shaders will be fast enough to do _everything_
Ampere K. Hardraade wrote:
At the moment, is antialiasing applied to textures themselves?
Sort of. This is the purpose behind mipmapping and filtering --
avoiding aliasing effects in texture (texel) space.
If so, what will happen if antialiasing is applied to the final
render/output instead?
Jon S. Berndt wrote:
This is good for YASim. However, the Nasal approach won't apply for
other applications which use JSBSim, and JSBSim also needs its own
fuel management for batch runs (standalone operation) outside of
FlightGear.
Well, it's certainly fgfs-specific, although there's really
I found time this afternoon to refresh my memory about how the fuel
stuff works.
The FDM reads these properties to determine the amount of fuel in each
tank. YASim uses this only for computing the inertia tensor and total
aircraft mass, it doesn't care about fuel per se.
Jon S. Berndt wrote:
I haven't been following this thread very closely. Can someone
concisely recap what is wanted, here? It's most likely a very simple
addition for us if it's something we don't now model.
Actually, YASim uses a Nasal-based fuel system that was designed to be
FDM-independent.
Innis Cunningham wrote:
I dont think there is a total fuel onboard or fuel remaining
property. I asked about this a couple of weeks back and got no
reply(I think).
Each tank has its own value, under /consumables/fuel/tank[n] you will
find level-gal_us and level-lbs properties.
I don't think
Christian Mayer wrote:
Manual Massing wrote:
Yes, textures and geometry are paged and decompressed
asynchronously in the background (seperate thread). The engine
supports image compression to save IO (and possibly bus)
bandwith, e.g. JPEG and S3TC compression. The first maybe quite
Frederic Bourvier wrote:
It is still true that JPEG have no alpha channel, so not all
textures could be converted.
Yes. Although the loader could play tricks like storing the
alpha channel in a separate grayscale image. And I believe the
already-mentioned jpeg2000 format does support
201 - 300 of 1282 matches
Mail list logo
