currently exist carried over. (Sorry for the previous screw up David, I
found a logic error in my script that prevented the carry over from not
working correctly.)
here's an update to the b52 - it's just some relatively minor changes to the
fdm and panels.
I've been trying to improve the take-off and landing characteristics, or at
least get them to fit the pictures and film I've seen.
The best way to take off is by using the autopilot - at sea level just extend
the flaps, punch in the altitude hold on the autopilot (and heading if you're
lazy), and apply full power. It'll also take of with the default the default
elevator trim of -0.07 but it 'staircases' a little bit - the auto pilot
smooths that out.
I've included some notes and observations about taking-off and landing in the
readme.
While I wouldn't claim any sort of accuracy for it, I hope it manages to get
some of the characteristics right.
much what i've seen p-51d's do. Be careful of spins.
Added vstab incidence (real ones have it) thus improving takeoff behavior.
Reduced turbo-mul to what it probably should be.
Returned wing camber to Andy's estimate.
Increased flap drag. And tried making adjustments to get the thing to not
glide so impossibly far.
Corrected empty + pilot aircraft mass to 7190.
Upped "cruise speed" to maximum operational speed of 380 knots.
Reduced prop pitch at cruise to 0.8 (3000 rpm is only for takeoff).
Changed camber to 0.01 (found reference that said 1%)
Decreased tail surface effectiveness slightly just to get better numbers.
Changed turbo-mult to 2.5 and wastegate-mp to 30
Changes:
Fit the solver to the known stall speed instead of an abstract
approach configuration. That is, specify stall AoA and speed as
"approach" values. At approach weight (20% fuel) I can now just
barely hold the aircraft in the air without losing it at 87 kias.
Note that the IAS guage seems to have a slight calibration error, it
was reading something that looked more like 95 knots; I got the real
value out of the property browser.
Change the sign of the incidence value for the wing. It specifies a
rotation about the axis pointing out the left wing, so positive values
are "nose down".
Increase the "effectiveness" of the tail surfaces quite a bit.
Smaller surfaces do actually need higher values. YASim scales surface
force coefficients with their areas, which is correct within a single
wing. But between wing-like devides, generated forces kinda/sorta
scale linearly with their spans. This is particularly important for
tail draggers, since YASim's lack of prop wash modelling needs to be
offset by extra elevator authority.
Add a camber value to the wing. Most wing airfoils are asymmetric,
and produce non-zero lift at zero AoA. I picked 0.1 (10% of stall
lift at zero alpha) as a reasonable guess. If someone has airfoil
data for the Mustang we could look this up exactly. This was the
biggest change, which allows the cruise AoA to be much lower than
approach or stall.
Reduced the compression value for the tail wheel to 20cm. These
things are very stiff; they "compress" only as much as the tires do.
Even 0.2 is too much motion, but the numerics tend to go wacky when
you give them very high spring coefficients. This helped the ground
handling a little bit.
Removed the extra damping from the main gear. My impression of tail
draggers is that they tend to have "squishy" main gear. Again, this
(subjectively) seemed to improve ground handling to me. I also tried
reducing the spring constants to 0.5, but that ended up being too
squishy -- you could see the ship (stopped on the ground) bank to the
left by 2-3° when you pushed the throttle forward.
Ground handling is still pretty difficult; I get the best results by
holding the tail down until 90 knots or so and then very gently
lowering the stick. The aircraft bobs once or twice and then lifts
off. I don't think this is proper procedure, though.
Andy
Changes:
Fit the solver to the known stall speed instead of an abstract
approach configuration. That is, specify stall AoA and speed as
"approach" values. At approach weight (20% fuel) I can now just
barely hold the aircraft in the air without losing it at 87 kias.
Note that the IAS guage seems to have a slight calibration error, it
was reading something that looked more like 95 knots; I got the real
value out of the property browser.
Change the sign of the incidence value for the wing. It specifies a
rotation about the axis pointing out the left wing, so positive values
are "nose down".
Increase the "effectiveness" of the tail surfaces quite a bit.
Smaller surfaces do actually need higher values. YASim scales surface
force coefficients with their areas, which is correct within a single
wing. But between wing-like devides, generated forces kinda/sorta
scale linearly with their spans. This is particularly important for
tail draggers, since YASim's lack of prop wash modelling needs to be
offset by extra elevator authority.
Add a camber value to the wing. Most wing airfoils are asymmetric,
and produce non-zero lift at zero AoA. I picked 0.1 (10% of stall
lift at zero alpha) as a reasonable guess. If someone has airfoil
data for the Mustang we could look this up exactly. This was the
biggest change, which allows the cruise AoA to be much lower than
approach or stall.
Reduced the compression value for the tail wheel to 20cm. These
things are very stiff; they "compress" only as much as the tires do.
Even 0.2 is too much motion, but the numerics tend to go wacky when
you give them very high spring coefficients. This helped the ground
handling a little bit.
Removed the extra damping from the main gear. My impression of tail
draggers is that they tend to have "squishy" main gear. Again, this
(subjectively) seemed to improve ground handling to me. I also tried
reducing the spring constants to 0.5, but that ended up being too
squishy -- you could see the ship (stopped on the ground) bank to the
left by 2-3° when you pushed the throttle forward.
Ground handling is still pretty difficult; I get the best results by
holding the tail down until 90 knots or so and then very gently
lowering the stick. The aircraft bobs once or twice and then lifts
off. I don't think this is proper procedure, though.
Andy
Now I translate into Polish the locale conected file.
There are some (4) words that wasn't translated I will translate them
when I will speak with friends how to translate them corectly.
I made the full translation of default "en" file (not short as the
German translation).
I send you 3 files:
1) locale.xml -added Polish variable
2) strings-pl.xml -translation in ISO8859-2 encoding (default Polish
encoding in Linux, UNIXs, Internet
3) strings-pl-win.xml -translation in Windows-1250 encoding ( encoding
in Windows only)
I give the same licence for the translation as the all FGFS project has-
GNU GPL.
Please add that translation to the project, and new created releases.
I've done a new Sea Hawk. Well, the model and the fdm aren't new, just
slightly modified, but I've incorporated some more animation stuff and tried
a different way of texturing it.
The animation additions are things I worked out for the YF23 (still can't get
it to fly again) - mostly u/c related stuff.
This actual aircraft (WV908) is in the Royal Navy Historical Flight and so is
kept unusally clean;) In the photographs I looked at, hardly any fuseage
panel lines were visible so I've not tried to include any. Instead of the
normal fuselage side views and wing plan textures I've just used fairly
high-res detail 'patches' for the markings, applied to 'carrier' objects.
This is much more like the way I'd do things if I was working on a picture in
my 3d software - there I'd apply multiple textures to an object, as required,
using scope and priority settings to get what I want. With .ac format models
you can only apply a single texture to an object - hence the need for the
carrier objects. These are sections of the underlying 'real' object that
have been moved out/away from from the original object surface so that they
cover them.
The pros are 1) the resolution of the details is much higher - have a close
look at the Ace of Diamonds art on the nose and on the bit that sticks out of
the front of the tail-fin (I don't know the proper name for this), and 2)
less texture space is needed.
The most obvious con is that there's more potential for z-buffer problems. I
notice that whilst on the ground (in chase view), there appears to be
z-buffer fighting for the texture patches but once the a/c has taken off and
has got to about 200ft or so, it clears up. I've no idea why this should
happen as I'm not changing any of the view settings.
There are a few things I still need to figure out in this respect - I think
there's an issue with graduated textures - they seem to get reduced to 16bpp
and show a lot of banding that's absent on the texture and the model appears
inverted from tower views, at least in 16bpp, but ok from the chase view, and
stuff like that.
I said that the model and fdm aren't new but they have been modified a bit.
I've only reduced the approach aoa in the fdm but the model, whilst basically
the same, has had quite a few changes to accomodate the new u/c and texture
patches. It also got into FG by a slightly different route - I found that
AC3D would support polys with > 3 sides and after looking at and comparing
.ac and .obj file formats (I can export from RS3D in .obj format) I wrote a C
prog to convert .obj format files into .ac format files. It's a nasty bit of
hackery that even uses a temporary workfile (LOL), and it will only work with
the simplest of .obj files (e.g. no vertice normal or texture info) but it
allows me to export the model geometry in .obj format, convert it, and load
it straight into AC3D without turning everything into triangles or flipping
face normals.
The funny thing is that objects that consist of just a single rectangle (e.g.
an aileron or flap surface) are not recognised by FG and they have to be
split into two triangles, and once the model's loaded up into FG I can see
from some of the rendering artifacts that it's all still reduced to triangles
prior to display anyway. Still, it saves me from having to do a lot of face
flipping.
Really, the texturing method is experimental and I hope I get some feed-back
on it regarding display and performance issues. Ultimately, I'd like to try
to reduce the texture size down from 512x512 to 256x256 - nearly half of the
current texture 'space' is unused.
