Changes made 19/12/2004
Panel re-oriented
3d Compass shows through windows.
Wing-tips slightly altered.
Changes made 18/12/2004
Prop spinner shortened and widened
Nose area slightly remodelled to fit silouette
Nose texture altered to place lower intake correctly
Nose wheel reduced in size.
Nose leg Oleo guide added (does not rotate - is this correct with real ac?)
Nose wheel Axle added.
Nose wheel fixed to rotate about it's shaft axis.
Windscreen / panel mesh changed so that panel no longer protrudes thru dash
Panel instruments moved to represent the geometries of the real cockpit.
Pilot / Copilot Yokes moved inboard to represent the geometries of the real cockpit.
Alpha layer added to interior texture to prevent panel showing through seats / yokes.
Interior texture duplicated and mapped to panel only to allow panel to show.
Front seats moved slightly inboard.
Landing light pair added to port wing texture.
Alpah layer added to wing texture to prevent panel showing through.
Texture remapped to Flaps (no shows ribs again).
Wing strut outer joins brought inboard to point of wing taper to match real aircraft geometries.
Wing struts thinned in front profile and thickened in side profile.
VHF aerials moved aft to their usual position.
Maingear legs altered so they now join with the fusealage (previously, 20cm gap)
Rear window altered slightly to match silouette.
Rear (white) Navigation Light made to translate with the rudder.
Not yet done: independant landing and taxi lights on port wing
I've finished the emigration of the radiostack, and I've also removed it
completely. It turned out that the comm radio is completely implemented in
the ATC subsystem. I've changed the affected ATC files to point
to /instrumentation/com, but I guess that the maintainer of the ATC code
should decide wether to make it configureable, and how.
I also had to change some files in Network and Main. The changes in network
should be obvious, but the changes in Main were a bit suspect. The files
included radiostack.hxx, but they weren't directly depending on
radiostack-hxx. They were depending on other files that were included by
radiostack.hxx. I got it to compile, but I'm not sure if I included the
correct directly depending file.
For the data directory I changed every occurrence of /radios/
with /instrumentation/ with this simple one-liner that I found on the net:
find -name '*.xml' -type f | xargs perl -pi -e
's/\/radios\//\/instrumentation\//g'
Instead of me sending all the files that got changed by this I suggest that
you execute the one-liner yourself. Of course I can not guarantee that this
will work perfectly, but I considered hand editing to be not an option (I'm
lazy). I don't want to test every aircraft to see if everything still works,
I think it's better to wait and see if anyone complaints about broken nav
radios/instruments.
I've made an encoder and a transponder. The transponder gets C-Mode altitude
information from the encoder. These two might not be very usefull right now,
but I think they might come in handy when the ATC network gets going.
Here are some updates to the KAP140 autopilot in the default c172. It now uses
ailerons and elevator instead of aileron-trim and elevator-trim. I've started
to "upgrade" it to the "two axis altitude preselect" version. Vertical speed
select rounds to nearest 100 fpm.
I've also modified the c172 electrical configuration to turn on the gps
instrument.
Perhaps the most important change is that the nasal script for the KAP140 has
moved from data/Nasal to the c172p aircraft subdir. So it is important that
you delete data/Nasal/kap140.nas. Having the kap140.nas script as a global
script was not a good solution. Now it is aircraft specific, and thus
included in the c172p-set.xml file. Ideally I would like it to be instrument
specific, so that it would be included whenever the KAP140*.xml instruments
where included on the panel.
Instrumentation and systems are now configureable from xml files. The two
generic configurations generic-systems.xml and generic-instrumentation.xml
configures the systems and instrumentation as it was hardcoded. You can
override the generic configurations in a similar way as you override the
autopilot configuration.
All necessary elements for an ADF gauge had been migrated from
Cockpit/kr_87.cxx to Instrumentation/adf.cxx. Migrating the sound
related elements was apparently planned, but not done yet. This
intermediate state broke the ident morse sound: it couldn't get
turned off and it always indicated "SF", regardless of the tuned-in
frequency. The following patches continue the migration:
adf-radio.diff => Base/Aircraft/Instruments/adf-radio.xml:
---------------------------------------------------------------
* sets maximum volume to 1 (rather than 2); Not only is 1
loud enough (and 2 unpleasantly noisy), it also prevents
the knob from being turned to non-existant positions. :-)
* fixes wrong use of /instrumentation/adf/ident
* the voice/ident selector(?) remains unchanged, but as it's
not switched to "IDENT", there'll be no ident sound by default
this is consistent with other sounds and DME.
radiostack.diff => src/Cockpit/radiostack.[ch]xx:
---------------------------------------------------------------
* comment out use of FGKR_87 class. kr_87.[ch]xx is now no
longer used. kr-87adf.xml would no longer work, either, but
isn't used anywhere, anyway. Future adf radios have to use
the adf instrument, using xml/Nasal for specific hardware
implementation details.
adf.diff => src/Instrumentation/adf.[ch]xx:
---------------------------------------------------------------
* adds ident morse sound capability using two new input
properties:
- /instrumentation/adf/volume-norm (double)
- /instrumentation/adf/ident-audible (bool)
Here's some new AI stuff.
1) AI objects must now be defined in a scenario file, not in preferences.xml
or a *-set file. (Of course this doesn't prevent objects from being created
dynamically, as with Durk's traffic manager).
2) A new demo_scenario file is attached. It creates 3 aircraft, a sailboat,
and a thunderstorm.
3) Objects without flightplans live forever.
4) FGAIShip::ProcessFlightplan() is not yet implemented.
5) preferences.xml should now define only <enabled> and <scenario>
Here is the KAP140 Two Axis Autopilot update.
I think it's fairly complete now, all the modes are working. I tested the
localizer and glideslope hold and it was pretty stable all the way down to
the middle marker.
In the pilot guide for backcourse hold (REV) mode it says to reset the heading
bug to the _front course_. I haven't figured out how to implement this so for
the time beeing one should reset the heading bug to the _backcourse_. Apart
from this the panel should operate identical to the way the pilot guide
describes.
Here is the KAP140 Two Axis Autopilot.
Aircraft/Instruments/KAP140TwoAxis.xml
Is of course the instrument config file.
Aircraft/Instruments/Textures/KAP140.rgb
The texture.
Nasal/kap140.nas
Most of the work is done here. Without Nasal I don't see how I could implement
the NAV-ARM modes and the flashing annunciators.
Aircraft/c172p/Systems/KAP140.xml
The autopilot PID controllers configuration file. Maybe this file should be in
a more accessible directory and not hidden deep inside c172p!?
I've also attached the changes to the default C172 to include this autopilot
in the 3d-cockpit panel and the 2d vfr panel. Or at least I hope that I've
managed to include all that is needed.
Add clickable range selection for the radar and wxradar. Right
now it is clickable only between 20 and 40 mile ranges, which should work for
most uses.
OV10-jsbsim-set.xml has many changes. It creates a thunderstorm over
woodside VOR. It removes the lowest cloud layer so that the storm can be
seen. It sets the surface wind speed to zero, which may help stop the
"drifting left" complaints. It sets the radar range to 40 miles.
The weather radar instrument is corrected.
The radar instrument uses the above three items, and applies a scale factor to
the x-shift and y-shift in order to match the instrument's scale. Changing
the display scale can be done entirely in the XML code for the instrument.
Right now it's set up only to display a 40 mile scale.
The radar is an AWACS view, which is not very realistic, but it is useful and
demonstrates the technology. With just a little more work I can get a HUD
marker. All I need to do there is make a bank angle adjustment to the
current values.
This works great with one target. For two or more targets the radar
instrument will have to know the numbering of the aircraft model properties.
This isn't implemented yet.
David Culp:
I couldn't stop. Here's a better radar instrument. It has:
1) range select knob 20 and 40 nm (not clickable.. yet)
2) target altitude readout at lower right
3) target disappears when range exceeds 43 nm
4) range ring values now are read from instrumentation/radar/range
5) instrumentation/radar/range is preset in the *-set.xml file to 40 nm
The next step would be a clickable range selection. The problem here is that
the instrument currently displays the "blip" only if the target's range is
less then 43 nm. If the range scale is decreased to 20 nm, then the "blip"
will show past the edges of the instrument. I might need to make another
instrument for the 20 nm scale to make that work.
tasks that should be purely proportional. So I added support for my old
ultra-simplistic PI controller. This does wonders for stage #1 of the
altitude and AGL hold.
controls in the cockpit vs. which wheels they apply to. FlightGear now
sets /controls/gear/brake-left, /controls/gear/brake-right, and
/controls/gear/brake-parking. It should be up to the FDM to sort out
which wheels under which circumstances are affected by these controls
and ultimately what happens to the physical motion of the aircraft.
I added some more hotspots to Davids c172p since he already had done all the animation. Also I tried making the throttle and mixture knobs into hotspots even when they are moving adding extra hotspots for them. Also you can click on the trim wheel to trim now.
I added a directory for the labels for the white toggle switches, but there is probably better way to do the labels then I came up with. There is a short readme file which gives the path for the new directory.
I've added reheat to the engines to simulate water injection and then tweaked
it so that it's just about possible to take off with the full fuel load/ferry
configuration (a little under the mtow - 420,000lbs vs 450,000lbs).
It's interesting to note that the normal combat tow for the F model was
291,570lbs - equivilent to a fuel load of about 0.46 (this would actually
leave you with more fuel than in real life because some of that weight would
be the weapons load but here it's fuel)
Anyway, I've added all this info to the readme and explained some of the
reasoning behind the fdm there.
It still doesn't reach the correct altitudes, and certainly not with a full
fuel load, but it starts getting into the right ball park at combat tow.
I've also replaced the transparent instruments on the mini panel with some
text/digital ones. I wanted more accurate numbers when I was monitoring the
effects of fdm changes and the dials just didn't give the detail. They
aren't perfect and be difficult to see against certain backgrounds and in
certain lighting conditions but what the hey - nearly everything I do is a
bit of an experiment;)
Something I've noticed is that since I've started identifying flight surfaces
and gear components individually I've noticed some problems with the flaps
and gear in replay. I address the left and right flaps independently so they
have left&right-flap-pos-norms and don't get controlled by the replay
mechanism which must refer to the single flap-pos-norm. There's a similar
thing with the gear - I have to identify them individually so I can animate
them properly so on the b52 there're six gear elements but only the first
three are actioned in replay.
Personally, I think that the only way around this will be to provide
control-overrides for all these items, much like there're the AP control
overrides for throttle etc.
The base a10 yasim config wasn't working because of the control structure
changes so I've fixed that. The other yasim configs are also included
because I forgot to omit them from the archive but they're not updated or
changed.
All the a10 stuff needs badly re-doing though and it's a bit of a mess - the
yasim configs are all similar but I don't know which ones had Andy Ross's
mods. I've also got to either forget the weapon load version or get it
working with weight entries so that the rest of the configs can be
indentical.
folder. This has meant duplicating most of the instruments it uses but it
should be easier to maintain and once I've worked through all the other a/c
you'll be able to remove a lot of the cruft I'm responsible for in the
generic instrument folders.
The only files that now don't reside in the yf23 folder are the 'set' file and
the yasim config.
The stuff in this archive should replace the entire existing yf23 folder and
the two 'set' and yasim files (unless I've screwed up somewhere;)
There are some small changes to the fdm.
I also had this rather silly idea, so I had to give it a go;) Have a look at
the ground below the a/c.
It doesn't track the Sun, of course, so it stays directly below the a/c. It
just uses a couple of rotations to keep it flat, and a translation to keep it
on the ground. It seemed strange curious that I had to use a translation
factor of 0.3 instead 1.0 to keep it in the right place.
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.
OK -- thanks. I have now fixed up all the other XML files in the base
package that use "max" and "wrap". Those affected are all in
Aircraft/Instruments/. In these files I have also corrected the
indentation in some places, and corrected the frequency controls in
nav3.xml (which does not seem to be in use), and corrected a few obvious
hotspot position bugs. Where the radios used wrapping to toggle the
ident button between 0 and 1, I have changed this to use
"property-toggle" instead.
There's now another a10 variant - a ferry load configuration - no weapons but
3 x 600 us gal external tanks. This seems to be the heaviest confguration
for an a10. I also found a performance graph for the a10 in clean
configuration and it showed max speeds of 275 knots at 45000 ft and 398 knots
at 1200 ft. As things seem to get a bit squiffy above 35000 ft, in my
experience, I used the 1200 ft figure. This is pretty close the the figure
that Andy Ross found (380 knots at 0 ft) and I've also tried to incorporate
his mods into the new configs, with a better balanced wing/hstab settings.
After getting a good clean config, I added the extra masses/fuel
tanks/fueselages but didn't change any of the rest of the config, and it
still seems to work properly. The external tanks were done as fuel tank
entries, with corresponding fuselage entries, whereas I'm not sure how to
handle the 'weight' entries in yasim yet so the weapon load is still done
with an increased total mass and ballast entries.
There'll be some stuff in the archives that haven't changed i.e. the cl & wl
a10 and seahawk models, but until I get using cvs for my own bits and pieces
it was easier to do the whole directory. I hope this isn't a problem.
Finally, I've set up some panels, based on the c310 vfr and mini panels. The
vfr panels have a lot of additional instruments on them but impose quite a
high frame-rate hit on my system. The mini panels also have some additional
instruments but seem to work without noticable penalty here. I've set these
panels as the defaults for these aircraft but I'm not sure it's a good idea
to have the vfr panels by default due to the performance hit. Using them as
default will should give some feedback though;)
To go with the new panels are a number of rough and ready instruments I
hacked, mostly out of one of the rpm gauges, but I've adapted the throttle
quadrent (jet-throttle-quadrant) to funstion for throttle, flaps and reheat.
All the gauge faces were based on an existing ffgfs instrument texture, so
there's no problem with copyright there. All the other bits that I've done
may be distributed under the same conditions as fgfs.
The only real changes to the seahawk stuff were to add the panels, but I
found that Sea Hawks have three fuel tanks, with a 'saddle tank' over the
engine feeding fuel into the second/rear tank, so the yasim config's changed.
Here are some more updates, and bits and pieces.
The tsr2 is mostly a re-write, with more reasonable figures for the wing and
hstab. I've also tried to reduce the poly count on the model whilst adding
the airbrakes and canopies.
Finally, I've set up some panels, based on the c310 vfr and mini panels. The
vfr panels have a lot of additional instruments on them but impose quite a
high frame-rate hit on my system. The mini panels also have some additional
instruments but seem to work without noticable penalty here. I've set these
panels as the defaults for these aircraft but I'm not sure it's a good idea
to have the vfr panels by default due to the performance hit. Using them as
default will should give some feedback though;)
To go with the new panels are a number of rough and ready instruments I
hacked, mostly out of one of the rpm gauges, but I've adapted the throttle
quadrent (jet-throttle-quadrant) to funstion for throttle, flaps and reheat.
All the gauge faces were based on an existing ffgfs instrument texture, so
there's no problem with copyright there. All the other bits that I've done
may be distributed under the same conditions as fgfs.
[ In support of the TSR2, SeaHawk and A-10 ]
I've set up some panels, based on the c310 vfr and mini panels. The
vfr panels have a lot of additional instruments on them but impose quite a
high frame-rate hit on my system. The mini panels also have some additional
instruments but seem to work without noticable penalty here. I've set these
panels as the defaults for these aircraft but I'm not sure it's a good idea
to have the vfr panels by default due to the performance hit. Using them as
default will should give some feedback though;)
To go with the new panels are a number of rough and ready instruments I
hacked, mostly out of one of the rpm gauges, but I've adapted the throttle
quadrent (jet-throttle-quadrant) to funstion for throttle, flaps and reheat.
All the gauge faces were based on an existing ffgfs instrument texture, so
there's no problem with copyright there. All the other bits that I've done
may be distributed under the same conditions as fgfs.
The other stuff isn't really an update but something I did for a bit of a
laugh. The idea ocurred to me after animating the folding wings on the
seahawk and seeing that the aileron and flap axis still worked...
Here're a couple of updates. Well, one's an update - the tsr2 and this now
has reasonable wing and hstab values. The roll rate was very high and I
figured that as it was going to be a hack anyway, due to the all moving
tailplanes, I just made them very ineffective and linked them top the
tailplanes in the model file. I think I may have over factored them a bit
too much but it's interesting watch them in chase view. If the autopilot
roll-out-deg is dropped to about two it'll start oscillating, and from behind
it looks like it's paddling:)
you simply click with the left mouse button to advance to 'both';
after that, if you click again, the start engages until you let go of
the mouse button, at which point the knob snaps back to 'both'.
Here's a B52-H that I've done and it can be distributed under the same
conditions etc. as fgfs. It seems to fly ok but I'm sure it could do with a
bit of adjustment - perhaps Andy R. will have a look and give it a few tweaks.
It wouldn't need too much work to convert it to an -A model (different
engines, taller fin etc.) and then it could be teamed up with the X15 :)
I still can't get textures on the models but it occurred to me that if
someone could apply blank texture maps to the models I could then fill in the
blanks, as it were.
I also noticed that there don't appear to be models included for the F-104,
F-15 & F-16 and I think I could probably do some and animate them for fgfs if
they'd be useful.
Re the A10 - Andy said he'd had a look at it and made a few changes to fix a
few things that I'd done incorrectly and asked if I wanted to keep tinkering
with it or should he roll his changes into the fgfs cvs? I said to him that
I'd be happy to go with his changes as they'll be more realistic/accurate than
the stuff I've done.
I've certainly no problem with anyone doing anything with any of the stuff
I've done, so long as it's an improvement :)
I've taken the liberty of attaching a .tar.gz file containing a .3ds model of
a BAC-TSR2, a yasim config file based on the correct figures (where I could
find them) and the -set.xml and model.xml files to fly it.
I'm primarily a 3d'er and originally did the TSR2 for a picture I'm working
on but when I got fgfs running (Debian Linux) I couldn't resist loading it in
and trying to get it to fly. The model was created in Realsoft3D and
exported as .3ds.
I've been able to tag the various sub-objects, to animate them but the export
process appears to 'flatten' any object hierarchy I set up and I'm guessing
this is necessary for sequential animations - I couldn't set up the correct
sequential rotations to properly bring the main u/c in. Also, in real life,
there are several other u/c doors that should open and close in sequence to
get the gear in and apparently the sequence was quite complex.
On the ground though, it is as shown (so I didn't need to model the extra
doors for my picture anyway;)
It could do with some airbrakes too, both for the model and for the fdm. As
with the extra u/c doors, I didn't need them for the picture and they haven't
been modelled.
As well as not being able to preserve object hierarchies when I export from
Realsoft3D's native object format to .3ds, I'm not able to preserve textures
or colour-mapping either, so the aircraft appears all white.
Hopefully, someone might like to add the extra doors and airbrakes, which
shouldn't be too difficult, and put some texturing on it - mostly white
anyway, for the prototypes, or a contemporary RAF scheme if someone wants to
pretend that it entered service.
The yasim fdm model, as said, cannot be regarded as accurate. However, while
it is based on the specs for the real aircraft, where I could find them, the
measurments are probably only accurate to about 1 metre. That's assuming I
was measuring the right things in the first place;) Other bits that I wasn't
sure about i.e. flaps, ailerons etc. have been hacked out of the a4 or the
747.
It could do with some 'refinment' by people who know what they're doing, but
it seems to fly about right, or rather, as I'd imagine:) (me want a
forward-looking ski-toe terrain avoidance radar:)
Anyway, I'm happy for the whole lot to be released under the same licence and
conditions as the rest of the fgfs stuff, either as a part of fgfs or by
anyone else who will also follow those same licence and condition terms.
I've also got a reasonable yasim b52 flying but no moveable bits on the model
yet, a vulcan with a similar simple 3d model using a grossly hacked c310
jbsim fdm (right numbers where I could find them but powered by a couple of
XLRs) and a Saunders-Roe SR45 Princess flying boat model and yasim fdm (can't
get it into the air with propellors but substituting equivilent jets (2.5x
factor) got it flying. I've started on a EE/BAC Lighting FMk6 model but I'll
probably be doing a Fairchild A-10 and an Antonov An-225 first.
I figure this is the best way I can contribute to the fgfs project, and l'd
like to be able to offer something.
Make the plane much sloppier at high alpha and/or with the flaps
extended. In slow flight, there's much more lateral instability now,
and adverse yaw is more obvious at the start of a turn using only
ailerons.
activated with the mouse, but they do respond to the following
properties:
/controls/lights/taxi
/controls/lights/landing
/controls/pitot-heat
/controls/lights/navigation
/controls/lights/beacon
/controls/lights/strobes
- yokes
- carb heat
- throttle
- mixture
- flap switch
- trim wheel
Moved the pilot seat back slightly.
Use LOD more aggressively, so that all the interior detail is skipped
when the viewer is distant.
the root PropertyNode element. For example,
--aircraft=c172
is now an alias for
--aircraft=c172r
which is an alias for
--aircraft=c172r-jsbsim
All JSBSim *-set.xml files have been renamed to include 'jsbsim'
explicitly in their names; the ones without 'jsbsim' are now aliases
to the default, whatever that may be.
Here are some new, simpler aircraft identifiers:
--aircraft=cub
--aircraft=747
--aircraft=sopwithCamel
--aircraft=c310-3d
and so on.
This system allows users to create new *-set.xml files by overriding
parts of existing ones rather than by cut-and-paste.
- makes instrument knobs turn at a realistic rate
- removes redundant <min> and <max> specifications*
- corrects the indentation to reflect nesting depth
- corrects some descriptive names
* E.g. if the gyro compass heading is 365, there's no point clamping the
value to 360 before drawing it. Just using the given value is more
likely to be right - or, if it's wrong, at least we won't hide the bug.
button) modes. Due to a typo in altimeter.xml, one direction of
adjustment with the left mouse button was giving fast changes.
Simple patch attached.
- Julian
implement them for the C172P 3D model. Look near the top of
preferences.xml for an example. The recognized properties are as
follow, with vanilla defaults in parentheses:
/sim/view/config/default-field-of-view-deg (30)
/sim/view/config/default-pitch-deg (0)
/sim/view/config/front-direction-deg (0)
/sim/view/config/front-left-direction-deg (45)
/sim/view/config/left-direction-deg (90)
/sim/view/config/back-left-direction-deg (135)
/sim/view/config/back-direction-deg (180)
/sim/view/config/back-right-direction-deg (225)
/sim/view/config/right-direction-deg (270)
/sim/view/config/front-right-direction-deg (315)
These are particularly useful for the view from inside a 3D aircraft
model.
twice the design size (character height) of the old one.
Advantages:
- displays . and : correctly with less space around, and digits
with more space around (using Andy's improvements to plib)
- small text becomes much more legible (-> clock, AP-altitude)
- the font contains pretty much every character that can be
displayed on a seven segment display, so it might be more
useful for future instruments.
