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.
+ The wing stall angle was weird, as mentioned earlier. Values
greater than 45° don't have much physical meaning. I changed it to
25, which should be closer to a realistic value.
+ The lift="1.1" on the elevator flaps wasn't quite enough to get the
aircraft into the approach AoA. I changed it to 1.2, and it works.
It's still not as responsive as I'd have expected (then again, this
is a big aircraft...).
+ The hstab effectiveness was negative. This is wrong, as this is a
multiplier for all force generated by the surface. A surface with a
negative value will produce thrust instead of drag. :) Maybe this
was needed because the elevator was rigged backwards somewhere else?
I changed it
+ The wing and hstab had very small stall widths (very sharp stalls).
Low aspect wings should have gentle stalls, not sharp ones. I
changed it to 15 as a guess.
+ There's no rudder input mapped. This can be done with a "split"
input to the tails in exactly the same way that the aireron works on
the wing. It will simply add to the elevator input. V-tail
Bonanzas will require the same treatment.
Here's a 'beta' version of a YF23. The model is virtually finished - I think
I just need to split the wheel well and cockpit linings to clear up the
smoothing artifacts, and add a couple of other little details.
The texturing is rudimentary, all I've done is to map simple colour blocks to
everything. There's a definite problem with the rear cockpit canopy
transparency - anything viewed through it, except for the pilot stuff and the
rear canopy surround is invisible. The weird thing is that everything is ok
if you angle the view to look through the front canopy - this is easier to do
with the rear canopy open (parking brake). The front and rear canopy
glasses, and hud glass are the only transparent objects, and they're all at
the bottom of the hierarchy.
I'd found that if I placed objects below any transparent objects in the
hierarchy, they'd become invisible when viewed through the transparent object
- any objects above the transparent objects would be visible. This seems to
have worked for the front canopy and hud (the pilot and seat is visible from
the front view through both the front canopy and the hud glass) but not the
rear canopy.
Time for a bit more experimentation, methinks. That, or find TFM to R:)
I've finally got the u/c door/gear timing working, and I'm also pleased with
the suspension animation. I couldn't resist linking the pilot's head to the
rudder - it's not as though it does anything, except on the ground (where it
also operates the nose wheel steering.
It all still needs some tuning and finishing - I've modelled the front wing
flaps/slats/what-ever-they-ares and I've put some slats in the fdm, but I
haven't 'used' them yet. The suspension is still too spongey and it heels
over quite badly on take-off in cross-winds (shows off the independent main
suspension nicely though), and more work on the fdm is needed too.
