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
There are two <dme> entries in preferences.xml, resulting in two dme branches
under /instrumentation/ (dme[0] and dme[1]). The serviceable property is only
set for the second entry (dme[1]), and that one is not connected to the dme
module. Solution: Remove the first <dme> entry, and set the index explicitly
to 0 for the remaining <dme> entry.
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.
These files add a functioning Fresnel Lens Optical Landing System (FLOLS).
The orange/red 'source' lights are illuminated according to the position of
the pilot's eye above/below the 3.5 deg glide slope. The apparent position
of the source light relative to the fixed green datum lights allow the pilot
to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is
below the coverage of the lowest (red) source light.
TODO - add rules for the operation of the wave-off lights.
the data/Huds/Default/default.xml file if we don't want to draw the runway
in the default HUD (but then we should take a close look at all the elements
in the default HUD if we go down that road.)
I have now the FDM side of an aircraft carrier set up.
The implementation uses a local cache of the scene graph to do intersection
tests. This can then be done per gear/hook/lauchbar.
Also the required aircraft carrier hardware will show up in this cache and can
provide the required information.
The cache itself is ATM integrated into the FGInterface class.
New are functions to query a ground contact point below a given location in
the earth. Together with that contact point the surface normal and the
velocity of that contact surface are returned. The locations, normals and
velovities are cartesian vectors given in the wgs84 coordinate system (origin
in the earths center, x axis towards lat=lon=0, y axis towards lat=0, lon=90,
z axis towards the north pole).
A function to test catching a wire. The test is done by intersection of the
quad where the hook moved during the past timestep with the lines
representing the wires. When this test was sucessfull, we can query for the
locations/velocities of the wires mount points. When the wire is no longer
needed it should be released.
Catapults are also stored as special lines in the scenegraph. There is a
function which returns the nearest catapult line and its current
locations/velocities.
To build up the cache you need to call a function to let the cache know where
and how big the cache must be.
I have also a preliminary implementation to make use of that stuff from within
JSBSim together with an aircraft which I have used for development.
To play with that, you have to install the patches/new files described above.
The hook can be extended with the H key, retracted with h. Start flightgear
with
fgfs --lat=37.688 --lon=-122.683 --heading=180 --altitude=71
and you will be placed on the carriers deck rolling backwards wrt the carrier.
Then apply the breaks and wait until the aircraft settled down past being not
trimmed. Now taxi on the deck to one of the catapults. When the nose wheel is
above the first few meters of the catapult (please taxi exactly there). Apply
the breaks and leave them applied. lower the flaps to half and give full
throttle. Pull a little at your stick and release the breaks. As the breaks
are released the aircraft is launched.
Then you can cruise a bit, and again try to land on the nimitz. When you land,
do not forget to extend the hook with 'H'.
If you like it, you can then taxi to the catapult ... :)
The physical model is not yet ready, but the api between the FDM and
flightgear has prooven to be sufficient for that task.
This file is in a rather bad state. Hence:
- remove doubled "rudder" settings
- fix & nasalify brake properties (/controls/gear/wheel[?]/brake, yet again)
- remove redundant index setting
- nasalify throttle (to allow more than 8 engines)
- nasalify flaps (to make flaps with more than 4 positions work)
- nasalify elevator trim (just for fun :-)
- fix syntax
- remove lots of trailing spaces
File tested by Jon-Eirik Pettersen
I attach the latest version of Nimitz. The textures have been improved. A glide-path has been added, it is on by default, but can be switched off by means of the properties browser: /ai/models/ship/controls/glide-path. The origin has been adjusted to the turning pivot and approximate roll center.
Modified AiShip files are also attached. These allow the radius of the turning circle of a ship to be input. The turning circle is adjusted for speed and rudder angle. Roll has been corrected so that a ship leans out of a turn, not inwards like an aircraft. The roll angle is adjusted for speed and rudder angle (yes, application of more rudder reduces roll angle - rudders act as stabilizers).
TODO
Add a relative wind calculation so that a carrier can be turned to the appropriate launch and recovery courses.
Add a 'flight plan' so that the carrier can carry out a racetrack for flight ops.
Add a projector landing sight.
Add auto-land facilities.
i modified the joystick settings for the Sidewinder Precision Pro joystick.
Now all buttons and axis react the same way in unix and windows except for
the view elevation binding which is on axis 5 in unix and 7 in windows.
Here the windows axis is inverse, the unix version is not.
This means if you move the hat down in unix you will look down
if you move the hat down in windows you will look up.
To fix this we would need some sort of property to inverse the axis independly
for windows and unix. If you know a way to do this feel free to fix this.
I also added some more button bindings.
With button 1 you can now switch between the views,
The brakes where moved from button 1 to button 0 because this button was
unused and users who want to switch from MS Flight Simulator to FlightGear
will like that too because the buttons are now used the same way on both
sims. With the unused button 8 (shift button), you can now retract the gears.
I also fixed the arrangement for the 4 buttons called A, B, C and D left to
the stick.
With button B you can now turn the flaps up and with button A down.
With button C you can use the left brake and with button D the right brake.
Before those changes the windows and unix bindings were different and somehow
unordered (crossed).
I tested this new Joystick settings in Windows Millenium and
Linux Slackware 10 with Flightgear 0.9.6 for windows and the newest cvs
version from today for Linux.
Here are files to get automated contrails working. I've set up contrails for
the 737, using my simple, untextured contrail model. Vivian has made another
contrail model, but I'm still trying to get his to work. I'm hoping others
will try to make contrail models also.
Here's some code that defines a top to thermals. When the top of a thermal is
reached the strength is phased-out linearly over the next 100 feet of
altitude. At first I tried just capping the thermal at the top, but the
change in thermal strength was too fast for the FDM to handle well.
Included is a new version of the thermal scenario that includes a top
(height-msl) to the thermal. The default value is 5000 feet.
I use both Linux and Win XP with my CH yoke and pedals and noted that I have two different versions of the yoke xml with the mixture and prop axis reversed. Here is an edit that works for me with both Win XP and Linux.
After applying the attached patches (based on latest CVS) you should
have a new option available within your version that should also
show up using fgfs --help, the syntax is:
fgfs --min-status={level} --show-aircraft
whereas "level" can be anything between
"alpha","beta","early-production" and "production"
Of course running something like
fgfs --min-status=alpha --show-aircraft
should not return any aircraft right now, as none of the
current aircraft definition files in your base-package is using the
required
<status></status>
tag - but you can easily give it a try by adding something like
<status>alpha</status>
The tag should be placed as a sub-tag within <sim> - so directly behind
the <description> tag would be just fine and straight-forward.
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.
This will modify menubar.cxx/hxx so that it exports the
entire menubar (from menubar.xml) to the property tree, so that it can
now be changed dynamically using Nasal's setprop() instruction and
afterwards running a newly added fgcommand to update the menubar
based on those changes using the appropriate menubar path within
the property tree.
By default the menubar from menubar.xml will be stored within:
/sim/menubar/default
Erik:
I have moved the loading of menubar.xml into preferences.xml and
made sure that the menubar is destroyed every time a new menubar
is created.
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.
