These patches add a clock instrument, which allows to model failure ("serviceable") and to adjust the time independently of the system time (defaults to GMT). The main incentive is to make the p51d clock work and adjustable via the knob.
o Offers a time string ("12:03:15") for the LCD or for LED
clocks, or an empty string in case of failure/power off. The
instrument assumes that digital clocks are battery buffered,
so they will be updated even if there's nothing on the display.
o Offers the number of seconds since midnight for analog
clocks, like in the p51d. This number is not increased
if !serviceable. So the clock will stand still and continue
where it stopped when it's serviceable again.
I did not consider voltage yet, because the Mustang's clock will need a lot more current than the LCD clock. The instrument is updated 4 times per second but returns immediately if neither time nor offset changed. The function getGMTString() in fg_props.cxx could be removed after applying these patches.
I'm not sure if I connected adf and dme to the correct bus, but it's time that c310s have them working. There was a temporary workaround in c310-ifr-set.xml, but not for the c310-3d (= c310u3a-3d), the plain c310 and eventually others.
Here's an update to the yf23. I've added a couple of small details to the
model and played with the textures a bit:) Still no response from the chap
at NASA about sticking their logos on it yet.
I've also been fiddling with the fdm. It had been bugging me that I couldn't
find any sign of air/speed brakes but just recently I found that braking is
done by moving the ailerons up and the flaps down, in opposition to each
other, which I thought was pretty neat really.
This was actually pretty easy to mimic - although there are no spoiler
surfaces defined in the YASim wing entry I was still able to map the spoiler
control input to the ailerons and flaps, and once I'd got the directions
right it seems to work - hit the spoilers and the ailerons move up, the flaps
drop and the energy worm shows that I'm losing speed.
The downside is that the flaps and the ailerons have to have similar lift and
drag characteristics, to balance each each other, and this means that it ends
up with the flaps not giving much lift and the brakes not having much affect
at low speeds. If I could change the deflection rates then I could balance
them that way (and improve the rudder control too) - as it is, the deflection
for the flaps and ailerons is the same, just in opposite directions. This
sounds like a job for interpolation tables but I haven't tried them yet and I
don't know if I can use them in this way in YASim.
The opposing flap/aileron techique is also used for manuevering e.g. by using
it on just one side but I haven't tried to incorporate that yet;)
Landing it is proving to be tricky - it gets down smoothly to about 20ft then
what I presume is ground effect kicks in and upsets the trim. The only
answer appears to be to force the nose down at this point. What's more, it
needs to be held down untill you trim the elevator out otherwise it'll
happily roll along on it's main gear, with it's nose in the air:) There's
definitely not enough drag either.
For the base package I have some more files for the JSBSim airplanes. All of the main configuration files now have a rudder aerosurface scale component, so that rudders can be animated. This was not on my earlier models. I also put fuel in the tanks, even though this seems not to work yet.
Also attached are the -set files for all the airplanes. They now all specify a fuel load.
I've been messing with the yf23 some more. I think it flies a bit better now
and has more reasonable auto-pilot take-off characteristics - just apply full
power and go, and it doesn't go into such a steep climb.
Out of curiosity, I've also taken the rudder control input and linked it to
the stabilators/elevators and ailerons. Now, with some slick joystick
manipulation it's possible to fly it at about 30 deg off-axis in more or less
level flight (actually, with full 'rudder' input, it looks nearer to 40 deg
to me and you end up tracing a very long curve).
If no rudder input is used it flies 'normally'.
I'd like to be able to 'tune' it so that it's more stable while transitioning
but I'm not sure if that's going to be possible. It's also high-lighted some
problems I'm having with my Sidewinder joystick - when I use the rudder
control, the engine No.2 throttle jumps to 50% unless auto-throttle is
engaged (this also happens with the b52 too), and there seems to be some
interaction between the different axis if all three (roll, pitch and rudder)
are changed at the same time - difficult to be sure on that one though.
I'll probably un-map the throttle control from the joystick as I tend to use
the keyboard for engine control anyway, especially for landing.
Here's a quick update to the yf23 fdm and auto-pilot settings. It flies and
takes-off reasonably well - still haven't tried landing it yet;) It can
still be a bit wobbly at times though and It's not very good at terrain
following either.
Taking off on auto-pilot is quite fun. Set full flaps and CTRL-a (assuming
you're near sea level), hit F6 to make it go straight and apply power - about
50% until it rotates then apply full power. Retract the gear as soon as it
gets off the ground and by the time you#ve done that, retract the flaps.
Quite entertaining from a tower view:)
It's not really an ideal a/c to model but apart from the aesthetics, which
appeal to me, I was curious about not having a rudder.
There's a new texture sheet too but it only makes the a/c a paler shade of
grey.
I've attached an update for the yf23 and I think I've included all the right
files - the model is unchanged (I think I'll eventually paint it in an
imaginary NASA scheme, perhaps a bit like the HIDEC F-15, until I can get
some newer pictures and see what they've done with it) so I've not included
it again.
The fdm still needs quite a bit of work - it can be a bit twitchy and wobbly
at times, and the auto-pilot roll-out and smooth need tightening up, but it's
flyable. Haven't tried landing it yet though;)
- HSI GS needles shouldn't disappear when they hit their limits, only when
there is no GS signal.
- Make vac/amp gauge driven by new minimalistic amp model.
- Update digital clock face color to look more "LCD-ish" based on a real
C172-S cockpit photo.
- Add an OAT gauge to the old C172 2d panel.
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.
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.
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.
support under /radios/.
The display now goes dark when the switch is turned off.
The switch position is now handled entirely within the XML -- the C++
code is generic, so that other DME receiver types can also be
modelled.
Here're some updates for some of the instruments, the TSR2 and the B52.
The instruments are just parameterised/non-specific versions of the engine
and fuel gauges. The old gauges will still be used by the a10s and the sea
hawks until I get them done.
There're a couple of tweaks to the tsr2 yasim config and amendments to the
model file to change the angle at which the airbrakes operate, correct the
direction that the nose gear retracts/extends and to rotate the main-gear
carts during retraction/extention. There're also new panels, using the new
instruments.
The b52 yasim config has some big changes due to finding some more info i.e.
wing incidence of 6 degrees, fuel capacities and aileron changes (removed
from G & H versions!). It's now based on an 'F' model and I've put some
comments in the yasim config about it. The b52-readme.txt includes a
suggested method on getting airborne;). I've included an amended model -
B52-F.3ds, which is the default in the new model file, and a couple of panels.
I'm quite pleased with the b52 - the take-offs resemble the photographs I've
seen and I think I've got reasonable values where I've had to guess at stuff,
but the results from the yasim solver look as through the model is
approaching the limits of acceptability for yasim. By this I mean that the
model is probably a bit dodgy, not that the yasim solver is limited.
