https://wiki.flightgear.org/w/api.php?action=feedcontributions&user=Flug&feedformat=atomFlightGear wiki - User contributions [en]2024-03-29T06:51:24ZUser contributionsMediaWiki 1.39.6https://wiki.flightgear.org/w/index.php?title=Howto:Adding_Bombable_to_FlightGear_Aircraft&diff=138414Howto:Adding Bombable to FlightGear Aircraft2023-09-22T05:17:13Z<p>Flug: /* STEP 4. Add to an AI Scenario */ more details, problems solved, troubleshooting, fixing some details, etc.</p>
<hr />
<div>{{Template:Bombable_Navigation}}<br />
<br />
[[File:camel-through-wing.jpg|thumb]]<br />
[[File:spad-vs-camel.jpg|thumb]]<br />
[[File:warthog-down-on-bay-bridge.jpg|thumb]]<br />
How to make a [[FlightGear]] [[aircraft]] work with [[Bombable]].<br />
<br />
When you follow these instructions, you will add the following properties to your aircraft:<br />
<br />
* AI aircraft can fly, maneuver, dodge, and attack the main aircraft. They can avoid the ground (aircraft) or stay on the ground (ships, vehicles) while maneuvering.<br />
* AI and MP aircraft can be damaged by the main aircraft and will stop functioning, crash, catch fire, explode, etc., appropriately when hit by weapons or bombs. MP aircraft will report damage back over MP to the main aircraft, making multiplayer dogfights possible.<br />
* MP aircraft will display weapons shooting whenever the remote MP aircraft is shooting, and report damage back to the main aircraft if the remote MP aircraft shoots or damages your aircraft.<br />
* AI and MP aircraft can have smoke, contrails, and damaged engine smoke<br />
* AI aircraft can automatically follow the main aircraft and attack it with weapons, which will be visible.<br />
* You can design and customize the features per aircraft--to make, for instance, a maneuverable twisty dogfighter, light and easily damaged, or a fast, heavily armored energy fighter with lower maneuverability.<br />
<br />
To make FlightGear aircraft work with Bombable--as the main aircraft, an AI aircraft, and via Multiplayer (MP)--you need three things:<br />
<br />
* Weapons submodels that report impacts properly<br />
* A snippet of code added to the aircraft's -set.xml file to allow communication of Bombable information over Multiplayer<br />
* A section of code in the load/unload section of the Aircraft's XML files that allow Bombable to initialize and give it information about the aircraft needed to operate as an AI or Multiplayer model<br />
<br />
There are several decisions you will have to make about where to put your file and what to name it (see "Where your aircraft files are" below for more info).<br />
<br />
For our example, we'll mod the [https://github.com/FGMEMBERS/F-15E F-15E model from FGUK] to become Bombable. We'll assume:<br />
<br />
* You have [[Bombable]] installed already<br />
* You have the aircraft installed in FGDATA/aircraft/F-15E<br />
* We will add the files/mods needed for AI aircraft to the FGDATA/aircraft/F-15E directories (rather than creating a new, separate FGDATA/AI/Aircraft version of the F-15E)<br />
* We're just going to mod the existing F-15E directories and aircraft without changing and aircraft or file names (rather than creating a separate, new, differently named F-15E-Bombable aircraft)<br />
<br />
== Preliminaries ==<br />
<br />
===Helpful/Needed files===<br />
<br />
* [http://www.flightgear.org/forums/viewtopic.php?t=5742 '''Bombable download''']<br />
*[http://brenthugh.com/flightgear/F-15E.zip '''F-15E model with the mods as described in this article'''] (finished and working version, though still un-polished, as described below, but with several updates and fixes beyond those mentioned in the article)<br />
**''Note that this zip file includes an AI directory with two AI scenarios you can use to fly against the F-15E AI aircraft. You can also use these two scenarios with the current F-15E model linked just below.''<br />
* [https://github.com/FGMEMBERS/F-15E '''Current F-15E model from FGUK'''] - which now includes the Bombable mods as well as a large number of tweaks and updates to the base F-15E model that have been added since 2011.<br />
<br />
=== Note: The original FGUK F-15E, without the Bombable mods, is no longer available. ===<br />
The mods described below were added to the base FGUK F-15E aircraft in about 2011. Since then, FGUK has incorporated the Bombable mods in the F-15E aircraft and then continued to make further enhancements to the F-15E since that time.<br />
<br />
So, unfortunately, you will not be able to download the original F-15E files and then follow the steps below to make your own modded F-15E version. <br />
<br />
Still, you can:<br />
<br />
* Download the [http://brenthugh.com/flightgear/F-15E.zip F-15E model with the mods as described in this article] (2011) to see the end result of the mods, and then read the steps below to see what changes were made to arrive at the Bombable-compatible mod.<br />
* Download the [https://github.com/FGMEMBERS/F-15E current F-15E model from FGUK], which also include the Bombable mods, and see how the mods look in a somewhat more current/updated aircraft model.<br />
<br />
Either way, by looking at either of those aircraft and following the instructions below, you should be able to get good idea about how the original files were modded to become compatible with Bombable.<br />
<br />
''Here is the step-by-step guide to modding the F-15E to become Bombable-compatible:''<br />
<br />
==Step 1: Check the weapons models for impact reporting==<br />
Most FG aircraft that have weapons already work with Bombable at a basic level, right out of the box. That is because FG has a way for aircraft weapons to report their impacts, and most FG aircraft with weapons already use the impact reporting system.<br />
<br />
First, find the XML file that defines the weapons submodels. Typically this is in the aircraft's Models directory (or a subdirectory). It may be named submodels.xml, or F-15-submodels.xml, or guns.xml, or something similar.<br />
<br />
When you open the correct file (FGDATA\Aircraft\F-15E\Models\Effects\guns\submodels.xml, in this case), it will look something like this:<br />
<br />
<PropertyList><br />
<br />
<!-- Gauche --><br />
<submodel><br />
<name>left</name><br />
<model>Aircraft/F-15E/Models/Effects/guns/apibullet-tracer.xml</model><br />
<trigger>controls/armament/trigger</trigger><br />
<speed>2460.0</speed><br />
<repeat>true</repeat><br />
. . . <br />
<br />
[[Howto:_Add_submodels|A complete description of these files is here.]]<br />
<br />
For each <submodel></submodel> section, the areas of interest are the <name> and the <collision> and <impact> areas.<br />
<br />
===Submodel name===<br />
For the submodel name, in FG 2.4.0 we are working around a little FG bug, and Bombable identifies munitions and weapons by their name. <br />
<br />
So it is very important that the name of each weapons submodel include one of the following keywords:<br />
<br />
gun, tracer, bullet, round, cannon, bomb, heavy-bomb, rocket, missile, <br />
MK-81, MK-82, MK-83, MK-84, 5 pound, 25 pound, 100 pound, 150 pound, <br />
250 pound, 500 pound, 1000 pound, 2000 pound<br />
<br />
The name simply needs to include the appropriate keyword in some way--so if you have another name you prefer, just include the keyword at the end, like "MKFD Special Munition (250 pound)".<br />
<br />
In this case, it is a 20 mm gatling gun, so more into cannon range, with projectiles weighing in at about .25 lb. So we simply add "cannon" to each of the submodel names:<br />
<br />
<submodel><br />
<name>left cannon</name><br />
<br />
<submodel><br />
<name>right cannon</name><br />
<br />
===Collision and impact reporting===<br />
The collision and impact areas of this file look like this:<br />
<br />
<collision>true</collision><br />
<collision-report>sim/ai/aircraft/collision/gun</collision-report><br />
<impact>true</impact><br />
<impact-report>sim/ai/aircraft/impact/bullet</impact-report><br />
<br />
[IMPORTANT!] Both <collision> and <impact> should be set to true. <br />
<br />
[IMPORTANT!] <impact-report> should be one of these--the first one is the default, but any is fine:<br />
<br />
ai/models/model-impact<br />
sim/armament/weapons/impact<br />
sim/ai/aircraft/impact/bullet<br />
sim/ai/aircraft/impact/gun<br />
sim/ai/aircraft/impact/cannon<br />
sim/ai/aircraft/impact/bomb<br />
<br />
According to the FG documentation, the <collision-report> setting is no longer used, so you can safely delete it (though it does no harm to leave it be).<br />
<br />
For the F-15E, this section of each <submodel> looks fine, so we just leave it alone.<br />
<br />
We save the file with the changes to the <name> sections.<br />
<br />
==STEP 2: Adding code needed for MultiPlayer to the -set.xml file==<br />
<br />
In the aircraft's -set.XML file, we need to add a <multiplay> section in the <PropertyList><sim> section.<br />
<br />
This gets a bit confusing for two reasons:<br />
<br />
* -set.xml files may (or may not!) load other files, so the <sim> section where we need to add our code may be in the -set.xml file OR in one of the other .xml files the -set.xml file loads<br />
<br />
* There may be existing code in <sim><multiplayer> and so we can simply add our code to that rather than creating a new/different <multiplayer> section.<br />
<br />
In the case of the F-15E, we open FGDATA\Aircraft\F-15E\F-15E_StrikeEagle-set.xml and find:<br />
<br />
<?xml version="1.0"?><br />
<PropertyList><br />
<sim><br />
<br />
<description>F-15E_Strike_Eagle</description><br />
<author>Flying Toaster 3DM, StuartC</author><br />
<status>Alpha 2.01</status><br />
. . .<br />
<br />
[[Howto: Make_an_aircraft#The_-set.xml_file|Find out more about the -set.xml file here.]]<br />
<br />
The <sim> section is what we are looking for.<br />
<br />
We search for <multiplayer> and don't find any existing <multiplayer> section. So we can add our needed <multiplayer> section in any convenient place. Let's place it between the <submodels> and <panel> sections. The added code is in between those two:<br />
<br />
<submodels> <br />
<serviceable type="bool">true</serviceable><br />
<path>Aircraft/F-15E/Models/Effects/guns/submodels.xml</path><br />
<path>Aircraft/F-15E/Models/weapons/loads.xml</path><br />
</submodels><br />
<br />
<!-- Required to make Bombable work over multiplayer --><br />
<!-- String 9 is for Bombable damage/reset messages --><br />
<!-- Int 10,11,... are for various weapons triggers as particular to this aircraft --><br />
<multiplay><br />
<generic><br />
<string n="9" type="string"/><br />
<int n="10" alias="controls/armament/trigger" /><br />
</generic><br />
</multiplay><br />
<br />
<br />
<panel><br />
<visibility archive="y">false</visibility><br />
</panel><br />
<br />
You'll notice we have customized one line: <int n="10" alias="controls/armament/trigger" /><br />
<br />
The alias, controls/armament/trigger, refers to the submodel <trigger> which we observed in Step 1. <br />
<br />
If the aircraft has more than one trigger (for more than one weapon, for example), we can make several triggers like this:<br />
<br />
<int n="10" alias="controls/armament/trigger" /><br />
<int n="11" alias="controls/armament/trigger1" /><br />
<int n="12" alias="controls/armament/trigger2" /><br />
<int n="13" alias="controls/armament/trigger3" /><br />
<int n="14" alias="controls/armament/trigger4" /><br />
<br />
Each alias should correspond to a different <trigger> property in the submodel.xml definitions.<br />
<br />
Save the -set.xml file with the changes.<br />
<br />
==STEP 3: Add the Bombable Nasal code to the Model XML file==<br />
<br />
Bombable needs to have certain code run when the AI or MP aircraft initializes. The code is in [[Nasal]], FlightGear's scripting language. The code gives Bombable needed information about the aircraft (dimensions, vulnerabilities, weapons, etc) and also the code tells Bombable which systems to initialize for this aircraft.<br />
<br />
The simplest way to create this code is to start with a similar aircraft in the Bombable download, then copy and mod the Bombable code as needed.<br />
<br />
There are two steps in this process:<br />
<br />
* Create the -bombableinclude.xml file<br />
* Link the -bombableinclude.xml file to the aircraft's existing model XML file<br />
<br />
===Create the -bombableinclude.xml file=== <br />
In the Bombable distribution, the include files are named [aircraftname]-bombableinclude.xml and are generally found in FGDATA/AI/Aircraft/[aircraftname]/Models.<br />
<br />
In this case, the most similar aircraft in the Bombable distribution is the A-10. If [[Bombable]] is installed, the needed file is in:<br />
<br />
FGDATA\AI\Aircraft\A-10-Bombable\Models\A-10-bombableinclude.xml<br />
<br />
Open the file with a text editor and save it with a new name in your F-15E directory. The new name & directory should be something like:<br />
<br />
FGDATA\Aircraft\F-15E\Models\F-15E_StrikeEagle-bombableinclude.xml<br />
<br />
Now you can open and edit this file. Most changes are quite obvious--change the name, change the dimensions, etc.<br />
<br />
When done, we end up with a file like this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList><br />
<!-- Nasal code --><br />
<nasal><br />
<br />
<br />
<load><br />
<![CDATA[<br />
print("Loading F-15E ", cmdarg().getPath());<br />
<br />
var nodeName = cmdarg().getPath(); <br />
<br />
##checks whether it has been initialized already; if so, just return<br />
if ( bombable.check_overall_initialized (nodeName) ) return;<br />
<br />
<br />
<br />
<br />
############################################<br />
#FUNCTION object_init, INITIALIZER<br />
var object_init = func() {<br />
# Datas of this object are under: cmdarg().getPath()<br />
var thisNodeName = cmdarg().getPath();<br />
var thisNode = props.globals.getNode(thisNodeName);<br />
# Add some useful nodes<br />
<br />
<br />
<br />
########################################################################<br />
########################################################################<br />
# INITIALIZE BOMBABLE<br />
# <br />
# Initialize constants and main routines for maintaining altitude<br />
# relative to ground-level, relocating after file/reset, and <br />
# creating bombable/shootable objects.<br />
# <br />
# These routines are found in FG/nasal/bombable.nas<br />
# <br />
######################################################################## <br />
# INITIALIZE BOMBABLE Object<br />
# This object will be slurped in the object's node as a child<br />
# node named "bombable". <br />
# All distances are specified in meters.<br />
# All altitudes are relative to current ground level at the object's <br />
# location<br />
# <br />
<br />
thisNodeName = cmdarg().getPath(); <br />
<br />
var bombableObject = { <br />
<br />
<br />
objectNodeName : thisNodeName,<br />
objectNode : props.globals.getNode(thisNodeName),<br />
updateTime_s : 1/3, #time, in seconds, between the updates that <br />
#keep the object at its AGL. Tradeoff is high-speed updates look more<br />
#realistic but slow down the framerate/cause jerkiness. Faster-moving<br />
#objects will need more frequent updates to look realistic.<br />
#update time faster than about 1/3 seems to have a noticeable effect<br />
#on frame rate <br />
<br />
<br />
######################################### <br />
# ALTITUDE DEFINITIONS<br />
# <br />
altitudes : { <br />
wheelsOnGroundAGL_m : 1 , #altitude correction to add to your aircraft or ship that is needed to put wheels on ground (or, for a ship, make it float in the water at the correct level). For most objects this is 0 but some models need a small correction to place them exactly at ground level<br />
<br />
minimumAGL_m : 300, #minimum altitude above ground level this object is allowed to fly<br />
maximumAGL_m : 50000, #maximum altitude AGL this object is allowed to fly, ie, operational ceiling <br />
crashedAGL_m : 0.6, #altitude AGL when crashed. Ships will sink to this level, aircraft or vehicles will sink into the ground as landing gear collapses or tires deflate. Should be negative, even just -0.001.<br />
},<br />
# <br />
#########################################<br />
# VELOCITIES DEFINITIONS<br />
# <br />
velocities : { <br />
maxSpeedReduce_percent : 0.5, #max % to reduce speed, per step, when damaged<br />
minSpeed_kt : 112, #minimum speed to reduce to when damaged. Ground vehicles and ships might stop completely when damaged but aircraft will need a minimum speed so they keep moving until they hit the ground.<br />
cruiseSpeed_kt : 550, #cruising speed, typical/optimal cruising speed, V C for aircraft<br />
<br />
attackSpeed_kt : 900, #typical/optimal speed when aggressively attacking or evading, in<br />
#level flight for aircraft<br />
<br />
maxSpeed_kt : 1400 , #Maximum possible speed under dive or downhill conditions, V NE for aircraft<br />
<br />
damagedAltitudeChangeMaxRate_meterspersecond : 30, #max rate to sink or fly downwards when damaged, in meters/second<br />
<br />
#The terminal velocities are calculated by opening the 'real' AC <br />
#in FG, level flight, full throttle, then putting<br />
#the AC at different angles of attack with the autopilot,<br />
#and noting the terminal airspeed & vertical speed velocities.<br />
#For best results, do it near sea level, under 5000 feet altitude.<br />
#One or two each of climb & dive velocities are probably sufficient.<br />
#However if you do more we may be able to use the more precise<br />
#data in the future.<br />
#<br />
#Note that these are intended to be true airspeed whereas FG's<br />
#/velocities/airspeed-kt reports indicated airspeed, so some <br />
#conversion or reference to groundspeed-kt is needed.<br />
# <br />
#In FG /velocities/groundspeed-kt is equal (or close <br />
#to equal, except for wind . . .) true airspeed when pitch=0 <br />
#but as pitch increases or decreases that will change.<br />
# <br />
diveTerminalVelocities: {<br />
point1: { airspeed_kt : 1060, vertical_speed_fps : - 337},<br />
point2: { airspeed_kt : 1230, vertical_speed_fps : - 755},<br />
<br />
},<br />
<br />
climbTerminalVelocities: {<br />
point1: { airspeed_kt : 468, vertical_speed_fps : 236},<br />
point2: { airspeed_kt : 843, vertical_speed_fps : 251},<br />
#point3: { airspeed_kt : 1100, vertical_speed_fps : 161},<br />
<br />
},<br />
<br />
},<br />
# <br />
#########################################<br />
# EVASION DEFINITIONS<br />
# <br />
# The evasion system makes the AI aircraft dodge when they come under<br />
# fire. <br />
evasions : { <br />
dodgeDelayMax_sec : 15, #max time to delay/wait between dodges<br />
dodgeDelayMin_sec : 5, #minimum time to delay/wait between dodges<br />
dodgeMax_deg : 88, #Max amount to turn when dodging<br />
#90 degrees = instant turn, unrealistic<br />
#up to 80 is usually OK, somewhere in 80-85 starts to be unrealistically fast<br />
#>85 is usually very unrealistic. You must test this in your scenario, however.<br />
<br />
dodgeMin_deg : 83, #minimum amount to turn when dodging <br />
rollRateMax_degpersec : 300, #you can figure this out by rolling the corresponding FG aircraft and timing a 180 or 360 deg roll <br />
dodgeROverLPreference_percent : 50, # Preference for right turns vs. left when dodging. 90% means 90% right turns, 50% means 50% right turns.<br />
dodgeAltMin_m : -8000, #Aircraft will begin to move up or down <br />
dodgeAltMax_m : 8000, #Max & Min are relative to current alt <br />
dodgeVertSpeedClimb_mps : 1500, #Max speed to climb when evading<br />
dodgeVertSpeedDive_mps : 1500, #Max speed to dive when evading <br />
},<br />
# <br />
#########################################<br />
# ATTACK DEFINITIONS<br />
# <br />
# The attack system makes the AI aircraft turn and fly towards <br />
# other aircraft <br />
attacks : { <br />
maxDistance_m : 30000, #max distance to turn & attack main aircraft<br />
minDistance_m : 4000, #min distance to turn & attack main aircraft, ie, fly away this far before turning to attack again<br />
continueAttackAngle_deg : 80, #when within minDistance_m, the aircraft will continue to turn towards the main aircraft and attack *if* if the angle is less than this amount from dead ahead<br />
altitudeHigherCutoff_m : 30000, # will attack the main aircraft unless this amount higher than it or more<br />
altitudeLowerCutoff_m : 30000, # will attack the main aircraft unless this amount lower than it or more<br />
climbPower : 8000, # How powerful the aircraft is when climbing during an attack; 4000 would be typical for, say a Zero--scale accordingly for others; higher is stronger<br />
divePower : 10000, # How powerful the aircraft is when diving during and attack; 6000 typical of a Zero--could be much more than climbPower if the aircraft is a weak climber but a strong diver <br />
rollMin_deg : 82, #when turning on attack, roll to this angle min<br />
#for sedate, Cessna-like manuevers make rollMin low. If you want an aggressive,<br />
#attacking, aiming fighter keep it close to rollMax, or even almost equal to rollMax <br />
rollMax_deg : 87, #when turning on attack, roll to this angle max<br />
#90 degrees = instant turn, unrealistic<br />
#up to 80 might be OK, depending on aircraft & speed; somewhere in 80-85 starts to be unrealistically fast<br />
#>85 is usually very unrealistic. You must test this in your scenario, however.<br />
rollRateMax_degpersec : 120, #you can figure this out by rolling the corresponding FG aircraft and timing a 180 or 360 deg roll <br />
attackCheckTime_sec : 10, # check for need to attack/correct course this often <br />
attackCheckTimeEngaged_sec : 0.5, # once engaged with enemy, check/update course this frequently<br />
<br />
},<br />
<br />
# <br />
#########################################<br />
# WEAPONS DEFINITIONS<br />
# <br />
# The weapons system makes the AI aircraft fire on the main aircraft <br />
# You can define any number of weapons--just enclose each in curly brackets<br />
# and separate with commas (,). <br />
weapons : {<br />
front_gun : #internal name - this can be any name you want; must be a valid nasal variable name<br />
{ <br />
name : "Machine Gun", # name presented to users, ie in on-screen messages<br />
maxDamage_percent : 5, # maximum percentage damage one hit from the aircraft's main weapon/machine guns will do to an opponent<br />
maxDamageDistance_m : 2000, # maximum distance at which the aircrafts main weapon/maching guns will be able to damage an opponent<br />
weaponAngle_deg : { heading: 0, elevation: 0 }, # direction the aircraft's main weapon is aimed. <br />
# 0,0 = straight ahead, 90,0=directly right, 0,90=directly up, 0,180=directly back, etc.<br />
weaponOffset_m : {x:2, y:0, z:0}, # Offset of the weapon from the main aircraft center<br />
weaponSize_m : {start:.1, end:.1}, # Visual size of the weapon's projectile, in meters, at start & end of its path<br />
<br />
}, <br />
sidewinder_missile : #internal name - this can be any name you want; must be a valid nasal variable name<br />
{ <br />
name : "Sidewinder guided missile", # name presented to users, ie in on-screen messages<br />
maxDamage_percent : 40, # maximum percentage damage one hit from the aircraft's main weapon/machine guns will do to an opponent<br />
maxDamageDistance_m : 6000, # maximum distance at which the aircrafts main weapon/machine guns will be able to damage an opponent<br />
weaponAngle_deg : { heading: 0, elevation: 0 }, # direction the aircraft's main weapon is aimed. <br />
# 0,0 = straight ahead, 90,0=directly right, 0,90=directly up, 0,180=directly back, etc.<br />
weaponOffset_m : {x:2, y:0, z:0}, # Offset of the weapon from the main aircraft center<br />
weaponSize_m : {start:1, end:1}, # Visual size of the weapon's projectile, in meters, at start & end of its path<br />
<br />
}, <br />
<br />
<br />
}, <br />
<br />
# <br />
#########################################<br />
# DIMENSION DEFINITIONS<br />
#<br />
# All dimensions are in meters<br />
# <br />
# <br />
dimensions : { <br />
width_m : 17.53, #width of your object, ie, for aircraft, wingspan<br />
length_m : 16.26, #length of your object, ie, for aircraft, distance nose to tail<br />
height_m : 4.47, #height of your object, ie, for aircraft ground to highest point when sitting on runway<br />
<br />
damageRadius_m : 8, #typically 1/2 the longest dimension of the object. Hits within this distance of the <br />
#center of object have some possibility of damage<br />
vitalDamageRadius_m : 2, #typically the radius of the fuselage or cockpit or other most <br />
# vital area at the center of the object. Always smaller than damageRadius_m<br />
<br />
crashRadius_m : 6, #It's a crash if the main aircraft hits in this area.<br />
<br />
},<br />
#<br />
#########################################<br />
# VULNERABILITIES DEFINITIONS <br />
#<br />
vulnerabilities : { <br />
damageVulnerability : 9, #Vulnerability to damage from armament, 1=normal M1 tank; higher to make objects easier to kill and lower to make them more difficult. This is a multiplier, so 5 means 5X easier to kill than an M1, 1/5 means 5X harder to kill. <br />
<br />
engineDamageVulnerability_percent : 6, #Chance that a small-caliber machine-gun round will damage the engine. <br />
<br />
fireVulnerability_percent : 5, #Vulnerability to catching on fire. 100% means even the slightest impact will set it on fire; 20% means quite difficult to set on fire; 0% means set on fire only when completely damaged; -1% means never set on fire. <br />
<br />
fireDamageRate_percentpersecond : .1, #Amount of damage to add, per second, when on fire. 100%=completely damaged. Warthog is relatively damage-resistant.<br />
<br />
fireExtinguishMaxTime_seconds : 80, #Once a fire starts, for this many seconds there is a chance to put out the fire; fires lasting longer than this won't be put out until the object burns out.<br />
<br />
fireExtinguishSuccess_percentage : 45, #Chance of the crew putting out the fire within the MaxTime above. Warthoge is relatively damage-resistant.<br />
<br />
explosiveMass_kg : 27772 , #mass of the object in KG, but give at least a 2-10X bonus to anything carrying flammables or high explosives.<br />
},<br />
#<br />
#########################################<br />
# LIVERY DEFINITIONS<br />
#<br />
# Path to livery files to use at different damage levels.<br />
# Path is relative to the AI aircraft's directory.<br />
# The object will start with the first livery listed and <br />
# change to succeeding liveries as the damage<br />
# level increases. The final livery should indicate full damage/<br />
# object destroyed. <br />
# <br />
# If you don't want to specify any special liveries simply set <br />
# damageLivery : nil and the object's normal livery will be used. <br />
# <br />
damageLiveries : {<br />
damageLivery : [ ] <br />
},<br />
<br />
};<br />
<br />
#########################################<br />
# INITIALIZE ROUTINES<br />
# <br />
# OVERALL INITIALIZER: Needed to make all the others work<br />
bombable.initialize ( bombableObject );<br />
#<br />
# LOCATION: Relocate object to maintain its position after file/reset <br />
# (best not used for airplanes)<br />
# bombable.location_init ( thisNodeName );<br />
#<br />
# GROUND: Keep object at altitude relative to ground level<br />
bombable.ground_init ( thisNodeName );<br />
#<br />
# ATTACK: Make the object attack the main aircraft <br />
bombable.attack_init ( thisNodeName );<br />
#<br />
# WEAPONS: Make the object shoot the main aircraft <br />
bombable.weapons_init ( thisNodeName ); <br />
#<br />
# BOMBABLE: Make the object bombable/damageable <br />
bombable.bombable_init ( thisNodeName );<br />
#<br />
# SMOKE/CONTRAIL: Start a flare, contrail, smoke trail, or exhaust <br />
# trail for the object.<br />
# Smoke types available: flare, jetcontrail, pistonexhaust, smoketrail,<br />
# damagedengine <br />
bombable.startSmoke("jetcontrail", thisNodeName );<br />
#F-15E already has contrails, we're leaving this out<br />
#<br />
# END INITIALIZE BOMBABLE<br />
########################################################################<br />
######################################################################## <br />
<br />
<br />
<br />
}<br />
<br />
object_init();<br />
]]><br />
</load><br />
<unload><br />
<![CDATA[<br />
print("Unload F-15E.");<br />
var nodeName= cmdarg().getPath(); <br />
bombable.de_overall_initialize( nodeName );<br />
bombable.initialize_del( nodeName );<br />
bombable.ground_del( nodeName );<br />
bombable.location_del (nodeName);<br />
bombable.bombable_del( nodeName );<br />
bombable.attack_del( nodeName );<br />
bombable.weapons_del (nodeName); <br />
# </unload><br />
<br />
]]><br />
</unload><br />
</nasal> <br />
<br />
</PropertyList><br />
<br />
Save this file with the name you have chosen ( FGDATA\Aircraft\F-15E\Models\F-15E_StrikeEagle-bombableinclude.xml).<br />
<br />
===Link the -bombableinclude.xml file to the existing F-15 model file===<br />
<br />
Now that we have created the -bombableinclude.xml file, we need to set up the aircraft to load the file on startup.<br />
<br />
AI scenarios (and MP aircraft) load the aircraft's model file. So we need to locate that file and include the new -bombableinclude.xml file in it.<br />
<br />
Where is the model file? Look in the aircraft's -set.xml file. In that file will be a section called <model>. For the F-15E it looks like this:<br />
<br />
<model><br />
<path>Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</path><br />
</model><br />
<br />
So Aircraft/F-15E/Models/F-15E_StrikeEagle.xml is our model file. <br />
<br />
<br />
Load Aircraft/F-15E/Models/F-15E_StrikeEagle.xml in a text editor. At the beginning of that file you will find this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList><br />
<br />
Change it to this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList include="F-15E_StrikeEagle-bombableinclude.xml"><br />
<br />
Save the file.<br />
<br />
===Notes===<br />
* The statement include="F-15E_StrikeEagle-bombableinclude.xml" indicates that F-15E_StrikeEagle-bombableinclude.xml will be in the same directory as F-15E_StrikeEagle.xml. That directory is Aircraft/F-15E/Models -- so make sure that the -bombableinclude.xml file is indeed in that directory!<br />
<br />
* Model files can have only ONE Nasal <load> section and one <unload> section. Ramifications:<br />
<blockquote>''If you have more than one, the second and subsequent <load>/<unload> sections are ignored.''<br />
<br />
''The problem? Your aircraft may already have a <load> or <unload> section. When you add the Bombable code, one of the two <load> sections (the pre-existing one or Bombable's) will be ignored.''<br />
<br />
''The solution is to combine the two <load> sections into one, and the same with the <unload> sections. You'll need to know a little about [[Nasal]] programming to do anything complicated, but as a rule you can just copy/paste whatever is in the aircraft's <load> section to the '''end''' of Bombable's <load> section, and the same with <unload>.''<br />
<br />
* ''One trick here is to post the existing Nasal code at the END of the section, AFTER the Bombable code - both for the <load> and <unload> sections. This is a bit of a kludge, but it allows you to use the same model file for both regular and AI aircraft. Often the existing nasal in the model file is needed only for regular/piloted aircraft and not for the AI version. Because of this, the code will thrown an error when run as an AI aircraft. If you simply place the existing Nasal code AFTER the Bombable code, the Bombable code will run (it works and is needed for both regular and AI aircraft). Then if the existing Nasal code runs as a regular aircraft, it will run fine as well. If it is an AI aircraft, it will give a runtime error and stop. But it won't hurt anything because the Bombable code has already run.''<br />
* ''The proper way to address this issue is to make separate model files for regular and AI aircraft. The AI aircraft can generally be stripped way down, no console and other details are needed, and much less nasal code for subsystems is needed. How to handle all of that properly is a whole topic of its own.''<br />
</blockquote><br />
* You'll notice the Nasal code starts with ''<![CDATA['' and ends with '']]>''. That is needed to make Nasal code work within XML files. [http://www.w3schools.com/xml/xml_cdata.asp CDATA usage is explained here.]<br />
<br />
==STEP 4. Add to an AI Scenario==<br />
Now we can add the F-15E to an AI scenario.<br />
<br />
Create a file named F-15E-demo.xml and save it in your FGDATA/AI directory.<br />
<br />
Most of the entries in the scenario file are self-explanatory. For the <model> entry you'll need the path of the same model file for the F-15 that we located in Step 3--which is Aircraft/F-15E/Models/F-15E_StrikeEagle.xml.<br />
<br />
Here is how the file should look when you are done:<br />
<br />
<?xml version="1.0"?><br />
<PropertyList><br />
<scenario><br />
<description>My new F-15E scenario. Starts at KSFO! </description><br />
<br />
<entry><br />
<type>aircraft</type><br />
<callsign>Jones</callsign><br />
<name>F15E Leader</name><br />
<model type="string">Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model><br />
<latitude type="double">37.608720</latitude><br />
<longitude type="double">-122.3076</longitude><br />
<altitude type="double">309</altitude><br />
<speed>280.0</speed><br />
<heading type="double">192</heading><br />
</entry><br />
<br />
<entry><br />
<type>aircraft</type><br />
<callsign>Cooper</callsign><br />
<name>F15E Wingman</name><br />
<model type="string">Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model><br />
<latitude type="double">37.608200</latitude><br />
<longitude type="double">-122.2988</longitude><br />
<altitude type="double">309</altitude><br />
<speed>270.0</speed><br />
<heading type="double">192</heading><br />
</entry><br />
</scenario><br />
<br />
</PropertyList><br />
<br />
Again, save as FGDATA/AI/F-15E-demo.xml. When you start FGRun next time, F-15E-demo will be listed as one of the scenario file options. (You may need to quit and re-start FGRun.)<br />
<br />
If the scenario doesn't appear, check [fgfs.log] for any errors related to the scenario file. Here is a typical error message:<blockquote>''0.53 [WARN]:ai C:\Jenkins\workspace\Windows-release\flightgear\src\AIModel\AIManager.cxx:257: Skipping malformed scenario file:Path "e:/FlightGear 2020.3/data/AI/F-15E-demo.xml"''<br />
<br />
'' 0.53 [WARN]:general C:\Jenkins\workspace\Windows-release\simgear\simgear\debug\ErrorReportingCallback.cxx:82: Error:bad data from sceanrio load::The scenario couldn't be loaded:mismatched tag''<br />
<br />
''at e:/FlightGear 2020.3/data/AI/F-15E-demo.xml,''<br />
<br />
''line 31, column 2''<br />
<br />
'' e:/FlightGear 2020.3/data/AI/F-15E-demo.xml,''<br />
<br />
''line 31, column 2''</blockquote><br />
<br />
* The path given in this line can vary: ''<model type="string">Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model>''<br />
** If you are placing the scenario file in the AI subdirectory and the aircraft is in ''AI/Aircraft/F-15E - then the above line will work as is.''<br />
** However, a common situation is to place the aircraft file in data/Aircraft/F-15E (as we described above - that is the normal place for regular/piloted aircraft, and if we are NOT making a special AI version of the aircraft, then the aircraft will ilve in data/Aircraft/F-15E or a similar place. In that case, perhaps the AI folder is in ''data/AI'' and the F-15E folder is in ''data/Aircraft/F-15E.'' In that case, we need a correct relative directory from wherever the scenario .xml file is to wherever the F-15E model file is, for example:<br />
*** <model type="string">../Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model><br />
**** Here ".." means go to the parent directory, so "../Aircraft" means go to the parent directoy of ''AI'', then go to the ''Aircraft'' subdirectory from there.<br />
**** Regardless of the details, the point is: In order for the scenario file to work properly, you must have a proper, complete, accurate path leading from the location of the AI scenario file to the location of the ''F-15E_StrikeEagle.xml'' file.<br />
**** More details about this below in the section ''Where your aircraft files are''.<br />
<br />
==STEP 5. Troubleshooting==<br />
OK, we're done. Time to fly our new aircraft in our new scenario!<br />
<br />
Oh, yeah . . . we just followed a very complicated process with numerous steps that could go wrong. Maybe we'd better test a bit first.<br />
<br />
Start Flightgear. Using FGRun:<br />
<br />
1. Choose ''UFO bombable'' as the main aircraft (best for testing . . . )<br />
2. Airport KSFO<br />
3. Scenario F-15-demo (which we just created--if saved correctly in the FGDATA/AI directory, it will show up in the scenario list of FGRun)<br />
4. Click "Run"<br />
5. Closely watch the command console as FG starts. You may pick up important errors in XML files and/or Nasal code.<br />
6. You should see<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
<br />
Uh-oh. There is our first error. f-15-demo.xml, line 31, column 2, I have "<scenario>" rather than "</scenario>".<br />
<br />
I fix, save the fixed file, and re-start. Now I get:<br />
<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
* Failed to load XML: . . . F-15E-StrikeEagle-bombableinclude.xml<br />
<br />
OK, this is typical. There is a typo or stray character on the .xml file . . . or something.<br />
<br />
After a few minutes of trying different things, I discover I've made a typo:<br />
<br />
* In \Aircraft\F-15E\Models\F-15E_StrikeEagle.xml is this line:<br />
<PropertyList include="F-15E_StrikeEagle-bombableinclude.xml"><br />
* But I've saved the file as <br />
FGDATA/Aircraft/F-15E/F-15-StrikeEagle-bombableinclude.xml<br />
<br />
OK, that one little "E" after F-15 made all the difference. Plus, in one place it has "-" before StrikeEagle, and in the other one it has "_". I change the filename to match what's in the -set.xml file and try again.<br />
<br />
And finally:<br />
<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
* Loading F-15E /ai/models/aircraft<br />
* Loading F-15E /ai/models/aircraft[1]<br />
* A bunch of other Bombable messages showing the aircraft initializing (I have Bombable menu/Debug turned on, which is helpful at this stage)<br />
* A bunch of error messages showing various animations and systems not load (ahhh . . . that's why we create stripped-down versions of aircraft in the AI/Aircraft directory--a completely separate and even longer article).<br />
<br />
I open Equipment/Maps, click "traffic", see the two aircraft "Jones" and "Cooper", track them down with the UFO, they show proper smoke trails, I shoot at them, I shoot them down. It works!<br />
<br />
Success!<br />
<br />
Well, except . . . are they flying realistically? Climbing, turning, diving, shooting? Are they taking damage realistically? Does it work properly under Multiplayer?<br />
<br />
Here is where you spend hours researching real F-15s, flying against the AI models with the UFO and other aircraft, tweaking parameters in the -bombableinclude.xml file, and so on and on.<br />
<br />
You're just getting started. <br />
<br />
Good luck!<br />
<br />
===Testing/parsing XML files===<br />
One final tip: XML files are extremely persnickety. Just one wrong character can make an entire file fail to load. <br />
<br />
The best/easiest way to test XML files is load them in Internet Explorer. It will parse the XML file and display any errors it finds. (If you don't have access to IE there are other XML parsers available.) This is far easier and faster than starting and re-starting FG repeatedly, and IE gives better, more informative error messages as well.<br />
<br />
==IMPORTANT POSTSCRIPT: Where your aircraft files are==<br />
An important detail in getting Bombable to work with aircraft over AI and MP is the directories you store the files in and the names you choose to use for them.<br />
<br />
FlightGear stores aircraft and AI aircraft files in at least two different places.<br />
<br />
In a typical FG installation, in your FGDATA folder, you will find<br />
<br />
* FGDATA/Aircraft<br />
* FGDATA/AI/Aircraft<br />
<br />
FGDATA/Aircraft holds files for the main aircraft whereas FGDATA/AI/Aircraft holds files for AI and MP aircraft.<br />
<br />
AI/MP aircraft don't have all the features of main aircraft, so you might find the very same aircraft in FGDATA/Aircraft and in FGDATA/AI/Aircraft--but the one in FGDATA/AI/Aircraft will be very stripped down, fewer files, smaller, and less complex.<br />
<br />
When building a [[AI_Systems#AI_Models|FlightGear AI scenario]], you can specify the exact path and filename of the file FlightGear looks for. You can specify a file in the FGDATA/Aircraft directory, or in the FGDATA/AI/Aircraft, or really anywhere within the FGDATA directory that you like. Examples:<br />
<br />
<model type="string">AI/Aircraft/sopwithCamel-Bombable/Models/sopwithCamel-model.xml</model> <br />
<br />
OR<br />
<br />
<model type="string">Aircraft/sopwithCamel-Bombable/Models/sopwithCamel-model.xml</model> <br />
<br />
When loading an MP aircraft, FlightGear first looks for the (typically smaller/simpler) aircraft file in FGDATA/AI/Aircraft.<br />
<br />
If it doesn't find the aircraft there, it then searches FGDATA/Aircraft.<br />
<br />
===How FG matches Multiplayer Aircraft with your local AI aircraft models===<br />
<br />
As of version 2.4.0, when FG is looking for the local AI aircraft model to display for a remote aircraft over Multiplayer, FG searches first the AI Aircraft directories, then the Aircraft directories.<br />
<br />
It searches for a match by looking for the file with a name exactly matching the MP aircraft's model (this is typically in the aircraft's Models subdirectory and ends with .ac, though this may vary) and if that fails, FG looks for a matching -set.xml file.<br />
<br />
The important points for making AI models that will work over MP with Bombable: <br />
<br />
* Make sure the main aircraft and the AI version of the aircraft have the exact same names for the aircraft's model file and the aircraft's -set.xml<br />
<br />
* If you're modding an existing but non-bombable-compatible aircraft, you need to decide whether you're going to leave all the directories, model XML file names, and -set.xml file names the same as the standard flightgear aircraft (leading to possible frustration as your version overwrites existing aircraft files on users hard drivers) OR rename the aircraft's directory, -set.xml file name, and model file name (which means you're going to have to do a bit of work on the aircraft's XML files to make sure everything still works with all those name changes.<br />
<br />
* You can create a separate, stripped down AI version of the aircraft in the FGDATA/AI/Aircraft directory and add the Bombable additions to it (more work for you but smaller/quicker download and easier on the memory and framerate in FG) OR you can simply add all the Bombable additions to the main aircraft directory in FGDATA/Aircraft.<br />
<br />
Bombable will work with any of those options--so it is really up to you.<br />
<br />
==EXTRA: Making livery change with damage==<br />
<br />
Once you have Bombable working with your aircraft there is a bonus: bombable.nas will handle setting the livery colors and<br />
automatically changing them as the object becomes damaged. <br />
<br />
For an example of how this works and looks, take a look at the Bombable scenarios involving the M1 tank and the Jeep.<br />
<br />
For this to work your model must have different liveries available<br />
and then animate the liveries so that the texture used is the one shown<br />
in this path: /ai/model/model[X]/bombable/texture-corps-path. The /ai/model/model[X]/ part is assumed for AI craft so you need to add <texture-prop>bombable/texture-corps-path</texture-prop> in the right place of your XML file. <br />
<br />
Example from Jeep.xml in the jeep-bombable directory:<br />
<br />
<animation><br />
<type>material</type><br />
<object-name>jeep-body</object-name><br />
<object-name>roof1</object-name><br />
<object-name>roof2</object-name><br />
<object-name>softroof</object-name><br />
<object-name>chassis</object-name><br />
<object-name>chassis.002</object-name><br />
<object-name>Plane</object-name><br />
<object-name>hinge</object-name><br />
<object-name>screen</object-name><br />
<object-name>wiper.L</object-name><br />
<object-name>wiper.R</object-name><br />
<object-name>seat.L</object-name><br />
<object-name>seat.R</object-name><br />
<texture-prop>bombable/texture-corps-path</texture-prop><br />
<transparency><br />
<alpha>1.0</alpha><br />
</transparency><br />
</animation><br />
<br />
<br />
Additionally, if you want to change your object's the livery color programmatically (for instance, if you include a menu item to select different liveries) you can use the following code in the -bombableinclude.xml file (see above) to change all liveries, including damage liveries, that the object uses:<br />
<br />
Example:<br />
liveries = [<br />
"Models/livery_nodamage.png", <br />
"Models/livery_slightdamage.png", <br />
"Models/livery_highdamage.png");<br />
];<br />
<br />
bombable.set_livery (cmdarg().getPath(), liveries); <br />
<br />
You can include liveries for as many different levels of damage (ie, fine gradations of change from undamaged to completely damaged) as you like. For instance:<br />
<br />
<br />
Example:<br />
liveries = [<br />
"Models/livery_nodamage.png", <br />
"Models/livery_barelydamaged.png", <br />
"Models/livery_justslightlydamaged.png", <br />
"Models/livery_alittlemoredamage.png", <br />
"Models/livery_fairlydamaged.png", <br />
"Models/livery_kindadamaged.png",<br />
"Models/livery_prettydamaged.png",<br />
"Models/livery_whoawereintroublenow.png", <br />
"Models/livery_finishedoff.png");<br />
];<br />
<br />
bombable.set_livery (cmdarg().getPath(), liveries); <br />
<br />
<br />
<br />
<br />
==Related content==<br />
* [[Bombable]] <br />
* [[Howto:Nasal in scenery object XML files]]<br />
* [[AI Traffic]]<br />
* [[AI Systems#AI Models]]<br />
* [[Howto:Add submodels]]<br />
* [[Howto:Make an aircraft]]<br />
<br />
[[Category:Aircraft enhancement|Bombable]]<br />
[[Category:Bombable]]<br />
[[Category:Nasal howto|Bombable]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Howto:Adding_Bombable_to_FlightGear_Aircraft&diff=138413Howto:Adding Bombable to FlightGear Aircraft2023-09-22T00:19:36Z<p>Flug: /* Helpful/Needed files */ Added note about needed files in the AI directory of .zip</p>
<hr />
<div>{{Template:Bombable_Navigation}}<br />
<br />
[[File:camel-through-wing.jpg|thumb]]<br />
[[File:spad-vs-camel.jpg|thumb]]<br />
[[File:warthog-down-on-bay-bridge.jpg|thumb]]<br />
How to make a [[FlightGear]] [[aircraft]] work with [[Bombable]].<br />
<br />
When you follow these instructions, you will add the following properties to your aircraft:<br />
<br />
* AI aircraft can fly, maneuver, dodge, and attack the main aircraft. They can avoid the ground (aircraft) or stay on the ground (ships, vehicles) while maneuvering.<br />
* AI and MP aircraft can be damaged by the main aircraft and will stop functioning, crash, catch fire, explode, etc., appropriately when hit by weapons or bombs. MP aircraft will report damage back over MP to the main aircraft, making multiplayer dogfights possible.<br />
* MP aircraft will display weapons shooting whenever the remote MP aircraft is shooting, and report damage back to the main aircraft if the remote MP aircraft shoots or damages your aircraft.<br />
* AI and MP aircraft can have smoke, contrails, and damaged engine smoke<br />
* AI aircraft can automatically follow the main aircraft and attack it with weapons, which will be visible.<br />
* You can design and customize the features per aircraft--to make, for instance, a maneuverable twisty dogfighter, light and easily damaged, or a fast, heavily armored energy fighter with lower maneuverability.<br />
<br />
To make FlightGear aircraft work with Bombable--as the main aircraft, an AI aircraft, and via Multiplayer (MP)--you need three things:<br />
<br />
* Weapons submodels that report impacts properly<br />
* A snippet of code added to the aircraft's -set.xml file to allow communication of Bombable information over Multiplayer<br />
* A section of code in the load/unload section of the Aircraft's XML files that allow Bombable to initialize and give it information about the aircraft needed to operate as an AI or Multiplayer model<br />
<br />
There are several decisions you will have to make about where to put your file and what to name it (see "Where your aircraft files are" below for more info).<br />
<br />
For our example, we'll mod the [https://github.com/FGMEMBERS/F-15E F-15E model from FGUK] to become Bombable. We'll assume:<br />
<br />
* You have [[Bombable]] installed already<br />
* You have the aircraft installed in FGDATA/aircraft/F-15E<br />
* We will add the files/mods needed for AI aircraft to the FGDATA/aircraft/F-15E directories (rather than creating a new, separate FGDATA/AI/Aircraft version of the F-15E)<br />
* We're just going to mod the existing F-15E directories and aircraft without changing and aircraft or file names (rather than creating a separate, new, differently named F-15E-Bombable aircraft)<br />
<br />
== Preliminaries ==<br />
<br />
===Helpful/Needed files===<br />
<br />
* [http://www.flightgear.org/forums/viewtopic.php?t=5742 '''Bombable download''']<br />
*[http://brenthugh.com/flightgear/F-15E.zip '''F-15E model with the mods as described in this article'''] (finished and working version, though still un-polished, as described below, but with several updates and fixes beyond those mentioned in the article)<br />
**''Note that this zip file includes an AI directory with two AI scenarios you can use to fly against the F-15E AI aircraft. You can also use these two scenarios with the current F-15E model linked just below.''<br />
* [https://github.com/FGMEMBERS/F-15E '''Current F-15E model from FGUK'''] - which now includes the Bombable mods as well as a large number of tweaks and updates to the base F-15E model that have been added since 2011.<br />
<br />
=== Note: The original FGUK F-15E, without the Bombable mods, is no longer available. ===<br />
The mods described below were added to the base FGUK F-15E aircraft in about 2011. Since then, FGUK has incorporated the Bombable mods in the F-15E aircraft and then continued to make further enhancements to the F-15E since that time.<br />
<br />
So, unfortunately, you will not be able to download the original F-15E files and then follow the steps below to make your own modded F-15E version. <br />
<br />
Still, you can:<br />
<br />
* Download the [http://brenthugh.com/flightgear/F-15E.zip F-15E model with the mods as described in this article] (2011) to see the end result of the mods, and then read the steps below to see what changes were made to arrive at the Bombable-compatible mod.<br />
* Download the [https://github.com/FGMEMBERS/F-15E current F-15E model from FGUK], which also include the Bombable mods, and see how the mods look in a somewhat more current/updated aircraft model.<br />
<br />
Either way, by looking at either of those aircraft and following the instructions below, you should be able to get good idea about how the original files were modded to become compatible with Bombable.<br />
<br />
''Here is the step-by-step guide to modding the F-15E to become Bombable-compatible:''<br />
<br />
==Step 1: Check the weapons models for impact reporting==<br />
Most FG aircraft that have weapons already work with Bombable at a basic level, right out of the box. That is because FG has a way for aircraft weapons to report their impacts, and most FG aircraft with weapons already use the impact reporting system.<br />
<br />
First, find the XML file that defines the weapons submodels. Typically this is in the aircraft's Models directory (or a subdirectory). It may be named submodels.xml, or F-15-submodels.xml, or guns.xml, or something similar.<br />
<br />
When you open the correct file (FGDATA\Aircraft\F-15E\Models\Effects\guns\submodels.xml, in this case), it will look something like this:<br />
<br />
<PropertyList><br />
<br />
<!-- Gauche --><br />
<submodel><br />
<name>left</name><br />
<model>Aircraft/F-15E/Models/Effects/guns/apibullet-tracer.xml</model><br />
<trigger>controls/armament/trigger</trigger><br />
<speed>2460.0</speed><br />
<repeat>true</repeat><br />
. . . <br />
<br />
[[Howto:_Add_submodels|A complete description of these files is here.]]<br />
<br />
For each <submodel></submodel> section, the areas of interest are the <name> and the <collision> and <impact> areas.<br />
<br />
===Submodel name===<br />
For the submodel name, in FG 2.4.0 we are working around a little FG bug, and Bombable identifies munitions and weapons by their name. <br />
<br />
So it is very important that the name of each weapons submodel include one of the following keywords:<br />
<br />
gun, tracer, bullet, round, cannon, bomb, heavy-bomb, rocket, missile, <br />
MK-81, MK-82, MK-83, MK-84, 5 pound, 25 pound, 100 pound, 150 pound, <br />
250 pound, 500 pound, 1000 pound, 2000 pound<br />
<br />
The name simply needs to include the appropriate keyword in some way--so if you have another name you prefer, just include the keyword at the end, like "MKFD Special Munition (250 pound)".<br />
<br />
In this case, it is a 20 mm gatling gun, so more into cannon range, with projectiles weighing in at about .25 lb. So we simply add "cannon" to each of the submodel names:<br />
<br />
<submodel><br />
<name>left cannon</name><br />
<br />
<submodel><br />
<name>right cannon</name><br />
<br />
===Collision and impact reporting===<br />
The collision and impact areas of this file look like this:<br />
<br />
<collision>true</collision><br />
<collision-report>sim/ai/aircraft/collision/gun</collision-report><br />
<impact>true</impact><br />
<impact-report>sim/ai/aircraft/impact/bullet</impact-report><br />
<br />
[IMPORTANT!] Both <collision> and <impact> should be set to true. <br />
<br />
[IMPORTANT!] <impact-report> should be one of these--the first one is the default, but any is fine:<br />
<br />
ai/models/model-impact<br />
sim/armament/weapons/impact<br />
sim/ai/aircraft/impact/bullet<br />
sim/ai/aircraft/impact/gun<br />
sim/ai/aircraft/impact/cannon<br />
sim/ai/aircraft/impact/bomb<br />
<br />
According to the FG documentation, the <collision-report> setting is no longer used, so you can safely delete it (though it does no harm to leave it be).<br />
<br />
For the F-15E, this section of each <submodel> looks fine, so we just leave it alone.<br />
<br />
We save the file with the changes to the <name> sections.<br />
<br />
==STEP 2: Adding code needed for MultiPlayer to the -set.xml file==<br />
<br />
In the aircraft's -set.XML file, we need to add a <multiplay> section in the <PropertyList><sim> section.<br />
<br />
This gets a bit confusing for two reasons:<br />
<br />
* -set.xml files may (or may not!) load other files, so the <sim> section where we need to add our code may be in the -set.xml file OR in one of the other .xml files the -set.xml file loads<br />
<br />
* There may be existing code in <sim><multiplayer> and so we can simply add our code to that rather than creating a new/different <multiplayer> section.<br />
<br />
In the case of the F-15E, we open FGDATA\Aircraft\F-15E\F-15E_StrikeEagle-set.xml and find:<br />
<br />
<?xml version="1.0"?><br />
<PropertyList><br />
<sim><br />
<br />
<description>F-15E_Strike_Eagle</description><br />
<author>Flying Toaster 3DM, StuartC</author><br />
<status>Alpha 2.01</status><br />
. . .<br />
<br />
[[Howto: Make_an_aircraft#The_-set.xml_file|Find out more about the -set.xml file here.]]<br />
<br />
The <sim> section is what we are looking for.<br />
<br />
We search for <multiplayer> and don't find any existing <multiplayer> section. So we can add our needed <multiplayer> section in any convenient place. Let's place it between the <submodels> and <panel> sections. The added code is in between those two:<br />
<br />
<submodels> <br />
<serviceable type="bool">true</serviceable><br />
<path>Aircraft/F-15E/Models/Effects/guns/submodels.xml</path><br />
<path>Aircraft/F-15E/Models/weapons/loads.xml</path><br />
</submodels><br />
<br />
<!-- Required to make Bombable work over multiplayer --><br />
<!-- String 9 is for Bombable damage/reset messages --><br />
<!-- Int 10,11,... are for various weapons triggers as particular to this aircraft --><br />
<multiplay><br />
<generic><br />
<string n="9" type="string"/><br />
<int n="10" alias="controls/armament/trigger" /><br />
</generic><br />
</multiplay><br />
<br />
<br />
<panel><br />
<visibility archive="y">false</visibility><br />
</panel><br />
<br />
You'll notice we have customized one line: <int n="10" alias="controls/armament/trigger" /><br />
<br />
The alias, controls/armament/trigger, refers to the submodel <trigger> which we observed in Step 1. <br />
<br />
If the aircraft has more than one trigger (for more than one weapon, for example), we can make several triggers like this:<br />
<br />
<int n="10" alias="controls/armament/trigger" /><br />
<int n="11" alias="controls/armament/trigger1" /><br />
<int n="12" alias="controls/armament/trigger2" /><br />
<int n="13" alias="controls/armament/trigger3" /><br />
<int n="14" alias="controls/armament/trigger4" /><br />
<br />
Each alias should correspond to a different <trigger> property in the submodel.xml definitions.<br />
<br />
Save the -set.xml file with the changes.<br />
<br />
==STEP 3: Add the Bombable Nasal code to the Model XML file==<br />
<br />
Bombable needs to have certain code run when the AI or MP aircraft initializes. The code is in [[Nasal]], FlightGear's scripting language. The code gives Bombable needed information about the aircraft (dimensions, vulnerabilities, weapons, etc) and also the code tells Bombable which systems to initialize for this aircraft.<br />
<br />
The simplest way to create this code is to start with a similar aircraft in the Bombable download, then copy and mod the Bombable code as needed.<br />
<br />
There are two steps in this process:<br />
<br />
* Create the -bombableinclude.xml file<br />
* Link the -bombableinclude.xml file to the aircraft's existing model XML file<br />
<br />
===Create the -bombableinclude.xml file=== <br />
In the Bombable distribution, the include files are named [aircraftname]-bombableinclude.xml and are generally found in FGDATA/AI/Aircraft/[aircraftname]/Models.<br />
<br />
In this case, the most similar aircraft in the Bombable distribution is the A-10. If [[Bombable]] is installed, the needed file is in:<br />
<br />
FGDATA\AI\Aircraft\A-10-Bombable\Models\A-10-bombableinclude.xml<br />
<br />
Open the file with a text editor and save it with a new name in your F-15E directory. The new name & directory should be something like:<br />
<br />
FGDATA\Aircraft\F-15E\Models\F-15E_StrikeEagle-bombableinclude.xml<br />
<br />
Now you can open and edit this file. Most changes are quite obvious--change the name, change the dimensions, etc.<br />
<br />
When done, we end up with a file like this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList><br />
<!-- Nasal code --><br />
<nasal><br />
<br />
<br />
<load><br />
<![CDATA[<br />
print("Loading F-15E ", cmdarg().getPath());<br />
<br />
var nodeName = cmdarg().getPath(); <br />
<br />
##checks whether it has been initialized already; if so, just return<br />
if ( bombable.check_overall_initialized (nodeName) ) return;<br />
<br />
<br />
<br />
<br />
############################################<br />
#FUNCTION object_init, INITIALIZER<br />
var object_init = func() {<br />
# Datas of this object are under: cmdarg().getPath()<br />
var thisNodeName = cmdarg().getPath();<br />
var thisNode = props.globals.getNode(thisNodeName);<br />
# Add some useful nodes<br />
<br />
<br />
<br />
########################################################################<br />
########################################################################<br />
# INITIALIZE BOMBABLE<br />
# <br />
# Initialize constants and main routines for maintaining altitude<br />
# relative to ground-level, relocating after file/reset, and <br />
# creating bombable/shootable objects.<br />
# <br />
# These routines are found in FG/nasal/bombable.nas<br />
# <br />
######################################################################## <br />
# INITIALIZE BOMBABLE Object<br />
# This object will be slurped in the object's node as a child<br />
# node named "bombable". <br />
# All distances are specified in meters.<br />
# All altitudes are relative to current ground level at the object's <br />
# location<br />
# <br />
<br />
thisNodeName = cmdarg().getPath(); <br />
<br />
var bombableObject = { <br />
<br />
<br />
objectNodeName : thisNodeName,<br />
objectNode : props.globals.getNode(thisNodeName),<br />
updateTime_s : 1/3, #time, in seconds, between the updates that <br />
#keep the object at its AGL. Tradeoff is high-speed updates look more<br />
#realistic but slow down the framerate/cause jerkiness. Faster-moving<br />
#objects will need more frequent updates to look realistic.<br />
#update time faster than about 1/3 seems to have a noticeable effect<br />
#on frame rate <br />
<br />
<br />
######################################### <br />
# ALTITUDE DEFINITIONS<br />
# <br />
altitudes : { <br />
wheelsOnGroundAGL_m : 1 , #altitude correction to add to your aircraft or ship that is needed to put wheels on ground (or, for a ship, make it float in the water at the correct level). For most objects this is 0 but some models need a small correction to place them exactly at ground level<br />
<br />
minimumAGL_m : 300, #minimum altitude above ground level this object is allowed to fly<br />
maximumAGL_m : 50000, #maximum altitude AGL this object is allowed to fly, ie, operational ceiling <br />
crashedAGL_m : 0.6, #altitude AGL when crashed. Ships will sink to this level, aircraft or vehicles will sink into the ground as landing gear collapses or tires deflate. Should be negative, even just -0.001.<br />
},<br />
# <br />
#########################################<br />
# VELOCITIES DEFINITIONS<br />
# <br />
velocities : { <br />
maxSpeedReduce_percent : 0.5, #max % to reduce speed, per step, when damaged<br />
minSpeed_kt : 112, #minimum speed to reduce to when damaged. Ground vehicles and ships might stop completely when damaged but aircraft will need a minimum speed so they keep moving until they hit the ground.<br />
cruiseSpeed_kt : 550, #cruising speed, typical/optimal cruising speed, V C for aircraft<br />
<br />
attackSpeed_kt : 900, #typical/optimal speed when aggressively attacking or evading, in<br />
#level flight for aircraft<br />
<br />
maxSpeed_kt : 1400 , #Maximum possible speed under dive or downhill conditions, V NE for aircraft<br />
<br />
damagedAltitudeChangeMaxRate_meterspersecond : 30, #max rate to sink or fly downwards when damaged, in meters/second<br />
<br />
#The terminal velocities are calculated by opening the 'real' AC <br />
#in FG, level flight, full throttle, then putting<br />
#the AC at different angles of attack with the autopilot,<br />
#and noting the terminal airspeed & vertical speed velocities.<br />
#For best results, do it near sea level, under 5000 feet altitude.<br />
#One or two each of climb & dive velocities are probably sufficient.<br />
#However if you do more we may be able to use the more precise<br />
#data in the future.<br />
#<br />
#Note that these are intended to be true airspeed whereas FG's<br />
#/velocities/airspeed-kt reports indicated airspeed, so some <br />
#conversion or reference to groundspeed-kt is needed.<br />
# <br />
#In FG /velocities/groundspeed-kt is equal (or close <br />
#to equal, except for wind . . .) true airspeed when pitch=0 <br />
#but as pitch increases or decreases that will change.<br />
# <br />
diveTerminalVelocities: {<br />
point1: { airspeed_kt : 1060, vertical_speed_fps : - 337},<br />
point2: { airspeed_kt : 1230, vertical_speed_fps : - 755},<br />
<br />
},<br />
<br />
climbTerminalVelocities: {<br />
point1: { airspeed_kt : 468, vertical_speed_fps : 236},<br />
point2: { airspeed_kt : 843, vertical_speed_fps : 251},<br />
#point3: { airspeed_kt : 1100, vertical_speed_fps : 161},<br />
<br />
},<br />
<br />
},<br />
# <br />
#########################################<br />
# EVASION DEFINITIONS<br />
# <br />
# The evasion system makes the AI aircraft dodge when they come under<br />
# fire. <br />
evasions : { <br />
dodgeDelayMax_sec : 15, #max time to delay/wait between dodges<br />
dodgeDelayMin_sec : 5, #minimum time to delay/wait between dodges<br />
dodgeMax_deg : 88, #Max amount to turn when dodging<br />
#90 degrees = instant turn, unrealistic<br />
#up to 80 is usually OK, somewhere in 80-85 starts to be unrealistically fast<br />
#>85 is usually very unrealistic. You must test this in your scenario, however.<br />
<br />
dodgeMin_deg : 83, #minimum amount to turn when dodging <br />
rollRateMax_degpersec : 300, #you can figure this out by rolling the corresponding FG aircraft and timing a 180 or 360 deg roll <br />
dodgeROverLPreference_percent : 50, # Preference for right turns vs. left when dodging. 90% means 90% right turns, 50% means 50% right turns.<br />
dodgeAltMin_m : -8000, #Aircraft will begin to move up or down <br />
dodgeAltMax_m : 8000, #Max & Min are relative to current alt <br />
dodgeVertSpeedClimb_mps : 1500, #Max speed to climb when evading<br />
dodgeVertSpeedDive_mps : 1500, #Max speed to dive when evading <br />
},<br />
# <br />
#########################################<br />
# ATTACK DEFINITIONS<br />
# <br />
# The attack system makes the AI aircraft turn and fly towards <br />
# other aircraft <br />
attacks : { <br />
maxDistance_m : 30000, #max distance to turn & attack main aircraft<br />
minDistance_m : 4000, #min distance to turn & attack main aircraft, ie, fly away this far before turning to attack again<br />
continueAttackAngle_deg : 80, #when within minDistance_m, the aircraft will continue to turn towards the main aircraft and attack *if* if the angle is less than this amount from dead ahead<br />
altitudeHigherCutoff_m : 30000, # will attack the main aircraft unless this amount higher than it or more<br />
altitudeLowerCutoff_m : 30000, # will attack the main aircraft unless this amount lower than it or more<br />
climbPower : 8000, # How powerful the aircraft is when climbing during an attack; 4000 would be typical for, say a Zero--scale accordingly for others; higher is stronger<br />
divePower : 10000, # How powerful the aircraft is when diving during and attack; 6000 typical of a Zero--could be much more than climbPower if the aircraft is a weak climber but a strong diver <br />
rollMin_deg : 82, #when turning on attack, roll to this angle min<br />
#for sedate, Cessna-like manuevers make rollMin low. If you want an aggressive,<br />
#attacking, aiming fighter keep it close to rollMax, or even almost equal to rollMax <br />
rollMax_deg : 87, #when turning on attack, roll to this angle max<br />
#90 degrees = instant turn, unrealistic<br />
#up to 80 might be OK, depending on aircraft & speed; somewhere in 80-85 starts to be unrealistically fast<br />
#>85 is usually very unrealistic. You must test this in your scenario, however.<br />
rollRateMax_degpersec : 120, #you can figure this out by rolling the corresponding FG aircraft and timing a 180 or 360 deg roll <br />
attackCheckTime_sec : 10, # check for need to attack/correct course this often <br />
attackCheckTimeEngaged_sec : 0.5, # once engaged with enemy, check/update course this frequently<br />
<br />
},<br />
<br />
# <br />
#########################################<br />
# WEAPONS DEFINITIONS<br />
# <br />
# The weapons system makes the AI aircraft fire on the main aircraft <br />
# You can define any number of weapons--just enclose each in curly brackets<br />
# and separate with commas (,). <br />
weapons : {<br />
front_gun : #internal name - this can be any name you want; must be a valid nasal variable name<br />
{ <br />
name : "Machine Gun", # name presented to users, ie in on-screen messages<br />
maxDamage_percent : 5, # maximum percentage damage one hit from the aircraft's main weapon/machine guns will do to an opponent<br />
maxDamageDistance_m : 2000, # maximum distance at which the aircrafts main weapon/maching guns will be able to damage an opponent<br />
weaponAngle_deg : { heading: 0, elevation: 0 }, # direction the aircraft's main weapon is aimed. <br />
# 0,0 = straight ahead, 90,0=directly right, 0,90=directly up, 0,180=directly back, etc.<br />
weaponOffset_m : {x:2, y:0, z:0}, # Offset of the weapon from the main aircraft center<br />
weaponSize_m : {start:.1, end:.1}, # Visual size of the weapon's projectile, in meters, at start & end of its path<br />
<br />
}, <br />
sidewinder_missile : #internal name - this can be any name you want; must be a valid nasal variable name<br />
{ <br />
name : "Sidewinder guided missile", # name presented to users, ie in on-screen messages<br />
maxDamage_percent : 40, # maximum percentage damage one hit from the aircraft's main weapon/machine guns will do to an opponent<br />
maxDamageDistance_m : 6000, # maximum distance at which the aircrafts main weapon/machine guns will be able to damage an opponent<br />
weaponAngle_deg : { heading: 0, elevation: 0 }, # direction the aircraft's main weapon is aimed. <br />
# 0,0 = straight ahead, 90,0=directly right, 0,90=directly up, 0,180=directly back, etc.<br />
weaponOffset_m : {x:2, y:0, z:0}, # Offset of the weapon from the main aircraft center<br />
weaponSize_m : {start:1, end:1}, # Visual size of the weapon's projectile, in meters, at start & end of its path<br />
<br />
}, <br />
<br />
<br />
}, <br />
<br />
# <br />
#########################################<br />
# DIMENSION DEFINITIONS<br />
#<br />
# All dimensions are in meters<br />
# <br />
# <br />
dimensions : { <br />
width_m : 17.53, #width of your object, ie, for aircraft, wingspan<br />
length_m : 16.26, #length of your object, ie, for aircraft, distance nose to tail<br />
height_m : 4.47, #height of your object, ie, for aircraft ground to highest point when sitting on runway<br />
<br />
damageRadius_m : 8, #typically 1/2 the longest dimension of the object. Hits within this distance of the <br />
#center of object have some possibility of damage<br />
vitalDamageRadius_m : 2, #typically the radius of the fuselage or cockpit or other most <br />
# vital area at the center of the object. Always smaller than damageRadius_m<br />
<br />
crashRadius_m : 6, #It's a crash if the main aircraft hits in this area.<br />
<br />
},<br />
#<br />
#########################################<br />
# VULNERABILITIES DEFINITIONS <br />
#<br />
vulnerabilities : { <br />
damageVulnerability : 9, #Vulnerability to damage from armament, 1=normal M1 tank; higher to make objects easier to kill and lower to make them more difficult. This is a multiplier, so 5 means 5X easier to kill than an M1, 1/5 means 5X harder to kill. <br />
<br />
engineDamageVulnerability_percent : 6, #Chance that a small-caliber machine-gun round will damage the engine. <br />
<br />
fireVulnerability_percent : 5, #Vulnerability to catching on fire. 100% means even the slightest impact will set it on fire; 20% means quite difficult to set on fire; 0% means set on fire only when completely damaged; -1% means never set on fire. <br />
<br />
fireDamageRate_percentpersecond : .1, #Amount of damage to add, per second, when on fire. 100%=completely damaged. Warthog is relatively damage-resistant.<br />
<br />
fireExtinguishMaxTime_seconds : 80, #Once a fire starts, for this many seconds there is a chance to put out the fire; fires lasting longer than this won't be put out until the object burns out.<br />
<br />
fireExtinguishSuccess_percentage : 45, #Chance of the crew putting out the fire within the MaxTime above. Warthoge is relatively damage-resistant.<br />
<br />
explosiveMass_kg : 27772 , #mass of the object in KG, but give at least a 2-10X bonus to anything carrying flammables or high explosives.<br />
},<br />
#<br />
#########################################<br />
# LIVERY DEFINITIONS<br />
#<br />
# Path to livery files to use at different damage levels.<br />
# Path is relative to the AI aircraft's directory.<br />
# The object will start with the first livery listed and <br />
# change to succeeding liveries as the damage<br />
# level increases. The final livery should indicate full damage/<br />
# object destroyed. <br />
# <br />
# If you don't want to specify any special liveries simply set <br />
# damageLivery : nil and the object's normal livery will be used. <br />
# <br />
damageLiveries : {<br />
damageLivery : [ ] <br />
},<br />
<br />
};<br />
<br />
#########################################<br />
# INITIALIZE ROUTINES<br />
# <br />
# OVERALL INITIALIZER: Needed to make all the others work<br />
bombable.initialize ( bombableObject );<br />
#<br />
# LOCATION: Relocate object to maintain its position after file/reset <br />
# (best not used for airplanes)<br />
# bombable.location_init ( thisNodeName );<br />
#<br />
# GROUND: Keep object at altitude relative to ground level<br />
bombable.ground_init ( thisNodeName );<br />
#<br />
# ATTACK: Make the object attack the main aircraft <br />
bombable.attack_init ( thisNodeName );<br />
#<br />
# WEAPONS: Make the object shoot the main aircraft <br />
bombable.weapons_init ( thisNodeName ); <br />
#<br />
# BOMBABLE: Make the object bombable/damageable <br />
bombable.bombable_init ( thisNodeName );<br />
#<br />
# SMOKE/CONTRAIL: Start a flare, contrail, smoke trail, or exhaust <br />
# trail for the object.<br />
# Smoke types available: flare, jetcontrail, pistonexhaust, smoketrail,<br />
# damagedengine <br />
bombable.startSmoke("jetcontrail", thisNodeName );<br />
#F-15E already has contrails, we're leaving this out<br />
#<br />
# END INITIALIZE BOMBABLE<br />
########################################################################<br />
######################################################################## <br />
<br />
<br />
<br />
}<br />
<br />
object_init();<br />
]]><br />
</load><br />
<unload><br />
<![CDATA[<br />
print("Unload F-15E.");<br />
var nodeName= cmdarg().getPath(); <br />
bombable.de_overall_initialize( nodeName );<br />
bombable.initialize_del( nodeName );<br />
bombable.ground_del( nodeName );<br />
bombable.location_del (nodeName);<br />
bombable.bombable_del( nodeName );<br />
bombable.attack_del( nodeName );<br />
bombable.weapons_del (nodeName); <br />
# </unload><br />
<br />
]]><br />
</unload><br />
</nasal> <br />
<br />
</PropertyList><br />
<br />
Save this file with the name you have chosen ( FGDATA\Aircraft\F-15E\Models\F-15E_StrikeEagle-bombableinclude.xml).<br />
<br />
===Link the -bombableinclude.xml file to the existing F-15 model file===<br />
<br />
Now that we have created the -bombableinclude.xml file, we need to set up the aircraft to load the file on startup.<br />
<br />
AI scenarios (and MP aircraft) load the aircraft's model file. So we need to locate that file and include the new -bombableinclude.xml file in it.<br />
<br />
Where is the model file? Look in the aircraft's -set.xml file. In that file will be a section called <model>. For the F-15E it looks like this:<br />
<br />
<model><br />
<path>Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</path><br />
</model><br />
<br />
So Aircraft/F-15E/Models/F-15E_StrikeEagle.xml is our model file. <br />
<br />
<br />
Load Aircraft/F-15E/Models/F-15E_StrikeEagle.xml in a text editor. At the beginning of that file you will find this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList><br />
<br />
Change it to this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList include="F-15E_StrikeEagle-bombableinclude.xml"><br />
<br />
Save the file.<br />
<br />
===Notes===<br />
* The statement include="F-15E_StrikeEagle-bombableinclude.xml" indicates that F-15E_StrikeEagle-bombableinclude.xml will be in the same directory as F-15E_StrikeEagle.xml. That directory is Aircraft/F-15E/Models -- so make sure that the -bombableinclude.xml file is indeed in that directory!<br />
<br />
* Model files can have only ONE Nasal <load> section and one <unload> section.<br />
<br />
If you have more than one, the second and subsequent <load>/<unload> sections are ignored.<br />
<br />
The problem? Your aircraft may already have a <load> or <unload> section. When you add the Bombable code, one of the two <load> sections (the pre-existing one or Bombable's) will be ignored.<br />
<br />
The solution is to combine the two <load> sections into one, and the same with the <unload> sections. You'll need to know a little about [[Nasal]] programming to do anything complicated, but as a rule you can just copy/paste whatever is in the aircraft's <load> section to the start of Bombable's <load> section, and the same with <unload>.<br />
<br />
* You'll notice the Nasal code starts with ''<![CDATA['' and ends with '']]>''. That is needed to make Nasal code work within XML files. [http://www.w3schools.com/xml/xml_cdata.asp CDATA usage is explained here.]<br />
<br />
==STEP 4. Add to an AI Scenario==<br />
Now we can add the F-15E to an AI scenario.<br />
<br />
Create a file named F-15E-demo.xml and save it in your FGDATA/AI directory.<br />
<br />
Most of the entries in the scenario file are self-explanatory. For the <model> entry you'll need the path of the same model file for the F-15 that we located in Step 3--which is Aircraft/F-15E/Models/F-15E_StrikeEagle.xml.<br />
<br />
Here is how the file should look when you are done:<br />
<br />
<?xml version="1.0"?><br />
<PropertyList><br />
<scenario><br />
<description>My new F-15E scenario. Starts at KSFO! </description><br />
<br />
<entry><br />
<type>aircraft</type><br />
<callsign>Jones</callsign><br />
<name>F15E Leader</name><br />
<model type="string">Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model><br />
<latitude type="double">37.608720</latitude><br />
<longitude type="double">-122.3076</longitude><br />
<altitude type="double">309</altitude><br />
<speed>280.0</speed><br />
<heading type="double">192</heading><br />
</entry><br />
<br />
<entry><br />
<type>aircraft</type><br />
<callsign>Cooper</callsign><br />
<name>F15E Wingman</name><br />
<model type="string">Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model><br />
<latitude type="double">37.608200</latitude><br />
<longitude type="double">-122.2988</longitude><br />
<altitude type="double">309</altitude><br />
<speed>270.0</speed><br />
<heading type="double">192</heading><br />
</entry><br />
<scenario><br />
<br />
</PropertyList><br />
<br />
Again, save as FGDATA/AI/F-15E-demo.xml. When you start FGRun next time, F-15E-demo will be listed as one of the scenario file options. (You may need to quit and re-start FGRun.)<br />
<br />
==STEP 5. Troubleshooting==<br />
OK, we're done. Time to fly our new aircraft in our new scenario!<br />
<br />
Oh, yeah . . . we just followed a very complicated process with numerous steps that could go wrong. Maybe we'd better test a bit first.<br />
<br />
Start Flightgear. Using FGRun:<br />
<br />
1. Choose ''UFO bombable'' as the main aircraft (best for testing . . . )<br />
2. Airport KSFO<br />
3. Scenario F-15-demo (which we just created--if saved correctly in the FGDATA/AI directory, it will show up in the scenario list of FGRun)<br />
4. Click "Run"<br />
5. Closely watch the command console as FG starts. You may pick up important errors in XML files and/or Nasal code.<br />
6. You should see<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
<br />
Uh-oh. There is our first error. f-15-demo.xml, line 31, column 2, I have "<scenario>" rather than "</scenario>".<br />
<br />
I fix, save the fixed file, and re-start. Now I get:<br />
<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
* Failed to load XML: . . . F-15E-StrikeEagle-bombableinclude.xml<br />
<br />
OK, this is typical. There is a typo or stray character on the .xml file . . . or something.<br />
<br />
After a few minutes of trying different things, I discover I've made a typo:<br />
<br />
* In \Aircraft\F-15E\Models\F-15E_StrikeEagle.xml is this line:<br />
<PropertyList include="F-15E_StrikeEagle-bombableinclude.xml"><br />
* But I've saved the file as <br />
FGDATA/Aircraft/F-15E/F-15-StrikeEagle-bombableinclude.xml<br />
<br />
OK, that one little "E" made all the difference. I change the filename to match what's in the -set.xml file and try again.<br />
<br />
And finally:<br />
<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
* Loading F-15E /ai/models/aircraft<br />
* Loading F-15E /ai/models/aircraft[1]<br />
* A bunch of other Bombable messages showing the aircraft initializing (I have Bombable menu/Debug turned on, which is helpful at this stage)<br />
* A bunch of error messages showing various animations and systems not load (ahhh . . . that's why we create stripped-down versions of aircraft in the AI/Aircraft directory--a completely separate and even longer article).<br />
<br />
I open Equipment/Maps, click "traffic", see the two aircraft "Jones" and "Cooper", track them down with the UFO, they show proper smoke trails, I shoot at them, I shoot them down. It works!<br />
<br />
Success!<br />
<br />
Well, except . . . are they flying realistically? Climbing, turning, diving, shooting? Are they taking damage realistically? Does it work properly under Multiplayer?<br />
<br />
Here is where you spend hours researching real F-15s, flying against the AI models with the UFO and other aircraft, tweaking parameters in the -bombableinclude.xml file, and so on and on.<br />
<br />
You're just getting started. <br />
<br />
Good luck!<br />
<br />
===Testing/parsing XML files===<br />
One final tip: XML files are extremely persnickety. Just one wrong character can make an entire file fail to load. <br />
<br />
The best/easiest way to test XML files is load them in Internet Explorer. It will parse the XML file and display any errors it finds. (If you don't have access to IE there are other XML parsers available.) This is far easier and faster than starting and re-starting FG repeatedly, and IE gives better, more informative error messages as well.<br />
<br />
==IMPORTANT POSTSCRIPT: Where your aircraft files are==<br />
An important detail in getting Bombable to work with aircraft over AI and MP is the directories you store the files in and the names you choose to use for them.<br />
<br />
FlightGear stores aircraft and AI aircraft files in at least two different places.<br />
<br />
In a typical FG installation, in your FGDATA folder, you will find<br />
<br />
* FGDATA/Aircraft<br />
* FGDATA/AI/Aircraft<br />
<br />
FGDATA/Aircraft holds files for the main aircraft whereas FGDATA/AI/Aircraft holds files for AI and MP aircraft.<br />
<br />
AI/MP aircraft don't have all the features of main aircraft, so you might find the very same aircraft in FGDATA/Aircraft and in FGDATA/AI/Aircraft--but the one in FGDATA/AI/Aircraft will be very stripped down, fewer files, smaller, and less complex.<br />
<br />
When building a [[AI_Systems#AI_Models|FlightGear AI scenario]], you can specify the exact path and filename of the file FlightGear looks for. You can specify a file in the FGDATA/Aircraft directory, or in the FGDATA/AI/Aircraft, or really anywhere within the FGDATA directory that you like. Examples:<br />
<br />
<model type="string">AI/Aircraft/sopwithCamel-Bombable/Models/sopwithCamel-model.xml</model> <br />
<br />
OR<br />
<br />
<model type="string">Aircraft/sopwithCamel-Bombable/Models/sopwithCamel-model.xml</model> <br />
<br />
When loading an MP aircraft, FlightGear first looks for the (typically smaller/simpler) aircraft file in FGDATA/AI/Aircraft.<br />
<br />
If it doesn't find the aircraft there, it then searches FGDATA/Aircraft.<br />
<br />
===How FG matches Multiplayer Aircraft with your local AI aircraft models===<br />
<br />
As of version 2.4.0, when FG is looking for the local AI aircraft model to display for a remote aircraft over Multiplayer, FG searches first the AI Aircraft directories, then the Aircraft directories.<br />
<br />
It searches for a match by looking for the file with a name exactly matching the MP aircraft's model (this is typically in the aircraft's Models subdirectory and ends with .ac, though this may vary) and if that fails, FG looks for a matching -set.xml file.<br />
<br />
The important points for making AI models that will work over MP with Bombable: <br />
<br />
* Make sure the main aircraft and the AI version of the aircraft have the exact same names for the aircraft's model file and the aircraft's -set.xml<br />
<br />
* If you're modding an existing but non-bombable-compatible aircraft, you need to decide whether you're going to leave all the directories, model XML file names, and -set.xml file names the same as the standard flightgear aircraft (leading to possible frustration as your version overwrites existing aircraft files on users hard drivers) OR rename the aircraft's directory, -set.xml file name, and model file name (which means you're going to have to do a bit of work on the aircraft's XML files to make sure everything still works with all those name changes.<br />
<br />
* You can create a separate, stripped down AI version of the aircraft in the FGDATA/AI/Aircraft directory and add the Bombable additions to it (more work for you but smaller/quicker download and easier on the memory and framerate in FG) OR you can simply add all the Bombable additions to the main aircraft directory in FGDATA/Aircraft.<br />
<br />
Bombable will work with any of those options--so it is really up to you.<br />
<br />
==EXTRA: Making livery change with damage==<br />
<br />
Once you have Bombable working with your aircraft there is a bonus: bombable.nas will handle setting the livery colors and<br />
automatically changing them as the object becomes damaged. <br />
<br />
For an example of how this works and looks, take a look at the Bombable scenarios involving the M1 tank and the Jeep.<br />
<br />
For this to work your model must have different liveries available<br />
and then animate the liveries so that the texture used is the one shown<br />
in this path: /ai/model/model[X]/bombable/texture-corps-path. The /ai/model/model[X]/ part is assumed for AI craft so you need to add <texture-prop>bombable/texture-corps-path</texture-prop> in the right place of your XML file. <br />
<br />
Example from Jeep.xml in the jeep-bombable directory:<br />
<br />
<animation><br />
<type>material</type><br />
<object-name>jeep-body</object-name><br />
<object-name>roof1</object-name><br />
<object-name>roof2</object-name><br />
<object-name>softroof</object-name><br />
<object-name>chassis</object-name><br />
<object-name>chassis.002</object-name><br />
<object-name>Plane</object-name><br />
<object-name>hinge</object-name><br />
<object-name>screen</object-name><br />
<object-name>wiper.L</object-name><br />
<object-name>wiper.R</object-name><br />
<object-name>seat.L</object-name><br />
<object-name>seat.R</object-name><br />
<texture-prop>bombable/texture-corps-path</texture-prop><br />
<transparency><br />
<alpha>1.0</alpha><br />
</transparency><br />
</animation><br />
<br />
<br />
Additionally, if you want to change your object's the livery color programmatically (for instance, if you include a menu item to select different liveries) you can use the following code in the -bombableinclude.xml file (see above) to change all liveries, including damage liveries, that the object uses:<br />
<br />
Example:<br />
liveries = [<br />
"Models/livery_nodamage.png", <br />
"Models/livery_slightdamage.png", <br />
"Models/livery_highdamage.png");<br />
];<br />
<br />
bombable.set_livery (cmdarg().getPath(), liveries); <br />
<br />
You can include liveries for as many different levels of damage (ie, fine gradations of change from undamaged to completely damaged) as you like. For instance:<br />
<br />
<br />
Example:<br />
liveries = [<br />
"Models/livery_nodamage.png", <br />
"Models/livery_barelydamaged.png", <br />
"Models/livery_justslightlydamaged.png", <br />
"Models/livery_alittlemoredamage.png", <br />
"Models/livery_fairlydamaged.png", <br />
"Models/livery_kindadamaged.png",<br />
"Models/livery_prettydamaged.png",<br />
"Models/livery_whoawereintroublenow.png", <br />
"Models/livery_finishedoff.png");<br />
];<br />
<br />
bombable.set_livery (cmdarg().getPath(), liveries); <br />
<br />
<br />
<br />
<br />
==Related content==<br />
* [[Bombable]] <br />
* [[Howto:Nasal in scenery object XML files]]<br />
* [[AI Traffic]]<br />
* [[AI Systems#AI Models]]<br />
* [[Howto:Add submodels]]<br />
* [[Howto:Make an aircraft]]<br />
<br />
[[Category:Aircraft enhancement|Bombable]]<br />
[[Category:Bombable]]<br />
[[Category:Nasal howto|Bombable]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Howto:Adding_Bombable_to_FlightGear_Aircraft&diff=138412Howto:Adding Bombable to FlightGear Aircraft2023-09-22T00:01:19Z<p>Flug: /* Step 1: Check the weapons models for impact reporting */</p>
<hr />
<div>{{Template:Bombable_Navigation}}<br />
<br />
[[File:camel-through-wing.jpg|thumb]]<br />
[[File:spad-vs-camel.jpg|thumb]]<br />
[[File:warthog-down-on-bay-bridge.jpg|thumb]]<br />
How to make a [[FlightGear]] [[aircraft]] work with [[Bombable]].<br />
<br />
When you follow these instructions, you will add the following properties to your aircraft:<br />
<br />
* AI aircraft can fly, maneuver, dodge, and attack the main aircraft. They can avoid the ground (aircraft) or stay on the ground (ships, vehicles) while maneuvering.<br />
* AI and MP aircraft can be damaged by the main aircraft and will stop functioning, crash, catch fire, explode, etc., appropriately when hit by weapons or bombs. MP aircraft will report damage back over MP to the main aircraft, making multiplayer dogfights possible.<br />
* MP aircraft will display weapons shooting whenever the remote MP aircraft is shooting, and report damage back to the main aircraft if the remote MP aircraft shoots or damages your aircraft.<br />
* AI and MP aircraft can have smoke, contrails, and damaged engine smoke<br />
* AI aircraft can automatically follow the main aircraft and attack it with weapons, which will be visible.<br />
* You can design and customize the features per aircraft--to make, for instance, a maneuverable twisty dogfighter, light and easily damaged, or a fast, heavily armored energy fighter with lower maneuverability.<br />
<br />
To make FlightGear aircraft work with Bombable--as the main aircraft, an AI aircraft, and via Multiplayer (MP)--you need three things:<br />
<br />
* Weapons submodels that report impacts properly<br />
* A snippet of code added to the aircraft's -set.xml file to allow communication of Bombable information over Multiplayer<br />
* A section of code in the load/unload section of the Aircraft's XML files that allow Bombable to initialize and give it information about the aircraft needed to operate as an AI or Multiplayer model<br />
<br />
There are several decisions you will have to make about where to put your file and what to name it (see "Where your aircraft files are" below for more info).<br />
<br />
For our example, we'll mod the [https://github.com/FGMEMBERS/F-15E F-15E model from FGUK] to become Bombable. We'll assume:<br />
<br />
* You have [[Bombable]] installed already<br />
* You have the aircraft installed in FGDATA/aircraft/F-15E<br />
* We will add the files/mods needed for AI aircraft to the FGDATA/aircraft/F-15E directories (rather than creating a new, separate FGDATA/AI/Aircraft version of the F-15E)<br />
* We're just going to mod the existing F-15E directories and aircraft without changing and aircraft or file names (rather than creating a separate, new, differently named F-15E-Bombable aircraft)<br />
<br />
== Preliminaries ==<br />
<br />
===Helpful/Needed files===<br />
<br />
* [http://www.flightgear.org/forums/viewtopic.php?t=5742 Bombable download]<br />
*[http://brenthugh.com/flightgear/F-15E.zip F-15E model with the mods as described in this article] (finished and working version, though still un-polished, as described below, but with several updates and fixes beyond those mentioned in the article)<br />
* [https://github.com/FGMEMBERS/F-15E Current F-15E model from FGUK] - which now includes the Bombable mods as well as a large number of tweaks and updates to the base F-15E model that have been added since 2011.<br />
<br />
=== Note: The original FGUK F-15E, without the Bombable mods, is no longer available. ===<br />
The mods described below were added to the base FGUK F-15E aircraft in about 2011. Since then, FGUK has incorporated the Bombable mods in the F-15E aircraft and then continued to make further enhancements to the F-15E since that time.<br />
<br />
So, unfortunately, you will not be able to download the original F-15E files and then follow the steps below to make your own modded F-15E version. <br />
<br />
Still, you can:<br />
<br />
* Download the [http://brenthugh.com/flightgear/F-15E.zip F-15E model with the mods as described in this article] (2011) to see the end result of the mods, and then read the steps below to see what changes were made to arrive at the Bombable-compatible mod.<br />
* Download the [https://github.com/FGMEMBERS/F-15E current F-15E model from FGUK], which also include the Bombable mods, and see how the mods look in a somewhat more current/updated aircraft model.<br />
<br />
Either way, by looking at either of those aircraft and following the instructions below, you should be able to get good idea about how the original files were modded to become compatible with Bombable.<br />
<br />
''Here is the step-by-step guide to modding the F-15E to become Bombable-compatible:''<br />
<br />
==Step 1: Check the weapons models for impact reporting==<br />
Most FG aircraft that have weapons already work with Bombable at a basic level, right out of the box. That is because FG has a way for aircraft weapons to report their impacts, and most FG aircraft with weapons already use the impact reporting system.<br />
<br />
First, find the XML file that defines the weapons submodels. Typically this is in the aircraft's Models directory (or a subdirectory). It may be named submodels.xml, or F-15-submodels.xml, or guns.xml, or something similar.<br />
<br />
When you open the correct file (FGDATA\Aircraft\F-15E\Models\Effects\guns\submodels.xml, in this case), it will look something like this:<br />
<br />
<PropertyList><br />
<br />
<!-- Gauche --><br />
<submodel><br />
<name>left</name><br />
<model>Aircraft/F-15E/Models/Effects/guns/apibullet-tracer.xml</model><br />
<trigger>controls/armament/trigger</trigger><br />
<speed>2460.0</speed><br />
<repeat>true</repeat><br />
. . . <br />
<br />
[[Howto:_Add_submodels|A complete description of these files is here.]]<br />
<br />
For each <submodel></submodel> section, the areas of interest are the <name> and the <collision> and <impact> areas.<br />
<br />
===Submodel name===<br />
For the submodel name, in FG 2.4.0 we are working around a little FG bug, and Bombable identifies munitions and weapons by their name. <br />
<br />
So it is very important that the name of each weapons submodel include one of the following keywords:<br />
<br />
gun, tracer, bullet, round, cannon, bomb, heavy-bomb, rocket, missile, <br />
MK-81, MK-82, MK-83, MK-84, 5 pound, 25 pound, 100 pound, 150 pound, <br />
250 pound, 500 pound, 1000 pound, 2000 pound<br />
<br />
The name simply needs to include the appropriate keyword in some way--so if you have another name you prefer, just include the keyword at the end, like "MKFD Special Munition (250 pound)".<br />
<br />
In this case, it is a 20 mm gatling gun, so more into cannon range, with projectiles weighing in at about .25 lb. So we simply add "cannon" to each of the submodel names:<br />
<br />
<submodel><br />
<name>left cannon</name><br />
<br />
<submodel><br />
<name>right cannon</name><br />
<br />
===Collision and impact reporting===<br />
The collision and impact areas of this file look like this:<br />
<br />
<collision>true</collision><br />
<collision-report>sim/ai/aircraft/collision/gun</collision-report><br />
<impact>true</impact><br />
<impact-report>sim/ai/aircraft/impact/bullet</impact-report><br />
<br />
[IMPORTANT!] Both <collision> and <impact> should be set to true. <br />
<br />
[IMPORTANT!] <impact-report> should be one of these--the first one is the default, but any is fine:<br />
<br />
ai/models/model-impact<br />
sim/armament/weapons/impact<br />
sim/ai/aircraft/impact/bullet<br />
sim/ai/aircraft/impact/gun<br />
sim/ai/aircraft/impact/cannon<br />
sim/ai/aircraft/impact/bomb<br />
<br />
According to the FG documentation, the <collision-report> setting is no longer used, so you can safely delete it (though it does no harm to leave it be).<br />
<br />
For the F-15E, this section of each <submodel> looks fine, so we just leave it alone.<br />
<br />
We save the file with the changes to the <name> sections.<br />
<br />
==STEP 2: Adding code needed for MultiPlayer to the -set.xml file==<br />
<br />
In the aircraft's -set.XML file, we need to add a <multiplay> section in the <PropertyList><sim> section.<br />
<br />
This gets a bit confusing for two reasons:<br />
<br />
* -set.xml files may (or may not!) load other files, so the <sim> section where we need to add our code may be in the -set.xml file OR in one of the other .xml files the -set.xml file loads<br />
<br />
* There may be existing code in <sim><multiplayer> and so we can simply add our code to that rather than creating a new/different <multiplayer> section.<br />
<br />
In the case of the F-15E, we open FGDATA\Aircraft\F-15E\F-15E_StrikeEagle-set.xml and find:<br />
<br />
<?xml version="1.0"?><br />
<PropertyList><br />
<sim><br />
<br />
<description>F-15E_Strike_Eagle</description><br />
<author>Flying Toaster 3DM, StuartC</author><br />
<status>Alpha 2.01</status><br />
. . .<br />
<br />
[[Howto: Make_an_aircraft#The_-set.xml_file|Find out more about the -set.xml file here.]]<br />
<br />
The <sim> section is what we are looking for.<br />
<br />
We search for <multiplayer> and don't find any existing <multiplayer> section. So we can add our needed <multiplayer> section in any convenient place. Let's place it between the <submodels> and <panel> sections. The added code is in between those two:<br />
<br />
<submodels> <br />
<serviceable type="bool">true</serviceable><br />
<path>Aircraft/F-15E/Models/Effects/guns/submodels.xml</path><br />
<path>Aircraft/F-15E/Models/weapons/loads.xml</path><br />
</submodels><br />
<br />
<!-- Required to make Bombable work over multiplayer --><br />
<!-- String 9 is for Bombable damage/reset messages --><br />
<!-- Int 10,11,... are for various weapons triggers as particular to this aircraft --><br />
<multiplay><br />
<generic><br />
<string n="9" type="string"/><br />
<int n="10" alias="controls/armament/trigger" /><br />
</generic><br />
</multiplay><br />
<br />
<br />
<panel><br />
<visibility archive="y">false</visibility><br />
</panel><br />
<br />
You'll notice we have customized one line: <int n="10" alias="controls/armament/trigger" /><br />
<br />
The alias, controls/armament/trigger, refers to the submodel <trigger> which we observed in Step 1. <br />
<br />
If the aircraft has more than one trigger (for more than one weapon, for example), we can make several triggers like this:<br />
<br />
<int n="10" alias="controls/armament/trigger" /><br />
<int n="11" alias="controls/armament/trigger1" /><br />
<int n="12" alias="controls/armament/trigger2" /><br />
<int n="13" alias="controls/armament/trigger3" /><br />
<int n="14" alias="controls/armament/trigger4" /><br />
<br />
Each alias should correspond to a different <trigger> property in the submodel.xml definitions.<br />
<br />
Save the -set.xml file with the changes.<br />
<br />
==STEP 3: Add the Bombable Nasal code to the Model XML file==<br />
<br />
Bombable needs to have certain code run when the AI or MP aircraft initializes. The code is in [[Nasal]], FlightGear's scripting language. The code gives Bombable needed information about the aircraft (dimensions, vulnerabilities, weapons, etc) and also the code tells Bombable which systems to initialize for this aircraft.<br />
<br />
The simplest way to create this code is to start with a similar aircraft in the Bombable download, then copy and mod the Bombable code as needed.<br />
<br />
There are two steps in this process:<br />
<br />
* Create the -bombableinclude.xml file<br />
* Link the -bombableinclude.xml file to the aircraft's existing model XML file<br />
<br />
===Create the -bombableinclude.xml file=== <br />
In the Bombable distribution, the include files are named [aircraftname]-bombableinclude.xml and are generally found in FGDATA/AI/Aircraft/[aircraftname]/Models.<br />
<br />
In this case, the most similar aircraft in the Bombable distribution is the A-10. If [[Bombable]] is installed, the needed file is in:<br />
<br />
FGDATA\AI\Aircraft\A-10-Bombable\Models\A-10-bombableinclude.xml<br />
<br />
Open the file with a text editor and save it with a new name in your F-15E directory. The new name & directory should be something like:<br />
<br />
FGDATA\Aircraft\F-15E\Models\F-15E_StrikeEagle-bombableinclude.xml<br />
<br />
Now you can open and edit this file. Most changes are quite obvious--change the name, change the dimensions, etc.<br />
<br />
When done, we end up with a file like this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList><br />
<!-- Nasal code --><br />
<nasal><br />
<br />
<br />
<load><br />
<![CDATA[<br />
print("Loading F-15E ", cmdarg().getPath());<br />
<br />
var nodeName = cmdarg().getPath(); <br />
<br />
##checks whether it has been initialized already; if so, just return<br />
if ( bombable.check_overall_initialized (nodeName) ) return;<br />
<br />
<br />
<br />
<br />
############################################<br />
#FUNCTION object_init, INITIALIZER<br />
var object_init = func() {<br />
# Datas of this object are under: cmdarg().getPath()<br />
var thisNodeName = cmdarg().getPath();<br />
var thisNode = props.globals.getNode(thisNodeName);<br />
# Add some useful nodes<br />
<br />
<br />
<br />
########################################################################<br />
########################################################################<br />
# INITIALIZE BOMBABLE<br />
# <br />
# Initialize constants and main routines for maintaining altitude<br />
# relative to ground-level, relocating after file/reset, and <br />
# creating bombable/shootable objects.<br />
# <br />
# These routines are found in FG/nasal/bombable.nas<br />
# <br />
######################################################################## <br />
# INITIALIZE BOMBABLE Object<br />
# This object will be slurped in the object's node as a child<br />
# node named "bombable". <br />
# All distances are specified in meters.<br />
# All altitudes are relative to current ground level at the object's <br />
# location<br />
# <br />
<br />
thisNodeName = cmdarg().getPath(); <br />
<br />
var bombableObject = { <br />
<br />
<br />
objectNodeName : thisNodeName,<br />
objectNode : props.globals.getNode(thisNodeName),<br />
updateTime_s : 1/3, #time, in seconds, between the updates that <br />
#keep the object at its AGL. Tradeoff is high-speed updates look more<br />
#realistic but slow down the framerate/cause jerkiness. Faster-moving<br />
#objects will need more frequent updates to look realistic.<br />
#update time faster than about 1/3 seems to have a noticeable effect<br />
#on frame rate <br />
<br />
<br />
######################################### <br />
# ALTITUDE DEFINITIONS<br />
# <br />
altitudes : { <br />
wheelsOnGroundAGL_m : 1 , #altitude correction to add to your aircraft or ship that is needed to put wheels on ground (or, for a ship, make it float in the water at the correct level). For most objects this is 0 but some models need a small correction to place them exactly at ground level<br />
<br />
minimumAGL_m : 300, #minimum altitude above ground level this object is allowed to fly<br />
maximumAGL_m : 50000, #maximum altitude AGL this object is allowed to fly, ie, operational ceiling <br />
crashedAGL_m : 0.6, #altitude AGL when crashed. Ships will sink to this level, aircraft or vehicles will sink into the ground as landing gear collapses or tires deflate. Should be negative, even just -0.001.<br />
},<br />
# <br />
#########################################<br />
# VELOCITIES DEFINITIONS<br />
# <br />
velocities : { <br />
maxSpeedReduce_percent : 0.5, #max % to reduce speed, per step, when damaged<br />
minSpeed_kt : 112, #minimum speed to reduce to when damaged. Ground vehicles and ships might stop completely when damaged but aircraft will need a minimum speed so they keep moving until they hit the ground.<br />
cruiseSpeed_kt : 550, #cruising speed, typical/optimal cruising speed, V C for aircraft<br />
<br />
attackSpeed_kt : 900, #typical/optimal speed when aggressively attacking or evading, in<br />
#level flight for aircraft<br />
<br />
maxSpeed_kt : 1400 , #Maximum possible speed under dive or downhill conditions, V NE for aircraft<br />
<br />
damagedAltitudeChangeMaxRate_meterspersecond : 30, #max rate to sink or fly downwards when damaged, in meters/second<br />
<br />
#The terminal velocities are calculated by opening the 'real' AC <br />
#in FG, level flight, full throttle, then putting<br />
#the AC at different angles of attack with the autopilot,<br />
#and noting the terminal airspeed & vertical speed velocities.<br />
#For best results, do it near sea level, under 5000 feet altitude.<br />
#One or two each of climb & dive velocities are probably sufficient.<br />
#However if you do more we may be able to use the more precise<br />
#data in the future.<br />
#<br />
#Note that these are intended to be true airspeed whereas FG's<br />
#/velocities/airspeed-kt reports indicated airspeed, so some <br />
#conversion or reference to groundspeed-kt is needed.<br />
# <br />
#In FG /velocities/groundspeed-kt is equal (or close <br />
#to equal, except for wind . . .) true airspeed when pitch=0 <br />
#but as pitch increases or decreases that will change.<br />
# <br />
diveTerminalVelocities: {<br />
point1: { airspeed_kt : 1060, vertical_speed_fps : - 337},<br />
point2: { airspeed_kt : 1230, vertical_speed_fps : - 755},<br />
<br />
},<br />
<br />
climbTerminalVelocities: {<br />
point1: { airspeed_kt : 468, vertical_speed_fps : 236},<br />
point2: { airspeed_kt : 843, vertical_speed_fps : 251},<br />
#point3: { airspeed_kt : 1100, vertical_speed_fps : 161},<br />
<br />
},<br />
<br />
},<br />
# <br />
#########################################<br />
# EVASION DEFINITIONS<br />
# <br />
# The evasion system makes the AI aircraft dodge when they come under<br />
# fire. <br />
evasions : { <br />
dodgeDelayMax_sec : 15, #max time to delay/wait between dodges<br />
dodgeDelayMin_sec : 5, #minimum time to delay/wait between dodges<br />
dodgeMax_deg : 88, #Max amount to turn when dodging<br />
#90 degrees = instant turn, unrealistic<br />
#up to 80 is usually OK, somewhere in 80-85 starts to be unrealistically fast<br />
#>85 is usually very unrealistic. You must test this in your scenario, however.<br />
<br />
dodgeMin_deg : 83, #minimum amount to turn when dodging <br />
rollRateMax_degpersec : 300, #you can figure this out by rolling the corresponding FG aircraft and timing a 180 or 360 deg roll <br />
dodgeROverLPreference_percent : 50, # Preference for right turns vs. left when dodging. 90% means 90% right turns, 50% means 50% right turns.<br />
dodgeAltMin_m : -8000, #Aircraft will begin to move up or down <br />
dodgeAltMax_m : 8000, #Max & Min are relative to current alt <br />
dodgeVertSpeedClimb_mps : 1500, #Max speed to climb when evading<br />
dodgeVertSpeedDive_mps : 1500, #Max speed to dive when evading <br />
},<br />
# <br />
#########################################<br />
# ATTACK DEFINITIONS<br />
# <br />
# The attack system makes the AI aircraft turn and fly towards <br />
# other aircraft <br />
attacks : { <br />
maxDistance_m : 30000, #max distance to turn & attack main aircraft<br />
minDistance_m : 4000, #min distance to turn & attack main aircraft, ie, fly away this far before turning to attack again<br />
continueAttackAngle_deg : 80, #when within minDistance_m, the aircraft will continue to turn towards the main aircraft and attack *if* if the angle is less than this amount from dead ahead<br />
altitudeHigherCutoff_m : 30000, # will attack the main aircraft unless this amount higher than it or more<br />
altitudeLowerCutoff_m : 30000, # will attack the main aircraft unless this amount lower than it or more<br />
climbPower : 8000, # How powerful the aircraft is when climbing during an attack; 4000 would be typical for, say a Zero--scale accordingly for others; higher is stronger<br />
divePower : 10000, # How powerful the aircraft is when diving during and attack; 6000 typical of a Zero--could be much more than climbPower if the aircraft is a weak climber but a strong diver <br />
rollMin_deg : 82, #when turning on attack, roll to this angle min<br />
#for sedate, Cessna-like manuevers make rollMin low. If you want an aggressive,<br />
#attacking, aiming fighter keep it close to rollMax, or even almost equal to rollMax <br />
rollMax_deg : 87, #when turning on attack, roll to this angle max<br />
#90 degrees = instant turn, unrealistic<br />
#up to 80 might be OK, depending on aircraft & speed; somewhere in 80-85 starts to be unrealistically fast<br />
#>85 is usually very unrealistic. You must test this in your scenario, however.<br />
rollRateMax_degpersec : 120, #you can figure this out by rolling the corresponding FG aircraft and timing a 180 or 360 deg roll <br />
attackCheckTime_sec : 10, # check for need to attack/correct course this often <br />
attackCheckTimeEngaged_sec : 0.5, # once engaged with enemy, check/update course this frequently<br />
<br />
},<br />
<br />
# <br />
#########################################<br />
# WEAPONS DEFINITIONS<br />
# <br />
# The weapons system makes the AI aircraft fire on the main aircraft <br />
# You can define any number of weapons--just enclose each in curly brackets<br />
# and separate with commas (,). <br />
weapons : {<br />
front_gun : #internal name - this can be any name you want; must be a valid nasal variable name<br />
{ <br />
name : "Machine Gun", # name presented to users, ie in on-screen messages<br />
maxDamage_percent : 5, # maximum percentage damage one hit from the aircraft's main weapon/machine guns will do to an opponent<br />
maxDamageDistance_m : 2000, # maximum distance at which the aircrafts main weapon/maching guns will be able to damage an opponent<br />
weaponAngle_deg : { heading: 0, elevation: 0 }, # direction the aircraft's main weapon is aimed. <br />
# 0,0 = straight ahead, 90,0=directly right, 0,90=directly up, 0,180=directly back, etc.<br />
weaponOffset_m : {x:2, y:0, z:0}, # Offset of the weapon from the main aircraft center<br />
weaponSize_m : {start:.1, end:.1}, # Visual size of the weapon's projectile, in meters, at start & end of its path<br />
<br />
}, <br />
sidewinder_missile : #internal name - this can be any name you want; must be a valid nasal variable name<br />
{ <br />
name : "Sidewinder guided missile", # name presented to users, ie in on-screen messages<br />
maxDamage_percent : 40, # maximum percentage damage one hit from the aircraft's main weapon/machine guns will do to an opponent<br />
maxDamageDistance_m : 6000, # maximum distance at which the aircrafts main weapon/machine guns will be able to damage an opponent<br />
weaponAngle_deg : { heading: 0, elevation: 0 }, # direction the aircraft's main weapon is aimed. <br />
# 0,0 = straight ahead, 90,0=directly right, 0,90=directly up, 0,180=directly back, etc.<br />
weaponOffset_m : {x:2, y:0, z:0}, # Offset of the weapon from the main aircraft center<br />
weaponSize_m : {start:1, end:1}, # Visual size of the weapon's projectile, in meters, at start & end of its path<br />
<br />
}, <br />
<br />
<br />
}, <br />
<br />
# <br />
#########################################<br />
# DIMENSION DEFINITIONS<br />
#<br />
# All dimensions are in meters<br />
# <br />
# <br />
dimensions : { <br />
width_m : 17.53, #width of your object, ie, for aircraft, wingspan<br />
length_m : 16.26, #length of your object, ie, for aircraft, distance nose to tail<br />
height_m : 4.47, #height of your object, ie, for aircraft ground to highest point when sitting on runway<br />
<br />
damageRadius_m : 8, #typically 1/2 the longest dimension of the object. Hits within this distance of the <br />
#center of object have some possibility of damage<br />
vitalDamageRadius_m : 2, #typically the radius of the fuselage or cockpit or other most <br />
# vital area at the center of the object. Always smaller than damageRadius_m<br />
<br />
crashRadius_m : 6, #It's a crash if the main aircraft hits in this area.<br />
<br />
},<br />
#<br />
#########################################<br />
# VULNERABILITIES DEFINITIONS <br />
#<br />
vulnerabilities : { <br />
damageVulnerability : 9, #Vulnerability to damage from armament, 1=normal M1 tank; higher to make objects easier to kill and lower to make them more difficult. This is a multiplier, so 5 means 5X easier to kill than an M1, 1/5 means 5X harder to kill. <br />
<br />
engineDamageVulnerability_percent : 6, #Chance that a small-caliber machine-gun round will damage the engine. <br />
<br />
fireVulnerability_percent : 5, #Vulnerability to catching on fire. 100% means even the slightest impact will set it on fire; 20% means quite difficult to set on fire; 0% means set on fire only when completely damaged; -1% means never set on fire. <br />
<br />
fireDamageRate_percentpersecond : .1, #Amount of damage to add, per second, when on fire. 100%=completely damaged. Warthog is relatively damage-resistant.<br />
<br />
fireExtinguishMaxTime_seconds : 80, #Once a fire starts, for this many seconds there is a chance to put out the fire; fires lasting longer than this won't be put out until the object burns out.<br />
<br />
fireExtinguishSuccess_percentage : 45, #Chance of the crew putting out the fire within the MaxTime above. Warthoge is relatively damage-resistant.<br />
<br />
explosiveMass_kg : 27772 , #mass of the object in KG, but give at least a 2-10X bonus to anything carrying flammables or high explosives.<br />
},<br />
#<br />
#########################################<br />
# LIVERY DEFINITIONS<br />
#<br />
# Path to livery files to use at different damage levels.<br />
# Path is relative to the AI aircraft's directory.<br />
# The object will start with the first livery listed and <br />
# change to succeeding liveries as the damage<br />
# level increases. The final livery should indicate full damage/<br />
# object destroyed. <br />
# <br />
# If you don't want to specify any special liveries simply set <br />
# damageLivery : nil and the object's normal livery will be used. <br />
# <br />
damageLiveries : {<br />
damageLivery : [ ] <br />
},<br />
<br />
};<br />
<br />
#########################################<br />
# INITIALIZE ROUTINES<br />
# <br />
# OVERALL INITIALIZER: Needed to make all the others work<br />
bombable.initialize ( bombableObject );<br />
#<br />
# LOCATION: Relocate object to maintain its position after file/reset <br />
# (best not used for airplanes)<br />
# bombable.location_init ( thisNodeName );<br />
#<br />
# GROUND: Keep object at altitude relative to ground level<br />
bombable.ground_init ( thisNodeName );<br />
#<br />
# ATTACK: Make the object attack the main aircraft <br />
bombable.attack_init ( thisNodeName );<br />
#<br />
# WEAPONS: Make the object shoot the main aircraft <br />
bombable.weapons_init ( thisNodeName ); <br />
#<br />
# BOMBABLE: Make the object bombable/damageable <br />
bombable.bombable_init ( thisNodeName );<br />
#<br />
# SMOKE/CONTRAIL: Start a flare, contrail, smoke trail, or exhaust <br />
# trail for the object.<br />
# Smoke types available: flare, jetcontrail, pistonexhaust, smoketrail,<br />
# damagedengine <br />
bombable.startSmoke("jetcontrail", thisNodeName );<br />
#F-15E already has contrails, we're leaving this out<br />
#<br />
# END INITIALIZE BOMBABLE<br />
########################################################################<br />
######################################################################## <br />
<br />
<br />
<br />
}<br />
<br />
object_init();<br />
]]><br />
</load><br />
<unload><br />
<![CDATA[<br />
print("Unload F-15E.");<br />
var nodeName= cmdarg().getPath(); <br />
bombable.de_overall_initialize( nodeName );<br />
bombable.initialize_del( nodeName );<br />
bombable.ground_del( nodeName );<br />
bombable.location_del (nodeName);<br />
bombable.bombable_del( nodeName );<br />
bombable.attack_del( nodeName );<br />
bombable.weapons_del (nodeName); <br />
# </unload><br />
<br />
]]><br />
</unload><br />
</nasal> <br />
<br />
</PropertyList><br />
<br />
Save this file with the name you have chosen ( FGDATA\Aircraft\F-15E\Models\F-15E_StrikeEagle-bombableinclude.xml).<br />
<br />
===Link the -bombableinclude.xml file to the existing F-15 model file===<br />
<br />
Now that we have created the -bombableinclude.xml file, we need to set up the aircraft to load the file on startup.<br />
<br />
AI scenarios (and MP aircraft) load the aircraft's model file. So we need to locate that file and include the new -bombableinclude.xml file in it.<br />
<br />
Where is the model file? Look in the aircraft's -set.xml file. In that file will be a section called <model>. For the F-15E it looks like this:<br />
<br />
<model><br />
<path>Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</path><br />
</model><br />
<br />
So Aircraft/F-15E/Models/F-15E_StrikeEagle.xml is our model file. <br />
<br />
<br />
Load Aircraft/F-15E/Models/F-15E_StrikeEagle.xml in a text editor. At the beginning of that file you will find this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList><br />
<br />
Change it to this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList include="F-15E_StrikeEagle-bombableinclude.xml"><br />
<br />
Save the file.<br />
<br />
===Notes===<br />
* The statement include="F-15E_StrikeEagle-bombableinclude.xml" indicates that F-15E_StrikeEagle-bombableinclude.xml will be in the same directory as F-15E_StrikeEagle.xml. That directory is Aircraft/F-15E/Models -- so make sure that the -bombableinclude.xml file is indeed in that directory!<br />
<br />
* Model files can have only ONE Nasal <load> section and one <unload> section.<br />
<br />
If you have more than one, the second and subsequent <load>/<unload> sections are ignored.<br />
<br />
The problem? Your aircraft may already have a <load> or <unload> section. When you add the Bombable code, one of the two <load> sections (the pre-existing one or Bombable's) will be ignored.<br />
<br />
The solution is to combine the two <load> sections into one, and the same with the <unload> sections. You'll need to know a little about [[Nasal]] programming to do anything complicated, but as a rule you can just copy/paste whatever is in the aircraft's <load> section to the start of Bombable's <load> section, and the same with <unload>.<br />
<br />
* You'll notice the Nasal code starts with ''<![CDATA['' and ends with '']]>''. That is needed to make Nasal code work within XML files. [http://www.w3schools.com/xml/xml_cdata.asp CDATA usage is explained here.]<br />
<br />
==STEP 4. Add to an AI Scenario==<br />
Now we can add the F-15E to an AI scenario.<br />
<br />
Create a file named F-15E-demo.xml and save it in your FGDATA/AI directory.<br />
<br />
Most of the entries in the scenario file are self-explanatory. For the <model> entry you'll need the path of the same model file for the F-15 that we located in Step 3--which is Aircraft/F-15E/Models/F-15E_StrikeEagle.xml.<br />
<br />
Here is how the file should look when you are done:<br />
<br />
<?xml version="1.0"?><br />
<PropertyList><br />
<scenario><br />
<description>My new F-15E scenario. Starts at KSFO! </description><br />
<br />
<entry><br />
<type>aircraft</type><br />
<callsign>Jones</callsign><br />
<name>F15E Leader</name><br />
<model type="string">Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model><br />
<latitude type="double">37.608720</latitude><br />
<longitude type="double">-122.3076</longitude><br />
<altitude type="double">309</altitude><br />
<speed>280.0</speed><br />
<heading type="double">192</heading><br />
</entry><br />
<br />
<entry><br />
<type>aircraft</type><br />
<callsign>Cooper</callsign><br />
<name>F15E Wingman</name><br />
<model type="string">Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model><br />
<latitude type="double">37.608200</latitude><br />
<longitude type="double">-122.2988</longitude><br />
<altitude type="double">309</altitude><br />
<speed>270.0</speed><br />
<heading type="double">192</heading><br />
</entry><br />
<scenario><br />
<br />
</PropertyList><br />
<br />
Again, save as FGDATA/AI/F-15E-demo.xml. When you start FGRun next time, F-15E-demo will be listed as one of the scenario file options. (You may need to quit and re-start FGRun.)<br />
<br />
==STEP 5. Troubleshooting==<br />
OK, we're done. Time to fly our new aircraft in our new scenario!<br />
<br />
Oh, yeah . . . we just followed a very complicated process with numerous steps that could go wrong. Maybe we'd better test a bit first.<br />
<br />
Start Flightgear. Using FGRun:<br />
<br />
1. Choose ''UFO bombable'' as the main aircraft (best for testing . . . )<br />
2. Airport KSFO<br />
3. Scenario F-15-demo (which we just created--if saved correctly in the FGDATA/AI directory, it will show up in the scenario list of FGRun)<br />
4. Click "Run"<br />
5. Closely watch the command console as FG starts. You may pick up important errors in XML files and/or Nasal code.<br />
6. You should see<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
<br />
Uh-oh. There is our first error. f-15-demo.xml, line 31, column 2, I have "<scenario>" rather than "</scenario>".<br />
<br />
I fix, save the fixed file, and re-start. Now I get:<br />
<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
* Failed to load XML: . . . F-15E-StrikeEagle-bombableinclude.xml<br />
<br />
OK, this is typical. There is a typo or stray character on the .xml file . . . or something.<br />
<br />
After a few minutes of trying different things, I discover I've made a typo:<br />
<br />
* In \Aircraft\F-15E\Models\F-15E_StrikeEagle.xml is this line:<br />
<PropertyList include="F-15E_StrikeEagle-bombableinclude.xml"><br />
* But I've saved the file as <br />
FGDATA/Aircraft/F-15E/F-15-StrikeEagle-bombableinclude.xml<br />
<br />
OK, that one little "E" made all the difference. I change the filename to match what's in the -set.xml file and try again.<br />
<br />
And finally:<br />
<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
* Loading F-15E /ai/models/aircraft<br />
* Loading F-15E /ai/models/aircraft[1]<br />
* A bunch of other Bombable messages showing the aircraft initializing (I have Bombable menu/Debug turned on, which is helpful at this stage)<br />
* A bunch of error messages showing various animations and systems not load (ahhh . . . that's why we create stripped-down versions of aircraft in the AI/Aircraft directory--a completely separate and even longer article).<br />
<br />
I open Equipment/Maps, click "traffic", see the two aircraft "Jones" and "Cooper", track them down with the UFO, they show proper smoke trails, I shoot at them, I shoot them down. It works!<br />
<br />
Success!<br />
<br />
Well, except . . . are they flying realistically? Climbing, turning, diving, shooting? Are they taking damage realistically? Does it work properly under Multiplayer?<br />
<br />
Here is where you spend hours researching real F-15s, flying against the AI models with the UFO and other aircraft, tweaking parameters in the -bombableinclude.xml file, and so on and on.<br />
<br />
You're just getting started. <br />
<br />
Good luck!<br />
<br />
===Testing/parsing XML files===<br />
One final tip: XML files are extremely persnickety. Just one wrong character can make an entire file fail to load. <br />
<br />
The best/easiest way to test XML files is load them in Internet Explorer. It will parse the XML file and display any errors it finds. (If you don't have access to IE there are other XML parsers available.) This is far easier and faster than starting and re-starting FG repeatedly, and IE gives better, more informative error messages as well.<br />
<br />
==IMPORTANT POSTSCRIPT: Where your aircraft files are==<br />
An important detail in getting Bombable to work with aircraft over AI and MP is the directories you store the files in and the names you choose to use for them.<br />
<br />
FlightGear stores aircraft and AI aircraft files in at least two different places.<br />
<br />
In a typical FG installation, in your FGDATA folder, you will find<br />
<br />
* FGDATA/Aircraft<br />
* FGDATA/AI/Aircraft<br />
<br />
FGDATA/Aircraft holds files for the main aircraft whereas FGDATA/AI/Aircraft holds files for AI and MP aircraft.<br />
<br />
AI/MP aircraft don't have all the features of main aircraft, so you might find the very same aircraft in FGDATA/Aircraft and in FGDATA/AI/Aircraft--but the one in FGDATA/AI/Aircraft will be very stripped down, fewer files, smaller, and less complex.<br />
<br />
When building a [[AI_Systems#AI_Models|FlightGear AI scenario]], you can specify the exact path and filename of the file FlightGear looks for. You can specify a file in the FGDATA/Aircraft directory, or in the FGDATA/AI/Aircraft, or really anywhere within the FGDATA directory that you like. Examples:<br />
<br />
<model type="string">AI/Aircraft/sopwithCamel-Bombable/Models/sopwithCamel-model.xml</model> <br />
<br />
OR<br />
<br />
<model type="string">Aircraft/sopwithCamel-Bombable/Models/sopwithCamel-model.xml</model> <br />
<br />
When loading an MP aircraft, FlightGear first looks for the (typically smaller/simpler) aircraft file in FGDATA/AI/Aircraft.<br />
<br />
If it doesn't find the aircraft there, it then searches FGDATA/Aircraft.<br />
<br />
===How FG matches Multiplayer Aircraft with your local AI aircraft models===<br />
<br />
As of version 2.4.0, when FG is looking for the local AI aircraft model to display for a remote aircraft over Multiplayer, FG searches first the AI Aircraft directories, then the Aircraft directories.<br />
<br />
It searches for a match by looking for the file with a name exactly matching the MP aircraft's model (this is typically in the aircraft's Models subdirectory and ends with .ac, though this may vary) and if that fails, FG looks for a matching -set.xml file.<br />
<br />
The important points for making AI models that will work over MP with Bombable: <br />
<br />
* Make sure the main aircraft and the AI version of the aircraft have the exact same names for the aircraft's model file and the aircraft's -set.xml<br />
<br />
* If you're modding an existing but non-bombable-compatible aircraft, you need to decide whether you're going to leave all the directories, model XML file names, and -set.xml file names the same as the standard flightgear aircraft (leading to possible frustration as your version overwrites existing aircraft files on users hard drivers) OR rename the aircraft's directory, -set.xml file name, and model file name (which means you're going to have to do a bit of work on the aircraft's XML files to make sure everything still works with all those name changes.<br />
<br />
* You can create a separate, stripped down AI version of the aircraft in the FGDATA/AI/Aircraft directory and add the Bombable additions to it (more work for you but smaller/quicker download and easier on the memory and framerate in FG) OR you can simply add all the Bombable additions to the main aircraft directory in FGDATA/Aircraft.<br />
<br />
Bombable will work with any of those options--so it is really up to you.<br />
<br />
==EXTRA: Making livery change with damage==<br />
<br />
Once you have Bombable working with your aircraft there is a bonus: bombable.nas will handle setting the livery colors and<br />
automatically changing them as the object becomes damaged. <br />
<br />
For an example of how this works and looks, take a look at the Bombable scenarios involving the M1 tank and the Jeep.<br />
<br />
For this to work your model must have different liveries available<br />
and then animate the liveries so that the texture used is the one shown<br />
in this path: /ai/model/model[X]/bombable/texture-corps-path. The /ai/model/model[X]/ part is assumed for AI craft so you need to add <texture-prop>bombable/texture-corps-path</texture-prop> in the right place of your XML file. <br />
<br />
Example from Jeep.xml in the jeep-bombable directory:<br />
<br />
<animation><br />
<type>material</type><br />
<object-name>jeep-body</object-name><br />
<object-name>roof1</object-name><br />
<object-name>roof2</object-name><br />
<object-name>softroof</object-name><br />
<object-name>chassis</object-name><br />
<object-name>chassis.002</object-name><br />
<object-name>Plane</object-name><br />
<object-name>hinge</object-name><br />
<object-name>screen</object-name><br />
<object-name>wiper.L</object-name><br />
<object-name>wiper.R</object-name><br />
<object-name>seat.L</object-name><br />
<object-name>seat.R</object-name><br />
<texture-prop>bombable/texture-corps-path</texture-prop><br />
<transparency><br />
<alpha>1.0</alpha><br />
</transparency><br />
</animation><br />
<br />
<br />
Additionally, if you want to change your object's the livery color programmatically (for instance, if you include a menu item to select different liveries) you can use the following code in the -bombableinclude.xml file (see above) to change all liveries, including damage liveries, that the object uses:<br />
<br />
Example:<br />
liveries = [<br />
"Models/livery_nodamage.png", <br />
"Models/livery_slightdamage.png", <br />
"Models/livery_highdamage.png");<br />
];<br />
<br />
bombable.set_livery (cmdarg().getPath(), liveries); <br />
<br />
You can include liveries for as many different levels of damage (ie, fine gradations of change from undamaged to completely damaged) as you like. For instance:<br />
<br />
<br />
Example:<br />
liveries = [<br />
"Models/livery_nodamage.png", <br />
"Models/livery_barelydamaged.png", <br />
"Models/livery_justslightlydamaged.png", <br />
"Models/livery_alittlemoredamage.png", <br />
"Models/livery_fairlydamaged.png", <br />
"Models/livery_kindadamaged.png",<br />
"Models/livery_prettydamaged.png",<br />
"Models/livery_whoawereintroublenow.png", <br />
"Models/livery_finishedoff.png");<br />
];<br />
<br />
bombable.set_livery (cmdarg().getPath(), liveries); <br />
<br />
<br />
<br />
<br />
==Related content==<br />
* [[Bombable]] <br />
* [[Howto:Nasal in scenery object XML files]]<br />
* [[AI Traffic]]<br />
* [[AI Systems#AI Models]]<br />
* [[Howto:Add submodels]]<br />
* [[Howto:Make an aircraft]]<br />
<br />
[[Category:Aircraft enhancement|Bombable]]<br />
[[Category:Bombable]]<br />
[[Category:Nasal howto|Bombable]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Howto:Adding_Bombable_to_FlightGear_Aircraft&diff=138411Howto:Adding Bombable to FlightGear Aircraft2023-09-21T23:59:26Z<p>Flug: Explained that the original F-15E files are no longer available, and what to do about it.</p>
<hr />
<div>{{Template:Bombable_Navigation}}<br />
<br />
[[File:camel-through-wing.jpg|thumb]]<br />
[[File:spad-vs-camel.jpg|thumb]]<br />
[[File:warthog-down-on-bay-bridge.jpg|thumb]]<br />
How to make a [[FlightGear]] [[aircraft]] work with [[Bombable]].<br />
<br />
When you follow these instructions, you will add the following properties to your aircraft:<br />
<br />
* AI aircraft can fly, maneuver, dodge, and attack the main aircraft. They can avoid the ground (aircraft) or stay on the ground (ships, vehicles) while maneuvering.<br />
* AI and MP aircraft can be damaged by the main aircraft and will stop functioning, crash, catch fire, explode, etc., appropriately when hit by weapons or bombs. MP aircraft will report damage back over MP to the main aircraft, making multiplayer dogfights possible.<br />
* MP aircraft will display weapons shooting whenever the remote MP aircraft is shooting, and report damage back to the main aircraft if the remote MP aircraft shoots or damages your aircraft.<br />
* AI and MP aircraft can have smoke, contrails, and damaged engine smoke<br />
* AI aircraft can automatically follow the main aircraft and attack it with weapons, which will be visible.<br />
* You can design and customize the features per aircraft--to make, for instance, a maneuverable twisty dogfighter, light and easily damaged, or a fast, heavily armored energy fighter with lower maneuverability.<br />
<br />
To make FlightGear aircraft work with Bombable--as the main aircraft, an AI aircraft, and via Multiplayer (MP)--you need three things:<br />
<br />
* Weapons submodels that report impacts properly<br />
* A snippet of code added to the aircraft's -set.xml file to allow communication of Bombable information over Multiplayer<br />
* A section of code in the load/unload section of the Aircraft's XML files that allow Bombable to initialize and give it information about the aircraft needed to operate as an AI or Multiplayer model<br />
<br />
There are several decisions you will have to make about where to put your file and what to name it (see "Where your aircraft files are" below for more info).<br />
<br />
For our example, we'll mod the [https://github.com/FGMEMBERS/F-15E F-15E model from FGUK] to become Bombable. We'll assume:<br />
<br />
* You have [[Bombable]] installed already<br />
* You have the aircraft installed in FGDATA/aircraft/F-15E<br />
* We will add the files/mods needed for AI aircraft to the FGDATA/aircraft/F-15E directories (rather than creating a new, separate FGDATA/AI/Aircraft version of the F-15E)<br />
* We're just going to mod the existing F-15E directories and aircraft without changing and aircraft or file names (rather than creating a separate, new, differently named F-15E-Bombable aircraft)<br />
<br />
===Helpful/Needed files===<br />
<br />
* [http://www.flightgear.org/forums/viewtopic.php?t=5742 Bombable download]<br />
*[http://brenthugh.com/flightgear/F-15E.zip F-15E model with the mods as described in this article] (finished and working version, though still un-polished, as described below, but with several updates and fixes beyond those mentioned in the article)<br />
* [https://github.com/FGMEMBERS/F-15E Current F-15E model from FGUK] - which now includes the Bombable mods as well as a large number of tweaks and updates to the base F-15E model that have been added since 2011.<br />
<br />
=== Note: The original FGUK F-15E, without the Bombable mods, is no longer available. ===<br />
The mods described below were added to the base FGUK F-15E aircraft in about 2011. Since then, FGUK has incorporated the Bombable mods in the F-15E aircraft and then continued to make further enhancements to the F-15E since that time.<br />
<br />
So, unfortunately, you will not be able to download the original F-15E files and then follow the steps below to make your own modded F-15E version. <br />
<br />
Still, you can:<br />
<br />
* Download the [http://brenthugh.com/flightgear/F-15E.zip F-15E model with the mods as described in this article] (2011) to see the end result of the mods, and then read the steps below to see what changes were made to arrive at the Bombable-compatible mod.<br />
* Download the [https://github.com/FGMEMBERS/F-15E current F-15E model from FGUK], which also include the Bombable mods, and see how the mods look in a somewhat more current/updated aircraft model.<br />
<br />
Either way, by looking at either of those aircraft and following the instructions below, you should be able to get good idea about how the original files were modded to become compatible with Bombable.<br />
<br />
==Step 1: Check the weapons models for impact reporting==<br />
Most FG aircraft that have weapons already work with Bombable at a basic level, right out of the box. That is because FG has a way for aircraft weapons to report their impacts, and most FG aircraft with weapons already use the impact reporting system.<br />
<br />
First, find the XML file that defines the weapons submodels. Typically this is in the aircraft's Models directory (or a subdirectory). It may be named submodels.xml, or F-15-submodels.xml, or guns.xml, or something similar.<br />
<br />
When you open the correct file (FGDATA\Aircraft\F-15E\Models\Effects\guns\submodels.xml, in this case), it will look something like this:<br />
<br />
<PropertyList><br />
<br />
<!-- Gauche --><br />
<submodel><br />
<name>left</name><br />
<model>Aircraft/F-15E/Models/Effects/guns/apibullet-tracer.xml</model><br />
<trigger>controls/armament/trigger</trigger><br />
<speed>2460.0</speed><br />
<repeat>true</repeat><br />
. . . <br />
<br />
[[Howto:_Add_submodels|A complete description of these files is here.]]<br />
<br />
For each <submodel></submodel> section, the areas of interest are the <name> and the <collision> and <impact> areas.<br />
<br />
===Submodel name===<br />
For the submodel name, in FG 2.4.0 we are working around a little FG bug, and Bombable identifies munitions and weapons by their name. <br />
<br />
So it is very important that the name of each weapons submodel include one of the following keywords:<br />
<br />
gun, tracer, bullet, round, cannon, bomb, heavy-bomb, rocket, missile, <br />
MK-81, MK-82, MK-83, MK-84, 5 pound, 25 pound, 100 pound, 150 pound, <br />
250 pound, 500 pound, 1000 pound, 2000 pound<br />
<br />
The name simply needs to include the appropriate keyword in some way--so if you have another name you prefer, just include the keyword at the end, like "MKFD Special Munition (250 pound)".<br />
<br />
In this case, it is a 20 mm gatling gun, so more into cannon range, with projectiles weighing in at about .25 lb. So we simply add "cannon" to each of the submodel names:<br />
<br />
<submodel><br />
<name>left cannon</name><br />
<br />
<submodel><br />
<name>right cannon</name><br />
<br />
===Collision and impact reporting===<br />
The collision and impact areas of this file look like this:<br />
<br />
<collision>true</collision><br />
<collision-report>sim/ai/aircraft/collision/gun</collision-report><br />
<impact>true</impact><br />
<impact-report>sim/ai/aircraft/impact/bullet</impact-report><br />
<br />
[IMPORTANT!] Both <collision> and <impact> should be set to true. <br />
<br />
[IMPORTANT!] <impact-report> should be one of these--the first one is the default, but any is fine:<br />
<br />
ai/models/model-impact<br />
sim/armament/weapons/impact<br />
sim/ai/aircraft/impact/bullet<br />
sim/ai/aircraft/impact/gun<br />
sim/ai/aircraft/impact/cannon<br />
sim/ai/aircraft/impact/bomb<br />
<br />
According to the FG documentation, the <collision-report> setting is no longer used, so you can safely delete it (though it does no harm to leave it be).<br />
<br />
For the F-15E, this section of each <submodel> looks fine, so we just leave it alone.<br />
<br />
We save the file with the changes to the <name> sections.<br />
<br />
==STEP 2: Adding code needed for MultiPlayer to the -set.xml file==<br />
<br />
In the aircraft's -set.XML file, we need to add a <multiplay> section in the <PropertyList><sim> section.<br />
<br />
This gets a bit confusing for two reasons:<br />
<br />
* -set.xml files may (or may not!) load other files, so the <sim> section where we need to add our code may be in the -set.xml file OR in one of the other .xml files the -set.xml file loads<br />
<br />
* There may be existing code in <sim><multiplayer> and so we can simply add our code to that rather than creating a new/different <multiplayer> section.<br />
<br />
In the case of the F-15E, we open FGDATA\Aircraft\F-15E\F-15E_StrikeEagle-set.xml and find:<br />
<br />
<?xml version="1.0"?><br />
<PropertyList><br />
<sim><br />
<br />
<description>F-15E_Strike_Eagle</description><br />
<author>Flying Toaster 3DM, StuartC</author><br />
<status>Alpha 2.01</status><br />
. . .<br />
<br />
[[Howto: Make_an_aircraft#The_-set.xml_file|Find out more about the -set.xml file here.]]<br />
<br />
The <sim> section is what we are looking for.<br />
<br />
We search for <multiplayer> and don't find any existing <multiplayer> section. So we can add our needed <multiplayer> section in any convenient place. Let's place it between the <submodels> and <panel> sections. The added code is in between those two:<br />
<br />
<submodels> <br />
<serviceable type="bool">true</serviceable><br />
<path>Aircraft/F-15E/Models/Effects/guns/submodels.xml</path><br />
<path>Aircraft/F-15E/Models/weapons/loads.xml</path><br />
</submodels><br />
<br />
<!-- Required to make Bombable work over multiplayer --><br />
<!-- String 9 is for Bombable damage/reset messages --><br />
<!-- Int 10,11,... are for various weapons triggers as particular to this aircraft --><br />
<multiplay><br />
<generic><br />
<string n="9" type="string"/><br />
<int n="10" alias="controls/armament/trigger" /><br />
</generic><br />
</multiplay><br />
<br />
<br />
<panel><br />
<visibility archive="y">false</visibility><br />
</panel><br />
<br />
You'll notice we have customized one line: <int n="10" alias="controls/armament/trigger" /><br />
<br />
The alias, controls/armament/trigger, refers to the submodel <trigger> which we observed in Step 1. <br />
<br />
If the aircraft has more than one trigger (for more than one weapon, for example), we can make several triggers like this:<br />
<br />
<int n="10" alias="controls/armament/trigger" /><br />
<int n="11" alias="controls/armament/trigger1" /><br />
<int n="12" alias="controls/armament/trigger2" /><br />
<int n="13" alias="controls/armament/trigger3" /><br />
<int n="14" alias="controls/armament/trigger4" /><br />
<br />
Each alias should correspond to a different <trigger> property in the submodel.xml definitions.<br />
<br />
Save the -set.xml file with the changes.<br />
<br />
==STEP 3: Add the Bombable Nasal code to the Model XML file==<br />
<br />
Bombable needs to have certain code run when the AI or MP aircraft initializes. The code is in [[Nasal]], FlightGear's scripting language. The code gives Bombable needed information about the aircraft (dimensions, vulnerabilities, weapons, etc) and also the code tells Bombable which systems to initialize for this aircraft.<br />
<br />
The simplest way to create this code is to start with a similar aircraft in the Bombable download, then copy and mod the Bombable code as needed.<br />
<br />
There are two steps in this process:<br />
<br />
* Create the -bombableinclude.xml file<br />
* Link the -bombableinclude.xml file to the aircraft's existing model XML file<br />
<br />
===Create the -bombableinclude.xml file=== <br />
In the Bombable distribution, the include files are named [aircraftname]-bombableinclude.xml and are generally found in FGDATA/AI/Aircraft/[aircraftname]/Models.<br />
<br />
In this case, the most similar aircraft in the Bombable distribution is the A-10. If [[Bombable]] is installed, the needed file is in:<br />
<br />
FGDATA\AI\Aircraft\A-10-Bombable\Models\A-10-bombableinclude.xml<br />
<br />
Open the file with a text editor and save it with a new name in your F-15E directory. The new name & directory should be something like:<br />
<br />
FGDATA\Aircraft\F-15E\Models\F-15E_StrikeEagle-bombableinclude.xml<br />
<br />
Now you can open and edit this file. Most changes are quite obvious--change the name, change the dimensions, etc.<br />
<br />
When done, we end up with a file like this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList><br />
<!-- Nasal code --><br />
<nasal><br />
<br />
<br />
<load><br />
<![CDATA[<br />
print("Loading F-15E ", cmdarg().getPath());<br />
<br />
var nodeName = cmdarg().getPath(); <br />
<br />
##checks whether it has been initialized already; if so, just return<br />
if ( bombable.check_overall_initialized (nodeName) ) return;<br />
<br />
<br />
<br />
<br />
############################################<br />
#FUNCTION object_init, INITIALIZER<br />
var object_init = func() {<br />
# Datas of this object are under: cmdarg().getPath()<br />
var thisNodeName = cmdarg().getPath();<br />
var thisNode = props.globals.getNode(thisNodeName);<br />
# Add some useful nodes<br />
<br />
<br />
<br />
########################################################################<br />
########################################################################<br />
# INITIALIZE BOMBABLE<br />
# <br />
# Initialize constants and main routines for maintaining altitude<br />
# relative to ground-level, relocating after file/reset, and <br />
# creating bombable/shootable objects.<br />
# <br />
# These routines are found in FG/nasal/bombable.nas<br />
# <br />
######################################################################## <br />
# INITIALIZE BOMBABLE Object<br />
# This object will be slurped in the object's node as a child<br />
# node named "bombable". <br />
# All distances are specified in meters.<br />
# All altitudes are relative to current ground level at the object's <br />
# location<br />
# <br />
<br />
thisNodeName = cmdarg().getPath(); <br />
<br />
var bombableObject = { <br />
<br />
<br />
objectNodeName : thisNodeName,<br />
objectNode : props.globals.getNode(thisNodeName),<br />
updateTime_s : 1/3, #time, in seconds, between the updates that <br />
#keep the object at its AGL. Tradeoff is high-speed updates look more<br />
#realistic but slow down the framerate/cause jerkiness. Faster-moving<br />
#objects will need more frequent updates to look realistic.<br />
#update time faster than about 1/3 seems to have a noticeable effect<br />
#on frame rate <br />
<br />
<br />
######################################### <br />
# ALTITUDE DEFINITIONS<br />
# <br />
altitudes : { <br />
wheelsOnGroundAGL_m : 1 , #altitude correction to add to your aircraft or ship that is needed to put wheels on ground (or, for a ship, make it float in the water at the correct level). For most objects this is 0 but some models need a small correction to place them exactly at ground level<br />
<br />
minimumAGL_m : 300, #minimum altitude above ground level this object is allowed to fly<br />
maximumAGL_m : 50000, #maximum altitude AGL this object is allowed to fly, ie, operational ceiling <br />
crashedAGL_m : 0.6, #altitude AGL when crashed. Ships will sink to this level, aircraft or vehicles will sink into the ground as landing gear collapses or tires deflate. Should be negative, even just -0.001.<br />
},<br />
# <br />
#########################################<br />
# VELOCITIES DEFINITIONS<br />
# <br />
velocities : { <br />
maxSpeedReduce_percent : 0.5, #max % to reduce speed, per step, when damaged<br />
minSpeed_kt : 112, #minimum speed to reduce to when damaged. Ground vehicles and ships might stop completely when damaged but aircraft will need a minimum speed so they keep moving until they hit the ground.<br />
cruiseSpeed_kt : 550, #cruising speed, typical/optimal cruising speed, V C for aircraft<br />
<br />
attackSpeed_kt : 900, #typical/optimal speed when aggressively attacking or evading, in<br />
#level flight for aircraft<br />
<br />
maxSpeed_kt : 1400 , #Maximum possible speed under dive or downhill conditions, V NE for aircraft<br />
<br />
damagedAltitudeChangeMaxRate_meterspersecond : 30, #max rate to sink or fly downwards when damaged, in meters/second<br />
<br />
#The terminal velocities are calculated by opening the 'real' AC <br />
#in FG, level flight, full throttle, then putting<br />
#the AC at different angles of attack with the autopilot,<br />
#and noting the terminal airspeed & vertical speed velocities.<br />
#For best results, do it near sea level, under 5000 feet altitude.<br />
#One or two each of climb & dive velocities are probably sufficient.<br />
#However if you do more we may be able to use the more precise<br />
#data in the future.<br />
#<br />
#Note that these are intended to be true airspeed whereas FG's<br />
#/velocities/airspeed-kt reports indicated airspeed, so some <br />
#conversion or reference to groundspeed-kt is needed.<br />
# <br />
#In FG /velocities/groundspeed-kt is equal (or close <br />
#to equal, except for wind . . .) true airspeed when pitch=0 <br />
#but as pitch increases or decreases that will change.<br />
# <br />
diveTerminalVelocities: {<br />
point1: { airspeed_kt : 1060, vertical_speed_fps : - 337},<br />
point2: { airspeed_kt : 1230, vertical_speed_fps : - 755},<br />
<br />
},<br />
<br />
climbTerminalVelocities: {<br />
point1: { airspeed_kt : 468, vertical_speed_fps : 236},<br />
point2: { airspeed_kt : 843, vertical_speed_fps : 251},<br />
#point3: { airspeed_kt : 1100, vertical_speed_fps : 161},<br />
<br />
},<br />
<br />
},<br />
# <br />
#########################################<br />
# EVASION DEFINITIONS<br />
# <br />
# The evasion system makes the AI aircraft dodge when they come under<br />
# fire. <br />
evasions : { <br />
dodgeDelayMax_sec : 15, #max time to delay/wait between dodges<br />
dodgeDelayMin_sec : 5, #minimum time to delay/wait between dodges<br />
dodgeMax_deg : 88, #Max amount to turn when dodging<br />
#90 degrees = instant turn, unrealistic<br />
#up to 80 is usually OK, somewhere in 80-85 starts to be unrealistically fast<br />
#>85 is usually very unrealistic. You must test this in your scenario, however.<br />
<br />
dodgeMin_deg : 83, #minimum amount to turn when dodging <br />
rollRateMax_degpersec : 300, #you can figure this out by rolling the corresponding FG aircraft and timing a 180 or 360 deg roll <br />
dodgeROverLPreference_percent : 50, # Preference for right turns vs. left when dodging. 90% means 90% right turns, 50% means 50% right turns.<br />
dodgeAltMin_m : -8000, #Aircraft will begin to move up or down <br />
dodgeAltMax_m : 8000, #Max & Min are relative to current alt <br />
dodgeVertSpeedClimb_mps : 1500, #Max speed to climb when evading<br />
dodgeVertSpeedDive_mps : 1500, #Max speed to dive when evading <br />
},<br />
# <br />
#########################################<br />
# ATTACK DEFINITIONS<br />
# <br />
# The attack system makes the AI aircraft turn and fly towards <br />
# other aircraft <br />
attacks : { <br />
maxDistance_m : 30000, #max distance to turn & attack main aircraft<br />
minDistance_m : 4000, #min distance to turn & attack main aircraft, ie, fly away this far before turning to attack again<br />
continueAttackAngle_deg : 80, #when within minDistance_m, the aircraft will continue to turn towards the main aircraft and attack *if* if the angle is less than this amount from dead ahead<br />
altitudeHigherCutoff_m : 30000, # will attack the main aircraft unless this amount higher than it or more<br />
altitudeLowerCutoff_m : 30000, # will attack the main aircraft unless this amount lower than it or more<br />
climbPower : 8000, # How powerful the aircraft is when climbing during an attack; 4000 would be typical for, say a Zero--scale accordingly for others; higher is stronger<br />
divePower : 10000, # How powerful the aircraft is when diving during and attack; 6000 typical of a Zero--could be much more than climbPower if the aircraft is a weak climber but a strong diver <br />
rollMin_deg : 82, #when turning on attack, roll to this angle min<br />
#for sedate, Cessna-like manuevers make rollMin low. If you want an aggressive,<br />
#attacking, aiming fighter keep it close to rollMax, or even almost equal to rollMax <br />
rollMax_deg : 87, #when turning on attack, roll to this angle max<br />
#90 degrees = instant turn, unrealistic<br />
#up to 80 might be OK, depending on aircraft & speed; somewhere in 80-85 starts to be unrealistically fast<br />
#>85 is usually very unrealistic. You must test this in your scenario, however.<br />
rollRateMax_degpersec : 120, #you can figure this out by rolling the corresponding FG aircraft and timing a 180 or 360 deg roll <br />
attackCheckTime_sec : 10, # check for need to attack/correct course this often <br />
attackCheckTimeEngaged_sec : 0.5, # once engaged with enemy, check/update course this frequently<br />
<br />
},<br />
<br />
# <br />
#########################################<br />
# WEAPONS DEFINITIONS<br />
# <br />
# The weapons system makes the AI aircraft fire on the main aircraft <br />
# You can define any number of weapons--just enclose each in curly brackets<br />
# and separate with commas (,). <br />
weapons : {<br />
front_gun : #internal name - this can be any name you want; must be a valid nasal variable name<br />
{ <br />
name : "Machine Gun", # name presented to users, ie in on-screen messages<br />
maxDamage_percent : 5, # maximum percentage damage one hit from the aircraft's main weapon/machine guns will do to an opponent<br />
maxDamageDistance_m : 2000, # maximum distance at which the aircrafts main weapon/maching guns will be able to damage an opponent<br />
weaponAngle_deg : { heading: 0, elevation: 0 }, # direction the aircraft's main weapon is aimed. <br />
# 0,0 = straight ahead, 90,0=directly right, 0,90=directly up, 0,180=directly back, etc.<br />
weaponOffset_m : {x:2, y:0, z:0}, # Offset of the weapon from the main aircraft center<br />
weaponSize_m : {start:.1, end:.1}, # Visual size of the weapon's projectile, in meters, at start & end of its path<br />
<br />
}, <br />
sidewinder_missile : #internal name - this can be any name you want; must be a valid nasal variable name<br />
{ <br />
name : "Sidewinder guided missile", # name presented to users, ie in on-screen messages<br />
maxDamage_percent : 40, # maximum percentage damage one hit from the aircraft's main weapon/machine guns will do to an opponent<br />
maxDamageDistance_m : 6000, # maximum distance at which the aircrafts main weapon/machine guns will be able to damage an opponent<br />
weaponAngle_deg : { heading: 0, elevation: 0 }, # direction the aircraft's main weapon is aimed. <br />
# 0,0 = straight ahead, 90,0=directly right, 0,90=directly up, 0,180=directly back, etc.<br />
weaponOffset_m : {x:2, y:0, z:0}, # Offset of the weapon from the main aircraft center<br />
weaponSize_m : {start:1, end:1}, # Visual size of the weapon's projectile, in meters, at start & end of its path<br />
<br />
}, <br />
<br />
<br />
}, <br />
<br />
# <br />
#########################################<br />
# DIMENSION DEFINITIONS<br />
#<br />
# All dimensions are in meters<br />
# <br />
# <br />
dimensions : { <br />
width_m : 17.53, #width of your object, ie, for aircraft, wingspan<br />
length_m : 16.26, #length of your object, ie, for aircraft, distance nose to tail<br />
height_m : 4.47, #height of your object, ie, for aircraft ground to highest point when sitting on runway<br />
<br />
damageRadius_m : 8, #typically 1/2 the longest dimension of the object. Hits within this distance of the <br />
#center of object have some possibility of damage<br />
vitalDamageRadius_m : 2, #typically the radius of the fuselage or cockpit or other most <br />
# vital area at the center of the object. Always smaller than damageRadius_m<br />
<br />
crashRadius_m : 6, #It's a crash if the main aircraft hits in this area.<br />
<br />
},<br />
#<br />
#########################################<br />
# VULNERABILITIES DEFINITIONS <br />
#<br />
vulnerabilities : { <br />
damageVulnerability : 9, #Vulnerability to damage from armament, 1=normal M1 tank; higher to make objects easier to kill and lower to make them more difficult. This is a multiplier, so 5 means 5X easier to kill than an M1, 1/5 means 5X harder to kill. <br />
<br />
engineDamageVulnerability_percent : 6, #Chance that a small-caliber machine-gun round will damage the engine. <br />
<br />
fireVulnerability_percent : 5, #Vulnerability to catching on fire. 100% means even the slightest impact will set it on fire; 20% means quite difficult to set on fire; 0% means set on fire only when completely damaged; -1% means never set on fire. <br />
<br />
fireDamageRate_percentpersecond : .1, #Amount of damage to add, per second, when on fire. 100%=completely damaged. Warthog is relatively damage-resistant.<br />
<br />
fireExtinguishMaxTime_seconds : 80, #Once a fire starts, for this many seconds there is a chance to put out the fire; fires lasting longer than this won't be put out until the object burns out.<br />
<br />
fireExtinguishSuccess_percentage : 45, #Chance of the crew putting out the fire within the MaxTime above. Warthoge is relatively damage-resistant.<br />
<br />
explosiveMass_kg : 27772 , #mass of the object in KG, but give at least a 2-10X bonus to anything carrying flammables or high explosives.<br />
},<br />
#<br />
#########################################<br />
# LIVERY DEFINITIONS<br />
#<br />
# Path to livery files to use at different damage levels.<br />
# Path is relative to the AI aircraft's directory.<br />
# The object will start with the first livery listed and <br />
# change to succeeding liveries as the damage<br />
# level increases. The final livery should indicate full damage/<br />
# object destroyed. <br />
# <br />
# If you don't want to specify any special liveries simply set <br />
# damageLivery : nil and the object's normal livery will be used. <br />
# <br />
damageLiveries : {<br />
damageLivery : [ ] <br />
},<br />
<br />
};<br />
<br />
#########################################<br />
# INITIALIZE ROUTINES<br />
# <br />
# OVERALL INITIALIZER: Needed to make all the others work<br />
bombable.initialize ( bombableObject );<br />
#<br />
# LOCATION: Relocate object to maintain its position after file/reset <br />
# (best not used for airplanes)<br />
# bombable.location_init ( thisNodeName );<br />
#<br />
# GROUND: Keep object at altitude relative to ground level<br />
bombable.ground_init ( thisNodeName );<br />
#<br />
# ATTACK: Make the object attack the main aircraft <br />
bombable.attack_init ( thisNodeName );<br />
#<br />
# WEAPONS: Make the object shoot the main aircraft <br />
bombable.weapons_init ( thisNodeName ); <br />
#<br />
# BOMBABLE: Make the object bombable/damageable <br />
bombable.bombable_init ( thisNodeName );<br />
#<br />
# SMOKE/CONTRAIL: Start a flare, contrail, smoke trail, or exhaust <br />
# trail for the object.<br />
# Smoke types available: flare, jetcontrail, pistonexhaust, smoketrail,<br />
# damagedengine <br />
bombable.startSmoke("jetcontrail", thisNodeName );<br />
#F-15E already has contrails, we're leaving this out<br />
#<br />
# END INITIALIZE BOMBABLE<br />
########################################################################<br />
######################################################################## <br />
<br />
<br />
<br />
}<br />
<br />
object_init();<br />
]]><br />
</load><br />
<unload><br />
<![CDATA[<br />
print("Unload F-15E.");<br />
var nodeName= cmdarg().getPath(); <br />
bombable.de_overall_initialize( nodeName );<br />
bombable.initialize_del( nodeName );<br />
bombable.ground_del( nodeName );<br />
bombable.location_del (nodeName);<br />
bombable.bombable_del( nodeName );<br />
bombable.attack_del( nodeName );<br />
bombable.weapons_del (nodeName); <br />
# </unload><br />
<br />
]]><br />
</unload><br />
</nasal> <br />
<br />
</PropertyList><br />
<br />
Save this file with the name you have chosen ( FGDATA\Aircraft\F-15E\Models\F-15E_StrikeEagle-bombableinclude.xml).<br />
<br />
===Link the -bombableinclude.xml file to the existing F-15 model file===<br />
<br />
Now that we have created the -bombableinclude.xml file, we need to set up the aircraft to load the file on startup.<br />
<br />
AI scenarios (and MP aircraft) load the aircraft's model file. So we need to locate that file and include the new -bombableinclude.xml file in it.<br />
<br />
Where is the model file? Look in the aircraft's -set.xml file. In that file will be a section called <model>. For the F-15E it looks like this:<br />
<br />
<model><br />
<path>Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</path><br />
</model><br />
<br />
So Aircraft/F-15E/Models/F-15E_StrikeEagle.xml is our model file. <br />
<br />
<br />
Load Aircraft/F-15E/Models/F-15E_StrikeEagle.xml in a text editor. At the beginning of that file you will find this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList><br />
<br />
Change it to this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList include="F-15E_StrikeEagle-bombableinclude.xml"><br />
<br />
Save the file.<br />
<br />
===Notes===<br />
* The statement include="F-15E_StrikeEagle-bombableinclude.xml" indicates that F-15E_StrikeEagle-bombableinclude.xml will be in the same directory as F-15E_StrikeEagle.xml. That directory is Aircraft/F-15E/Models -- so make sure that the -bombableinclude.xml file is indeed in that directory!<br />
<br />
* Model files can have only ONE Nasal <load> section and one <unload> section.<br />
<br />
If you have more than one, the second and subsequent <load>/<unload> sections are ignored.<br />
<br />
The problem? Your aircraft may already have a <load> or <unload> section. When you add the Bombable code, one of the two <load> sections (the pre-existing one or Bombable's) will be ignored.<br />
<br />
The solution is to combine the two <load> sections into one, and the same with the <unload> sections. You'll need to know a little about [[Nasal]] programming to do anything complicated, but as a rule you can just copy/paste whatever is in the aircraft's <load> section to the start of Bombable's <load> section, and the same with <unload>.<br />
<br />
* You'll notice the Nasal code starts with ''<![CDATA['' and ends with '']]>''. That is needed to make Nasal code work within XML files. [http://www.w3schools.com/xml/xml_cdata.asp CDATA usage is explained here.]<br />
<br />
==STEP 4. Add to an AI Scenario==<br />
Now we can add the F-15E to an AI scenario.<br />
<br />
Create a file named F-15E-demo.xml and save it in your FGDATA/AI directory.<br />
<br />
Most of the entries in the scenario file are self-explanatory. For the <model> entry you'll need the path of the same model file for the F-15 that we located in Step 3--which is Aircraft/F-15E/Models/F-15E_StrikeEagle.xml.<br />
<br />
Here is how the file should look when you are done:<br />
<br />
<?xml version="1.0"?><br />
<PropertyList><br />
<scenario><br />
<description>My new F-15E scenario. Starts at KSFO! </description><br />
<br />
<entry><br />
<type>aircraft</type><br />
<callsign>Jones</callsign><br />
<name>F15E Leader</name><br />
<model type="string">Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model><br />
<latitude type="double">37.608720</latitude><br />
<longitude type="double">-122.3076</longitude><br />
<altitude type="double">309</altitude><br />
<speed>280.0</speed><br />
<heading type="double">192</heading><br />
</entry><br />
<br />
<entry><br />
<type>aircraft</type><br />
<callsign>Cooper</callsign><br />
<name>F15E Wingman</name><br />
<model type="string">Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model><br />
<latitude type="double">37.608200</latitude><br />
<longitude type="double">-122.2988</longitude><br />
<altitude type="double">309</altitude><br />
<speed>270.0</speed><br />
<heading type="double">192</heading><br />
</entry><br />
<scenario><br />
<br />
</PropertyList><br />
<br />
Again, save as FGDATA/AI/F-15E-demo.xml. When you start FGRun next time, F-15E-demo will be listed as one of the scenario file options. (You may need to quit and re-start FGRun.)<br />
<br />
==STEP 5. Troubleshooting==<br />
OK, we're done. Time to fly our new aircraft in our new scenario!<br />
<br />
Oh, yeah . . . we just followed a very complicated process with numerous steps that could go wrong. Maybe we'd better test a bit first.<br />
<br />
Start Flightgear. Using FGRun:<br />
<br />
1. Choose ''UFO bombable'' as the main aircraft (best for testing . . . )<br />
2. Airport KSFO<br />
3. Scenario F-15-demo (which we just created--if saved correctly in the FGDATA/AI directory, it will show up in the scenario list of FGRun)<br />
4. Click "Run"<br />
5. Closely watch the command console as FG starts. You may pick up important errors in XML files and/or Nasal code.<br />
6. You should see<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
<br />
Uh-oh. There is our first error. f-15-demo.xml, line 31, column 2, I have "<scenario>" rather than "</scenario>".<br />
<br />
I fix, save the fixed file, and re-start. Now I get:<br />
<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
* Failed to load XML: . . . F-15E-StrikeEagle-bombableinclude.xml<br />
<br />
OK, this is typical. There is a typo or stray character on the .xml file . . . or something.<br />
<br />
After a few minutes of trying different things, I discover I've made a typo:<br />
<br />
* In \Aircraft\F-15E\Models\F-15E_StrikeEagle.xml is this line:<br />
<PropertyList include="F-15E_StrikeEagle-bombableinclude.xml"><br />
* But I've saved the file as <br />
FGDATA/Aircraft/F-15E/F-15-StrikeEagle-bombableinclude.xml<br />
<br />
OK, that one little "E" made all the difference. I change the filename to match what's in the -set.xml file and try again.<br />
<br />
And finally:<br />
<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
* Loading F-15E /ai/models/aircraft<br />
* Loading F-15E /ai/models/aircraft[1]<br />
* A bunch of other Bombable messages showing the aircraft initializing (I have Bombable menu/Debug turned on, which is helpful at this stage)<br />
* A bunch of error messages showing various animations and systems not load (ahhh . . . that's why we create stripped-down versions of aircraft in the AI/Aircraft directory--a completely separate and even longer article).<br />
<br />
I open Equipment/Maps, click "traffic", see the two aircraft "Jones" and "Cooper", track them down with the UFO, they show proper smoke trails, I shoot at them, I shoot them down. It works!<br />
<br />
Success!<br />
<br />
Well, except . . . are they flying realistically? Climbing, turning, diving, shooting? Are they taking damage realistically? Does it work properly under Multiplayer?<br />
<br />
Here is where you spend hours researching real F-15s, flying against the AI models with the UFO and other aircraft, tweaking parameters in the -bombableinclude.xml file, and so on and on.<br />
<br />
You're just getting started. <br />
<br />
Good luck!<br />
<br />
===Testing/parsing XML files===<br />
One final tip: XML files are extremely persnickety. Just one wrong character can make an entire file fail to load. <br />
<br />
The best/easiest way to test XML files is load them in Internet Explorer. It will parse the XML file and display any errors it finds. (If you don't have access to IE there are other XML parsers available.) This is far easier and faster than starting and re-starting FG repeatedly, and IE gives better, more informative error messages as well.<br />
<br />
==IMPORTANT POSTSCRIPT: Where your aircraft files are==<br />
An important detail in getting Bombable to work with aircraft over AI and MP is the directories you store the files in and the names you choose to use for them.<br />
<br />
FlightGear stores aircraft and AI aircraft files in at least two different places.<br />
<br />
In a typical FG installation, in your FGDATA folder, you will find<br />
<br />
* FGDATA/Aircraft<br />
* FGDATA/AI/Aircraft<br />
<br />
FGDATA/Aircraft holds files for the main aircraft whereas FGDATA/AI/Aircraft holds files for AI and MP aircraft.<br />
<br />
AI/MP aircraft don't have all the features of main aircraft, so you might find the very same aircraft in FGDATA/Aircraft and in FGDATA/AI/Aircraft--but the one in FGDATA/AI/Aircraft will be very stripped down, fewer files, smaller, and less complex.<br />
<br />
When building a [[AI_Systems#AI_Models|FlightGear AI scenario]], you can specify the exact path and filename of the file FlightGear looks for. You can specify a file in the FGDATA/Aircraft directory, or in the FGDATA/AI/Aircraft, or really anywhere within the FGDATA directory that you like. Examples:<br />
<br />
<model type="string">AI/Aircraft/sopwithCamel-Bombable/Models/sopwithCamel-model.xml</model> <br />
<br />
OR<br />
<br />
<model type="string">Aircraft/sopwithCamel-Bombable/Models/sopwithCamel-model.xml</model> <br />
<br />
When loading an MP aircraft, FlightGear first looks for the (typically smaller/simpler) aircraft file in FGDATA/AI/Aircraft.<br />
<br />
If it doesn't find the aircraft there, it then searches FGDATA/Aircraft.<br />
<br />
===How FG matches Multiplayer Aircraft with your local AI aircraft models===<br />
<br />
As of version 2.4.0, when FG is looking for the local AI aircraft model to display for a remote aircraft over Multiplayer, FG searches first the AI Aircraft directories, then the Aircraft directories.<br />
<br />
It searches for a match by looking for the file with a name exactly matching the MP aircraft's model (this is typically in the aircraft's Models subdirectory and ends with .ac, though this may vary) and if that fails, FG looks for a matching -set.xml file.<br />
<br />
The important points for making AI models that will work over MP with Bombable: <br />
<br />
* Make sure the main aircraft and the AI version of the aircraft have the exact same names for the aircraft's model file and the aircraft's -set.xml<br />
<br />
* If you're modding an existing but non-bombable-compatible aircraft, you need to decide whether you're going to leave all the directories, model XML file names, and -set.xml file names the same as the standard flightgear aircraft (leading to possible frustration as your version overwrites existing aircraft files on users hard drivers) OR rename the aircraft's directory, -set.xml file name, and model file name (which means you're going to have to do a bit of work on the aircraft's XML files to make sure everything still works with all those name changes.<br />
<br />
* You can create a separate, stripped down AI version of the aircraft in the FGDATA/AI/Aircraft directory and add the Bombable additions to it (more work for you but smaller/quicker download and easier on the memory and framerate in FG) OR you can simply add all the Bombable additions to the main aircraft directory in FGDATA/Aircraft.<br />
<br />
Bombable will work with any of those options--so it is really up to you.<br />
<br />
==EXTRA: Making livery change with damage==<br />
<br />
Once you have Bombable working with your aircraft there is a bonus: bombable.nas will handle setting the livery colors and<br />
automatically changing them as the object becomes damaged. <br />
<br />
For an example of how this works and looks, take a look at the Bombable scenarios involving the M1 tank and the Jeep.<br />
<br />
For this to work your model must have different liveries available<br />
and then animate the liveries so that the texture used is the one shown<br />
in this path: /ai/model/model[X]/bombable/texture-corps-path. The /ai/model/model[X]/ part is assumed for AI craft so you need to add <texture-prop>bombable/texture-corps-path</texture-prop> in the right place of your XML file. <br />
<br />
Example from Jeep.xml in the jeep-bombable directory:<br />
<br />
<animation><br />
<type>material</type><br />
<object-name>jeep-body</object-name><br />
<object-name>roof1</object-name><br />
<object-name>roof2</object-name><br />
<object-name>softroof</object-name><br />
<object-name>chassis</object-name><br />
<object-name>chassis.002</object-name><br />
<object-name>Plane</object-name><br />
<object-name>hinge</object-name><br />
<object-name>screen</object-name><br />
<object-name>wiper.L</object-name><br />
<object-name>wiper.R</object-name><br />
<object-name>seat.L</object-name><br />
<object-name>seat.R</object-name><br />
<texture-prop>bombable/texture-corps-path</texture-prop><br />
<transparency><br />
<alpha>1.0</alpha><br />
</transparency><br />
</animation><br />
<br />
<br />
Additionally, if you want to change your object's the livery color programmatically (for instance, if you include a menu item to select different liveries) you can use the following code in the -bombableinclude.xml file (see above) to change all liveries, including damage liveries, that the object uses:<br />
<br />
Example:<br />
liveries = [<br />
"Models/livery_nodamage.png", <br />
"Models/livery_slightdamage.png", <br />
"Models/livery_highdamage.png");<br />
];<br />
<br />
bombable.set_livery (cmdarg().getPath(), liveries); <br />
<br />
You can include liveries for as many different levels of damage (ie, fine gradations of change from undamaged to completely damaged) as you like. For instance:<br />
<br />
<br />
Example:<br />
liveries = [<br />
"Models/livery_nodamage.png", <br />
"Models/livery_barelydamaged.png", <br />
"Models/livery_justslightlydamaged.png", <br />
"Models/livery_alittlemoredamage.png", <br />
"Models/livery_fairlydamaged.png", <br />
"Models/livery_kindadamaged.png",<br />
"Models/livery_prettydamaged.png",<br />
"Models/livery_whoawereintroublenow.png", <br />
"Models/livery_finishedoff.png");<br />
];<br />
<br />
bombable.set_livery (cmdarg().getPath(), liveries); <br />
<br />
<br />
<br />
<br />
==Related content==<br />
* [[Bombable]] <br />
* [[Howto:Nasal in scenery object XML files]]<br />
* [[AI Traffic]]<br />
* [[AI Systems#AI Models]]<br />
* [[Howto:Add submodels]]<br />
* [[Howto:Make an aircraft]]<br />
<br />
[[Category:Aircraft enhancement|Bombable]]<br />
[[Category:Bombable]]<br />
[[Category:Nasal howto|Bombable]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Howto:Adding_Bombable_to_FlightGear_Aircraft&diff=138410Howto:Adding Bombable to FlightGear Aircraft2023-09-21T23:09:31Z<p>Flug: Updated link to FGUK F-15E</p>
<hr />
<div>{{Template:Bombable_Navigation}}<br />
<br />
[[File:camel-through-wing.jpg|thumb]]<br />
[[File:spad-vs-camel.jpg|thumb]]<br />
[[File:warthog-down-on-bay-bridge.jpg|thumb]]<br />
How to make a [[FlightGear]] [[aircraft]] work with [[Bombable]].<br />
<br />
When you follow these instructions, you will add the following properties to your aircraft:<br />
<br />
* AI aircraft can fly, maneuver, dodge, and attack the main aircraft. They can avoid the ground (aircraft) or stay on the ground (ships, vehicles) while maneuvering.<br />
* AI and MP aircraft can be damaged by the main aircraft and will stop functioning, crash, catch fire, explode, etc., appropriately when hit by weapons or bombs. MP aircraft will report damage back over MP to the main aircraft, making multiplayer dogfights possible.<br />
* MP aircraft will display weapons shooting whenever the remote MP aircraft is shooting, and report damage back to the main aircraft if the remote MP aircraft shoots or damages your aircraft.<br />
* AI and MP aircraft can have smoke, contrails, and damaged engine smoke<br />
* AI aircraft can automatically follow the main aircraft and attack it with weapons, which will be visible.<br />
* You can design and customize the features per aircraft--to make, for instance, a maneuverable twisty dogfighter, light and easily damaged, or a fast, heavily armored energy fighter with lower maneuverability.<br />
<br />
To make FlightGear aircraft work with Bombable--as the main aircraft, an AI aircraft, and via Multiplayer (MP)--you need three things:<br />
<br />
* Weapons submodels that report impacts properly<br />
* A snippet of code added to the aircraft's -set.xml file to allow communication of Bombable information over Multiplayer<br />
* A section of code in the load/unload section of the Aircraft's XML files that allow Bombable to initialize and give it information about the aircraft needed to operate as an AI or Multiplayer model<br />
<br />
There are several decisions you will have to make about where to put your file and what to name it (see "Where your aircraft files are" below for more info).<br />
<br />
For our example, we'll mod the [https://github.com/FGMEMBERS/F-15E F-15E model from FGUK] to become Bombable. We'll assume:<br />
<br />
* You have [[Bombable]] installed already<br />
* You have the aircraft installed in FGDATA/aircraft/F-15E<br />
* We will add the files/mods needed for AI aircraft to the FGDATA/aircraft/F-15E directories (rather than creating a new, separate FGDATA/AI/Aircraft version of the F-15E)<br />
* We're just going to mod the existing F-15E directories and aircraft without changing and aircraft or file names (rather than creating a separate, new, differently named F-15E-Bombable aircraft)<br />
<br />
===Helpful/Needed files===<br />
<br />
* [http://www.flightgear.org/forums/viewtopic.php?t=5742 Bombable download]<br />
* [https://github.com/FGMEMBERS/F-15E F-15E model from FGUK]<br />
* [http://brenthugh.com/flightgear/F-15E.zip F-15E model with the mods as described in this article] (finished and working version, though still un-polished, as described below, but with several updates and fixes beyond those mentioned in the article)<br />
<br />
=== Note: If the FGUK F-15E is unavailable. ===<br />
If the FGUK base files are not available from FGUK or from the links above, you can try using any available F-15 variant or similar aircraft available in the FG hangar. For example, often other FGUK aircraft will use similar file and naming conventions, making the instructions below fairly easy to follow. Just start as instructed below, and apply similar mods as described below. Be award that exact filenames and other details may be different, however.<br />
<br />
You can also download the [http://brenthugh.com/flightgear/F-15E.zip F-15E model with the mods as described in this article] to see the end result of the mods, giving you a good idea of how the mod progressed.<br />
<br />
==Step 1: Check the weapons models for impact reporting==<br />
Most FG aircraft that have weapons already work with Bombable at a basic level, right out of the box. That is because FG has a way for aircraft weapons to report their impacts, and most FG aircraft with weapons already use the impact reporting system.<br />
<br />
First, find the XML file that defines the weapons submodels. Typically this is in the aircraft's Models directory (or a subdirectory). It may be named submodels.xml, or F-15-submodels.xml, or guns.xml, or something similar.<br />
<br />
When you open the correct file (FGDATA\Aircraft\F-15E\Models\Effects\guns\submodels.xml, in this case), it will look something like this:<br />
<br />
<PropertyList><br />
<br />
<!-- Gauche --><br />
<submodel><br />
<name>left</name><br />
<model>Aircraft/F-15E/Models/Effects/guns/apibullet-tracer.xml</model><br />
<trigger>controls/armament/trigger</trigger><br />
<speed>2460.0</speed><br />
<repeat>true</repeat><br />
. . . <br />
<br />
[[Howto:_Add_submodels|A complete description of these files is here.]]<br />
<br />
For each <submodel></submodel> section, the areas of interest are the <name> and the <collision> and <impact> areas.<br />
<br />
===Submodel name===<br />
For the submodel name, in FG 2.4.0 we are working around a little FG bug, and Bombable identifies munitions and weapons by their name. <br />
<br />
So it is very important that the name of each weapons submodel include one of the following keywords:<br />
<br />
gun, tracer, bullet, round, cannon, bomb, heavy-bomb, rocket, missile, <br />
MK-81, MK-82, MK-83, MK-84, 5 pound, 25 pound, 100 pound, 150 pound, <br />
250 pound, 500 pound, 1000 pound, 2000 pound<br />
<br />
The name simply needs to include the appropriate keyword in some way--so if you have another name you prefer, just include the keyword at the end, like "MKFD Special Munition (250 pound)".<br />
<br />
In this case, it is a 20 mm gatling gun, so more into cannon range, with projectiles weighing in at about .25 lb. So we simply add "cannon" to each of the submodel names:<br />
<br />
<submodel><br />
<name>left cannon</name><br />
<br />
<submodel><br />
<name>right cannon</name><br />
<br />
===Collision and impact reporting===<br />
The collision and impact areas of this file look like this:<br />
<br />
<collision>true</collision><br />
<collision-report>sim/ai/aircraft/collision/gun</collision-report><br />
<impact>true</impact><br />
<impact-report>sim/ai/aircraft/impact/bullet</impact-report><br />
<br />
[IMPORTANT!] Both <collision> and <impact> should be set to true. <br />
<br />
[IMPORTANT!] <impact-report> should be one of these--the first one is the default, but any is fine:<br />
<br />
ai/models/model-impact<br />
sim/armament/weapons/impact<br />
sim/ai/aircraft/impact/bullet<br />
sim/ai/aircraft/impact/gun<br />
sim/ai/aircraft/impact/cannon<br />
sim/ai/aircraft/impact/bomb<br />
<br />
According to the FG documentation, the <collision-report> setting is no longer used, so you can safely delete it (though it does no harm to leave it be).<br />
<br />
For the F-15E, this section of each <submodel> looks fine, so we just leave it alone.<br />
<br />
We save the file with the changes to the <name> sections.<br />
<br />
==STEP 2: Adding code needed for MultiPlayer to the -set.xml file==<br />
<br />
In the aircraft's -set.XML file, we need to add a <multiplay> section in the <PropertyList><sim> section.<br />
<br />
This gets a bit confusing for two reasons:<br />
<br />
* -set.xml files may (or may not!) load other files, so the <sim> section where we need to add our code may be in the -set.xml file OR in one of the other .xml files the -set.xml file loads<br />
<br />
* There may be existing code in <sim><multiplayer> and so we can simply add our code to that rather than creating a new/different <multiplayer> section.<br />
<br />
In the case of the F-15E, we open FGDATA\Aircraft\F-15E\F-15E_StrikeEagle-set.xml and find:<br />
<br />
<?xml version="1.0"?><br />
<PropertyList><br />
<sim><br />
<br />
<description>F-15E_Strike_Eagle</description><br />
<author>Flying Toaster 3DM, StuartC</author><br />
<status>Alpha 2.01</status><br />
. . .<br />
<br />
[[Howto: Make_an_aircraft#The_-set.xml_file|Find out more about the -set.xml file here.]]<br />
<br />
The <sim> section is what we are looking for.<br />
<br />
We search for <multiplayer> and don't find any existing <multiplayer> section. So we can add our needed <multiplayer> section in any convenient place. Let's place it between the <submodels> and <panel> sections. The added code is in between those two:<br />
<br />
<submodels> <br />
<serviceable type="bool">true</serviceable><br />
<path>Aircraft/F-15E/Models/Effects/guns/submodels.xml</path><br />
<path>Aircraft/F-15E/Models/weapons/loads.xml</path><br />
</submodels><br />
<br />
<!-- Required to make Bombable work over multiplayer --><br />
<!-- String 9 is for Bombable damage/reset messages --><br />
<!-- Int 10,11,... are for various weapons triggers as particular to this aircraft --><br />
<multiplay><br />
<generic><br />
<string n="9" type="string"/><br />
<int n="10" alias="controls/armament/trigger" /><br />
</generic><br />
</multiplay><br />
<br />
<br />
<panel><br />
<visibility archive="y">false</visibility><br />
</panel><br />
<br />
You'll notice we have customized one line: <int n="10" alias="controls/armament/trigger" /><br />
<br />
The alias, controls/armament/trigger, refers to the submodel <trigger> which we observed in Step 1. <br />
<br />
If the aircraft has more than one trigger (for more than one weapon, for example), we can make several triggers like this:<br />
<br />
<int n="10" alias="controls/armament/trigger" /><br />
<int n="11" alias="controls/armament/trigger1" /><br />
<int n="12" alias="controls/armament/trigger2" /><br />
<int n="13" alias="controls/armament/trigger3" /><br />
<int n="14" alias="controls/armament/trigger4" /><br />
<br />
Each alias should correspond to a different <trigger> property in the submodel.xml definitions.<br />
<br />
Save the -set.xml file with the changes.<br />
<br />
==STEP 3: Add the Bombable Nasal code to the Model XML file==<br />
<br />
Bombable needs to have certain code run when the AI or MP aircraft initializes. The code is in [[Nasal]], FlightGear's scripting language. The code gives Bombable needed information about the aircraft (dimensions, vulnerabilities, weapons, etc) and also the code tells Bombable which systems to initialize for this aircraft.<br />
<br />
The simplest way to create this code is to start with a similar aircraft in the Bombable download, then copy and mod the Bombable code as needed.<br />
<br />
There are two steps in this process:<br />
<br />
* Create the -bombableinclude.xml file<br />
* Link the -bombableinclude.xml file to the aircraft's existing model XML file<br />
<br />
===Create the -bombableinclude.xml file=== <br />
In the Bombable distribution, the include files are named [aircraftname]-bombableinclude.xml and are generally found in FGDATA/AI/Aircraft/[aircraftname]/Models.<br />
<br />
In this case, the most similar aircraft in the Bombable distribution is the A-10. If [[Bombable]] is installed, the needed file is in:<br />
<br />
FGDATA\AI\Aircraft\A-10-Bombable\Models\A-10-bombableinclude.xml<br />
<br />
Open the file with a text editor and save it with a new name in your F-15E directory. The new name & directory should be something like:<br />
<br />
FGDATA\Aircraft\F-15E\Models\F-15E_StrikeEagle-bombableinclude.xml<br />
<br />
Now you can open and edit this file. Most changes are quite obvious--change the name, change the dimensions, etc.<br />
<br />
When done, we end up with a file like this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList><br />
<!-- Nasal code --><br />
<nasal><br />
<br />
<br />
<load><br />
<![CDATA[<br />
print("Loading F-15E ", cmdarg().getPath());<br />
<br />
var nodeName = cmdarg().getPath(); <br />
<br />
##checks whether it has been initialized already; if so, just return<br />
if ( bombable.check_overall_initialized (nodeName) ) return;<br />
<br />
<br />
<br />
<br />
############################################<br />
#FUNCTION object_init, INITIALIZER<br />
var object_init = func() {<br />
# Datas of this object are under: cmdarg().getPath()<br />
var thisNodeName = cmdarg().getPath();<br />
var thisNode = props.globals.getNode(thisNodeName);<br />
# Add some useful nodes<br />
<br />
<br />
<br />
########################################################################<br />
########################################################################<br />
# INITIALIZE BOMBABLE<br />
# <br />
# Initialize constants and main routines for maintaining altitude<br />
# relative to ground-level, relocating after file/reset, and <br />
# creating bombable/shootable objects.<br />
# <br />
# These routines are found in FG/nasal/bombable.nas<br />
# <br />
######################################################################## <br />
# INITIALIZE BOMBABLE Object<br />
# This object will be slurped in the object's node as a child<br />
# node named "bombable". <br />
# All distances are specified in meters.<br />
# All altitudes are relative to current ground level at the object's <br />
# location<br />
# <br />
<br />
thisNodeName = cmdarg().getPath(); <br />
<br />
var bombableObject = { <br />
<br />
<br />
objectNodeName : thisNodeName,<br />
objectNode : props.globals.getNode(thisNodeName),<br />
updateTime_s : 1/3, #time, in seconds, between the updates that <br />
#keep the object at its AGL. Tradeoff is high-speed updates look more<br />
#realistic but slow down the framerate/cause jerkiness. Faster-moving<br />
#objects will need more frequent updates to look realistic.<br />
#update time faster than about 1/3 seems to have a noticeable effect<br />
#on frame rate <br />
<br />
<br />
######################################### <br />
# ALTITUDE DEFINITIONS<br />
# <br />
altitudes : { <br />
wheelsOnGroundAGL_m : 1 , #altitude correction to add to your aircraft or ship that is needed to put wheels on ground (or, for a ship, make it float in the water at the correct level). For most objects this is 0 but some models need a small correction to place them exactly at ground level<br />
<br />
minimumAGL_m : 300, #minimum altitude above ground level this object is allowed to fly<br />
maximumAGL_m : 50000, #maximum altitude AGL this object is allowed to fly, ie, operational ceiling <br />
crashedAGL_m : 0.6, #altitude AGL when crashed. Ships will sink to this level, aircraft or vehicles will sink into the ground as landing gear collapses or tires deflate. Should be negative, even just -0.001.<br />
},<br />
# <br />
#########################################<br />
# VELOCITIES DEFINITIONS<br />
# <br />
velocities : { <br />
maxSpeedReduce_percent : 0.5, #max % to reduce speed, per step, when damaged<br />
minSpeed_kt : 112, #minimum speed to reduce to when damaged. Ground vehicles and ships might stop completely when damaged but aircraft will need a minimum speed so they keep moving until they hit the ground.<br />
cruiseSpeed_kt : 550, #cruising speed, typical/optimal cruising speed, V C for aircraft<br />
<br />
attackSpeed_kt : 900, #typical/optimal speed when aggressively attacking or evading, in<br />
#level flight for aircraft<br />
<br />
maxSpeed_kt : 1400 , #Maximum possible speed under dive or downhill conditions, V NE for aircraft<br />
<br />
damagedAltitudeChangeMaxRate_meterspersecond : 30, #max rate to sink or fly downwards when damaged, in meters/second<br />
<br />
#The terminal velocities are calculated by opening the 'real' AC <br />
#in FG, level flight, full throttle, then putting<br />
#the AC at different angles of attack with the autopilot,<br />
#and noting the terminal airspeed & vertical speed velocities.<br />
#For best results, do it near sea level, under 5000 feet altitude.<br />
#One or two each of climb & dive velocities are probably sufficient.<br />
#However if you do more we may be able to use the more precise<br />
#data in the future.<br />
#<br />
#Note that these are intended to be true airspeed whereas FG's<br />
#/velocities/airspeed-kt reports indicated airspeed, so some <br />
#conversion or reference to groundspeed-kt is needed.<br />
# <br />
#In FG /velocities/groundspeed-kt is equal (or close <br />
#to equal, except for wind . . .) true airspeed when pitch=0 <br />
#but as pitch increases or decreases that will change.<br />
# <br />
diveTerminalVelocities: {<br />
point1: { airspeed_kt : 1060, vertical_speed_fps : - 337},<br />
point2: { airspeed_kt : 1230, vertical_speed_fps : - 755},<br />
<br />
},<br />
<br />
climbTerminalVelocities: {<br />
point1: { airspeed_kt : 468, vertical_speed_fps : 236},<br />
point2: { airspeed_kt : 843, vertical_speed_fps : 251},<br />
#point3: { airspeed_kt : 1100, vertical_speed_fps : 161},<br />
<br />
},<br />
<br />
},<br />
# <br />
#########################################<br />
# EVASION DEFINITIONS<br />
# <br />
# The evasion system makes the AI aircraft dodge when they come under<br />
# fire. <br />
evasions : { <br />
dodgeDelayMax_sec : 15, #max time to delay/wait between dodges<br />
dodgeDelayMin_sec : 5, #minimum time to delay/wait between dodges<br />
dodgeMax_deg : 88, #Max amount to turn when dodging<br />
#90 degrees = instant turn, unrealistic<br />
#up to 80 is usually OK, somewhere in 80-85 starts to be unrealistically fast<br />
#>85 is usually very unrealistic. You must test this in your scenario, however.<br />
<br />
dodgeMin_deg : 83, #minimum amount to turn when dodging <br />
rollRateMax_degpersec : 300, #you can figure this out by rolling the corresponding FG aircraft and timing a 180 or 360 deg roll <br />
dodgeROverLPreference_percent : 50, # Preference for right turns vs. left when dodging. 90% means 90% right turns, 50% means 50% right turns.<br />
dodgeAltMin_m : -8000, #Aircraft will begin to move up or down <br />
dodgeAltMax_m : 8000, #Max & Min are relative to current alt <br />
dodgeVertSpeedClimb_mps : 1500, #Max speed to climb when evading<br />
dodgeVertSpeedDive_mps : 1500, #Max speed to dive when evading <br />
},<br />
# <br />
#########################################<br />
# ATTACK DEFINITIONS<br />
# <br />
# The attack system makes the AI aircraft turn and fly towards <br />
# other aircraft <br />
attacks : { <br />
maxDistance_m : 30000, #max distance to turn & attack main aircraft<br />
minDistance_m : 4000, #min distance to turn & attack main aircraft, ie, fly away this far before turning to attack again<br />
continueAttackAngle_deg : 80, #when within minDistance_m, the aircraft will continue to turn towards the main aircraft and attack *if* if the angle is less than this amount from dead ahead<br />
altitudeHigherCutoff_m : 30000, # will attack the main aircraft unless this amount higher than it or more<br />
altitudeLowerCutoff_m : 30000, # will attack the main aircraft unless this amount lower than it or more<br />
climbPower : 8000, # How powerful the aircraft is when climbing during an attack; 4000 would be typical for, say a Zero--scale accordingly for others; higher is stronger<br />
divePower : 10000, # How powerful the aircraft is when diving during and attack; 6000 typical of a Zero--could be much more than climbPower if the aircraft is a weak climber but a strong diver <br />
rollMin_deg : 82, #when turning on attack, roll to this angle min<br />
#for sedate, Cessna-like manuevers make rollMin low. If you want an aggressive,<br />
#attacking, aiming fighter keep it close to rollMax, or even almost equal to rollMax <br />
rollMax_deg : 87, #when turning on attack, roll to this angle max<br />
#90 degrees = instant turn, unrealistic<br />
#up to 80 might be OK, depending on aircraft & speed; somewhere in 80-85 starts to be unrealistically fast<br />
#>85 is usually very unrealistic. You must test this in your scenario, however.<br />
rollRateMax_degpersec : 120, #you can figure this out by rolling the corresponding FG aircraft and timing a 180 or 360 deg roll <br />
attackCheckTime_sec : 10, # check for need to attack/correct course this often <br />
attackCheckTimeEngaged_sec : 0.5, # once engaged with enemy, check/update course this frequently<br />
<br />
},<br />
<br />
# <br />
#########################################<br />
# WEAPONS DEFINITIONS<br />
# <br />
# The weapons system makes the AI aircraft fire on the main aircraft <br />
# You can define any number of weapons--just enclose each in curly brackets<br />
# and separate with commas (,). <br />
weapons : {<br />
front_gun : #internal name - this can be any name you want; must be a valid nasal variable name<br />
{ <br />
name : "Machine Gun", # name presented to users, ie in on-screen messages<br />
maxDamage_percent : 5, # maximum percentage damage one hit from the aircraft's main weapon/machine guns will do to an opponent<br />
maxDamageDistance_m : 2000, # maximum distance at which the aircrafts main weapon/maching guns will be able to damage an opponent<br />
weaponAngle_deg : { heading: 0, elevation: 0 }, # direction the aircraft's main weapon is aimed. <br />
# 0,0 = straight ahead, 90,0=directly right, 0,90=directly up, 0,180=directly back, etc.<br />
weaponOffset_m : {x:2, y:0, z:0}, # Offset of the weapon from the main aircraft center<br />
weaponSize_m : {start:.1, end:.1}, # Visual size of the weapon's projectile, in meters, at start & end of its path<br />
<br />
}, <br />
sidewinder_missile : #internal name - this can be any name you want; must be a valid nasal variable name<br />
{ <br />
name : "Sidewinder guided missile", # name presented to users, ie in on-screen messages<br />
maxDamage_percent : 40, # maximum percentage damage one hit from the aircraft's main weapon/machine guns will do to an opponent<br />
maxDamageDistance_m : 6000, # maximum distance at which the aircrafts main weapon/machine guns will be able to damage an opponent<br />
weaponAngle_deg : { heading: 0, elevation: 0 }, # direction the aircraft's main weapon is aimed. <br />
# 0,0 = straight ahead, 90,0=directly right, 0,90=directly up, 0,180=directly back, etc.<br />
weaponOffset_m : {x:2, y:0, z:0}, # Offset of the weapon from the main aircraft center<br />
weaponSize_m : {start:1, end:1}, # Visual size of the weapon's projectile, in meters, at start & end of its path<br />
<br />
}, <br />
<br />
<br />
}, <br />
<br />
# <br />
#########################################<br />
# DIMENSION DEFINITIONS<br />
#<br />
# All dimensions are in meters<br />
# <br />
# <br />
dimensions : { <br />
width_m : 17.53, #width of your object, ie, for aircraft, wingspan<br />
length_m : 16.26, #length of your object, ie, for aircraft, distance nose to tail<br />
height_m : 4.47, #height of your object, ie, for aircraft ground to highest point when sitting on runway<br />
<br />
damageRadius_m : 8, #typically 1/2 the longest dimension of the object. Hits within this distance of the <br />
#center of object have some possibility of damage<br />
vitalDamageRadius_m : 2, #typically the radius of the fuselage or cockpit or other most <br />
# vital area at the center of the object. Always smaller than damageRadius_m<br />
<br />
crashRadius_m : 6, #It's a crash if the main aircraft hits in this area.<br />
<br />
},<br />
#<br />
#########################################<br />
# VULNERABILITIES DEFINITIONS <br />
#<br />
vulnerabilities : { <br />
damageVulnerability : 9, #Vulnerability to damage from armament, 1=normal M1 tank; higher to make objects easier to kill and lower to make them more difficult. This is a multiplier, so 5 means 5X easier to kill than an M1, 1/5 means 5X harder to kill. <br />
<br />
engineDamageVulnerability_percent : 6, #Chance that a small-caliber machine-gun round will damage the engine. <br />
<br />
fireVulnerability_percent : 5, #Vulnerability to catching on fire. 100% means even the slightest impact will set it on fire; 20% means quite difficult to set on fire; 0% means set on fire only when completely damaged; -1% means never set on fire. <br />
<br />
fireDamageRate_percentpersecond : .1, #Amount of damage to add, per second, when on fire. 100%=completely damaged. Warthog is relatively damage-resistant.<br />
<br />
fireExtinguishMaxTime_seconds : 80, #Once a fire starts, for this many seconds there is a chance to put out the fire; fires lasting longer than this won't be put out until the object burns out.<br />
<br />
fireExtinguishSuccess_percentage : 45, #Chance of the crew putting out the fire within the MaxTime above. Warthoge is relatively damage-resistant.<br />
<br />
explosiveMass_kg : 27772 , #mass of the object in KG, but give at least a 2-10X bonus to anything carrying flammables or high explosives.<br />
},<br />
#<br />
#########################################<br />
# LIVERY DEFINITIONS<br />
#<br />
# Path to livery files to use at different damage levels.<br />
# Path is relative to the AI aircraft's directory.<br />
# The object will start with the first livery listed and <br />
# change to succeeding liveries as the damage<br />
# level increases. The final livery should indicate full damage/<br />
# object destroyed. <br />
# <br />
# If you don't want to specify any special liveries simply set <br />
# damageLivery : nil and the object's normal livery will be used. <br />
# <br />
damageLiveries : {<br />
damageLivery : [ ] <br />
},<br />
<br />
};<br />
<br />
#########################################<br />
# INITIALIZE ROUTINES<br />
# <br />
# OVERALL INITIALIZER: Needed to make all the others work<br />
bombable.initialize ( bombableObject );<br />
#<br />
# LOCATION: Relocate object to maintain its position after file/reset <br />
# (best not used for airplanes)<br />
# bombable.location_init ( thisNodeName );<br />
#<br />
# GROUND: Keep object at altitude relative to ground level<br />
bombable.ground_init ( thisNodeName );<br />
#<br />
# ATTACK: Make the object attack the main aircraft <br />
bombable.attack_init ( thisNodeName );<br />
#<br />
# WEAPONS: Make the object shoot the main aircraft <br />
bombable.weapons_init ( thisNodeName ); <br />
#<br />
# BOMBABLE: Make the object bombable/damageable <br />
bombable.bombable_init ( thisNodeName );<br />
#<br />
# SMOKE/CONTRAIL: Start a flare, contrail, smoke trail, or exhaust <br />
# trail for the object.<br />
# Smoke types available: flare, jetcontrail, pistonexhaust, smoketrail,<br />
# damagedengine <br />
bombable.startSmoke("jetcontrail", thisNodeName );<br />
#F-15E already has contrails, we're leaving this out<br />
#<br />
# END INITIALIZE BOMBABLE<br />
########################################################################<br />
######################################################################## <br />
<br />
<br />
<br />
}<br />
<br />
object_init();<br />
]]><br />
</load><br />
<unload><br />
<![CDATA[<br />
print("Unload F-15E.");<br />
var nodeName= cmdarg().getPath(); <br />
bombable.de_overall_initialize( nodeName );<br />
bombable.initialize_del( nodeName );<br />
bombable.ground_del( nodeName );<br />
bombable.location_del (nodeName);<br />
bombable.bombable_del( nodeName );<br />
bombable.attack_del( nodeName );<br />
bombable.weapons_del (nodeName); <br />
# </unload><br />
<br />
]]><br />
</unload><br />
</nasal> <br />
<br />
</PropertyList><br />
<br />
Save this file with the name you have chosen ( FGDATA\Aircraft\F-15E\Models\F-15E_StrikeEagle-bombableinclude.xml).<br />
<br />
===Link the -bombableinclude.xml file to the existing F-15 model file===<br />
<br />
Now that we have created the -bombableinclude.xml file, we need to set up the aircraft to load the file on startup.<br />
<br />
AI scenarios (and MP aircraft) load the aircraft's model file. So we need to locate that file and include the new -bombableinclude.xml file in it.<br />
<br />
Where is the model file? Look in the aircraft's -set.xml file. In that file will be a section called <model>. For the F-15E it looks like this:<br />
<br />
<model><br />
<path>Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</path><br />
</model><br />
<br />
So Aircraft/F-15E/Models/F-15E_StrikeEagle.xml is our model file. <br />
<br />
<br />
Load Aircraft/F-15E/Models/F-15E_StrikeEagle.xml in a text editor. At the beginning of that file you will find this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList><br />
<br />
Change it to this:<br />
<br />
<?xml version="1.0"?><br />
<br />
<PropertyList include="F-15E_StrikeEagle-bombableinclude.xml"><br />
<br />
Save the file.<br />
<br />
===Notes===<br />
* The statement include="F-15E_StrikeEagle-bombableinclude.xml" indicates that F-15E_StrikeEagle-bombableinclude.xml will be in the same directory as F-15E_StrikeEagle.xml. That directory is Aircraft/F-15E/Models -- so make sure that the -bombableinclude.xml file is indeed in that directory!<br />
<br />
* Model files can have only ONE Nasal <load> section and one <unload> section.<br />
<br />
If you have more than one, the second and subsequent <load>/<unload> sections are ignored.<br />
<br />
The problem? Your aircraft may already have a <load> or <unload> section. When you add the Bombable code, one of the two <load> sections (the pre-existing one or Bombable's) will be ignored.<br />
<br />
The solution is to combine the two <load> sections into one, and the same with the <unload> sections. You'll need to know a little about [[Nasal]] programming to do anything complicated, but as a rule you can just copy/paste whatever is in the aircraft's <load> section to the start of Bombable's <load> section, and the same with <unload>.<br />
<br />
* You'll notice the Nasal code starts with ''<![CDATA['' and ends with '']]>''. That is needed to make Nasal code work within XML files. [http://www.w3schools.com/xml/xml_cdata.asp CDATA usage is explained here.]<br />
<br />
==STEP 4. Add to an AI Scenario==<br />
Now we can add the F-15E to an AI scenario.<br />
<br />
Create a file named F-15E-demo.xml and save it in your FGDATA/AI directory.<br />
<br />
Most of the entries in the scenario file are self-explanatory. For the <model> entry you'll need the path of the same model file for the F-15 that we located in Step 3--which is Aircraft/F-15E/Models/F-15E_StrikeEagle.xml.<br />
<br />
Here is how the file should look when you are done:<br />
<br />
<?xml version="1.0"?><br />
<PropertyList><br />
<scenario><br />
<description>My new F-15E scenario. Starts at KSFO! </description><br />
<br />
<entry><br />
<type>aircraft</type><br />
<callsign>Jones</callsign><br />
<name>F15E Leader</name><br />
<model type="string">Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model><br />
<latitude type="double">37.608720</latitude><br />
<longitude type="double">-122.3076</longitude><br />
<altitude type="double">309</altitude><br />
<speed>280.0</speed><br />
<heading type="double">192</heading><br />
</entry><br />
<br />
<entry><br />
<type>aircraft</type><br />
<callsign>Cooper</callsign><br />
<name>F15E Wingman</name><br />
<model type="string">Aircraft/F-15E/Models/F-15E_StrikeEagle.xml</model><br />
<latitude type="double">37.608200</latitude><br />
<longitude type="double">-122.2988</longitude><br />
<altitude type="double">309</altitude><br />
<speed>270.0</speed><br />
<heading type="double">192</heading><br />
</entry><br />
<scenario><br />
<br />
</PropertyList><br />
<br />
Again, save as FGDATA/AI/F-15E-demo.xml. When you start FGRun next time, F-15E-demo will be listed as one of the scenario file options. (You may need to quit and re-start FGRun.)<br />
<br />
==STEP 5. Troubleshooting==<br />
OK, we're done. Time to fly our new aircraft in our new scenario!<br />
<br />
Oh, yeah . . . we just followed a very complicated process with numerous steps that could go wrong. Maybe we'd better test a bit first.<br />
<br />
Start Flightgear. Using FGRun:<br />
<br />
1. Choose ''UFO bombable'' as the main aircraft (best for testing . . . )<br />
2. Airport KSFO<br />
3. Scenario F-15-demo (which we just created--if saved correctly in the FGDATA/AI directory, it will show up in the scenario list of FGRun)<br />
4. Click "Run"<br />
5. Closely watch the command console as FG starts. You may pick up important errors in XML files and/or Nasal code.<br />
6. You should see<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
<br />
Uh-oh. There is our first error. f-15-demo.xml, line 31, column 2, I have "<scenario>" rather than "</scenario>".<br />
<br />
I fix, save the fixed file, and re-start. Now I get:<br />
<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
* Failed to load XML: . . . F-15E-StrikeEagle-bombableinclude.xml<br />
<br />
OK, this is typical. There is a typo or stray character on the .xml file . . . or something.<br />
<br />
After a few minutes of trying different things, I discover I've made a typo:<br />
<br />
* In \Aircraft\F-15E\Models\F-15E_StrikeEagle.xml is this line:<br />
<PropertyList include="F-15E_StrikeEagle-bombableinclude.xml"><br />
* But I've saved the file as <br />
FGDATA/Aircraft/F-15E/F-15-StrikeEagle-bombableinclude.xml<br />
<br />
OK, that one little "E" made all the difference. I change the filename to match what's in the -set.xml file and try again.<br />
<br />
And finally:<br />
<br />
* Bombable (ver. 4.4) loaded . . . <br />
* loading scenario "f-15-demo"<br />
* Loading F-15E /ai/models/aircraft<br />
* Loading F-15E /ai/models/aircraft[1]<br />
* A bunch of other Bombable messages showing the aircraft initializing (I have Bombable menu/Debug turned on, which is helpful at this stage)<br />
* A bunch of error messages showing various animations and systems not load (ahhh . . . that's why we create stripped-down versions of aircraft in the AI/Aircraft directory--a completely separate and even longer article).<br />
<br />
I open Equipment/Maps, click "traffic", see the two aircraft "Jones" and "Cooper", track them down with the UFO, they show proper smoke trails, I shoot at them, I shoot them down. It works!<br />
<br />
Success!<br />
<br />
Well, except . . . are they flying realistically? Climbing, turning, diving, shooting? Are they taking damage realistically? Does it work properly under Multiplayer?<br />
<br />
Here is where you spend hours researching real F-15s, flying against the AI models with the UFO and other aircraft, tweaking parameters in the -bombableinclude.xml file, and so on and on.<br />
<br />
You're just getting started. <br />
<br />
Good luck!<br />
<br />
===Testing/parsing XML files===<br />
One final tip: XML files are extremely persnickety. Just one wrong character can make an entire file fail to load. <br />
<br />
The best/easiest way to test XML files is load them in Internet Explorer. It will parse the XML file and display any errors it finds. (If you don't have access to IE there are other XML parsers available.) This is far easier and faster than starting and re-starting FG repeatedly, and IE gives better, more informative error messages as well.<br />
<br />
==IMPORTANT POSTSCRIPT: Where your aircraft files are==<br />
An important detail in getting Bombable to work with aircraft over AI and MP is the directories you store the files in and the names you choose to use for them.<br />
<br />
FlightGear stores aircraft and AI aircraft files in at least two different places.<br />
<br />
In a typical FG installation, in your FGDATA folder, you will find<br />
<br />
* FGDATA/Aircraft<br />
* FGDATA/AI/Aircraft<br />
<br />
FGDATA/Aircraft holds files for the main aircraft whereas FGDATA/AI/Aircraft holds files for AI and MP aircraft.<br />
<br />
AI/MP aircraft don't have all the features of main aircraft, so you might find the very same aircraft in FGDATA/Aircraft and in FGDATA/AI/Aircraft--but the one in FGDATA/AI/Aircraft will be very stripped down, fewer files, smaller, and less complex.<br />
<br />
When building a [[AI_Systems#AI_Models|FlightGear AI scenario]], you can specify the exact path and filename of the file FlightGear looks for. You can specify a file in the FGDATA/Aircraft directory, or in the FGDATA/AI/Aircraft, or really anywhere within the FGDATA directory that you like. Examples:<br />
<br />
<model type="string">AI/Aircraft/sopwithCamel-Bombable/Models/sopwithCamel-model.xml</model> <br />
<br />
OR<br />
<br />
<model type="string">Aircraft/sopwithCamel-Bombable/Models/sopwithCamel-model.xml</model> <br />
<br />
When loading an MP aircraft, FlightGear first looks for the (typically smaller/simpler) aircraft file in FGDATA/AI/Aircraft.<br />
<br />
If it doesn't find the aircraft there, it then searches FGDATA/Aircraft.<br />
<br />
===How FG matches Multiplayer Aircraft with your local AI aircraft models===<br />
<br />
As of version 2.4.0, when FG is looking for the local AI aircraft model to display for a remote aircraft over Multiplayer, FG searches first the AI Aircraft directories, then the Aircraft directories.<br />
<br />
It searches for a match by looking for the file with a name exactly matching the MP aircraft's model (this is typically in the aircraft's Models subdirectory and ends with .ac, though this may vary) and if that fails, FG looks for a matching -set.xml file.<br />
<br />
The important points for making AI models that will work over MP with Bombable: <br />
<br />
* Make sure the main aircraft and the AI version of the aircraft have the exact same names for the aircraft's model file and the aircraft's -set.xml<br />
<br />
* If you're modding an existing but non-bombable-compatible aircraft, you need to decide whether you're going to leave all the directories, model XML file names, and -set.xml file names the same as the standard flightgear aircraft (leading to possible frustration as your version overwrites existing aircraft files on users hard drivers) OR rename the aircraft's directory, -set.xml file name, and model file name (which means you're going to have to do a bit of work on the aircraft's XML files to make sure everything still works with all those name changes.<br />
<br />
* You can create a separate, stripped down AI version of the aircraft in the FGDATA/AI/Aircraft directory and add the Bombable additions to it (more work for you but smaller/quicker download and easier on the memory and framerate in FG) OR you can simply add all the Bombable additions to the main aircraft directory in FGDATA/Aircraft.<br />
<br />
Bombable will work with any of those options--so it is really up to you.<br />
<br />
==EXTRA: Making livery change with damage==<br />
<br />
Once you have Bombable working with your aircraft there is a bonus: bombable.nas will handle setting the livery colors and<br />
automatically changing them as the object becomes damaged. <br />
<br />
For an example of how this works and looks, take a look at the Bombable scenarios involving the M1 tank and the Jeep.<br />
<br />
For this to work your model must have different liveries available<br />
and then animate the liveries so that the texture used is the one shown<br />
in this path: /ai/model/model[X]/bombable/texture-corps-path. The /ai/model/model[X]/ part is assumed for AI craft so you need to add <texture-prop>bombable/texture-corps-path</texture-prop> in the right place of your XML file. <br />
<br />
Example from Jeep.xml in the jeep-bombable directory:<br />
<br />
<animation><br />
<type>material</type><br />
<object-name>jeep-body</object-name><br />
<object-name>roof1</object-name><br />
<object-name>roof2</object-name><br />
<object-name>softroof</object-name><br />
<object-name>chassis</object-name><br />
<object-name>chassis.002</object-name><br />
<object-name>Plane</object-name><br />
<object-name>hinge</object-name><br />
<object-name>screen</object-name><br />
<object-name>wiper.L</object-name><br />
<object-name>wiper.R</object-name><br />
<object-name>seat.L</object-name><br />
<object-name>seat.R</object-name><br />
<texture-prop>bombable/texture-corps-path</texture-prop><br />
<transparency><br />
<alpha>1.0</alpha><br />
</transparency><br />
</animation><br />
<br />
<br />
Additionally, if you want to change your object's the livery color programmatically (for instance, if you include a menu item to select different liveries) you can use the following code in the -bombableinclude.xml file (see above) to change all liveries, including damage liveries, that the object uses:<br />
<br />
Example:<br />
liveries = [<br />
"Models/livery_nodamage.png", <br />
"Models/livery_slightdamage.png", <br />
"Models/livery_highdamage.png");<br />
];<br />
<br />
bombable.set_livery (cmdarg().getPath(), liveries); <br />
<br />
You can include liveries for as many different levels of damage (ie, fine gradations of change from undamaged to completely damaged) as you like. For instance:<br />
<br />
<br />
Example:<br />
liveries = [<br />
"Models/livery_nodamage.png", <br />
"Models/livery_barelydamaged.png", <br />
"Models/livery_justslightlydamaged.png", <br />
"Models/livery_alittlemoredamage.png", <br />
"Models/livery_fairlydamaged.png", <br />
"Models/livery_kindadamaged.png",<br />
"Models/livery_prettydamaged.png",<br />
"Models/livery_whoawereintroublenow.png", <br />
"Models/livery_finishedoff.png");<br />
];<br />
<br />
bombable.set_livery (cmdarg().getPath(), liveries); <br />
<br />
<br />
<br />
<br />
==Related content==<br />
* [[Bombable]] <br />
* [[Howto:Nasal in scenery object XML files]]<br />
* [[AI Traffic]]<br />
* [[AI Systems#AI Models]]<br />
* [[Howto:Add submodels]]<br />
* [[Howto:Make an aircraft]]<br />
<br />
[[Category:Aircraft enhancement|Bombable]]<br />
[[Category:Bombable]]<br />
[[Category:Nasal howto|Bombable]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Bombable&diff=138352Bombable2023-09-10T01:38:00Z<p>Flug: Added Bombable 5.0, compatible with FG 2020</p>
<hr />
<div>{{Template:Bombable_Navigation}}<br />
{{Infobox subsystem<br />
|image = Bombable4 4 600.png<br />
|name = Bombable Addon<br />
|started = 2009<br />
|description = Addon for FlightGear that adds support for dogfighting, damage, and AI bots.<br />
|status = Under active development (01/2014)<br />
|developers = Flug<br />
|folders = {{github url|user=bhugh|repo=Bombable}}<br />
}}<br />
<br />
[[File:camel-through-wing.jpg|thumb|[[Sopwith Camel]]]]<br />
[[File:spad-vs-camel.jpg|thumb]]<br />
[[File:warthog-down-on-bay-bridge.jpg|thumb|[[A-10 Warthog]]]]<br />
<br />
'''Bombable''' is an addon for [[FlightGear]] that adds bombs, weapons, damage, fire, and explosion effects to FlightGear that work with the main [[aircraft]], [[scenery]], [[AI]] aircraft and other AI objects, and [[multiplayer]] aircraft objects. Bombable turns FlightGear into a combat flight simulator.<br />
<br />
[https://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772#p43772 Download the current version of the Bombable add-on here.]<br />
<br />
== Features ==<br />
* [[Multiplayer]] dogfighting.<br />
* AI scenarios that allow you to use any FlightGear aircraft that can shoot weapons and/or drop bombs for air-to-air, air-to-ground, and anti-maritime combat missions against AI tanks, [[jeep]]s, ships, and aircraft that will fight you.<br />
* Explosion and burning when you crash.<br />
* Damage added to your aircraft when you exceed the [[Howto: Define limits|aircraft's limitations]] (excessive g-force, exceeding V<sub>NE</sub>, etc.).<br />
<br />
== Downloading and using in FlightGear ==<br />
* [http://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772 Download Bombable on the Flightgear Forums thread for Bombable] or [https://github.com/bhugh/Bombable/releases/tag/v5.0 using this direct link]<br />
* Instructions for installing and using Bombable are included in the Docs directory of the download file.<br />
<br />
== List of Bombable Aircraft ==<br />
[[Sopwith Camel]], SPAD VII, [[Fokker Dr.I]] Triplane, [[A6M2 Zero]], F6F Hellcat, [[Fairchild Republic A-10 Thunderbolt II|A-10 Warthog]], [[UFO]], and other included aircraft such the [[Polikarpov I16]].<br />
<br />
== How to add Bombable to a FlightGear aircraft ==<br />
* [[Howto: Adding Bombable to FlightGear Aircraft]]<br />
<br />
== Related articles ==<br />
* [[Howto: Dogfighting over Multiplayer with Bombable]]<br />
* [[Dicta Boelcke]] rules for dogfighting by the WWI aces<br />
* [[Bombable_Development_Roadmap]]<br />
<br />
== Bombable video ==<br />
{{#ev:youtube|PirnWJHZtcg}}<br />
<br />
== Readme ==<br />
* [[Bombable Readme]]<br />
<br />
== History ==<br />
FlightGear seems to have most all the pieces under the hood to make an excellent platform for simulating historical military aircraft, dogfighting and fighter plane tactics with aircraft of different eras, and bombing runs and other tactics from various historical eras, and other aircraft simulations that could depend on FlightGear's realistic, underlying flight models.<br />
<br />
Some aircraft have implemented limited weapons, armament, and explosions. The A-10 Warthog was released, including an AI scenario for the A-10 to bomb M-1 tanks, which then exploded realistically.<br />
<br />
The Bombable add-on was designed to put all the available FlightGear elements together as a proof of concept to see if FlightGear can be a realistic simulator for aircraft that include weapons and armament, working with AI aircraft and over Multiplayer, including:<br />
<br />
* Realistic impact detection and damage assessment<br />
* Damage tracking over AI and Multiplayer and communication of impacts and damage levels over Multiplayer<br />
* AI aircraft, vehicles, and ships that can evade, attack, and generally act realistically<br />
* Explosions, fires, and so on, upon damage and crash<br />
<br />
Bombable was developed with the idea that in a realistic flight simulator environment, the rules and techniques of dogfighting and aerial warfare--like the World War I [[Dicta Boelcke]], by Oswald Boelcke, one of the first great aces of the war--would naturally develop and naturally play out.<br />
<br />
== Status ==<br />
<br />
As of September 2023 (Bombable 5.0) the status is:<br />
<br />
* Bombable is now a standard FlightGear add-on, and compatible with FlightGear 2020<br />
<br />
As of January 2014 (Bombable 4.5) the status is:<br />
* Damage impact detection is the most advanced element in Bombable. It is greatly improved over FG's native impact detection system, and the framework is in place for further refinements or as a model for FG to implement more refined impact detection internally.<br />
<br />
* Damage tracking and communication over Multiplayer works well in a very lightweight with a very low data rate. However, only a general damage percentage is tracked and communicated. Damage to different locations or systems is not simulated.<br />
<br />
* AI aircraft behavior is controlled by a Nasal script that modifies FlightGear's AI system. This is Bombable's weakest point--in many ways the Nasal script is simply fighting the underlying AI code for control of the AI aircraft. Creating more realistic/intelligent AI fighter aircraft will require greater integration with FlightGear's AI systems. That is a problem for programmers--but for users, the AI aircraft now move, attack, and evade with reasonable realism.<br />
<br />
* AI aircraft weapons systems are simulated through a probabilistic approach. And shown visually via FlightGear's Particle System. At this time it appears that creating and tracking AI weapon projectiles via FlightGear's submodel system, which simulates submodel dynamics and impacts precisely, is technically difficult and would have a drastic negative impact on the FlightGear framerate. Bombable follows the more promising of simulating AI weapon fire using FlightGear's particle system, which allows for visual display of numerous moving particles with little to no effect on the framerate and calculating weapons hits mathematically in a simple way that has minimal impact on framerate.<br />
<br />
* '''AI aircraft move vertically &ndash; and do loops''': AI aircraft now move much more realistically in the vertical direction. They do loops, dive, and all the rest. Their behavior (climb rates, dive rates, and so on) matches those of the corresponding FG aircraft. This makes for a much more realistic 3-D dogfighting experience in FlightGear.<br />
<br />
* Proof of concept for explosions, fires, weapons damage animations, and crash animations is in place. All these elements could be refined for greater realism.<br />
<br />
* '''Realistic roll rates for ai aircraft''': Roll rates are one the most important factors determining the effectiveness of fighter aircraft-- aircraft that can roll faster can turn faster. Now the roll rate for AI aircraft in scenarios can be customized, and bugs in the roll & turn routines for AI aircraft have been fixed.<br />
<br />
* '''Significant performance improvements''': Bombable now makes much less of an impact on your framerate, and much less stuttering & slowdown at key points, like when numerous machine gun rounds are impacting.<br />
<br />
* '''Relocate any scenario to your location''': Have an AI scenario based in San Francisco, but want to fly in London? No problem, just hit a button in the Bombable menu and your scenario comes to you, wherever you are. Damage levels for AI aircraft and objects are re-set. It's like loading a new scenario without having to re-start FlightGear.<br />
<br />
* '''Re-spawn AI aircraft & objects''': After you have shot down (or been shot down by!) AI aircraft or objects in scenarios, you can instantly re-spawn them and try again. (Available in the Bombable menu.)<br />
<br />
The last two are kind of game changers. With FG 2.12's ability to load and unload scenarios instantly and easily, and Bombable's ability to move scenarios to wherever you are, anywhere in the world, scenarios are now flexible and moveable.<br />
<br />
== Versions ==<br />
<br />
[https://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772#p43772 Download the current version of the Bombable add-on here.] Below is information about previous versions and updates. <br />
[[File:Bombable-Camel-vs-Camel.png|300px|thumbnail|right|Camel v. Camel in Bombable]]<br />
<br />
=== Version 5.0 (9/2023), compatable with GB 2020 and earlier version that are compatible with addons ===<br />
<br />
=== Version 4.6 (2/2017), compatible with FG 2016.4.4 and earlier versions ===<br />
Small tweaks for 100% compatibility with FG version 3.0 through 2016.4.4.<br />
<br />
=== Version 4.5b (01/2014, compatible with FG 2.12.1 and earlier versions) ===<br />
Version 4.5b works with FG 2.12.x and has some improvements that take advantage of FG 2.12's new AI scenario handling system.<br />
<br />
In addition, 4.5b has some improved aircraft, tweaks AI aircraft performance and realism, and fixes a few bugs.<br />
<br />
=== Version 4.5 (04/2013, compatible with FG 2.10) ===<br />
Flug just uploaded a new version of Bombable that is compatible with FlightGear 2.10.0--in fact, it should work with all 2.X versions of FlightGear.<br />
<br />
http://brenthugh.com/flightgear/bombable4-5.zip<br />
<br />
Thanks to Voudoun da Vinci for helping track down some of the problems and the fixes.<br />
<br />
Bombable is still pretty new to FG 2.10, so please let me know if you find any problems. Message in this thread is the best way.<br />
<br />
FYI part of the package is a new, greatly improved, historically accurate (to the degree I could make it so!) JSBSim FDM for the Sopwith Camel.<br />
<br />
The idea was to make the Camel fly like a real Camel--not just when flying safely well within the envelope like a commercial pilot, but when taking it to the edge and beyond, as real combat pilots did in WWI.<br />
<br />
Not easy to fly--but a lot of fun to try. It's SopwithCamel-Bombable (JSBSim), included in the Bombable distribution.<br />
<br />
Bombable is now compatible with FG 2.10 (as well as 2.8, 2.6 and earlier versions) and includes a new, far more realistic and true-to-life JSBSim flight model for the Sopwith Camel.<br />
<br />
* The new JSBSim version of Sopwith Camel is far more realistic as a fighter aircraft, implementing nearly every documented flight characteristic of the original Camel. The new JSBSim Camel is very quirky and difficult to fly--just as the original Camel was. See separate file documenting the JSBSim flight model. To try the new Camel flight model, in FGRun select:<br />
<br />
* sopwithCamel-Bombable<br />
* Sopwith Camel 1F.1 (JSBSim, Experimental, Guns/Bombable)<br />
<br />
* Improvements to make Bombable more compatible with FG 2.10 (as well as 2.6 and 2.8):<br />
<br />
* Continue to refined workaround for the FG bug allowing only one particlesystem per XML file. <br />
<br />
* Workarounds for a stricter XML parser that was adopted by FG somewhere between FG 2.4 and 2.10. Several of the aircraft XML files would not parse due to the special or foreign characters included in comments. <br />
<br />
* Updated sound files to mono format (required by FG 2.10 3-D sound system).<br />
<br />
* Minor updates/bugfixes to aircraft, scenarios<br />
<br />
=== Version 4.4 ===<br />
Version 4.4 is a complete revamping of Bombable into more of a complete, cohesive system for Multiplayer and AI dogfighting and bombing. The accuracy of all the basic functions has been improved and made more realistic, and a number of new "Bombable- compatible" aircraft have been included, from WWI fighters to modern-day jet fighters.<br />
<br />
* '''Weapon hit detection greatly improved''': Complete re-vamped system for detecting your weapon hits on AI or Multiplayeraircraft. It is no longer limited by FG's built-in, large "damage cylinder". It now extends the weapon's flight path within that cylinder to determine precisely how close the weapon hit on your target--allowing muchbetter modeling of hits, damage, and results.<br />
<br />
* '''Damage analysis system greatly improved''': In addition, the damage analysis system has been updated to calculate and use the momentum of weapons as the basis for determing damage of weapon hits. This has proven to be far more realistic and gives much better results thanthe previous ad-hoc method.<br />
<br />
* '''Greatly improved damage impact animations''': Previous versions of Bombable relied on FG's built-in impact animations. The result was that FG often showed the damage impact explosion when the projectile had actually made a clean miss of the aircraft. In Bombable 4.4, this problem is solved, with impact explosions being shown exactly where Bombable calculates they happen, and only when Bombable detects an actual hit with damage. So you have much tigher correspondence between what you see and whatdamage is recorded.<br />
<br />
* The impact animations work for all types of small and large caliber guns and bombs. The system uses FG's excellent particle system to draw the gun and bomb impacts with almost not impact on framerate, and far less jerkiness than FG's usual submodel method. As a bonus, the new animations look much, much better as well, and the visual of the impact matches the actual damage of the impact quite well--that is, the visual size of a bomb explosion closely matches the actual damage area of the bomb; small caliber weapons hits show as smallerimpacts that large caliber weapons, etc.<br />
<br />
* '''Your own weapons can damage you''': Drop a bomb on your own aircraft or too near it? You'll see the results--damage to your aircraft. This makes bombing runs far more realistic--if you get too close to the bomb impact, you'll feel the results.<br />
<br />
* '''Impact visuals, smoke, and fire shown on scenery''': If you drop a bomb on a scenery or a building, you see an explosion and a long-lasting fire &ndash; just as you do when you bomb a jeep, tank, or airplane. Previously, the bombs, guns, rockets, and other armament only had an effect on AI and MP aircraft, tanks, ships, and so on. Now armament hits affect almost everything in the FlightGear world.<br />
<br />
* '''Re-spawn AI aircraft''': After you have shot down (or been shot down by!) AI aircraft in scenarios, you can instantly re-spawn them and try again. (Available in the Bombable menu.)<br />
<br />
* '''Bombable Fokker DR.1 fixed''': Fixed/update the Fokker Dr.1 aircraft. It is now the same aircraft as distributed in FG 2.4.0 but with added historically accurate guns and an aircraft help file.<br />
<br />
* '''Bombable Grumman F6F Hellcat added''': Added a new Bombable-compatible aircraft, the Grumman F6F Hellcat. This makes a great foil to the A6M2 Zero, as they fought against each other in WWII. (As always, mucho thanks must go to the authors of the F6F aircraft--all I've done is update the weaponry to be historically accurate and add a thin veneer of tweaks to make the aircraft completely compatible with Bombable. All credit for aircraft design, systems, FDM, and everything else goes to the original authors, in this case EmanuelBaranger and others.)<br />
<br />
* '''New scenarios''': New scenario to show off the F6F, one to show offthe Bombable UFO, and one to help with testing: <br />
** BOMB-LakeTahoeWWIIB17BombersWithF6FCover.xml<br />
** BOMB-MarinCountyUFOInvasion.xml<br />
** BOMB-Kansas-City-Bombable-Testbed.xml <br />
<br />
* '''Bombable A-10 Warthog added''': The A-10 is the best plane to fly several scenarios and including it in the package means that it can be used to fly multiplayer bombable as well. It has several tweaks making it easier to use with the Bombable package and also improves an annoying bug where the A-10 slows FG's framerate massively after a few re-init/re-locates. (Again, all credit to the A-10 original authors--all I have done is adda few Bombable tweaks and specifics.)<br />
<br />
* '''Bombable UFO added''': This is mostly for testing; keys 1-9, 0, q, and w fire different weapons. A working AI version is included--so you can have dueling Bombable UFOs over Multiplayer or try the UFO dogfighting scenario (surprisingly fun!). Also a testbed scenario is included, and using the UFO with the BOMB-Kansas-City-Bombable-Testbed.xml scenario is the easiest way to test most Bombable functions, aircraft, and AI aircraft. (Based on FG's stock UFO, but with Bombable capabilitiesadded.)<br />
<br />
* '''Bomb damage''': Reconfigured damage impact of bombs; the bombs now act--lookand create damage--far closer to real data.<br />
<br />
* '''New menu''': Re-vamped Bombable menu with new/streamlined/more sensible options.<br />
<br />
* '''Reset damage''': In the new Bombable menu you can reset damage for main aircraft and AI aircraft and objects.<br />
<br />
* '''Bombable scenarios renamed''': Renamed all scenarios that come with the package with prefix "BOMB-". This should make it easier to find the scenarios and also update or remove them when necessary.<br />
<br />
* '''Smaller smoke/fire option''': A small fire option, used where appropriate, so that fires/explosions/damage don't always look sooverly huge.<br />
<br />
* '''Unusable aircraft removed''': Removed unused/unusable aircraft from the distribution. Some of these are perfectly fine for general flying, but weapons or other features don't work well with Bombable, and having them listed in the menus when they didn't really work made forconfusion.<br />
<br />
* '''Scenario fixes''': Some scenarios were not loading properly for some people in ver. 4.3. This might be because of inconsistencies in the case of some file and directory names. I worked on resolving thisissue, but please let me know if it is still happening.<br />
<br />
* '''Scenarios renamed''': Renamed all scenarios to start with "BOMB-". This should help us keep straight which scenarios work with Bombable and also troubleshoot and track down & fix problems with scenarios.<br />
<br />
* '''AI weapons improved''': AI weapons now malfunction when the AI aircraft, vehicle, or ship is damaged.<br />
<br />
* '''Misc. updates''': Updated included AI aircraft and scenarios to fit with the new impact detection system.<br />
<br />
* '''For bombable aircraft designers''': If you have designed aircraft to use with Bombable, you should look at the sample AI aircraft provided to see updates to the Bombable dimensions, vulnerabilities, and weapons sections. You will need to re-tool your aircraft slightly, but when finished the results will be much better.<br />
<br />
* '''Bug fixes''': Various small bug fixed and improvements, fixed a lot of the programs with scenarios, AI Aircraft, directories.<br />
<br />
See the To Do file (many of which have now been done) for many more changes, updates, and improvements.<br />
<br />
=== Version 4.3 ===<br />
* Multiplayer dogfighting is now working in FG 2.4.0. (It broke sometime in the FG 2.X.X. series.) Use one of the MP-dogfighting- enabled planes included in the packet (Sopwith Camel-Bombable/Yasim, SPAD VII-Bombable, or FKDR1-Bombable/JSB, or A6M2-Bombable/YASim--use the versions marked as Guns/Bombable, not the default FG installs) and make sure your opponent does the same--you will both be able to shoot and damage each other, see damage reports, etc.<br />
<br />
* Weapons on AI aircraft--which will shoot at you as you attack them--can now be placed in different locations and aimed indifferent directions.<br />
<br />
In combat, they will shoot you if that location/direction is lined up with you. The AI B-17 Bomber included in the package will shoot at you from the rear; the M-1 tank will shoot towards the front at about a 45 degree angle, Jeep will shoot forwards and upwards,Ferries will shoot forward or backwards, etc.<br />
<br />
The result is a far more realistic experience. Shooting bombers used to be like shooting fish in a barrel--now between the bombers shooting at you and the fighter planes coming in from high cover, you're lucky to score a few small hits and get out of therealive . . .<br />
<br />
* The AI Weapons system was generally improved and weapon strength, direction, size, location, and effectiveness can be specified in the XML file for each AI aircraft type. (If you're creating your own Bombable-enable aircraft, just add weapons specs in the WEAPONSsection of AI aircraft; see enclosed AI/Aircraft files for examples.)<br />
<br />
* Generally tweaked AI aircraft, attack & weapons routines, and AI scenarios for a better, more realistic experience. In particular,try:<br />
** MarinCountyWWIIBombersWithCover.xml (fly A6M2-Bombable/YASim)<br />
** MarinCountyCamelInvasion1-Simple.xml (fly Sopwith Camel-Bombable/YASim) <br />
<br />
* Again worked on the problem of getting AI aircraft to climb and dive more realistically instead of sedately. The AI aircraft are farmore realistic/active in the vertical direction now.<br />
<br />
* Bombable no longer overwrites existing aircraft or anything else in FG's installation. It will add new aircraft and a few other Bombable-specific files. All new/added aircraft have the suffix -Bombable. Bombable will overwrite-replace things from its ownprevious installation, but no other files.<br />
<br />
Generally when flying Bombable's AI scenarios or flying over multiplayer with another person using Bombable, your best experience will be to use one of the aircraft provided (and identifiable by the -Bombable extension) or another aircraftspecifically set up to use Bombable's capabilities.<br />
<br />
=== Version 4.2 ===<br />
* Made numerous changes/updates/improvements related to getting Bombable working with FG 2.4.0.<br />
<br />
* Found the FG 2.4.0 "reinit" problem in both M-1 and Jeep in AI/Aircraft & fixed<br />
<br />
* Reconfigured the damage calculations for light weapons in the test_impact function. Result may be that it is harder/takes more hits than before to damage aircraft or objects. If it is too hard you can select both "Easy Mode" and "Super Easy Mode" together to make it quite a bit easier to both hit targets and create damage. This still needs some refinement but it is setting the groundworkfor a better, more consistent way of dealing with damage.<br />
<br />
* Small refinements in display, damage reports, etc.<br />
<br />
* FG 2.4.0 is doing this crazy thing where it reinitializes AI objects in scenario repeatedly and also (sometimes!) slips in non-AI objects like joystick inputs for initialization as AI/scenario objects. This results in massive slowdowns and other bizarre behavior. So I've set up checks to disallow repeated re-inits of AI objects and only allow AI and Multiplayer objects (as opposed joystick input devices, etc) to initialize themselves with Bombable. The ultimate solution here is a FG code fix, but in the meanwhilesome of the worst effects might be mitigated.<br />
<br />
=== Version 4.0 ===<br />
This is a beta release that works with Flightgear 2.4.0. Some AI aircraft characteristics have changed in FG 2.4.0 so there are someproblems and different behavior in the AI aircraft.<br />
<br />
* Removed the "reinit" command in bombable.nas that made FG 2.4.0 croak.<br />
<br />
* Removed the mp_broadcast.nas file that is no longer necessary with FG 2.4.0 (and in fact the old version included with Bombable made FG2.4.0 choke).<br />
<br />
* FG 2.4.0 doesn't make the weight or mass of the armament available on impact (previous versions}}} did!), so a kludgy work-around wascreated.<br />
<br />
* Numerous other tweaks and bug fixes.<br />
<br />
=== Version 3.0p ===<br />
* This is a bit of an alpha release and has not been as thoroughly tested with all scenarios as previous releases.<br />
<br />
* '''AI aircraft are more mobile vertically''': AI Aircraft dodge and chase you more vertically, diving and climbing.<br />
<br />
* '''Various bugfixes'''<br />
<br />
=== Version 3.0o ===<br />
* '''AI aircraft shoot at and damage you''': When in an AI dogfight, if you let the AI aircraft get into position they have a chance to shoot at and possibly damage you. This is working best with WWI AI Aircraft (Camel, SPAD, Fokker) as in the Marin County Camel Invasion scenarios, but it will also work with the Zero and Warthog scenarios.<br />
<br />
* '''Mostly fixed menu/options save/restore bug''': Some of the options still don't save/restore correctly, but most do now.<br />
<br />
* '''Numerous other bugfixes/small improvements'''<br />
<br />
=== Version 3.0n ===<br />
* '''AI aircraft dodge and "attack" realistically''': AI dogfights just became 10X as realistic, as fighter planes will turn and attack, just as fighter planes did in WWI and WWII. Try the Marin County Camel Invasion and Marin County Zero Invasion scenarios for a taste of how this works. (No weapons for AI aircraft yet--maybe in the future.)<br />
<br />
* '''New scenario &ndash; B-17 bombers with fighter cover''': Fly out of Marin Ranch and attack a squadron of 6 B-17 Bombers. As you do so, the fighter squadrons descend and swarm you. They don't fire at you (yet! fodder for future versions!) but they turn aggressively towards you, evade your shots, etc., just as real fighters would.<br />
<br />
* '''Damaged ai aircraft crash more realistically'''<br />
<br />
* '''Greatly improved, more realistic damage analysis''': Damage assessment for guns is a lot more realistic, giving greater damage when you hit closer to the center of the object and allowing for the possibility that even small arms might strike a vital or explosive point, causing catastrophic damage. For instance, you can now damage the Nimitz or Eisenhower*--though it's still tough to sink.<br />
<br />
* '''More realistic fire starting''': One of the chief causes of combat aircraft damage is the fires that even small caliber weapons can cause--and fires are even more likely with heavier ammo that includes incendiary (high explosive) materials. Bombable now models that any hit may start a fire, and heavier rounds are more likely to start files. Fires progressively damage the aircraft and eventually bring it down. Beware that fires sometimes go out before completely disabling the aircraft--so monitor the enemy aircraft to make sure they do not recover and escape.<br />
<br />
* '''More realistic aircraft smoke starting''': Similar to fire starting, each damaging hit has the possibility to cause damage that causes the aircraft to emit a trail of smoke. The bigger/closer the hit, the more likely to cause this damage.<br />
<br />
* '''Bombable preferences/settings saved and restored at startup'''<br />
<br />
* '''Fixed excessive damage report problem''': Aircraft would continually report damage even after objects received 100% damage--now fixed.<br />
<br />
* '''Numerous small bugfixes'''<br />
<br />
* Note: You can bomb the Nimitz/Eisenhower carriers if you have the bombable carriers add-on: http://forum.flightgear.org/viewtopic.php?f=2&t=7082<br />
<br />
=== Version 3.0m ===<br />
* Positive and negative G-force limits are now settable separately (most aircraft have different limits for positive vs negative G, so this adds some realism)<br />
<br />
* Bugfixes on damage & damage report<br />
<br />
* Every hit now registers via on-screen popup (vs previous behavior of only showing damage when it increased past multiples of 5%)<br />
<br />
* Bugfixes on g-force damage that caused extraneous very high g forces to cause random damage<br />
<br />
* Bugfixes in multiplayer communication, fixed problems when MP is disabled or doesn't exist<br />
<br />
* Bugfix on bombable multiplayer unload (runtime error "listenerids") and improvement to unload routines<br />
<br />
* Fixed Easy/Super Easy Mode malfunction (Super Easy Mode never engaged; new default mode is Easy Mode which should give same performance as previous default mode)<br />
<br />
* Tuned damage/vulnerabilities on ferries (San Francisco Ferry Invasion scenario)<br />
<br />
=== Version 3.0L ===<br />
* '''Overspeed detection/damage'''<br />
<br />
* '''G-force and overspeed detection optional''': Switches in the Bombable menu to turn it off; turned off by default except for planes included in Bombable package.<br />
<br />
* '''Vulnerabilities framework for primary aircraft''': Allows max acceleration, max speed parameters to be set individually per aircraft (main aircraft) and then damage from overspeed/overacceleration is accrued when those limits are exceeded.<br />
<br />
* '''Blackout/redout tunable per aircraft''': Allows blackout & redout values to be set per aircraft--for instance to reflect that WWI aircraft had no pressure suits or special high-G training. This will help level the playing field and create uniformity in MP dogfighting with similar aircraft.<br />
<br />
* '''G-force and overspeed limits and damage amounts tuned''': For the four aircraft included in the Bombable package (A6M2 Zero, Sopwith Camel, SPAD VII, Fokker DR1) the g-force damage & overspeed damage parameters have been individually tuned and are fairly realistic.<br />
<br />
* '''Fires only for appropriate damage''': Overspeed & overacceleration (g-force) damage doesn't start a fire, though it will still rack up 100% damage and shut you down.<br />
<br />
* '''Numerous bugfixes'''<br />
<br />
=== Version 3.0k ===<br />
* '''Excessive G-force damages your aircraft:''' Excessive g-force now adds damage to your airframe and can even make you crash. To avoid damaging your aircraft due to excessive g-force, always fly with blackout/redout turned on and avoid pulling g-forces much beyond those that make you blackout or redout.<br />
<br />
* '''Zeros over marin county scenario:''' Marin County Zero Invasion scenario added.<br />
<br />
=== Version 3.0j (private release) ===<br />
* '''Burn/smoke on crash:''' Aircraft now catch fire, burn, and instantly go to 100% damage when they crash. This is broadcast via MP so others will see you burn when you crash.<br />
<br />
* '''A5mw zero for dogfighting:''' A6M2 ready for MP dogfighting included in release.<br />
<br />
* '''A6M2 Zero:''' Added historically accurate guns and cannons (fire with e and E) to A6M2 Zero.<br />
<br />
* '''Bombable A62M Zero:''' Included Bombable version of the AI A6M2 Zero from Hellcat's Carrier Bombable project, but also made a few tweaks/improvements to he AI A6M2 for improved realism. See http://www.4shared.com/file/235605076/6101800f/carrier_bombable.html<br />
<br />
* '''Dogfighting:''' Greatly improved dogfighting/multiplayer communication of damages<br />
<br />
* '''Bugfix DR 1:''' Added keyboard firing switch to Fokker DR 1 (use the 'e' key to fire the weapons).<br />
<br />
* '''Bugfixes:''' Many other miscellaneous bug fixes and improvements.<br />
<br />
=== Version 3.0i ===<br />
* '''Reset resets damage:''' In dogfighting, resetting or using the Location menu to change your location resets your damage to 0% and broadcasts that to others flying with you via multiplayer<br />
<br />
* '''FlightGear 2.0 compatible:''' Tested and works with FG 2.0 as well as FG 1.9 and CVS versions between 1.9 and 2.0<br />
<br />
* '''Bugfixes:''' Various small bugfixes<br />
<br />
=== Versions 3.0 through 3.0h ===<br />
* '''Bombable/shootable:''' Code to make objects, AI aircraft, MP aircraft bombable and shootable.<br />
<br />
* '''Moving AI bombable/shootable objects:''' Code to allow AI aircraft, naval vessels, and surface vehicles to move (sort of) realistically and act as bombable/moving aerial targets.<br />
<br />
* '''Scenarios:''' Bombing and dogfighting scenarios using these AI aircraft.<br />
<br />
* '''Multiplayer dogfighting:''' Code to allow multiplayer (MP) communication of damage to aircraft, allowing multiplayer dogfighting<br />
<br />
* '''Aircraft enhancements--weapons and dogfighting:''' Three WWI era aircraft enhanced with historically accurate weapons systems and prepared for MP dogfighting (Sopwith Camel, Fokker DR1, SPAD-VII)<br />
<br />
* '''Contrails and smoke:''' MP aircraft capable of dogfighting, and some other MP and AI aircraft automatically have contrails and engine smoke trails. This makes it possible to locate the aircraft when doing MP dogfighting and generally adds to the realism.<br />
<br />
== External links ==<br />
* [http://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772 Download Bombable, Bombable forum thread]<br />
<br />
[[Category:Bombable]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Talk:Catalog_metadata&diff=107486Talk:Catalog metadata2017-03-20T05:43:20Z<p>Flug: /* Suggestions for further tags */</p>
<hr />
<div>== 2.12 lessons learned ==<br />
See [[Release plan]].<br />
<br />
We still keep seeing issues due to aircraft developers contributing resources with files, file names, paths that would break support on OS with case-sensitive OS or a different locale setting, it would make sense to add some form of optional and automated/scripted validation during startup to detect such issues, without requiring a manual review, possibly through [[Catalog metadata]] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40407.html] [http://flightgear.org/forums/viewtopic.php?f=17&t=20214&p=186020&hilit=xml+french#p185963]<br />
<br />
Things that could be checked by using Nasal and corresponding SimGear bindings:<br />
* XML validation<br />
* file/path look-up<br />
* texture dimensions<br />
* max texture size [http://flightgear.org/forums/viewtopic.php?f=23&t=14232&hilit=zakalawe+traffic&start=165#p185864]<br />
* check for rgb, png, dds textures [http://flightgear.org/forums/viewtopic.php?f=5&t=16092&p=156059&hilit=texture+dimensions#p156029]<br />
* check for stereo files [http://flightgear.org/forums/viewtopic.php?f=19&t=20332]<br />
* try to resolve shader references<br />
* try to compile shaders<br />
* validate effects [http://flightgear.org/forums/viewtopic.php?f=14&t=19824&p=183221&hilit=+effect#p183221]<br />
* resolve dependencies to external resources (aircraft, instruments)<br />
<br />
== What is this? ==<br />
The purpose of this may need further explanation. From this page alone I am not able to figure out the purpose of this, only make educated guesses. My best guess is that this is about a more or less fixed set of tags that probably is added to aircraft in the <code>''aircraft''-set.xml</code> that may or may not be parsed as of now, in essence being an experimental or developing feature.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 16:05, 12 March 2014 (UTC)<br />
<br />
: It's basically [[Formalizing Aircraft Status]], but more in line with the [http://wiki.flightgear.org/index.php?title=Aircraft_status_indication&oldid=29443 original proposal]. The whole idea is to allow aircraft to be categorized and classified based on meta information, i.e. for downloading/installing (GUI frontend, integrated GUI and/or website) ([[Simplifying Aircraft Deployment]]). --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:35, 12 March 2014 (UTC)<br />
<br />
:: That was still a bit too vague. However, a few days ago I came across [https://gitorious.org/saab-ja-37-viggen/flightgear-saab-ja-37-viggen/source/d82e0a0aed44391ff3bf97091de673590bfb5c0b:Aircraft/JA37/JA37-Viggen-set.xml#L21-37 this] and together with results from a recent search triggered by [http://wiki.flightgear.org/index.php?title=User_talk:Zakalawe&diff=76899&oldid=76875 this post] I had an Aha! moment.<br />
<br />
:: I have now added a first section describing what the article is all about, an example of how to use the metadata tags and tried to link together some other resources and a relevant devel list thread.<br />
<br />
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 15:41, 3 October 2014 (UTC)<br />
<br />
== Suggestions for further tags ==<br />
* Smoke (if an aircraft can make smoke trail. E.g. Alphajet)<br />
* Rotary (engine). This is a wildly different type of engine than a radial engine, so definitely deserving of a separate entry. https://en.wikipedia.org/wiki/Rotary_engine#Distinction_between_.22rotary.22_and_.22radial.22_engines</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107483Sopwith Camel (JSBSim)2017-03-20T00:51:57Z<p>Flug: /* THROTTLE, BLIP SWITCH, AND MAGNETOS */</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
The aircraft features:<br />
* An advanced JSBSim Flight Dynamics Model based on extensive historical research and testing to match historical performance data, handling characteristics, and capabilities<br />
* Ground and water effects, friction, terrain bumpiness, shadows, dust<br />
* Crash and damage effects<br />
* Historically accurate weapons capabilities<br />
* Extensive sound design<br />
* [[Bombable]] compatible<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings for left and right magneto alone, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
[[File:Sopwith_Camels_battle_in_Bombable_02.png|thumb|right|JSBSim Sopwith Camels in Bombable add-on]]<br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often registers your throttle at 0% even though the slider may be at 100%; give it a jiggle to prevent underpowered takeoff). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
[[File:Sopwith_Camels_battle_in_Bombable_01.png|thumb|right|Sopwith Camel - 1917-2017]]<br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine power to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum historical capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
'''TAXIING:''' In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
'''STALL:''' Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
'''TRIM:''' Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
'''Extensive help, tips, historical documents and references''' in the DOCS folder.<br />
<br />
===KEY SPEEDS & TECHNICAL DATA===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all [https://en.wikipedia.org/wiki/Indicated_airspeed Indicated Air Speed/IAS])<br />
<br />
* Top speeds:<br />
** 115 mph @ 6500 ft<br />
** 113 mph @ 10000 ft<br />
** 106.5 mph @ 15000 ft (all [https://en.wikipedia.org/wiki/True_airspeed True Air Speed/TAS])<br />
<br />
* Climb to<br />
** 6500 ft = 6 min 0 sec<br />
** 10000 ft = 10 min 35 sec<br />
** 15000 ft = 20 min 40 sec<br />
<br />
* Service Ceiling: 19,600 ft<br />
<br />
* Range: 217 miles<br />
<br />
* Empty weight: 956 lb<br />
* Fully Loaded weight: 1523 pounds<br />
<br />
* Fuel: Main (pressure) tank 30 gallons; gravity tank 7 gallons; total 37 gallons. <br />
* Castor Oil: 6.5 gallons.<br />
<br />
* Engine: [https://en.wikipedia.org/wiki/Clerget_9B 130 HP Clerget 9B Rotary]<br />
<br />
* Armament: 2 synchronized 7.7mm Vickers machine guns<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107482Sopwith Camel (JSBSim)2017-03-20T00:51:25Z<p>Flug: photos</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
The aircraft features:<br />
* An advanced JSBSim Flight Dynamics Model based on extensive historical research and testing to match historical performance data, handling characteristics, and capabilities<br />
* Ground and water effects, friction, terrain bumpiness, shadows, dust<br />
* Crash and damage effects<br />
* Historically accurate weapons capabilities<br />
* Extensive sound design<br />
* [[Bombable]] compatible<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings for left and right magneto alone, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
[[File:Sopwith_Camels_battle_in_Bombable_02.png|thumb|right|JSBSim Sopwith Camels in Bombable add-on]]<br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often registers your throttle at 0% even though the slider may be at 100%; give it a jiggle to prevent underpowered takeoff). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
[[File:Sopwith_Camels_battle_in_Bombable_01.png|thumb|right|Sopwith Camel - 1917-2017]]<br />
<br />
<br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine power to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum historical capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
'''TAXIING:''' In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
'''STALL:''' Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
'''TRIM:''' Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
'''Extensive help, tips, historical documents and references''' in the DOCS folder.<br />
<br />
===KEY SPEEDS & TECHNICAL DATA===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all [https://en.wikipedia.org/wiki/Indicated_airspeed Indicated Air Speed/IAS])<br />
<br />
* Top speeds:<br />
** 115 mph @ 6500 ft<br />
** 113 mph @ 10000 ft<br />
** 106.5 mph @ 15000 ft (all [https://en.wikipedia.org/wiki/True_airspeed True Air Speed/TAS])<br />
<br />
* Climb to<br />
** 6500 ft = 6 min 0 sec<br />
** 10000 ft = 10 min 35 sec<br />
** 15000 ft = 20 min 40 sec<br />
<br />
* Service Ceiling: 19,600 ft<br />
<br />
* Range: 217 miles<br />
<br />
* Empty weight: 956 lb<br />
* Fully Loaded weight: 1523 pounds<br />
<br />
* Fuel: Main (pressure) tank 30 gallons; gravity tank 7 gallons; total 37 gallons. <br />
* Castor Oil: 6.5 gallons.<br />
<br />
* Engine: [https://en.wikipedia.org/wiki/Clerget_9B 130 HP Clerget 9B Rotary]<br />
<br />
* Armament: 2 synchronized 7.7mm Vickers machine guns<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107481Sopwith Camel (JSBSim)2017-03-20T00:45:31Z<p>Flug: /* STARTING OUT */</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
The aircraft features:<br />
* An advanced JSBSim Flight Dynamics Model based on extensive historical research and testing to match historical performance data, handling characteristics, and capabilities<br />
* Ground and water effects, friction, terrain bumpiness, shadows, dust<br />
* Crash and damage effects<br />
* Historically accurate weapons capabilities<br />
* Extensive sound design<br />
* [[Bombable]] compatible<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings for left and right magneto alone, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often registers your throttle at 0% even though the slider may be at 100%; give it a jiggle to prevent underpowered takeoff). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine power to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum historical capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
'''TAXIING:''' In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
'''STALL:''' Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
'''TRIM:''' Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
'''Extensive help, tips, historical documents and references''' in the DOCS folder.<br />
<br />
===KEY SPEEDS & TECHNICAL DATA===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all [https://en.wikipedia.org/wiki/Indicated_airspeed Indicated Air Speed/IAS])<br />
<br />
* Top speeds:<br />
** 115 mph @ 6500 ft<br />
** 113 mph @ 10000 ft<br />
** 106.5 mph @ 15000 ft (all [https://en.wikipedia.org/wiki/True_airspeed True Air Speed/TAS])<br />
<br />
* Climb to<br />
** 6500 ft = 6 min 0 sec<br />
** 10000 ft = 10 min 35 sec<br />
** 15000 ft = 20 min 40 sec<br />
<br />
* Service Ceiling: 19,600 ft<br />
<br />
* Range: 217 miles<br />
<br />
* Empty weight: 956 lb<br />
* Fully Loaded weight: 1523 pounds<br />
<br />
* Fuel: Main (pressure) tank 30 gallons; gravity tank 7 gallons; total 37 gallons. <br />
* Castor Oil: 6.5 gallons.<br />
<br />
* Engine: [https://en.wikipedia.org/wiki/Clerget_9B 130 HP Clerget 9B Rotary]<br />
<br />
* Armament: 2 synchronized 7.7mm Vickers machine guns<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107480Sopwith Camel (JSBSim)2017-03-20T00:44:15Z<p>Flug: /* MISC */</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
The aircraft features:<br />
* An advanced JSBSim Flight Dynamics Model based on extensive historical research and testing to match historical performance data, handling characteristics, and capabilities<br />
* Ground and water effects, friction, terrain bumpiness, shadows, dust<br />
* Crash and damage effects<br />
* Historically accurate weapons capabilities<br />
* Extensive sound design<br />
* [[Bombable]] compatible<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings for left and right magneto alone, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine power to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum historical capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
'''TAXIING:''' In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
'''STALL:''' Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
'''TRIM:''' Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
'''Extensive help, tips, historical documents and references''' in the DOCS folder.<br />
<br />
===KEY SPEEDS & TECHNICAL DATA===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all [https://en.wikipedia.org/wiki/Indicated_airspeed Indicated Air Speed/IAS])<br />
<br />
* Top speeds:<br />
** 115 mph @ 6500 ft<br />
** 113 mph @ 10000 ft<br />
** 106.5 mph @ 15000 ft (all [https://en.wikipedia.org/wiki/True_airspeed True Air Speed/TAS])<br />
<br />
* Climb to<br />
** 6500 ft = 6 min 0 sec<br />
** 10000 ft = 10 min 35 sec<br />
** 15000 ft = 20 min 40 sec<br />
<br />
* Service Ceiling: 19,600 ft<br />
<br />
* Range: 217 miles<br />
<br />
* Empty weight: 956 lb<br />
* Fully Loaded weight: 1523 pounds<br />
<br />
* Fuel: Main (pressure) tank 30 gallons; gravity tank 7 gallons; total 37 gallons. <br />
* Castor Oil: 6.5 gallons.<br />
<br />
* Engine: [https://en.wikipedia.org/wiki/Clerget_9B 130 HP Clerget 9B Rotary]<br />
<br />
* Armament: 2 synchronized 7.7mm Vickers machine guns<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107479Sopwith Camel (JSBSim)2017-03-20T00:42:50Z<p>Flug: /* THROTTLE, BLIP SWITCH, AND MAGNETOS */</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
The aircraft features:<br />
* An advanced JSBSim Flight Dynamics Model based on extensive historical research and testing to match historical performance data, handling characteristics, and capabilities<br />
* Ground and water effects, friction, terrain bumpiness, shadows, dust<br />
* Crash and damage effects<br />
* Historically accurate weapons capabilities<br />
* Extensive sound design<br />
* [[Bombable]] compatible<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings for left and right magneto alone, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine power to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum historical capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
===KEY SPEEDS & TECHNICAL DATA===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all [https://en.wikipedia.org/wiki/Indicated_airspeed Indicated Air Speed/IAS])<br />
<br />
* Top speeds:<br />
** 115 mph @ 6500 ft<br />
** 113 mph @ 10000 ft<br />
** 106.5 mph @ 15000 ft (all [https://en.wikipedia.org/wiki/True_airspeed True Air Speed/TAS])<br />
<br />
* Climb to<br />
** 6500 ft = 6 min 0 sec<br />
** 10000 ft = 10 min 35 sec<br />
** 15000 ft = 20 min 40 sec<br />
<br />
* Service Ceiling: 19,600 ft<br />
<br />
* Range: 217 miles<br />
<br />
* Empty weight: 956 lb<br />
* Fully Loaded weight: 1523 pounds<br />
<br />
* Fuel: Main (pressure) tank 30 gallons; gravity tank 7 gallons; total 37 gallons. <br />
* Castor Oil: 6.5 gallons.<br />
<br />
* Engine: [https://en.wikipedia.org/wiki/Clerget_9B 130 HP Clerget 9B Rotary]<br />
<br />
* Armament: 2 synchronized 7.7mm Vickers machine guns<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107478Sopwith Camel (JSBSim)2017-03-20T00:40:42Z<p>Flug: /* KEY SPEEDS & TECHNICAL DATA */</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
The aircraft features:<br />
* An advanced JSBSim Flight Dynamics Model based on extensive historical research and testing to match historical performance data, handling characteristics, and capabilities<br />
* Ground and water effects, friction, terrain bumpiness, shadows, dust<br />
* Crash and damage effects<br />
* Historically accurate weapons capabilities<br />
* Extensive sound design<br />
* [[Bombable]] compatible<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings for left and right magneto alone, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum historical capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
===KEY SPEEDS & TECHNICAL DATA===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all [https://en.wikipedia.org/wiki/Indicated_airspeed Indicated Air Speed/IAS])<br />
<br />
* Top speeds:<br />
** 115 mph @ 6500 ft<br />
** 113 mph @ 10000 ft<br />
** 106.5 mph @ 15000 ft (all [https://en.wikipedia.org/wiki/True_airspeed True Air Speed/TAS])<br />
<br />
* Climb to<br />
** 6500 ft = 6 min 0 sec<br />
** 10000 ft = 10 min 35 sec<br />
** 15000 ft = 20 min 40 sec<br />
<br />
* Service Ceiling: 19,600 ft<br />
<br />
* Range: 217 miles<br />
<br />
* Empty weight: 956 lb<br />
* Fully Loaded weight: 1523 pounds<br />
<br />
* Fuel: Main (pressure) tank 30 gallons; gravity tank 7 gallons; total 37 gallons. <br />
* Castor Oil: 6.5 gallons.<br />
<br />
* Engine: [https://en.wikipedia.org/wiki/Clerget_9B 130 HP Clerget 9B Rotary]<br />
<br />
* Armament: 2 synchronized 7.7mm Vickers machine guns<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107477Sopwith Camel (JSBSim)2017-03-20T00:40:04Z<p>Flug: /* KEY SPEEDS & TECHNICAL DATA */</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
The aircraft features:<br />
* An advanced JSBSim Flight Dynamics Model based on extensive historical research and testing to match historical performance data, handling characteristics, and capabilities<br />
* Ground and water effects, friction, terrain bumpiness, shadows, dust<br />
* Crash and damage effects<br />
* Historically accurate weapons capabilities<br />
* Extensive sound design<br />
* [[Bombable]] compatible<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings for left and right magneto alone, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum historical capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
===KEY SPEEDS & TECHNICAL DATA===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all [https://en.wikipedia.org/wiki/Indicated_airspeedIndicated Air Speed/IAS])<br />
<br />
* Top speeds:<br />
** 115 mph @ 6500 ft<br />
** 113 mph @ 10000 ft<br />
** 106.5 mph @ 15000 ft (all [https://en.wikipedia.org/wiki/True_airspeed True Air Speed/TAS])<br />
<br />
* Climb to<br />
** 6500 ft = 6 min 0 sec<br />
** 10000 ft = 10 min 35 sec<br />
** 15000 ft = 20 min 40 sec<br />
<br />
* Service Ceiling: 19,600 ft<br />
<br />
* Range: 217 miles<br />
<br />
* Empty weight: 956 lb<br />
* Fully Loaded weight: 1523 pounds<br />
<br />
* Fuel: Main (pressure) tank 30 gallons; gravity tank 7 gallons; total 37 gallons. <br />
* Castor Oil: 6.5 gallons.<br />
<br />
* Engine: [https://en.wikipedia.org/wiki/Clerget_9B 130 HP Clerget 9B Rotary]<br />
<br />
* Armament: 2 synchronized 7.7mm Vickers machine guns<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107476Sopwith Camel (JSBSim)2017-03-20T00:35:20Z<p>Flug: /* KEY SPEEDS & TECHNICAL DATA */</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
The aircraft features:<br />
* An advanced JSBSim Flight Dynamics Model based on extensive historical research and testing to match historical performance data, handling characteristics, and capabilities<br />
* Ground and water effects, friction, terrain bumpiness, shadows, dust<br />
* Crash and damage effects<br />
* Historically accurate weapons capabilities<br />
* Extensive sound design<br />
* [[Bombable]] compatible<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings for left and right magneto alone, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum historical capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
===KEY SPEEDS & TECHNICAL DATA===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all [https://en.wikipedia.org/wiki/Indicated_airspeedIndicated Air Speed/IAS])<br />
<br />
* Top speeds:<br />
** 115 mph @ 6500 ft<br />
** 113 mph @ 10000 ft<br />
** 106.5 mph @ 15000 ft (all [https://en.wikipedia.org/wiki/True_airspeed True Air Speed/TAS])<br />
<br />
* Climb to<br />
** 6500 ft = 6 min 0 sec<br />
** 10000 ft = 10 min 35 sec<br />
** 15000 ft = 20 min 40 sec<br />
<br />
* Service Ceiling: 19,600 ft<br />
<br />
* Empty weight: 956 lb<br />
* Fully Loaded weight: 1523 pounds<br />
<br />
* Fuel: Main (pressure) tank 30 gallons; gravity tank 7 gallons; total 37 gallons. <br />
* Castor Oil: 6.5 gallons.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107475Sopwith Camel (JSBSim)2017-03-20T00:31:18Z<p>Flug: </p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
The aircraft features:<br />
* An advanced JSBSim Flight Dynamics Model based on extensive historical research and testing to match historical performance data, handling characteristics, and capabilities<br />
* Ground and water effects, friction, terrain bumpiness, shadows, dust<br />
* Crash and damage effects<br />
* Historically accurate weapons capabilities<br />
* Extensive sound design<br />
* [[Bombable]] compatible<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings for left and right magneto alone, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum historical capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
===KEY SPEEDS & TECHNICAL DATA===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all IAS)<br />
<br />
* Top speeds:<br />
* 115 mph @ 6500 ft<br />
* 113 mph @ 10000 ft<br />
* 106.5 mph @ 15000 ft<br />
<br />
* Climb to<br />
* 6500 ft = 6 min 0 sec<br />
* 10000 ft = 10 min 35 sec<br />
* 15000 ft = 20 min 40 sec<br />
<br />
* Service Ceiling: 19,600 ft<br />
<br />
* Empty weight: 956 lb<br />
* Fully Loaded weight: 1523 pounds<br />
<br />
* Fuel: Main (pressure) tank 30 gallons; gravity tank 7 gallons; total 37 gallons. <br />
* Oil: 6.5 gallons.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107474Sopwith Camel (JSBSim)2017-03-20T00:30:15Z<p>Flug: speeds and technical data</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
The aircraft features:<br />
* An advanced JSBSim Flight Dynamics Model based on extensive historical research and testing to match historical performance data, handling characteristics, and capabilities<br />
* Ground and water effects, friction, terrain bumpiness, shadows, dust<br />
* Crash and damage effects<br />
* Historically accurate weapons capabilities<br />
* Extensive sound design<br />
* [[Bombable]] compatible<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings for left and right magneto alone, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===KEY SPEEDS & TECHNICAL DATA===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all IAS)<br />
<br />
* Top speeds:<br />
* 115 mph @ 6500 ft<br />
* 113 mph @ 10000 ft<br />
* 106.5 mph @ 15000 ft<br />
<br />
* Climb to<br />
* 6500 ft = 6 min 0 sec<br />
* 10000 ft = 10 min 35 sec<br />
* 15000 ft = 20 min 40 sec<br />
<br />
* Service Ceiling: 19,600 ft<br />
<br />
* Empty weight: 956 lb<br />
* Fully Loaded weight: 1523 pounds<br />
<br />
* Fuel: Main (pressure) tank 30 gallons; gravity tank 7 gallons; total 37 gallons. <br />
* Oil: 6.5 gallons.<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum historical capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel&diff=107473Sopwith Camel2017-03-20T00:14:10Z<p>Flug: </p>
<hr />
<div>{{:{{PAGENAME}}/info}}<br />
The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
<br />
==Aircraft help==<br />
=== Starting ===<br />
# Press { and } once each--so that both L and R magneto switches are in center position.<br />
# Hold the s key for several seconds until the engine catches.<br />
<br />
=== Take Off ===<br />
# Zoom the view out so you can see the edges of the runway with your peripheral vision. As you speed up, gently pull back on the stick - this<br />
avoids the spin-out that otherwise happens around 40-45 MPH. <br />
# As you lift off, about 45 MPH, be prepared to counter the torque of the engines with your ailerons. <br />
<br />
* The blip switch (b) disengages both magnetos and cuts power.<br />
* Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch. Releasing the brake (or b key) releases<br />
the blip switch.<br />
<br />
=== Approach ===<br />
* Speed 55 MPH IAS<br />
* Throttle OPEN<br />
* Use the blip switch to control speed NOT throttle<br />
* blip switch ON/OFF as required<br />
* touchdown speed: 50-55 MPH IAS<br />
* stall speed 48 MPH IAS<br />
<br />
=== Alternate JSBSim Camel ===<br />
<br />
A JSBSim version of the Camel is also available, with advanced JSBSim Flight Dynamics Model based on extensive historical research, ground and water effects, crash and damage effects, historically accurate weapons capabilities, more extensive sound design, and more. <br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=4&t=19584&p=180466#p180466 More information about and downloads for the JSBSim Sopwith Camel in the Flightgear Forums.] [[Sopwith Camel (JSBSim)|JSBSim Sopwith Camel wiki page here.]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107472Sopwith Camel (JSBSim)2017-03-20T00:12:29Z<p>Flug: /* Aircraft help */</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings for left and right magneto alone, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===KEY SPEEDS===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all IAS)<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107471Sopwith Camel (JSBSim)2017-03-19T23:59:00Z<p>Flug: /* KEYS AND CONTROLS */</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* '''Shift B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===KEY SPEEDS===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all IAS)<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107470Sopwith Camel (JSBSim)2017-03-19T23:58:31Z<p>Flug: /* KEYS */</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
==Aircraft help==<br />
<br />
===KEYS AND CONTROLS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* Shift '''B''' - Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' - Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' - Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' - Fire guns<br />
<br />
* '''l''' - Change livery<br />
<br />
* '''n''' - Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' - In INSPECT AIRCRAFT VIEW: Move and look around ('''v/V''' to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' - Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===KEY SPEEDS===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all IAS)<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107469Sopwith Camel (JSBSim)2017-03-19T23:57:28Z<p>Flug: /* KEYS */ formatting</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
==Aircraft help==<br />
<br />
===KEYS===<br />
* '''s''' - Start engine (OR: Click propeller/center of dash)<br />
<br />
* '''b''' (or press brakes) - Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* '''{ }''' - Toggle left/right magneto switch. 4/9 and 5/9 power settings, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* Shift '''B''' Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* '''u/Shift U/Ctrl u''' Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* '''m/M''' Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* '''e''' Fire guns<br />
<br />
* '''l''' Change livery<br />
<br />
* '''n''' Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* '''WwAaSsDdQq''' and '''mouse''' In INSPECT AIRCRAFT VIEW: Move and look around (v/V to select this view; see View/View Options)<br />
<br />
* '''Camel Menu''' Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===KEY SPEEDS===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all IAS)<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107468Sopwith Camel (JSBSim)2017-03-19T23:54:36Z<p>Flug: Formatting</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
==Aircraft help==<br />
<br />
===KEYS===<br />
* Key s Start engine (OR: Click propeller/center of dash)<br />
<br />
* Key b (or press brakes) Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* Keys { } Toggle left/right magneto switch. 4/9 and 5/9 power settings, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* Key B Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* Keys u/U/ctrl u Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* Keys m/M Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* Key e Fire guns<br />
<br />
* Key l Change livery<br />
<br />
* Key n Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* Key WwAaSsDdQq and mouse In INSPECT AIRCRAFT VIEW: Move and look around (v/V to select this view; see View/View Options)<br />
<br />
* Camel Menu Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. <br />
<br />
Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. <br />
<br />
Check throttle set at 100% (on startup FlightGear often has your throttle at 0% even though the slider may be at 100%). <br />
<br />
Press and hold the 's' key for 0.5 seconds.<br />
<br />
It may take several tries before the engine catches. <br />
<br />
If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. <br />
<br />
Zoom view full out; steer via peripheral vision.<br />
<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
<br />
More advanced takeoff procedure usable under calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. <br />
<br />
Throttle provides a limited range of power settings. <br />
<br />
The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. <br />
<br />
Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. <br />
<br />
If you fly inverted or pull negative Gs, the<br />
engine will soon stop. <br />
<br />
Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. <br />
<br />
Throttle FULL OPEN, L Magneto ON, R Magneto OFF. <br />
<br />
Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. <br />
<br />
Note relatively steep glide slope. <br />
<br />
Sideslip as needed to control speed. Simply engaging ailerons may provide you with all the sideslip you need (adverse yaw).<br />
<br />
On runout, hold tail firmly down to act as brake.<br />
<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===KEY SPEEDS===<br />
* Approach speed 55 KTS (60-65 mph)<br />
* Threshhold speed 48 KTS (55 mph)<br />
* Touchdown speed: 40 KTS (45-50 mph)<br />
* Stall speed 41 KTS (48 mph)<br />
* Best Climb speed 55 KTS (60-65 mph) (all IAS)<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum capacity of the Camel.<br />
<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. <br />
<br />
At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. <br />
<br />
Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. With full fuel, constant 10-20 lbs forward pressure on the stick was required to maintain level flight. <br />
<br />
Be aware of natural nose-up attitude and potential for inadvertent climb and stall whenever flying with full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107467Sopwith Camel (JSBSim)2017-03-19T23:38:19Z<p>Flug: Photos/formatting</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
[[File:Real-sopwith-camel-1917-vs-flightgear-2017.png|thumb|right|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
[[File:JSBSim-camel-bad-crash.jpg|thumb|right|JSBSim Camel: Bad Crash]]<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
==Aircraft help==<br />
<br />
===KEYS===<br />
* Key s Start engine (OR: Click propeller/center of dash)<br />
<br />
* Key b (or press brakes) Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* Keys { } Toggle left/right magneto switch. 4/9 and 5/9 power settings, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* Key B Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* Keys u/U/ctrl u Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* Keys m/M Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* Key e Fire guns<br />
<br />
* Key l Change livery<br />
<br />
* Key n Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* Key WwAaSsDdQq and mouse In INSPECT AIRCRAFT VIEW: Move and look around (v/V to select this view; see View/View Options)<br />
<br />
* Camel Menu Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. Check throttle @ 100%. Press and hold the 's' key for 0.5 seconds.<br />
It may take several tries before the engine catches. If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. Zoom view full out; steer via peripheral vision.<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
More advanced/Calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. Throttle provides a limited range of power settings. The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. If you fly inverted or pull negative Gs, the<br />
engine will soon stop. Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. Throttle FULL OPEN, L Magneto ON, R Magneto OFF. Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. Note relatively steep glide slope. Sideslip as needed<br />
to control speed. On runout, hold tail firmly down to act as brake.<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===KEY SPEEDS===<br />
Approach speed 55 KTS (60-65 mph) : Threshhold speed 48 KTS (55 mph) : Touchdown speed: 40 KTS (45-50 mph)<br />
Stall speed 41 KTS (48 mph) : Best Climb speed 55 KTS (60-65 mph) (all IAS)<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum capacity of the Camel.<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. Beware of stall @ full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107466Sopwith Camel (JSBSim)2017-03-19T23:37:33Z<p>Flug: Photos</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
<gallery><br />
Real-sopwith-camel-1917-vs-flightgear-2017.png<br />
JSBSim-camel-bad-crash.jpg|Caption1<br />
</gallery><br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
==Aircraft help==<br />
<br />
===KEYS===<br />
* Key s Start engine (OR: Click propeller/center of dash)<br />
<br />
* Key b (or press brakes) Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* Keys { } Toggle left/right magneto switch. 4/9 and 5/9 power settings, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* Key B Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* Keys u/U/ctrl u Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* Keys m/M Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* Key e Fire guns<br />
<br />
* Key l Change livery<br />
<br />
* Key n Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* Key WwAaSsDdQq and mouse In INSPECT AIRCRAFT VIEW: Move and look around (v/V to select this view; see View/View Options)<br />
<br />
* Camel Menu Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. Check throttle @ 100%. Press and hold the 's' key for 0.5 seconds.<br />
It may take several tries before the engine catches. If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. Zoom view full out; steer via peripheral vision.<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
More advanced/Calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. Throttle provides a limited range of power settings. The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. If you fly inverted or pull negative Gs, the<br />
engine will soon stop. Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. Throttle FULL OPEN, L Magneto ON, R Magneto OFF. Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. Note relatively steep glide slope. Sideslip as needed<br />
to control speed. On runout, hold tail firmly down to act as brake.<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===KEY SPEEDS===<br />
Approach speed 55 KTS (60-65 mph) : Threshhold speed 48 KTS (55 mph) : Touchdown speed: 40 KTS (45-50 mph)<br />
Stall speed 41 KTS (48 mph) : Best Climb speed 55 KTS (60-65 mph) (all IAS)<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum capacity of the Camel.<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. Beware of stall @ full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107465Sopwith Camel (JSBSim)2017-03-19T23:34:29Z<p>Flug: Formatting</p>
<hr />
<div>The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data and reports about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
==Aircraft help==<br />
<br />
===KEYS===<br />
* Key s Start engine (OR: Click propeller/center of dash)<br />
<br />
* Key b (or press brakes) Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* Keys { } Toggle left/right magneto switch. 4/9 and 5/9 power settings, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* Key B Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* Keys u/U/ctrl u Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* Keys m/M Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* Key e Fire guns<br />
<br />
* Key l Change livery<br />
<br />
* Key n Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* Key WwAaSsDdQq and mouse In INSPECT AIRCRAFT VIEW: Move and look around (v/V to select this view; see View/View Options)<br />
<br />
* Camel Menu Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
===STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. Check throttle @ 100%. Press and hold the 's' key for 0.5 seconds.<br />
It may take several tries before the engine catches. If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. Zoom view full out; steer via peripheral vision.<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
More advanced/Calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. Throttle provides a limited range of power settings. The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. If you fly inverted or pull negative Gs, the<br />
engine will soon stop. Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. Throttle FULL OPEN, L Magneto ON, R Magneto OFF. Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. Note relatively steep glide slope. Sideslip as needed<br />
to control speed. On runout, hold tail firmly down to act as brake.<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===KEY SPEEDS===<br />
Approach speed 55 KTS (60-65 mph) : Threshhold speed 48 KTS (55 mph) : Touchdown speed: 40 KTS (45-50 mph)<br />
Stall speed 41 KTS (48 mph) : Best Climb speed 55 KTS (60-65 mph) (all IAS)<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum capacity of the Camel.<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. Beware of stall @ full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
== YASim Camel ==<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107464Sopwith Camel (JSBSim)2017-03-19T23:32:53Z<p>Flug: Added info from a/c help file</p>
<hr />
<div>{{:{{PAGENAME}}/info}}<br />
The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
==Aircraft help==<br />
<br />
===KEYS===<br />
* Key s Start engine (OR: Click propeller/center of dash)<br />
<br />
* Key b (or press brakes) Blip switch - both magnetos OFF - blip and magnetos are the primary method for controlling engine power<br />
<br />
* Keys { } Toggle left/right magneto switch. 4/9 and 5/9 power settings, respectively. Magneto switches visible on dash at lower left.<br />
<br />
* Key B Toggle chocks (OR: click chocks/wheels with mouse)<br />
<br />
* Keys u/U/ctrl u Adjust pilot viewpoint up/down, select default pilot viewpoint<br />
<br />
* Keys m/M Adjust mixture (If manual mixture selected via menu Camel/Toggle Manual Mixture)<br />
<br />
* Key e Fire guns<br />
<br />
* Key l Change livery<br />
<br />
* Key n Nudge aircraft forward (ie, when taxiing in the grass and stuck)<br />
<br />
* Key WwAaSsDdQq and mouse In INSPECT AIRCRAFT VIEW: Move and look around (v/V to select this view; see View/View Options)<br />
<br />
* Camel Menu Repair/restore aircraft (must be on ground/stopped), hide pilot and cockpit clutter, more<br />
<br />
==STARTING OUT===<br />
Press { and } once each - so that both L and R magneto switches are in upward position. Check that Blip Switch ('b' key,<br />
visible button on Camel's joystick handle) is disengaged. Check throttle @ 100%. Press and hold the 's' key for 0.5 seconds.<br />
It may take several tries before the engine catches. If you spawn in on the ground, chocks are in place. Shift-B to remove.<br />
<br />
===TAKE OFF===<br />
Always take off directly INTO wind regardless of runway configuration. Zoom view full out; steer via peripheral vision.<br />
Easiest, most dependable way to take off: Full throttle, moderate back-pressure on stick to keep<br />
tail engaged w/ ground. Use rudder to steer (tail dragging on ground provides most control authority).<br />
3-point lift-off @ 40-45 KTS (45-50 mph); immediately ease stick forward to avoid excessive climb, loss of airspeed, stall.<br />
More advanced/Calm conditions: Gently lift tail @ 30-35 mph and continue rolling (or in ground effect) through 50-55 mph before lift-off.<br />
<br />
Crashing on takeoff? Check wind and weather - many real Camel pilots crashed on take-off/landing with strong crosswind or tailwind.<br />
<br />
===THROTTLE, BLIP SWITCH, AND MAGNETOS===<br />
Real Camel pilots used a combination of throttle, magneto settings, and the blip switch to achieve desired power<br />
settings. Throttle provides a limited range of power settings. The blip switch (b) disengages both magnetos and cuts<br />
power totally. Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch.<br />
Releasing the brake (or releasing the 'b' key) releases the blip switch. Engaging only one magneto ('{' or '}')<br />
reduces engine RPM to just under half (L magneto) and just over half (R magneto).<br />
<br />
This gives you 3 distinct power settings via magneto (L, R, or both) - you can fine-tune each of them with the throttle.<br />
Note that L magneto ON/R magneto OFF + Blip switch gives you very fine low-power control for, e.g., approach and landing.<br />
<br />
===NEGATIVE G - INVERTED FLIGHT===<br />
The Camel's fuel system requires gravity to feed fuel to the engine. If you fly inverted or pull negative Gs, the<br />
engine will soon stop. Once you return to upright flight, fuel will flow and the engine will start again.<br />
<br />
===APPROACH AND LANDING===<br />
Land directly into wind regardless of runway layout. Throttle FULL OPEN, L Magneto ON, R Magneto OFF. Control engine<br />
power via Blip Switch (b); Engine is typically mostly OFF (via Blip) on approach. Note relatively steep glide slope. Sideslip as needed<br />
to control speed. On runout, hold tail firmly down to act as brake.<br />
Unstable or ground loop on landing? Just add full power (R Magneto ON) and go around.<br />
<br />
===KEY SPEEDS===<br />
Approach speed 55 KTS (60-65 mph) : Threshhold speed 48 KTS (55 mph) : Touchdown speed: 40 KTS (45-50 mph)<br />
Stall speed 41 KTS (48 mph) : Best Climb speed 55 KTS (60-65 mph) (all IAS)<br />
<br />
===GUNS & RELOADING===<br />
Guns have 400 rounds each, the maximum capacity of the Camel.<br />
Fire with the 'e' key or a joystick trigger linked to /controls/armament/trigger.<br />
<br />
Reload guns: Use the Camel Menu - you must be on ground, stopped, engine off.<br />
<br />
===MISC===<br />
TAXIING: In windy conditions, use elevator to hold tail firmly down for better steering authority. At high RPM, prop wash<br />
gives some rudder and elevator authority even at near stand-still. Use this plus the burst of power from Blip to<br />
help maneuver and taxi over bumps. Don't forget 'n' for nudge when you get stuck.<br />
<br />
STALL: Push forward firmly on the stick, gain airspeed. Vigorously oppose any spin (rudder and ailerons). It may help to blip<br />
engine off, reducing torque and gyroscopic moment. You will lose ~500 ft altitude or more.<br />
<br />
TRIM: Real Camels had no trim mechanism and were tail heavy with full fuel - nose heavy with low fuel. Beware of stall @ full fuel!<br />
<br />
Extensive help, tips, documents in the DOCS folder.<br />
<br />
==Download JSBSim Camel==<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
=== YASim Camel ===<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=Sopwith_Camel_(JSBSim)&diff=107463Sopwith Camel (JSBSim)2017-03-19T23:27:55Z<p>Flug: Created page</p>
<hr />
<div>{{:{{PAGENAME}}/info}}<br />
The '''Sopwith Camel''' was a British First World War single-seat biplane [[:Category:Military aircraft|fighter]] introduced on the Western Front in 1917.<br />
<br />
This page is about the JSBSim version of the Sopwith Camel created for FlightGear and based on historical data about aircraft performance and handling.<br />
<br />
The JSBSim Sopwith Camel is [https://forum.flightgear.org/viewtopic.php?f=4&t=19584 available for download on the FlightGear Forums here.]<br />
<br />
==Aircraft help==<br />
=== Starting ===<br />
# Press { and } once each--so that both L and R magneto switches are in center position.<br />
# Hold the s key for several seconds until the engine catches.<br />
<br />
=== Take Off ===<br />
# Zoom the view out so you can see the edges of the runway with your peripheral vision. As you speed up, gently pull back on the stick - this<br />
avoids the spin-out that otherwise happens around 40-45 MPH. <br />
# As you lift off, about 45 MPH, be prepared to counter the torque of the engines with your ailerons. <br />
<br />
* The blip switch (b) disengages both magnetos and cuts power.<br />
* Engaging either R or L brake (via keyboard, joystick, or rudder/pedals) also engages the blip switch. Releasing the brake (or b key) releases<br />
the blip switch.<br />
<br />
=== Approach ===<br />
* Speed 55 MPH IAS<br />
* Throttle OPEN<br />
* Use the blip switch to control speed NOT throttle<br />
* blip switch ON/OFF as required<br />
* touchdown speed: 50-55 MPH IAS<br />
* stall speed 48 MPH IAS<br />
<br />
=== YASim Camel ===<br />
<br />
The JSBSim Camel share the aircraft model and many details with [[Sopwith Camel|the YASim Camel available from FGAddons]].</div>Flughttps://wiki.flightgear.org/w/index.php?title=ALS_technical_notes&diff=107438ALS technical notes2017-03-19T13:01:05Z<p>Flug: /* ALS fuselage shadow effect */ link to forum</p>
<hr />
<div>== Quality level mapping ==<br />
The rendering quality of ALS effects is controlled by two main sliders, the landmass effects and transition effects. The transition effects slider regulates the quality of overlaid textured, while the landmass effects slider regulates all other aspects of procedural texturing, such as pixel color post-processing (dust, snow or wet terrain effects) and apparent terrain roughness (bump and parallax mapping).<br />
<br />
In addition, specific effects for certain terrain types (water, urban, forest, agriculture, etc.) and models in the scene can be switched on separately. In some cases, this may be needed for a consistent visual impression. For example, if a dust effect is used on the terrain, the water needs to be rendered using a separate water shader, otherwise it will appear dusty as well. Likewise, if the Rayleigh haze is used in the highest quality terrain effect, then the highest quality water effect needs to be used to see the same Rayleigh scattering effect on the water.<br />
<br />
For technical reasons (landmass and transition control the same shader code) the settings are sometimes mutually dependent, e.g., if the transition quality is set to level 6, it won't have any effect until the landmass quality is also set to level 6.<br />
<br />
=== Transition ===<br />
The mapping of quality to visuals of the transition slider is as follows:<br />
<br />
{| class="wikitable"<br />
! Level !! Comments<br />
|-<br />
! scope="row" | 1<br />
| Base texture scheme<br />
|-<br />
! scope="row" | 2<br />
| Alternative hires airport keep effect<br />
|-<br />
! scope="row" | 3<br />
|<br />
* Base and overlay texture, runway effect (if landmass is above level 4)<br />
* Secondary lights on runway and airport keep<br />
|-<br />
! scope="row" | 4<br />
| Base, overlay and hires texture<br />
|-<br />
! scope="row" | 5<br />
| Base, overlay, hires, detail, grain, dot and rock texture (if landmass is level 6)<br />
|}<br />
<br />
=== Landmass ===<br />
{{Note|Quality levels 1 and 2 are reserved to represent fixed pipeline rendering and the "default renderer" in an eventually merged rendering GUI. However, ALS is currently switched on per checkbox and not by quality level, and so they do not have a function.}}<br />
<br />
{| class="wikitable"<br />
! Level !! Comments<br />
|-<br />
! scope="row" | 1<br />
| ''See note above''<br />
|-<br />
! scope="row" | 2<br />
| ''See note above''<br />
|-<br />
! scope="row" | 3<br />
| ALS-rendered position-differential haze and light, moonlight<br />
|-<br />
! scope="row" | 4<br />
| <br />
* Procedural snow cover on terrain<br />
* Procedural dust and vegetation effects<br />
* Wet terrain effect with approximate reflection half vector<br />
* Patchy fog distribution<br />
|-<br />
! scope="row" | 5<br />
| Noise bump-mapping and parallax mapping of terrain<br />
|-<br />
! scope="row" | 6<br />
| (''Requires transition effect level 6'')<br />
* Wet terrain effect with correct reflection half vector<br />
* Hires bump mapping and snow patchiness<br />
* Variable upper haze layer surface<br />
* Rayleigh haze<br />
* Secondary lights on all terrain types<br />
* Slope line and strata effects<br />
|}<br />
<br />
== ALS secondary lights ==<br />
The ALS framework supports a generic implementation of landing lights and a searchlight which are based on a framerate-friendly computation in screen coordinates, i.e., the lights project correctly ''only if the light is close to the viewer'' (typically, that would be from cockpit view). In other words, this is not a full (and rather expensive) computation of light volumes as in Rembrandt, but a much faster test of illuminated screen areas.<br />
<br />
[[File:Landing light03.jpg|400px|Cessna 172P using generic ALS landing lights]]<br />
<br />
Two landing lights and a searchlight are supported. The landing lights have a fixed position with respect to the aircraft axis (technically, with respect to the default view axis as defined in the respective view), whereas the searchlight follows any offset of the view axis in view mode, i.e., when using the mouse to look around, the searchlight will follow the motion, the landing lights will not. The lights require ALS to run above basic quality level and work on runway and airport keep above transition setting 3 and everywhere else only at highest quality setting. All lights are controlled via properties in <code>/sim/rendering/als-secondary-lights/</code>.<br />
<br />
The names of the properties should be self-explanatory, if for instance if <code>/sim/rendering/als-secondary-lights/use-searchlight</code> is set to true, then the searchlight (which always follows the current view axis) is used. <br />
<br />
The properties <code>/sim/rendering/als-secondary-lights/landing-light1-offset-deg</code> and <code>/sim/rendering/als-secondary-lights/landing-light2-offset-deg</code> allow to specify angular offsets for the landing light which are then not centered on the view axis. This can be used to simulate one or two landing lights set in the wings.<br />
<br />
[[File:Offsetv2.jpg|400px|Secondary lights vertical offset demo]]<br />
<br />
A third offset <code>/sim/rendering/als-secondary-lights/landing-light3-offset-deg</code> is available which allows for a vertical offset. This is especially useful for tail dagger aircraft.<br />
<br />
[[File:Offsetv.jpg|400px|Secondary lights vertical offset settings]]<br />
<br />
The lights can be switched on and off from the [[Property Browser]] for any aircraft without any modifications to the aircraft definition. Implementing them correctly aircraft side thus just involves linking the landing light switches to the ALS control properties and setting the correct angular offsets. Additionally, it is recommended to switch the lights off unless in a cockpit view, as they don't project correctly for any external view.<br />
<br />
Range, color, light cone opening angle or intensity of the lights can currently not be configured, and there are no plans to support such a feature in the near future.<br />
<br />
All three lights will illuminate fog (if dense enough) and precipitation.<br />
<br />
[[File:Als secondary light fog.jpg|400px|ALS generic lights illuminating dense fog]]<br />
<br />
== ALS specific features of the model effect ==<br />
<br />
In addition to the features supported by the model-combined-deferred effect in all three renderers (normal, light, specular, environment reflection and dirt map), ALS also supports a couple of unique effects (which, if configured, will not have any effect in other renderers.<br />
<br />
=== The grain texture ===<br />
<br />
ALS supports a grain texture for models. This is a semi-transparent overlay texture that works just as [[Procedural Texturing#The grain texture|its equivalent for terrain texturing]] and provides the option of generating centimeter-scale details such as rust or discoloration on a surface without having to use huge textures. An example of a surface rendered with grain texture is the image of the USS Vinson flightdeck below:<br />
<br />
[[File:Grain rain01.jpg|700px|Grain and rain effects on Vinson's flightdeck]]<br />
<br />
This is done using the following effect declaration inheriting from '''model-combined-deferred.eff''' as<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<br />
<PropertyList><br />
<br />
<name>flightdeck</name><br />
<inherits-from>Effects/model-combined-deferred</inherits-from><br />
<parameters><br />
<grain-texture-enabled type="int">2</grain-texture-enabled><br />
<grain-magnification type="float">0.1</grain-magnification><br />
<rain-enabled type="int">2</rain-enabled><br />
<texture n="7"><br />
<image>Models/Geometry/Nimitz/rust_texture.png</image><br />
<type>2d</type><br />
<filter>linear-mipmap-linear</filter> <br />
<wrap-s>repeat</wrap-s><br />
<wrap-t>repeat</wrap-t><br />
<internal-format>normalized</internal-format><br />
</texture><br />
</parameters><br />
<br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
The grain texture has the number 7 and needs to be enabled by<br />
<syntaxhighlight lang="xml"><br />
<grain-texture-enabled type="int">2</grain-texture-enabled><br />
</syntaxhighlight><br />
<br />
If the value is set to 1, the grain texture uses the uv-mapping of the underlying surface. If that is very irregular (as in the case of the Vinson flightdeck), alternatively the grain can be mapped in xy-model coordinates if the parameter is set to 2, the uv-mapping of the base texture layer is then discarded.<br />
<br />
The resolution of the grain texture with respect to the base coordinate layer is specified by<br />
<syntaxhighlight lang="xml"><br />
<grain-magnification type="float">0.1</grain-magnification><br />
</syntaxhighlight><br />
<br />
If the number is less than 0, the grain resolution is lower than the base layer. If the parameter is greater than 0, it is higher (note that in the above case, the grain is mapped to (xy) rather than (uv), hence the base size is 1 m, so the grain texture is mapped on a 10x10 m patch on the flightdeck, for which a 1024x1024 pixel texture provides ~1 cm sized details).<br />
<br />
=== The rain effect ===<br />
<br />
Any number greater than 0 passed to<br />
<syntaxhighlight lang="xml"><br />
<rain-enabled type="int">2</rain-enabled><br />
</syntaxhighlight><br />
<br />
enables the splash effect of raindrops on the surface if it points upward. The surface does not have to be flat for this to work, the effect checks for the surface normal automatically, see the rain enabled for the Citation Bravo.<br />
<br />
Thorsten noted about rain splashes: "Works fine here - runway needs to get really wet though before you see them (put the environment slider to max to achieve this quickly, it will take some waiting with just rain on)."<br />
<br />
[[File:Grain rain02.jpg|700px|Rain effect on the Citation Bravo]]<br />
<br />
<br />
=== Glossy surfaces ===<br />
<br />
To better treat the environment reflections on a glossy surface, ALS contains two options not present in the other renderers.<br />
<br />
<br />
<syntaxhighlight lang="xml"><br />
<reflection-type type="int">1</reflection-type><br />
</syntaxhighlight><br />
<br />
This parameter can currently be set to 1 or 2 and regulates how the color of the environment reflection is merged with the color of the glossy surface. If set to 1, the shader uses a color mixing as in the other two renderers, if set to 2 it uses a technique called 'grain merge' which gives different weight to the color channels. The reason for introducing type 2 was a grey tint which changed the reflected color in a unrealistic way. With FlightGear 2017.2.0 this will be fixed and type set to 2 should be obsolete then.<br />
<br />
<syntaxhighlight lang="xml"><br />
<reflection-fresnel-factor type="float">0.0</reflection-fresnel-factor><br />
</syntaxhighlight><br />
<br />
This parameter regulates how strong the Fresnel term of a glossy surface is. Many smooth surfaces reflect much more under shallow angles such that an environment reflection is not very prominent when looking under 90 degrees but dominates the visuals when looking under a grazing angle. The parameter sets the relative strength of a Fresnel reflection with respect to the basic reflection definition which is assumed to hold for vertical viewing (i.e. setting the parameter to 0.8 gives you extra glossiness under shallow angles).<br />
<br />
The following comparison shows the default color mixing (upper left) for a reflecting white livery and for grain merge (upper right). In addition, note the enhanced Fresnel reflectivity at the tail and the cowling on the pictures. The lower row shows (left) full reflection with default color mixing and (right) for grain merge. Default color mixing is more physically correct, while grain merge is less correct but preserves white color much better.<br />
<br />
[[File:Reflect Model default2.jpg|400px|Effect of color mixing in a reflection]]<br />
[[File:Reflect Grain merge2.jpg|400px|Effect of grain merge in reflection]]<br />
<br />
[[File:Reflect Model Default Full.jpg|400px|Full reflection with default ]]<br />
[[File:Reflect Grain Merge Full.jpg|400px|Full reflection with grain merge]]<br />
<br />
== The exhaust flame effect ==<br />
<br />
Rendering proper flames of e.g. afterburners or rocket thrusters with diffuse edges is notoriously difficult - all solutions based on textured models tend to have unnaturally sharp edges. Usually the particle system is used in such cases, however at high velocities this has other issues - particles become easily separated, making flames look disrupted and detached from the exhaust.<br />
<br />
ALS includes a dedicated procedural effect in which the flame is rendered by numerically integrating a 3-dim distribution of glowing emitters inside a bounding box (i.e. re-creates the process by which a real flame would be seen). The function which determines the emitter distribution is partially user-controlled so that a wide range of shapes can be generated.<br />
<br />
To use the effect, first the bounding box has to be defined. Note that the shape and alignment of the bounding box needs to be standardized for the effect to work, i.e. you need to use either the default bounding box under Aircraft/Generic/Effects/Thruster/ or make a custom one which fits inside the default box at the same location in model coordinates.<br />
<br />
To change position, size and orientation of the bounding box to match with the airplane model, translate, scale and rotate animations or model offsets can later be used.<br />
<br />
=== Model definition for effect ===<br />
This is a standard XML model definition that needs to specify the geometry, all animations and the effect to use. For the geometry you can use the standard ''Aircraft/Generic/Effects/Thruster/thrust_flame.ac'' or make your own. The F-15 uses a slightly different 3D model to allow for the nozzles. The 3D model needs to be big enough to contain the flame, bearing in mind that the flame is drawn as a cylinder.<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<PropertyList><br />
<br />
<path>Aircraft/Generic/Effects/Thruster/thrust_flame.ac</path><br />
<nopreview/><br />
<animation><br />
<type>scale</type><br />
<property alias="/params/augmentation-alight"/><br />
<x-min>0.2</x-min><br />
<y-min>0.3</y-min><br />
<z-min>0.3</z-min><br />
<y-max>1</y-max><br />
<z-max>1</z-max><br />
<x-factor>0.472</x-factor><br />
<y-factor>0.6</y-factor><br />
<z-factor>0.6</z-factor><br />
</animation><br />
<animation><br />
<type>select</type><br />
<object-name>ALS-FlameTrail</object-name><br />
<condition><br />
<greater-than><br />
<property alias="/params/augmentation-ignition"/><br />
<value>0.8</value><br />
</greater-than><br />
</condition><br />
</animation><br />
<br />
<effect><br />
<inherits-from>Aircraft/MyAircraft/Models/Effects/my-flame</inherits-from><br />
<object-name>Bounding_box</object-name><br />
</effect><br />
<br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
=== Effect definition for model ===<br />
To define the effect to apply to the model (as referenced in the ''effect'' section in the model XML) you need to create ''my-flame.eff'' as below. The ''.eff'' file defines the parameters that are passed into the shader and it is these that control how the flame looks.<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf-8"?><br />
<PropertyList><br />
<name>AB-flame</name><br />
<inherits-from>Effects/thrust-flame</inherits-from><br />
<parameters><br />
<base_flame_b type="float">0.8</base_flame_b><br />
<base_flame_density type="float">0.6</base_flame_density><br />
<base_flame_g type="float">0.9</base_flame_g><br />
<base_flame_r type="float">0.9</base_flame_r><br />
<deflection_coeff type="float">0</deflection_coeff><br />
<flame_color_high_b type="float">0.8</flame_color_high_b><br />
<flame_color_high_g type="float">0.85</flame_color_high_g><br />
<flame_color_high_r type="float">0.9</flame_color_high_r><br />
<flame_color_low_b type="float">0.07</flame_color_low_b><br />
<flame_color_low_g type="float">0.15</flame_color_low_g><br />
<flame_color_low_r type="float">0.35</flame_color_low_r><br />
<flame_radius_fraction type="float">0.8</flame_radius_fraction><br />
<noise_scale type="float">0.3</noise_scale><br />
<noise_strength type="float">0.2</noise_strength><br />
<thrust_collimation type="float">0.1</thrust_collimation><br />
<thrust_density type="float">0.7</thrust_density><br />
<use_noise type="int">1</use_noise><br />
<use_shocks type="int">1</use_shocks><br />
</parameters><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
There is also a detailed version (utilizing 3d noise and a higher sampling resolution) available. This has to be explicitly requested in a derived effect by overriding the default shader choice with the detailed version, i.e. bu inserting<br />
<br />
<syntaxhighlight lang="xml"><br />
<technique n="4"><br />
<pass><br />
<program><br />
<fragment-shader n="0">Shaders/thrustflame-ALS-detailed.frag</fragment-shader><br />
</program><br />
</pass><br />
</technique><br />
</syntaxhighlight><br />
<br />
below the parameter section.<br />
<br />
{{Note|The detailed shader uses four times as much performance at least - only use it if you really need it!}}<br />
<br />
=== F-15 Afterburner example image === <br />
The F-15 afterburner flame shown below (at different ambient lighting based on time) uses the parameters above. The main parameters of importance, and therefore to tune, for an aircraft jet engine are the colors, the two densities, the flame radius fraction. The base density is at the start of the flame and this. The F-15 overlays a billboarded image to achieve the diamonds that are interleaved with the ALS drawn flame. <br />
<br />
<br />
[[File:F-15 afterburner using ALS Thrust Effect.jpg|700px|This shows the F-15 afterburner at different ambient light.]]<br />
<br />
The meaning of the parameters are as follows:<br />
<br />
<syntaxhighlight lang="xml"><br />
<use_shocks type="int">1</use_shocks><br />
<use_noise type="int">1</use_noise><br />
</syntaxhighlight><br />
<br />
<syntaxhighlight lang="xml" inline><use_shocks></syntaxhighlight> and <syntaxhighlight lang="xml" inline><use_noise></syntaxhighlight> are the parameters that control the random noise and the shock diamonds. Both are modestly computationally expensive, i.e. if these effects are not required it is better to switch them off by setting these values to zero.<br />
<br />
<syntaxhighlight lang="xml"><br />
<flame_color_low_r type="float">0.95</flame_color_low_r><br />
<flame_color_high_r type="float">1.0</flame_color_high_r><br />
<base_flame_r type="float">0.8</base_flame_r><br />
</syntaxhighlight><br />
<br />
(same for the (g,b) channels) set the color. base_flame refers to the part of the flame which is directly attached to the thruster and usually brightest. flame_color_high refers to the high density part of the flame, flame_color_low refers to the low density parts of the flame. (rgb) values always need to be [0:1]<br />
<br />
<syntaxhighlight lang="xml"><br />
<thrust_density type="float">1.0</thrust_density><br />
<base_flame_density type="float">0.1</base_flame_density><br />
</syntaxhighlight><br />
<br />
determine the overall emitter density in the flame and in the base directly at the thruster respectively. There's no formal upper limit for the parameters, but a flame with density 1 already appears fairly opaque.<br />
<br />
<syntaxhighlight lang="xml"><br />
<flame_radius_fraction type="float">0.8</flame_radius_fraction><br />
</syntaxhighlight><br />
<br />
governs how much of the bounding box the flame radius at the exhaust nozzle fills. If the flame needs to expand (as for the plume of a thruster operating in vacuum) or needs to bend (as for a flame deflected by the airstream) this parameter needs to be small, if the flame is essentially cylindrical the paramater can be chosen close to 1 to minimize clipping errors. Note that this determines the size of the flame relative to the bounding box - the overall size of the flame should be adjusted by using a scale animation on the bounding box<br />
<br />
<syntaxhighlight lang="xml"><br />
<noise_strength type="float">0.2</noise_strength><br />
<noise_scale type="float">0.3</noise_scale><br />
</syntaxhighlight><br />
<br />
determined how turbulent the flame looks. noise_strength [0:1] determines how prominently the noise influences the flame and noise_scale (in meters relative to the original bounding box) determines how large the visible patches of turbulence are (given that the original bounding box is not larger than 5 m in the longest direction, the parameter should probably kept between 0.1 and 5).<br />
<br />
<syntaxhighlight lang="xml"><br />
<shock_frequency>1.0</shock_frequency><br />
</syntaxhighlight><br />
<br />
influences at what distance shock diamonds appear in the flame. Useful values are perhaps between 0.2 and 5.<br />
<br />
<syntaxhighlight lang="xml"><br />
<thrust_collimation type="float">0.1</thrust_collimation> <br />
</syntaxhighlight><br />
<br />
should take a value of between 0 and 1 and determines how collimated the flame is. For values > 0, the flame is widened - note that this requires a sufficiently small flame radius fraction to avoid clipping errors. For widened flames, the density is automatically lowered and shock diamonds are removed.<br />
<br />
<syntaxhighlight lang="xml"><br />
<deflection_coeff type="float">0.</deflection_coeff><br />
</syntaxhighlight><br />
<br />
should be somewhere between 0 and 0.06 and gives a lateral deflection (such as by an airstream) to the flame. Note that this re-positions the origin of the flame in the bounding box to better utilize the bounding box volume, i.e. if you need a dynamical deflection, you also need a translate animation for the bounding box.<br />
<br />
Any of those parameters can be adjusted runtime by replacing the value with <syntaxhighlight lang="xml" inline><use>/my-property</use></syntaxhighlight>. Dependent on how <code>/my-property</code> is created it might be tied though (in particular JSBSim-computed properties are) in which case it is not picked up by the effect framework - you need to copy it via property rule to an untied property then. This allows to render dynamical changes of the flame.<br />
<br />
For instance the [[SpaceShuttle - Project Overview|Space Shuttle]] main engines use<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<PropertyList><br />
<name>ssme-flame</name><br />
<inherits-from>Effects/thrust-flame</inherits-from><br />
<parameters><br />
<flame_color_low_r>0.9</flame_color_low_r><br />
<flame_color_low_g>0.7</flame_color_low_g><br />
<flame_color_low_b>0.5</flame_color_low_b><br />
<flame_color_high_r>0.7</flame_color_high_r><br />
<flame_color_high_g>0.7</flame_color_high_g><br />
<flame_color_high_b>1.0</flame_color_high_b><br />
<base_flame_r type="float">0.8</base_flame_r><br />
<base_flame_g type="float">1.0</base_flame_g><br />
<base_flame_b type="float">1.0</base_flame_b><br />
<use_shocks type="int">1</use_shocks><br />
<use_noise type="int">1</use_noise><br />
<thrust_collimation><use>/sim/systems/various/ssme-flame-collimation</use></thrust_collimation> <br />
<thrust_density><use>/sim/systems/various/ssme-flame-density</use></thrust_density><br />
<base_flame_density type="float">1.0</base_flame_density><br />
<shock_frequency>1.0</shock_frequency><br />
<noise_strength>0.3</noise_strength><br />
<noise_scale>0.1</noise_scale><br />
</parameters><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
to simulate the change of flame geometry in the thin upper atmosphere during ascent:<br />
<br />
[[File:Shuttle flame05.jpg|400px|Space Shuttle main engine flames during early ascent]]<br />
[[File:Shuttle flame06.jpg|400px|Space Shuttle main engine flames during late ascent]]<br />
<br />
Using the deflection parameter, the curved SRB separation motor flames are rendered using<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<br />
<PropertyList><br />
<name>SRBsep-flame</name><br />
<inherits-from>Effects/thrust-flame</inherits-from><br />
<parameters><br />
<flame_color_low_r type="float">0.95</flame_color_low_r><br />
<flame_color_low_g type="float">0.55</flame_color_low_g><br />
<flame_color_low_b type="float">0.1</flame_color_low_b><br />
<flame_color_high_r type="float">1.0</flame_color_high_r><br />
<flame_color_high_g type="float">1.0</flame_color_high_g><br />
<flame_color_high_b type="float">1.0</flame_color_high_b><br />
<use_shocks type="int">0</use_shocks><br />
<use_noise type="int">1</use_noise><br />
<thrust_collimation type="float">0.4</thrust_collimation> <br />
<thrust_density type="float">1.0</thrust_density><br />
<base_flame_density type="float">0.0</base_flame_density><br />
<noise_strength type="float">0.7</noise_strength><br />
<noise_scale type="float">0.4</noise_scale><br />
<deflection_coeff type="float">-0.06</deflection_coeff><br />
<flame_radius_fraction type="float">0.1</flame_radius_fraction><br />
</parameters><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
<br />
[[File:Flame_sep.jpg|700px|Space Shuttle SRB separation motor flames]]<br />
<br />
Application of the effect is not limited to flames, it can also do heat blur (think a very transparent, high-noise dark emitter distribution) or vapour trails and other smoke.<br />
<br />
By itself, the effect does however not compute ambient and diffuse light channels, i.e. for non-emissive distributions lighting is the responsibility of the user. One quick way of obtaining a correct fading of color with light in the scene is to create an untied property based on<br />
<br />
<code>/rendering/scene/diffuse/red</code><br />
<br />
and used this to scale all color values.<br />
<br />
{{note|Do not use the full (rgb) information in the property tree for ALS, it will produce pronounced color mismatches with the rest of the scene as ALS determines light inside the shader and never uses the properties.}}<br />
<br />
== Chute animation effect ==<br />
<br />
The chute animation effect is designed to provide a natural appearance of the deformation and the fluttering motion of a piece of cloth under changing stress.<br />
<br />
[[File:Chute seq01.jpg|400px|Drag chute separation sequence 1]] [[File:Chute seq03.jpg|400px|Drag chute separation sequence 2]]<br />
<br />
<br />
=== Coordinate system ===<br />
<br />
The shader assumes that the 3d mesh of the chute is oriented in a particular coordinate system. The z-axis (upward) should extend from the zero point where the various ropes come together to the canopy above through the center of the model. The canopy of the chute should therefore roughly be in the xy plane.<br />
<br />
To position the chute correctly with the aircraft, you then need to use appropriate offsets and rotations when loading.<br />
<br />
=== Effect definition for model ===<br />
<br />
To define the effect to apply to the model (as referenced in the ''effect'' section in the model XML) you need to create ''mychute.eff'' as below. The ''.eff'' file defines the parameters that are passed into the shader and it is these that control the behavior.<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf-8"?><br />
<PropertyList><br />
<name>mychute</name><br />
<inherits-from>Effects/chute</inherits-from><br />
<parameters><br />
<chute_force><use>Aircraft/MyAircraft/myforce</use></chute_force><br />
<chute_projection_z>0.0</chute_projection_z><br />
<chute_fold>0.0</chute_fold><br />
<chute_bend>0.0</chute_bend><br />
</parameters><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
<br />
The meaning of these parameters is as follows:<br />
<br />
<syntaxhighlight lang="xml"><br />
<chute_projection_z>0.0</chute_projection_z><br />
</syntaxhighlight><br />
<br />
This is the distance of the branching point of the various lines leading to the canopy (at model coordinate zero) to the edge of the canopy. All transformations affecting the shape of the canopy (in particular the collapse of the canopy if the force is gone) will be applied with respect to this reference plane.<br />
<br />
<syntaxhighlight lang="xml"><br />
<chute_force><use>Aircraft/MyAircraft/myforce</use></chute_force><br />
</syntaxhighlight><br />
<br />
This is a normalized force applied to the canopy. The chute should be modeled with a deformation corresponding to a force parameter of 1 - any higher value will narrow the chute's radius, deepen the chute's deformation along the z-axis and increase the motion, any lower value will widen chute radius (compare screenshots above) and lessen its depth and slow down motion. The normal parameter range should be from [0:2], any higher or lower may look odd.<br />
<br />
<syntaxhighlight lang="xml"><br />
<chute_fold>0.0</chute_fold><br />
<chute_bend>0.0</chute_bend><br />
</syntaxhighlight><br />
<br />
These are deformation modes used to animate a chute after jettison when it is no longer pulled into shape and can flutter through the air. The first one [0:1] is a general collapse into the projection plane with random deformations around, the second one [-1:1] is a gross bending mode of the projection plane itself. Before jettison, these parameters should default to 0.<br />
<br />
=== Jettison animation ===<br />
<br />
A complete animated jettison sequence is quite complex and would usually require a Nasal sequence taking the chute through a deceleration trajectory (utilizing translation and rotation animations), bending ad folding oscillations and finally some unfolding as it sinks through the air. The Space Shuttle chute uses the following control loop for 10 seconds of jettison dynamics:<br />
<br />
<syntaxhighlight lang="nasal"><br />
var drag_chute_jettison_animation = func (time) {<br />
<br />
var dt = getprop("/sim/time/delta-sec");<br />
time = time + dt;<br />
<br />
# horizontal motion<br />
<br />
var x = 0.0;<br />
<br />
if (time > 2.0)<br />
{x = -16.0 + 20.0 * time;}<br />
else<br />
{x = 2.0 * time + 5.0 * time * time;}<br />
<br />
<br />
setprop("/controls/shuttle/drag-chute-dist",x);<br />
<br />
# vertical motion<br />
<br />
var y = 0.0;<br />
if (time > 5.0)<br />
{<br />
y = -2.5 + 0.6 * (time-5.0) * (time-5.0);<br />
}<br />
else <br />
{<br />
y = -0.2 * time;<br />
}<br />
if (y > 12.5) {y=12.5;}<br />
<br />
setprop("/controls/shuttle/drag-chute-down",y);<br />
<br />
# fold<br />
<br />
var f = 0.5 * time;<br />
if (f> 1.0) {f = 1.0;}<br />
if (time > 9.5)<br />
{f = 0.25 + 1.5 + (time-9.5);}<br />
if (time > 6.0)<br />
{<br />
f = f -0.3* (time-7.0); <br />
if (f<0.1) {f=0.1;}<br />
}<br />
setprop("/controls/shuttle/drag-chute-fold", f);<br />
<br />
# rotate<br />
<br />
var r = (time - 2.0) * 18.0;<br />
if (r>90.0) {r=90.0;}<br />
if (r<0.0) {r=0.0;}<br />
setprop("/controls/shuttle/drag-chute-slant", r);<br />
<br />
# bend<br />
<br />
var b = 0;<br />
if (time > 7.5)<br />
{b = 0;}<br />
else if (time >6.0)<br />
{b = 0.75 - 0.5 * (time - 6.0);} <br />
else if (time > 4.5) <br />
{b = (time - 4.5) * 0.5;}<br />
else {b=0;} <br />
<br />
setprop("/controls/shuttle/drag-chute-bend", b);<br />
<br />
if (time > 10.0) <br />
{<br />
print("Exiting...");<br />
settimer (func { setprop("/controls/shuttle/drag-chute-deploy-timer", 0); }, 0.5);<br />
return;<br />
}<br />
<br />
setprop("/test/timer", time);<br />
<br />
settimer( func{ drag_chute_jettison_animation (time); }, 0);<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
== ALS glass effect ==<br />
<br />
As of FlightGear version 3.5, ALS supports a glass effect with dynamic response to the environment which can render, for instance, the splashes of raindrops on the canopy, frost or fogging.<br />
<br />
[[File:Glass01.jpg|400px|Frost effect]]<br />
[[File:Glass07.jpg|400px|Raindrop splashes]]<br />
<br />
The base effect properties are controlled via inheritance and the environment response run-time via properties residing in <b>/environment/aircraft-effects</b>. Derived effects should inherit from <b>Effects/glass</b>. Any surface using the glass effect will automatically register itself as transparent for use in [[Project Rembrandt| Rembrandt]]. <br />
<br />
The glass effect is primarily intended for interior views. In particular, no external fog or haze is rendered for the glass, i.e. if the effect is used in an outside view, it is the responsibility of the aircraft modeler to take care (e.g. with LOD settings or range animations) that no problems in bad visibility occur.<br />
<br />
=== Why a separate effect for glass seen from inside? ===<br />
<br />
Basically because the two situations are rather different. Slight dirt on the glass against the background of the sky from inside is rather prominent, against the background of the cockpit seen from outside it is not. Visuals from inside are dominated by Mie forward scattering of light, leading to a bright glare effect when looking at dirt, frost, fog or scratches close to the sun. From outside, reflected light rather than transmitted light is dominant. The reflection of any external object on the outside of the glass changes as the aircraft moves, this is not the case for the reflection of the cockpit in the glass seen from the inside. <br />
<br />
The viewing situation is also different. From the inside, we usually do not focus the eyes on the plane of the glass but look through it, from the outside the focus of the eyes is often close to the glass surface. For something half a meter before the eye, we also need to apply a lot more resolution and details than for an object typically seen from 10+ meters from the outside.<br />
<br />
Add to this that atmospheric fog is never relevant for glass seen from inside but for glass seen from outside, and it suddenly makes sense to use a different effect.<br />
<br />
The recommended effect for glass surfaces seen from outside is model-combined-transparent.eff.<br />
<br />
<br />
=== Rain ===<br />
Rain splashes will render automatically when the weather system reports rain via environment/rain-norm. In addition, the user can set rain splashes to render via <code>environment/aircraft-effects/ground-splash-norm</code> (this is intended to allow splashes to be rendered e.g., for water landings of aircraft equipped with floats).<br />
<br />
By default, the rain splashes impact from above (more precisely the +z direction in model coordinates). This may be inadequate if the aircraft is moving. However, the shader can not know what the airstream at the glass will be, so the impact vector of rain splashes has to be modeled aircraft-side and set via <code>environment/aircraft-effects/splash-vector-x</code> (<code>splash-vector-y</code>, <code>splash-vector-z</code>). These are likewise in model coordinates.<br />
<br />
As long as the length of the splash vector is less than 1, just the impact angle will change, as the length of the vector increases to 2, droplets will also be visibly moving. This allows fine control of the visuals dependent on any number of factors desired. A simple Nasal snipped varying the splash vector with airspeed for the F-16 is given below (but ''do not mindlessly copy and expect to work for any aircraft — it won't!''). This example is for normals pointing outwards, if the normals are pointing inwards the vector needs to be inverted.<br />
<br />
<syntaxhighlight lang="nasal"><br />
var splash_vec_loop = func(){<br />
var airspeed = getprop("/velocities/airspeed-kt");<br />
<br />
# f16<br />
var airspeed_max = 120;<br />
<br />
if (airspeed > airspeed_max) {<br />
airspeed = airspeed_max;<br />
}<br />
<br />
airspeed = math.sqrt(airspeed / airspeed_max);<br />
<br />
var splash_x = -0.1 - 2 * airspeed;<br />
var splash_y = 0.0;<br />
var splash_z = 1.0 - 1.35 * airspeed;<br />
<br />
setprop("/environment/aircraft-effects/splash-vector-x", splash_x);<br />
setprop("/environment/aircraft-effects/splash-vector-y", splash_y);<br />
setprop("/environment/aircraft-effects/splash-vector-z", splash_z);<br />
<br />
settimer(func(){<br />
splash_vec_loop();<br />
}, 1);<br />
}<br />
</syntaxhighlight><br />
<br />
Note the timing constant of the loop — running the update per-frame leads to a spurious movement of the coordinate system in which rain is rendered and spoils the effect.<br />
<br />
<br />
Another method when using JSBSIM would be to use a combination of FCS Functions and Filters.<br />
<br />
<syntaxhighlight lang="xml"><br />
<system name="c172p-glass-effects"><br />
<channel name="rain"><br />
<fcs_function name="glass-effects/splashx"><br />
<function><br />
<difference><br />
<value>-0.1</value><br />
<product><br />
<value>2.0</value><br />
<sqrt><br />
<quotient><br />
<min><br />
<property>/velocities/airspeed-kt</property><br />
<value>40</value><br />
</min><br />
<value>40</value><br />
</quotient><br />
</sqrt><br />
</product><br />
</difference><br />
</function><br />
</fcs_function><br />
<fcs_function name="glass-effects/splashz"><br />
<function><br />
<difference><br />
<value>1.0</value><br />
<product><br />
<value>1.35</value><br />
<sqrt><br />
<quotient><br />
<min><br />
<property>/velocities/airspeed-kt</property><br />
<value>40</value><br />
</min><br />
<value>40</value><br />
</quotient><br />
</sqrt><br />
</product><br />
</difference><br />
</function><br />
</fcs_function><br />
</channel><br />
</system><br />
</syntaxhighlight><br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<PropertyList><br />
<filter><br />
<name>splashX</name><br />
<type>gain</type><br />
<input><br />
<property>/fdm/jsbsim/glass-effects/splashx</property><br />
</input><br />
<output><br />
<property>/environment/aircraft-effects/splash-vector-x</property><br />
</output><br />
</filter><br />
<filter><br />
<name>splashY</name><br />
<type>gain</type><br />
<input><br />
<value>0.0</value><br />
</input><br />
<output><br />
<property>/environment/aircraft-effects/splash-vector-y</property><br />
</output><br />
</filter><br />
<filter><br />
<name>splashZ</name><br />
<type>gain</type><br />
<input><br />
<property>/fdm/jsbsim/glass-effects/splashz</property><br />
</input><br />
<output><br />
<property>/environment/aircraft-effects/splash-vector-z</property><br />
</output><br />
</filter><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
You could reduce the above method and eliminate the "filters" by doing the following.<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<system name="c172p-glass-effects"><br />
<channel name="rain"><br />
<fcs_function name="glass-effects/airspeed-clamped-sqrt"><br />
<function> <br />
<sqrt><br />
<quotient><br />
<min><br />
<property>/velocities/airspeed-kt</property><br />
<value>40</value><br />
</min><br />
<value>40</value><br />
</quotient><br />
</sqrt><br />
</function><br />
</fcs_function><br />
<fcs_function name="glass-effects/splashx"><br />
<function><br />
<difference><br />
<value>-0.1</value><br />
<product><br />
<value>2.0</value><br />
<property>/fdm/jsbsim/glass-effects/airspeed-clamped-sqrt</property><br />
</product><br />
</difference><br />
</function><br />
<output>/environment/aircraft-effects/splash-vector-x</output><br />
</fcs_function><br />
<fcs_function name="glass-effects/splashy"><br />
<function><br />
<value>0.0</value><br />
</function><br />
<output>/environment/aircraft-effects/splash-vector-y</output><br />
</fcs_function><br />
<fcs_function name="glass-effects/splashz"><br />
<function><br />
<difference><br />
<value>1.0</value><br />
<product><br />
<value>1.35</value><br />
<property>/fdm/jsbsim/glass-effects/airspeed-clamped-sqrt</property><br />
</product><br />
</difference><br />
</function><br />
<output>/environment/aircraft-effects/splash-vector-z</output><br />
</fcs_function><br />
</channel><br />
</system><br />
</syntaxhighlight><br />
<br />
Yet another method (currently used in the c172p) limits movement to a range of table entries. This gives the developer the ability to control the behavior even more.<br />
<syntaxhighlight lang="xml"><br />
<PropertyList><br />
<filter><br />
<name>splash-xa</name><br />
<update-interval-secs type="double">0.1</update-interval-secs><br />
<type>gain</type><br />
<gain>1.0</gain><br />
<input><br />
<expression><br />
<table><br />
<property>/velocities/airspeed-kt</property><br />
<entry><ind> 0 </ind><dep> -0.33 </dep></entry><br />
<entry><ind> 4 </ind><dep> -0.33 </dep></entry><br />
<entry><ind> 5 </ind><dep> -1.7 </dep></entry><br />
<entry><ind> 50 </ind><dep> -2.1 </dep></entry><br />
</table><br />
</expression><br />
</input><br />
<output><br />
<property>/environment/aircraft-effects/splash-xa</property><br />
</output><br />
</filter><br />
<filter><br />
<name>splash-za</name><br />
<update-interval-secs type="double">0.1</update-interval-secs><br />
<type>gain</type><br />
<gain>1.0</gain><br />
<input><br />
<expression><br />
<table><br />
<property>/velocities/airspeed-kt</property><br />
<entry><ind> 0 </ind><dep> 0.82 </dep></entry><br />
<entry><ind> 4 </ind><dep> 0.82 </dep></entry><br />
<entry><ind> 5 </ind><dep> -0.17 </dep></entry><br />
<entry><ind> 50 </ind><dep> -0.35 </dep></entry><br />
</table><br />
</expression><br />
</input><br />
<output><br />
<property>/environment/aircraft-effects/splash-za</property><br />
</output><br />
</filter><br />
<filter><br />
<name>splash-xr</name><br />
<update-interval-secs type="double">0.1</update-interval-secs><br />
<type>gain</type><br />
<gain>1.0</gain><br />
<input><br />
<expression><br />
<table><br />
<property>/engines/active-engine/rpm</property><br />
<entry><ind> 0 </ind><dep> -0.33 </dep></entry><br />
<entry><ind> 600 </ind><dep> -0.33 </dep></entry><br />
<entry><ind> 601 </ind><dep> -1.3 </dep></entry><br />
<entry><ind> 1500 </ind><dep> -1.9 </dep></entry><br />
</table><br />
</expression><br />
</input><br />
<output><br />
<property>/environment/aircraft-effects/splash-xr</property><br />
</output><br />
</filter><br />
<filter><br />
<name>splash-zr</name><br />
<update-interval-secs type="double">0.1</update-interval-secs><br />
<type>gain</type><br />
<gain>1.0</gain><br />
<input><br />
<expression><br />
<table><br />
<property>/engines/active-engine/rpm</property><br />
<entry><ind> 0 </ind><dep> 0.82 </dep></entry><br />
<entry><ind> 600 </ind><dep> 0.82 </dep></entry><br />
<entry><ind> 601 </ind><dep> 0.127 </dep></entry><br />
<entry><ind> 1500 </ind><dep> -0.29 </dep></entry><br />
</table>0<br />
</expression><br />
</input><br />
<output><br />
<property>/environment/aircraft-effects/splash-zr</property><br />
</output><br />
</filter><br />
<filter><br />
<name>splash-x</name><br />
<update-interval-secs type="double">0.1</update-interval-secs><br />
<type>gain</type><br />
<gain>1.0</gain><br />
<input><br />
<condition><br />
<greater-than-equals><br />
<property>/velocities/airspeed-kt</property><br />
<value>5</value><br />
</greater-than-equals><br />
</condition><br />
<property>/environment/aircraft-effects/splash-xa</property><br />
</input><br />
<input><br />
<condition><br />
<less-than><br />
<property>/velocities/airspeed-kt</property><br />
<value>5</value><br />
</less-than><br />
</condition><br />
<property>/environment/aircraft-effects/splash-xr</property><br />
</input><br />
<output><br />
<property>/environment/aircraft-effects/splash-vector-x</property><br />
</output><br />
</filter><br />
<filter><br />
<name>splash-y</name><br />
<update-interval-secs type="double">0.1</update-interval-secs><br />
<type>gain</type><br />
<gain>1.0</gain><br />
<input><br />
<value>0.0</value><br />
</input><br />
<output><br />
<property>/environment/aircraft-effects/splash-vector-y</property><br />
</output><br />
</filter><br />
<filter><br />
<name>splash-z</name><br />
<update-interval-secs type="double">0.1</update-interval-secs><br />
<type>gain</type><br />
<gain>1.0</gain><br />
<input><br />
<condition><br />
<greater-than-equals><br />
<property>/velocities/airspeed-kt</property><br />
<value>5</value><br />
</greater-than-equals><br />
</condition><br />
<property>/environment/aircraft-effects/splash-za</property><br />
</input><br />
<input><br />
<condition><br />
<less-than><br />
<property>/velocities/airspeed-kt</property><br />
<value>5</value><br />
</less-than><br />
</condition><br />
<property>/environment/aircraft-effects/splash-zr</property><br />
</input><br />
<output><br />
<property>/environment/aircraft-effects/splash-vector-z</property><br />
</output><br />
</filter><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
=== Frost and fogging ===<br />
<br />
Frost on the canopy is rendered when environment/aircraft-effects/frost-level is set in the range from 0 to 1. Again, it is up to the aircraft developer to decide at what exterior conditions frosting should happen and whether the aircraft is equipped with heating to remove the frost again.<br />
<br />
Fogging is controlled by environment/aircraft-effects/fog-level in the range 0 to 1. Unless a mask is used, fogging is homogeneous across the whole surface (it is really intended to be used with a mask).<br />
<br />
=== Tint ===<br />
<br />
Tinted glass can be easily created by changing <br />
<br />
<syntaxhighlight lang="xml"><br />
<glass-tint type="vec4d" n="0"> 1.0 1.0 1.0 1.0</glass-tint><br />
</syntaxhighlight><br />
<br />
to any value desired. This will affect all effects assumed outside of the glass layer (frost and rain splashes) but not fogging inside the glass. Use primarily for development and quick tests, don't misuse the alpha value available here, it has odd side effects.<br />
<br />
=== Functional masks ===<br />
<br />
If the glass surface is uv-mapped and textured, it is possible to switch on a mask functionality in the inheritance via<br />
<br />
<syntaxhighlight lang="xml"><br />
<texture n="2"><br />
<image>my_mask.png</image><br />
<type>2d</type><br />
<filter>linear-mipmap-linear</filter><br />
<wrap-s>clamp</wrap-s><br />
<wrap-t>clamp</wrap-t><br />
<internal-format>normalized</internal-format><br />
</texture><br />
<use-mask type="int">1</use-mask><br />
<overlay-color type="vec3d" n="0">1.0 1.0 1.0</overlay-color><br />
</syntaxhighlight><br />
<br />
The red channel in my_mask.png controls the strength of fogging, full red corresponds to maximal fogging, no red to zero fogging. This allows to selectively model the position of heaters in the cockpit. Use <b>/environment/aircraft-effects/fog-level</b> to adjust the actual amount of fog runtime.<br />
<br />
The green channel of my_mask.png is the amount of reduction of rain in an area. This is intended for airplanes equipped with windshield wipers to partially clear the wiped area of the rain. Whether the windshield wiper is actually on or not is controlled runtime via <b>/environent/aircraft-effects/use-wipers</b> (1 sets wipers to on).<br />
<br />
The blue channel of my_mask.png is reserved for an overlay pattern which will be drawn in an optionally specified <overlay-color> vector (white in the example xml above) - the primary function is to render damage on the glass, but with a different color, also dirt or an alternative more finely controlled frost pattern can be used. The strength of the pattern can be adjusted runtime via <b>/environment/aircraft-effects/overlay-alpha</b>, allowing dynamical accumulation of dirt or sudden appearance of damage.<br />
<br />
Examples for the result of a fog mask and a damage mask are shown below:<br />
<br />
[[File:Glass12.jpg|400px|Crack pattern using a damage mask]]<br />
[[File:Glass11.jpg|400px|Partial fogging using a mask texture]]<br />
<br />
<b>Note that by default all the runtime switches for the mask are off / set to zero! Remember to to switch them on when testing the effect!</b><br />
<br />
=== Mie scattering ===<br />
<br />
Most glass effects show prominent Mie forward scattering as in reality, i.e. frost patterns or fogging will appear much more prominent when looking almost towards the sun than under any other angle. While the frost pattern is normally not very prominent and one is able to look through unhindered, this changes substantially when looking into the sun, at which point it almost obscures the view.<br />
<br />
[[File:Glass08.jpg|400px|Mie scattering of low light on frost]]<br />
[[File:Glass13.jpg|400px|Morning sun Mie scattering on fog]]<br />
<br />
For frost and fog, the strength of the effect is set automatically, but for the damage/dirt layer it is under user control at effect design time. Changing the parameter<br />
<br />
<syntaxhighlight lang="xml"><br />
<overlay-glare type="float">0.5</overlay-glare><br />
</syntaxhighlight><br />
<br />
from its default value allows to adjust the strength of the glare when looking through the overlay layer close to the sun.<br />
<br />
=== Internal cockpit reflection ===<br />
<br />
There is support for a reflection of the cockpit interior.<br />
<br />
[[File:Reflect.jpg|640px|Internal glass cube map reflection]]<br />
<br />
<br />
This needs to be provided as a cubemap specific for the airplane and switched on via the flag <use-reflection> set to 1. The relative strength of the reflection can be optionally via <reflection-strength>. The strength of the reflection in the cockpit is dynamically adjusted for a number of factors, among them balance of direct to indirect light, the approximate amount of light falling on the surface seen in the reflection and the amount of direct sunlight falling into the eye.<br />
<br />
If the six cubemap faces are called my_cube_map_??.png, then using an effect file called c172p-reflect.eff the inheritance looks like this:<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<PropertyList><br />
<name>c172-reflect</name><br />
<inherits-from>Effects/glass</inherits-from><br />
<parameters><br />
<texture n="3"><br />
<type>cubemap</type><br />
<images><br />
<positive-x>my_cube_map_px.png</positive-x><br />
<negative-x>my_cube_map_nx.png</negative-x><br />
<positive-y>my_cube_map_py.png</positive-y><br />
<negative-y>my_cube_map_ny.png</negative-y><br />
<positive-z>my_cube_map_pz.png</positive-z><br />
<negative-z>my_cube_map_nz.png</negative-z><br />
</images><br />
</texture><br />
<use-reflection type="int">1</use-reflection><br />
<reflection-strength type="float">1.0</reflection-strength><br />
</parameters><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
The inheritance call includes all surface objects that use the effect.<br />
<br />
<syntaxhighlight lang="xml"><br />
<effect><br />
<inherits-from>Aircraft/c172p/Models/Effects/c172p-reflect</inherits-from><br />
<object-name>glas</object-name><br />
<object-name>rightwindow</object-name><br />
<object-name>leftwindow</object-name><br />
</effect><br />
</syntaxhighlight><br />
<br />
<br />
See below (Interior shading), for details on cube_map creation and orientation.<br />
<br />
=== Lightmaps for internal cockpit reflection ===<br />
<br />
If the cockpit is illuminated at night, the reflection map will not show this change by default. However,the glass effect supports a lightmap for the reflection, which can be used in parallel with the lightmap for the panels to show the reflection of a lit panel at night.<br />
<br />
Since the reflection map is a cube map, the lightmap for it has to be as well, the syntax is hence<br />
<br />
<syntaxhighlight lang="xml"><br />
<use-reflection-lightmap type="int">1</use-reflection-lightmap><br />
<texture n="4"><br />
<type>cubemap</type><br />
<images><br />
<positive-x>Models/Effects/interior/reflection/light-px.png</positive-x> <br />
<negative-x>Models/Effects/interior/reflection/light-nx.png</negative-x> <br />
<positive-y>Models/Effects/interior/reflection/light-py.png</positive-y> <br />
<negative-y>Models/Effects/interior/reflection/light-ny.png</negative-y> <br />
<positive-z>Models/Effects/interior/reflection/light-pz.png</positive-z> <br />
<negative-z>Models/Effects/interior/reflection/light-nz.png</negative-z> <br />
</images><br />
</texture><br />
</syntaxhighlight><br />
<br />
The control parameters of the lightmap otherwise parallel those of the [[Model-combined_effect]] or the model interior effect described below, i.e. up to four channels can be independently specified on the lightmap.<br />
<br />
=== Troubleshooting ===<br />
<br />
By default, rain and frost are mapped to the shape of the canopy using coordinate systems that adapts to the splash vector and the canopy shape. This requires no particular action aircraft-side except to provide the bare geometry of a canopy/windshield, but may not be satisfactory in all instances - in particular for near vertical cockpit side windows the scheme does poorly.<br />
<br />
There are two alternative coordinate maps available in this case, controlled by the parameter<br />
<br />
<syntaxhighlight lang="xml"><br />
<surface-mapping-scheme type="int">0</surface-mapping-scheme><br />
</syntaxhighlight><br />
<br />
If the parameter is changed to 1, the uv-mapping of the surface is used (it has to exist of course). For this to work properly, the uv-mapping needs to be sufficiently regular and roughly preserve the mapped area.<br />
<br />
If the parameter is changed to 2, a local orthonormal system based on the normals of the surface is constructed. This no longer takes the splash vector consistently into account and works poorly for surfaces which are flat in the (xy)-plane, but gives decent result for side windows.<br />
<br />
== The HUD effect ==<br />
<br />
The HUD effect is a variant of the glass effect designed to render the visuals of a head-up display (HUD) closer to real life. This only works if the HUD is custom-created via [[Canvas]], not via the native FG HUD mechanism as the latter by-passes the effect framework.<br />
<br />
The effect takes the same configuration options as the glass effect (i.e. it can render frost, damage, scratches, glare,...) but in addition it runs a blur over the HUD image and alters the color distribution of the projected symbols to de-saturate the bright parts in the center. The result looks less monochromatic and more like light projected onto a surface (left: bare canvas right: HUD effect)<br />
<br />
[[File:HUD effect.jpg|800px|Comparison between a bare canvas HUD (left) and the ALS HUD shader run over it (right)]]<br />
<br />
<br />
=== Usage ===<br />
<br />
The effect is used from the model file by assigning it to the surface that also carries the canvas texture of the HUD via<br />
<br />
<syntaxhighlight lang="xml"><br />
<effect><br />
<inherits-from>Effects/hud</inherits-from><br />
<object-name>HUDImage</object-name><br />
</effect><br />
</syntaxhighlight><br />
<br />
This should usually work out of the box, but if the HUD brightness should be changeable or the glass properties adjusted, a derived effect needs to be created.<br />
<br />
=== Parameters ===<br />
<br />
In addition to the parameters supported by the glass shader (which, for instance in the case of rain splashes, may or may not be appropriate for a HUD, this is left at user's discretion), the HUD effect takes the following special parameters:<br />
<br />
<syntaxhighlight lang="xml"><br />
<brightness>1.0</brightness><br />
<sample-res>0.0006</sample-res><br />
<sample-far>2.5</sample-far><br />
</syntaxhighlight><br />
<br />
The first one is the relative brightness setting of the HUD (which should equal the alpha value assigned to the canvas image of the symbols). This parameter is used to de-saturate colors in the symbol centers.<br />
<br />
Remaining two parameters represent the size and shape of the blur Kernel being used. The sample resolution (sample-res) determines the overall size of the blur region, the farthest sample (sample-far) how far out the tails of the blur region extend.<br />
<br />
Note: The number of sampling steps is not computed adaptive to these parameters, if the steps get too coarse, then multiple image echoes instead of a proper blur will be generated - adjust these parameters with care (if at all).<br />
<br />
== The ALS interior model effect ==<br />
<br />
Since the interior of a cockpit is a large part of what a pilot gets to see in-flight, but this interior represents a rather special situation (light is reduced as it falls through windows, it may have artificial light, there is never any fog or haze,...) ALS offers a separate effect to specifically render the interior of a plane.<br />
<br />
This effect also includes optional features which will be available at higher quality settings of the model shader.<br />
<br />
=== Interior shadows and tinted glass effect ===<br />
<br />
With FlightGear version 3.5 and above, ALS now supports interior shading; i.e. the sun shining through the windows and casting shadows on the panel.<br />
<br />
[[File:interior01.jpg|640px|Interior shading effect]]<br />
<br />
This effect is based on an opacity map - a cube map of textures which tells the renderer where the cockpit is transparent and where not. The opacity map has to be created beforehand, which allows to make it quite detailed. In this map, white stands for a completely transparent surface, black for an opaque surface, colors for tinted glass which will create a colored light spot in the cockpit, grey hues for partial shadowing allowing to paint dirt effects onto the windows, and caustics can be drawn using the alpha channel: (1-alpha) will be used as an enhancement of the light at a certain spot.<br />
<br />
The effect is typically declared as derived by inheritance using an effect file such as c172-interior.eff which looks like this<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf-8"?><br />
<br />
<PropertyList><br />
<name>c172-interior-glass</name><br />
<inherits-from>Effects/model-interior</inherits-from><br />
<parameters><br />
<texture n="4"><br />
<type>cubemap</type><br />
<images><br />
<positive-x>Models/Effects/interior/clr_px.png</positive-x><br />
<negative-x>Models/Effects/interior/clr_nx.png</negative-x><br />
<positive-y>Models/Effects/interior/clr_py.png</positive-y><br />
<negative-y>Models/Effects/interior/clr_ny.png</negative-y><br />
<positive-z>Models/Effects/interior/clr_pz.png</positive-z><br />
<negative-z>Models/Effects/interior/clr_nz.png</negative-z><br />
</images><br />
</texture><br />
<opacity-cube-center type="vec3d" n="0"> 0.5 0.0 0.3</opacity-cube-center><br />
<opacity-cube-scale type="vec3d" n="0"> 1.5 0.5 0.7</opacity-cube-scale><br />
<opacity-cube-angle type="float">0.0</opacity-cube-angle><br />
</parameters><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
which is called by inheritance in the model.xml file.<br />
<br />
Imagine the opacity map as a box surrounding the cockpit and trying to closely follow its contours. The origin in the box needs to be placed into the center of the cockpit, which is what <b><opacity-cube-center></b> does. Each of the three dimensions then needs to be stretched to roughly fit the layout of the canopy, this is done by <b><opacity-cube-scale></b>. <br />
<br />
If opacity map center and scale are wrong, you will still see shadows, but they won't match the real cockpit layout (the lightspot of a window will be seen displaced and at a different size of the real window). Thus, carefully measuring the best box layout in a 3d tool is moderately important.<br />
<br />
<br />
<br />
Aircraft-side the effect is called as<br />
<br />
<syntaxhighlight lang="xml"><br />
<effect><br />
<inherits-from>Aircraft/c172p/Models/Effects/c172p-interior</inherits-from><br />
<object-name>Plane.010_0</object-name><br />
<object-name>Plane.010_1</object-name><br />
<object-name>PilotSeat</object-name><br />
<object-name>CopilotSeat</object-name><br />
<object-name>panel_1_1</object-name><br />
<object-name>InstrumentCover.001</object-name><br />
<object-name>doorint_right</object-name><br />
<object-name>doorint_left</object-name><br />
<object-name>doorhandleint_right</object-name><br />
<object-name>doorhandleint_left</object-name><br />
<object-name>Panel_0</object-name><br />
<object-name>Throttle</object-name><br />
<object-name>Mixture</object-name><br />
<object-name>Pedestal</object-name><br />
<object-name>TrimWheel</object-name><br />
<object-name>ParkingBrake</object-name><br />
<object-name>BackSeat</object-name><br />
<object-name>FuelSelectorFace</object-name><br />
</effect><br />
</syntaxhighlight><br />
<br />
Each object that you want the shadow effect to fall on must be included in the inheritance.<br />
<br />
Unless you supply a path, the cube_.png's need to reside in the same directory as the model.xml where you added the <effect> tag pair that calls c172-interior.eff, not where you put the aircraft_interior.eff.<br />
<br />
<br />
The orientation of the faces of each cube have to be adjusted based on the positive and negative axis of the model.<br />
<br />
For example, using the c172p model as a reference.<br />
<br />
The tail, right wing and top on the model are positive inside Blender. So the cube faces are laid out as follows.<br />
<br />
Note: Depending on the image's orientation when photographed the rotation direction will vary. This is assuming the images are being taken from the center of the cockpit looking out. Using compass headings to describe how to rotate the images.<br />
<br />
px (tail) rotate 90 deg from N or S to W<br />
<br />
nx (nose) rotate 90 deg from N or S to E<br />
<br />
py (starboard/right) from N do not rotate<br />
<br />
ny (port/left) from N rotate 180 deg to S<br />
<br />
pz (top) rotate 90 deg from N or S to W<br />
<br />
nz (bottom) rotate 90 deg from N or S to W<br />
<br />
[[File:C172p-cube.jpg|640px|Cube map layout of the c172p]]<br />
<br />
<br />
With Blender, it's pretty easy to create the cubemap.<br />
<br />
1. Add a camera where the cubemap will be. Set the FOV to 90 degrees.<br />
2. Set the resolution to 1024x1024 (or any other square, power-of-two size).<br />
3. Hide all lights and windows; disable ambient lighting (set it to black) and turn off ambient occlusion.<br />
4. Set the world color to white.<br />
5. Enable the compositor and add an invert node.<br />
6. Render and save the six views as you would normally.<br />
7. Add dirt, tinted glass color and caustics by hand<br />
<br />
This process depends on the model setup but it should work for most aircraft with a few tweaks.<br />
<br />
==== Cubemap Kit for Blender ====<br />
<br />
[[File:Als-interior-shadow-blender-instructions.png|320px|How to make an interior cubemap with the cubemap kit]]<br />
<br />
See [http://chateau-logic.com/content/flightgear-interior-shadow-cubemap-kit flightgear-interior-shadow-cubemap-kit] for a premade kit to create the cubemap and the .eff sample file to use it.<br />
<br />
==== Important Notes ====<br />
<br />
<b>Important note:</b> Currently (May 2015) the effect does not deal gracefully with child models included into the main model with offsets and/or rotations because these introduce a different coordinate system in which the shadow does not match. The general idea of a code solution is known, but not implemented. Right now this can only be addressed by explicitly positioning child models in the *.ac file and not using any offsets when including them.<br />
<br />
=== ALS flashlight ===<br />
<br />
This effect is meant to imitate a hand held flashlight for use in getting instruments in the cockpit turned on in dark conditions.<br />
It is almost identical in nature to ALS searchlight only it is applied using interior-model.eff.<br />
It has two user defined light color filters that can be applied and also a user defined light radius setting.<br />
<br />
[[File:ALS flashlight.jpg|600px|ALS flashlight effect]]<br />
<br />
To implement this effect use<br />
<syntaxhighlight lang="xml"><inherits-from>Effects/model-interior</inherits-from></syntaxhighlight><br />
A full definition looks like this<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf-8"?><br />
<PropertyList><br />
<name>c172-interior</name><br />
<inherits-from>Effects/model-interior</inherits-from><br />
<parameters><br />
<light-filter-one type="vec3d">0.5 0.5 0.5</light-filter-one><br />
<light-filter-two type="vec3d">0.9 0.2 0.2</light-filter-two><br />
<light-radius type="float">13</light-radius><br />
</parameters><br />
</PropertyList><br />
</syntaxhighlight><br />
In the example above light-filter-one is soft white light and light-filter-two is a soft red light.<br />
<br />
After defining as above you can turn it on using the following property<br />
<br />
/sim/rendering/als-secondary-lights/use-flashlight = 1 is light-filter-one<br />
<br />
/sim/rendering/als-secondary-lights/use-flashlight = 2 is light-filter-two<br />
<br />
'''Special note:'''<br />
The flashlight effect inherits model-interior, model-interior.eff is setup around the opacity cube map, it won't allow you to go without one, and in the event you try, you get an environment reflection cube map as default which happens to have green grass on it and may cast a greenish hue over applied objects.<br />
A workaround is to create a pseudo cubemap by creating a white.png 64x64 square, and creating the following structure to represent a transparent cubemap.<br />
<br />
<syntaxhighlight lang="xml"><br />
<texture n="4"><br />
<type>cubemap</type><br />
<images><br />
<positive-x>Aircraft/c172p/Models/Effects/interior/white.png</positive-x><br />
<negative-x>Aircraft/c172p/Models/Effects/interior/white.png</negative-x><br />
<positive-y>Aircraft/c172p/Models/Effects/interior/white.png</positive-y><br />
<negative-y>Aircraft/c172p/Models/Effects/interior/white.png</negative-y><br />
<positive-z>Aircraft/c172p/Models/Effects/interior/white.png</positive-z><br />
<negative-z>Aircraft/c172p/Models/Effects/interior/white.png</negative-z><br />
</images><br />
</texture><br />
</syntaxhighlight><br />
<br />
=== Implicit lightmap ===<br />
<br />
At lowest quality level, the effect supports an implicit lightmap, i.e. a color range of the basic texture can be selected and declared to act as a lightmap. This is specifically useful to render panel backlighting as in the example below:<br />
<br />
[[File:Ilightmap.jpg|600px|An implicit lightmap used to simulate a backlit panel]]<br />
<br />
The effect is off by default and switched on by setting<br />
<br />
<syntaxhighlight lang="xml"><br />
<implicit-lightmap-enabled type="int">1</implicit-lightmap-enabled><br />
</syntaxhighlight><br />
<br />
The following parameters are available:<br />
<br />
<syntaxhighlight lang="xml"><br />
<implicit-lightmap-tag-color type="vec3d">1.0 1.0 1.0</implicit-lightmap-tag-color><br />
</syntaxhighlight><br />
<br />
This sets the base color to be tagged, i.e. if the panel labels to be illuminated at night are white, the color needs to be set to white.<br />
<br />
<syntaxhighlight lang="xml"><br />
<implicit-lightmap-threshold-low type="float">0.5</implicit-lightmap-threshold-low><br />
<implicit-lightmap-threshold-high type="float">1.5</implicit-lightmap-threshold-high><br />
</syntaxhighlight><br />
<br />
The thresholds determine how similar a color may be to the base color in order to be still illuminated. The measure is the Euklidean distance of the color vectors. The lower thresholds determines when illumination will start to fade, the higher threshold at what distance in color space illumination will no longer take place. The thresholds have to be adapted to the specific situation - the technique works best for high-contrast panels (white labels on black background) and may not work at all for low contrast panels.<br />
<br />
<syntaxhighlight lang="xml"><br />
<implicit-lightmap-emit-color type="vec3d">1.0 1.0 1.0</implicit-lightmap-emit-color><br />
</syntaxhighlight><br />
<br />
The emit color specifies at which color the pixel will show if it is tagged (see above) and the implicit lightmap is on (see below) - set this to the color of the backlight.<br />
<br />
<syntaxhighlight lang="xml"><br />
<implicit-lightmap-intensity type="float">0.0</implicit-lightmap-intensity><br />
</syntaxhighlight><br />
<br />
Finally, the intensity determines how brightly the illuminated pixel will shine.<br />
<br />
Ambiance lighting can be simulated with the following tags.<br />
<br />
<syntaxhighlight lang="xml"><br />
<residual-ambience-r type="float"><use>/fdm/jsbsim/systems/light/cockpit-ambience-r</use></residual-ambience-r><br />
<residual-ambience-g type="float"><use>/fdm/jsbsim/systems/light/cockpit-ambience-g</use></residual-ambience-g><br />
<residual-ambience-b type="float"><use>/fdm/jsbsim/systems/light/cockpit-ambience-b</use></residual-ambience-b><br />
</syntaxhighlight><br />
<br />
In the above example note the use of the "use" tag.<br />
<br />
<syntaxhighlight lang="xml"><br />
<use>/fdm/jsbsim/systems/light/cockpit-ambience-r</use><br />
</syntaxhighlight><br />
<br />
This can be any defined property or static value.<br />
<br />
'''Special note:'''<br />
The implicit lightmap inherits model-interior, model-interior.eff is setup around the opacity cube map, it won't allow you to go without one, and in the event you try, you get an environment reflection cube map as default which happens to have green grass on it and may cast a greenish hue over applied objects.<br />
A workaround is to create a pseudo cubemap by creating a white.png 64x64 square, and creating the following structure to represent a transparent cubemap.<br />
<br />
<syntaxhighlight lang="xml"><br />
<texture n="4"><br />
<type>cubemap</type><br />
<images><br />
<positive-x>Aircraft/c172p/Models/Effects/interior/white.png</positive-x><br />
<negative-x>Aircraft/c172p/Models/Effects/interior/white.png</negative-x><br />
<positive-y>Aircraft/c172p/Models/Effects/interior/white.png</positive-y><br />
<negative-y>Aircraft/c172p/Models/Effects/interior/white.png</negative-y><br />
<positive-z>Aircraft/c172p/Models/Effects/interior/white.png</positive-z><br />
<negative-z>Aircraft/c172p/Models/Effects/interior/white.png</negative-z><br />
</images><br />
</texture><br />
</syntaxhighlight><br />
<br />
=== Irradiance maps ===<br />
<br />
<b>Note:</b> This effect requires higher than minimum model shader quality setting.<br />
<br />
In the simplest rendering schemes, diffuse and specular light are assumed to be highly directional (i.e. it illuminates lit surfaces only) while ambient light is taken to be omnidirectional.<br />
<br />
In reality, that is hardly ever true. In a typical outside location, ambient light is mainly coming from the sky above (which is why the ground underneath a car is dark even in the absence of directional light when the sky is overcast and the sun is not visible). In an enclosed space (like a room, or an aircraft cockpit), ambient light has to fall through the windows, i.e. is mainly not coming above but falling in horizontally.<br />
<br />
The directional dependence is not very strong though, yet it leaves measurable effects. In rendering, this can be accounted for by irradiance maps. In the following, the interior of the C-172p is rendered in the first case using omnidirectional ambient light, in the second case using an irradiance map giving the ambient light the directionality of the cabin windows, i.e. the light falls in predominantly horizontally (in addition, a grain map is superimposed to provide structure). Note how the spatial structure of the roof, looking bland when rendered in omnidirectional light is brought out by the irradiance map.<br />
<br />
[[File:Als-interior-irradiance01.jpg|400px|C-172p cabin interior rendered without irradiance and grain map]]<br />
[[File:Als-interior-irradiance02.jpg|400px|C-172p cabin interior rendered with irradiance and grain map]]<br />
<br />
Irradiance mapping is configured by the following parameters:<br />
<br />
<syntaxhighlight lang="xml"><br />
<irradiance-map-type type="int">2</irradiance-map-type><br />
<irradiance-map-strength type="float">0.5</irradiance-map-strength><br />
</syntaxhighlight><br />
<br />
There are several pre-configured irradiance map functions which can be chosen by map type. <br />
<br />
0: (default) omndirectional light<br />
1: light predominantly coming from above (most appropriate for fighter cockpits)<br />
2: light predominantly coming from the horizon (most appropriate for GA aircraft)<br />
<br />
The strength of the irradiance map regulates how pronounced the asymmetry of the map will be. A strength of zero always makes the light omnidirectional, whereas a strength of 1 implies that no light is coming from any direction 90 degree to the main direction (i.e. for the option 2, a strength of 1.0 means that no ambient light will fall in from above or below and that hence horizontal surfaces will appear pitch black unless direct light falls on them)<br />
<br />
'''Special note:'''<br />
The irradiance map inherits model-interior, model-interior.eff is setup around the opacity cube map, it won't allow you to go without one, and in the event you try, you get an environment reflection cube map as default which happens to have green grass on it and may cast a greenish hue over applied objects.<br />
A workaround is to create a pseudo cubemap by creating a white.png 64x64 square, and creating the following structure to represent a transparent cubemap.<br />
<br />
<syntaxhighlight lang="xml"><br />
<texture n="4"><br />
<type>cubemap</type><br />
<images><br />
<positive-x>Aircraft/c172p/Models/Effects/interior/white.png</positive-x><br />
<negative-x>Aircraft/c172p/Models/Effects/interior/white.png</negative-x><br />
<positive-y>Aircraft/c172p/Models/Effects/interior/white.png</positive-y><br />
<negative-y>Aircraft/c172p/Models/Effects/interior/white.png</negative-y><br />
<positive-z>Aircraft/c172p/Models/Effects/interior/white.png</positive-z><br />
<negative-z>Aircraft/c172p/Models/Effects/interior/white.png</negative-z><br />
</images><br />
</texture><br />
</syntaxhighlight>.<br />
<br />
=== Explicit lightmap ===<br />
<br />
<b>Note:</b> This effect requires higher than minimum model shader quality setting.<br />
<br />
In addition to the implicit lightmap, it is also possible to explicitly specify a lightmap. The syntax for this exactly parallels the syntax of the [[Model-combined_effect]] which supplies lightmaps for the exterior.<br />
<br />
For example<br />
<br />
<syntaxhighlight lang="xml"><br />
<texture n="3"><br />
<image>Aircraft/MyAircraft/Effects/my_lightmap.png</image><br />
<type>2d</type><br />
<filter>linear-mipmap-linear</filter><br />
<wrap-s>clamp</wrap-s><br />
<wrap-t>clamp</wrap-t><br />
<internal-format>normalized</internal-format><br />
</texture><br />
<lightmap-enabled type="int">1</lightmap-enabled><br />
<lightmap-multi type="int">0</lightmap-multi><br />
<lightmap-factor type="float" n="0">1.0</lightmap-factor><br />
<lightmap-color type="vec3d" n="0"> 1.0 1.0 1.0 </lightmap-color><br />
</syntaxhighlight><br />
<br />
sets up a single channel lightmap in which pixel color times the lightmap color provides the illumination. Using the multi-channel function, up to four different maps can be specified in which the (rgba) values of a pixel encode where the light falls and the associated lightmap color what color the illumination takes. Each of these maps can be switched on and off or dimmed in intensity independently.<br />
<br />
=== Grain map ===<br />
<br />
<b>Note:</b> This effect requires higher than minimum model shader quality setting.<br />
<br />
The grain map sets a repeating hires overlay texture which can supply a very credible illusion of structure to a surface for cheap. The syntax exactly parallels that of the [[Model-combined_effect]] ALS grain feature described above.<br />
<br />
For instance, the following<br />
<br />
<syntaxhighlight lang="xml"><br />
<texture n="7"><br />
<image>Aircraft/Effects/MyGrainmap.png</image><br />
<type>2d</type><br />
<filter>linear-mipmap-linear</filter><br />
<wrap-s>repeat</wrap-s><br />
<wrap-t>repeat</wrap-t><br />
<internal-format>normalized</internal-format><br />
</texture><br />
<grain-texture-enabled type="int">1</grain-texture-enabled><br />
<grain-magnification type="float">10</grain-magnification><br />
</syntaxhighlight><br />
<br />
sets up a grain overlay with a 10-time higher resolution over the base texture layer.<br />
<br />
== ALS procedural lights ==<br />
<br />
The ALS framework supports procedurally generated lights (for instance aircraft position lights, strobe lights,... ) for aircraft and models. Note that the effect produces the visuals of the lights themselves, but they do not illuminate their surroundings.<br />
<br />
=== Why procedural lights? ===<br />
<br />
Traditionally aircraft position lights have been implemented as billboarded emissive textures. This technique is limited in scope, as it has difficulty producing a directional light or changes in the light appearance (for instance glare) with changed scene lighting. The ALS procedural lights are designed to give visuals consistent with the auto-generated scene lights (runway lighting, street lights) and support configurable directionality, glare and even the illumination of fog by the lights.<br />
<br />
<br />
=== Basic implementation ===<br />
<br />
The base of the light is a texture quad which has Effects/procedural-light.eff assigned. Start from including the template provided into your model as<br />
<br />
<syntaxhighlight lang="xml"><br />
<model><br />
<path>/Models/Effects/procedural_light.xml</path><br />
<offsets><br />
<x-m> 0 </x-m><br />
<y-m> 0 </y-m><br />
<z-m> 2 </z-m><br />
</offsets><br />
</model><br />
</syntaxhighlight><br />
<br />
and configure from there according to your own needs.<br />
<br />
<b>Do not billboard the light via animation!</b> The GLSL code will take care of the billboarding. Use a scale animation to change the size of the light, do not change the quad (the *.ac) itself in size, the shader code requires its geometry to be fixed.<br />
<br />
The lights are currently not supported in the default or Rembrandt renderer and will simply be invisible in these frameworks.<br />
<br />
=== Configuring the light ===<br />
<br />
Make your own derived effect inheriting from Effects/procedural-light.eff and assign it in the xml wrapper of the light.<br />
<br />
* the base light color can be set via<br />
<br />
<syntaxhighlight lang="xml"><br />
<light_color_base_r type="float">1.0</light_color_base_r><br />
<light_color_base_g type="float">0.0</light_color_base_g><br />
<light_color_base_b type="float">0.0</light_color_base_b><br />
</syntaxhighlight><br />
<br />
These take the normal set of values ranging from 0 to 1. <br />
<br />
* how the light appears at full intensity in the center can be set via<br />
<br />
<syntaxhighlight lang="xml"><br />
<light_color_center_r type="float">1.0</light_color_center_r><br />
<light_color_center_g type="float">1.0</light_color_center_g><br />
<light_color_center_b type="float">1.0</light_color_center_b><br />
</syntaxhighlight><br />
<br />
The idea behind this is that lights give a better visual appearance if their center is rendered visually brighter and de-saturated, but this occurs only if the light is at full intensity.<br />
<br />
There are no sanity checks done, you can assign any center color you like even if this makes no sense - you can change center color or darken it, so use with care.<br />
<br />
* to runtime change the light intensity, assign<br />
<br />
<syntaxhighlight lang="xml"><br />
<intensity_scale type="float">1.0</intensity_scale><br />
</syntaxhighlight><br />
<br />
to a property and change that property in the range from 0 to 1.<br />
<br />
<br />
<br />
* for directional lights, you need to assign a pointing vector in aircraft coordinates into which the light cone points and set the directionality flag to true to activate the computations. This is done via:<br />
<br />
<syntaxhighlight lang="xml"> <br />
<pointing_x type="float">-1.0</pointing_x><br />
<pointing_y type="float">0.0</pointing_y><br />
<pointing_z type="float">0.0</pointing_z><br />
<is_directional type="bool">true</is_directional><br />
</syntaxhighlight><br />
<br />
It would be customary to pass a normalized vector, but if you don't know how to do it, the shader will do it for you. By assigning properties to the pointing coordinates, the light direction can be changed runtime.<br />
<br />
<b>Do not use a rotation animation to change the light direction - it won't work.</b> Make the pointing vector properties and change them to your needs.<br />
<br />
* fading of a directional light away from the pointing axis is controlled by passing angles (or rather sines of angles).<br />
<br />
<syntaxhighlight lang="xml"> <br />
<inner_angle type="float">0.2</inner_angle><br />
<outer_angle type="float">0.4</outer_angle><br />
<zero_angle type="float">0.7</zero_angle><br />
<outer_gain type="float">0.5</outer_gain><br />
</syntaxhighlight><br />
<br />
Up to inner_angle, the light will have full intensity. From inner to outer angle the light will linearly fade to outer_gain. From outer angle to zero angle, the light intensity will linearly fade to zero.<br />
<br />
* to get an automatic strobe effect you can set<br />
<br />
<syntaxhighlight lang="xml"> <br />
<is_strobe type="bool">true</is_strobe><br />
</syntaxhighlight><br />
<br />
to true. If you want your own strobe pattern, generate a strobe function and use <b>intensity_scale</b> instead to pass it to the shader.<br />
<br />
<br />
=== Complete example ===<br />
<br />
Here's the left nav light of the C-172p:<br />
<br />
<syntaxhighlight lang="xml"> <br />
<?xml version="1.0" encoding="utf-8"?><br />
<PropertyList><br />
<br />
<name>procedural-light-nav-left</name><br />
<inherits-from>Effects/procedural-light</inherits-from><br />
<br />
<parameters><br />
<light_color_base_r type="float">1.000</light_color_base_r><br />
<light_color_base_g type="float">0.320</light_color_base_g><br />
<light_color_base_b type="float">0.320</light_color_base_b><br />
<light_color_center_r type="float">1.0</light_color_center_r><br />
<light_color_center_g type="float">1.0</light_color_center_g><br />
<light_color_center_b type="float">1.0</light_color_center_b><br />
<intensity_scale type="float">1.0</intensity_scale><br />
<br />
<!-- Arc is 110 deg, is 55 deg per side, giving 35 deg from wing --><br />
<pointing_x type="float">1.0</pointing_x><br />
<pointing_y type="float">0.7002075382097097</pointing_y><br />
<pointing_z type="float">0.0</pointing_z><br />
<br />
<is_directional type="bool">true</is_directional><br />
<is_strobe type="bool">false</is_strobe><br />
<br />
<!-- Angles are 0.0 at 0 deg from pointing direction, 1.0 at<br />
90/-90 deg, and 0.0 at 180/-180 deg.<br />
<br />
For left navigation light we use -0/-35 .. +110/+145 for<br />
the inner/outer range. This gives an arc of 110/180 deg,<br />
or 55/90 deg from center.<br />
<br />
Value = sin(angle in degrees)<br />
<br />
0.8191520442889918 = 55 deg (* 2 = 110 deg inner angle)<br />
1.0000 = 90 deg (* 2 = 180 deg outer angle)<br />
--><br />
<inner_angle type="float">0.8191520442889918</inner_angle><br />
<outer_angle type="float">1.0</outer_angle><br />
<zero_angle type="float">0.982547593563</zero_angle><br />
<outer_gain type="float">0.1</outer_gain><br />
</parameters><br />
<br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
=== Examples ===<br />
The Cessna 182 by Heiko Schulz and Gilberto Agostinho with procedural lights activated:<br><br />
:''(To percieve the effect well, you probably have to darken your room and switch to fullscreen)''<br />
[[File:Cessna 182 with procedural lights.jpg|800px]]<br />
<br />
== ALS fuselage shadow effect ==<br />
ALS supports the manipulation of a (simplified) ground shadow. This effect uses an existing simplified shadow animation configuration and by default uses the gear-agl-m property to calculate the ground placement of that simplified shadow.<br />
<br />
The system, techniques for using it, and several working examples are on [https://forum.flightgear.org/viewtopic.php?f=47&t=24859&start=135 this extensive forum thread about the ALS shadow effects].<br />
<br />
[[File:Alsshadow.jpg|800px|ALS Shadow]]<br />
<br />
The effect can be applied easily in any aircraft that report the gear-agl-m property by simply adding a declaration inheriting from shadow.eff.<br />
<br />
If the aircraft does not support the gear-agl-m property, (notably JSBSim), you need to create a [[Autopilot configuration reference | Property Rule]] to pass a supported AGL data to the gear-agl-m property. In this case we use altitude-agl-ft converted to meters using a property rule configuration file.<br />
<br />
For the first example we'll use the "supported gear-agl-m" method for aircraft that don't require a property rule.<br />
<br />
Simply add the following inheritance declaration after you declare your shadow animation statement.<br />
<syntaxhighlight lang="xml"><br />
<effect><br />
<inherits-from>Effects/shadow</inherits-from><br />
<object-name>name_of_the_shadow_object</object-name><br />
</effect><br />
</syntaxhighlight><br />
In the non-ALS simplified shadow code you normally use a "translate" animation to position the shadow on the ground.<br />
When using the ALS method you must either remove, comment out, or apply a condition to restrict its use to non ALS shadow applications, because ALS is responsible for computing the shadows ground position.<br />
<br />
Here is how we apply a condition to the translation to limit it effect to non-ALS application only.<br />
<syntaxhighlight lang="xml"><br />
<!--Translate to ground level --><br />
<animation><br />
<type>translate</type><br />
<object-name>shadow</object-name><br />
<condition><br />
<not><br />
<property>/sim/rendering/shaders/skydome</property><br />
</not><br />
</condition><br />
<property>/position/altitude-agl-ft</property><br />
<factor>-0.3048</factor><br />
<center><br />
<x-m>0</x-m><br />
<y-m>0</y-m><br />
<z-m>0</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>0</y><br />
<z>1</z><br />
</axis><br />
</animation><br />
</syntaxhighlight><br />
<br />
A complete shadow animation block looks like this.<br />
<syntaxhighlight lang="xml"><br />
<PropertyList><br />
<br />
<animation><br />
<!-- opaque objects --><br />
<!-- transparent objects --><br />
<object-name>shadow</object-name><br />
<type>select</type><br />
<condition><br />
<not><br />
<property>/sim/rendering/rembrandt/enabled</property><br />
</not><br />
</condition><br />
</animation><br />
<br />
<effect><br />
<inherits-from>Effects/shadow</inherits-from><br />
<object-name>shadow</object-name><br />
</effect><br />
<br />
<animation><br />
<type>noshadow</type><br />
<object-name>shadow</object-name><br />
</animation><br />
<br />
<!-- pitch --><br />
<animation><br />
<type>rotate</type><br />
<object-name>shadow</object-name><br />
<property>/orientation/pitch-deg</property><br />
<factor>-1.0</factor><br />
<center><br />
<x-m>0</x-m><br />
<y-m>0</y-m><br />
<z-m>0</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
<br />
<!-- roll --><br />
<animation><br />
<type>rotate</type><br />
<object-name>shadow</object-name><br />
<property>/orientation/roll-deg</property><br />
<factor>1.0</factor><br />
<center><br />
<x-m>0</x-m><br />
<y-m>0</y-m><br />
<z-m>0</z-m><br />
</center><br />
<axis><br />
<x>1</x><br />
<y>0</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
<br />
<!--Translate to ground level --><br />
<animation><br />
<type>translate</type><br />
<object-name>shadow</object-name><br />
<condition><br />
<not><br />
<property>/sim/rendering/shaders/skydome</property><br />
</not><br />
</condition><br />
<property>/position/altitude-agl-ft</property><br />
<factor>-0.3048</factor><br />
<center><br />
<x-m>0</x-m><br />
<y-m>0</y-m><br />
<z-m>0</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>0</y><br />
<z>1</z><br />
</axis><br />
</animation><br />
<br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
For aircraft requiring a [[Autopilot configuration reference | Property Rule]] there are a couple extra steps.<br />
<br />
In aircraft-set.xml you add the property rule call to the "configuration file" in between the PropertyList/sim/systems tag pairs.<br />
<syntaxhighlight lang="xml"> <br />
<property-rule n="101"><br />
<name>gear_agl-m</name><br />
<path>Aircraft/c172p/Systems/gearAGL.xml</path><br />
</property-rule><br />
</syntaxhighlight><br />
Note: the n="101" needs to be =+100 as -100 is reserved for system wide property rules.<br />
In the above example 101 was used because 100 was already being used by a previous property rule definition.<br />
<br />
The "configuration file" normally goes in /Systems.<br />
In this example we named the configuration file /Systems/gearAGL.xml.<br />
<br />
Here is the complete /Systems/gearAGL.xml configuration file.<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<br />
<PropertyList><br />
<filter><br />
<type>gain</type><br />
<gain>0.3048</gain><br />
<input>/position/altitude-agl-ft</input><br />
<reference>6</reference><br />
<output>/position/gear-agl-m</output><br />
</filter><br />
</PropertyList><br />
</syntaxhighlight><br />
What the configuration file does is convert the input of altitude-agl-ft to the output of (((altitude-agl-ft)-6)*0.3048) or (convert ft-6 to m) and pass it to /position/gear-agl-m.<br />
<br />
See [[Autopilot configuration reference | Input and reference properties or values <input> and <reference>]].<br />
<br />
== ALS 3d shadow volume effect ==<br />
What might be considered the next level of realism using a relatively "cheap" shadow effect is to use a 3d volume shadow.<br />
<br />
[[File:Shadow vol02.jpg|800px|ALS 3d Shadow Volume]]<br />
<br />
The procedure to implement the ALS shadow volume is similar to the ALS-shadow above with a few modifications.<br />
<br />
First you have to have a 3d shadow volume model of the aircraft you are applying the effect to. This model should be a low poly model that is optimized to be as little of a footprint as possible.<br />
<br />
A property rule is required, same as above. This is used to generate the above ground altitude in meters, (altitude-agl-m). The "altitude-agl-m" is used to place the shadow close to the ground in real time at an FDM rate of execution.<br />
{{note|Do not confuse "altitude-agl-m" with the other type of non-3d ALS-shadow property of "gear-agl-m". The shaders involved use these two different properties respectively for the two different effect. They are not interchangeable.}}<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<PropertyList><br />
<filter><br />
<type>gain</type><br />
<gain>0.3048</gain><br />
<input>/position/altitude-agl-ft</input><br />
<reference>1.0</reference><br />
<output>/position/altitude-agl-m</output><br />
</filter><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
The other difference from the ALS-shadow above is that it uses a different inherited effect.<br />
Instead of<br />
<syntaxhighlight lang="xml"><br />
<effect><br />
<inherits-from>Effects/shadow</inherits-from><br />
<object-name>shadow</object-name><br />
</effect><br />
</syntaxhighlight><br />
you use<br />
<syntaxhighlight lang="xml"><br />
<effect><br />
<inherits-from>Effects/shadow-vol</inherits-from><br />
<object-name>shadow</object-name><br />
</effect><br />
</syntaxhighlight><br />
<br />
<br />
== Related content ==<br />
<br />
* [[Procedural Texturing]]<br />
* [[Atmospheric light scattering]]<br />
* [[ALS infrared vision]]<br />
<br />
[[Category:Shader development]]<br />
[[Category:ALS]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Howto:Shader_programming_in_FlightGear&diff=107430Howto:Shader programming in FlightGear2017-03-19T04:46:01Z<p>Flug: /* Error Reports, Debugging, Troubleshooting */</p>
<hr />
<div>{{forum|47|Effects & Shaders}}<br />
{{Rendering}}<br />
<!--<br />
{{WIP|More to follow}}<br />
--><br />
<br />
This is meant to become an introduction to '''shader programming in FlightGear''', for the time being (03/2010), this is work in progress, please feel free to ask questions or suggest topics.<br />
<br />
Your help in improving and updating this article is appreciated, thanks!<br />
<br />
Tutorials about GLSL Programming in general are collected at [[GLSL Shader Programming Resources]] <br />
<br />
For an OpenGL quick reference, please see: http://www.khronos.org/files/opengl-quick-reference-card.pdf for an GLSL quick reference see [http://www-evasion.imag.fr/Membres/Sebastien.Barbier/Enseignement/glsl_quickref.pdf glsl_quickref.pdf]<br />
<br />
== What is GLSL? ==<br />
''GLSL'' (''OpenGL Shading Language'' or "GLslang") is the official OpenGL shading language and allows you to write programs, so called "shaders" in a high level shading language that is based on the C programming language to create OpenGL fragment (pixel) and vertex shaders.<br />
<br />
With the recent advances in graphics cards, new features have been added to allow for increased flexibility in the rendering pipeline at the vertex and fragment level. Programmability at this level is achieved with the use of fragment and vertex shaders.<br />
<br />
GLSL was created to give developers more direct control of the graphics pipeline without having to use assembly language or hardware-specific languages. Shaders provide the possibility to process individual vertices or fragments individually, so that complex rendering tasks can be accomplished without stressing the CPU. Support for shader was first introduced via extensions in OpenGL 1.5, but is now part of the core OpenGL 2.0 standard.<br />
<br />
Shaders are written and stored as plain text files, which can be uploaded (as strings) and executed on the GPU (processor of the graphics card).<br />
<br />
== What is a shader? ==<br />
A ''shader'' is a programmable replacement for parts of the fixed OpenGL function pipeline, you can imagine it sort of like a "plugin" to customize rendering for specific scene elements.<br />
<br />
GLSL shaders are not stand-alone applications; they require an application that utilizes the OpenGL API. <br />
A shader is a program, to be run it must be loaded, compiled and linked. <br />
Shaders will be compiled when the 3D application starts. They will be validated and optimized for the current hardware.<br />
<br />
Actually each vertex and fragment shader must have one entry point (the main function) each, but you can create and link more shaders.<br />
<br />
GLSL shaders themselves are simply a set of strings that are passed to the hardware vendors driver for compilation from within an application using the OpenGL APIs entry points. Shaders can be created on the fly from within an application or read in as text files, but must be sent to the driver in the form of a string. <br />
<br />
GLSL has explicit ties to the OpenGL API - to the extent that much of the OpenGL "state" (for example which light sources are bound, what material properties are currently set up) is presented as pre-defined global variables in GLSL.<br />
<br />
Shaders offer:<br />
* Opportunity for Improved Visual Quality<br />
* Algorithm Flexibility<br />
* Performance Benefits<br />
<br />
Shaders have access to textures and the render state (parameters, matrices, lights, materials etc).<br />
A "pass" is the rendering of a 3D Model with a vertex and pixel shader pair.<br />
An effect can require multiple passes, while each pass can use a different shader and/or model pair.<br />
A Pass can render to a texture (to be used by another pass). Think of the "fixed functionality" as the default Shader.<br />
<br />
To make it simple, a shader is a program that is loaded on the GPU and called for every vertex or pixel: this gives programmers the possibility to implement techniques and visual effects and execute them faster. In modern games or simulators lots of shaders are used: lights, water, skinning, reflections and much more. <br />
<br />
We can create as many shader programs as needed. You can have many shaders of the same type (vertex or fragment) attached to the same program, but only one of them can define the entry point — the <code>main()</code> function.<br />
<br />
Each Shader program is assigned an handler, and you can have as many programs linked and ready to use as you want (and your hardware allows).<br />
Once rendering, we can switch from program to program, and even go back to fixed functionality during a single frame. <br />
<br />
To really understand shaders, you should have a knowledge about the rendering pipeline; this helps to understand where and when the shaders act in the rendering process. In general, you must know that vertex are collected, processed by vertex shaders, primitives are built, then are applied colors, textures and are also called fragment shaders; finally it comes to the rasterization and the frame is put on the buffer. <br />
<br />
Some benefits of using GLSL are:<br />
* Cross platform compatibility on multiple operating systems, including Linux, Mac OS and Windows.<br />
* The ability to write shaders that can be used on any hardware vendor’s graphics card that supports the OpenGL Shading Language.<br />
* Each hardware vendor includes the GLSL compiler in their driver, thus allowing each vendor to create code optimized for their particular graphics cards architecture.<br />
<br />
== Language features ==<br />
While GLSL has a C-Like syntax, it introduces some new types and keywords. To get a detailed view of the language, please see the GLSL specification you can find on http://www.opengl.org/documentation/glsl/<br />
<br />
The OpenGL Shading Language provides many operators familiar to those with a background in using the C programming language. This gives shader developers flexibility when writing shaders. GLSL contains the operators in C and C++, with the exception of pointers. Bitwise operators were added in version 1.30.<br />
<br />
Similar to the C programming language, GLSL supports loops and branching, including <code>if</code>, <code>else</code>, <code>if</code>/<code>else</code>, <code>for</code>, <code>do-while</code>, <code>break</code>, <code>continue</code>, etc.<br />
<br />
User defined functions are supported, and a wide variety of commonly used functions are provided built-in as well. This allows the graphics card manufacturer the ability to optimize these built-in functions at the hardware level if they are inclined to do so. Many of these functions are similar to those found in the math library of the C programming language such as <code>exp()</code> and <code>abs()</code> while others are specific to graphics programming such as <code>smoothstep()</code> and <code>texture2D()</code>.<br />
<br />
== Error Reports, Debugging, Troubleshooting ==<br />
<br />
Shaders are compiled at FG startup.<br />
<br />
Shader compilation errors can be found in the fgfs.log file. More about the [[Commonly_used_debugging_tools#fgfs.log|fgfs.log here]].<br />
<br />
As of FG 2016.4.4, shaders do not seem to recompile upon Debug/Reload Aircraft Model or File/Reset. So the only option to re-compile/test a shader is to quit a re-start FG altogether.<br />
<br />
== Shader types ==<br />
There are two types of shaders in GLSL: ''vertex shaders'' and ''fragment shaders'' (with geometry shaders being a part of OpenGL 3.2).<br />
<br />
These are executed by vertex and fragment processors in the graphics hardware.<br />
<br />
* Vertex shaders transform vertices, set up data for fragment shaders<br />
* Fragment shaders operate on fragments generated by rasterization<br />
* Geometry shaders create geometry on the GPU<br />
<br />
Typically, vertex shader files use the file extension <code>.vert</code>, while fragment shader files use the <code>.frag</code> extension. <br />
In FlightGear, these files can be found in the <code>Shaders</code> subdirectory of the base package, in essence <code>$FG_ROOT/Shaders</code>.<br />
<br />
For a list of currently available shaders, you may want to take a look at: {{fg root file|Shaders}}.<br />
<br />
So, shaders generally go around in pairs - one shader (the ''vertex shader'') is a short program that takes in one vertex from the main CPU and produces one vertex that is passed on to the GPU rasterizer which uses the vertices to create triangles - which it then chops up into individual pixel-sized fragments. <br />
<br />
A vertex shader is run once per vertex, while a fragment shader is run once per fragment covered by the primitive being rendered (a point, a line or a triangle). A fragment equate a pixel except in the case of multi-sampling where a pixel can be the weighted average of several fragments. Multi-sampling is used to remove aliasing and jagged edges.<br />
Many such executions can happen in parallel. There is no communication or ordering between executions. Vertex shaders are flexible and quick.<br />
<br />
=== Vertex shaders ===<br />
{{FGCquote<br />
|The vertex shader doesn't know anything about the mesh it renders, it just knows one single vertex at a time and all the info that is attached to the vertex (normals, tangents, binormals, color,...) And the vertex shader doesn't really draw anything, it just takes care of all the things which have to do with 'where in space' you are.<br />
The way this works is that for all the vertices of an object you want to render, the position of the object gets attached to all vertices (currently in the color spot). The vertex shader then just adds the offset vector to the vertex coordinate with respect to the origin.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32326487/<br />
|title=<nowiki>Re: [Flightgear-devel] cities in FG & how to move forward</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-05-11</nowiki><br />
}}<br />
}}<br />
<br />
{| class="wikitable"<br />
! Input<br />
| Vertex attributes<br />
|-<br />
! Output<br />
| At least vertex position (in the clip space)<br />
|-<br />
! Restrictions<br />
| Cannot access any vertex other than the current one<br />
|-<br />
! ''Note''<br />
| ''Loading a vertex shader turns off parts of the OpenGL pipeline (vertex shaders fully replace the "Texturing & Lighting unit").''<br />
|}<br />
<br />
Objects in a computer graphics scene are usually meshes that are made up of polygons. The corner of each of those polygons is called a ''vertex''.<br />
A vertex shader receives input in the form of per-vertex variables called ''attribute variables'', and per-polygon variables called ''uniform variables''.<br />
The vertex shader must specify the coordinates of the vertex in question. This way, the geometry of the object can be modified. <br />
<br />
Vertex shaders operate on each vertex, the vertex shader is executed for every vertex related OpenGL call (for example <code>glVertex*</code> or <code>glDrawArrays</code>).<br />
Accordingly, this means for example, that for meshes that contain for example 5000 vertices, the vertex shader will also be executed 5000 times.<br />
<br />
A single vertex itself is composed of a number of ''attributes'' (vertex attrib), such as: position, texture coordinates, normal and color for the most common. <br />
The position (attribute) is the most important one. The coordinates (x, y and z) of the vertex's entering position are those which have been given by the 3D modeler during the creation of the 3D model. The vertex's position is defined in the local space of the mesh (or object space). <br />
<br />
A vertex shader provides almost full control over what is happening with each vertex. Consequently, all per-vertex operations of the fixed function OpenGL pipeline are replaced by the custom vertex shader. <br />
<br />
Vertex shaders take application geometry and per-vertex attributes as input and transform the input data in some meaningful way.<br />
<br />
* A vertex shader '''must''' write to <code>gl_Position</code><br />
* A vertex shader '''can''' write to <code>gl_PointSize</code>, <code>gl_ClipVertex</code><br />
* <code>gl_Vertex</code> is an attribute supplying the untransformed vertex coordinate<br />
* <code>gl_Position</code> is an special output variable for the transformed vertex coordinate<br />
<br />
A vertex shader can also set other variables which are called ''varying variables''.<br />
The values of these variables are passed on to the second kind of shader, the ''fragment shader''. <br />
The fragment shader is run for every pixel on the screen where the polygons of the mesh appear. The fragment shader is responsible for setting the final color of that little piece of the mesh<br />
<br />
Common tasks for a vertex shader include:<br />
* Vertex position transformation<br />
* Per vertex lighting<br />
* Normal transformation<br />
* Texture coordinates transformation or generation<br />
* Vertex color computation<br />
* Geometry skinning<br />
* Animation<br />
* Setting up data for fragment shaders<br />
<br />
The vertex shader runs from start to end for each and every vertex that's passed into the graphics card – the fragment process does the same thing at the pixel level. In most scenes there are a heck of a lot more pixel fragments than there are vertices – so the performance of the fragment shader is vastly more important and any work we can do in the vertex shader, we probably should. <br />
<br />
A minum vertex shader example may looks this:<br />
<syntaxhighlight lang="glsl"><br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fragment shaders ===<br />
{{FGCquote<br />
|the fragment shader basically knows only the pixel it is about to render and whatever information is passed from the vertex shader. Based on 'where' the vertex shader says the pixel is, the rasterizer stage determines what the texture for the pixel should be. <br />
But there are techniques to do this in a different way, for instance the water depth map uses world coordinates to look up a world texture, and the gardens would have to be drawn in a similar way.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32326487/<br />
|title=<nowiki>Re: [Flightgear-devel] cities in FG & how to move forward</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-05-11</nowiki><br />
}}<br />
}}<br />
<br />
{| class="wikitable"<br />
! Input<br />
| Interpolation of the vertex shader outputs<br />
|-<br />
! Output<br />
| Usually a fragment color.<br />
|-<br />
! Restrictions<br />
| Fragment shaders have no knowledge of neighboring pixels.<br />
|-<br />
! ''Note''<br />
| ''Loading a fragment shader turns off parts of the OpenGL pipeline (pixel shaders fully replace the "Texturing Unit").''<br />
|}<br />
<br />
The other shader (the ''fragment shader'' - also (incorrectly) known as the "pixel shader") takes one pixel from the rasterizer and generates one pixel to write or blend into the frame buffer. <br />
<br />
A fragment shader can write to the following special output variables:<br />
* <code>gl_FragColor</code> to set the color of the fragment<br />
* <code>gl_FragData[n]</code> to output to a specific render target<br />
* <code>gl_FragDepth</code> to set the fragment depth<br />
<br />
Common tasks of fragment shaders include:<br />
* Texturing (even procedural)<br />
* Per pixel lighting and material application<br />
* Ray tracing<br />
* Fragment color computation<br />
* Operations on Interpolated Values<br />
* Doing operations per fragment to make pretty pictures<br />
<br />
A minimum fragment shader may look like this:<br />
<syntaxhighlight lang="glsl"><br />
void main(void)<br />
{<br />
gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);<br />
}<br />
</syntaxhighlight><br />
<br />
A fragment shader takes perspective-correct interpolated attribute values as input and either discards the fragment or outputs the fragment's color.<br />
<br />
Fragment shaders operate on every fragment which is produced by rasterization. Fragment shaders give you nearly full control over what is happening with each fragment. However just like vertex shaders, a fragment shader replaces all per-fragment operations of the fixed function OpenGL pipeline.<br />
<br />
== Data types in GLSL ==<br />
Note that there is no implicit type conversion in GLSL, all conversions and initializations have to be done using explicit constructor calls!<br />
<br />
=== Scalars ===<br />
* <code>float</code> – 32 bit, very nearly IEEE-754 compatible<br />
* <code>int</code> – at least 16 bit, but not backed by a fixed-width register<br />
* <code>bool</code> – like C++, but must be explicitly used for all flow control<br />
<br />
=== Vectors ===<br />
* <code>vec2</code>, <code>vec3</code>, <code>vec4</code> – 2D, 3D and 4D floating point vector<br />
* <code>ivec2</code>, <code>ivec3</code>, <code>ivec4</code> – 2D, 3D and 4D integer vector<br />
* <code>bvec2</code>, <code>bvec3</code>, <code>bvec4</code> – 2D, 3D and 4D boolean vectors<br />
<br />
Accessing a vector can be done using letters as well as standard C selectors.<br />
<br />
TODO: explain swizzling<br />
<br />
One can use the letters x,y,z,w to access vectors components; r,g,b,a for color components; and<br />
s,t,p,q for texture coordinates.<br />
<br />
=== Matrices ===<br />
* <code>mat2</code> – 2x2 floating point matrix<br />
* <code>mat3</code> – 3x3 floating point matrix<br />
* <code>mat4</code> – 4x4 floating potint matrix <br />
<br />
=== Samplers ===<br />
In GLSL, textures are represented and accessed using so called "samplers", which are used for sampling textures and which have to be uniform. The following samplers are available:<br />
<br />
* <code>sampler1D</code>, <code>sampler2D</code>, <code>sampler3D</code> – 1D, 2D and 3D texture<br />
* <code>samplerCube</code> – Cube Map texture<br />
* <code>sampler1Dshadow</code>, <code>sampler2Dshadow</code> – 1D and 2D depth-component texture<br />
<br />
=== Arrays ===<br />
GLSL supports the same syntax for creating arrays that is already known from C or C++, e.g.:<br />
<syntaxhighlight lang="glsl"><br />
vec2 foo[10];<br />
</syntaxhighlight><br />
<br />
So, arrays can be declared using the same syntax as in C, but can't be initialized when declared. Accessing array's elements is done as in C.<br />
<br />
=== Structures ===<br />
Structures can also be created like in C or C++, e.g.:<br />
<syntaxhighlight lang="glsl"><br />
struct foo {<br />
vec3 pos;<br />
};<br />
</syntaxhighlight><br />
<br />
== Global storage qualifiers ==<br />
Used for communication between shaders and application:<br />
* <code>const</code> – For declaring non-writable, compile-time constant variables<br />
* <code>attribute</code> – For frequently changing (per vertex) information passed from the application to a vertex shader (no integers, bools, structs, or arrays)<br />
* <code>uniform</code> – For infrequently changing (per primitive) information passed from the application to a vertex or fragment shader:constant shader parameters that can be changed between draws (cannot be written to in a shader, do not change per-vertex or per-fragment)<br />
* <code>varying</code> – For information passed from a vertex shader to a fragment shader, will be interpolated in a perspective-correct manner during rasterization (can write in vertex shader, but only read in fragment shader)<br />
<br />
== Functions ==<br />
* Much like C++<br />
* Entry point into a shader is <code>void main()</code><br />
* Overloading based on parameter type (but not return type)<br />
* No support for direct or indirect recursion<br />
* Call by value-return calling convention<br />
<br />
As in C, a shader is structured in functions. At least each type of shader must have a main function declared with the following syntax: <code>void main()</code><br />
User defined functions may be defined. As in C a function may have a return value, and use the return statement to pass out its result. A function can be void. The return type can have any type, except array.<br />
<br />
=== Parameter qualifiers ===<br />
The parameters of a function may have the following qualifiers:<br />
* <code>in</code> – Copy in, but don't copy back out (still writable within function)<br />
* <code>out</code> – Only copy out; undefined at function entry point<br />
* <code>inout</code> – Copy in and copy out<br />
<br />
If no qualifier is specified, by default it is considered to be in.<br />
<br />
== Built-ins ==<br />
=== Vertex shader ===<br />
* <code>vec4 gl_Position;</code> – '''Must''' be written<br />
* <code>vec4 gl_ClipPosition;</code> – May be written<br />
* <code>float gl_PointSize;</code> – May be written<br />
<br />
=== Fragment shader ===<br />
* <code>float gl_FragColor;</code> – May be written<br />
* <code>float gl_FragDepth;</code> – May be read/written<br />
* <code>vec4 gl_FragCoord;</code> – May be read<br />
* <code>bool gl_FrontFacing;</code> – May be read<br />
<br />
=== Vertex attributes ===<br />
Only available in vertex shaders.<br />
<br />
* <code>attribute vec4 gl_Vertex;</code><br />
* <code>attribute vec3 gl_Normal;</code><br />
* <code>attribute vec4 gl_Color;</code><br />
* <code>attribute vec4 gl_SecondaryColor;</code><br />
* <code>attribute vec4 gl_MultiTexCoordn;</code><br />
* <code>attribute float gl_FogCoord;</code><br />
<br />
=== Uniforms ===<br />
* <code>uniform mat4 gl_ModelViewMatrix;</code><br />
* <code>uniform mat4 gl_ProjectionMatrix;</code><br />
* <code>uniform mat4 gl_ModelViewProjectionMatrix;</code><br />
* <code>uniform mat3 gl_NormalMatrix;</code><br />
* <code>uniform mat4 gl_TextureMatrix[n];</code><br />
<br />
<syntaxhighlight lang="glsl"><br />
struct gl_MaterialParameters {<br />
vec4 emission;<br />
vec4 ambient;<br />
vec4 diffuse;<br />
vec4 specular;<br />
float shininess;<br />
};<br />
</syntaxhighlight><br />
<br />
* <code>uniform gl_MaterialParameters gl_FrontMaterial;</code><br />
* <code>uniform gl_MaterialParameters gl_BackMaterial;</code><br />
<br />
<syntaxhighlight lang="glsl"><br />
struct gl_LightSourceParameters {<br />
vec4 ambient;<br />
vec4 diffuse;<br />
vec4 specular;<br />
vec4 position;<br />
vec4 halfVector;<br />
vec3 spotDirection;<br />
float spotExponent;<br />
float spotCutoff;<br />
float spotCosCutoff;<br />
float constantAttenuation<br />
float linearAttenuation<br />
float quadraticAttenuation<br />
};<br />
</syntaxhighlight><br />
<br />
* <code>uniform gl_LightSourceParameters gl_LightSource[gl_MaxLights];</code><br />
<br />
=== Varyings ===<br />
An interface between vertex and fragment shaders is provided by varying variables: Vertex shaders compute values per vertex and fragment shaders compute values per fragment. <br />
The value of a varying variable defined in a vertex shader, will be interpolated (perspective-correct) over the primitive being rendered and the interpolated value in the fragment shader can be accessed.<br />
<br />
Varying variables can only be used with the data types <code>float</code>, <code>vec2</code>, <code>vec3</code>, <code>vec4</code>, <code>mat2</code>, <code>mat3</code>, <code>mat4</code>. (and arrays of them too.)<br />
<br />
* <code>varying vec4 gl_FrontColor; // vertex</code><br />
* <code>varying vec4 gl_BackColor; // vertex</code><br />
* <code>varying vec4 gl_FrontSecColor; // vertex</code><br />
* <code>varying vec4 gl_BackSecColor; // vertex</code><br />
* <code>varying vec4 gl_Color; // fragment</code><br />
* <code>varying vec4 gl_SecondaryColor; // fragment</code><br />
* <code>varying vec4 gl_TexCoord[]; // both</code><br />
* <code>varying float gl_FogFragCoord; // both</code><br />
<br />
=== Functions ===<br />
== Anatomy of a shader ==<br />
A shader's entry point is the main function which returns void and takes no arguments (void)<br />
<br />
=== Anatomy of a vertex shader ===<br />
The function <code>void main()</code> is called afresh for each vertex in the 3D object model:<br />
<syntaxhighlight lang="glsl"><br />
// Vertex Shader<br />
void main() {<br />
gl_Position = gl_Vertex;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Anatomy of a fragment shader ===<br />
The function <code>void main()</code> is called afresh for each fragment/pixel in the 3D object model:<br />
<syntaxhighlight lang="glsl"><br />
// Fragment Shader<br />
void main() {<br />
gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0);<br />
}<br />
</syntaxhighlight><br />
<br />
== Practical application – ALS landing lights – spotlight ==<br />
[[File:ALS Secondary Light Proof of Concept.png|thumb|300px|ALS secondary light proof of concept]]<br />
[[File:Als Secondary Lights combined with Fog Effect.jpg|thumb|300px|Weather settings to produce fog and ALS landing lights on a runway.]]<br />
[[File:Model on Water and Trees on Land.jpg|thumb|300px|Model on water and trees on land ALS lights effect]]<br />
[[File:Model on Water.jpg|thumb|300px|ALS lights effect over model and water.]]<br />
[[File:ALS Lights over Model and Terrain.jpg|thumb|300px|ALS lights over model and terrain]]<br />
<br />
The ALS landing lights-spotlight (we'll call it ALS lights from now on) is a good example for showing how to incorporate a shader effect into FlightGear as it touches many parts of the visuals we see and many parts of the coding pipeline.<br />
<br />
In the case of ALS Lights, you have to add the effect to every visual item rendered on the screen that you want to see a light shining on. If you want it to be capable of shining on everything, you have to account for each separate item and how that item is rendered. That is a lot of code to touch.<br />
<br />
The list might include<br />
* Terrain<br />
** Runway<br />
** Dirtrunway<br />
** Agriculture<br />
* Models<br />
** AI<br />
** Aircraft<br />
** Tree<br />
** Buildings<br />
* Weather<br />
** Fog<br />
** Clouds<br />
** Hazes<br />
* Water<br />
** Inland<br />
** Ocean<br />
** Stream<br />
<br />
Some of these items may be controlled or rendered by the same effect and shader file. They might have to be accounted for individually. They may have special lighting influences that have to be accounted for. You have to take each one separately and account for all its needs. <br />
<br />
The example highlighted in this article is what was added to <code>tree.eff</code> to shine the lights on trees.<br />
<br />
=== Program flow simplified ===<br />
Preferences/Nasal/XML → Property tree → Effect file → Shader → Rendered to screen<br />
<br />
=== Preferences/Nasal/XML ===<br />
Any combination of Preferences, [[Nasal|Nasal]] or [[Xml|XML]] manipulates data in the [[Property Tree|property tree]]. <br />
In this case the switch to turn on the landing or spot light and a couple other needed data containers are defined in <code>$FG_ROOT/preferences.xml</code> with the following lines.<br />
<syntaxhighlight lang="xml"><br />
<als-secondary-lights><br />
<use-searchlight type="bool">false</use-searchlight><br />
<use-landing-light type="bool">false</use-landing-light><br />
<use-alt-landing-light type="bool">false</use-alt-landing-light><br />
<landing-light1-offset-deg type="float">0.0</landing-light1-offset-deg><br />
<landing-light2-offset-deg type="float">0.0</landing-light2-offset-deg><br />
</als-secondary-lights><br />
</syntaxhighlight><br />
<br />
They show up in the property tree under <code>sim/rendering/als-secondary-lights</code> and can be activated or manipulated by normal Nasal calls or XML.<br />
<br />
=== Property tree ===<br />
The [[Property Tree|property tree]] is like the CPU of the [[FlightGear]] program at a user level. It's a go-between that allows the user to see and influence many aspects at the heart of the program in ALMOST real time. More of the internals of FlightGear are being exposed to the property tree than ever before. This allows us to have user level access in areas of the code that used to only be reserved for [[Programming Resources|programmers]]. Because of the manner in which the property tree is fed information, and the one step removed from the C source, care must be taken in how it is used. Depending on how it is used it won't be as responsive to manipulation as it would be if you were to change the same information at the C source level. <br />
<br />
=== Effects file ===<br />
The effects file is the mechanism we use to combine and manipulate all the necessary data to create stunning visual effects. It's the link between the data contained and produced in Nasal, XML and the property tree and the graphics rendering pipeline. It's there to allow us to create these affects without having to know or use the C++ code base. Its flexible framework allows for an almost infinite range of sophisticated effects.<br />
<br />
==== Parameters ====<br />
Parameter entries defined in the Effect file correspond to a property tree data container (static or variable). They will contain the data needed by the shader program to perform its magic. The type of information contained in the property tree might be program control data or variable/static data that the shader program can manipulate prior to sending on to render.<br />
In the case of ALS lights, below is some of the data passed to, and used by, the shader program.<br />
<br />
<syntaxhighlight lang="xml"><br />
<small><br />
<display_xsize><use>/sim/startup/xsize</use></display_xsize><br />
<display_ysize><use>/sim/startup/ysize</use></display_ysize><br />
<view_pitch_offset><use>/sim/current-view/pitch-offset-deg</use></view_pitch_offset><br />
<view_heading_offset><use>/sim/current-view/heading-offset-deg</use></view_heading_offset><br />
<view_fov><use>/sim/current-view/field-of-view</use></view_fov><br />
<use_searchlight><use>/sim/rendering/als-secondary-lights/use-searchlight</use></use_searchlight><br />
<use_landing_light><use>/sim/rendering/als-secondary-lights/use-landing-light</use></use_landing_light><br />
<use_alt_landing_light><use>/sim/rendering/als-secondary-lights/use-alt-landing-light</use></use_alt_landing_light><br />
<landing_light1_offset><use>/sim/rendering/als-secondary-lights/landing-light1-offset-deg</use></landing_light1_offset><br />
<landing_light2_offset><use>/sim/rendering/als-secondary-lights/landing-light2-offset-deg</use></landing_light2_offset><br />
<quality_level><use>/sim/rendering/shaders/landmass</use></quality_level><br />
<tquality_level><use>/sim/rendering/shaders/transition</use></tquality_level><br />
</small><br />
</syntaxhighlight><br />
<br />
Note the <code>use-searchlight</code> entry, it is pointing to the use-searchlight entry in the property tree under <code>sim/rendering/als-secondary-lights</code> that was defined in <code>preferences.xml</code>.<br />
<br />
Some of this data may play a duel role inside the shader program. In other words it might be used to control other functions in addition to ALS lights.<br />
There will also be other parameter entries that have nothing to do with ALS lights. They might be used for other actions or effects the shader is handling. <br />
<br />
==== Technique ====<br />
In general, the shader program and the uniforms are defined in between the technique tags. The technique is assigned an index to distinguish one technique from another (technique n="1"). As is the case with tree.eff, sometimes the shader program and its uniforms are defined and needed in more than one technique. In the case of <code>tree.eff</code> it is used in technique 4 and 5. Which means in FlightGear, the tree shader set to either of the the highest two shader settings still produces ALS lights when activated.<br />
<br />
==== Shader program ====<br />
Next comes the entry to define what shader program the parameters data is going to be passed to.<br />
This is where you specify what shader program is to be used by the technique. ALS has the lowest techniques, with higher quality preceding lower quality.<br />
<br />
<syntaxhighlight lang="xml"><br />
<program><br />
<fragment-shader>Shaders/tree-ALS.frag</fragment-shader><br />
<fragment-shader>Shaders/secondary_lights.frag</fragment-shader><br />
</program><br />
</syntaxhighlight><br />
In the case of ALS Lights, so far we only have to deal with the fragment shader.<br />
<br />
The program section of the effect file is a nifty method used to allow users to add shaders to FlightGear without having to add code at C level language base. The C level base is programed to recognize the XML tag pair of <program></program> and thus incorporate the GLSL program files pointed to between the tags. Otherwise you would have to add the GLSL program calls in the base C requiring a completely different set of programing skills and also the necessity of compiling FlightGear everytime you want to add new shader. It can work this way because shader programs are compiled at run-time.<br />
<br />
We'll describe the contents of the shader programs below. For now, suffice it to say <code>tree-ALS.frag</code> contains the main program and <code>secondary_lights.frag</code> has functions that are passed uniform data that is manipulated and returned to main for processing.<br />
<br />
==== Uniforms ====<br />
The uniforms section is the mechanism that feeds the parameter data to the shader program.<br />
<syntaxhighlight lang="xml"><br />
<small><br />
<uniform><br />
<name>view_pitch_offset</name><br />
<type>float</type><br />
<value><use>view_pitch_offset</use></value><br />
</uniform><br />
<uniform><br />
<name>view_heading_offset</name><br />
<type>float</type><br />
<value><use>view_heading_offset</use></value><br />
</uniform><br />
<uniform><br />
<name>field_of_view</name><br />
<type>float</type><br />
<value><use>view_fov</use></value><br />
</uniform><br />
<uniform><br />
<name>landing_light1_offset</name><br />
<type>float</type><br />
<value><use>landing_light1_offset</use></value><br />
</uniform><br />
<uniform><br />
<name>landing_light2_offset</name><br />
<type>float</type><br />
<value><use>landing_light2_offset</use></value><br />
</uniform><br />
<uniform><br />
<name>use_searchlight</name><br />
<type>int</type><br />
<value><use>use_searchlight</use></value><br />
</uniform><br />
<uniform><br />
<name>use_landing_light</name><br />
<type>int</type><br />
<value><use>use_landing_light</use></value><br />
</uniform><br />
<uniform><br />
<name>use_alt_landing_light</name><br />
<type>int</type><br />
<value><use>use_alt_landing_light</use></value><br />
</uniform><br />
<uniform><br />
<name>display_xsize</name><br />
<type>int</type><br />
<value><use>display_xsize</use></value><br />
</uniform><br />
<uniform><br />
<name>display_ysize</name><br />
<type>int</type><br />
<value><use>display_ysize</use></value><br />
</uniform><br />
</small><br />
</syntaxhighlight><br />
Note the name, <code>use_searchlight</code>, which was originally defined in <code>preferences.xml</code> and then became an entry in parameters is now being passed to the program shader by the uniform. Below in the "Shader program" section, we will show you how the shader receives the uniform's data.<br />
<br />
=== Shader programs ===<br />
The shader programs used in this example are <code>tree-ALS.frag</code> and <code>secondary_lights.frag</code>.<br />
<br />
=== secondary_lights.frag ===<br />
<code>secondary_lights.frag</code> consists of<br />
* Uniform inputs (data coming into the shader to be manipulated<br />
* Functions that manipulate the uniform data<br />
<br />
Following it the actual GLSL code in <code>secondary_lights.frag</code>.<br />
<br />
==== Uniform input ====<br />
<syntaxhighlight lang="glsl"><br />
uniform int display_xsize;<br />
uniform int display_ysize;<br />
uniform float field_of_view;<br />
uniform float view_pitch_offset;<br />
uniform float view_heading_offset;<br />
</syntaxhighlight><br />
<br />
==== Functions ====<br />
<syntaxhighlight lang="glsl"><br />
float light_distance_fading(in float dist)<br />
{<br />
return min(1.0, 10000.0/(dist*dist));<br />
}<br />
<br />
float fog_backscatter(in float avisibility)<br />
{<br />
return 0.5* min(1.0,10000.0/(avisibility*avisibility));<br />
}<br />
<br />
vec3 searchlight()<br />
{<br />
vec2 center = vec2 (float(display_xsize) * 0.5, float(display_ysize) * 0.4);<br />
float headlightIntensity; <br />
float lightRadius = (float(display_xsize) *9.16 /field_of_view);<br />
float angularDist = length(gl_FragCoord.xy -center);<br />
if (angularDist < lightRadius)<br />
{<br />
headlightIntensity = pow(cos(angularDist/lightRadius * 1.57075),2.0);<br />
//headlightIntensity = headlightIntensity * <br />
//headlightIntensity*= clamp(1.0 + 0.15 * log(1000.0/(dist*dist)),0.0,1.0);<br />
return headlightIntensity * vec3 (0.5,0.5, 0.5);<br />
}<br />
else return vec3 (0.0,0.0,0.0);<br />
}<br />
<br />
vec3 landing_light(in float offset)<br />
{<br />
float fov_h = field_of_view;<br />
float fov_v = float(display_ysize)/float(display_xsize) * field_of_view; <br />
float yaw_offset;<br />
if (view_heading_offset > 180.0)<br />
{yaw_offset = -360.0+view_heading_offset;}<br />
else<br />
{yaw_offset = view_heading_offset;}<br />
float x_offset = (float(display_xsize) / fov_h * (yaw_offset + offset));<br />
float y_offset = -(float(display_ysize) / fov_v * view_pitch_offset);<br />
vec2 center = vec2 (float(display_xsize) * 0.5 + x_offset, float(display_ysize) * 0.4 + y_offset);<br />
float landingLightIntensity; <br />
float lightRadius = (float(display_xsize) *9.16 /field_of_view);<br />
float angularDist = length(gl_FragCoord.xy -center);<br />
if (angularDist < lightRadius)<br />
{<br />
landingLightIntensity = pow(cos(angularDist/lightRadius * 1.57075),2.0);<br />
//landingLightIntensity *= min(1.0, 10000.0/(dist*dist));<br />
return landingLightIntensity * vec3 (0.5,0.5, 0.5);<br />
}<br />
else return vec3 (0.0,0.0,0.0);<br />
}<br />
</syntaxhighlight><br />
<br />
=== tree-ALS.frag ===<br />
<code>tree-ALS.frag</code> consists of<br />
* Uniform inputs (data coming into the shader to be manipulated<br />
* Functions that manipulate the uniform data<br />
<br />
Following it the actual GLSL code in <code>tree-ALS.frag</code>.<br />
While there is significantly more code in <code>tree-ALS.frag</code>, only the code that was included for the ALS lights is being shown and discussed here.<br />
<br />
==== Uniform input ====<br />
Uniform data is brought into the shader in the following manner.<br />
<br />
<syntaxhighlight lang="glsl"><br />
uniform float landing_light1_offset;<br />
uniform float landing_light2_offset;<br />
uniform int use_searchlight;<br />
uniform int use_landing_light;<br />
uniform int use_alt_landing_light;<br />
uniform int quality_level;<br />
uniform int tquality_level;<br />
</syntaxhighlight><br />
<br />
Note <code>use_searchlight</code> and how it is defined as incoming uniform data.<br />
<br />
==== Variable data ====<br />
Variable data can be defined in the shader program. An example of variable data defined in the shader program that is needed for ALS lights is<br />
<syntaxhighlight lang="glsl"><br />
vec3 secondary_light = vec3 (0.0,0.0,0.0);<br />
</syntaxhighlight><br />
<br />
==== Functions ====<br />
Function calls to the function defined in <code>secondary_lights.frag</code> are<br />
<syntaxhighlight lang="glsl"><br />
vec3 searchlight();<br />
vec3 landing_light(in float offset);<br />
</syntaxhighlight><br />
<br />
You don't have to use any path information or includes in the code because the GLSL compiler program takes care of linking all the shader programs as long as they are defined correctly in the "programs" section of the effect file.<br />
Variable data can be passed to and returned from GLSL functions just like any other language.<br />
<br />
==== Main program ====<br />
The <code>main()</code> function is the heart of the shader program. This is where the shader program manipulates all the data made available to it.<br />
<syntaxhighlight lang="glsl"><br />
void main()<br />
{<br />
vec3 secondary_light = vec3 (0.0,0.0,0.0);<br />
if ((quality_level>5) && (tquality_level>5))<br />
{<br />
if (use_searchlight == 1)<br />
{<br />
secondary_light += searchlight();<br />
}<br />
if (use_landing_light == 1)<br />
{<br />
secondary_light += landing_light(landing_light1_offset);<br />
}<br />
if (use_alt_landing_light == 1)<br />
{<br />
secondary_light += landing_light(landing_light2_offset);<br />
}<br />
}<br />
vec4 fragColor = vec4 (gl_Color.rgb +secondary_light * light_distance_fading(dist),1.0) * texel;<br />
}<br />
</syntaxhighlight><br />
<br />
Note how <code>use_searchlight</code> is used in the main function to determine if the property defined in <code>preferences.xml</code> and manipulated in the property tree is set to true or 1.<br />
<br />
Some of the variable data contained in the shader program is used for other purposes and is introduced into the shader program from other property, parameter and uniform definitions not pertaining to ALS lights.<br />
<br />
==== File list ====<br />
Files that are directly touched by this effect include <br />
* <code>preferences.xml</code><br />
* <code>agriculture.eff</code>:<br />
** Inherits properties from <code>crop</code> << <code>terrain-default</code><br />
** Adds program shaders (technique 2)<br />
*** Fragment <code>agriculture-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 2)<br />
* <code>airfield.eff</code>:<br />
** Inherits properties from <code>terrain-default</code><br />
** Adds program shaders (technique 2)<br />
*** Fragment <code>airfield-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 2)<br />
* <code>building.eff</code>:<br />
** Inherits properties from <code>model-combined-deferred</code> << <code>model-combined</code><br />
** Adds program shaders (technique 4)<br />
*** Fragment <code>model-ALS-ultra.frag</code> and <code>secondary_lights.frag</code><br />
** Inherits uniforms from <code>model-combined-deferred</code> << <code>model-combined</code><br />
* <code>dirt-runway.eff</code>:<br />
** Inherits properties from <code>crop</code> << <code>terrain-default</code><br />
** Adds program shaders (technique 2)<br />
*** Fragment <code>drunway-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 2)<br />
* <code>model-combined.eff</code>:<br />
** Inherits properties from <code>model-default</code><br />
** Adds program shaders (technique 4)<br />
*** Fragment <code>model-ALS-ultra.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 4)<br />
* <code>model-default.eff</code>:<br />
** Adds properties<br />
** Adds program shaders (technique 5)<br />
*** Fragment <code>model-ALS-base.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 5)<br />
* <code>runway.eff</code>:<br />
** Inherits properties from terrain-default<br />
** Adds program shaders (technique 2)<br />
*** Fragment <code>runway-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 2)<br />
* <code>terrain-default.eff</code>:<br />
** Adds properties<br />
** Adds program shaders (technique 3)<br />
*** Fragment <code>terrain-ALS-ultra.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 3)<br />
* <code>tree.eff</code>:<br />
** Adds properties<br />
** Adds program shaders (technique 4 and 5)<br />
*** Fragment <code>tree-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 4 and 5)<br />
* <code>urban.eff</code>:<br />
** Inherits properties from <code>terrain-default</code><br />
** Adds program shaders (technique 1 and 2)<br />
*** Fragment <code>urban-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 1 and 2)<br />
* <code>water.eff</code>:<br />
** Inherits properties from <code>terrain-default</code><br />
** Adds program shaders (technique 1)<br />
*** Fragment <code>water-ALS-high.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 1)<br />
* <code>water-inland.eff</code>:<br />
** Inherits properties from <code>terrain-default</code><br />
** Adds program shaders (technique 2)<br />
*** Fragment <code>water-ALS-high.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 2)<br />
<br />
== General comments from forum discussion ==<br />
{{cquote|In principle, we always do the same steps in the fragment shaders to determine the color of a pixel:<br />
<br />
* texel color - what is the base color of the pixel fully lit and unfogged<br />
* lighting - how is this color changed by the light falling onto that pixel, usually the relation is something like fragColor equals texel * light<br />
* fogging - how much is the color hidden by haze, usually the relation is something like gl_FragColor equals mix(fragColor, hazeColor, transmission_factor);<br />
what is displayed on the screen in the end is whatever gl_FragColor is set to<br />
<br />
But the location where this happens isn't always obvious - often (part) of the light is computed in the vertex shader already, in which case it typically enters the fragment shader as gl_Color.<br />
<br />
So, the lighting equation in tree-haze.frag is indeed<br />
vec4 fragColor equals vec4 (gl_Color.xyz,1.0) * texel;<br />
and your change to the light should happen just before that. But you can't do<br />
gl_Color.rgb equals gl_Color.rgb + my_light;<br />
because gl_Color.rgb is a varying variable type, and you can't assign new values to them inside the shader, so you need to either make a new variable or just do<br />
vec4 fragColor equals vec4 ((gl_Color.rgb + my_light),1.0) * texel;<br />
(note that color.rgb is the same as color.xyz, GLSL doesn't really care which convention you use, but I took a few months to learn that, so early code by myself often uses xyz indexing convention for color vectors as well).<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=15#p220075 <br />
|title=ALS landing lights<br />
|author=Thorsten Renk |date= Tue Oct 07, 2014 12:04 -0700}}</ref>|Thorsten Renk}}<br />
<br />
{{cquote|An effect is a container for a series of techniques which are all the possible things you could do with some object.<br />
<br />
The <predicate> section inside each effect determines which of the techniques we actually run. Typically the predicate section contains conditionals on a) rendering framework properties b) OpenGL extension support and c) quality level properties. The renderer searches the effects from lowest to highest technique number and uses the first one that fits the bill (which is why high quality levels precede low quality levels).<br />
<br />
The rendering itself is specified as <pass> - each pass runs the renderer over the whole scene. We may sometimes make a quick first pass to fill the depth buffer or a stencil buffer, but usually we render with a single pass.<br />
<br />
Techniques may not involve a shader at all, for instance 12 in terrain-default is a pure fixed pipeline fallback technique, but all the rendering you're interested in use a shader, which means they have a <program> section which determines what actual code is supposed to run.<br />
<br />
If you run a shader, that needs parameters specified as <uniform>, and textures which need to be assigned to a texture unit _and_ be declared as a uniform sampler.<br />
<br />
In addition, each technique contains a host of parameter configuring the fixed pipeline elements, like alpha tests before the fragment stage, or depth buffer writing/reading, alpha blending,... you can ignore them on the first go.<br />
<br />
So if you want to look at which shader code is executed when you call the water effect at a certain quality level, you need to work your way through the predicate sections of the techniques from lowest to highest till you find the one that matches, and then look into the program section of that technique.<br />
<br />
Now, to make matters more complicated, all the parameters and textures that are assigned to uniforms and texture units in the techniques need to be declared and linked to properties were applicable in the <parameters> section heading each effect declaration. So a texture you want to use has to appear three times - in the parameters section heading the effect, inside the technique assigned to a texture unit and assigned to a uniform sampler.<br />
<br />
Now, inheritance moves all the declared parameters and techniques from one effect to the one inheriting. In the case of water, that means the technique is actually _not_ inherited because terrain-default.eff doesn't contain a technique 1 at all, but the general <parameters> section is inherited. So you don't need to declare the additions to <parameters> again, but you do need to make the changes to the <programs> and the <uniform> sections.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=15#p220152 <br />
|title=ALS landing lights<br />
|author=Thorsten Renk |date= Wed Oct 08, 2014 1:58 -0700}}</ref>|Thorsten Renk}}<br />
<br />
{{cquote|At low water shader quality, water isn't rendered separately from the terrain, i.e. it runs via terrain-default.eff - since you modified that to allow light, light works for water out of the box.<br />
At high water slider, the techniques in water.eff kick in, and only then do you need to modify the specific water shader code. Now, the peculiar thing about water is that there are two effects (water.eff and water_inland.eff) sharing the same shader code (but calling it with somewhat different parameters). So the function not found error was presumably caused by you modifying water.eff whereas the water you were seeing was initiated by water_inland.eff, and in that effect, the secondary_lights.frag wasn't initially in the program section. So if you alter the water shader code, you need to modify two effect files rather than one to pass the right parameters and access the functions you need.<br />
<br />
..........<br />
..........<br />
<br />
Adding them _after_ fogging, isn't what you want - you'll see that if visibility is <100 m, everything will go black at night, because fog color is black at night, so finalColor.rgb of a heavily fogged object will also be black, and then when you light it up, you multiply your light value with black and it'll be black. Or, if you add the light value (which you should only do if the object you add it to is a light color itself), then you'll get a featureless grey. You want to add light after texel color and before fogging.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=30#p220216 <br />
|title=ALS landing lights<br />
|author=Thorsten Renk |date= Wed Oct 08, 2014 11:19 -0700}}</ref>|Thorsten Renk}}<br />
<br />
{{cquote|So, in old times when rendering textures was slow and complicated, we rendered objects with monochromatic surface colors. Then the (schematic) lighting equation (without specular, and the sum of ambient and diffuse already computed) was<br />
<br />
visibleColor.rgb equals objectColor.rgb * light.rgb + objectEmissive.rgb<br />
<br />
Now, we have textures and so we get<br />
<br />
visibleColor.rgb equals objectColor.rgb * texel.rgb * light.rgb + objectEmissive.rgb + lightMapTexel.rgb<br />
<br />
Since we can have the full color information in the texture, objectColor.rgb is usually (1.0,1.0,1.0) because the info is redundant. But if you don't use a texture, of course objectColor.rgb has the actual color value (incidentially, I think we shouldn't texture with monochromatic surfaces at all, it creates a jarring visual impression which can be cured by using even a small texture...)<br />
<br />
But if you do, the rendering pipeline is set up to compute color.rgb equals objectColor * light.rgb in the vertex shader, so the equation we have in the fragment shader is something like<br />
<br />
visibleColor.rgb equals color.rgb * texel.rgb + objectEmissive.rgb + lightMapTexel.rgb<br />
<br />
and if we add a secondary light like<br />
<br />
visibleColor.rgb equals (color.rgb + secLight.rgb) * texel.rgb<br />
<br />
it of course can never recover the color information, because color.rgb is zero at night since you multiplied the actual color with zero sunlight and the texel doesn't carry information for an untextured object.<br />
<br />
Since the secondary light is in screen coordinates, it can't appear in the vertex shader, so the solution would be to pass the actual color and light rather than their product to the fragment shader. Which is expensive, because we need another varying vec3, and varying variable types fill memory and need to be computed an interpolated per vertex/per fragment - which is why I'm not sure whether we shouldn't accept the loss of the color...<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=45#p220321 <br />
|title=ALS landing lights<br />
|author=Thorsten Renk |date= Sat Oct 11, 2014 1:28 -0700}}</ref>|Thorsten Renk}}<br />
<br />
{{cquote|Inheritance works like this:<br />
<br />
The base effect has a list of things<br />
<br />
A1 B1 C1 D1<br />
<br />
The second effect inherits 1 but just declares C2 and E2, so then the list is<br />
<br />
A1 B1 C2 D1 E2<br />
<br />
The third effect inherits from 2 and declares A3, so then the list is<br />
<br />
A3 B1 C2 D1 E2<br />
<br />
whereas if the third effect would inherit from 1, then the list would be<br />
<br />
A3 B1 C1 D1<br />
<br />
So if already present, inheritance overrides, if not present it adds. I suspect that's why programs need to be indexed, so they they override and don't add...<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=45#p220403 <br />
|title=ALS landing lights<br />
|author=Thorsten Renk |date= Sat Oct 11, 2014 11:33 -0700}}</ref>|Thorsten Renk}}<br />
<br />
<references/><br />
<br />
[[Category:Howto|Shader Programming in FlightGear]]<br />
[[Category:Shader development]]<br />
[[Category: Core developer documentation]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Howto:Shader_programming_in_FlightGear&diff=107429Howto:Shader programming in FlightGear2017-03-19T02:44:58Z<p>Flug: /* Language features */ Error log, troubleshooting section</p>
<hr />
<div>{{forum|47|Effects & Shaders}}<br />
{{Rendering}}<br />
<!--<br />
{{WIP|More to follow}}<br />
--><br />
<br />
This is meant to become an introduction to '''shader programming in FlightGear''', for the time being (03/2010), this is work in progress, please feel free to ask questions or suggest topics.<br />
<br />
Your help in improving and updating this article is appreciated, thanks!<br />
<br />
Tutorials about GLSL Programming in general are collected at [[GLSL Shader Programming Resources]] <br />
<br />
For an OpenGL quick reference, please see: http://www.khronos.org/files/opengl-quick-reference-card.pdf for an GLSL quick reference see [http://www-evasion.imag.fr/Membres/Sebastien.Barbier/Enseignement/glsl_quickref.pdf glsl_quickref.pdf]<br />
<br />
== What is GLSL? ==<br />
''GLSL'' (''OpenGL Shading Language'' or "GLslang") is the official OpenGL shading language and allows you to write programs, so called "shaders" in a high level shading language that is based on the C programming language to create OpenGL fragment (pixel) and vertex shaders.<br />
<br />
With the recent advances in graphics cards, new features have been added to allow for increased flexibility in the rendering pipeline at the vertex and fragment level. Programmability at this level is achieved with the use of fragment and vertex shaders.<br />
<br />
GLSL was created to give developers more direct control of the graphics pipeline without having to use assembly language or hardware-specific languages. Shaders provide the possibility to process individual vertices or fragments individually, so that complex rendering tasks can be accomplished without stressing the CPU. Support for shader was first introduced via extensions in OpenGL 1.5, but is now part of the core OpenGL 2.0 standard.<br />
<br />
Shaders are written and stored as plain text files, which can be uploaded (as strings) and executed on the GPU (processor of the graphics card).<br />
<br />
== What is a shader? ==<br />
A ''shader'' is a programmable replacement for parts of the fixed OpenGL function pipeline, you can imagine it sort of like a "plugin" to customize rendering for specific scene elements.<br />
<br />
GLSL shaders are not stand-alone applications; they require an application that utilizes the OpenGL API. <br />
A shader is a program, to be run it must be loaded, compiled and linked. <br />
Shaders will be compiled when the 3D application starts. They will be validated and optimized for the current hardware.<br />
<br />
Actually each vertex and fragment shader must have one entry point (the main function) each, but you can create and link more shaders.<br />
<br />
GLSL shaders themselves are simply a set of strings that are passed to the hardware vendors driver for compilation from within an application using the OpenGL APIs entry points. Shaders can be created on the fly from within an application or read in as text files, but must be sent to the driver in the form of a string. <br />
<br />
GLSL has explicit ties to the OpenGL API - to the extent that much of the OpenGL "state" (for example which light sources are bound, what material properties are currently set up) is presented as pre-defined global variables in GLSL.<br />
<br />
Shaders offer:<br />
* Opportunity for Improved Visual Quality<br />
* Algorithm Flexibility<br />
* Performance Benefits<br />
<br />
Shaders have access to textures and the render state (parameters, matrices, lights, materials etc).<br />
A "pass" is the rendering of a 3D Model with a vertex and pixel shader pair.<br />
An effect can require multiple passes, while each pass can use a different shader and/or model pair.<br />
A Pass can render to a texture (to be used by another pass). Think of the "fixed functionality" as the default Shader.<br />
<br />
To make it simple, a shader is a program that is loaded on the GPU and called for every vertex or pixel: this gives programmers the possibility to implement techniques and visual effects and execute them faster. In modern games or simulators lots of shaders are used: lights, water, skinning, reflections and much more. <br />
<br />
We can create as many shader programs as needed. You can have many shaders of the same type (vertex or fragment) attached to the same program, but only one of them can define the entry point — the <code>main()</code> function.<br />
<br />
Each Shader program is assigned an handler, and you can have as many programs linked and ready to use as you want (and your hardware allows).<br />
Once rendering, we can switch from program to program, and even go back to fixed functionality during a single frame. <br />
<br />
To really understand shaders, you should have a knowledge about the rendering pipeline; this helps to understand where and when the shaders act in the rendering process. In general, you must know that vertex are collected, processed by vertex shaders, primitives are built, then are applied colors, textures and are also called fragment shaders; finally it comes to the rasterization and the frame is put on the buffer. <br />
<br />
Some benefits of using GLSL are:<br />
* Cross platform compatibility on multiple operating systems, including Linux, Mac OS and Windows.<br />
* The ability to write shaders that can be used on any hardware vendor’s graphics card that supports the OpenGL Shading Language.<br />
* Each hardware vendor includes the GLSL compiler in their driver, thus allowing each vendor to create code optimized for their particular graphics cards architecture.<br />
<br />
== Language features ==<br />
While GLSL has a C-Like syntax, it introduces some new types and keywords. To get a detailed view of the language, please see the GLSL specification you can find on http://www.opengl.org/documentation/glsl/<br />
<br />
The OpenGL Shading Language provides many operators familiar to those with a background in using the C programming language. This gives shader developers flexibility when writing shaders. GLSL contains the operators in C and C++, with the exception of pointers. Bitwise operators were added in version 1.30.<br />
<br />
Similar to the C programming language, GLSL supports loops and branching, including <code>if</code>, <code>else</code>, <code>if</code>/<code>else</code>, <code>for</code>, <code>do-while</code>, <code>break</code>, <code>continue</code>, etc.<br />
<br />
User defined functions are supported, and a wide variety of commonly used functions are provided built-in as well. This allows the graphics card manufacturer the ability to optimize these built-in functions at the hardware level if they are inclined to do so. Many of these functions are similar to those found in the math library of the C programming language such as <code>exp()</code> and <code>abs()</code> while others are specific to graphics programming such as <code>smoothstep()</code> and <code>texture2D()</code>.<br />
<br />
== Error Reports, Debugging, Troubleshooting ==<br />
<br />
Shader compilation errors can be found in the fgfs.log file. More about the [[Commonly_used_debugging_tools#fgfs.log|fgfs.log here]].<br />
<br />
== Shader types ==<br />
There are two types of shaders in GLSL: ''vertex shaders'' and ''fragment shaders'' (with geometry shaders being a part of OpenGL 3.2).<br />
<br />
These are executed by vertex and fragment processors in the graphics hardware.<br />
<br />
* Vertex shaders transform vertices, set up data for fragment shaders<br />
* Fragment shaders operate on fragments generated by rasterization<br />
* Geometry shaders create geometry on the GPU<br />
<br />
Typically, vertex shader files use the file extension <code>.vert</code>, while fragment shader files use the <code>.frag</code> extension. <br />
In FlightGear, these files can be found in the <code>Shaders</code> subdirectory of the base package, in essence <code>$FG_ROOT/Shaders</code>.<br />
<br />
For a list of currently available shaders, you may want to take a look at: {{fg root file|Shaders}}.<br />
<br />
So, shaders generally go around in pairs - one shader (the ''vertex shader'') is a short program that takes in one vertex from the main CPU and produces one vertex that is passed on to the GPU rasterizer which uses the vertices to create triangles - which it then chops up into individual pixel-sized fragments. <br />
<br />
A vertex shader is run once per vertex, while a fragment shader is run once per fragment covered by the primitive being rendered (a point, a line or a triangle). A fragment equate a pixel except in the case of multi-sampling where a pixel can be the weighted average of several fragments. Multi-sampling is used to remove aliasing and jagged edges.<br />
Many such executions can happen in parallel. There is no communication or ordering between executions. Vertex shaders are flexible and quick.<br />
<br />
=== Vertex shaders ===<br />
{{FGCquote<br />
|The vertex shader doesn't know anything about the mesh it renders, it just knows one single vertex at a time and all the info that is attached to the vertex (normals, tangents, binormals, color,...) And the vertex shader doesn't really draw anything, it just takes care of all the things which have to do with 'where in space' you are.<br />
The way this works is that for all the vertices of an object you want to render, the position of the object gets attached to all vertices (currently in the color spot). The vertex shader then just adds the offset vector to the vertex coordinate with respect to the origin.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32326487/<br />
|title=<nowiki>Re: [Flightgear-devel] cities in FG & how to move forward</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-05-11</nowiki><br />
}}<br />
}}<br />
<br />
{| class="wikitable"<br />
! Input<br />
| Vertex attributes<br />
|-<br />
! Output<br />
| At least vertex position (in the clip space)<br />
|-<br />
! Restrictions<br />
| Cannot access any vertex other than the current one<br />
|-<br />
! ''Note''<br />
| ''Loading a vertex shader turns off parts of the OpenGL pipeline (vertex shaders fully replace the "Texturing & Lighting unit").''<br />
|}<br />
<br />
Objects in a computer graphics scene are usually meshes that are made up of polygons. The corner of each of those polygons is called a ''vertex''.<br />
A vertex shader receives input in the form of per-vertex variables called ''attribute variables'', and per-polygon variables called ''uniform variables''.<br />
The vertex shader must specify the coordinates of the vertex in question. This way, the geometry of the object can be modified. <br />
<br />
Vertex shaders operate on each vertex, the vertex shader is executed for every vertex related OpenGL call (for example <code>glVertex*</code> or <code>glDrawArrays</code>).<br />
Accordingly, this means for example, that for meshes that contain for example 5000 vertices, the vertex shader will also be executed 5000 times.<br />
<br />
A single vertex itself is composed of a number of ''attributes'' (vertex attrib), such as: position, texture coordinates, normal and color for the most common. <br />
The position (attribute) is the most important one. The coordinates (x, y and z) of the vertex's entering position are those which have been given by the 3D modeler during the creation of the 3D model. The vertex's position is defined in the local space of the mesh (or object space). <br />
<br />
A vertex shader provides almost full control over what is happening with each vertex. Consequently, all per-vertex operations of the fixed function OpenGL pipeline are replaced by the custom vertex shader. <br />
<br />
Vertex shaders take application geometry and per-vertex attributes as input and transform the input data in some meaningful way.<br />
<br />
* A vertex shader '''must''' write to <code>gl_Position</code><br />
* A vertex shader '''can''' write to <code>gl_PointSize</code>, <code>gl_ClipVertex</code><br />
* <code>gl_Vertex</code> is an attribute supplying the untransformed vertex coordinate<br />
* <code>gl_Position</code> is an special output variable for the transformed vertex coordinate<br />
<br />
A vertex shader can also set other variables which are called ''varying variables''.<br />
The values of these variables are passed on to the second kind of shader, the ''fragment shader''. <br />
The fragment shader is run for every pixel on the screen where the polygons of the mesh appear. The fragment shader is responsible for setting the final color of that little piece of the mesh<br />
<br />
Common tasks for a vertex shader include:<br />
* Vertex position transformation<br />
* Per vertex lighting<br />
* Normal transformation<br />
* Texture coordinates transformation or generation<br />
* Vertex color computation<br />
* Geometry skinning<br />
* Animation<br />
* Setting up data for fragment shaders<br />
<br />
The vertex shader runs from start to end for each and every vertex that's passed into the graphics card – the fragment process does the same thing at the pixel level. In most scenes there are a heck of a lot more pixel fragments than there are vertices – so the performance of the fragment shader is vastly more important and any work we can do in the vertex shader, we probably should. <br />
<br />
A minum vertex shader example may looks this:<br />
<syntaxhighlight lang="glsl"><br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fragment shaders ===<br />
{{FGCquote<br />
|the fragment shader basically knows only the pixel it is about to render and whatever information is passed from the vertex shader. Based on 'where' the vertex shader says the pixel is, the rasterizer stage determines what the texture for the pixel should be. <br />
But there are techniques to do this in a different way, for instance the water depth map uses world coordinates to look up a world texture, and the gardens would have to be drawn in a similar way.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32326487/<br />
|title=<nowiki>Re: [Flightgear-devel] cities in FG & how to move forward</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-05-11</nowiki><br />
}}<br />
}}<br />
<br />
{| class="wikitable"<br />
! Input<br />
| Interpolation of the vertex shader outputs<br />
|-<br />
! Output<br />
| Usually a fragment color.<br />
|-<br />
! Restrictions<br />
| Fragment shaders have no knowledge of neighboring pixels.<br />
|-<br />
! ''Note''<br />
| ''Loading a fragment shader turns off parts of the OpenGL pipeline (pixel shaders fully replace the "Texturing Unit").''<br />
|}<br />
<br />
The other shader (the ''fragment shader'' - also (incorrectly) known as the "pixel shader") takes one pixel from the rasterizer and generates one pixel to write or blend into the frame buffer. <br />
<br />
A fragment shader can write to the following special output variables:<br />
* <code>gl_FragColor</code> to set the color of the fragment<br />
* <code>gl_FragData[n]</code> to output to a specific render target<br />
* <code>gl_FragDepth</code> to set the fragment depth<br />
<br />
Common tasks of fragment shaders include:<br />
* Texturing (even procedural)<br />
* Per pixel lighting and material application<br />
* Ray tracing<br />
* Fragment color computation<br />
* Operations on Interpolated Values<br />
* Doing operations per fragment to make pretty pictures<br />
<br />
A minimum fragment shader may look like this:<br />
<syntaxhighlight lang="glsl"><br />
void main(void)<br />
{<br />
gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);<br />
}<br />
</syntaxhighlight><br />
<br />
A fragment shader takes perspective-correct interpolated attribute values as input and either discards the fragment or outputs the fragment's color.<br />
<br />
Fragment shaders operate on every fragment which is produced by rasterization. Fragment shaders give you nearly full control over what is happening with each fragment. However just like vertex shaders, a fragment shader replaces all per-fragment operations of the fixed function OpenGL pipeline.<br />
<br />
== Data types in GLSL ==<br />
Note that there is no implicit type conversion in GLSL, all conversions and initializations have to be done using explicit constructor calls!<br />
<br />
=== Scalars ===<br />
* <code>float</code> – 32 bit, very nearly IEEE-754 compatible<br />
* <code>int</code> – at least 16 bit, but not backed by a fixed-width register<br />
* <code>bool</code> – like C++, but must be explicitly used for all flow control<br />
<br />
=== Vectors ===<br />
* <code>vec2</code>, <code>vec3</code>, <code>vec4</code> – 2D, 3D and 4D floating point vector<br />
* <code>ivec2</code>, <code>ivec3</code>, <code>ivec4</code> – 2D, 3D and 4D integer vector<br />
* <code>bvec2</code>, <code>bvec3</code>, <code>bvec4</code> – 2D, 3D and 4D boolean vectors<br />
<br />
Accessing a vector can be done using letters as well as standard C selectors.<br />
<br />
TODO: explain swizzling<br />
<br />
One can use the letters x,y,z,w to access vectors components; r,g,b,a for color components; and<br />
s,t,p,q for texture coordinates.<br />
<br />
=== Matrices ===<br />
* <code>mat2</code> – 2x2 floating point matrix<br />
* <code>mat3</code> – 3x3 floating point matrix<br />
* <code>mat4</code> – 4x4 floating potint matrix <br />
<br />
=== Samplers ===<br />
In GLSL, textures are represented and accessed using so called "samplers", which are used for sampling textures and which have to be uniform. The following samplers are available:<br />
<br />
* <code>sampler1D</code>, <code>sampler2D</code>, <code>sampler3D</code> – 1D, 2D and 3D texture<br />
* <code>samplerCube</code> – Cube Map texture<br />
* <code>sampler1Dshadow</code>, <code>sampler2Dshadow</code> – 1D and 2D depth-component texture<br />
<br />
=== Arrays ===<br />
GLSL supports the same syntax for creating arrays that is already known from C or C++, e.g.:<br />
<syntaxhighlight lang="glsl"><br />
vec2 foo[10];<br />
</syntaxhighlight><br />
<br />
So, arrays can be declared using the same syntax as in C, but can't be initialized when declared. Accessing array's elements is done as in C.<br />
<br />
=== Structures ===<br />
Structures can also be created like in C or C++, e.g.:<br />
<syntaxhighlight lang="glsl"><br />
struct foo {<br />
vec3 pos;<br />
};<br />
</syntaxhighlight><br />
<br />
== Global storage qualifiers ==<br />
Used for communication between shaders and application:<br />
* <code>const</code> – For declaring non-writable, compile-time constant variables<br />
* <code>attribute</code> – For frequently changing (per vertex) information passed from the application to a vertex shader (no integers, bools, structs, or arrays)<br />
* <code>uniform</code> – For infrequently changing (per primitive) information passed from the application to a vertex or fragment shader:constant shader parameters that can be changed between draws (cannot be written to in a shader, do not change per-vertex or per-fragment)<br />
* <code>varying</code> – For information passed from a vertex shader to a fragment shader, will be interpolated in a perspective-correct manner during rasterization (can write in vertex shader, but only read in fragment shader)<br />
<br />
== Functions ==<br />
* Much like C++<br />
* Entry point into a shader is <code>void main()</code><br />
* Overloading based on parameter type (but not return type)<br />
* No support for direct or indirect recursion<br />
* Call by value-return calling convention<br />
<br />
As in C, a shader is structured in functions. At least each type of shader must have a main function declared with the following syntax: <code>void main()</code><br />
User defined functions may be defined. As in C a function may have a return value, and use the return statement to pass out its result. A function can be void. The return type can have any type, except array.<br />
<br />
=== Parameter qualifiers ===<br />
The parameters of a function may have the following qualifiers:<br />
* <code>in</code> – Copy in, but don't copy back out (still writable within function)<br />
* <code>out</code> – Only copy out; undefined at function entry point<br />
* <code>inout</code> – Copy in and copy out<br />
<br />
If no qualifier is specified, by default it is considered to be in.<br />
<br />
== Built-ins ==<br />
=== Vertex shader ===<br />
* <code>vec4 gl_Position;</code> – '''Must''' be written<br />
* <code>vec4 gl_ClipPosition;</code> – May be written<br />
* <code>float gl_PointSize;</code> – May be written<br />
<br />
=== Fragment shader ===<br />
* <code>float gl_FragColor;</code> – May be written<br />
* <code>float gl_FragDepth;</code> – May be read/written<br />
* <code>vec4 gl_FragCoord;</code> – May be read<br />
* <code>bool gl_FrontFacing;</code> – May be read<br />
<br />
=== Vertex attributes ===<br />
Only available in vertex shaders.<br />
<br />
* <code>attribute vec4 gl_Vertex;</code><br />
* <code>attribute vec3 gl_Normal;</code><br />
* <code>attribute vec4 gl_Color;</code><br />
* <code>attribute vec4 gl_SecondaryColor;</code><br />
* <code>attribute vec4 gl_MultiTexCoordn;</code><br />
* <code>attribute float gl_FogCoord;</code><br />
<br />
=== Uniforms ===<br />
* <code>uniform mat4 gl_ModelViewMatrix;</code><br />
* <code>uniform mat4 gl_ProjectionMatrix;</code><br />
* <code>uniform mat4 gl_ModelViewProjectionMatrix;</code><br />
* <code>uniform mat3 gl_NormalMatrix;</code><br />
* <code>uniform mat4 gl_TextureMatrix[n];</code><br />
<br />
<syntaxhighlight lang="glsl"><br />
struct gl_MaterialParameters {<br />
vec4 emission;<br />
vec4 ambient;<br />
vec4 diffuse;<br />
vec4 specular;<br />
float shininess;<br />
};<br />
</syntaxhighlight><br />
<br />
* <code>uniform gl_MaterialParameters gl_FrontMaterial;</code><br />
* <code>uniform gl_MaterialParameters gl_BackMaterial;</code><br />
<br />
<syntaxhighlight lang="glsl"><br />
struct gl_LightSourceParameters {<br />
vec4 ambient;<br />
vec4 diffuse;<br />
vec4 specular;<br />
vec4 position;<br />
vec4 halfVector;<br />
vec3 spotDirection;<br />
float spotExponent;<br />
float spotCutoff;<br />
float spotCosCutoff;<br />
float constantAttenuation<br />
float linearAttenuation<br />
float quadraticAttenuation<br />
};<br />
</syntaxhighlight><br />
<br />
* <code>uniform gl_LightSourceParameters gl_LightSource[gl_MaxLights];</code><br />
<br />
=== Varyings ===<br />
An interface between vertex and fragment shaders is provided by varying variables: Vertex shaders compute values per vertex and fragment shaders compute values per fragment. <br />
The value of a varying variable defined in a vertex shader, will be interpolated (perspective-correct) over the primitive being rendered and the interpolated value in the fragment shader can be accessed.<br />
<br />
Varying variables can only be used with the data types <code>float</code>, <code>vec2</code>, <code>vec3</code>, <code>vec4</code>, <code>mat2</code>, <code>mat3</code>, <code>mat4</code>. (and arrays of them too.)<br />
<br />
* <code>varying vec4 gl_FrontColor; // vertex</code><br />
* <code>varying vec4 gl_BackColor; // vertex</code><br />
* <code>varying vec4 gl_FrontSecColor; // vertex</code><br />
* <code>varying vec4 gl_BackSecColor; // vertex</code><br />
* <code>varying vec4 gl_Color; // fragment</code><br />
* <code>varying vec4 gl_SecondaryColor; // fragment</code><br />
* <code>varying vec4 gl_TexCoord[]; // both</code><br />
* <code>varying float gl_FogFragCoord; // both</code><br />
<br />
=== Functions ===<br />
== Anatomy of a shader ==<br />
A shader's entry point is the main function which returns void and takes no arguments (void)<br />
<br />
=== Anatomy of a vertex shader ===<br />
The function <code>void main()</code> is called afresh for each vertex in the 3D object model:<br />
<syntaxhighlight lang="glsl"><br />
// Vertex Shader<br />
void main() {<br />
gl_Position = gl_Vertex;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Anatomy of a fragment shader ===<br />
The function <code>void main()</code> is called afresh for each fragment/pixel in the 3D object model:<br />
<syntaxhighlight lang="glsl"><br />
// Fragment Shader<br />
void main() {<br />
gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0);<br />
}<br />
</syntaxhighlight><br />
<br />
== Practical application – ALS landing lights – spotlight ==<br />
[[File:ALS Secondary Light Proof of Concept.png|thumb|300px|ALS secondary light proof of concept]]<br />
[[File:Als Secondary Lights combined with Fog Effect.jpg|thumb|300px|Weather settings to produce fog and ALS landing lights on a runway.]]<br />
[[File:Model on Water and Trees on Land.jpg|thumb|300px|Model on water and trees on land ALS lights effect]]<br />
[[File:Model on Water.jpg|thumb|300px|ALS lights effect over model and water.]]<br />
[[File:ALS Lights over Model and Terrain.jpg|thumb|300px|ALS lights over model and terrain]]<br />
<br />
The ALS landing lights-spotlight (we'll call it ALS lights from now on) is a good example for showing how to incorporate a shader effect into FlightGear as it touches many parts of the visuals we see and many parts of the coding pipeline.<br />
<br />
In the case of ALS Lights, you have to add the effect to every visual item rendered on the screen that you want to see a light shining on. If you want it to be capable of shining on everything, you have to account for each separate item and how that item is rendered. That is a lot of code to touch.<br />
<br />
The list might include<br />
* Terrain<br />
** Runway<br />
** Dirtrunway<br />
** Agriculture<br />
* Models<br />
** AI<br />
** Aircraft<br />
** Tree<br />
** Buildings<br />
* Weather<br />
** Fog<br />
** Clouds<br />
** Hazes<br />
* Water<br />
** Inland<br />
** Ocean<br />
** Stream<br />
<br />
Some of these items may be controlled or rendered by the same effect and shader file. They might have to be accounted for individually. They may have special lighting influences that have to be accounted for. You have to take each one separately and account for all its needs. <br />
<br />
The example highlighted in this article is what was added to <code>tree.eff</code> to shine the lights on trees.<br />
<br />
=== Program flow simplified ===<br />
Preferences/Nasal/XML → Property tree → Effect file → Shader → Rendered to screen<br />
<br />
=== Preferences/Nasal/XML ===<br />
Any combination of Preferences, [[Nasal|Nasal]] or [[Xml|XML]] manipulates data in the [[Property Tree|property tree]]. <br />
In this case the switch to turn on the landing or spot light and a couple other needed data containers are defined in <code>$FG_ROOT/preferences.xml</code> with the following lines.<br />
<syntaxhighlight lang="xml"><br />
<als-secondary-lights><br />
<use-searchlight type="bool">false</use-searchlight><br />
<use-landing-light type="bool">false</use-landing-light><br />
<use-alt-landing-light type="bool">false</use-alt-landing-light><br />
<landing-light1-offset-deg type="float">0.0</landing-light1-offset-deg><br />
<landing-light2-offset-deg type="float">0.0</landing-light2-offset-deg><br />
</als-secondary-lights><br />
</syntaxhighlight><br />
<br />
They show up in the property tree under <code>sim/rendering/als-secondary-lights</code> and can be activated or manipulated by normal Nasal calls or XML.<br />
<br />
=== Property tree ===<br />
The [[Property Tree|property tree]] is like the CPU of the [[FlightGear]] program at a user level. It's a go-between that allows the user to see and influence many aspects at the heart of the program in ALMOST real time. More of the internals of FlightGear are being exposed to the property tree than ever before. This allows us to have user level access in areas of the code that used to only be reserved for [[Programming Resources|programmers]]. Because of the manner in which the property tree is fed information, and the one step removed from the C source, care must be taken in how it is used. Depending on how it is used it won't be as responsive to manipulation as it would be if you were to change the same information at the C source level. <br />
<br />
=== Effects file ===<br />
The effects file is the mechanism we use to combine and manipulate all the necessary data to create stunning visual effects. It's the link between the data contained and produced in Nasal, XML and the property tree and the graphics rendering pipeline. It's there to allow us to create these affects without having to know or use the C++ code base. Its flexible framework allows for an almost infinite range of sophisticated effects.<br />
<br />
==== Parameters ====<br />
Parameter entries defined in the Effect file correspond to a property tree data container (static or variable). They will contain the data needed by the shader program to perform its magic. The type of information contained in the property tree might be program control data or variable/static data that the shader program can manipulate prior to sending on to render.<br />
In the case of ALS lights, below is some of the data passed to, and used by, the shader program.<br />
<br />
<syntaxhighlight lang="xml"><br />
<small><br />
<display_xsize><use>/sim/startup/xsize</use></display_xsize><br />
<display_ysize><use>/sim/startup/ysize</use></display_ysize><br />
<view_pitch_offset><use>/sim/current-view/pitch-offset-deg</use></view_pitch_offset><br />
<view_heading_offset><use>/sim/current-view/heading-offset-deg</use></view_heading_offset><br />
<view_fov><use>/sim/current-view/field-of-view</use></view_fov><br />
<use_searchlight><use>/sim/rendering/als-secondary-lights/use-searchlight</use></use_searchlight><br />
<use_landing_light><use>/sim/rendering/als-secondary-lights/use-landing-light</use></use_landing_light><br />
<use_alt_landing_light><use>/sim/rendering/als-secondary-lights/use-alt-landing-light</use></use_alt_landing_light><br />
<landing_light1_offset><use>/sim/rendering/als-secondary-lights/landing-light1-offset-deg</use></landing_light1_offset><br />
<landing_light2_offset><use>/sim/rendering/als-secondary-lights/landing-light2-offset-deg</use></landing_light2_offset><br />
<quality_level><use>/sim/rendering/shaders/landmass</use></quality_level><br />
<tquality_level><use>/sim/rendering/shaders/transition</use></tquality_level><br />
</small><br />
</syntaxhighlight><br />
<br />
Note the <code>use-searchlight</code> entry, it is pointing to the use-searchlight entry in the property tree under <code>sim/rendering/als-secondary-lights</code> that was defined in <code>preferences.xml</code>.<br />
<br />
Some of this data may play a duel role inside the shader program. In other words it might be used to control other functions in addition to ALS lights.<br />
There will also be other parameter entries that have nothing to do with ALS lights. They might be used for other actions or effects the shader is handling. <br />
<br />
==== Technique ====<br />
In general, the shader program and the uniforms are defined in between the technique tags. The technique is assigned an index to distinguish one technique from another (technique n="1"). As is the case with tree.eff, sometimes the shader program and its uniforms are defined and needed in more than one technique. In the case of <code>tree.eff</code> it is used in technique 4 and 5. Which means in FlightGear, the tree shader set to either of the the highest two shader settings still produces ALS lights when activated.<br />
<br />
==== Shader program ====<br />
Next comes the entry to define what shader program the parameters data is going to be passed to.<br />
This is where you specify what shader program is to be used by the technique. ALS has the lowest techniques, with higher quality preceding lower quality.<br />
<br />
<syntaxhighlight lang="xml"><br />
<program><br />
<fragment-shader>Shaders/tree-ALS.frag</fragment-shader><br />
<fragment-shader>Shaders/secondary_lights.frag</fragment-shader><br />
</program><br />
</syntaxhighlight><br />
In the case of ALS Lights, so far we only have to deal with the fragment shader.<br />
<br />
The program section of the effect file is a nifty method used to allow users to add shaders to FlightGear without having to add code at C level language base. The C level base is programed to recognize the XML tag pair of <program></program> and thus incorporate the GLSL program files pointed to between the tags. Otherwise you would have to add the GLSL program calls in the base C requiring a completely different set of programing skills and also the necessity of compiling FlightGear everytime you want to add new shader. It can work this way because shader programs are compiled at run-time.<br />
<br />
We'll describe the contents of the shader programs below. For now, suffice it to say <code>tree-ALS.frag</code> contains the main program and <code>secondary_lights.frag</code> has functions that are passed uniform data that is manipulated and returned to main for processing.<br />
<br />
==== Uniforms ====<br />
The uniforms section is the mechanism that feeds the parameter data to the shader program.<br />
<syntaxhighlight lang="xml"><br />
<small><br />
<uniform><br />
<name>view_pitch_offset</name><br />
<type>float</type><br />
<value><use>view_pitch_offset</use></value><br />
</uniform><br />
<uniform><br />
<name>view_heading_offset</name><br />
<type>float</type><br />
<value><use>view_heading_offset</use></value><br />
</uniform><br />
<uniform><br />
<name>field_of_view</name><br />
<type>float</type><br />
<value><use>view_fov</use></value><br />
</uniform><br />
<uniform><br />
<name>landing_light1_offset</name><br />
<type>float</type><br />
<value><use>landing_light1_offset</use></value><br />
</uniform><br />
<uniform><br />
<name>landing_light2_offset</name><br />
<type>float</type><br />
<value><use>landing_light2_offset</use></value><br />
</uniform><br />
<uniform><br />
<name>use_searchlight</name><br />
<type>int</type><br />
<value><use>use_searchlight</use></value><br />
</uniform><br />
<uniform><br />
<name>use_landing_light</name><br />
<type>int</type><br />
<value><use>use_landing_light</use></value><br />
</uniform><br />
<uniform><br />
<name>use_alt_landing_light</name><br />
<type>int</type><br />
<value><use>use_alt_landing_light</use></value><br />
</uniform><br />
<uniform><br />
<name>display_xsize</name><br />
<type>int</type><br />
<value><use>display_xsize</use></value><br />
</uniform><br />
<uniform><br />
<name>display_ysize</name><br />
<type>int</type><br />
<value><use>display_ysize</use></value><br />
</uniform><br />
</small><br />
</syntaxhighlight><br />
Note the name, <code>use_searchlight</code>, which was originally defined in <code>preferences.xml</code> and then became an entry in parameters is now being passed to the program shader by the uniform. Below in the "Shader program" section, we will show you how the shader receives the uniform's data.<br />
<br />
=== Shader programs ===<br />
The shader programs used in this example are <code>tree-ALS.frag</code> and <code>secondary_lights.frag</code>.<br />
<br />
=== secondary_lights.frag ===<br />
<code>secondary_lights.frag</code> consists of<br />
* Uniform inputs (data coming into the shader to be manipulated<br />
* Functions that manipulate the uniform data<br />
<br />
Following it the actual GLSL code in <code>secondary_lights.frag</code>.<br />
<br />
==== Uniform input ====<br />
<syntaxhighlight lang="glsl"><br />
uniform int display_xsize;<br />
uniform int display_ysize;<br />
uniform float field_of_view;<br />
uniform float view_pitch_offset;<br />
uniform float view_heading_offset;<br />
</syntaxhighlight><br />
<br />
==== Functions ====<br />
<syntaxhighlight lang="glsl"><br />
float light_distance_fading(in float dist)<br />
{<br />
return min(1.0, 10000.0/(dist*dist));<br />
}<br />
<br />
float fog_backscatter(in float avisibility)<br />
{<br />
return 0.5* min(1.0,10000.0/(avisibility*avisibility));<br />
}<br />
<br />
vec3 searchlight()<br />
{<br />
vec2 center = vec2 (float(display_xsize) * 0.5, float(display_ysize) * 0.4);<br />
float headlightIntensity; <br />
float lightRadius = (float(display_xsize) *9.16 /field_of_view);<br />
float angularDist = length(gl_FragCoord.xy -center);<br />
if (angularDist < lightRadius)<br />
{<br />
headlightIntensity = pow(cos(angularDist/lightRadius * 1.57075),2.0);<br />
//headlightIntensity = headlightIntensity * <br />
//headlightIntensity*= clamp(1.0 + 0.15 * log(1000.0/(dist*dist)),0.0,1.0);<br />
return headlightIntensity * vec3 (0.5,0.5, 0.5);<br />
}<br />
else return vec3 (0.0,0.0,0.0);<br />
}<br />
<br />
vec3 landing_light(in float offset)<br />
{<br />
float fov_h = field_of_view;<br />
float fov_v = float(display_ysize)/float(display_xsize) * field_of_view; <br />
float yaw_offset;<br />
if (view_heading_offset > 180.0)<br />
{yaw_offset = -360.0+view_heading_offset;}<br />
else<br />
{yaw_offset = view_heading_offset;}<br />
float x_offset = (float(display_xsize) / fov_h * (yaw_offset + offset));<br />
float y_offset = -(float(display_ysize) / fov_v * view_pitch_offset);<br />
vec2 center = vec2 (float(display_xsize) * 0.5 + x_offset, float(display_ysize) * 0.4 + y_offset);<br />
float landingLightIntensity; <br />
float lightRadius = (float(display_xsize) *9.16 /field_of_view);<br />
float angularDist = length(gl_FragCoord.xy -center);<br />
if (angularDist < lightRadius)<br />
{<br />
landingLightIntensity = pow(cos(angularDist/lightRadius * 1.57075),2.0);<br />
//landingLightIntensity *= min(1.0, 10000.0/(dist*dist));<br />
return landingLightIntensity * vec3 (0.5,0.5, 0.5);<br />
}<br />
else return vec3 (0.0,0.0,0.0);<br />
}<br />
</syntaxhighlight><br />
<br />
=== tree-ALS.frag ===<br />
<code>tree-ALS.frag</code> consists of<br />
* Uniform inputs (data coming into the shader to be manipulated<br />
* Functions that manipulate the uniform data<br />
<br />
Following it the actual GLSL code in <code>tree-ALS.frag</code>.<br />
While there is significantly more code in <code>tree-ALS.frag</code>, only the code that was included for the ALS lights is being shown and discussed here.<br />
<br />
==== Uniform input ====<br />
Uniform data is brought into the shader in the following manner.<br />
<br />
<syntaxhighlight lang="glsl"><br />
uniform float landing_light1_offset;<br />
uniform float landing_light2_offset;<br />
uniform int use_searchlight;<br />
uniform int use_landing_light;<br />
uniform int use_alt_landing_light;<br />
uniform int quality_level;<br />
uniform int tquality_level;<br />
</syntaxhighlight><br />
<br />
Note <code>use_searchlight</code> and how it is defined as incoming uniform data.<br />
<br />
==== Variable data ====<br />
Variable data can be defined in the shader program. An example of variable data defined in the shader program that is needed for ALS lights is<br />
<syntaxhighlight lang="glsl"><br />
vec3 secondary_light = vec3 (0.0,0.0,0.0);<br />
</syntaxhighlight><br />
<br />
==== Functions ====<br />
Function calls to the function defined in <code>secondary_lights.frag</code> are<br />
<syntaxhighlight lang="glsl"><br />
vec3 searchlight();<br />
vec3 landing_light(in float offset);<br />
</syntaxhighlight><br />
<br />
You don't have to use any path information or includes in the code because the GLSL compiler program takes care of linking all the shader programs as long as they are defined correctly in the "programs" section of the effect file.<br />
Variable data can be passed to and returned from GLSL functions just like any other language.<br />
<br />
==== Main program ====<br />
The <code>main()</code> function is the heart of the shader program. This is where the shader program manipulates all the data made available to it.<br />
<syntaxhighlight lang="glsl"><br />
void main()<br />
{<br />
vec3 secondary_light = vec3 (0.0,0.0,0.0);<br />
if ((quality_level>5) && (tquality_level>5))<br />
{<br />
if (use_searchlight == 1)<br />
{<br />
secondary_light += searchlight();<br />
}<br />
if (use_landing_light == 1)<br />
{<br />
secondary_light += landing_light(landing_light1_offset);<br />
}<br />
if (use_alt_landing_light == 1)<br />
{<br />
secondary_light += landing_light(landing_light2_offset);<br />
}<br />
}<br />
vec4 fragColor = vec4 (gl_Color.rgb +secondary_light * light_distance_fading(dist),1.0) * texel;<br />
}<br />
</syntaxhighlight><br />
<br />
Note how <code>use_searchlight</code> is used in the main function to determine if the property defined in <code>preferences.xml</code> and manipulated in the property tree is set to true or 1.<br />
<br />
Some of the variable data contained in the shader program is used for other purposes and is introduced into the shader program from other property, parameter and uniform definitions not pertaining to ALS lights.<br />
<br />
==== File list ====<br />
Files that are directly touched by this effect include <br />
* <code>preferences.xml</code><br />
* <code>agriculture.eff</code>:<br />
** Inherits properties from <code>crop</code> << <code>terrain-default</code><br />
** Adds program shaders (technique 2)<br />
*** Fragment <code>agriculture-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 2)<br />
* <code>airfield.eff</code>:<br />
** Inherits properties from <code>terrain-default</code><br />
** Adds program shaders (technique 2)<br />
*** Fragment <code>airfield-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 2)<br />
* <code>building.eff</code>:<br />
** Inherits properties from <code>model-combined-deferred</code> << <code>model-combined</code><br />
** Adds program shaders (technique 4)<br />
*** Fragment <code>model-ALS-ultra.frag</code> and <code>secondary_lights.frag</code><br />
** Inherits uniforms from <code>model-combined-deferred</code> << <code>model-combined</code><br />
* <code>dirt-runway.eff</code>:<br />
** Inherits properties from <code>crop</code> << <code>terrain-default</code><br />
** Adds program shaders (technique 2)<br />
*** Fragment <code>drunway-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 2)<br />
* <code>model-combined.eff</code>:<br />
** Inherits properties from <code>model-default</code><br />
** Adds program shaders (technique 4)<br />
*** Fragment <code>model-ALS-ultra.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 4)<br />
* <code>model-default.eff</code>:<br />
** Adds properties<br />
** Adds program shaders (technique 5)<br />
*** Fragment <code>model-ALS-base.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 5)<br />
* <code>runway.eff</code>:<br />
** Inherits properties from terrain-default<br />
** Adds program shaders (technique 2)<br />
*** Fragment <code>runway-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 2)<br />
* <code>terrain-default.eff</code>:<br />
** Adds properties<br />
** Adds program shaders (technique 3)<br />
*** Fragment <code>terrain-ALS-ultra.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 3)<br />
* <code>tree.eff</code>:<br />
** Adds properties<br />
** Adds program shaders (technique 4 and 5)<br />
*** Fragment <code>tree-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 4 and 5)<br />
* <code>urban.eff</code>:<br />
** Inherits properties from <code>terrain-default</code><br />
** Adds program shaders (technique 1 and 2)<br />
*** Fragment <code>urban-ALS.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 1 and 2)<br />
* <code>water.eff</code>:<br />
** Inherits properties from <code>terrain-default</code><br />
** Adds program shaders (technique 1)<br />
*** Fragment <code>water-ALS-high.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 1)<br />
* <code>water-inland.eff</code>:<br />
** Inherits properties from <code>terrain-default</code><br />
** Adds program shaders (technique 2)<br />
*** Fragment <code>water-ALS-high.frag</code> and <code>secondary_lights.frag</code><br />
** Adds uniforms (technique 2)<br />
<br />
== General comments from forum discussion ==<br />
{{cquote|In principle, we always do the same steps in the fragment shaders to determine the color of a pixel:<br />
<br />
* texel color - what is the base color of the pixel fully lit and unfogged<br />
* lighting - how is this color changed by the light falling onto that pixel, usually the relation is something like fragColor equals texel * light<br />
* fogging - how much is the color hidden by haze, usually the relation is something like gl_FragColor equals mix(fragColor, hazeColor, transmission_factor);<br />
what is displayed on the screen in the end is whatever gl_FragColor is set to<br />
<br />
But the location where this happens isn't always obvious - often (part) of the light is computed in the vertex shader already, in which case it typically enters the fragment shader as gl_Color.<br />
<br />
So, the lighting equation in tree-haze.frag is indeed<br />
vec4 fragColor equals vec4 (gl_Color.xyz,1.0) * texel;<br />
and your change to the light should happen just before that. But you can't do<br />
gl_Color.rgb equals gl_Color.rgb + my_light;<br />
because gl_Color.rgb is a varying variable type, and you can't assign new values to them inside the shader, so you need to either make a new variable or just do<br />
vec4 fragColor equals vec4 ((gl_Color.rgb + my_light),1.0) * texel;<br />
(note that color.rgb is the same as color.xyz, GLSL doesn't really care which convention you use, but I took a few months to learn that, so early code by myself often uses xyz indexing convention for color vectors as well).<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=15#p220075 <br />
|title=ALS landing lights<br />
|author=Thorsten Renk |date= Tue Oct 07, 2014 12:04 -0700}}</ref>|Thorsten Renk}}<br />
<br />
{{cquote|An effect is a container for a series of techniques which are all the possible things you could do with some object.<br />
<br />
The <predicate> section inside each effect determines which of the techniques we actually run. Typically the predicate section contains conditionals on a) rendering framework properties b) OpenGL extension support and c) quality level properties. The renderer searches the effects from lowest to highest technique number and uses the first one that fits the bill (which is why high quality levels precede low quality levels).<br />
<br />
The rendering itself is specified as <pass> - each pass runs the renderer over the whole scene. We may sometimes make a quick first pass to fill the depth buffer or a stencil buffer, but usually we render with a single pass.<br />
<br />
Techniques may not involve a shader at all, for instance 12 in terrain-default is a pure fixed pipeline fallback technique, but all the rendering you're interested in use a shader, which means they have a <program> section which determines what actual code is supposed to run.<br />
<br />
If you run a shader, that needs parameters specified as <uniform>, and textures which need to be assigned to a texture unit _and_ be declared as a uniform sampler.<br />
<br />
In addition, each technique contains a host of parameter configuring the fixed pipeline elements, like alpha tests before the fragment stage, or depth buffer writing/reading, alpha blending,... you can ignore them on the first go.<br />
<br />
So if you want to look at which shader code is executed when you call the water effect at a certain quality level, you need to work your way through the predicate sections of the techniques from lowest to highest till you find the one that matches, and then look into the program section of that technique.<br />
<br />
Now, to make matters more complicated, all the parameters and textures that are assigned to uniforms and texture units in the techniques need to be declared and linked to properties were applicable in the <parameters> section heading each effect declaration. So a texture you want to use has to appear three times - in the parameters section heading the effect, inside the technique assigned to a texture unit and assigned to a uniform sampler.<br />
<br />
Now, inheritance moves all the declared parameters and techniques from one effect to the one inheriting. In the case of water, that means the technique is actually _not_ inherited because terrain-default.eff doesn't contain a technique 1 at all, but the general <parameters> section is inherited. So you don't need to declare the additions to <parameters> again, but you do need to make the changes to the <programs> and the <uniform> sections.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=15#p220152 <br />
|title=ALS landing lights<br />
|author=Thorsten Renk |date= Wed Oct 08, 2014 1:58 -0700}}</ref>|Thorsten Renk}}<br />
<br />
{{cquote|At low water shader quality, water isn't rendered separately from the terrain, i.e. it runs via terrain-default.eff - since you modified that to allow light, light works for water out of the box.<br />
At high water slider, the techniques in water.eff kick in, and only then do you need to modify the specific water shader code. Now, the peculiar thing about water is that there are two effects (water.eff and water_inland.eff) sharing the same shader code (but calling it with somewhat different parameters). So the function not found error was presumably caused by you modifying water.eff whereas the water you were seeing was initiated by water_inland.eff, and in that effect, the secondary_lights.frag wasn't initially in the program section. So if you alter the water shader code, you need to modify two effect files rather than one to pass the right parameters and access the functions you need.<br />
<br />
..........<br />
..........<br />
<br />
Adding them _after_ fogging, isn't what you want - you'll see that if visibility is <100 m, everything will go black at night, because fog color is black at night, so finalColor.rgb of a heavily fogged object will also be black, and then when you light it up, you multiply your light value with black and it'll be black. Or, if you add the light value (which you should only do if the object you add it to is a light color itself), then you'll get a featureless grey. You want to add light after texel color and before fogging.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=30#p220216 <br />
|title=ALS landing lights<br />
|author=Thorsten Renk |date= Wed Oct 08, 2014 11:19 -0700}}</ref>|Thorsten Renk}}<br />
<br />
{{cquote|So, in old times when rendering textures was slow and complicated, we rendered objects with monochromatic surface colors. Then the (schematic) lighting equation (without specular, and the sum of ambient and diffuse already computed) was<br />
<br />
visibleColor.rgb equals objectColor.rgb * light.rgb + objectEmissive.rgb<br />
<br />
Now, we have textures and so we get<br />
<br />
visibleColor.rgb equals objectColor.rgb * texel.rgb * light.rgb + objectEmissive.rgb + lightMapTexel.rgb<br />
<br />
Since we can have the full color information in the texture, objectColor.rgb is usually (1.0,1.0,1.0) because the info is redundant. But if you don't use a texture, of course objectColor.rgb has the actual color value (incidentially, I think we shouldn't texture with monochromatic surfaces at all, it creates a jarring visual impression which can be cured by using even a small texture...)<br />
<br />
But if you do, the rendering pipeline is set up to compute color.rgb equals objectColor * light.rgb in the vertex shader, so the equation we have in the fragment shader is something like<br />
<br />
visibleColor.rgb equals color.rgb * texel.rgb + objectEmissive.rgb + lightMapTexel.rgb<br />
<br />
and if we add a secondary light like<br />
<br />
visibleColor.rgb equals (color.rgb + secLight.rgb) * texel.rgb<br />
<br />
it of course can never recover the color information, because color.rgb is zero at night since you multiplied the actual color with zero sunlight and the texel doesn't carry information for an untextured object.<br />
<br />
Since the secondary light is in screen coordinates, it can't appear in the vertex shader, so the solution would be to pass the actual color and light rather than their product to the fragment shader. Which is expensive, because we need another varying vec3, and varying variable types fill memory and need to be computed an interpolated per vertex/per fragment - which is why I'm not sure whether we shouldn't accept the loss of the color...<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=45#p220321 <br />
|title=ALS landing lights<br />
|author=Thorsten Renk |date= Sat Oct 11, 2014 1:28 -0700}}</ref>|Thorsten Renk}}<br />
<br />
{{cquote|Inheritance works like this:<br />
<br />
The base effect has a list of things<br />
<br />
A1 B1 C1 D1<br />
<br />
The second effect inherits 1 but just declares C2 and E2, so then the list is<br />
<br />
A1 B1 C2 D1 E2<br />
<br />
The third effect inherits from 2 and declares A3, so then the list is<br />
<br />
A3 B1 C2 D1 E2<br />
<br />
whereas if the third effect would inherit from 1, then the list would be<br />
<br />
A3 B1 C1 D1<br />
<br />
So if already present, inheritance overrides, if not present it adds. I suspect that's why programs need to be indexed, so they they override and don't add...<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=45#p220403 <br />
|title=ALS landing lights<br />
|author=Thorsten Renk |date= Sat Oct 11, 2014 11:33 -0700}}</ref>|Thorsten Renk}}<br />
<br />
<references/><br />
<br />
[[Category:Howto|Shader Programming in FlightGear]]<br />
[[Category:Shader development]]<br />
[[Category: Core developer documentation]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Howto_talk:Shader_programming_in_FlightGear&diff=107428Howto talk:Shader programming in FlightGear2017-03-19T02:12:07Z<p>Flug: /* Topics to be covered */</p>
<hr />
<div>= Todo =<br />
* shader primitives/elements <br />
* explain shaders available in FlightGear<br />
<br />
= Topics to be covered =<br />
* what is a vertex<br />
* what is a fragment<br />
* the OGL rendering pipeline<br />
* swizzling/component access<br />
* operators<br />
* ctors<br />
* branching (if, else, loops)<br />
* FlightGear effects<br />
<br />
Practical programming tips, where errors are reported, etc.</div>Flughttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_February_2017&diff=107290FlightGear Newsletter February 20172017-03-07T02:47:18Z<p>Flug: /* JSBSim Sopwith Camel Updated to Ver. 2.0alpha */</p>
<hr />
<div>{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter January 2017]].}}<br />
<br />
{{Newsletter-header|February 2017}}<br />
<div style="border-bottom: 3px double #BBB"><br />
{| width="100%" |<br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Development news}}<br><br />
{{Newsletter-cover-header|In the hangar}}<br><br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Scenery Corner}}<br><br />
{{Newsletter-cover-header|Community News}}<br><br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Contributing}}<br><br />
[[#Translators required|Translators required]]<br><br />
[[#FlightGear logos|FlightGear logos]]<br><br />
[[#Screenshots|Screenshots]]<br><br />
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small><br />
|}</div><br />
== Development news ==<br />
=== FlightGear v2017.1 released ===<br />
The FlightGear development team is delighted to announce the v2017.1 "Bergen" release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include: Accurate buildings from OpenStreetMap, voice synthesis of tutorial instructions, improved rendering of Earth from orbit, and a more realistic blackout/redout system.<br />
<br />
=== Bombable Add-on: Update 4.6 now available - Full Compatibility with FG 2016.x.x & 2017.x.x ===<br />
The [[Bombable]] add-on--which converts FlightGear into full fledged combat flight simulator, with realistic weapons, dogfighting, bombing, and strafing--either with AI opponents or via multiplayer, has been updated to version 4.6.<br />
<br />
The new version of Bombable brings full compatibility with FlightGear through 2016.4.4.<br />
<br />
Download the Bombable add-on, or find out more, on the [[Bombable|Bombable wiki page]]<br />
<br />
[[File:Bombable-Camel-vs-Camel.png|framed|center|The Bombable Add-On features aircraft from World War I through modern times]]<br />
<br />
== In the hangar ==<br />
<br />
=== JSBSim Sopwith Camel Updated to Ver. 2.0alpha ===<br />
Flug's JSBSim Sopwith Camel has undergone major revisions and the 2.0gamma version of the aircraft has been released. <br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=4&t=19584&start=45#p305653 More information and download the JSBSim Camel here]<br />
<br />
[[File:real-sopwith-camel-1917-vs-flightgear-2017.png|framed|center|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
<br />
==== Major features of the new release: ====<br />
* '''Greatly updated/refined flight dynamics model''', even more closely adhering to the historically reported behavior of the aircraft<br />
* '''Crashes modeled''' - parts break, dust, explosions, etc. <br />
[[File:JSBSim-camel-bad-crash.jpg|framed|right|JSBSim Camel: Bad Crash]]<br />
* '''Completely new sound design''' - hear when you are rolling, landing gear makes contact, wind buffeting etc<br />
* '''Ground interactions''' - tail drag, wheels, wingtip, etc dragging surface kicks up dust<br />
* '''Water landings''' - you can successfully ditch in water, kicks up spray & other effects<br />
* '''Friction effects and bumps''' - you can land or take off on almost any suitable land, but you will notice increased drag from e.g. tall grass, bumps, and you might break a landing gear if you're not careful. Use ''''n' key to nudge the aircraft''' if you get stuck in a hole or ditch.<br />
* '''New Inspect Aircraft View''' - based on Walk View, this allows you to easily get various views near the aircraft<br />
<br />
[http://www.youtube.com/watch?v=QOXPFoV-JTI View a video demo of an early version of some of these features.]<br />
<br />
==== Things to try in your new JSBSim Camel: ====<br />
* '''Crash landing''' <br />
[[File:JSBSim-camel-ground-effects.jpg|300px|thumbnail|right|JSBSim Camel Ground Contact Effects]]<br />
* '''Hard landing'''<br />
* '''Over-g/overspeed'''<br />
* '''Inverted flight'''<br />
* '''Land in a random field''', try to take off again (use 'n' as needed for nudges, and '''menu Camel/Repair''' as needed--because you WILL need it).<br />
* '''Water landing''' - try both a controlled ditch and hard landing <br />
* '''Scrape a wing''' on takeoff or landing<br />
* '''Nose over''' on takeoff or landing (menu Camel/Repair afterwards . . . )<br />
* '''Take off, land and do touch-and-go landings''' while viewing from external view (Model View or Inspect Aircraft View)<br />
* '''How fast can you do a level 360 degree turn''' left or right? Real Camel pilots could do it 8-10 seconds level flight to level flight.<br />
* '''Spins and recovery''' - try powered stall and unpowered stall in level flight; pulling into a stall at 45, 60, and 90 degree bank angles, etc. How about a stall from inverted flight? Can you figure out how to enter a flat inverted spin from inverted flight--as reported by WWI Camel pilots?<br />
* Take offs and landings in '''calm weather, headwind, crosswind, tailwind'''. Can you successfully take off and land in a strong crosswind, for example?<br />
* Take offs and landings in calm weather, headwind, crosswind, tailwind. Can you successfully take off and land in a strong crosswind, for example?<br />
* '''Loops, barrel rolls, split-s turns, wingovers, hammerheads,''' other typical acrobatic and fighter maneuvers. What happens if you pull the stick back moderately or hard at the top of a loop?<br />
[[File:JSBSim-camel-nosing-over2.jpg|framed|left|JSBSIM Camel: Nosing Over]]<br />
* Install the '''[http://wiki.flightgear.org/Bombable Bombable] add-on and dogfight''' other Camels, Spads, Fokkers, etc.<br />
* Or '''dogfight via multiplayer''' with [http://wiki.flightgear.org/Bombable Bombable]<br />
<br />
Note that the JSBSim version of the Camel included in the pack is the primary emphasis of this release. The JSBSim FDM and effects mentioned above are the point of the release. The aircraft model is identical to the FG Camel, so you won't see anything new there! And the release also includes a YASim version of the Camel that is Bombable compatible but doesn't include any other special effects or FDM development of the type outlined above.<br />
<br />
In short, to see fly the *JSBSim Camel*. In the FG aircraft menu, look for *Sopwith Camel 1F.1 (JSBSim, Historically Accurate FDM & Weapons, Bombable-compatible, ver 2.0)*.<br />
<br />
Version 2.0gamma is a pre-release and may be refined further (based on user feedback) before the final release. However, the release is fully functional and generally well tested.<br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=4&t=19584&start=45#p305653 More information and download the JSBSim Camel here]<br />
[[File:JSBSim-camel-tumbling2.jpg|728x576px|framed|center|JSBSim Camel: Tumbling to a stop]]<br />
<br />
== Scenery corner ==<br />
== Community News ==<br />
== Contributing ==<br />
=== Translators required ===<br />
{|<br />
| [[File:en.gif]]<br />
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].<br />
|-<br />
| [[File:fr.gif]]<br />
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].<br />
|-<br />
| [[File:de.gif]]<br />
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.<br />
|-<br />
| [[File:nl.gif]]<br />
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].<br />
|-<br />
| [[File:es.gif]]<br />
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].<br />
|-<br />
| [[File:cat.gif]]<br />
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].<br />
|-<br />
| [[File:pt.gif]]<br />
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].<br />
|}<br />
<br />
=== FlightGear logos ===<br />
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.<br />
<br />
=== Screenshots ===<br />
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].<br />
<br />
==== Screenshot of the Month ====<br />
FlightGear's Screenshot of the Month February 2017 is ''Having some fun in the Basque Country'' by xcvb!<br />
[[File:Cap-10 in Basque Country.jpg|900px|center|TITLE]]<br />
<br />
If you want to participate in the screenshot contest of March 2017, you can submit your candidate to [https://forum.flightgear.org/viewtopic.php?f=19&t=31783 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=31783#p306280 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of March.<br />
<br />
[[Category:FlightGear Newsletter|2017 02]]<br />
[[Category:Changes after 2017.1]]<br />
[[de:FlightGear Newsletter Februar 2017]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_February_2017&diff=107289FlightGear Newsletter February 20172017-03-07T02:46:35Z<p>Flug: /* Bombable Add-on: Update 4.6 now available - Full Compatibility with FG 2016.x.x */</p>
<hr />
<div>{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter January 2017]].}}<br />
<br />
{{Newsletter-header|February 2017}}<br />
<div style="border-bottom: 3px double #BBB"><br />
{| width="100%" |<br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Development news}}<br><br />
{{Newsletter-cover-header|In the hangar}}<br><br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Scenery Corner}}<br><br />
{{Newsletter-cover-header|Community News}}<br><br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Contributing}}<br><br />
[[#Translators required|Translators required]]<br><br />
[[#FlightGear logos|FlightGear logos]]<br><br />
[[#Screenshots|Screenshots]]<br><br />
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small><br />
|}</div><br />
== Development news ==<br />
=== FlightGear v2017.1 released ===<br />
The FlightGear development team is delighted to announce the v2017.1 "Bergen" release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include: Accurate buildings from OpenStreetMap, voice synthesis of tutorial instructions, improved rendering of Earth from orbit, and a more realistic blackout/redout system.<br />
<br />
=== Bombable Add-on: Update 4.6 now available - Full Compatibility with FG 2016.x.x & 2017.x.x ===<br />
The [[Bombable]] add-on--which converts FlightGear into full fledged combat flight simulator, with realistic weapons, dogfighting, bombing, and strafing--either with AI opponents or via multiplayer, has been updated to version 4.6.<br />
<br />
The new version of Bombable brings full compatibility with FlightGear through 2016.4.4.<br />
<br />
Download the Bombable add-on, or find out more, on the [[Bombable|Bombable wiki page]]<br />
<br />
[[File:Bombable-Camel-vs-Camel.png|framed|center|The Bombable Add-On features aircraft from World War I through modern times]]<br />
<br />
== In the hangar ==<br />
<br />
=== JSBSim Sopwith Camel Updated to Ver. 2.0alpha ===<br />
Flug's JSBSim Sopwith Camel has undergone major revisions and the 2.0alpha version of the aircraft has been released. <br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=4&t=19584&start=45#p305653 More information and download the JSBSim Camel here]<br />
<br />
[[File:real-sopwith-camel-1917-vs-flightgear-2017.png|framed|center|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
<br />
==== Major features of the new release: ====<br />
* '''Greatly updated/refined flight dynamics model''', even more closely adhering to the historically reported behavior of the aircraft<br />
* '''Crashes modeled''' - parts break, dust, explosions, etc. <br />
[[File:JSBSim-camel-bad-crash.jpg|framed|right|JSBSim Camel: Bad Crash]]<br />
* '''Completely new sound design''' - hear when you are rolling, landing gear makes contact, wind buffeting etc<br />
* '''Ground interactions''' - tail drag, wheels, wingtip, etc dragging surface kicks up dust<br />
* '''Water landings''' - you can successfully ditch in water, kicks up spray & other effects<br />
* '''Friction effects and bumps''' - you can land or take off on almost any suitable land, but you will notice increased drag from e.g. tall grass, bumps, and you might break a landing gear if you're not careful. Use ''''n' key to nudge the aircraft''' if you get stuck in a hole or ditch.<br />
* '''New Inspect Aircraft View''' - based on Walk View, this allows you to easily get various views near the aircraft<br />
<br />
[http://www.youtube.com/watch?v=QOXPFoV-JTI View a video demo of an early version of some of these features.]<br />
<br />
==== Things to try in your new JSBSim Camel: ====<br />
* '''Crash landing''' <br />
[[File:JSBSim-camel-ground-effects.jpg|300px|thumbnail|right|JSBSim Camel Ground Contact Effects]]<br />
* '''Hard landing'''<br />
* '''Over-g/overspeed'''<br />
* '''Inverted flight'''<br />
* '''Land in a random field''', try to take off again (use 'n' as needed for nudges, and '''menu Camel/Repair''' as needed--because you WILL need it).<br />
* '''Water landing''' - try both a controlled ditch and hard landing <br />
* '''Scrape a wing''' on takeoff or landing<br />
* '''Nose over''' on takeoff or landing (menu Camel/Repair afterwards . . . )<br />
* '''Take off, land and do touch-and-go landings''' while viewing from external view (Model View or Inspect Aircraft View)<br />
* '''How fast can you do a level 360 degree turn''' left or right? Real Camel pilots could do it 8-10 seconds level flight to level flight.<br />
* '''Spins and recovery''' - try powered stall and unpowered stall in level flight; pulling into a stall at 45, 60, and 90 degree bank angles, etc. How about a stall from inverted flight? Can you figure out how to enter a flat inverted spin from inverted flight--as reported by WWI Camel pilots?<br />
* Take offs and landings in '''calm weather, headwind, crosswind, tailwind'''. Can you successfully take off and land in a strong crosswind, for example?<br />
* Take offs and landings in calm weather, headwind, crosswind, tailwind. Can you successfully take off and land in a strong crosswind, for example?<br />
* '''Loops, barrel rolls, split-s turns, wingovers, hammerheads,''' other typical acrobatic and fighter maneuvers. What happens if you pull the stick back moderately or hard at the top of a loop?<br />
[[File:JSBSim-camel-nosing-over2.jpg|framed|left|JSBSIM Camel: Nosing Over]]<br />
* Install the '''[http://wiki.flightgear.org/Bombable Bombable] add-on and dogfight''' other Camels, Spads, Fokkers, etc.<br />
* Or '''dogfight via multiplayer''' with [http://wiki.flightgear.org/Bombable Bombable]<br />
<br />
Note that the JSBSim version of the Camel included in the pack is the primary emphasis of this release. The JSBSim FDM and effects mentioned above are the point of the release. The aircraft model is identical to the FG Camel, so you won't see anything new there! And the release also includes a YASim version of the Camel that is Bombable compatible but doesn't include any other special effects or FDM development of the type outlined above.<br />
<br />
In short, to see fly the *JSBSim Camel*. In the FG aircraft menu, look for *Sopwith Camel 1F.1 (JSBSim, Historically Accurate FDM & Weapons, Bombable-compatible, ver 2.0)*.<br />
<br />
Version 2.0alpha is a pre-release and may be refined further (based on user feedback) before the final release. However, the release is fully functional and generally well tested.<br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=4&t=19584&start=45#p305653 More information and download the JSBSim Camel here]<br />
[[File:JSBSim-camel-tumbling2.jpg|728x576px|framed|center|JSBSim Camel: Tumbling to a stop]]<br />
<br />
== Scenery corner ==<br />
== Community News ==<br />
== Contributing ==<br />
=== Translators required ===<br />
{|<br />
| [[File:en.gif]]<br />
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].<br />
|-<br />
| [[File:fr.gif]]<br />
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].<br />
|-<br />
| [[File:de.gif]]<br />
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.<br />
|-<br />
| [[File:nl.gif]]<br />
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].<br />
|-<br />
| [[File:es.gif]]<br />
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].<br />
|-<br />
| [[File:cat.gif]]<br />
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].<br />
|-<br />
| [[File:pt.gif]]<br />
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].<br />
|}<br />
<br />
=== FlightGear logos ===<br />
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.<br />
<br />
=== Screenshots ===<br />
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].<br />
<br />
==== Screenshot of the Month ====<br />
FlightGear's Screenshot of the Month February 2017 is ''Having some fun in the Basque Country'' by xcvb!<br />
[[File:Cap-10 in Basque Country.jpg|900px|center|TITLE]]<br />
<br />
If you want to participate in the screenshot contest of March 2017, you can submit your candidate to [https://forum.flightgear.org/viewtopic.php?f=19&t=31783 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=31783#p306280 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of March.<br />
<br />
[[Category:FlightGear Newsletter|2017 02]]<br />
[[Category:Changes after 2017.1]]<br />
[[de:FlightGear Newsletter Februar 2017]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=JSBSim_Thrusters&diff=107241JSBSim Thrusters2017-03-02T22:37:57Z<p>Flug: /* Parameter definitions */</p>
<hr />
<div>'''[[JSBSim]]''' uses '''thruster''' models to convert engine power into aerodynamic forces. The following table shows which engine-thruster combinations work.<br />
<br />
{| class="wikitable" style="text-align:center;border: none; background: none;"<br />
|-<br />
! colspan="2" rowspan="2" style="border: none; background: none;" | <br />
! colspan=4 | Thrusters<br />
|-<br />
| style="width:60px;" | [[JSBSim Thrusters#FGDirect|Direct]] <br />
| style="width:60px;" | [[JSBSim Thrusters#FGNozzle|Nozzle]]<br />
| style="width:60px;" | [[JSBSim Thrusters#FGPropeller|Propeller]]<br />
| style="width:60px;" | [[JSBSim Thrusters#FGRotor|Rotor]] <br />
|-<br />
! rowspan=5 | Engines<br />
|[[JSBSim Engines#FGElectric|Electric]]<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|-<br />
|[[JSBSim Engines#FGPiston|Piston]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|-<br />
|[[JSBSim Engines#FGRocket|Rocket]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" | <br />
|-<br />
|[[JSBSim Engines#FGTurbine|Turbine]]<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
|-<br />
|[[JSBSim Engines#FGTurboProp|TurboProp]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|}<br />
<br />
== FGDirect ==<br />
Thrust is computed directly by the engine, the direct thruster file is a stub. Currently FGTurbine engines use this thruster and it can also be used with FGElectric.<br />
<br />
=== Configuration file format ===<br />
This is the complete configuration file. Copy and paste into your 'direct.xml' file.<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?> <br />
<direct name="Direct"><br />
</direct> <br />
</syntaxhighlight><br />
<br />
=== Notes ===<br />
* The direct thruster creates a property called propulsion/engine[#]/reverser-angle-rad<br />
* "Reverser angle" as used here is a way to manipulate the thrust vector, along the thrust axis ONLY, during run time. This should not be confused with a thrust vectoring nozzle. The angle is defined in radians, and is used thus: Final_thrust = cosine( reverser_angle ) * unmodified_thrust. Therefore a reverser angle of 0 results in no change, and a reverser angle of 3.14 (pi) results in a completely reversed thrust vector. An angle of 1.57 (pi/2) results in no thrust at all<br />
<br />
== FGNozzle ==<br />
FGNozzle is for the FGRocket engine.<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?> <br />
<nozzle name="{string}"><br />
<area unit="{FT2 | M2 | IN2}"> {number} </area><br />
</nozzle><br />
</syntaxhighlight><br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
|area<br />
|Nozzle area at the exit plane.<br />
|}<br />
<br />
=== Notes ===<br />
* All parameters MUST be specified.<br />
* The area specified times the sea level pressure (2117 lbf/ft^2) is the amount thrust is reduced at sea level<br />
<br />
== FGPropeller ==<br />
FGPropeller models a propeller given the tabular data for Ct and Cp, indexed by the advance ratio "J".<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<!-- Sense goes in the parent tag --><br />
<sense> {1 | -1} </sense> <br />
<?xml version="1.0"?> <br />
<propeller name="{string}"><br />
<ixx> {number} </ixx><br />
<diameter unit="IN"> {number} </diameter><br />
<numblades> {number} </numblades><br />
<gearratio> {number} </gearratio><br />
<minpitch> {number} </minpitch><br />
<maxpitch> {number} </maxpitch><br />
<minrpm> {number} </minrpm><br />
<maxrpm> {number} </maxrpm><br />
<constspeed> {number} </constspeed><br />
<reversepitch> {number} </reversepitch><br />
<p_factor> {number} </p_factor><br />
<ct_factor> {number} </ct_factor><br />
<cp_factor> {number} </cp_factor><br />
<br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="C_POWER" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
</propeller><br />
</syntaxhighlight><br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
| valign="top" | ixx<br />
|Propeller rotational inertia. This can be english units, slug & feet^2:<br />
<br />
<ixx unit="SLUG*FT2"> 8.95 </ixx><br />
<br />
Or in metric units, kg * meters^2:<br />
<br />
<ixx unit="KG*M2"> 12.14 </ixx><br />
<br />
For a thin rod of mass m (kg) and diameter D (meters) spinning about its center, the formula is m*D^2/12. See the [http://en.wikipedia.org/wiki/List_of_moments_of_inertia Moments of inertia reference page] and [http://www.engineeringtoolbox.com/moment-inertia-torque-d_913.html list of conversion factors for different units for moment of inertia].)<br />
|-<br />
|diameter<br />
|Propeller disk diameter.<br />
|-<br />
|numblades<br />
|Number of blades.<br />
|-<br />
|gearratio<br />
|Ratio of (engine rpm) / (prop rpm).<br />
|-<br />
|minpitch<br />
|Minimum blade pitch angle.<br />
|-<br />
|maxpitch<br />
|Maximum blade pitch angle.<br />
|-<br />
|minrpm<br />
|Minimum rpm target for constant speed propeller.<br />
|-<br />
|maxrpm<br />
|Maximum rpm target for constant speed propeller.<br />
|-<br />
|constspeed<br />
|1 = constant speed mode, 0 = manual pitch mode. <br />
|-<br />
|reversepitch<br />
|Blade pitch angle for reverse.<br />
|-<br />
|sense<br />
|Direction of rotation (1= clockwise as viewed from rear, -1=counter-clockwise as viewed from rear). Sense is specified in the parent tag of the propeller. ''See [[JSBSim_Thrusters#Sense_bug_affecting_gyroscopic_moment|important note below]] regarding a JSBSim bug affecting sense and the direction of the resulting gyroscopic moment.''<br />
|-<br />
|p_factor<br />
|P factor.<br />
|-<br />
|ct_factor<br />
|A multiplier for the coefficients of thrust (multiplies the dependent variable in the C_THRUST table by this factor).<br />
|-<br />
|cp_factor<br />
|A multiplier for the coefficients of power (multiplies the dependent variable in the C_POWER table by this factor).<br />
|}<br />
<br />
=== C_THRUST and C_POWER tables ===<br />
The C_THRUST and C_POWER tables are required. <br />
<br />
The independent variable for both tables is [http://en.wikipedia.org/wiki/Advance_ratio Advance Ratio] (J). The dependent variable is the coefficient of thrust (Ct) for the C_THRUST and the coefficient of power (Cp) for C_POWER. <br />
<br />
For variable pitch propellers, it is possible to give a two-dimensional table, showing Ct and Cp for different J and different pitch angles of the propeller. See example below.<br />
<br />
[http://www.mh-aerotools.de/airfoils/pylonprops_1.htm Propellors for F3D Models explains the theory] and has [http://www.mh-aerotools.de/airfoils/pylonprops_2.htm formulas] and [http://www.mh-aerotools.de/airfoils/pylonprops_3.htm many graphs] showing the relationship between J, Ct, and Cp.<br />
<br />
Relevant formulas relating the variables in the tables (and metric system units):<br />
<br />
* Thrust: T = Ct * rho * n^2 * D^4<br />
* Power: P = Cp * rho * n^3 * D^5)<br />
* Advance Ratio: J = v/(n*D)<br />
* Efficiency: eta = Ct/Cp * v/(n*D) (or equivalently, eta = Ct/Cp * J )<br />
<br />
In the formulas<br />
* Ct = coefficient of thrust<br />
* Cp = coefficient of power<br />
* v = true velocity of aircraft (m/s)<br />
* D = diameter of propeller disk (m)<br />
* n = rotations per second (1/s) (note RPS, not RPM)<br />
* rho = density of air (kg/m^3)<br />
* P = power (W)<br />
* T = thrust (N)<br />
<br />
For a typical propeller, both Cp and Ct are downward sloping curves that reach 0 when J is somewhere in the range 0-4 (depending on blade angle and other factors). Cp and Ct can be negative; this indicates the drag induced by the prop when the airspeed is relatively fast compared with prop RPM. At higher pitch angles Ct may have a positive slope or be flat in the lower J range.<br />
<br />
Ct/Cp gives the efficiency (eta), and propeller shape and general design give each propeller a distinctive [http://www.mh-aerotools.de/airfoils/pylonprops_3.htm efficiency curve]. For fixed-pitch propellers, the propeller is generally designed to reach peak efficiency either at climb velocity & RPM, cruise velocity and RPM, or some compromise between the two. [http://en.wikipedia.org/wiki/Controllable_pitch_propeller Variable pitch propellers] and [http://en.wikipedia.org/wiki/Constant_speed_propeller constant speed propellers] bring different factors into play.<br />
<br />
Note that several of the values mentioned above can be viewed while FG is running, in the property tree under /fdm/jsbsim/propulsion/engine. This is useful for seeing how the settings and tables play out under various conditions and fine-tuning the settings.<br />
<br />
==== Sample C_THRUST and C_POWER tables ====<br />
These example tables are from FlightGear's C172P aircraft:<br />
<br />
<syntaxhighlight lang="xml"><br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
0.0 0.068<br />
0.1 0.068<br />
0.2 0.067<br />
0.3 0.066<br />
0.4 0.064<br />
0.5 0.062<br />
0.6 0.059<br />
0.7 0.054<br />
0.8 0.043<br />
0.9 0.031<br />
1.0 0.019<br />
1.1 0.008<br />
1.2 -0.001<br />
1.3 -0.008<br />
1.4 -0.019<br />
1.5 -0.029<br />
1.6 -0.040<br />
1.7 -0.050<br />
1.8 -0.057<br />
1.9 -0.061<br />
2.0 -0.064<br />
2.1 -0.066<br />
2.2 -0.067<br />
2.3 -0.068<br />
5.0 -0.068<br />
</tableData><br />
</table><br />
<br />
<table name="C_POWER" type = "internal"><br />
<tableData><br />
0.0 0.0580<br />
0.1 0.0620<br />
0.2 0.0600<br />
0.3 0.0580<br />
0.4 0.0520<br />
0.5 0.0457<br />
0.6 0.0436<br />
0.7 0.0420<br />
0.8 0.0372<br />
0.9 0.0299<br />
1.0 0.0202<br />
1.1 0.0111<br />
1.2 0.0075<br />
1.3 0.0111<br />
1.4 0.0202<br />
1.5 0.0280<br />
1.6 0.0346<br />
1.7 0.0389<br />
1.8 0.0421<br />
1.9 0.0436<br />
2.0 0.0445<br />
2.1 0.0445<br />
2.2 0.0442<br />
2.3 0.0431<br />
2.4 0.0424<br />
5.0 0.0413<br />
</tableData><br />
</table><br />
</syntaxhighlight><br />
<br />
Example of table for variable pitch propeller ([http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg32187.html source]):<br />
<br />
<syntaxhighlight lang="xml"><br />
<!-- thrust coefficient as a function of advance ratio and blade angle --><br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
-10 0 15 25 35 45 55 65 90<br />
-0.2 -0.0734 0.0413 0.1503 0.1842 0.2030 0.2142 0.1974 0.1691 0.0000<br />
0.0 -0.1090 0.0000 0.1503 0.1842 0.2030 0.2162 0.2021 0.1691 0.0000<br />
0.2 -0.1222 -0.0376 0.1297 0.1804 0.2001 0.2162 0.2021 0.1691 0.0000<br />
0.4 -0.1222 -0.0873 0.0977 0.1786 0.1963 0.2142 0.2021 0.1691 0.0000<br />
0.6 -0.1222 -0.1222 0.0517 0.1607 0.1879 0.2087 0.1992 0.1691 0.0000<br />
0.8 -0.1222 -0.1222 0.0029 0.1203 0.1824 0.2012 0.1992 0.1691 0.0000<br />
1.0 -0.1222 -0.1222 -0.0489 0.0734 0.1748 0.1908 0.1974 0.1691 0.0000<br />
1.2 -0.1222 -0.1222 -0.1006 0.0226 0.1437 0.1842 0.1974 0.1691 0.0000<br />
1.4 -0.1222 -0.1222 -0.1222 -0.0329 0.1034 0.1813 0.1936 0.1691 0.0000<br />
1.6 -0.1222 -0.1222 -0.1222 -0.0836 0.0564 0.1748 0.1899 0.1691 0.0000<br />
1.8 -0.1222 -0.1222 -0.1222 -0.1222 0.0095 0.1503 0.1842 0.1691 0.0000<br />
2.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.0376 0.1174 0.1834 0.1691 0.0000<br />
2.2 -0.1222 -0.1222 -0.1222 -0.1222 -0.0846 0.0846 0.1804 0.1691 0.0000<br />
2.4 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0451 0.1473 0.1691 0.0000<br />
2.6 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0057 0.0932 0.1503 0.0000<br />
2.8 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0338 0.0610 0.1222 0.0000<br />
3.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0734 0.0320 0.0940 0.0000<br />
3.2 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1128 0.0029 0.0658 0.0000<br />
3.4 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0263 0.0376 0.0000<br />
3.6 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0555 0.0095 0.0000<br />
3.8 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0846 -0.0188 0.0000<br />
4.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1137 -0.0471 0.0000<br />
6.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0000<br />
</tableData><br />
</table><br />
<br />
<!-- power coefficient as a function of advance ratio and blade angle --><br />
<table name="C_POWER" type="internal"><br />
<tableData><br />
-10 0 15 25 35 45 55 65 90<br />
-0.2 0.0108 0.0215 0.0753 0.1710 0.2949 0.4194 0.4839 0.5355 0.5355<br />
0.0 0.0430 0.0108 0.0645 0.1594 0.2820 0.4194 0.4859 0.5355 0.5355<br />
0.2 0.0613 0.0172 0.0624 0.1484 0.2697 0.4194 0.4859 0.5355 0.5355<br />
0.4 0.0826 0.0376 0.0537 0.1368 0.2562 0.4194 0.4859 0.5355 0.5355<br />
0.6 0.1013 0.0570 0.0355 0.1271 0.2400 0.4110 0.4839 0.5355 0.5355<br />
0.8 0.1194 0.0763 0.0108 0.1078 0.2258 0.3923 0.4839 0.5355 0.5355<br />
1.0 0.1374 0.0948 0.0108 0.0755 0.2129 0.3723 0.4820 0.5355 0.5355<br />
1.2 0.1561 0.0758 -0.0355 0.0290 0.1884 0.3568 0.4788 0.5355 0.5355<br />
1.4 0.1742 0.1310 -0.0536 -0.0215 0.1452 0.3516 0.4729 0.5355 0.5355<br />
1.6 0.1923 0.1497 -0.0626 -0.0645 0.0916 0.3420 0.4626 0.5162 0.5355<br />
1.8 0.2110 0.1678 -0.0645 -0.1078 0.0269 0.3033 0.4484 0.5052 0.5355<br />
2.0 0.2291 0.1858 -0.0826 -0.1503 -0.0323 0.2581 0.4271 0.4949 0.5355<br />
2.2 0.2471 0.2045 -0.1013 -0.1936 -0.0968 0.2097 0.4142 0.4729 0.5355<br />
2.4 0.2658 0.2226 -0.1194 -0.2368 -0.1613 0.1497 0.4020 0.4626 0.5355<br />
2.6 0.2839 0.2407 -0.1374 -0.2794 -0.2045 0.0626 0.3923 0.4465 0.5355<br />
2.8 0.3020 0.2594 -0.1561 -0.3226 -0.2452 -0.0213 0.3839 0.4407 0.5355<br />
3.0 0.3207 0.2774 -0.1742 -0.3658 -0.2903 -0.0968 0.3710 0.4407 0.5355<br />
3.2 0.3387 0.2955 -0.1923 -0.4084 -0.3336 -0.1723 0.3471 0.4304 0.5355<br />
3.4 0.3568 0.3142 -0.2110 -0.4517 -0.3762 -0.2471 0.2691 0.4194 0.5355<br />
3.6 0.3755 0.3323 -0.2291 -0.4949 -0.4194 -0.3226 0.1890 0.4084 0.5355<br />
3.8 0.3936 0.3504 -0.2471 -0.5355 -0.4626 -0.3981 0.1052 0.3955 0.5355<br />
4.0 0.4117 0.3691 -0.2658 -0.5355 -0.5355 -0.4729 0.0213 0.3658 0.5355<br />
6.0 0.5355 0.5355 -0.5355 -0.5355 -0.5355 -0.5355 -0.5355 -0.3226 0.5355<br />
</tableData><br />
</table><br />
<br />
<!-- thrust effects of helical tip Mach --><br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 0.8<br />
</tableData><br />
</table><br />
<br />
<!-- power-required effects of helical tip Mach --><br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 1.8<br />
2.00 1.4<br />
</tableData><br />
</table><br />
<syntaxhighlight lang="xml"><br />
<br />
=== CT_MACH and CP_MACH ===<br />
The CT_MACH and CP_MACH tables are optional. They apply a factor to Ct and Cp based on the helical tip Mach. The CP_MACH table models the [http://en.wikipedia.org/wiki/Drag_divergence_Mach_number Drag Divergence Mach Number] for the propeller airfoil. The CT_MACH table models the thrust reduction.<br />
<br />
Examples:<br />
<br />
<syntaxhighlight lang="xml"><br />
<br />
<!-- thrust effects of helical tip Mach --><br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 0.8<br />
</tableData><br />
</table><br />
<br />
<!-- power-required effects of helical tip Mach --><br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 1.8<br />
2.00 1.4<br />
</tableData><br />
</table><br />
</syntaxhighlight><br />
<br />
=== Sense ===<br />
Sense is the direction of rotation. 1=clockwise (typically as seen from rear of aircraft or the cockpit of a typical front-propeller aircraft, but this may vary depending on how you have set up the coordinate system for your aircraft) and -1 is counter-clockwise.<br />
<br />
The sense tag goes in the parent tag of the thruster, ie, in the <propulsion><thruster> section which is typically in the main JSBSim XML file. Example:<br />
<br />
<syntaxhighlight lang="xml"><br />
<propulsion><br />
<engine file="Clerget9B"><br />
<location unit="IN"><br />
<x> 12 </x><br />
<y> 0 </y><br />
<z> 0 </z><br />
</location><br />
<orient unit="DEG"><br />
<roll> 0 </roll><br />
<pitch> 0 </pitch><br />
<yaw> 0 </yaw><br />
</orient><br />
<feed>0</feed><br />
<thruster file="CamelProp"><br />
'''<sense>1</sense>'''<br />
<location unit="IN"><br />
<x> 0 </x><br />
<y> 0 </y><br />
<z> 0 </z><br />
</location><br />
<orient unit="DEG"><br />
<roll> 0 </roll><br />
<pitch> 0 </pitch><br />
<yaw> 0 </yaw><br />
</orient><br />
</thruster><br />
</engine><br />
<tank type="FUEL"><br />
<location unit="IN"><br />
<x> 60 </x><br />
<y> 0 </y><br />
<z> -5.62 </z><br />
</location><br />
<capacity unit="LBS">133.6</capacity><br />
<contents unit="LBS">133.6</contents><br />
</tank><br />
</propulsion><br />
</syntaxhighlight><br />
<br />
====Sense bug affecting gyroscopic moment====<br />
Prior to about 2015--and continuing in current JSBSim and FlightGear versions unless you take the corrective steps outlined below--a JSBSim bug cause the gyroscopic moment of the propeller to be reversed.<br />
<br />
To fix this bug and get the correct sign for your gyroscopic effect, you must add version="1.1" (or higher--any version greater than 1.0 should work) to your propeller definition, as shown in this example:<br />
<br />
<syntaxhighlight><br />
<propeller name="prop" version="1.1"><br />
<!-- propeller definition --><br />
</propeller><br />
</syntaxhighlight><br />
<br />
The bug with the sign of gyroscopic effect and the fix are outlined under [https://sourceforge.net/p/jsbsim/bugs/110/ JSBSim Bug #110].<br />
<br />
For most aircraft and engine/propeller systems the gyroscopic effect is fairly subtle and thus the bug is difficult to detect. But for some aircraft, such as small, light, rotary-engined WWI-era aircraft, the gyroscopic effect is very noticeable, and the reverse in direction of the effect created by the bug is very noticeable as well.<br />
<br />
=== Starter speed (for piston engines) ===<br />
There is a somewhat complex relationship among the power coefficient, the maxhp, and idlerpm. Both maxhp and idlerpm are set in the engine xml file.<br />
<br />
The power of the starter motor is equal to 0.4*sqrt(maxhp). The minimum RPM needed to start the engine is 80% of the idlerpm. The greater the power coefficient (for J near 0), the more power the propeller will require to spin when starting the engine with the aircraft at rest.<br />
<br />
If your propeller will not spin fast enough to start, you can try some combination of:<br />
<br />
* Open the throttle. Pulling a partial vacuum in the intake manifold takes some power.<br />
* Increase maxhp (increases the power of the starter motor)<br />
* Decrease idlerpm (decreases the minimum RPM needed to start the engine)<br />
* Decrease the power coefficient in the C_POWER table, for values of J close to (or equal to) 0. This will reduce the amount of power it takes for the propeller to spin at a given RPM where J is close to 0 (which is the typical situation when starting the engine and the aircraft is at a dead stop).<br />
<br />
You can open the property tree and watch the value of J (/fdm/jsbsim/propulsion/engines/advance-ratio) to get an idea of which values you need to change in the C_POWER table.<br />
<br />
''' Code is in FG 2.8 to independently control the power of the piston starter motor, to include battery effects. '''<br />
starter-torque (fgfs 2.8) is a value specifying the zero RPM torque in lb*ft the starter motor provides. Current default value is 40% of the maximum horsepower value.<br />
starter-rpm (fgfs 2.8) is a value specifying the maximum RPM the unloaded starter motor can achieve. Loads placed on the engine by the propeller and throttle will further limit RPM achieved in practice. Peak starter power is achieved at 1/2 starter-rpm. At 1/2 starter-rpm torque is 1/2 starter-torque. Peak power can be calculated by the standard formula HP=(Torque*RPM)/5252<br />
<br />
=== Development tips ===<br />
* If you open the property tree browser within FG to /fdm/jsbsim/propulsion/engines you can see a number of helpful variables in action, including RPM, horsepower, advance ratio, thrust coefficient, and others.<br />
<br />
=== References ===<br />
* Barnes W. McCormick, "Aerodynamics, Aeronautics, and Flight Mechanics", Wiley & Sons, 1979 ISBN 0-471-03032-5<br />
* Edwin Hartman, David Biermann, "The Aerodynamic Characteristics of Full Scale Propellers Having 2, 3, and 4 Blades of Clark Y and R.A.F. 6 Airfoil Sections", NACA Report TN-640, 1938 (?)<br />
* Various NACA Technical Notes and Reports<br />
<br />
== FGRotor ==<br />
FGRotor models a helicopter rotor.<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<!-- Sense goes in the parent tag --><br />
<sense> {1 | 0 | -1} </sense><br />
<?xml version="1.0"?> <br />
<rotor name="{string}"><br />
<diameter unit="{LENGTH}"> {number} </diameter><br />
<numblades> {number} </numblades><br />
<gearratio> {number} </gearratio><br />
<nominalrpm> {number} </nominalrpm><br />
<minrpm> {number} </minrpm><br />
<maxrpm> {number} </maxrpm> <br />
<chord unit="{LENGTH}"> {number} </chord><br />
<liftcurveslope Xunit="1/RAD"> {number} </liftcurveslope><br />
<twist unit="{ANGLE}"> {number} </twist><br />
<hingeoffset unit="{LENGTH}"> {number} </hingeoffset><br />
<flappingmoment unit="{MOMENT}"> {number} </flappingmoment><br />
<massmoment Xunit="SLUG*FT"> {number} </massmoment><br />
<polarmoment unit="{MOMENT}"> {number} </polarmoment><br />
<inflowlag> {number} </inflowlag><br />
<tiplossfactor> {number} </tiplossfactor><br />
<maxbrakepower unit="{POWER}"> {number} </maxbrakepower><br />
<br />
<controlmap> {MAIN|TAIL|TANDEM} </controlmap><br />
<ExternalRPM> {number} </ExternalRPM><br />
<br />
<groundeffectexp> {number} </groundeffectexp><br />
<groundeffectshift unit="{LENGTH}"> {number} </groundeffectshift><br />
</rotor><br />
</syntaxhighlight><br />
<br />
* LENGTH means any of the supported units, same for ANGLE and MOMENT.X unit-attributes are a hint for currently unsupported units, so values must be provided accordingly.<br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
|diameter<br />
|Rotor disk diameter (2x R).<br />
|-<br />
|numblades<br />
|Number of blades (b).<br />
|-<br />
|gearratio<br />
|Ratio of (engine rpm) / (rotor rpm), usually > 1.<br />
|-<br />
|nominalrpm<br />
|RPM at which the rotor usally operates. <br />
|-<br />
|minrpm<br />
|Lowest RPM used in the model, optional and defaults to 1.<br />
|-<br />
|maxrpm<br />
|Largest RPM used in the model, optional and defaults to 2 x nominalrpm. <br />
|-<br />
|chord<br />
|Blade chord, (c).<br />
|-<br />
|liftcurveslope<br />
|Slope of curve of section lift against section angle of attack, per rad (a).<br />
|-<br />
|twist<br />
|Blade twist from root to tip, (theta_1).<br />
|-<br />
|hingeoffset<br />
|Rotor flapping-hinge offset (e).<br />
|-<br />
|flappingmoment<br />
|Flapping moment of inertia (I_b).<br />
|-<br />
|massmoment<br />
|Blade mass moment. Mass of a single blade times the blade's cg-distance from the hub, optional.<br />
|-<br />
|polarmoment<br />
|Moment of inertia for the whole rotor disk, optional.<br />
|-<br />
|inflowlag<br />
|Rotor inflow time constant, sec. Smaller values yield to quicker responses (typical values for main rotor: 0.1 - 0.2 s).<br />
|-<br />
|tiplossfactor<br />
|Tip-loss factor. The Blade fraction that produces lift. Value usually ranges between 0.95 - 1.0, optional (B).<br />
|-<br />
|maxbrakepower<br />
|Rotor brake, 20-30 hp should work for a mid size helicopter.<br />
|-<br />
|controlmap<br />
|Defines the control inputs used (see notes).<br />
|-<br />
|ExternalRPM<br />
|Links the rotor to another rotor, or an user controllable property.<br />
<br />
Experimental properties<br />
|-<br />
|groundeffectexp<br />
|Exponent for ground effect approximation. Values usually range from 0.04 for large rotors to 0.1 for smaller ones. As a rule of thumb the effect vanishes at a height 2-3 times the rotor diameter. formula used: exp ( - groundeffectexp * (height+groundeffectshift) ) Omitting or setting to 0.0 disables the effect calculation.<br />
|-<br />
|groundeffectshift<br />
|Further adjustment of ground effect, approx. hub height or slightly above. <br />
|}<br />
<br />
=== Notes ===<br />
==== Controls ====<br />
The behavior of the rotor is controlled/influenced by following inputs.<br />
* The power provided by the engine. This is handled by the regular engine controls.<br />
* The collective control input. This is read from the <tt>fdm</tt> property <tt>propulsion/engine[x]/collective-ctrl-rad</tt>. See below for tail rotor<br />
* The lateral cyclic input. Read from <tt>propulsion/engine[x]/lateral-ctrl-rad</tt>.<br />
* The longitudinal cyclic input. Read from <tt>propulsion/engine[x]/longitudinal-ctrl-rad</tt>.<br />
** The tail collective (aka antitorque, aka pedal) control input. Read from <tt>propulsion/engine[x]/antitorque-ctrl-rad</tt> or <tt>propulsion/engine[x]/tail-collective-ctrl-rad</tt>. <br />
<br />
==== Tail/tandem rotor ====<br />
Providing '''&lt;ExternalRPM&gt; 0 &lt;/ExternalRPM&gt;''' the tail rotor's RPM is linked to to the main (=first, =0) rotor, and specifying '''&lt;controlmap&gt; TAIL &lt;/controlmap&gt;''' tells this rotor to read the collective input from '''propulsion/engine[1]/antitorque-ctrl-rad''' (The TAIL-map ignores lateral and longitudinal input). The rotor needs to be attached to a dummy engine, e.g. an 1HP electrical engine. A tandem rotor is setup analogous.<br />
<br />
==== Sense ====<br />
The 'sense' parameter from the thruster is interpreted as follows, sense=1 means counter clockwise rotation of the main rotor, as viewed from above. This is as a far as I know more popular than clockwise rotation, which is defined by setting sense to -1. Concerning coaxial designs - by setting 'sense' to zero, a Kamov-style rotor is modeled (i.e. the rotor produces no torque).<br />
<br />
==== Engine issues ====<br />
In order to keep the rotor speed constant, use of a RPM-Governor system is encouraged (see examples).<br />
<br />
==== Development hints ====<br />
Setting '''&lt;ExternalRPM&gt; -1 &lt;/ExternalRPM&gt;''' the rotor's RPM is controlled by the '''propulsion/engine[x]/x-rpm-dict''' property. This feature can be useful when developing a FDM.<br />
<br />
==== Properties ====<br />
The rotor model creates the following properties:<br />
<br />
{| class="prettytable"<br />
|-<br />
|propulsion/engine[#]/rotor-rpm<br />
|RPMs of the rotor<br />
|-<br />
|propulsion/engine[#]/engine-rpm<br />
|RPMs of the Engine, as seen from this rotor.<br />
|-<br />
|propulsion/engine[#]/a0-rad<br />
|Rotor's coning angle in radians<br />
|-<br />
|propulsion/engine[#]/a1-rad<br />
|Longitudinal flapping angle with respect to the rotor shaft in radians<br />
|-<br />
|propulsion/engine[#]/b1-rad<br />
|Lateral flapping angle with respect to the rotor shaft in radians<br />
|-<br />
|propulsion/engine[#]/inflow-ratio<br />
| Lambda or λ<br />
|-<br />
|propulsion/engine[#]/advance-ratio<br />
|the tip-speed (aka advance) ratio Mu or μ<br />
|-<br />
|propulsion/engine[#]/induced-inflow-ratio<br />
| Nu or ν<br />
|-<br />
|propulsion/engine[#]/vi-fps<br />
|Induced Velocity in feet per second<br />
|-<br />
|propulsion/engine[#]/thrust-coefficient<br />
|<br />
|-<br />
|propulsion/engine[#]/torque-lbsft<br />
| Rotor torque in pound * feet<br />
|-<br />
|propulsion/engine[#]/theta-downwash-rad<br />
|Down wash θ angle - positive values point forward (given a horizontal spinning rotor) in radians<br />
|-<br />
|propulsion/engine[#]/phi-downwash-rad<br />
|Down wash Φ angle - positive values point leftward (given a horizontal spinning rotor) in radians<br />
|-<br />
|propulsion/engine[#]/groundeffect-scale-norm<br />
|<br />
|}<br />
<br />
(Control Inputs)<br />
{| class="prettytable"<br />
|-<br />
|propulsion/engine[#]/antitorque-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/tail-collective-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/lateral-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/longitudinal-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/collective-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/lateral-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/longitudinal-ctrl-rad<br />
|<br />
|}<br />
<br />
=== References ===<br />
{| class="prettytable"<br />
|-<br />
|SH79<br />
|Shaugnessy, J. D., Deaux, Thomas N., and Yenni, Kenneth R., "Development and Validation of a Piloted Simulation of a Helicopter and External Sling Load", NASA TP-1285, 1979.<br />
|-<br />
|BA41<br />
|Bailey,F.J.,Jr., "A Simplified Theoretical Method of Determining the Characteristics of a Lifting Rotor in Forward Flight", NACA Rep.716, 1941<br />
|-<br />
|AM50<br />
|Amer, Kenneth B.,"Theory of Helicopter Damping in Pitch or Roll and a Comparison With Flight Measurements", NACA TN-2136, 1950.<br />
|-<br />
|TA77<br />
|Talbot, Peter D., Corliss, Lloyd D., "A Mathematical Force and Moment Model of a UH-1H Helicopter for Flight Dynamics Simulations", NASA TM-73,254, 1977.<br />
|-<br />
|GE49<br />
|Gessow, Alfred, Amer, Kenneth B. "An Introduction to the Physical Aspects of Helicopter Stability", NACA TN-1982, 1949.<br />
|}<br />
<br />
{{JSBSim}}</div>Flughttps://wiki.flightgear.org/w/index.php?title=JSBSim_Thrusters&diff=107240JSBSim Thrusters2017-03-02T22:37:23Z<p>Flug: /* Parameter definitions */ link to info about the 'sense bug'</p>
<hr />
<div>'''[[JSBSim]]''' uses '''thruster''' models to convert engine power into aerodynamic forces. The following table shows which engine-thruster combinations work.<br />
<br />
{| class="wikitable" style="text-align:center;border: none; background: none;"<br />
|-<br />
! colspan="2" rowspan="2" style="border: none; background: none;" | <br />
! colspan=4 | Thrusters<br />
|-<br />
| style="width:60px;" | [[JSBSim Thrusters#FGDirect|Direct]] <br />
| style="width:60px;" | [[JSBSim Thrusters#FGNozzle|Nozzle]]<br />
| style="width:60px;" | [[JSBSim Thrusters#FGPropeller|Propeller]]<br />
| style="width:60px;" | [[JSBSim Thrusters#FGRotor|Rotor]] <br />
|-<br />
! rowspan=5 | Engines<br />
|[[JSBSim Engines#FGElectric|Electric]]<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|-<br />
|[[JSBSim Engines#FGPiston|Piston]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|-<br />
|[[JSBSim Engines#FGRocket|Rocket]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" | <br />
|-<br />
|[[JSBSim Engines#FGTurbine|Turbine]]<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
|-<br />
|[[JSBSim Engines#FGTurboProp|TurboProp]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|}<br />
<br />
== FGDirect ==<br />
Thrust is computed directly by the engine, the direct thruster file is a stub. Currently FGTurbine engines use this thruster and it can also be used with FGElectric.<br />
<br />
=== Configuration file format ===<br />
This is the complete configuration file. Copy and paste into your 'direct.xml' file.<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?> <br />
<direct name="Direct"><br />
</direct> <br />
</syntaxhighlight><br />
<br />
=== Notes ===<br />
* The direct thruster creates a property called propulsion/engine[#]/reverser-angle-rad<br />
* "Reverser angle" as used here is a way to manipulate the thrust vector, along the thrust axis ONLY, during run time. This should not be confused with a thrust vectoring nozzle. The angle is defined in radians, and is used thus: Final_thrust = cosine( reverser_angle ) * unmodified_thrust. Therefore a reverser angle of 0 results in no change, and a reverser angle of 3.14 (pi) results in a completely reversed thrust vector. An angle of 1.57 (pi/2) results in no thrust at all<br />
<br />
== FGNozzle ==<br />
FGNozzle is for the FGRocket engine.<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?> <br />
<nozzle name="{string}"><br />
<area unit="{FT2 | M2 | IN2}"> {number} </area><br />
</nozzle><br />
</syntaxhighlight><br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
|area<br />
|Nozzle area at the exit plane.<br />
|}<br />
<br />
=== Notes ===<br />
* All parameters MUST be specified.<br />
* The area specified times the sea level pressure (2117 lbf/ft^2) is the amount thrust is reduced at sea level<br />
<br />
== FGPropeller ==<br />
FGPropeller models a propeller given the tabular data for Ct and Cp, indexed by the advance ratio "J".<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<!-- Sense goes in the parent tag --><br />
<sense> {1 | -1} </sense> <br />
<?xml version="1.0"?> <br />
<propeller name="{string}"><br />
<ixx> {number} </ixx><br />
<diameter unit="IN"> {number} </diameter><br />
<numblades> {number} </numblades><br />
<gearratio> {number} </gearratio><br />
<minpitch> {number} </minpitch><br />
<maxpitch> {number} </maxpitch><br />
<minrpm> {number} </minrpm><br />
<maxrpm> {number} </maxrpm><br />
<constspeed> {number} </constspeed><br />
<reversepitch> {number} </reversepitch><br />
<p_factor> {number} </p_factor><br />
<ct_factor> {number} </ct_factor><br />
<cp_factor> {number} </cp_factor><br />
<br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="C_POWER" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
</propeller><br />
</syntaxhighlight><br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
| valign="top" | ixx<br />
|Propeller rotational inertia. This can be english units, slug & feet^2:<br />
<br />
<ixx unit="SLUG*FT2"> 8.95 </ixx><br />
<br />
Or in metric units, kg * meters^2:<br />
<br />
<ixx unit="KG*M2"> 12.14 </ixx><br />
<br />
For a thin rod of mass m (kg) and diameter D (meters) spinning about its center, the formula is m*D^2/12. See the [http://en.wikipedia.org/wiki/List_of_moments_of_inertia Moments of inertia reference page] and [http://www.engineeringtoolbox.com/moment-inertia-torque-d_913.html list of conversion factors for different units for moment of inertia].)<br />
|-<br />
|diameter<br />
|Propeller disk diameter.<br />
|-<br />
|numblades<br />
|Number of blades.<br />
|-<br />
|gearratio<br />
|Ratio of (engine rpm) / (prop rpm).<br />
|-<br />
|minpitch<br />
|Minimum blade pitch angle.<br />
|-<br />
|maxpitch<br />
|Maximum blade pitch angle.<br />
|-<br />
|minrpm<br />
|Minimum rpm target for constant speed propeller.<br />
|-<br />
|maxrpm<br />
|Maximum rpm target for constant speed propeller.<br />
|-<br />
|constspeed<br />
|1 = constant speed mode, 0 = manual pitch mode. <br />
|-<br />
|reversepitch<br />
|Blade pitch angle for reverse.<br />
|-<br />
|sense<br />
|Direction of rotation (1= clockwise as viewed from rear, -1=counter-clockwise as viewed from rear). Sense is specified in the parent tag of the propeller. ''See [[JSBSim_Thrusters#Sense_bug_affecting_gyroscopic_moment|important note below]] regarding a JSBSim bug affecting sense and the resulting gyroscopic moment.''<br />
|-<br />
|p_factor<br />
|P factor.<br />
|-<br />
|ct_factor<br />
|A multiplier for the coefficients of thrust (multiplies the dependent variable in the C_THRUST table by this factor).<br />
|-<br />
|cp_factor<br />
|A multiplier for the coefficients of power (multiplies the dependent variable in the C_POWER table by this factor).<br />
|}<br />
<br />
=== C_THRUST and C_POWER tables ===<br />
The C_THRUST and C_POWER tables are required. <br />
<br />
The independent variable for both tables is [http://en.wikipedia.org/wiki/Advance_ratio Advance Ratio] (J). The dependent variable is the coefficient of thrust (Ct) for the C_THRUST and the coefficient of power (Cp) for C_POWER. <br />
<br />
For variable pitch propellers, it is possible to give a two-dimensional table, showing Ct and Cp for different J and different pitch angles of the propeller. See example below.<br />
<br />
[http://www.mh-aerotools.de/airfoils/pylonprops_1.htm Propellors for F3D Models explains the theory] and has [http://www.mh-aerotools.de/airfoils/pylonprops_2.htm formulas] and [http://www.mh-aerotools.de/airfoils/pylonprops_3.htm many graphs] showing the relationship between J, Ct, and Cp.<br />
<br />
Relevant formulas relating the variables in the tables (and metric system units):<br />
<br />
* Thrust: T = Ct * rho * n^2 * D^4<br />
* Power: P = Cp * rho * n^3 * D^5)<br />
* Advance Ratio: J = v/(n*D)<br />
* Efficiency: eta = Ct/Cp * v/(n*D) (or equivalently, eta = Ct/Cp * J )<br />
<br />
In the formulas<br />
* Ct = coefficient of thrust<br />
* Cp = coefficient of power<br />
* v = true velocity of aircraft (m/s)<br />
* D = diameter of propeller disk (m)<br />
* n = rotations per second (1/s) (note RPS, not RPM)<br />
* rho = density of air (kg/m^3)<br />
* P = power (W)<br />
* T = thrust (N)<br />
<br />
For a typical propeller, both Cp and Ct are downward sloping curves that reach 0 when J is somewhere in the range 0-4 (depending on blade angle and other factors). Cp and Ct can be negative; this indicates the drag induced by the prop when the airspeed is relatively fast compared with prop RPM. At higher pitch angles Ct may have a positive slope or be flat in the lower J range.<br />
<br />
Ct/Cp gives the efficiency (eta), and propeller shape and general design give each propeller a distinctive [http://www.mh-aerotools.de/airfoils/pylonprops_3.htm efficiency curve]. For fixed-pitch propellers, the propeller is generally designed to reach peak efficiency either at climb velocity & RPM, cruise velocity and RPM, or some compromise between the two. [http://en.wikipedia.org/wiki/Controllable_pitch_propeller Variable pitch propellers] and [http://en.wikipedia.org/wiki/Constant_speed_propeller constant speed propellers] bring different factors into play.<br />
<br />
Note that several of the values mentioned above can be viewed while FG is running, in the property tree under /fdm/jsbsim/propulsion/engine. This is useful for seeing how the settings and tables play out under various conditions and fine-tuning the settings.<br />
<br />
==== Sample C_THRUST and C_POWER tables ====<br />
These example tables are from FlightGear's C172P aircraft:<br />
<br />
<syntaxhighlight lang="xml"><br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
0.0 0.068<br />
0.1 0.068<br />
0.2 0.067<br />
0.3 0.066<br />
0.4 0.064<br />
0.5 0.062<br />
0.6 0.059<br />
0.7 0.054<br />
0.8 0.043<br />
0.9 0.031<br />
1.0 0.019<br />
1.1 0.008<br />
1.2 -0.001<br />
1.3 -0.008<br />
1.4 -0.019<br />
1.5 -0.029<br />
1.6 -0.040<br />
1.7 -0.050<br />
1.8 -0.057<br />
1.9 -0.061<br />
2.0 -0.064<br />
2.1 -0.066<br />
2.2 -0.067<br />
2.3 -0.068<br />
5.0 -0.068<br />
</tableData><br />
</table><br />
<br />
<table name="C_POWER" type = "internal"><br />
<tableData><br />
0.0 0.0580<br />
0.1 0.0620<br />
0.2 0.0600<br />
0.3 0.0580<br />
0.4 0.0520<br />
0.5 0.0457<br />
0.6 0.0436<br />
0.7 0.0420<br />
0.8 0.0372<br />
0.9 0.0299<br />
1.0 0.0202<br />
1.1 0.0111<br />
1.2 0.0075<br />
1.3 0.0111<br />
1.4 0.0202<br />
1.5 0.0280<br />
1.6 0.0346<br />
1.7 0.0389<br />
1.8 0.0421<br />
1.9 0.0436<br />
2.0 0.0445<br />
2.1 0.0445<br />
2.2 0.0442<br />
2.3 0.0431<br />
2.4 0.0424<br />
5.0 0.0413<br />
</tableData><br />
</table><br />
</syntaxhighlight><br />
<br />
Example of table for variable pitch propeller ([http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg32187.html source]):<br />
<br />
<syntaxhighlight lang="xml"><br />
<!-- thrust coefficient as a function of advance ratio and blade angle --><br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
-10 0 15 25 35 45 55 65 90<br />
-0.2 -0.0734 0.0413 0.1503 0.1842 0.2030 0.2142 0.1974 0.1691 0.0000<br />
0.0 -0.1090 0.0000 0.1503 0.1842 0.2030 0.2162 0.2021 0.1691 0.0000<br />
0.2 -0.1222 -0.0376 0.1297 0.1804 0.2001 0.2162 0.2021 0.1691 0.0000<br />
0.4 -0.1222 -0.0873 0.0977 0.1786 0.1963 0.2142 0.2021 0.1691 0.0000<br />
0.6 -0.1222 -0.1222 0.0517 0.1607 0.1879 0.2087 0.1992 0.1691 0.0000<br />
0.8 -0.1222 -0.1222 0.0029 0.1203 0.1824 0.2012 0.1992 0.1691 0.0000<br />
1.0 -0.1222 -0.1222 -0.0489 0.0734 0.1748 0.1908 0.1974 0.1691 0.0000<br />
1.2 -0.1222 -0.1222 -0.1006 0.0226 0.1437 0.1842 0.1974 0.1691 0.0000<br />
1.4 -0.1222 -0.1222 -0.1222 -0.0329 0.1034 0.1813 0.1936 0.1691 0.0000<br />
1.6 -0.1222 -0.1222 -0.1222 -0.0836 0.0564 0.1748 0.1899 0.1691 0.0000<br />
1.8 -0.1222 -0.1222 -0.1222 -0.1222 0.0095 0.1503 0.1842 0.1691 0.0000<br />
2.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.0376 0.1174 0.1834 0.1691 0.0000<br />
2.2 -0.1222 -0.1222 -0.1222 -0.1222 -0.0846 0.0846 0.1804 0.1691 0.0000<br />
2.4 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0451 0.1473 0.1691 0.0000<br />
2.6 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0057 0.0932 0.1503 0.0000<br />
2.8 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0338 0.0610 0.1222 0.0000<br />
3.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0734 0.0320 0.0940 0.0000<br />
3.2 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1128 0.0029 0.0658 0.0000<br />
3.4 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0263 0.0376 0.0000<br />
3.6 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0555 0.0095 0.0000<br />
3.8 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0846 -0.0188 0.0000<br />
4.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1137 -0.0471 0.0000<br />
6.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0000<br />
</tableData><br />
</table><br />
<br />
<!-- power coefficient as a function of advance ratio and blade angle --><br />
<table name="C_POWER" type="internal"><br />
<tableData><br />
-10 0 15 25 35 45 55 65 90<br />
-0.2 0.0108 0.0215 0.0753 0.1710 0.2949 0.4194 0.4839 0.5355 0.5355<br />
0.0 0.0430 0.0108 0.0645 0.1594 0.2820 0.4194 0.4859 0.5355 0.5355<br />
0.2 0.0613 0.0172 0.0624 0.1484 0.2697 0.4194 0.4859 0.5355 0.5355<br />
0.4 0.0826 0.0376 0.0537 0.1368 0.2562 0.4194 0.4859 0.5355 0.5355<br />
0.6 0.1013 0.0570 0.0355 0.1271 0.2400 0.4110 0.4839 0.5355 0.5355<br />
0.8 0.1194 0.0763 0.0108 0.1078 0.2258 0.3923 0.4839 0.5355 0.5355<br />
1.0 0.1374 0.0948 0.0108 0.0755 0.2129 0.3723 0.4820 0.5355 0.5355<br />
1.2 0.1561 0.0758 -0.0355 0.0290 0.1884 0.3568 0.4788 0.5355 0.5355<br />
1.4 0.1742 0.1310 -0.0536 -0.0215 0.1452 0.3516 0.4729 0.5355 0.5355<br />
1.6 0.1923 0.1497 -0.0626 -0.0645 0.0916 0.3420 0.4626 0.5162 0.5355<br />
1.8 0.2110 0.1678 -0.0645 -0.1078 0.0269 0.3033 0.4484 0.5052 0.5355<br />
2.0 0.2291 0.1858 -0.0826 -0.1503 -0.0323 0.2581 0.4271 0.4949 0.5355<br />
2.2 0.2471 0.2045 -0.1013 -0.1936 -0.0968 0.2097 0.4142 0.4729 0.5355<br />
2.4 0.2658 0.2226 -0.1194 -0.2368 -0.1613 0.1497 0.4020 0.4626 0.5355<br />
2.6 0.2839 0.2407 -0.1374 -0.2794 -0.2045 0.0626 0.3923 0.4465 0.5355<br />
2.8 0.3020 0.2594 -0.1561 -0.3226 -0.2452 -0.0213 0.3839 0.4407 0.5355<br />
3.0 0.3207 0.2774 -0.1742 -0.3658 -0.2903 -0.0968 0.3710 0.4407 0.5355<br />
3.2 0.3387 0.2955 -0.1923 -0.4084 -0.3336 -0.1723 0.3471 0.4304 0.5355<br />
3.4 0.3568 0.3142 -0.2110 -0.4517 -0.3762 -0.2471 0.2691 0.4194 0.5355<br />
3.6 0.3755 0.3323 -0.2291 -0.4949 -0.4194 -0.3226 0.1890 0.4084 0.5355<br />
3.8 0.3936 0.3504 -0.2471 -0.5355 -0.4626 -0.3981 0.1052 0.3955 0.5355<br />
4.0 0.4117 0.3691 -0.2658 -0.5355 -0.5355 -0.4729 0.0213 0.3658 0.5355<br />
6.0 0.5355 0.5355 -0.5355 -0.5355 -0.5355 -0.5355 -0.5355 -0.3226 0.5355<br />
</tableData><br />
</table><br />
<br />
<!-- thrust effects of helical tip Mach --><br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 0.8<br />
</tableData><br />
</table><br />
<br />
<!-- power-required effects of helical tip Mach --><br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 1.8<br />
2.00 1.4<br />
</tableData><br />
</table><br />
<syntaxhighlight lang="xml"><br />
<br />
=== CT_MACH and CP_MACH ===<br />
The CT_MACH and CP_MACH tables are optional. They apply a factor to Ct and Cp based on the helical tip Mach. The CP_MACH table models the [http://en.wikipedia.org/wiki/Drag_divergence_Mach_number Drag Divergence Mach Number] for the propeller airfoil. The CT_MACH table models the thrust reduction.<br />
<br />
Examples:<br />
<br />
<syntaxhighlight lang="xml"><br />
<br />
<!-- thrust effects of helical tip Mach --><br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 0.8<br />
</tableData><br />
</table><br />
<br />
<!-- power-required effects of helical tip Mach --><br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 1.8<br />
2.00 1.4<br />
</tableData><br />
</table><br />
</syntaxhighlight><br />
<br />
=== Sense ===<br />
Sense is the direction of rotation. 1=clockwise (typically as seen from rear of aircraft or the cockpit of a typical front-propeller aircraft, but this may vary depending on how you have set up the coordinate system for your aircraft) and -1 is counter-clockwise.<br />
<br />
The sense tag goes in the parent tag of the thruster, ie, in the <propulsion><thruster> section which is typically in the main JSBSim XML file. Example:<br />
<br />
<syntaxhighlight lang="xml"><br />
<propulsion><br />
<engine file="Clerget9B"><br />
<location unit="IN"><br />
<x> 12 </x><br />
<y> 0 </y><br />
<z> 0 </z><br />
</location><br />
<orient unit="DEG"><br />
<roll> 0 </roll><br />
<pitch> 0 </pitch><br />
<yaw> 0 </yaw><br />
</orient><br />
<feed>0</feed><br />
<thruster file="CamelProp"><br />
'''<sense>1</sense>'''<br />
<location unit="IN"><br />
<x> 0 </x><br />
<y> 0 </y><br />
<z> 0 </z><br />
</location><br />
<orient unit="DEG"><br />
<roll> 0 </roll><br />
<pitch> 0 </pitch><br />
<yaw> 0 </yaw><br />
</orient><br />
</thruster><br />
</engine><br />
<tank type="FUEL"><br />
<location unit="IN"><br />
<x> 60 </x><br />
<y> 0 </y><br />
<z> -5.62 </z><br />
</location><br />
<capacity unit="LBS">133.6</capacity><br />
<contents unit="LBS">133.6</contents><br />
</tank><br />
</propulsion><br />
</syntaxhighlight><br />
<br />
====Sense bug affecting gyroscopic moment====<br />
Prior to about 2015--and continuing in current JSBSim and FlightGear versions unless you take the corrective steps outlined below--a JSBSim bug cause the gyroscopic moment of the propeller to be reversed.<br />
<br />
To fix this bug and get the correct sign for your gyroscopic effect, you must add version="1.1" (or higher--any version greater than 1.0 should work) to your propeller definition, as shown in this example:<br />
<br />
<syntaxhighlight><br />
<propeller name="prop" version="1.1"><br />
<!-- propeller definition --><br />
</propeller><br />
</syntaxhighlight><br />
<br />
The bug with the sign of gyroscopic effect and the fix are outlined under [https://sourceforge.net/p/jsbsim/bugs/110/ JSBSim Bug #110].<br />
<br />
For most aircraft and engine/propeller systems the gyroscopic effect is fairly subtle and thus the bug is difficult to detect. But for some aircraft, such as small, light, rotary-engined WWI-era aircraft, the gyroscopic effect is very noticeable, and the reverse in direction of the effect created by the bug is very noticeable as well.<br />
<br />
=== Starter speed (for piston engines) ===<br />
There is a somewhat complex relationship among the power coefficient, the maxhp, and idlerpm. Both maxhp and idlerpm are set in the engine xml file.<br />
<br />
The power of the starter motor is equal to 0.4*sqrt(maxhp). The minimum RPM needed to start the engine is 80% of the idlerpm. The greater the power coefficient (for J near 0), the more power the propeller will require to spin when starting the engine with the aircraft at rest.<br />
<br />
If your propeller will not spin fast enough to start, you can try some combination of:<br />
<br />
* Open the throttle. Pulling a partial vacuum in the intake manifold takes some power.<br />
* Increase maxhp (increases the power of the starter motor)<br />
* Decrease idlerpm (decreases the minimum RPM needed to start the engine)<br />
* Decrease the power coefficient in the C_POWER table, for values of J close to (or equal to) 0. This will reduce the amount of power it takes for the propeller to spin at a given RPM where J is close to 0 (which is the typical situation when starting the engine and the aircraft is at a dead stop).<br />
<br />
You can open the property tree and watch the value of J (/fdm/jsbsim/propulsion/engines/advance-ratio) to get an idea of which values you need to change in the C_POWER table.<br />
<br />
''' Code is in FG 2.8 to independently control the power of the piston starter motor, to include battery effects. '''<br />
starter-torque (fgfs 2.8) is a value specifying the zero RPM torque in lb*ft the starter motor provides. Current default value is 40% of the maximum horsepower value.<br />
starter-rpm (fgfs 2.8) is a value specifying the maximum RPM the unloaded starter motor can achieve. Loads placed on the engine by the propeller and throttle will further limit RPM achieved in practice. Peak starter power is achieved at 1/2 starter-rpm. At 1/2 starter-rpm torque is 1/2 starter-torque. Peak power can be calculated by the standard formula HP=(Torque*RPM)/5252<br />
<br />
=== Development tips ===<br />
* If you open the property tree browser within FG to /fdm/jsbsim/propulsion/engines you can see a number of helpful variables in action, including RPM, horsepower, advance ratio, thrust coefficient, and others.<br />
<br />
=== References ===<br />
* Barnes W. McCormick, "Aerodynamics, Aeronautics, and Flight Mechanics", Wiley & Sons, 1979 ISBN 0-471-03032-5<br />
* Edwin Hartman, David Biermann, "The Aerodynamic Characteristics of Full Scale Propellers Having 2, 3, and 4 Blades of Clark Y and R.A.F. 6 Airfoil Sections", NACA Report TN-640, 1938 (?)<br />
* Various NACA Technical Notes and Reports<br />
<br />
== FGRotor ==<br />
FGRotor models a helicopter rotor.<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<!-- Sense goes in the parent tag --><br />
<sense> {1 | 0 | -1} </sense><br />
<?xml version="1.0"?> <br />
<rotor name="{string}"><br />
<diameter unit="{LENGTH}"> {number} </diameter><br />
<numblades> {number} </numblades><br />
<gearratio> {number} </gearratio><br />
<nominalrpm> {number} </nominalrpm><br />
<minrpm> {number} </minrpm><br />
<maxrpm> {number} </maxrpm> <br />
<chord unit="{LENGTH}"> {number} </chord><br />
<liftcurveslope Xunit="1/RAD"> {number} </liftcurveslope><br />
<twist unit="{ANGLE}"> {number} </twist><br />
<hingeoffset unit="{LENGTH}"> {number} </hingeoffset><br />
<flappingmoment unit="{MOMENT}"> {number} </flappingmoment><br />
<massmoment Xunit="SLUG*FT"> {number} </massmoment><br />
<polarmoment unit="{MOMENT}"> {number} </polarmoment><br />
<inflowlag> {number} </inflowlag><br />
<tiplossfactor> {number} </tiplossfactor><br />
<maxbrakepower unit="{POWER}"> {number} </maxbrakepower><br />
<br />
<controlmap> {MAIN|TAIL|TANDEM} </controlmap><br />
<ExternalRPM> {number} </ExternalRPM><br />
<br />
<groundeffectexp> {number} </groundeffectexp><br />
<groundeffectshift unit="{LENGTH}"> {number} </groundeffectshift><br />
</rotor><br />
</syntaxhighlight><br />
<br />
* LENGTH means any of the supported units, same for ANGLE and MOMENT.X unit-attributes are a hint for currently unsupported units, so values must be provided accordingly.<br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
|diameter<br />
|Rotor disk diameter (2x R).<br />
|-<br />
|numblades<br />
|Number of blades (b).<br />
|-<br />
|gearratio<br />
|Ratio of (engine rpm) / (rotor rpm), usually > 1.<br />
|-<br />
|nominalrpm<br />
|RPM at which the rotor usally operates. <br />
|-<br />
|minrpm<br />
|Lowest RPM used in the model, optional and defaults to 1.<br />
|-<br />
|maxrpm<br />
|Largest RPM used in the model, optional and defaults to 2 x nominalrpm. <br />
|-<br />
|chord<br />
|Blade chord, (c).<br />
|-<br />
|liftcurveslope<br />
|Slope of curve of section lift against section angle of attack, per rad (a).<br />
|-<br />
|twist<br />
|Blade twist from root to tip, (theta_1).<br />
|-<br />
|hingeoffset<br />
|Rotor flapping-hinge offset (e).<br />
|-<br />
|flappingmoment<br />
|Flapping moment of inertia (I_b).<br />
|-<br />
|massmoment<br />
|Blade mass moment. Mass of a single blade times the blade's cg-distance from the hub, optional.<br />
|-<br />
|polarmoment<br />
|Moment of inertia for the whole rotor disk, optional.<br />
|-<br />
|inflowlag<br />
|Rotor inflow time constant, sec. Smaller values yield to quicker responses (typical values for main rotor: 0.1 - 0.2 s).<br />
|-<br />
|tiplossfactor<br />
|Tip-loss factor. The Blade fraction that produces lift. Value usually ranges between 0.95 - 1.0, optional (B).<br />
|-<br />
|maxbrakepower<br />
|Rotor brake, 20-30 hp should work for a mid size helicopter.<br />
|-<br />
|controlmap<br />
|Defines the control inputs used (see notes).<br />
|-<br />
|ExternalRPM<br />
|Links the rotor to another rotor, or an user controllable property.<br />
<br />
Experimental properties<br />
|-<br />
|groundeffectexp<br />
|Exponent for ground effect approximation. Values usually range from 0.04 for large rotors to 0.1 for smaller ones. As a rule of thumb the effect vanishes at a height 2-3 times the rotor diameter. formula used: exp ( - groundeffectexp * (height+groundeffectshift) ) Omitting or setting to 0.0 disables the effect calculation.<br />
|-<br />
|groundeffectshift<br />
|Further adjustment of ground effect, approx. hub height or slightly above. <br />
|}<br />
<br />
=== Notes ===<br />
==== Controls ====<br />
The behavior of the rotor is controlled/influenced by following inputs.<br />
* The power provided by the engine. This is handled by the regular engine controls.<br />
* The collective control input. This is read from the <tt>fdm</tt> property <tt>propulsion/engine[x]/collective-ctrl-rad</tt>. See below for tail rotor<br />
* The lateral cyclic input. Read from <tt>propulsion/engine[x]/lateral-ctrl-rad</tt>.<br />
* The longitudinal cyclic input. Read from <tt>propulsion/engine[x]/longitudinal-ctrl-rad</tt>.<br />
** The tail collective (aka antitorque, aka pedal) control input. Read from <tt>propulsion/engine[x]/antitorque-ctrl-rad</tt> or <tt>propulsion/engine[x]/tail-collective-ctrl-rad</tt>. <br />
<br />
==== Tail/tandem rotor ====<br />
Providing '''&lt;ExternalRPM&gt; 0 &lt;/ExternalRPM&gt;''' the tail rotor's RPM is linked to to the main (=first, =0) rotor, and specifying '''&lt;controlmap&gt; TAIL &lt;/controlmap&gt;''' tells this rotor to read the collective input from '''propulsion/engine[1]/antitorque-ctrl-rad''' (The TAIL-map ignores lateral and longitudinal input). The rotor needs to be attached to a dummy engine, e.g. an 1HP electrical engine. A tandem rotor is setup analogous.<br />
<br />
==== Sense ====<br />
The 'sense' parameter from the thruster is interpreted as follows, sense=1 means counter clockwise rotation of the main rotor, as viewed from above. This is as a far as I know more popular than clockwise rotation, which is defined by setting sense to -1. Concerning coaxial designs - by setting 'sense' to zero, a Kamov-style rotor is modeled (i.e. the rotor produces no torque).<br />
<br />
==== Engine issues ====<br />
In order to keep the rotor speed constant, use of a RPM-Governor system is encouraged (see examples).<br />
<br />
==== Development hints ====<br />
Setting '''&lt;ExternalRPM&gt; -1 &lt;/ExternalRPM&gt;''' the rotor's RPM is controlled by the '''propulsion/engine[x]/x-rpm-dict''' property. This feature can be useful when developing a FDM.<br />
<br />
==== Properties ====<br />
The rotor model creates the following properties:<br />
<br />
{| class="prettytable"<br />
|-<br />
|propulsion/engine[#]/rotor-rpm<br />
|RPMs of the rotor<br />
|-<br />
|propulsion/engine[#]/engine-rpm<br />
|RPMs of the Engine, as seen from this rotor.<br />
|-<br />
|propulsion/engine[#]/a0-rad<br />
|Rotor's coning angle in radians<br />
|-<br />
|propulsion/engine[#]/a1-rad<br />
|Longitudinal flapping angle with respect to the rotor shaft in radians<br />
|-<br />
|propulsion/engine[#]/b1-rad<br />
|Lateral flapping angle with respect to the rotor shaft in radians<br />
|-<br />
|propulsion/engine[#]/inflow-ratio<br />
| Lambda or λ<br />
|-<br />
|propulsion/engine[#]/advance-ratio<br />
|the tip-speed (aka advance) ratio Mu or μ<br />
|-<br />
|propulsion/engine[#]/induced-inflow-ratio<br />
| Nu or ν<br />
|-<br />
|propulsion/engine[#]/vi-fps<br />
|Induced Velocity in feet per second<br />
|-<br />
|propulsion/engine[#]/thrust-coefficient<br />
|<br />
|-<br />
|propulsion/engine[#]/torque-lbsft<br />
| Rotor torque in pound * feet<br />
|-<br />
|propulsion/engine[#]/theta-downwash-rad<br />
|Down wash θ angle - positive values point forward (given a horizontal spinning rotor) in radians<br />
|-<br />
|propulsion/engine[#]/phi-downwash-rad<br />
|Down wash Φ angle - positive values point leftward (given a horizontal spinning rotor) in radians<br />
|-<br />
|propulsion/engine[#]/groundeffect-scale-norm<br />
|<br />
|}<br />
<br />
(Control Inputs)<br />
{| class="prettytable"<br />
|-<br />
|propulsion/engine[#]/antitorque-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/tail-collective-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/lateral-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/longitudinal-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/collective-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/lateral-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/longitudinal-ctrl-rad<br />
|<br />
|}<br />
<br />
=== References ===<br />
{| class="prettytable"<br />
|-<br />
|SH79<br />
|Shaugnessy, J. D., Deaux, Thomas N., and Yenni, Kenneth R., "Development and Validation of a Piloted Simulation of a Helicopter and External Sling Load", NASA TP-1285, 1979.<br />
|-<br />
|BA41<br />
|Bailey,F.J.,Jr., "A Simplified Theoretical Method of Determining the Characteristics of a Lifting Rotor in Forward Flight", NACA Rep.716, 1941<br />
|-<br />
|AM50<br />
|Amer, Kenneth B.,"Theory of Helicopter Damping in Pitch or Roll and a Comparison With Flight Measurements", NACA TN-2136, 1950.<br />
|-<br />
|TA77<br />
|Talbot, Peter D., Corliss, Lloyd D., "A Mathematical Force and Moment Model of a UH-1H Helicopter for Flight Dynamics Simulations", NASA TM-73,254, 1977.<br />
|-<br />
|GE49<br />
|Gessow, Alfred, Amer, Kenneth B. "An Introduction to the Physical Aspects of Helicopter Stability", NACA TN-1982, 1949.<br />
|}<br />
<br />
{{JSBSim}}</div>Flughttps://wiki.flightgear.org/w/index.php?title=JSBSim_Thrusters&diff=107239JSBSim Thrusters2017-03-02T22:34:42Z<p>Flug: /* Sense bug affecting gyroscopic moment */</p>
<hr />
<div>'''[[JSBSim]]''' uses '''thruster''' models to convert engine power into aerodynamic forces. The following table shows which engine-thruster combinations work.<br />
<br />
{| class="wikitable" style="text-align:center;border: none; background: none;"<br />
|-<br />
! colspan="2" rowspan="2" style="border: none; background: none;" | <br />
! colspan=4 | Thrusters<br />
|-<br />
| style="width:60px;" | [[JSBSim Thrusters#FGDirect|Direct]] <br />
| style="width:60px;" | [[JSBSim Thrusters#FGNozzle|Nozzle]]<br />
| style="width:60px;" | [[JSBSim Thrusters#FGPropeller|Propeller]]<br />
| style="width:60px;" | [[JSBSim Thrusters#FGRotor|Rotor]] <br />
|-<br />
! rowspan=5 | Engines<br />
|[[JSBSim Engines#FGElectric|Electric]]<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|-<br />
|[[JSBSim Engines#FGPiston|Piston]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|-<br />
|[[JSBSim Engines#FGRocket|Rocket]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" | <br />
|-<br />
|[[JSBSim Engines#FGTurbine|Turbine]]<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
|-<br />
|[[JSBSim Engines#FGTurboProp|TurboProp]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|}<br />
<br />
== FGDirect ==<br />
Thrust is computed directly by the engine, the direct thruster file is a stub. Currently FGTurbine engines use this thruster and it can also be used with FGElectric.<br />
<br />
=== Configuration file format ===<br />
This is the complete configuration file. Copy and paste into your 'direct.xml' file.<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?> <br />
<direct name="Direct"><br />
</direct> <br />
</syntaxhighlight><br />
<br />
=== Notes ===<br />
* The direct thruster creates a property called propulsion/engine[#]/reverser-angle-rad<br />
* "Reverser angle" as used here is a way to manipulate the thrust vector, along the thrust axis ONLY, during run time. This should not be confused with a thrust vectoring nozzle. The angle is defined in radians, and is used thus: Final_thrust = cosine( reverser_angle ) * unmodified_thrust. Therefore a reverser angle of 0 results in no change, and a reverser angle of 3.14 (pi) results in a completely reversed thrust vector. An angle of 1.57 (pi/2) results in no thrust at all<br />
<br />
== FGNozzle ==<br />
FGNozzle is for the FGRocket engine.<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?> <br />
<nozzle name="{string}"><br />
<area unit="{FT2 | M2 | IN2}"> {number} </area><br />
</nozzle><br />
</syntaxhighlight><br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
|area<br />
|Nozzle area at the exit plane.<br />
|}<br />
<br />
=== Notes ===<br />
* All parameters MUST be specified.<br />
* The area specified times the sea level pressure (2117 lbf/ft^2) is the amount thrust is reduced at sea level<br />
<br />
== FGPropeller ==<br />
FGPropeller models a propeller given the tabular data for Ct and Cp, indexed by the advance ratio "J".<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<!-- Sense goes in the parent tag --><br />
<sense> {1 | -1} </sense> <br />
<?xml version="1.0"?> <br />
<propeller name="{string}"><br />
<ixx> {number} </ixx><br />
<diameter unit="IN"> {number} </diameter><br />
<numblades> {number} </numblades><br />
<gearratio> {number} </gearratio><br />
<minpitch> {number} </minpitch><br />
<maxpitch> {number} </maxpitch><br />
<minrpm> {number} </minrpm><br />
<maxrpm> {number} </maxrpm><br />
<constspeed> {number} </constspeed><br />
<reversepitch> {number} </reversepitch><br />
<p_factor> {number} </p_factor><br />
<ct_factor> {number} </ct_factor><br />
<cp_factor> {number} </cp_factor><br />
<br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="C_POWER" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
</propeller><br />
</syntaxhighlight><br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
| valign="top" | ixx<br />
|Propeller rotational inertia. This can be english units, slug & feet^2:<br />
<br />
<ixx unit="SLUG*FT2"> 8.95 </ixx><br />
<br />
Or in metric units, kg * meters^2:<br />
<br />
<ixx unit="KG*M2"> 12.14 </ixx><br />
<br />
For a thin rod of mass m (kg) and diameter D (meters) spinning about its center, the formula is m*D^2/12. See the [http://en.wikipedia.org/wiki/List_of_moments_of_inertia Moments of inertia reference page] and [http://www.engineeringtoolbox.com/moment-inertia-torque-d_913.html list of conversion factors for different units for moment of inertia].)<br />
|-<br />
|diameter<br />
|Propeller disk diameter.<br />
|-<br />
|numblades<br />
|Number of blades.<br />
|-<br />
|gearratio<br />
|Ratio of (engine rpm) / (prop rpm).<br />
|-<br />
|minpitch<br />
|Minimum blade pitch angle.<br />
|-<br />
|maxpitch<br />
|Maximum blade pitch angle.<br />
|-<br />
|minrpm<br />
|Minimum rpm target for constant speed propeller.<br />
|-<br />
|maxrpm<br />
|Maximum rpm target for constant speed propeller.<br />
|-<br />
|constspeed<br />
|1 = constant speed mode, 0 = manual pitch mode. <br />
|-<br />
|reversepitch<br />
|Blade pitch angle for reverse.<br />
|-<br />
|sense<br />
|Direction of rotation (1= clockwise as viewed from rear, -1=counter-clockwise as viewed from rear). Sense is specified in the parent tag of the propeller.<br />
|-<br />
|p_factor<br />
|P factor.<br />
|-<br />
|ct_factor<br />
|A multiplier for the coefficients of thrust (multiplies the dependent variable in the C_THRUST table by this factor).<br />
|-<br />
|cp_factor<br />
|A multiplier for the coefficients of power (multiplies the dependent variable in the C_POWER table by this factor).<br />
|}<br />
<br />
=== C_THRUST and C_POWER tables ===<br />
The C_THRUST and C_POWER tables are required. <br />
<br />
The independent variable for both tables is [http://en.wikipedia.org/wiki/Advance_ratio Advance Ratio] (J). The dependent variable is the coefficient of thrust (Ct) for the C_THRUST and the coefficient of power (Cp) for C_POWER. <br />
<br />
For variable pitch propellers, it is possible to give a two-dimensional table, showing Ct and Cp for different J and different pitch angles of the propeller. See example below.<br />
<br />
[http://www.mh-aerotools.de/airfoils/pylonprops_1.htm Propellors for F3D Models explains the theory] and has [http://www.mh-aerotools.de/airfoils/pylonprops_2.htm formulas] and [http://www.mh-aerotools.de/airfoils/pylonprops_3.htm many graphs] showing the relationship between J, Ct, and Cp.<br />
<br />
Relevant formulas relating the variables in the tables (and metric system units):<br />
<br />
* Thrust: T = Ct * rho * n^2 * D^4<br />
* Power: P = Cp * rho * n^3 * D^5)<br />
* Advance Ratio: J = v/(n*D)<br />
* Efficiency: eta = Ct/Cp * v/(n*D) (or equivalently, eta = Ct/Cp * J )<br />
<br />
In the formulas<br />
* Ct = coefficient of thrust<br />
* Cp = coefficient of power<br />
* v = true velocity of aircraft (m/s)<br />
* D = diameter of propeller disk (m)<br />
* n = rotations per second (1/s) (note RPS, not RPM)<br />
* rho = density of air (kg/m^3)<br />
* P = power (W)<br />
* T = thrust (N)<br />
<br />
For a typical propeller, both Cp and Ct are downward sloping curves that reach 0 when J is somewhere in the range 0-4 (depending on blade angle and other factors). Cp and Ct can be negative; this indicates the drag induced by the prop when the airspeed is relatively fast compared with prop RPM. At higher pitch angles Ct may have a positive slope or be flat in the lower J range.<br />
<br />
Ct/Cp gives the efficiency (eta), and propeller shape and general design give each propeller a distinctive [http://www.mh-aerotools.de/airfoils/pylonprops_3.htm efficiency curve]. For fixed-pitch propellers, the propeller is generally designed to reach peak efficiency either at climb velocity & RPM, cruise velocity and RPM, or some compromise between the two. [http://en.wikipedia.org/wiki/Controllable_pitch_propeller Variable pitch propellers] and [http://en.wikipedia.org/wiki/Constant_speed_propeller constant speed propellers] bring different factors into play.<br />
<br />
Note that several of the values mentioned above can be viewed while FG is running, in the property tree under /fdm/jsbsim/propulsion/engine. This is useful for seeing how the settings and tables play out under various conditions and fine-tuning the settings.<br />
<br />
==== Sample C_THRUST and C_POWER tables ====<br />
These example tables are from FlightGear's C172P aircraft:<br />
<br />
<syntaxhighlight lang="xml"><br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
0.0 0.068<br />
0.1 0.068<br />
0.2 0.067<br />
0.3 0.066<br />
0.4 0.064<br />
0.5 0.062<br />
0.6 0.059<br />
0.7 0.054<br />
0.8 0.043<br />
0.9 0.031<br />
1.0 0.019<br />
1.1 0.008<br />
1.2 -0.001<br />
1.3 -0.008<br />
1.4 -0.019<br />
1.5 -0.029<br />
1.6 -0.040<br />
1.7 -0.050<br />
1.8 -0.057<br />
1.9 -0.061<br />
2.0 -0.064<br />
2.1 -0.066<br />
2.2 -0.067<br />
2.3 -0.068<br />
5.0 -0.068<br />
</tableData><br />
</table><br />
<br />
<table name="C_POWER" type = "internal"><br />
<tableData><br />
0.0 0.0580<br />
0.1 0.0620<br />
0.2 0.0600<br />
0.3 0.0580<br />
0.4 0.0520<br />
0.5 0.0457<br />
0.6 0.0436<br />
0.7 0.0420<br />
0.8 0.0372<br />
0.9 0.0299<br />
1.0 0.0202<br />
1.1 0.0111<br />
1.2 0.0075<br />
1.3 0.0111<br />
1.4 0.0202<br />
1.5 0.0280<br />
1.6 0.0346<br />
1.7 0.0389<br />
1.8 0.0421<br />
1.9 0.0436<br />
2.0 0.0445<br />
2.1 0.0445<br />
2.2 0.0442<br />
2.3 0.0431<br />
2.4 0.0424<br />
5.0 0.0413<br />
</tableData><br />
</table><br />
</syntaxhighlight><br />
<br />
Example of table for variable pitch propeller ([http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg32187.html source]):<br />
<br />
<syntaxhighlight lang="xml"><br />
<!-- thrust coefficient as a function of advance ratio and blade angle --><br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
-10 0 15 25 35 45 55 65 90<br />
-0.2 -0.0734 0.0413 0.1503 0.1842 0.2030 0.2142 0.1974 0.1691 0.0000<br />
0.0 -0.1090 0.0000 0.1503 0.1842 0.2030 0.2162 0.2021 0.1691 0.0000<br />
0.2 -0.1222 -0.0376 0.1297 0.1804 0.2001 0.2162 0.2021 0.1691 0.0000<br />
0.4 -0.1222 -0.0873 0.0977 0.1786 0.1963 0.2142 0.2021 0.1691 0.0000<br />
0.6 -0.1222 -0.1222 0.0517 0.1607 0.1879 0.2087 0.1992 0.1691 0.0000<br />
0.8 -0.1222 -0.1222 0.0029 0.1203 0.1824 0.2012 0.1992 0.1691 0.0000<br />
1.0 -0.1222 -0.1222 -0.0489 0.0734 0.1748 0.1908 0.1974 0.1691 0.0000<br />
1.2 -0.1222 -0.1222 -0.1006 0.0226 0.1437 0.1842 0.1974 0.1691 0.0000<br />
1.4 -0.1222 -0.1222 -0.1222 -0.0329 0.1034 0.1813 0.1936 0.1691 0.0000<br />
1.6 -0.1222 -0.1222 -0.1222 -0.0836 0.0564 0.1748 0.1899 0.1691 0.0000<br />
1.8 -0.1222 -0.1222 -0.1222 -0.1222 0.0095 0.1503 0.1842 0.1691 0.0000<br />
2.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.0376 0.1174 0.1834 0.1691 0.0000<br />
2.2 -0.1222 -0.1222 -0.1222 -0.1222 -0.0846 0.0846 0.1804 0.1691 0.0000<br />
2.4 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0451 0.1473 0.1691 0.0000<br />
2.6 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0057 0.0932 0.1503 0.0000<br />
2.8 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0338 0.0610 0.1222 0.0000<br />
3.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0734 0.0320 0.0940 0.0000<br />
3.2 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1128 0.0029 0.0658 0.0000<br />
3.4 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0263 0.0376 0.0000<br />
3.6 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0555 0.0095 0.0000<br />
3.8 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0846 -0.0188 0.0000<br />
4.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1137 -0.0471 0.0000<br />
6.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0000<br />
</tableData><br />
</table><br />
<br />
<!-- power coefficient as a function of advance ratio and blade angle --><br />
<table name="C_POWER" type="internal"><br />
<tableData><br />
-10 0 15 25 35 45 55 65 90<br />
-0.2 0.0108 0.0215 0.0753 0.1710 0.2949 0.4194 0.4839 0.5355 0.5355<br />
0.0 0.0430 0.0108 0.0645 0.1594 0.2820 0.4194 0.4859 0.5355 0.5355<br />
0.2 0.0613 0.0172 0.0624 0.1484 0.2697 0.4194 0.4859 0.5355 0.5355<br />
0.4 0.0826 0.0376 0.0537 0.1368 0.2562 0.4194 0.4859 0.5355 0.5355<br />
0.6 0.1013 0.0570 0.0355 0.1271 0.2400 0.4110 0.4839 0.5355 0.5355<br />
0.8 0.1194 0.0763 0.0108 0.1078 0.2258 0.3923 0.4839 0.5355 0.5355<br />
1.0 0.1374 0.0948 0.0108 0.0755 0.2129 0.3723 0.4820 0.5355 0.5355<br />
1.2 0.1561 0.0758 -0.0355 0.0290 0.1884 0.3568 0.4788 0.5355 0.5355<br />
1.4 0.1742 0.1310 -0.0536 -0.0215 0.1452 0.3516 0.4729 0.5355 0.5355<br />
1.6 0.1923 0.1497 -0.0626 -0.0645 0.0916 0.3420 0.4626 0.5162 0.5355<br />
1.8 0.2110 0.1678 -0.0645 -0.1078 0.0269 0.3033 0.4484 0.5052 0.5355<br />
2.0 0.2291 0.1858 -0.0826 -0.1503 -0.0323 0.2581 0.4271 0.4949 0.5355<br />
2.2 0.2471 0.2045 -0.1013 -0.1936 -0.0968 0.2097 0.4142 0.4729 0.5355<br />
2.4 0.2658 0.2226 -0.1194 -0.2368 -0.1613 0.1497 0.4020 0.4626 0.5355<br />
2.6 0.2839 0.2407 -0.1374 -0.2794 -0.2045 0.0626 0.3923 0.4465 0.5355<br />
2.8 0.3020 0.2594 -0.1561 -0.3226 -0.2452 -0.0213 0.3839 0.4407 0.5355<br />
3.0 0.3207 0.2774 -0.1742 -0.3658 -0.2903 -0.0968 0.3710 0.4407 0.5355<br />
3.2 0.3387 0.2955 -0.1923 -0.4084 -0.3336 -0.1723 0.3471 0.4304 0.5355<br />
3.4 0.3568 0.3142 -0.2110 -0.4517 -0.3762 -0.2471 0.2691 0.4194 0.5355<br />
3.6 0.3755 0.3323 -0.2291 -0.4949 -0.4194 -0.3226 0.1890 0.4084 0.5355<br />
3.8 0.3936 0.3504 -0.2471 -0.5355 -0.4626 -0.3981 0.1052 0.3955 0.5355<br />
4.0 0.4117 0.3691 -0.2658 -0.5355 -0.5355 -0.4729 0.0213 0.3658 0.5355<br />
6.0 0.5355 0.5355 -0.5355 -0.5355 -0.5355 -0.5355 -0.5355 -0.3226 0.5355<br />
</tableData><br />
</table><br />
<br />
<!-- thrust effects of helical tip Mach --><br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 0.8<br />
</tableData><br />
</table><br />
<br />
<!-- power-required effects of helical tip Mach --><br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 1.8<br />
2.00 1.4<br />
</tableData><br />
</table><br />
<syntaxhighlight lang="xml"><br />
<br />
=== CT_MACH and CP_MACH ===<br />
The CT_MACH and CP_MACH tables are optional. They apply a factor to Ct and Cp based on the helical tip Mach. The CP_MACH table models the [http://en.wikipedia.org/wiki/Drag_divergence_Mach_number Drag Divergence Mach Number] for the propeller airfoil. The CT_MACH table models the thrust reduction.<br />
<br />
Examples:<br />
<br />
<syntaxhighlight lang="xml"><br />
<br />
<!-- thrust effects of helical tip Mach --><br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 0.8<br />
</tableData><br />
</table><br />
<br />
<!-- power-required effects of helical tip Mach --><br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 1.8<br />
2.00 1.4<br />
</tableData><br />
</table><br />
</syntaxhighlight><br />
<br />
=== Sense ===<br />
Sense is the direction of rotation. 1=clockwise (typically as seen from rear of aircraft or the cockpit of a typical front-propeller aircraft, but this may vary depending on how you have set up the coordinate system for your aircraft) and -1 is counter-clockwise.<br />
<br />
The sense tag goes in the parent tag of the thruster, ie, in the <propulsion><thruster> section which is typically in the main JSBSim XML file. Example:<br />
<br />
<syntaxhighlight lang="xml"><br />
<propulsion><br />
<engine file="Clerget9B"><br />
<location unit="IN"><br />
<x> 12 </x><br />
<y> 0 </y><br />
<z> 0 </z><br />
</location><br />
<orient unit="DEG"><br />
<roll> 0 </roll><br />
<pitch> 0 </pitch><br />
<yaw> 0 </yaw><br />
</orient><br />
<feed>0</feed><br />
<thruster file="CamelProp"><br />
'''<sense>1</sense>'''<br />
<location unit="IN"><br />
<x> 0 </x><br />
<y> 0 </y><br />
<z> 0 </z><br />
</location><br />
<orient unit="DEG"><br />
<roll> 0 </roll><br />
<pitch> 0 </pitch><br />
<yaw> 0 </yaw><br />
</orient><br />
</thruster><br />
</engine><br />
<tank type="FUEL"><br />
<location unit="IN"><br />
<x> 60 </x><br />
<y> 0 </y><br />
<z> -5.62 </z><br />
</location><br />
<capacity unit="LBS">133.6</capacity><br />
<contents unit="LBS">133.6</contents><br />
</tank><br />
</propulsion><br />
</syntaxhighlight><br />
<br />
====Sense bug affecting gyroscopic moment====<br />
Prior to about 2015--and continuing in current JSBSim and FlightGear versions unless you take the corrective steps outlined below--a JSBSim bug cause the gyroscopic moment of the propeller to be reversed.<br />
<br />
To fix this bug and get the correct sign for your gyroscopic effect, you must add version="1.1" (or higher--any version greater than 1.0 should work) to your propeller definition, as shown in this example:<br />
<br />
<syntaxhighlight><br />
<propeller name="prop" version="1.1"><br />
<!-- propeller definition --><br />
</propeller><br />
</syntaxhighlight><br />
<br />
The bug with the sign of gyroscopic effect and the fix are outlined under [https://sourceforge.net/p/jsbsim/bugs/110/ JSBSim Bug #110].<br />
<br />
For most aircraft and engine/propeller systems the gyroscopic effect is fairly subtle and thus the bug is difficult to detect. But for some aircraft, such as small, light, rotary-engined WWI-era aircraft, the gyroscopic effect is very noticeable, and the reverse in direction of the effect created by the bug is very noticeable as well.<br />
<br />
=== Starter speed (for piston engines) ===<br />
There is a somewhat complex relationship among the power coefficient, the maxhp, and idlerpm. Both maxhp and idlerpm are set in the engine xml file.<br />
<br />
The power of the starter motor is equal to 0.4*sqrt(maxhp). The minimum RPM needed to start the engine is 80% of the idlerpm. The greater the power coefficient (for J near 0), the more power the propeller will require to spin when starting the engine with the aircraft at rest.<br />
<br />
If your propeller will not spin fast enough to start, you can try some combination of:<br />
<br />
* Open the throttle. Pulling a partial vacuum in the intake manifold takes some power.<br />
* Increase maxhp (increases the power of the starter motor)<br />
* Decrease idlerpm (decreases the minimum RPM needed to start the engine)<br />
* Decrease the power coefficient in the C_POWER table, for values of J close to (or equal to) 0. This will reduce the amount of power it takes for the propeller to spin at a given RPM where J is close to 0 (which is the typical situation when starting the engine and the aircraft is at a dead stop).<br />
<br />
You can open the property tree and watch the value of J (/fdm/jsbsim/propulsion/engines/advance-ratio) to get an idea of which values you need to change in the C_POWER table.<br />
<br />
''' Code is in FG 2.8 to independently control the power of the piston starter motor, to include battery effects. '''<br />
starter-torque (fgfs 2.8) is a value specifying the zero RPM torque in lb*ft the starter motor provides. Current default value is 40% of the maximum horsepower value.<br />
starter-rpm (fgfs 2.8) is a value specifying the maximum RPM the unloaded starter motor can achieve. Loads placed on the engine by the propeller and throttle will further limit RPM achieved in practice. Peak starter power is achieved at 1/2 starter-rpm. At 1/2 starter-rpm torque is 1/2 starter-torque. Peak power can be calculated by the standard formula HP=(Torque*RPM)/5252<br />
<br />
=== Development tips ===<br />
* If you open the property tree browser within FG to /fdm/jsbsim/propulsion/engines you can see a number of helpful variables in action, including RPM, horsepower, advance ratio, thrust coefficient, and others.<br />
<br />
=== References ===<br />
* Barnes W. McCormick, "Aerodynamics, Aeronautics, and Flight Mechanics", Wiley & Sons, 1979 ISBN 0-471-03032-5<br />
* Edwin Hartman, David Biermann, "The Aerodynamic Characteristics of Full Scale Propellers Having 2, 3, and 4 Blades of Clark Y and R.A.F. 6 Airfoil Sections", NACA Report TN-640, 1938 (?)<br />
* Various NACA Technical Notes and Reports<br />
<br />
== FGRotor ==<br />
FGRotor models a helicopter rotor.<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<!-- Sense goes in the parent tag --><br />
<sense> {1 | 0 | -1} </sense><br />
<?xml version="1.0"?> <br />
<rotor name="{string}"><br />
<diameter unit="{LENGTH}"> {number} </diameter><br />
<numblades> {number} </numblades><br />
<gearratio> {number} </gearratio><br />
<nominalrpm> {number} </nominalrpm><br />
<minrpm> {number} </minrpm><br />
<maxrpm> {number} </maxrpm> <br />
<chord unit="{LENGTH}"> {number} </chord><br />
<liftcurveslope Xunit="1/RAD"> {number} </liftcurveslope><br />
<twist unit="{ANGLE}"> {number} </twist><br />
<hingeoffset unit="{LENGTH}"> {number} </hingeoffset><br />
<flappingmoment unit="{MOMENT}"> {number} </flappingmoment><br />
<massmoment Xunit="SLUG*FT"> {number} </massmoment><br />
<polarmoment unit="{MOMENT}"> {number} </polarmoment><br />
<inflowlag> {number} </inflowlag><br />
<tiplossfactor> {number} </tiplossfactor><br />
<maxbrakepower unit="{POWER}"> {number} </maxbrakepower><br />
<br />
<controlmap> {MAIN|TAIL|TANDEM} </controlmap><br />
<ExternalRPM> {number} </ExternalRPM><br />
<br />
<groundeffectexp> {number} </groundeffectexp><br />
<groundeffectshift unit="{LENGTH}"> {number} </groundeffectshift><br />
</rotor><br />
</syntaxhighlight><br />
<br />
* LENGTH means any of the supported units, same for ANGLE and MOMENT.X unit-attributes are a hint for currently unsupported units, so values must be provided accordingly.<br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
|diameter<br />
|Rotor disk diameter (2x R).<br />
|-<br />
|numblades<br />
|Number of blades (b).<br />
|-<br />
|gearratio<br />
|Ratio of (engine rpm) / (rotor rpm), usually > 1.<br />
|-<br />
|nominalrpm<br />
|RPM at which the rotor usally operates. <br />
|-<br />
|minrpm<br />
|Lowest RPM used in the model, optional and defaults to 1.<br />
|-<br />
|maxrpm<br />
|Largest RPM used in the model, optional and defaults to 2 x nominalrpm. <br />
|-<br />
|chord<br />
|Blade chord, (c).<br />
|-<br />
|liftcurveslope<br />
|Slope of curve of section lift against section angle of attack, per rad (a).<br />
|-<br />
|twist<br />
|Blade twist from root to tip, (theta_1).<br />
|-<br />
|hingeoffset<br />
|Rotor flapping-hinge offset (e).<br />
|-<br />
|flappingmoment<br />
|Flapping moment of inertia (I_b).<br />
|-<br />
|massmoment<br />
|Blade mass moment. Mass of a single blade times the blade's cg-distance from the hub, optional.<br />
|-<br />
|polarmoment<br />
|Moment of inertia for the whole rotor disk, optional.<br />
|-<br />
|inflowlag<br />
|Rotor inflow time constant, sec. Smaller values yield to quicker responses (typical values for main rotor: 0.1 - 0.2 s).<br />
|-<br />
|tiplossfactor<br />
|Tip-loss factor. The Blade fraction that produces lift. Value usually ranges between 0.95 - 1.0, optional (B).<br />
|-<br />
|maxbrakepower<br />
|Rotor brake, 20-30 hp should work for a mid size helicopter.<br />
|-<br />
|controlmap<br />
|Defines the control inputs used (see notes).<br />
|-<br />
|ExternalRPM<br />
|Links the rotor to another rotor, or an user controllable property.<br />
<br />
Experimental properties<br />
|-<br />
|groundeffectexp<br />
|Exponent for ground effect approximation. Values usually range from 0.04 for large rotors to 0.1 for smaller ones. As a rule of thumb the effect vanishes at a height 2-3 times the rotor diameter. formula used: exp ( - groundeffectexp * (height+groundeffectshift) ) Omitting or setting to 0.0 disables the effect calculation.<br />
|-<br />
|groundeffectshift<br />
|Further adjustment of ground effect, approx. hub height or slightly above. <br />
|}<br />
<br />
=== Notes ===<br />
==== Controls ====<br />
The behavior of the rotor is controlled/influenced by following inputs.<br />
* The power provided by the engine. This is handled by the regular engine controls.<br />
* The collective control input. This is read from the <tt>fdm</tt> property <tt>propulsion/engine[x]/collective-ctrl-rad</tt>. See below for tail rotor<br />
* The lateral cyclic input. Read from <tt>propulsion/engine[x]/lateral-ctrl-rad</tt>.<br />
* The longitudinal cyclic input. Read from <tt>propulsion/engine[x]/longitudinal-ctrl-rad</tt>.<br />
** The tail collective (aka antitorque, aka pedal) control input. Read from <tt>propulsion/engine[x]/antitorque-ctrl-rad</tt> or <tt>propulsion/engine[x]/tail-collective-ctrl-rad</tt>. <br />
<br />
==== Tail/tandem rotor ====<br />
Providing '''&lt;ExternalRPM&gt; 0 &lt;/ExternalRPM&gt;''' the tail rotor's RPM is linked to to the main (=first, =0) rotor, and specifying '''&lt;controlmap&gt; TAIL &lt;/controlmap&gt;''' tells this rotor to read the collective input from '''propulsion/engine[1]/antitorque-ctrl-rad''' (The TAIL-map ignores lateral and longitudinal input). The rotor needs to be attached to a dummy engine, e.g. an 1HP electrical engine. A tandem rotor is setup analogous.<br />
<br />
==== Sense ====<br />
The 'sense' parameter from the thruster is interpreted as follows, sense=1 means counter clockwise rotation of the main rotor, as viewed from above. This is as a far as I know more popular than clockwise rotation, which is defined by setting sense to -1. Concerning coaxial designs - by setting 'sense' to zero, a Kamov-style rotor is modeled (i.e. the rotor produces no torque).<br />
<br />
==== Engine issues ====<br />
In order to keep the rotor speed constant, use of a RPM-Governor system is encouraged (see examples).<br />
<br />
==== Development hints ====<br />
Setting '''&lt;ExternalRPM&gt; -1 &lt;/ExternalRPM&gt;''' the rotor's RPM is controlled by the '''propulsion/engine[x]/x-rpm-dict''' property. This feature can be useful when developing a FDM.<br />
<br />
==== Properties ====<br />
The rotor model creates the following properties:<br />
<br />
{| class="prettytable"<br />
|-<br />
|propulsion/engine[#]/rotor-rpm<br />
|RPMs of the rotor<br />
|-<br />
|propulsion/engine[#]/engine-rpm<br />
|RPMs of the Engine, as seen from this rotor.<br />
|-<br />
|propulsion/engine[#]/a0-rad<br />
|Rotor's coning angle in radians<br />
|-<br />
|propulsion/engine[#]/a1-rad<br />
|Longitudinal flapping angle with respect to the rotor shaft in radians<br />
|-<br />
|propulsion/engine[#]/b1-rad<br />
|Lateral flapping angle with respect to the rotor shaft in radians<br />
|-<br />
|propulsion/engine[#]/inflow-ratio<br />
| Lambda or λ<br />
|-<br />
|propulsion/engine[#]/advance-ratio<br />
|the tip-speed (aka advance) ratio Mu or μ<br />
|-<br />
|propulsion/engine[#]/induced-inflow-ratio<br />
| Nu or ν<br />
|-<br />
|propulsion/engine[#]/vi-fps<br />
|Induced Velocity in feet per second<br />
|-<br />
|propulsion/engine[#]/thrust-coefficient<br />
|<br />
|-<br />
|propulsion/engine[#]/torque-lbsft<br />
| Rotor torque in pound * feet<br />
|-<br />
|propulsion/engine[#]/theta-downwash-rad<br />
|Down wash θ angle - positive values point forward (given a horizontal spinning rotor) in radians<br />
|-<br />
|propulsion/engine[#]/phi-downwash-rad<br />
|Down wash Φ angle - positive values point leftward (given a horizontal spinning rotor) in radians<br />
|-<br />
|propulsion/engine[#]/groundeffect-scale-norm<br />
|<br />
|}<br />
<br />
(Control Inputs)<br />
{| class="prettytable"<br />
|-<br />
|propulsion/engine[#]/antitorque-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/tail-collective-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/lateral-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/longitudinal-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/collective-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/lateral-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/longitudinal-ctrl-rad<br />
|<br />
|}<br />
<br />
=== References ===<br />
{| class="prettytable"<br />
|-<br />
|SH79<br />
|Shaugnessy, J. D., Deaux, Thomas N., and Yenni, Kenneth R., "Development and Validation of a Piloted Simulation of a Helicopter and External Sling Load", NASA TP-1285, 1979.<br />
|-<br />
|BA41<br />
|Bailey,F.J.,Jr., "A Simplified Theoretical Method of Determining the Characteristics of a Lifting Rotor in Forward Flight", NACA Rep.716, 1941<br />
|-<br />
|AM50<br />
|Amer, Kenneth B.,"Theory of Helicopter Damping in Pitch or Roll and a Comparison With Flight Measurements", NACA TN-2136, 1950.<br />
|-<br />
|TA77<br />
|Talbot, Peter D., Corliss, Lloyd D., "A Mathematical Force and Moment Model of a UH-1H Helicopter for Flight Dynamics Simulations", NASA TM-73,254, 1977.<br />
|-<br />
|GE49<br />
|Gessow, Alfred, Amer, Kenneth B. "An Introduction to the Physical Aspects of Helicopter Stability", NACA TN-1982, 1949.<br />
|}<br />
<br />
{{JSBSim}}</div>Flughttps://wiki.flightgear.org/w/index.php?title=JSBSim_Thrusters&diff=107238JSBSim Thrusters2017-03-02T22:34:13Z<p>Flug: /* Sense */ Adding info about bug affecting the sign of the gyroscopic effect created by 'sense' and how to address it</p>
<hr />
<div>'''[[JSBSim]]''' uses '''thruster''' models to convert engine power into aerodynamic forces. The following table shows which engine-thruster combinations work.<br />
<br />
{| class="wikitable" style="text-align:center;border: none; background: none;"<br />
|-<br />
! colspan="2" rowspan="2" style="border: none; background: none;" | <br />
! colspan=4 | Thrusters<br />
|-<br />
| style="width:60px;" | [[JSBSim Thrusters#FGDirect|Direct]] <br />
| style="width:60px;" | [[JSBSim Thrusters#FGNozzle|Nozzle]]<br />
| style="width:60px;" | [[JSBSim Thrusters#FGPropeller|Propeller]]<br />
| style="width:60px;" | [[JSBSim Thrusters#FGRotor|Rotor]] <br />
|-<br />
! rowspan=5 | Engines<br />
|[[JSBSim Engines#FGElectric|Electric]]<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|-<br />
|[[JSBSim Engines#FGPiston|Piston]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|-<br />
|[[JSBSim Engines#FGRocket|Rocket]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" | <br />
|-<br />
|[[JSBSim Engines#FGTurbine|Turbine]]<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
|-<br />
|[[JSBSim Engines#FGTurboProp|TurboProp]]<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #FF3333;" |<br />
| style="background-color: #33FF33;" |<br />
| style="background-color: #33FF33;" |<br />
|}<br />
<br />
== FGDirect ==<br />
Thrust is computed directly by the engine, the direct thruster file is a stub. Currently FGTurbine engines use this thruster and it can also be used with FGElectric.<br />
<br />
=== Configuration file format ===<br />
This is the complete configuration file. Copy and paste into your 'direct.xml' file.<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?> <br />
<direct name="Direct"><br />
</direct> <br />
</syntaxhighlight><br />
<br />
=== Notes ===<br />
* The direct thruster creates a property called propulsion/engine[#]/reverser-angle-rad<br />
* "Reverser angle" as used here is a way to manipulate the thrust vector, along the thrust axis ONLY, during run time. This should not be confused with a thrust vectoring nozzle. The angle is defined in radians, and is used thus: Final_thrust = cosine( reverser_angle ) * unmodified_thrust. Therefore a reverser angle of 0 results in no change, and a reverser angle of 3.14 (pi) results in a completely reversed thrust vector. An angle of 1.57 (pi/2) results in no thrust at all<br />
<br />
== FGNozzle ==<br />
FGNozzle is for the FGRocket engine.<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?> <br />
<nozzle name="{string}"><br />
<area unit="{FT2 | M2 | IN2}"> {number} </area><br />
</nozzle><br />
</syntaxhighlight><br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
|area<br />
|Nozzle area at the exit plane.<br />
|}<br />
<br />
=== Notes ===<br />
* All parameters MUST be specified.<br />
* The area specified times the sea level pressure (2117 lbf/ft^2) is the amount thrust is reduced at sea level<br />
<br />
== FGPropeller ==<br />
FGPropeller models a propeller given the tabular data for Ct and Cp, indexed by the advance ratio "J".<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<!-- Sense goes in the parent tag --><br />
<sense> {1 | -1} </sense> <br />
<?xml version="1.0"?> <br />
<propeller name="{string}"><br />
<ixx> {number} </ixx><br />
<diameter unit="IN"> {number} </diameter><br />
<numblades> {number} </numblades><br />
<gearratio> {number} </gearratio><br />
<minpitch> {number} </minpitch><br />
<maxpitch> {number} </maxpitch><br />
<minrpm> {number} </minrpm><br />
<maxrpm> {number} </maxrpm><br />
<constspeed> {number} </constspeed><br />
<reversepitch> {number} </reversepitch><br />
<p_factor> {number} </p_factor><br />
<ct_factor> {number} </ct_factor><br />
<cp_factor> {number} </cp_factor><br />
<br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="C_POWER" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
{numbers}<br />
</tableData><br />
</table><br />
<br />
</propeller><br />
</syntaxhighlight><br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
| valign="top" | ixx<br />
|Propeller rotational inertia. This can be english units, slug & feet^2:<br />
<br />
<ixx unit="SLUG*FT2"> 8.95 </ixx><br />
<br />
Or in metric units, kg * meters^2:<br />
<br />
<ixx unit="KG*M2"> 12.14 </ixx><br />
<br />
For a thin rod of mass m (kg) and diameter D (meters) spinning about its center, the formula is m*D^2/12. See the [http://en.wikipedia.org/wiki/List_of_moments_of_inertia Moments of inertia reference page] and [http://www.engineeringtoolbox.com/moment-inertia-torque-d_913.html list of conversion factors for different units for moment of inertia].)<br />
|-<br />
|diameter<br />
|Propeller disk diameter.<br />
|-<br />
|numblades<br />
|Number of blades.<br />
|-<br />
|gearratio<br />
|Ratio of (engine rpm) / (prop rpm).<br />
|-<br />
|minpitch<br />
|Minimum blade pitch angle.<br />
|-<br />
|maxpitch<br />
|Maximum blade pitch angle.<br />
|-<br />
|minrpm<br />
|Minimum rpm target for constant speed propeller.<br />
|-<br />
|maxrpm<br />
|Maximum rpm target for constant speed propeller.<br />
|-<br />
|constspeed<br />
|1 = constant speed mode, 0 = manual pitch mode. <br />
|-<br />
|reversepitch<br />
|Blade pitch angle for reverse.<br />
|-<br />
|sense<br />
|Direction of rotation (1= clockwise as viewed from rear, -1=counter-clockwise as viewed from rear). Sense is specified in the parent tag of the propeller.<br />
|-<br />
|p_factor<br />
|P factor.<br />
|-<br />
|ct_factor<br />
|A multiplier for the coefficients of thrust (multiplies the dependent variable in the C_THRUST table by this factor).<br />
|-<br />
|cp_factor<br />
|A multiplier for the coefficients of power (multiplies the dependent variable in the C_POWER table by this factor).<br />
|}<br />
<br />
=== C_THRUST and C_POWER tables ===<br />
The C_THRUST and C_POWER tables are required. <br />
<br />
The independent variable for both tables is [http://en.wikipedia.org/wiki/Advance_ratio Advance Ratio] (J). The dependent variable is the coefficient of thrust (Ct) for the C_THRUST and the coefficient of power (Cp) for C_POWER. <br />
<br />
For variable pitch propellers, it is possible to give a two-dimensional table, showing Ct and Cp for different J and different pitch angles of the propeller. See example below.<br />
<br />
[http://www.mh-aerotools.de/airfoils/pylonprops_1.htm Propellors for F3D Models explains the theory] and has [http://www.mh-aerotools.de/airfoils/pylonprops_2.htm formulas] and [http://www.mh-aerotools.de/airfoils/pylonprops_3.htm many graphs] showing the relationship between J, Ct, and Cp.<br />
<br />
Relevant formulas relating the variables in the tables (and metric system units):<br />
<br />
* Thrust: T = Ct * rho * n^2 * D^4<br />
* Power: P = Cp * rho * n^3 * D^5)<br />
* Advance Ratio: J = v/(n*D)<br />
* Efficiency: eta = Ct/Cp * v/(n*D) (or equivalently, eta = Ct/Cp * J )<br />
<br />
In the formulas<br />
* Ct = coefficient of thrust<br />
* Cp = coefficient of power<br />
* v = true velocity of aircraft (m/s)<br />
* D = diameter of propeller disk (m)<br />
* n = rotations per second (1/s) (note RPS, not RPM)<br />
* rho = density of air (kg/m^3)<br />
* P = power (W)<br />
* T = thrust (N)<br />
<br />
For a typical propeller, both Cp and Ct are downward sloping curves that reach 0 when J is somewhere in the range 0-4 (depending on blade angle and other factors). Cp and Ct can be negative; this indicates the drag induced by the prop when the airspeed is relatively fast compared with prop RPM. At higher pitch angles Ct may have a positive slope or be flat in the lower J range.<br />
<br />
Ct/Cp gives the efficiency (eta), and propeller shape and general design give each propeller a distinctive [http://www.mh-aerotools.de/airfoils/pylonprops_3.htm efficiency curve]. For fixed-pitch propellers, the propeller is generally designed to reach peak efficiency either at climb velocity & RPM, cruise velocity and RPM, or some compromise between the two. [http://en.wikipedia.org/wiki/Controllable_pitch_propeller Variable pitch propellers] and [http://en.wikipedia.org/wiki/Constant_speed_propeller constant speed propellers] bring different factors into play.<br />
<br />
Note that several of the values mentioned above can be viewed while FG is running, in the property tree under /fdm/jsbsim/propulsion/engine. This is useful for seeing how the settings and tables play out under various conditions and fine-tuning the settings.<br />
<br />
==== Sample C_THRUST and C_POWER tables ====<br />
These example tables are from FlightGear's C172P aircraft:<br />
<br />
<syntaxhighlight lang="xml"><br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
0.0 0.068<br />
0.1 0.068<br />
0.2 0.067<br />
0.3 0.066<br />
0.4 0.064<br />
0.5 0.062<br />
0.6 0.059<br />
0.7 0.054<br />
0.8 0.043<br />
0.9 0.031<br />
1.0 0.019<br />
1.1 0.008<br />
1.2 -0.001<br />
1.3 -0.008<br />
1.4 -0.019<br />
1.5 -0.029<br />
1.6 -0.040<br />
1.7 -0.050<br />
1.8 -0.057<br />
1.9 -0.061<br />
2.0 -0.064<br />
2.1 -0.066<br />
2.2 -0.067<br />
2.3 -0.068<br />
5.0 -0.068<br />
</tableData><br />
</table><br />
<br />
<table name="C_POWER" type = "internal"><br />
<tableData><br />
0.0 0.0580<br />
0.1 0.0620<br />
0.2 0.0600<br />
0.3 0.0580<br />
0.4 0.0520<br />
0.5 0.0457<br />
0.6 0.0436<br />
0.7 0.0420<br />
0.8 0.0372<br />
0.9 0.0299<br />
1.0 0.0202<br />
1.1 0.0111<br />
1.2 0.0075<br />
1.3 0.0111<br />
1.4 0.0202<br />
1.5 0.0280<br />
1.6 0.0346<br />
1.7 0.0389<br />
1.8 0.0421<br />
1.9 0.0436<br />
2.0 0.0445<br />
2.1 0.0445<br />
2.2 0.0442<br />
2.3 0.0431<br />
2.4 0.0424<br />
5.0 0.0413<br />
</tableData><br />
</table><br />
</syntaxhighlight><br />
<br />
Example of table for variable pitch propeller ([http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg32187.html source]):<br />
<br />
<syntaxhighlight lang="xml"><br />
<!-- thrust coefficient as a function of advance ratio and blade angle --><br />
<table name="C_THRUST" type="internal"><br />
<tableData><br />
-10 0 15 25 35 45 55 65 90<br />
-0.2 -0.0734 0.0413 0.1503 0.1842 0.2030 0.2142 0.1974 0.1691 0.0000<br />
0.0 -0.1090 0.0000 0.1503 0.1842 0.2030 0.2162 0.2021 0.1691 0.0000<br />
0.2 -0.1222 -0.0376 0.1297 0.1804 0.2001 0.2162 0.2021 0.1691 0.0000<br />
0.4 -0.1222 -0.0873 0.0977 0.1786 0.1963 0.2142 0.2021 0.1691 0.0000<br />
0.6 -0.1222 -0.1222 0.0517 0.1607 0.1879 0.2087 0.1992 0.1691 0.0000<br />
0.8 -0.1222 -0.1222 0.0029 0.1203 0.1824 0.2012 0.1992 0.1691 0.0000<br />
1.0 -0.1222 -0.1222 -0.0489 0.0734 0.1748 0.1908 0.1974 0.1691 0.0000<br />
1.2 -0.1222 -0.1222 -0.1006 0.0226 0.1437 0.1842 0.1974 0.1691 0.0000<br />
1.4 -0.1222 -0.1222 -0.1222 -0.0329 0.1034 0.1813 0.1936 0.1691 0.0000<br />
1.6 -0.1222 -0.1222 -0.1222 -0.0836 0.0564 0.1748 0.1899 0.1691 0.0000<br />
1.8 -0.1222 -0.1222 -0.1222 -0.1222 0.0095 0.1503 0.1842 0.1691 0.0000<br />
2.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.0376 0.1174 0.1834 0.1691 0.0000<br />
2.2 -0.1222 -0.1222 -0.1222 -0.1222 -0.0846 0.0846 0.1804 0.1691 0.0000<br />
2.4 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0451 0.1473 0.1691 0.0000<br />
2.6 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0057 0.0932 0.1503 0.0000<br />
2.8 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0338 0.0610 0.1222 0.0000<br />
3.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0734 0.0320 0.0940 0.0000<br />
3.2 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1128 0.0029 0.0658 0.0000<br />
3.4 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0263 0.0376 0.0000<br />
3.6 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0555 0.0095 0.0000<br />
3.8 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.0846 -0.0188 0.0000<br />
4.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1137 -0.0471 0.0000<br />
6.0 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 -0.1222 0.0000<br />
</tableData><br />
</table><br />
<br />
<!-- power coefficient as a function of advance ratio and blade angle --><br />
<table name="C_POWER" type="internal"><br />
<tableData><br />
-10 0 15 25 35 45 55 65 90<br />
-0.2 0.0108 0.0215 0.0753 0.1710 0.2949 0.4194 0.4839 0.5355 0.5355<br />
0.0 0.0430 0.0108 0.0645 0.1594 0.2820 0.4194 0.4859 0.5355 0.5355<br />
0.2 0.0613 0.0172 0.0624 0.1484 0.2697 0.4194 0.4859 0.5355 0.5355<br />
0.4 0.0826 0.0376 0.0537 0.1368 0.2562 0.4194 0.4859 0.5355 0.5355<br />
0.6 0.1013 0.0570 0.0355 0.1271 0.2400 0.4110 0.4839 0.5355 0.5355<br />
0.8 0.1194 0.0763 0.0108 0.1078 0.2258 0.3923 0.4839 0.5355 0.5355<br />
1.0 0.1374 0.0948 0.0108 0.0755 0.2129 0.3723 0.4820 0.5355 0.5355<br />
1.2 0.1561 0.0758 -0.0355 0.0290 0.1884 0.3568 0.4788 0.5355 0.5355<br />
1.4 0.1742 0.1310 -0.0536 -0.0215 0.1452 0.3516 0.4729 0.5355 0.5355<br />
1.6 0.1923 0.1497 -0.0626 -0.0645 0.0916 0.3420 0.4626 0.5162 0.5355<br />
1.8 0.2110 0.1678 -0.0645 -0.1078 0.0269 0.3033 0.4484 0.5052 0.5355<br />
2.0 0.2291 0.1858 -0.0826 -0.1503 -0.0323 0.2581 0.4271 0.4949 0.5355<br />
2.2 0.2471 0.2045 -0.1013 -0.1936 -0.0968 0.2097 0.4142 0.4729 0.5355<br />
2.4 0.2658 0.2226 -0.1194 -0.2368 -0.1613 0.1497 0.4020 0.4626 0.5355<br />
2.6 0.2839 0.2407 -0.1374 -0.2794 -0.2045 0.0626 0.3923 0.4465 0.5355<br />
2.8 0.3020 0.2594 -0.1561 -0.3226 -0.2452 -0.0213 0.3839 0.4407 0.5355<br />
3.0 0.3207 0.2774 -0.1742 -0.3658 -0.2903 -0.0968 0.3710 0.4407 0.5355<br />
3.2 0.3387 0.2955 -0.1923 -0.4084 -0.3336 -0.1723 0.3471 0.4304 0.5355<br />
3.4 0.3568 0.3142 -0.2110 -0.4517 -0.3762 -0.2471 0.2691 0.4194 0.5355<br />
3.6 0.3755 0.3323 -0.2291 -0.4949 -0.4194 -0.3226 0.1890 0.4084 0.5355<br />
3.8 0.3936 0.3504 -0.2471 -0.5355 -0.4626 -0.3981 0.1052 0.3955 0.5355<br />
4.0 0.4117 0.3691 -0.2658 -0.5355 -0.5355 -0.4729 0.0213 0.3658 0.5355<br />
6.0 0.5355 0.5355 -0.5355 -0.5355 -0.5355 -0.5355 -0.5355 -0.3226 0.5355<br />
</tableData><br />
</table><br />
<br />
<!-- thrust effects of helical tip Mach --><br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 0.8<br />
</tableData><br />
</table><br />
<br />
<!-- power-required effects of helical tip Mach --><br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 1.8<br />
2.00 1.4<br />
</tableData><br />
</table><br />
<syntaxhighlight lang="xml"><br />
<br />
=== CT_MACH and CP_MACH ===<br />
The CT_MACH and CP_MACH tables are optional. They apply a factor to Ct and Cp based on the helical tip Mach. The CP_MACH table models the [http://en.wikipedia.org/wiki/Drag_divergence_Mach_number Drag Divergence Mach Number] for the propeller airfoil. The CT_MACH table models the thrust reduction.<br />
<br />
Examples:<br />
<br />
<syntaxhighlight lang="xml"><br />
<br />
<!-- thrust effects of helical tip Mach --><br />
<table name="CT_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 0.8<br />
</tableData><br />
</table><br />
<br />
<!-- power-required effects of helical tip Mach --><br />
<table name="CP_MACH" type="internal"><br />
<tableData><br />
0.85 1.0<br />
1.05 1.8<br />
2.00 1.4<br />
</tableData><br />
</table><br />
</syntaxhighlight><br />
<br />
=== Sense ===<br />
Sense is the direction of rotation. 1=clockwise (typically as seen from rear of aircraft or the cockpit of a typical front-propeller aircraft, but this may vary depending on how you have set up the coordinate system for your aircraft) and -1 is counter-clockwise.<br />
<br />
The sense tag goes in the parent tag of the thruster, ie, in the <propulsion><thruster> section which is typically in the main JSBSim XML file. Example:<br />
<br />
<syntaxhighlight lang="xml"><br />
<propulsion><br />
<engine file="Clerget9B"><br />
<location unit="IN"><br />
<x> 12 </x><br />
<y> 0 </y><br />
<z> 0 </z><br />
</location><br />
<orient unit="DEG"><br />
<roll> 0 </roll><br />
<pitch> 0 </pitch><br />
<yaw> 0 </yaw><br />
</orient><br />
<feed>0</feed><br />
<thruster file="CamelProp"><br />
'''<sense>1</sense>'''<br />
<location unit="IN"><br />
<x> 0 </x><br />
<y> 0 </y><br />
<z> 0 </z><br />
</location><br />
<orient unit="DEG"><br />
<roll> 0 </roll><br />
<pitch> 0 </pitch><br />
<yaw> 0 </yaw><br />
</orient><br />
</thruster><br />
</engine><br />
<tank type="FUEL"><br />
<location unit="IN"><br />
<x> 60 </x><br />
<y> 0 </y><br />
<z> -5.62 </z><br />
</location><br />
<capacity unit="LBS">133.6</capacity><br />
<contents unit="LBS">133.6</contents><br />
</tank><br />
</propulsion><br />
</syntaxhighlight><br />
<br />
===Sense bug affecting gyroscopic moment===<br />
Prior to about 2015--and continuing in current JSBSim and FlightGear versions unless you take the corrective steps outlined below--a JSBSim bug cause the gyroscopic moment of the propeller to be reversed.<br />
<br />
To fix this bug and get the correct sign for your gyroscopic effect, you must add version="1.1" (or higher--any version greater than 1.0 should work) to your propeller definition, as shown in this example:<br />
<br />
<syntaxhighlight><br />
<propeller name="prop" version="1.1"><br />
<!-- propeller definition --><br />
</propeller><br />
</syntaxhighlight><br />
<br />
The bug with the sign of gyroscopic effect and the fix are outlined under [https://sourceforge.net/p/jsbsim/bugs/110/ JSBSim Bug #110].<br />
<br />
For most aircraft and engine/propeller systems the gyroscopic effect is fairly subtle and thus the bug is difficult to detect. But for some aircraft, such as small, light, rotary-engined WWI-era aircraft, the gyroscopic effect is very noticeable, and the reverse in direction of the effect created by the bug is very noticeable as well.<br />
<br />
=== Starter speed (for piston engines) ===<br />
There is a somewhat complex relationship among the power coefficient, the maxhp, and idlerpm. Both maxhp and idlerpm are set in the engine xml file.<br />
<br />
The power of the starter motor is equal to 0.4*sqrt(maxhp). The minimum RPM needed to start the engine is 80% of the idlerpm. The greater the power coefficient (for J near 0), the more power the propeller will require to spin when starting the engine with the aircraft at rest.<br />
<br />
If your propeller will not spin fast enough to start, you can try some combination of:<br />
<br />
* Open the throttle. Pulling a partial vacuum in the intake manifold takes some power.<br />
* Increase maxhp (increases the power of the starter motor)<br />
* Decrease idlerpm (decreases the minimum RPM needed to start the engine)<br />
* Decrease the power coefficient in the C_POWER table, for values of J close to (or equal to) 0. This will reduce the amount of power it takes for the propeller to spin at a given RPM where J is close to 0 (which is the typical situation when starting the engine and the aircraft is at a dead stop).<br />
<br />
You can open the property tree and watch the value of J (/fdm/jsbsim/propulsion/engines/advance-ratio) to get an idea of which values you need to change in the C_POWER table.<br />
<br />
''' Code is in FG 2.8 to independently control the power of the piston starter motor, to include battery effects. '''<br />
starter-torque (fgfs 2.8) is a value specifying the zero RPM torque in lb*ft the starter motor provides. Current default value is 40% of the maximum horsepower value.<br />
starter-rpm (fgfs 2.8) is a value specifying the maximum RPM the unloaded starter motor can achieve. Loads placed on the engine by the propeller and throttle will further limit RPM achieved in practice. Peak starter power is achieved at 1/2 starter-rpm. At 1/2 starter-rpm torque is 1/2 starter-torque. Peak power can be calculated by the standard formula HP=(Torque*RPM)/5252<br />
<br />
=== Development tips ===<br />
* If you open the property tree browser within FG to /fdm/jsbsim/propulsion/engines you can see a number of helpful variables in action, including RPM, horsepower, advance ratio, thrust coefficient, and others.<br />
<br />
=== References ===<br />
* Barnes W. McCormick, "Aerodynamics, Aeronautics, and Flight Mechanics", Wiley & Sons, 1979 ISBN 0-471-03032-5<br />
* Edwin Hartman, David Biermann, "The Aerodynamic Characteristics of Full Scale Propellers Having 2, 3, and 4 Blades of Clark Y and R.A.F. 6 Airfoil Sections", NACA Report TN-640, 1938 (?)<br />
* Various NACA Technical Notes and Reports<br />
<br />
== FGRotor ==<br />
FGRotor models a helicopter rotor.<br />
<br />
=== Configuration file format ===<br />
<syntaxhighlight lang="xml"><br />
<!-- Sense goes in the parent tag --><br />
<sense> {1 | 0 | -1} </sense><br />
<?xml version="1.0"?> <br />
<rotor name="{string}"><br />
<diameter unit="{LENGTH}"> {number} </diameter><br />
<numblades> {number} </numblades><br />
<gearratio> {number} </gearratio><br />
<nominalrpm> {number} </nominalrpm><br />
<minrpm> {number} </minrpm><br />
<maxrpm> {number} </maxrpm> <br />
<chord unit="{LENGTH}"> {number} </chord><br />
<liftcurveslope Xunit="1/RAD"> {number} </liftcurveslope><br />
<twist unit="{ANGLE}"> {number} </twist><br />
<hingeoffset unit="{LENGTH}"> {number} </hingeoffset><br />
<flappingmoment unit="{MOMENT}"> {number} </flappingmoment><br />
<massmoment Xunit="SLUG*FT"> {number} </massmoment><br />
<polarmoment unit="{MOMENT}"> {number} </polarmoment><br />
<inflowlag> {number} </inflowlag><br />
<tiplossfactor> {number} </tiplossfactor><br />
<maxbrakepower unit="{POWER}"> {number} </maxbrakepower><br />
<br />
<controlmap> {MAIN|TAIL|TANDEM} </controlmap><br />
<ExternalRPM> {number} </ExternalRPM><br />
<br />
<groundeffectexp> {number} </groundeffectexp><br />
<groundeffectshift unit="{LENGTH}"> {number} </groundeffectshift><br />
</rotor><br />
</syntaxhighlight><br />
<br />
* LENGTH means any of the supported units, same for ANGLE and MOMENT.X unit-attributes are a hint for currently unsupported units, so values must be provided accordingly.<br />
<br />
=== Parameter definitions ===<br />
{| class="prettytable"<br />
|-<br />
|diameter<br />
|Rotor disk diameter (2x R).<br />
|-<br />
|numblades<br />
|Number of blades (b).<br />
|-<br />
|gearratio<br />
|Ratio of (engine rpm) / (rotor rpm), usually > 1.<br />
|-<br />
|nominalrpm<br />
|RPM at which the rotor usally operates. <br />
|-<br />
|minrpm<br />
|Lowest RPM used in the model, optional and defaults to 1.<br />
|-<br />
|maxrpm<br />
|Largest RPM used in the model, optional and defaults to 2 x nominalrpm. <br />
|-<br />
|chord<br />
|Blade chord, (c).<br />
|-<br />
|liftcurveslope<br />
|Slope of curve of section lift against section angle of attack, per rad (a).<br />
|-<br />
|twist<br />
|Blade twist from root to tip, (theta_1).<br />
|-<br />
|hingeoffset<br />
|Rotor flapping-hinge offset (e).<br />
|-<br />
|flappingmoment<br />
|Flapping moment of inertia (I_b).<br />
|-<br />
|massmoment<br />
|Blade mass moment. Mass of a single blade times the blade's cg-distance from the hub, optional.<br />
|-<br />
|polarmoment<br />
|Moment of inertia for the whole rotor disk, optional.<br />
|-<br />
|inflowlag<br />
|Rotor inflow time constant, sec. Smaller values yield to quicker responses (typical values for main rotor: 0.1 - 0.2 s).<br />
|-<br />
|tiplossfactor<br />
|Tip-loss factor. The Blade fraction that produces lift. Value usually ranges between 0.95 - 1.0, optional (B).<br />
|-<br />
|maxbrakepower<br />
|Rotor brake, 20-30 hp should work for a mid size helicopter.<br />
|-<br />
|controlmap<br />
|Defines the control inputs used (see notes).<br />
|-<br />
|ExternalRPM<br />
|Links the rotor to another rotor, or an user controllable property.<br />
<br />
Experimental properties<br />
|-<br />
|groundeffectexp<br />
|Exponent for ground effect approximation. Values usually range from 0.04 for large rotors to 0.1 for smaller ones. As a rule of thumb the effect vanishes at a height 2-3 times the rotor diameter. formula used: exp ( - groundeffectexp * (height+groundeffectshift) ) Omitting or setting to 0.0 disables the effect calculation.<br />
|-<br />
|groundeffectshift<br />
|Further adjustment of ground effect, approx. hub height or slightly above. <br />
|}<br />
<br />
=== Notes ===<br />
==== Controls ====<br />
The behavior of the rotor is controlled/influenced by following inputs.<br />
* The power provided by the engine. This is handled by the regular engine controls.<br />
* The collective control input. This is read from the <tt>fdm</tt> property <tt>propulsion/engine[x]/collective-ctrl-rad</tt>. See below for tail rotor<br />
* The lateral cyclic input. Read from <tt>propulsion/engine[x]/lateral-ctrl-rad</tt>.<br />
* The longitudinal cyclic input. Read from <tt>propulsion/engine[x]/longitudinal-ctrl-rad</tt>.<br />
** The tail collective (aka antitorque, aka pedal) control input. Read from <tt>propulsion/engine[x]/antitorque-ctrl-rad</tt> or <tt>propulsion/engine[x]/tail-collective-ctrl-rad</tt>. <br />
<br />
==== Tail/tandem rotor ====<br />
Providing '''&lt;ExternalRPM&gt; 0 &lt;/ExternalRPM&gt;''' the tail rotor's RPM is linked to to the main (=first, =0) rotor, and specifying '''&lt;controlmap&gt; TAIL &lt;/controlmap&gt;''' tells this rotor to read the collective input from '''propulsion/engine[1]/antitorque-ctrl-rad''' (The TAIL-map ignores lateral and longitudinal input). The rotor needs to be attached to a dummy engine, e.g. an 1HP electrical engine. A tandem rotor is setup analogous.<br />
<br />
==== Sense ====<br />
The 'sense' parameter from the thruster is interpreted as follows, sense=1 means counter clockwise rotation of the main rotor, as viewed from above. This is as a far as I know more popular than clockwise rotation, which is defined by setting sense to -1. Concerning coaxial designs - by setting 'sense' to zero, a Kamov-style rotor is modeled (i.e. the rotor produces no torque).<br />
<br />
==== Engine issues ====<br />
In order to keep the rotor speed constant, use of a RPM-Governor system is encouraged (see examples).<br />
<br />
==== Development hints ====<br />
Setting '''&lt;ExternalRPM&gt; -1 &lt;/ExternalRPM&gt;''' the rotor's RPM is controlled by the '''propulsion/engine[x]/x-rpm-dict''' property. This feature can be useful when developing a FDM.<br />
<br />
==== Properties ====<br />
The rotor model creates the following properties:<br />
<br />
{| class="prettytable"<br />
|-<br />
|propulsion/engine[#]/rotor-rpm<br />
|RPMs of the rotor<br />
|-<br />
|propulsion/engine[#]/engine-rpm<br />
|RPMs of the Engine, as seen from this rotor.<br />
|-<br />
|propulsion/engine[#]/a0-rad<br />
|Rotor's coning angle in radians<br />
|-<br />
|propulsion/engine[#]/a1-rad<br />
|Longitudinal flapping angle with respect to the rotor shaft in radians<br />
|-<br />
|propulsion/engine[#]/b1-rad<br />
|Lateral flapping angle with respect to the rotor shaft in radians<br />
|-<br />
|propulsion/engine[#]/inflow-ratio<br />
| Lambda or λ<br />
|-<br />
|propulsion/engine[#]/advance-ratio<br />
|the tip-speed (aka advance) ratio Mu or μ<br />
|-<br />
|propulsion/engine[#]/induced-inflow-ratio<br />
| Nu or ν<br />
|-<br />
|propulsion/engine[#]/vi-fps<br />
|Induced Velocity in feet per second<br />
|-<br />
|propulsion/engine[#]/thrust-coefficient<br />
|<br />
|-<br />
|propulsion/engine[#]/torque-lbsft<br />
| Rotor torque in pound * feet<br />
|-<br />
|propulsion/engine[#]/theta-downwash-rad<br />
|Down wash θ angle - positive values point forward (given a horizontal spinning rotor) in radians<br />
|-<br />
|propulsion/engine[#]/phi-downwash-rad<br />
|Down wash Φ angle - positive values point leftward (given a horizontal spinning rotor) in radians<br />
|-<br />
|propulsion/engine[#]/groundeffect-scale-norm<br />
|<br />
|}<br />
<br />
(Control Inputs)<br />
{| class="prettytable"<br />
|-<br />
|propulsion/engine[#]/antitorque-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/tail-collective-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/lateral-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/longitudinal-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/collective-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/lateral-ctrl-rad<br />
|<br />
|-<br />
|propulsion/engine[#]/longitudinal-ctrl-rad<br />
|<br />
|}<br />
<br />
=== References ===<br />
{| class="prettytable"<br />
|-<br />
|SH79<br />
|Shaugnessy, J. D., Deaux, Thomas N., and Yenni, Kenneth R., "Development and Validation of a Piloted Simulation of a Helicopter and External Sling Load", NASA TP-1285, 1979.<br />
|-<br />
|BA41<br />
|Bailey,F.J.,Jr., "A Simplified Theoretical Method of Determining the Characteristics of a Lifting Rotor in Forward Flight", NACA Rep.716, 1941<br />
|-<br />
|AM50<br />
|Amer, Kenneth B.,"Theory of Helicopter Damping in Pitch or Roll and a Comparison With Flight Measurements", NACA TN-2136, 1950.<br />
|-<br />
|TA77<br />
|Talbot, Peter D., Corliss, Lloyd D., "A Mathematical Force and Moment Model of a UH-1H Helicopter for Flight Dynamics Simulations", NASA TM-73,254, 1977.<br />
|-<br />
|GE49<br />
|Gessow, Alfred, Amer, Kenneth B. "An Introduction to the Physical Aspects of Helicopter Stability", NACA TN-1982, 1949.<br />
|}<br />
<br />
{{JSBSim}}</div>Flughttps://wiki.flightgear.org/w/index.php?title=Head_tracking&diff=107217Head tracking2017-02-28T08:40:23Z<p>Flug: /* Forum topics */ New forum topic on this topic</p>
<hr />
<div>'''Head tracking''' or '''face tracking''' allow the in-sim view follows your head movements. Head tracking is usually done for two similar purposes: Either to pan and translate the view presented on a screen, or to make the view of augmented or virtual reality goggles follow your head movements.<br />
<br />
Though there is no head tracking built into FlightGear (as of may 2016) there are still various ways to achieve that.<br />
<br />
More exotic uses of head tracking is to have a high resolution projector follow your head movements, while having a few low resolution projectors that only will be visible in your peripheral view.<br />
<br />
== Degrees of freedom ==<br />
Degrees of freedom (DoF) are very common measure of the capability of a head tracking solution. It is the number of axis the view can be rotated or translated around or along.<br />
<br />
For example would simple horizontal panning be 1 DoF (in essence rotation around the Z axis), while all translations and rotations would be 6 DoF (rotation around x, y and z + translation along x, y and z).<br />
<br />
== Screen view vs. VR view panning ==<br />
While you obviously would like a VR goggle view to precisely follow your head movements, you can not do that if you want to have the view on a screen in front of you. To be able to still see the screen when you are panning the view to directly behind, the translations usually are scaled down when head tracking is used for panning the view on a screen.<br />
<br />
While one or two DoF may be satisfactory when you are using head tracking to pan a screen view, three or sometimes six DoF is usually wanted when using VR goggles. Having six DoF with goggles usually requires requires external head tracking to capture the head movements as accelerometers are too noisy and will drift.<br />
<br />
== Head tracking solutions ==<br />
There are many ways to do head tracking. The solutions cheapest to implement will use your web camera and will follow your face or some markers to figure out where your head is and how it is rotated.<br />
<br />
The more expensive ones use IR cameras, either using a group of LED light markers or IR lights at the camera and reflective markers. The last method is used by some of the more popular commercial products. Often there is three or four markers grouped together with fixed relative positions that is attached to headwear or headphones.<br />
<br />
== Using head tracking in FlightGear ==<br />
As FlightGear is very flexible there are many ways head tracking can be implemented. Often some external head tracking software will [[Interfacing FlightGear|interface with FlightGear]] for example using a [[generic protocol]] such that the rotations and translations is read into [[Property tree|properties]] that in turn are used for panning and moving the view.<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[FaceTrackNoIR]]<br />
* [[Input device]]<br />
* [[Interfacing FlightGear]]<br />
* [[Howto:Wii Remote Head Tracking]]<br />
<br />
=== Forum topics ===<br />
* [https://forum.flightgear.org/viewtopic.php?f=24&t=29560 Setting up my flight gear?] <small>May 2016</small><br />
* [https://forum.flightgear.org/viewtopic.php?f=24&t=28718 How-to: motion tracking controller using vJoy and FreePIE] <small>February 2016</small><br />
* [https://forum.flightgear.org/viewtopic.php?f=24&t=31757&p=306068#p306068 TrackIR, EDTracker, vJoy, FreePIE, OpenTrack - headtracking solution for FlightGear] <small>February 2017</small><br />
* [https://forum.flightgear.org/viewtopic.php?f=6&t=10664 Headtrack] <small>January 2011–November 2015</small><br />
* [https://forum.flightgear.org/viewtopic.php?f=25&t=19848 FaceTracking: which views are movable ?] <small>May–June 2013</small><br />
* [https://forum.flightgear.org/viewtopic.php?f=36&t=16052 Offset problem with infra-red headtracker] <small>April 2012</small><br />
* [https://forum.flightgear.org/viewtopic.php?f=3&t=12412 Something for your sim pit? (Eye-following projector)] <small>June 2011</small><br />
* [https://forum.flightgear.org/viewtopic.php?f=6&t=11345 linux-track and FlightGear] <small>March 2011–March 2014</small><br />
* [https://forum.flightgear.org/viewtopic.php?f=19&t=11296 Typhoon+Grand Canyon+FaceTrackNoIR=AwEsOmE] <small>March 2011</small><br />
* [https://forum.flightgear.org/viewtopic.php?f=36&t=8499 First update FaceTrackNoIR] <small>June 2010–March 2011</small><br />
* [https://forum.flightgear.org/viewtopic.php?f=17&t=4763 Anything new related to FreeTrack/TrackIR?] <small>April 2009–July 2010</small><br />
* [https://forum.flightgear.org/viewtopic.php?f=36&t=212 Integration with OpenCV] <small>February 2007</small><br />
<br />
=== Developer mailing list threads ===<br />
* [https://sourceforge.net/p/flightgear/mailman/message/34768232/ <nowiki>[</nowiki>Flightgear-devel<nowiki>]</nowiki> SteamVR ] <small>January 2016</small><br />
* [https://sourceforge.net/p/flightgear/mailman/message/30602798/ <nowiki>[</nowiki>Flightgear-devel<nowiki>]</nowiki> Kinect for pc for head tracking?] <small>March 2013</small><br />
* [https://sourceforge.net/p/flightgear/mailman/message/27944122/ <nowiki>[</nowiki>Flightgear-devel<nowiki>]</nowiki> FG Input though socket or anyway? ] <small>August 2011</small><br />
* [https://sourceforge.net/p/flightgear/mailman/message/25067844/ <nowiki>[</nowiki>Flightgear-devel<nowiki>]</nowiki> Enable headtracking in FlightGear?] <small>April 2010</small><br />
* [https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/20080131170535.58250%40gmx.net/#msg18464396 <nowiki>[</nowiki>Flightgear-devel<nowiki>]</nowiki> Depth percepted cockpit] <small>January–February 2008</small><br />
* [https://sourceforge.net/p/flightgear/mailman/message/15602328/ <nowiki>[</nowiki>Flightgear-devel<nowiki>]</nowiki> Extending generic protocol for binary input streams.] <small>September 2007–March 2009</small><br />
* [https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/76d708440605102214i67cc8305sf6abbb28b8418223%40mail.gmail.com/#msg13176413 <nowiki>[</nowiki>Flightgear-devel<nowiki>]</nowiki> Formation Flying] <small>May 2006</small><br />
<br />
=== Source code ===<br />
* {{fgdata source|Nasal/view.nas}} – ''[[Nasal]] module that handles the view panning and translation, and related properties.''<br />
<br />
[[Category:FlightGear]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Aircraft-set.xml&diff=107211Aircraft-set.xml2017-02-27T04:46:57Z<p>Flug: /* The -set.xml file itself */ startup section</p>
<hr />
<div>The '''aircraft-set.xml''' file (or rather ''name-of-aircraft''-set.xml) is the top level aircraft configuration file. The aircraft-set.xml file should be in the aircraft's root directory, for example <code>[[$FG_ROOT]]/Aircraft/747-400/747-400-set.xml</code>.<br />
<br />
When FlightGear loads an aircraft the aircraft-set.xml file is from where all the other aircraft specific configuration and other files are read in. It also can contain the meta data that is used for example when packaging the aircraft before a release of FlightGear.<br />
<br />
== Overview ==<br />
The aircraft-set.xml file is an XML file that contain for example:<br />
<br />
* A header with for example a description and names of the authors<br />
* [[Aircraft rating system|Aircraft ratings]] that can be used to select only the more well developed aircraft (or bad ones if you are looking for aircraft to improve)<br />
* [[Howto:Reassign keyboard bindings|Keyboard bindings]]<br />
* Paths to [[Nasal]] modules<br />
* Paths to configuration files for the [[Flight Dynamics Model|flight dynamics model]] (FDMs), [[Howto:Animate models|3D models and their animations]], [[Autopilot configuration reference|autopilot]], [[Howto:Add sound effects to aircraft|sound]] etc.<br />
<br />
FlightGear allows a great deal of flexibility when it comes to how to configure an aircraft.<br />
<br />
To help provide a more consistent experience for end users, aircraft developers are encouraged to use [[Release:Aircraft Selection Criteria]] as a guide when preparing an aircraft for inclusion in the [[FGAddon]] aircraft repository, especially if you are hoping for your aircraft to become part of the default distribution, such as the c172p for example.<br />
<br />
== The aircraft-set.xml file name ==<br />
The ''name-of-aircraft'' portion of ''name-of-aircraft''-set.xml is the name of the aircraft that is used for example when starting FlightGear from the command line (using the <code>--aircraft=''name-of-aircraft''</code> option). For example, if the file name is<br />
<br />
fkdr1-set.xml<br />
<br />
Then the command line to start with that aircraft is something like:<br />
<br />
fgfs.exe --aircraft=fkdr1<br />
<br />
=== Multiple aircraft-set.xml files ===<br />
This naming convention gives you the opportunity to create two (or more) aircraft within the aircraft package root directory. For instance one could create two versions of an aircraft using different FDMs, but sharing many or most other features (and .xml files/models), using the following file names:<br />
<br />
fkdr1-yasim-set.xml<br />
fkdr1-uiuc-set.xml<br />
<br />
=== Not used for loading multiplayer aircraft ===<br />
The aircraft-set.xml aircraft name is not used when loading models in [[Howto:Multiplayer|multiplayer]]. As only the model and animations are of interest, instead the path to the aircraft model is transmitted with the multiplayer packets (in essence the string in the <code>/sim/model/path</code> [[Property tree|property]]).<br />
<br />
There is also a feature that will load an AI aircraft model if it shares the same path, in essence from<br />
<br />
[[$FG_ROOT]]/'''AI'''/Aircraft/''Aircraft-name''/Models/''Model-and-animation-configuration''.xml<br />
<br />
instead of<br />
<br />
$FG_ROOT/Aircraft/''Aircraft-name''/Models/''Model-and-animation-configuration''.xml<br />
<br />
Note that the AI aircraft model need not be an XML file with a model and animation configuration, but can also be a plain .ac (AC3D) file with a 3D model.<br />
<br />
Unfortunately, as this feature have been rather unknown and possibly undocumented for many years, few aircraft developers have provided such a model with their aircraft.<br />
<br />
Needless to say, aircraft developers are highly encouraged to provide such a model with the aircraft.<br />
<br />
== The property tree ==<br />
{{main article|Property tree}}<br />
<br />
The property tree contain a tree-like representation of various key-value pair properties that are used for configuration of and communication between different parts of FlightGear.<br />
<br />
Most of the properties can be set using various configuration files and can be manipulated while FlightGear is running. Some of them are manipulated by FlightGear itself, some by the FDM, some by aircraft systems and [[Nasal]] scripts. Properties can also be manipulated manually when FlightGear is running using the [[property browser]].<br />
<br />
== The -set.xml file itself ==<br />
The aircraft-set.xml file is a [[PropertyList XML files|PropertyList XML file]] that will configure properties in the property tree when an aircraft is loaded. Properties can also be added as needed.<br />
<br />
While the aircraft-set.xml file is very flexible and can be dauntingly complex for some aircraft this description will only deal with the most commonly used tags within the <code>&lt;sim&gt;</code> tags.<br />
<br />
{{note|Most of these tags are optional.}}<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<PropertyList><br />
<sim><br />
</syntaxhighlight><br />
<br />
XML file header and opening <code>&lt;PropertyList&gt;</code> and <code>&lt;sim&gt;</code> tags<br />
<br />
<syntaxhighlight lang="xml"><br />
<description><!-- Short description of the aircraft --></description><br />
</syntaxhighlight><br />
<br />
The description that will be shown in the aircraft selection dialog of [[FGRun]] and other GUIs.<br />
<br />
<syntaxhighlight lang="xml"><br />
<aircraft-version><!-- Version --></aircraft-version><br />
</syntaxhighlight><br />
<br />
Version of the aircraft. Often the date of the last change or a version number.<br />
<br />
<!--<br />
<br />
<syntaxhighlight lang="xml"><br />
<minimum-flightgear-version>4.0.0</minimum-flightgear-version><br />
</syntaxhighlight><br />
{{Main article|FlightGear Version Check}}<br />
<br />
Minimum FlightGear version required for this aircraft [http://forum.flightgear.org/viewtopic.php?f=4&t=28010&p=264797#p264788], note that this is a "soft" requirement - i.e. it will not terminate fg or trigger an error, but only show a warning in the console/fg window using a Nasal script that checks if the property is set. This is mainly intended to make compatibility issues more obvious, i.e. end-users downloading new aircraft and wanting to use them in conjunction with an old version of FlightGear, which is causing quite a bit of workload on the support forum.<br />
We are hoping to also display this info in the [[About dialog]]<br />
--><br />
<syntaxhighlight lang="xml"><br />
<rating><br />
<FDM type="int"><!-- 1..5 --></FDM><br />
<systems type="int"><!-- 1..5 --></systems><br />
<cockpit type="int"><!-- 1..5 --></cockpit><br />
<model type="int"><!-- 1..5 --></model><br />
</rating><br />
<!-- or --><br />
<status></status><br />
</syntaxhighlight><br />
<br />
Either the aircraft rating or development status. The aircraft ratings uses the the criteria outlined in the article [[Aircraft rating system]], that gives a reasonably objective rating based on the availability and quality of various aspects of the aircraft. The aircraft rating system has been available since about FlightGear 2.0. The development status usually is either of ''Alpha'', ''Beta'', ''Production'' or ''Stable'', in essence the developments statuses often used in software development.<br />
<br />
When using the aircraft rating system, a development status is applied automatically based on the ratings.<br />
<br />
<syntaxhighlight lang="xml"><br />
<author><!-- Name of author (development area), Name of author (development area), etc. --></author><br />
</syntaxhighlight><br />
<br />
Names of the authors. If multiple people worked on an aircraft, the specific development area for each person is often shown within parenthesis after the name.<br />
<br />
<syntaxhighlight lang="xml"><br />
<flight-model><!-- FDM --></flight-model><br />
</syntaxhighlight><br />
<br />
The FDM the aircraft is using. Use <code>yasim</code> for [[YASim]] and <code>jsb</code> for [[JSBSim]].<br />
<br />
<syntaxhighlight lang="xml"><br />
<aero><!-- Truncated file path --></aero><br />
</syntaxhighlight><br />
<br />
The filename of the FDM file, without <code>.xml</code>. For instance, if your FDM file is sopwithCamel1F1.xml, the aero section would look like <code><nowiki><aero>sopwithCamel1F1</aero></nowiki></code>.<br />
<br />
The next section is the <code><startup></code> section, which can contain two elements: <br />
<br />
<syntaxhighlight lang="xml"><br />
<splash-texture><!-- File path --></splash-texture><br />
</syntaxhighlight><br />
<br />
Path to an image you would like to show during loading of the aircraft. FlightGear will randomly pick one of the generic splashes in <code>[[$FG ROOT]]/Textures/</code> when this line is not found in the aircraft-set.xml file.<br />
<br />
<syntaxhighlight lang="xml"><br />
<splash-title><!-- Title --></splash-title><br />
</syntaxhighlight><br />
<br />
A small text to be shown above the splash texture during loading of an aircraft.<br />
<br />
Example:<br />
<br />
<syntaxhighlight lang="xml"><br />
<startup><br />
<splash-texture>images/splash.jpg</splash-texture><br />
<splash-title>My Aircraft!</splash-title><br />
</startup><br />
</syntaxhighlight><br />
<br />
</syntaxhighlight><br />
<br />
<br />
<syntaxhighlight lang="xml"><br />
<model><br />
<path><!-- File path --></path><br />
</model><br />
</syntaxhighlight><br />
<br />
The file path to either a plain .ac (AC3D) 3D model or a model and animation configuration XML file.<br />
<br />
This path is also used when loading multiplayer aircraft. For more details, see the [[#Not used for loading multiplayer aircraft]] section above.<br />
<br />
<syntaxhighlight lang="xml"><br />
<sound><br />
<path><!-- File path --></path><br />
</sound><br />
</syntaxhighlight><br />
<br />
The path to a [[Howto:Add sound effects to aircraft|sound configuration XML file]]. If for example you find a nice WAV file of the jet engine you're using, you can fix it up with your favorite sound editor so it loops nicely and include that into your model (I've noticed a few models where it can get quite annoying when the loop length is so small you can really notice it) so make it smooth.<br />
<br />
<syntaxhighlight lang="xml"><br />
<panel><br />
<path><!-- File path --></path><br />
</panel><br />
</syntaxhighlight><br />
<br />
File path to the 2D panel configuration XML file. We prefer 3D cockpits, which are linked in the model .xml file.<br />
<br />
<syntaxhighlight lang="xml"><br />
<autopilot><br />
<path><!-- File path --></path><br />
</autopilot><br />
</syntaxhighlight><br />
<br />
File path to the autopilot configuration XML file. For details, see for example [[Autopilot configuration reference]].<br />
<br />
<syntaxhighlight lang="xml"><br />
<checklists include=""/> <!-- File name --><br />
</syntaxhighlight><br />
<br />
Configuration XML file defining a [[Aircraft Checklists|checklist]] (available since version 3.0).<br />
<br />
<syntaxhighlight lang="xml"><br />
<variant-of><!-- Aircraft --></variant-of><br />
</syntaxhighlight><br />
<br />
Since 3.6, there is a new <code>&lt;variant-of&gt;</code> tag that can be added. This is used by the [[Integrated Qt5 Launcher|integrated Qt5 launcher]] to easily select a variant of an aircraft. For example, the [[British Aerospace Sea Harrier|BAe Sea Harrier FA2]] is a variant of the BAe Sea Harrier, and the ''Cessna 172P - Canvas Demo'' is a variant of the [[Cessna 172P]]. Additionally, this could be used for different [[Talk:Aircraft_Checklists#In-air_startups_.26_supporting_Startup_Situations|startup situations]] too.<br />
<br />
Example from the {{fgaddon aircraft source|777|777-200ER-set.xml|l=11|text=777-200ER-set.xml}}: <code>&lt;variant-of&gt;777-200&lt;/variant-of&gt;</code><br />
<br />
<syntaxhighlight lang="xml"><br />
</sim><br />
<PropertyList><br />
</syntaxhighlight><br />
<br />
Closing <code>&lt;sim&gt;</code> and <code>&lt;PropertyList&gt;</code> tags<br />
<br />
== Related content ==<br />
* [[Aircraft Generation Wizard]] (stalled as of 12/2013)<br />
* [[Aircraft rating system]]<br />
* [[Howto:3D Aircraft Models]]<br />
* [[Howto:Add sound effects to aircraft]]<br />
* [[Howto:Animate models]]<br />
* [[Release:Aircraft Selection Criteria]]<br />
<br />
[[Category:Aircraft enhancement]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Howto:Add_sound_effects_to_aircraft&diff=107072Howto:Add sound effects to aircraft2017-02-24T06:00:39Z<p>Flug: /* Configuration tags */ conditions</p>
<hr />
<div>You can '''add sound effects to aircraft''' by adding the sound samples and configuring the sound effects in XML files. The sound effects can be conditional and the sound's pitch and volume can depend on properties in the property tree. <br />
<br />
Some sound effects are added other ways. For example, sounds from avionics like navigation radio receivers are automatically added when you add those radios.<br />
<br />
{{FGCquote|1= The volume calculation due to distance and orientation of the sounds source ONLY work on mono samples!|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/28505220/ | title = <nowiki>Re: [Flightgear-devel] Stereo sounds no longer supported?</nowiki> | author = <nowiki>syd adams</nowiki> | date = Dec 7th, 2011 }}}}<br />
<br />
{{FGCquote|1= The old way was that the stereo sound would always play the left channel on the left side. Now you split the sound and place it in 3D space. When you turn your head, the speaker the left side sound comes out of changes with you|2= {{cite web | url = http://forum.flightgear.org/viewtopic.php?p=257291#p257291 | title = <nowiki>Re: 787-8 Boarding music</nowiki> | author = <nowiki>bugman</nowiki> | date = Sep 14th, 2015 }}}}<br />
<br />
{{FGCquote|1= All sounds must now be mono point sources, and stereo simply requires the two sound sources to be positioned in the 3D environment. |2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34100151/ | title = <nowiki>[Flightgear-devel] Audit and proposal for handling non-supported stereo sound files in FGAddon via the 3D sound engine.</nowiki> | author = <nowiki>Edward d'Auvergne</nowiki> | date = May 10th, 2015 }}}}<br />
<br />
{{FGCquote|1= We use OpenAL for 3D positional audio and most OpenAL implementations can only handle one stereo file.Also Stereo files will not work in 3d space, so they will not be positional.But most aircraft developers did not know that and used several stereo files expecting everything to work properly but the truth was that in most implementations just one of those stereo files was played.And if you think of it, stereo separation does not work for boarding music either since it plays left channel to your left ear and right channel to your right ear. But in reality boarding music is played left channel to the left audio channel in the aircraft and right channel to the right audio channel in the aircraft.This works the same as normal stereo if you enter the aircraft, but will, reverse once you turn around.So the solution is to split up the stereo file into two mono files and play the proper channel at the proper side of the passenger compartment.|2= {{cite web | url = http://forum.flightgear.org/viewtopic.php?p=257289#p257289 | title = <nowiki>Re: 787-8 Boarding music</nowiki> | author = <nowiki>erik</nowiki> | date = Sep 14th, 2015 }}}}<br />
<br />
== Sound configuration files ==<br />
The sound configuration files are [[PropertyList XML files]].<br />
<br />
The top level sound configuration file is composed of a <code>&lt;fx&gt;</code> and a <code>&lt;name&gt;</code> tag, a <code>&lt;path&gt;</code> to a sound sample file and zero or more <code>&lt;volume&gt;</code> and/or <code>&lt;pitch&gt;</code>definitions.<br />
<br />
Paths are relative to [[$FG_ROOT]], but absolute paths may also be used.<br />
<br />
Comments are bracketed with <code>&lt;!-- --&gt;</code>.<br />
<br />
=== Example ===<br />
This example would define an engine sound effect for a piston engine driven aeroplane.<br />
<br />
The sound effect representing the engine is located in <code>$FG_ROOT/Sounds</code> and is named <code>wasp.wav</code>. The effect is started when the property <code>/engines/engine/running</code> becomes non-zero. <br />
<br />
When that happens, the sound will be played looped (see <code>&lt;mode&gt;</code>) until the property returns zero again. As you can see the volume is dependent on the property <code>/engines/engine/mp-osi</code>, and the pitch of the sound depends on the property <code>/engines/engine/rpm</code>.<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<PropertyList><br />
<fx><br />
<engine><br />
<name>engine</name><br />
<path>Sounds/wasp.wav</path><br />
<mode>looped</mode><br />
<condition><br />
<property>/engines/engine/running</property><br />
</condition><br />
<volume><br />
<property>/engines/engine/mp-osi</property><br />
<factor>0.005</factor><br />
<min>0.15</min><br />
<max>0.5</max><br />
<offset>0.15</offset><br />
</volume><br />
<pitch><br />
<property>/engines/engine/rpm</property><br />
<factor>0.0012</factor><br />
<min>0.3</min><br />
<max>5.0</max><br />
<offset>0.3</offset><br />
</pitch><br />
</engine><br />
</fx><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
=== Inclusion from the aircraft-set.xml file ===<br />
In order for the sound configuration to be used, it has to be included from the [[aircraft-set.xml]] file.<br />
<br />
This can be done by adding the path to the file relative to the aircraft's base path within the <code>&lt;sim&gt;</code> tags in the aircraft-set.xml file..<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<PropertyList><br />
<!-- ... ---><br />
<sim><br />
<!-- ... ---><br />
<sound><br />
<path type="string">My-sound-config.xml</path><br />
</sound><br />
<!-- ... ---><br />
</sim><br />
<!-- ... ---><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
== Configuration tags ==<br />
<br />
; <code>&lt;fx&gt;</code><br />
: Named FX subtree living under /sim/sound<br />
<br />
; <code>&lt; ... &gt;</code><br />
: This is the event separator. The text inside the brackets can be anything, but it is advised to give it a meaningful name like: crank, engine, rumble, gear, squeal, flap, wind or stall.<br />
<br />
: The value can be defined multiple times, thus anything which is related may have the same name (grouping them together).<br />
<br />
; <code>&lt;name&gt;</code><br />
: This defines the name of the event. This name is used internally and, although it can me defined multiple times in the same file, should normally have an unique value.<br />
<br />
: Multiple definitions of the same name will allow multiple sections to interfere in the starting and stopping of the sample.<br />
<br />
: This method can't be used to control the pitch or volume of the sample, but instead multiple volume or pitch section should be included inside the same event.<br />
<br />
: The types "raise" and "fall" will stop the playback of the sample regardless of any other event. This means that when the type "raise" is supplied, sample playback will stop when the event turns false. Using the type "fall" will stop playback when the event turns true.<br />
<br />
: IMPORTANT<br />
:: If the trigger is used for anything else but stopping the sound at a certain event, all sections with the same name ''should'' have exactly the same sections for everything but property and type.<br />
<br />
:: In the case of just stopping the sample at a certain event, the sections for path, volume and pitch may be omitted.<br />
<br />
; <code>&lt;path&gt;</code><br />
: This defined the path to the sound file. The path is relative to the FlightGear root directory but could be specified absolute.<br />
<br />
: The sound format must be mono.<br />
<br />
; <code>&lt;condition&gt;</code><br />
: Define a condition that triggers the event.<br />
<br />
: For a complete description of the FlightGear conditions, please read docs-mini/README.conditions or read the [[Conditions]] article on the wikie.<br />
<br />
: An event should define either a condition or a property.<br />
<br />
; <code>&lt;property&gt;</code><br />
: Define which property triggers the event, and refers to a node in the FlightGear property tree.<br />
<br />
: Action is taken when the property is non zero.<br />
<br />
: A more sophisticated mechanism to trigger the event is described in <condition&gt;</code><br />
<br />
; <code>&lt;mode&gt;</code><br />
: This defines how the sample should be played:<br />
<br />
:; once<br />
:: The sample is played once. This is the default.<br />
<br />
:; looped<br />
:: The sample plays continuously, until the event turns false.<br />
<br />
:; in-transit<br />
:: the sample plays continuously, while the property is changing its value.<br />
<br />
; <code>&lt;type&gt;</code><br />
: This defines the type os this sample:<br />
<br />
:; fx<br />
:: This is the default type and doesn't need to be defined.<br />
<br />
:; avionics<br />
:: Sounds set to this time don't have a position and orientation but are treated as if it's mounted to the aircraft panel.<br />
<br />
:: It is up to the user to define if it can always be heard or only when in cockpit view.<br />
<br />
; <code>&lt;volume&gt;</code> / <code>&lt;pitch&gt;</code><br />
: Volume or Pitch definition.<br />
<br />
: Currently there may be up to 5 volume and up to 5 pitch definitions defined within one sound event.<br />
<br />
: There are two important results from each <volume> and <pitch> section: the offset and the value. Normally all offset values from the different volume/pitch are added together to create the total offset. The values from each <volume> or <pitch> section are multiplied together to create an final value. Then the volume (or pitch, respectively) is set to total offset + final value.<br />
<br />
: A special condition occurs when the value of factor is negative, in which case the offset doesn't get added to the other offset values but instead will be used in the multiplication section.<br />
<br />
: Pitch final output can range from 0 to 2. 1 represents the original pitch of the sound file. Offset defaults to 1, meaning that if no specific <pitch> parameters are given the file will be played at its original pitch.<br />
<br />
: Volume final output can range from 0 to 1. 1 represents full volume and 0 is silence.<br />
<br />
; <code>&lt;property&gt;</code><br />
: Defines which property supplies the value for the calculation.<br />
<br />
: Either a <property> or an <internal> should be defined. If none is defined, the property reverts to its default. For volume this is 0, meaning the sound will not be audible at all.<br />
<br />
: The value is treated as a floating point number.<br />
<br />
; <code>&lt;internal&gt;</code><br />
: Defines which internal variable should be used for the calculation.<br />
<br />
: The value is treated as a floating point number.<br />
<br />
: The following internals are available at this time:<br />
<br />
:; dt_play<br />
:: The number of seconds since the sound started playing.<br />
<br />
:; dt_stop<br />
:: The number of seconds after the sound has stopped.<br />
<br />
; <code>&lt;delay-sec&gt;</code><br />
: Delay after which the sound starts playing.<br />
<br />
: This is useful to let a property start two sounds at the same time, where the second is delayed until the first stopped playing.<br />
<br />
; <code>&lt;type&gt;</code><br />
: Defines the function that should be used upon the property before it is used for calculating the net result:<br />
<br />
:; lin<br />
:: Linear handling of the property value. This is the default.<br />
<br />
:; ln<br />
:: Convert the property value to a natural logarithmic value before scaling it.<br />
<br />
:: Anything below 1 will return zero.<br />
<br />
:; log<br />
:: convert the property value to a true logarithmic value before scaling it. (log base 10)<br />
<br />
:: Anything below 1 will return zero.<br />
<br />
:; inv<br />
:: Inverse linear handling (1/x).<br />
<br />
:; abs<br />
:: Absolute handling of the value (always positive).<br />
<br />
:; sqrt<br />
:: Calculate the square root of the absolute value before scaling it.<br />
<br />
; <code>&lt;factor&gt;</code><br />
: Defines the multiplication factor for the property value.<br />
<br />
: A special condition is when scale is defined as a negative value. In this case the result of |<scale>| * <property) will be subtracted from &lt;default&gt;<br />
<br />
; <code>&lt;offset&gt;</code><br />
: The initial value for this sound.<br />
<br />
: This value is also used as an offset value for calculating the end result.<br />
<br />
; <code>&lt;min&gt;</code><br />
: Minimum allowed value.<br />
<br />
: This is useful if sounds start to sound funny. Anything lower will be truncated to this value.<br />
<br />
; <code>&lt;max&gt;</code><br />
: Maximum allowed value.<br />
<br />
: This is useful if sounds gets to loud. Anything higher will be truncated to this value.<br />
<br />
: Keep in mind that min & max are applied first, then offset. So for example if min = 0, max = 0.5 and offset = 1.0, then the resulting values will range 1 to 1.5.<br />
<br />
; <code>&lt;position&gt;</code><br />
: Specify the position of the sounds source relative to the aircraft center.<br />
<br />
: The coordinate system used is a left hand coordinate system where +Y = left, -Y = right, -Z = down, +Z = up, -X = forward, +X = aft. Distances are in meters.<br />
<br />
: The volume calculation due to distance and orientation of the sounds source ONLY work on mono samples!<br />
<br />
: Also take notice that the values should not be 0.0, since that can produce sound artifacts on some sound cards.<br />
<br />
; <code>&lt;x&gt;</code><br />
: X dimension offset (-X = forward, +X = aft, in meters)<br />
<br />
; <code>&lt;y&gt;</code><br />
: Y dimension offset (+Y = left, -Y = right)<br />
<br />
; <code>&lt;z&gt;</code><br />
: Z dimension offset (-Z = down, +Z = up)<br />
<br />
; <code>&lt;orientation&gt;</code><br />
: Specify the orientation of the sounds source.<br />
<br />
: The zero vector is default, indicating that a Source is not directional.<br />
<br />
: Specifying a non-zero vector will make the Source directional in the X,Y,Z direction<br />
<br />
; <code>&lt;x&gt;</code><br />
: X dimension<br />
<br />
; <code>&lt;y&gt;</code><br />
: Y dimension<br />
<br />
; <code>&lt;z&gt;</code><br />
: Z dimension<br />
<br />
; <code>&lt;inner-angle&gt;</code><br />
: The inner edge of the audio cone in degrees (0.0 - 180.0).<br />
<br />
: Any sound withing that angle will be played at the current gain.<br />
<br />
; <code>&lt;outer-angle&gt;</code><br />
: The outer edge of the audio cone in degrees (0.0 - 180.0).<br />
<br />
: Any sound beyond the outer cone will be played at "outer-gain" volume.<br />
<br />
; <code>&lt;outer-gain&gt;</code><br />
: The gain at the outer edge of the cone.<br />
<br />
; <code>&lt;reference-dist&gt;</code><br />
: Set a reference distance of sound in meters. This is the distance where the volume is at its maximum.<br />
<br />
: Volume is clamped to this maximum for any distance below.<br />
<br />
: Volume is attenuated for any distance above.<br />
<br />
: Attenuation depends on reference and maximum distance. See OpenAL specification on "AL_INVERSE_DISTANCE_CLAMPED" mode for details on exact computation.<br />
<br />
; <code>&lt;max-dist&gt;</code><br />
: Set the maximum audible distance for the sound in meters.<br />
<br />
: Sound is cut-off above this distance.<br />
<br />
== Creating a configuration file ==<br />
<br />
To make things easy, there is a default value for most entries to allow a<br />
sane configuration when a certain entry is omitted.<br />
<br />
{| class="wikitable"<br />
! Tag !! Default value<br />
|-<br />
| '''&lt;type&gt;''' || lin<br />
|-<br />
| '''&lt;factor&gt;''' || 1.0<br />
|-<br />
| '''&lt;offset&gt;''' || 0.0 for volume, 1.0 for pitch<br />
|-<br />
| '''&lt;min&gt;''' || 0.0<br />
|-<br />
| '''&lt;max&gt;''' || 0.0 (don't check)<br />
|}<br />
<br />
Calculations are made the following way (for both pitch and volume):<br />
<syntaxhighlight lang="cpp"><br />
value = 0;<br />
offs = 0;<br />
<br />
for (n = 0; n < max; n++) {<br />
if (factor < 0) {<br />
value += offset[n] - abs(factor[n]) * function(property[n]);<br />
} else {<br />
value *= factor[n] * function(property[n]);<br />
offs += offset[n];<br />
}<br />
}<br />
<br />
volume = offs + value;<br />
if (volume > 1.0) vol = 1.0;<br />
</syntaxhighlight><br />
where function can be one of: lin, ln, log, inv, abs or sqrt<br />
<br />
== Multiplayer sound ==<br />
The multiplayer sound file works just as the normal sound file, except it should reside in <code>/sim/model/sound</code> instead of <code>/sim/sound</code>. Make sure it depends on properties that are [[Howto:Transmit_properties_over_MP|transmitted over MP]].<br />
<br />
== Recommended audio file formats ==<br />
{{note|The sound sample '''must be in mono''' format. This is because it can not be put in a 3D context otherwise. Also, as of at least June 2015 '''stereo samples will not be played'''.}}<br />
<br />
There some considerations on the quality to the audio files. As a rule of thumb, any computer is able to playback sounds in DVD-quality (48 kHz/24 bits).<br />
Macs still has trouble reading 32 bit files. Most standard sound cards also can't playback 32 bit files.<br />
<br />
From a listeners point of view, anything above 44.1 kHz and 24 bits is only useful for high end music. Personally, I would think that 44.1 kHz with 16 bits should be more than enough to play engine sounds and alarms from the cockpit. Consider the disk-space against the gain in audio quality!<br />
<br />
== Preventing sounds from playing when sim starts ==<br />
Some times it can be hard to prevent sounds from playing right away, if the condition starts to evaluate to true. A hack to get this to work is to multiply the volume with a property that you in nasal set to true some seconds after the sim has been initialized.<br />
<br />
== Bugs in the sound system ==<br />
* The Doppler effect if you pass an aircraft in high speed sometimes is way too high pitch.<br />
* None of the position coordinates must not be 0.0 as described above.<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[Conditions]]<br />
* [[Expressions]]<br />
* [[Howto:Reload sound configuration without restarting]]<br />
<br />
=== Readme file ===<br />
* {{readme file|xmlsound}}<br />
<br />
=== Source code ===<br />
* {{simgear file|simgear/sound/xmlsound.hxx}}<br />
* {{simgear file|simgear/sound/xmlsound.cxx}}<br />
* {{flightgear file|src/Sound/fg_fx.hxx}}<br />
* {{flightgear file|src/Sound/fg_fx.cxx}}<br />
<br />
[[Category:Aircraft enhancement]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Howto:Animate_models&diff=107071Howto:Animate models2017-02-24T03:53:41Z<p>Flug: /* Blend */</p>
<hr />
<div>The real world is full of motion. To simulate this in [[FlightGear]], '''models must be animated'''.<br />
<br />
FlightGear allows you to animate models in response to property changes: for example, the propellers can spin when the engine is on and the elevators can move up and down with your controller. There is no fixed limit on what parts can be animated: the only requirements are that the part is named in the 3D model file, and that there is a property in the main tree that you can use to get the positioning information. <br />
<br />
This document provides basic information for all kind of animations. When animating your model, it is very helpful to find an aircraft with parts similar to yours and use it as an example. Cut and paste the code into your wrapper file and then edit to suit.<br />
<br />
== Notes ==<br />
=== File name of main model and animation XML file ===<br />
{{main article|Aircraft-set.xml#Not used for loading multiplayer aircraft}}<br />
The file name of the main model and animation XML file, or the .ac file if there is no XML file, (in essence the property <code>/sim/model/path</code>) will be the name of the aircraft that is transmitted when using [[multiplayer]] and will also be used for loading multiplayer aircraft.<br />
<br />
There is also a mechanism to substitute a full aircraft model with a simpler AI aircraft model if one is available at the same file path (including for example <code>Models/Boeing-797-800.xml</code>), but in <code>[[$FG_ROOT]]/'''AI'''/Aircraft/</code> instead of <code>$FG_ROOT/Aircraft/</code>.<br />
<br />
=== .ac files ===<br />
{{Main article|AC files: Understanding and changing .ac code#Identifying an object}}<br />
<br />
When referring to an .ac file in your xml animation, it is important that the <code><object name></code> exactly matches the object named in the .ac file (this includes cases!). <br />
<br />
'''Note for SketchUp users:''' The spatial reference X/Y/Z used in animation to locate an object or a point are different from the ones in AC3D ie X values are the same in both but Y in animation must be matched to AC3D's -Z (Z value but opposite sign) and Z value in animation must be matched to AC3D's Y value. <br />
<br />
'''Note for SketchUp users:''' when exporting to AC3D in Sketchup, the .ac file will name the objects in your model to "blah" by default. You need to amend the relevant object names in your .ac file using text edit, so that the xml will work.<br />
<br />
=== Animation order ===<br />
Animations are executed by FlightGear in the order that they are read in the model's .xml file. Therefore, it is very important to pay attention to the order, especially when multiple animations are applied to the same object(s).<br />
<br />
== Tags used in most animations ==<br />
=== Name ===<br />
With a name animation, you can group multiple objects. <br />
<br />
<source><br />
<animation><br />
<name>Collection1</name><br />
<object-name>Object1</object-name><br />
<object-name>Object2</object-name><br />
<object-name>Object3</object-name><br />
</animation><br />
</source><br />
<br />
The example above creates a "virtual object" with the name Collection1. In animation, we can animate this group of objects, by using:<br />
<br />
<source><br />
<object-name>Collection1</object-name><br />
</source><br />
<br />
=== Object-name ===<br />
These names are set in the 3D model. Each single object has a unique name; for easy identification it is advised to use descriptive names (LeftElevator, Rudder etc.). Animations are only applied to those objects that are mentioned in an object-name line (one object per line!). Animations lacking those, will be applied to the entire model.<br />
<br />
=== Property ===<br />
Each animation must be associated with exactly one property from the main FlightGear property tree (remember that the properties in the wrapper file are not part of the main tree), using <code><property></code> to provide the property path:<br />
<br />
<source><br />
<animation><br />
<type>rotate</type><br />
<object-name>Rudder</object-name><br />
<property>controls/rudder</property><br />
</animation><br />
</source><br />
<br />
Note the omission of the leading slash '/' when reffering to the property. This assures that when the model is used for AI or multiplayer traffic the animations will follow that of the AI controller instead of that of the user.<br />
<br />
=== Axis ===<br />
An axis part is required in every animation that involves a rotating or moving thing.<br />
<br />
<source><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</source><br />
<br />
The axis are similar to the ones of the 3D model. There is a difference between rotation and translation:<br />
* In rotation animations, the axis part defines around what axis the object rotates. Negative/positive values make the difference between counterclockwise and clockwise rotations.<br />
* In translate animations, the part defines along what axis the object moves. If the x-axis is poiting backwards, an x-value of -1 will result in forward motion.<br />
<br />
You could also define two points, between which FlightGear will calculate the correct axis. This makes the use of a [[#Center|<nowiki><center></nowiki>]] tag redundant! Such coordinates are extremely useful for animating control surfaces (rudder, elevators etc.).<br />
<br />
<source><br />
<axis> <br />
<x1-m> 4.9</x1-m><br />
<y1-m> 7.1</y1-m><br />
<z1-m>-1.0</z1-m><br />
<x2-m> 5.9</x2-m><br />
<y2-m>11.2</y2-m><br />
<z2-m>-0.5</z2-m><br />
</axis><br />
</source><br />
<br />
=== Center ===<br />
Various animations ([[#Rotate|rotate]], [[#Spin|spin]], [[#Scale|scale]]) move around a center point.<br />
<br />
<source><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
</source><br />
<br />
The axis are similar to the ones of the 3D model, so finding coordinates is easily done in 3D modeling software.<br />
<br />
== Additional tags that can be used in most animations ==<br />
=== Conditions ===<br />
Multiple animations can make use of a conditional. Check <tt>$FGDATA/Docs/README.conditions</tt> for some more details.<br />
<br />
* '''equals:''' property value (or second property) is equal to value/(first)property.<br />
* '''greater-than:''' property value (or second property) is larger than value/(first)property.<br />
* '''greater-than-equals:''' property value (or second property) is greater than or equal to value/(first)property.<br />
* '''less-than:''' property value (or second property) is smaller than value/(first)property.<br />
* '''less-than-equals:''' property value (or second property) is smaller than or equal to value/(first)property.<br />
<br />
The example below is true when n1 has a value greater than 25.<br />
<source><br />
<condition><br />
<greater-than><br />
<property>engines/engine[1]/n1</property><br />
<value>25</value><br />
</greater-than><br />
</condition><br />
</source><br />
<br />
Then there are some special tags:<br />
<br />
* '''and:'''<br />
* '''not:'''<br />
* '''or:'''<br />
<br />
In the example below, the condition is true when either n1 is greater than 25% or equal to 0%.<br />
<source><br />
<condition><br />
<or><br />
<greater-than><br />
<property>engines/engine[1]/n1</property><br />
<value>25</value><br />
</greater-than><br />
<equals><br />
<property>engines/engine[1]/n1</property><br />
<value>0</value><br />
</equals><br />
</or><br />
</condition><br />
</source><br />
<br />
An example of implementation into an animation looks as follows:<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>rotate</type><br />
<property>suface-positions/left-aileron-pos-norm</property><br />
<factor>25</factor><br />
<condition><br />
<greater-than><br />
<property>suface-positions/left-aileron-pos-norm</property><br />
<value>10</value><br />
</greater-than><br />
</condition><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
=== Interpolation ===<br />
For non-fixed factors, an interpolation "table" can be created. <br />
<br />
<source><br />
<interpolation><br />
<entry><br />
<ind> 0.0</ind><br />
<dep> 0.0</dep><br />
</entry><br />
<entry><br />
<ind> 0.667</ind><br />
<dep> 0.0</dep><br />
</entry><br />
<entry><br />
<ind> 1.0</ind><br />
<dep> 0.5</dep><br />
</entry><br />
</interpolation><br />
</source><br />
<br />
The lines above represent the following table:<br />
<br />
{|<br />
!Input<br />
!Output<br />
|-<br />
|0.0<br />
|0.0<br />
|-<br />
|0.667<br />
|0.0<br />
|-<br />
|1.0<br />
|0.5<br />
|}<br />
<br />
You can add as many entries as you need. Interpolation tables are often used for gear animations (eg. to open doors during gear-movements and close them again once the gear is either retracted or fully extended).<br />
<br />
=== Expressions ===<br />
For some animations it is possible to define complex animations by using [[Expressions|Expressions]]. This even allows to drive the animation from multiple properties without the need for additional Nasal scripts. Here is an example for a translate animation depending on two properties and the cosine function:<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>translate</type><br />
<expression><br />
<product><br />
<property>/my/factor-property</property><br />
<cos><br />
<deg2rad><br />
<property>/my/angular-property</property><br />
</deg2rad><br />
</cos><br />
</product><br />
</expression><br />
[..]more elements[..]<br />
</animation><br />
</syntaxhighlight><br />
<br />
Animations which can utilize [[Expressions|Expressions]] are: <br />
* [[Howto:Animate_models#Translate|Translate]]<br />
* [[Howto:Animate_models#Rotate|Rotate]]<br />
* [[Howto:Animate_models#Scale|Scale]]<br />
* [[Howto:Animate_models#Range|Range]]<br />
* [[Howto:Animate_models#Blend|Blend]]<br />
<br />
See more detailed info at [[Expressions|Expressions]]<br />
<br />
== Object animations ==<br />
=== Alpha-test ===<br />
<source><br />
<animation><br />
<type>alpha-test</type><br />
<object-name>Object</object-name><br />
<alpha-factor>0.01</alpha-factor><br />
</animation><br />
</source><br />
This "animation" is a way to set an alpha test on a model branch. The effect is to avoid depth buffer writing of pixel that are not seen because they are transparent. This is particulary useful when modeling a metallic structure or a tree with a billboard. The threshold of transparency is set with the <alpha-factor> element. See also [[Pixel testing in effects]].<br />
<br />
=== Blend ===<br />
Blends an object with the surrounding. Comparable to a translucency animation. A value of 0 corresponds to no transparency, i.e. and ordinary solid object, and a value of 1 makes the object fully transparent, i.e., not visible at all.<br />
<br />
<source><br />
<animation><br />
<type>blend</type><br />
<property>/velocities/airspeed-kt</property><br />
<factor>0.00025</factor><br />
<min>0.2</min><br />
<max>0.7</max><br />
</animation><br />
</source><br />
<br />
* '''property:'''<br />
* '''factor:'''<br />
* '''min:'''<br />
* '''max:'''<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
Note that when using the Project Rembrandt renderer, all transparent and translucent objects must be registered to display properly. [[Project_Rembrandt#Registering_all_translucent_surfaces|More information here.]]<br />
<br />
=== Billboard ===<br />
This faces an object towards the viewer. Often used on 2D objects, like clouds, trees and lights.<br />
<br />
<source><br />
<animation><br />
<type>billboard</type><br />
<object-name>Object</object-name><br />
<spherical type="bool">true</spherical><br />
</animation><br />
</source><br />
<br />
* '''spherical:'''<br />
<br />
=== Dist-scale ===<br />
Used to scale an object, based on the distance to the viewer.<br />
<br />
<source><br />
<animation><br />
<type>dist-scale</type><br />
<object-name>Object</object-name><br />
<interpolation><br />
<entry><br />
<ind>0</ind><br />
<dep>1</dep><br />
</entry><br />
<entry><br />
<ind>300</ind><br />
<dep>4</dep><br />
</entry><br />
<entry><br />
<ind>1500</ind><br />
<dep>8</dep><br />
</entry><br />
</interpolation><br />
</animation><br />
</source><br />
<br />
You can optionally add [[#Center|&lt;center&gt;]] coordinates, to scale the object around that point.<br />
<br />
=== Flash ===<br />
<br />
Used to scale an object based on the cosine of the angle between the axis provided in the animation and the view vector.<br />
<br />
<source><br />
<animation><br />
<type>flash</type><br />
<object-name>Object</object-name><br />
<offset>0.0</offset><br />
<factor>1.0</factor><br />
<power>2</power><br />
<two-sides type="bool">false</two-sides><br />
<min>0.0</min><br />
<max>1.0</max><br />
<center><br />
<x-m>0.0</x-m><br />
<y-m>0.0</y-m><br />
<z-m>0.0</z-m><br />
</center><br />
<axis><br />
<x>0.0</x><br />
<y>-1</y><br />
<z>0.1</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''offset:'''<br />
* '''factor:'''<br />
* '''power:'''<br />
* '''two-sides:''' if false, nothing is drawn if the cosine is negative.<br />
* '''min:'''<br />
* '''max:'''<br />
<br />
scale = factor * pow( cosine, power ) + offset<br />
<br />
scale is then clamped between min and max.<br />
<br />
and this scale factor is applied to the object, from the center specified. It works best if scale is less than 1. Otherwise, there will be clipping issues.<br />
<br />
=== Noshadow ===<br />
This animation is used to make sure an object will cast no shadow.<br />
<br />
<source><br />
<animation><br />
<type>noshadow</type><br />
<object-name>Object</object-name><br />
</animation><br />
</source><br />
<br />
=== Range ===<br />
: ''See also [[Modeling - Getting Started#Level of Detail (LOD)]].''<br />
<br />
To prevent objects -like instruments- being drawn when the aircraft is actually too far away for them to be seen anyway, a range animation is used. <br />
<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>range</type><br />
<min-m>0</min-m><br />
<max-m>30</max-m><br />
</animation><br />
</syntaxhighlight><br />
<br />
* '''min-m:''' the shortest distance (in meters) from the object center at which it is visible.<br />
* '''max-m:''' the largest distance (in meters) from the object center at which it is visible.<br />
<br />
You could also use the generic level of detail (LOD) properties, which can be set by the user through View > Adjust LOD rangers: <br />
{| class="wikitable"<br />
! Property<br />
! Description<br />
! Default value<br />
|-<br />
|<tt>/sim/rendering/static-lod/bare</tt><br />
| only a rough exterior model<br />
| 30,000 m<br />
|-<br />
|<tt>/sim/rendering/static-lod/rough</tt> <br />
| most should be visible<br />
| 9,000 m<br />
|-<br />
|<tt>/sim/rendering/static-lod/detailed</tt> <br />
| all details should be visible<br />
| 1,500 m<br />
|}<br />
<br />
The animation code will look like this:<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>range</type><br />
<min-m>0</min-m><br />
<max-property>sim/rendering/static-lod/bare</max-property><br />
</animation><br />
</syntaxhighlight><br />
<br />
You can have both ranges (max and min) bound to a property, or just one of them.<br />
* '''min-property:''' <br />
* '''max-property:'''<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
=== Rotate ===<br />
One of the most important and frequently used animations of all. It rotates an object to an absolute position in degrees, as provided by the property-value.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>rotate</type><br />
<property>surface-positions/left-aileron-pos-norm</property><br />
<factor>25</factor><br />
<offset-deg>25</offset-deg><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
* '''offset-deg:''' is optional. Offset in degrees.<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
=== Scale ===<br />
A scale animation scales (resizes) an object. This can be either property-value dependant (first example) or a fixed scale (second example).<br />
<br />
<source><br />
<animation><br />
<type>scale</type><br />
<object-name>Object</object-name><br />
<property>sim/time/sun-angle-rad</property><br />
<x-min>1.0</x-min><br />
<y-min>1.0</y-min><br />
<z-min>1.0</z-min><br />
<x-factor>1.4</x-factor><br />
<y-factor>1.4</y-factor><br />
<z-factor>2.0</z-factor><br />
</animation><br />
</source><br />
<br />
* ?-min: the mimimum scale factor for each axis. If the property value would result in a smaller factor than this setting, the scale animation will hold.<br />
* ?-factor: the scale factor for each axis (factor*property=scale factor).<br />
<br />
<source><br />
<animation><br />
<type>scale</type><br />
<x-offset>0.5</x-offset><br />
<y-offset>0.5</y-offset><br />
<z-offset>0.5</z-offset><br />
</animation><br />
</source><br />
<br />
* x.offset: the scale factor.<br />
* Add [[#Center|&lt;center&gt;]] coordinates, to scale the object around that point.<br />
* '''You can optionally use an [[Howto:Animate_models#Expressions|expression]] in the <factor> or <offset> inputs.''' For more details see [[Expressions|Expressions]]<br />
<br />
=== Select ===<br />
This animation selects (or unselects) objects when certain conditions are true (or false). The example below shows the object when the n1 of engine[1] is higher than 25%.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>select</type><br />
<condition><br />
<greater-than><br />
<property>engines/engine[0]/n1</property><br />
<value>25</value><br />
</greater-than><br />
</condition><br />
</animation><br />
</source><br />
<br />
=== Shader ===<br />
<source><br />
<animation><br />
<type>shader</type><br />
<shader>chrome</shader><br />
<texture>chrome2.png</texture><br />
<object-name>Object</object-name><br />
</animation><br />
</source><br />
<br />
* '''shader:''' <br />
* '''texture:''' path to the texture used by the shader.<br />
<br />
=== Spin ===<br />
Very similar to [[#Rotate|rotate]], but the property provides a value in revolutions per minute (RPM) rather than an absolute position in degrees, and offset cannot be used.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>spin</type><br />
<property>engines/engine[0]/n1</property><br />
<factor>25</factor><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
<br />
=== Timed ===<br />
Swtiches between objects at specified intervals. This example switches between a lights-on model and a lights-off model. Lights on are shown 0.2 seconds, while lights off are displayed for 0.8 seconds.<br />
<br />
<source><br />
<animation><br />
<type>timed</type><br />
<object-name>BacklightOn</object-name><br />
<object-name>BacklightOff</object-name><br />
<use-personality type="bool">true</use-personality><br />
<branch-duration-sec>0.8</branch-duration-sec><br />
<branch-duration-sec>0.2</branch-duration-sec><br />
</animation><br />
</source><br />
<br />
=== Tracking ===<br />
The new (in 2.11) [[Tracking animation|'''locked-track animation''']] can do exactly the same thing as the [http://wiki.blender.org/index.php/Doc:2.6/Manual/Constraints/Tracking/Locked_Track Locked Track constraint] available in Blender. However it can also be used to simulate simple inverse kinematic systems consisting of two bones connected with a revolute joint (aka hinge). See [[Tracking animation|detailed explanantion]]<br />
<br />
=== Translate ===<br />
The same as [[#Textranslate|textranslate]], but this animation moves a whole object (so including fixed textures). The example below will move an object in the y-direction:<br />
<br />
{| class="wikitable" border="0" cellspacing="0" <br />
!Property value<br />
!Output<br />
|-<br />
| -1<br />
| -2.5<br />
|-<br />
| 0<br />
| 2.5<br />
|-<br />
| 1<br />
| 7.5<br />
|}<br />
<br />
<source><br />
<animation><br />
<type>translate</type><br />
<object-name>Object</object-name><br />
<property>controls/seat/pilot/position-norm</property><br />
<factor>5</factor><br />
<offset-m>2.5</offset-m><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
* '''offset-m:''' is optional. Offset in meters.<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
== Material animation ==<br />
An animation type that can be used in various ways. Of course you can combine the below mentiond systems into one (big) animation.<br />
<br />
<source><br />
<animation> <br />
<type>material</type> <br />
<object-name>Object</object-name><br />
<property-base>sim/model/c172p/material</property-base><br />
<global type="bool">true</global> <!-- This tag is no longer supported --><br />
...<br />
lines as mentioned below<br />
...<br />
</animation><br />
</source><br />
<br />
'''Optional:'''<br />
* '''property-base:''' when using prop(erties), you might want to set a property-base. All props will be relative to this path.<br />
* '''global (depreciated):''' by setting this to <tt>true</tt>, all objects using the same material as the defined object(s) (via <tt><object-name></tt>) will be affected by the animation. This is preferred to listing several objects in <object-name> tags. It's not only faster, but also doesn't break animations by forcing objects together. <span style="color:red; text-decoration: underline;">This tag is no longer supported</span><br />
<br />
'''Notes:'''<br />
* Numbers are clamped to 0.0-1.0, except "shininess", which is clamped to 0-128.<br />
* By appending <tt>-prop</tt> each of the material properties can read its value from another property.<br />
<br />
=== Ambient ===<br />
<source><br />
<ambient><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</ambient><br />
</source><br />
<br />
=== Diffuse ===<br />
<source><br />
<diffuse><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</diffuse><br />
</source><br />
<br />
=== Emission ===<br />
{{Main article|Howto: Illuminate faces}}<br />
<source><br />
<emission><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
<factor-prop>controls/lighting/panel-norm</factor-prop><br />
</emission><br />
</source><br />
<br />
Emission colors are multiplied by the factor-prop value. 1 is maximum color intensity, while 0 is the minimum. Colors are calculated according to the [http://en.wikipedia.org/wiki/RGB_color_model RGB color model].<br />
<br />
=== Shininess ===<br />
Shininess is clamped to 0-128.<br />
<source><br />
<shininess>105</shininess><br />
</source><br />
<br />
=== Specular ===<br />
<source><br />
<specular><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</specular><br />
</source><br />
<br />
=== Texture ===<br />
Used for the [[Livery over MP]] system.<br />
<br />
<source><br />
<property-base>sim/model/livery</property-base> <br />
<texture-prop>engine</texture-prop> <br />
<texture>KLM.png</texture> <br />
</source><br />
<br />
=== Transparency ===<br />
<source><br />
<transparency><br />
<alpha-prop>rotors/tail/rpm</alpha-prop><br />
<factor>-0.0015</factor><br />
<offset>1</offset><br />
</transparency><br />
</source><br />
<br />
=== Threshold ===<br />
<source><br />
<threshold>0.001</threshold><br />
</source><br />
<br />
== Texture Animations ==<br />
<br />
Applying different matrix transformations to the textures of an object.<br />
<br />
=== Textranslate ===<br />
A very important animation for cockpits! This animation moves textures over a surface.<br />
<br />
<source><br />
<animation><br />
<type>textranslate</type><br />
<object-name>Object</object-name><br />
<property>autopilot/settings/target-speed-kt</property><br />
<bias>0.0001</bias><br />
<factor>0.001</factor><br />
<step>100</step><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''bias:''' Adds an offset to the property before factor/step. A small value is needed to compensate for [http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems floating point accuracy].<br />
* '''factor:''' property * factor * texture width/height = the amount of pixels that the texture should be translated. If your texture is 256 pixels, an textranslate of 0.1 will result in the texture moving with 26 pixels, into the direction specified by the axis settings.<br />
* '''step:''' the step size at which the texture is translated. If this is set to 0.1, the texture will only be translated at 0.1, 0.2, 0.3 etc.<br />
* '''axis:''' the direction in which the texture is translated. Y is up/down, while X is left/right.<br />
<br />
=== Texrotate ===<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>texrotate</type><br />
<property>some/property/path</property><br />
<factor>25</factor><br />
<offset-deg>25</offset-deg><br />
<center><br />
<x>0.5</x><br />
<y>0.5</y><br />
<z>0</z><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>0</y><br />
<z>1</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
=== Textrapezoid ===<br />
<br />
<source><br />
<animation><br />
<type>textrapezoid</type><br />
<object-name>HUD.l.canvas</object-name><br />
<property>/hud/trapezoid-correction</property><br />
<side>bottom</side><br />
</animation><br />
</source><br />
<br />
* '''side''': side of quad which should be scaled (''top'' (default)/''right''/''bottom''/''left'')<br />
<br />
=== Texmultiple ===<br />
<br />
Only one texture matrix can be applied to each object. With ''textmultiple'' multiple texture animations can be combined into a single matrix, applied to the specified object.<br />
<br />
<source><br />
<animation><br />
<type>texmultiple</type><br />
<object-name>HUD.l.canvas</object-name><br />
<transform><br />
<subtype>textranslate</subtype><br />
<property>/hud/offset-x</property><br />
<axis><br />
<x>1</x><br />
<y>0</y><br />
<z>0</z><br />
</axis><br />
</transform><br />
<transform><br />
<subtype>textranslate</subtype><br />
<property>/hud/offset-y</property><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</transform><br />
<transform><br />
<subtype>textrapezoid</subtype><br />
<property>/hud/trapezoid-correction</property><br />
</transform><br />
</animation><br />
</source><br />
<br />
== Object interaction animations ==<br />
=== Enable-hot ===<br />
Scenery objects are automatically defined as solid by FlightGear, meaning that an aircraft can taxi on them and/or crash when touching. For certain objects (groundmarkings, beacon light-beams etc.) this might be an unwanted feature. The solidness can be disabled with the following animation:<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<enable-hot type="bool">false</enable-hot><br />
</animation><br />
</source><br />
<br />
* '''enable-hot:''' can be either true or false. Remember that objects are automatically solid, so it should not be necessary to set this at all when wanting solidness.<br />
<br />
=== Interactions ===<br />
<source><br />
<animation> <br />
<type>interaction</type> <br />
<object-name>Object</object-name> <br />
<interaction-type>carrier-wire</interaction-type> <br />
</animation> <br />
</source><br />
<br />
* '''interaction-type:''' can have the following values:<br />
** '''carrier-catapult:'''<br />
** '''carrier-wire:''' makes the object act as an arresting wire, as used on [[aircraft carrier]]s.<br />
<br />
== Direct manipulation animations ==<br />
=== Knob / slider (v. 2.11-) ===<br />
{{Main article|Knob / slider animation}}<br />
<br />
=== Pick ===<br />
{{Main article|Howto: Make a clickable panel#Pick}}<br />
<br />
== Shadow Handling ==<br />
There exist several possibilites for handling of shadows. <br /><br />
See '''[[ALS_technical_notes|ALS Technical Notes]]''' and more specific '''[[ALS_technical_notes#ALS_fuselage_shadow_effect|Fuselage Shadow Effect with ALS]]''' for a relatively simple shadow handling.<br /><br />
See '''[[Project Rembrandt]]''' which - amongst other functionality - implements a very realistic shadow mapping.<br />
<br />
== References ==<br />
{{Appendix|all|<br />
* {{cite web |url=http://www.opensubscriber.com/message/flightgear-devel@flightgear.org/958955.html |title="material" animation (and the bo105 as an example) |first=Melchior |last=Franz |date=22 March 2005 |work=FlightGear-devel mailinglist }}<br />
* {{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01546.html |title=flash animation |first=Frederic |last=Bouvier |date=22 Feb 2006 |work=FlightGear-devel mailinglist }}<br />
}}<br />
<br />
<br />
[[Category:Aircraft enhancement|Animate models]]<br />
[[Category:Howto|Animate models]]<br />
[[Category:Modeling|Animate models]]<br />
[[Category:Scenery enhancement|Animate models]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Howto:Animate_models&diff=107070Howto:Animate models2017-02-24T03:53:09Z<p>Flug: /* Blend */</p>
<hr />
<div>The real world is full of motion. To simulate this in [[FlightGear]], '''models must be animated'''.<br />
<br />
FlightGear allows you to animate models in response to property changes: for example, the propellers can spin when the engine is on and the elevators can move up and down with your controller. There is no fixed limit on what parts can be animated: the only requirements are that the part is named in the 3D model file, and that there is a property in the main tree that you can use to get the positioning information. <br />
<br />
This document provides basic information for all kind of animations. When animating your model, it is very helpful to find an aircraft with parts similar to yours and use it as an example. Cut and paste the code into your wrapper file and then edit to suit.<br />
<br />
== Notes ==<br />
=== File name of main model and animation XML file ===<br />
{{main article|Aircraft-set.xml#Not used for loading multiplayer aircraft}}<br />
The file name of the main model and animation XML file, or the .ac file if there is no XML file, (in essence the property <code>/sim/model/path</code>) will be the name of the aircraft that is transmitted when using [[multiplayer]] and will also be used for loading multiplayer aircraft.<br />
<br />
There is also a mechanism to substitute a full aircraft model with a simpler AI aircraft model if one is available at the same file path (including for example <code>Models/Boeing-797-800.xml</code>), but in <code>[[$FG_ROOT]]/'''AI'''/Aircraft/</code> instead of <code>$FG_ROOT/Aircraft/</code>.<br />
<br />
=== .ac files ===<br />
{{Main article|AC files: Understanding and changing .ac code#Identifying an object}}<br />
<br />
When referring to an .ac file in your xml animation, it is important that the <code><object name></code> exactly matches the object named in the .ac file (this includes cases!). <br />
<br />
'''Note for SketchUp users:''' The spatial reference X/Y/Z used in animation to locate an object or a point are different from the ones in AC3D ie X values are the same in both but Y in animation must be matched to AC3D's -Z (Z value but opposite sign) and Z value in animation must be matched to AC3D's Y value. <br />
<br />
'''Note for SketchUp users:''' when exporting to AC3D in Sketchup, the .ac file will name the objects in your model to "blah" by default. You need to amend the relevant object names in your .ac file using text edit, so that the xml will work.<br />
<br />
=== Animation order ===<br />
Animations are executed by FlightGear in the order that they are read in the model's .xml file. Therefore, it is very important to pay attention to the order, especially when multiple animations are applied to the same object(s).<br />
<br />
== Tags used in most animations ==<br />
=== Name ===<br />
With a name animation, you can group multiple objects. <br />
<br />
<source><br />
<animation><br />
<name>Collection1</name><br />
<object-name>Object1</object-name><br />
<object-name>Object2</object-name><br />
<object-name>Object3</object-name><br />
</animation><br />
</source><br />
<br />
The example above creates a "virtual object" with the name Collection1. In animation, we can animate this group of objects, by using:<br />
<br />
<source><br />
<object-name>Collection1</object-name><br />
</source><br />
<br />
=== Object-name ===<br />
These names are set in the 3D model. Each single object has a unique name; for easy identification it is advised to use descriptive names (LeftElevator, Rudder etc.). Animations are only applied to those objects that are mentioned in an object-name line (one object per line!). Animations lacking those, will be applied to the entire model.<br />
<br />
=== Property ===<br />
Each animation must be associated with exactly one property from the main FlightGear property tree (remember that the properties in the wrapper file are not part of the main tree), using <code><property></code> to provide the property path:<br />
<br />
<source><br />
<animation><br />
<type>rotate</type><br />
<object-name>Rudder</object-name><br />
<property>controls/rudder</property><br />
</animation><br />
</source><br />
<br />
Note the omission of the leading slash '/' when reffering to the property. This assures that when the model is used for AI or multiplayer traffic the animations will follow that of the AI controller instead of that of the user.<br />
<br />
=== Axis ===<br />
An axis part is required in every animation that involves a rotating or moving thing.<br />
<br />
<source><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</source><br />
<br />
The axis are similar to the ones of the 3D model. There is a difference between rotation and translation:<br />
* In rotation animations, the axis part defines around what axis the object rotates. Negative/positive values make the difference between counterclockwise and clockwise rotations.<br />
* In translate animations, the part defines along what axis the object moves. If the x-axis is poiting backwards, an x-value of -1 will result in forward motion.<br />
<br />
You could also define two points, between which FlightGear will calculate the correct axis. This makes the use of a [[#Center|<nowiki><center></nowiki>]] tag redundant! Such coordinates are extremely useful for animating control surfaces (rudder, elevators etc.).<br />
<br />
<source><br />
<axis> <br />
<x1-m> 4.9</x1-m><br />
<y1-m> 7.1</y1-m><br />
<z1-m>-1.0</z1-m><br />
<x2-m> 5.9</x2-m><br />
<y2-m>11.2</y2-m><br />
<z2-m>-0.5</z2-m><br />
</axis><br />
</source><br />
<br />
=== Center ===<br />
Various animations ([[#Rotate|rotate]], [[#Spin|spin]], [[#Scale|scale]]) move around a center point.<br />
<br />
<source><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
</source><br />
<br />
The axis are similar to the ones of the 3D model, so finding coordinates is easily done in 3D modeling software.<br />
<br />
== Additional tags that can be used in most animations ==<br />
=== Conditions ===<br />
Multiple animations can make use of a conditional. Check <tt>$FGDATA/Docs/README.conditions</tt> for some more details.<br />
<br />
* '''equals:''' property value (or second property) is equal to value/(first)property.<br />
* '''greater-than:''' property value (or second property) is larger than value/(first)property.<br />
* '''greater-than-equals:''' property value (or second property) is greater than or equal to value/(first)property.<br />
* '''less-than:''' property value (or second property) is smaller than value/(first)property.<br />
* '''less-than-equals:''' property value (or second property) is smaller than or equal to value/(first)property.<br />
<br />
The example below is true when n1 has a value greater than 25.<br />
<source><br />
<condition><br />
<greater-than><br />
<property>engines/engine[1]/n1</property><br />
<value>25</value><br />
</greater-than><br />
</condition><br />
</source><br />
<br />
Then there are some special tags:<br />
<br />
* '''and:'''<br />
* '''not:'''<br />
* '''or:'''<br />
<br />
In the example below, the condition is true when either n1 is greater than 25% or equal to 0%.<br />
<source><br />
<condition><br />
<or><br />
<greater-than><br />
<property>engines/engine[1]/n1</property><br />
<value>25</value><br />
</greater-than><br />
<equals><br />
<property>engines/engine[1]/n1</property><br />
<value>0</value><br />
</equals><br />
</or><br />
</condition><br />
</source><br />
<br />
An example of implementation into an animation looks as follows:<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>rotate</type><br />
<property>suface-positions/left-aileron-pos-norm</property><br />
<factor>25</factor><br />
<condition><br />
<greater-than><br />
<property>suface-positions/left-aileron-pos-norm</property><br />
<value>10</value><br />
</greater-than><br />
</condition><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
=== Interpolation ===<br />
For non-fixed factors, an interpolation "table" can be created. <br />
<br />
<source><br />
<interpolation><br />
<entry><br />
<ind> 0.0</ind><br />
<dep> 0.0</dep><br />
</entry><br />
<entry><br />
<ind> 0.667</ind><br />
<dep> 0.0</dep><br />
</entry><br />
<entry><br />
<ind> 1.0</ind><br />
<dep> 0.5</dep><br />
</entry><br />
</interpolation><br />
</source><br />
<br />
The lines above represent the following table:<br />
<br />
{|<br />
!Input<br />
!Output<br />
|-<br />
|0.0<br />
|0.0<br />
|-<br />
|0.667<br />
|0.0<br />
|-<br />
|1.0<br />
|0.5<br />
|}<br />
<br />
You can add as many entries as you need. Interpolation tables are often used for gear animations (eg. to open doors during gear-movements and close them again once the gear is either retracted or fully extended).<br />
<br />
=== Expressions ===<br />
For some animations it is possible to define complex animations by using [[Expressions|Expressions]]. This even allows to drive the animation from multiple properties without the need for additional Nasal scripts. Here is an example for a translate animation depending on two properties and the cosine function:<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>translate</type><br />
<expression><br />
<product><br />
<property>/my/factor-property</property><br />
<cos><br />
<deg2rad><br />
<property>/my/angular-property</property><br />
</deg2rad><br />
</cos><br />
</product><br />
</expression><br />
[..]more elements[..]<br />
</animation><br />
</syntaxhighlight><br />
<br />
Animations which can utilize [[Expressions|Expressions]] are: <br />
* [[Howto:Animate_models#Translate|Translate]]<br />
* [[Howto:Animate_models#Rotate|Rotate]]<br />
* [[Howto:Animate_models#Scale|Scale]]<br />
* [[Howto:Animate_models#Range|Range]]<br />
* [[Howto:Animate_models#Blend|Blend]]<br />
<br />
See more detailed info at [[Expressions|Expressions]]<br />
<br />
== Object animations ==<br />
=== Alpha-test ===<br />
<source><br />
<animation><br />
<type>alpha-test</type><br />
<object-name>Object</object-name><br />
<alpha-factor>0.01</alpha-factor><br />
</animation><br />
</source><br />
This "animation" is a way to set an alpha test on a model branch. The effect is to avoid depth buffer writing of pixel that are not seen because they are transparent. This is particulary useful when modeling a metallic structure or a tree with a billboard. The threshold of transparency is set with the <alpha-factor> element. See also [[Pixel testing in effects]].<br />
<br />
=== Blend ===<br />
Blends an object with the surrounding. Comparable to a translucency animation. A value of 0 corresponds to no transparency, i.e. and ordinary solid object, and a value of 1 makes the object fully transparent, i.e., not visible at all.<br />
<br />
<source><br />
<animation><br />
<type>blend</type><br />
<property>/velocities/airspeed-kt</property><br />
<factor>0.00025</factor><br />
<min>0.2</min><br />
<max>0.7</max><br />
</animation><br />
</source><br />
<br />
* '''property:'''<br />
* '''factor:'''<br />
* '''min:'''<br />
* '''max:'''<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
Note that when using the Project Rembrandt renderer, all transparent and translucent objects must be registered to display properly. [[Project_Rembrandt#Registering_all_translucent_surfaces More information here.]]<br />
<br />
=== Billboard ===<br />
This faces an object towards the viewer. Often used on 2D objects, like clouds, trees and lights.<br />
<br />
<source><br />
<animation><br />
<type>billboard</type><br />
<object-name>Object</object-name><br />
<spherical type="bool">true</spherical><br />
</animation><br />
</source><br />
<br />
* '''spherical:'''<br />
<br />
=== Dist-scale ===<br />
Used to scale an object, based on the distance to the viewer.<br />
<br />
<source><br />
<animation><br />
<type>dist-scale</type><br />
<object-name>Object</object-name><br />
<interpolation><br />
<entry><br />
<ind>0</ind><br />
<dep>1</dep><br />
</entry><br />
<entry><br />
<ind>300</ind><br />
<dep>4</dep><br />
</entry><br />
<entry><br />
<ind>1500</ind><br />
<dep>8</dep><br />
</entry><br />
</interpolation><br />
</animation><br />
</source><br />
<br />
You can optionally add [[#Center|&lt;center&gt;]] coordinates, to scale the object around that point.<br />
<br />
=== Flash ===<br />
<br />
Used to scale an object based on the cosine of the angle between the axis provided in the animation and the view vector.<br />
<br />
<source><br />
<animation><br />
<type>flash</type><br />
<object-name>Object</object-name><br />
<offset>0.0</offset><br />
<factor>1.0</factor><br />
<power>2</power><br />
<two-sides type="bool">false</two-sides><br />
<min>0.0</min><br />
<max>1.0</max><br />
<center><br />
<x-m>0.0</x-m><br />
<y-m>0.0</y-m><br />
<z-m>0.0</z-m><br />
</center><br />
<axis><br />
<x>0.0</x><br />
<y>-1</y><br />
<z>0.1</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''offset:'''<br />
* '''factor:'''<br />
* '''power:'''<br />
* '''two-sides:''' if false, nothing is drawn if the cosine is negative.<br />
* '''min:'''<br />
* '''max:'''<br />
<br />
scale = factor * pow( cosine, power ) + offset<br />
<br />
scale is then clamped between min and max.<br />
<br />
and this scale factor is applied to the object, from the center specified. It works best if scale is less than 1. Otherwise, there will be clipping issues.<br />
<br />
=== Noshadow ===<br />
This animation is used to make sure an object will cast no shadow.<br />
<br />
<source><br />
<animation><br />
<type>noshadow</type><br />
<object-name>Object</object-name><br />
</animation><br />
</source><br />
<br />
=== Range ===<br />
: ''See also [[Modeling - Getting Started#Level of Detail (LOD)]].''<br />
<br />
To prevent objects -like instruments- being drawn when the aircraft is actually too far away for them to be seen anyway, a range animation is used. <br />
<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>range</type><br />
<min-m>0</min-m><br />
<max-m>30</max-m><br />
</animation><br />
</syntaxhighlight><br />
<br />
* '''min-m:''' the shortest distance (in meters) from the object center at which it is visible.<br />
* '''max-m:''' the largest distance (in meters) from the object center at which it is visible.<br />
<br />
You could also use the generic level of detail (LOD) properties, which can be set by the user through View > Adjust LOD rangers: <br />
{| class="wikitable"<br />
! Property<br />
! Description<br />
! Default value<br />
|-<br />
|<tt>/sim/rendering/static-lod/bare</tt><br />
| only a rough exterior model<br />
| 30,000 m<br />
|-<br />
|<tt>/sim/rendering/static-lod/rough</tt> <br />
| most should be visible<br />
| 9,000 m<br />
|-<br />
|<tt>/sim/rendering/static-lod/detailed</tt> <br />
| all details should be visible<br />
| 1,500 m<br />
|}<br />
<br />
The animation code will look like this:<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>range</type><br />
<min-m>0</min-m><br />
<max-property>sim/rendering/static-lod/bare</max-property><br />
</animation><br />
</syntaxhighlight><br />
<br />
You can have both ranges (max and min) bound to a property, or just one of them.<br />
* '''min-property:''' <br />
* '''max-property:'''<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
=== Rotate ===<br />
One of the most important and frequently used animations of all. It rotates an object to an absolute position in degrees, as provided by the property-value.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>rotate</type><br />
<property>surface-positions/left-aileron-pos-norm</property><br />
<factor>25</factor><br />
<offset-deg>25</offset-deg><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
* '''offset-deg:''' is optional. Offset in degrees.<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
=== Scale ===<br />
A scale animation scales (resizes) an object. This can be either property-value dependant (first example) or a fixed scale (second example).<br />
<br />
<source><br />
<animation><br />
<type>scale</type><br />
<object-name>Object</object-name><br />
<property>sim/time/sun-angle-rad</property><br />
<x-min>1.0</x-min><br />
<y-min>1.0</y-min><br />
<z-min>1.0</z-min><br />
<x-factor>1.4</x-factor><br />
<y-factor>1.4</y-factor><br />
<z-factor>2.0</z-factor><br />
</animation><br />
</source><br />
<br />
* ?-min: the mimimum scale factor for each axis. If the property value would result in a smaller factor than this setting, the scale animation will hold.<br />
* ?-factor: the scale factor for each axis (factor*property=scale factor).<br />
<br />
<source><br />
<animation><br />
<type>scale</type><br />
<x-offset>0.5</x-offset><br />
<y-offset>0.5</y-offset><br />
<z-offset>0.5</z-offset><br />
</animation><br />
</source><br />
<br />
* x.offset: the scale factor.<br />
* Add [[#Center|&lt;center&gt;]] coordinates, to scale the object around that point.<br />
* '''You can optionally use an [[Howto:Animate_models#Expressions|expression]] in the <factor> or <offset> inputs.''' For more details see [[Expressions|Expressions]]<br />
<br />
=== Select ===<br />
This animation selects (or unselects) objects when certain conditions are true (or false). The example below shows the object when the n1 of engine[1] is higher than 25%.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>select</type><br />
<condition><br />
<greater-than><br />
<property>engines/engine[0]/n1</property><br />
<value>25</value><br />
</greater-than><br />
</condition><br />
</animation><br />
</source><br />
<br />
=== Shader ===<br />
<source><br />
<animation><br />
<type>shader</type><br />
<shader>chrome</shader><br />
<texture>chrome2.png</texture><br />
<object-name>Object</object-name><br />
</animation><br />
</source><br />
<br />
* '''shader:''' <br />
* '''texture:''' path to the texture used by the shader.<br />
<br />
=== Spin ===<br />
Very similar to [[#Rotate|rotate]], but the property provides a value in revolutions per minute (RPM) rather than an absolute position in degrees, and offset cannot be used.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>spin</type><br />
<property>engines/engine[0]/n1</property><br />
<factor>25</factor><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
<br />
=== Timed ===<br />
Swtiches between objects at specified intervals. This example switches between a lights-on model and a lights-off model. Lights on are shown 0.2 seconds, while lights off are displayed for 0.8 seconds.<br />
<br />
<source><br />
<animation><br />
<type>timed</type><br />
<object-name>BacklightOn</object-name><br />
<object-name>BacklightOff</object-name><br />
<use-personality type="bool">true</use-personality><br />
<branch-duration-sec>0.8</branch-duration-sec><br />
<branch-duration-sec>0.2</branch-duration-sec><br />
</animation><br />
</source><br />
<br />
=== Tracking ===<br />
The new (in 2.11) [[Tracking animation|'''locked-track animation''']] can do exactly the same thing as the [http://wiki.blender.org/index.php/Doc:2.6/Manual/Constraints/Tracking/Locked_Track Locked Track constraint] available in Blender. However it can also be used to simulate simple inverse kinematic systems consisting of two bones connected with a revolute joint (aka hinge). See [[Tracking animation|detailed explanantion]]<br />
<br />
=== Translate ===<br />
The same as [[#Textranslate|textranslate]], but this animation moves a whole object (so including fixed textures). The example below will move an object in the y-direction:<br />
<br />
{| class="wikitable" border="0" cellspacing="0" <br />
!Property value<br />
!Output<br />
|-<br />
| -1<br />
| -2.5<br />
|-<br />
| 0<br />
| 2.5<br />
|-<br />
| 1<br />
| 7.5<br />
|}<br />
<br />
<source><br />
<animation><br />
<type>translate</type><br />
<object-name>Object</object-name><br />
<property>controls/seat/pilot/position-norm</property><br />
<factor>5</factor><br />
<offset-m>2.5</offset-m><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
* '''offset-m:''' is optional. Offset in meters.<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
== Material animation ==<br />
An animation type that can be used in various ways. Of course you can combine the below mentiond systems into one (big) animation.<br />
<br />
<source><br />
<animation> <br />
<type>material</type> <br />
<object-name>Object</object-name><br />
<property-base>sim/model/c172p/material</property-base><br />
<global type="bool">true</global> <!-- This tag is no longer supported --><br />
...<br />
lines as mentioned below<br />
...<br />
</animation><br />
</source><br />
<br />
'''Optional:'''<br />
* '''property-base:''' when using prop(erties), you might want to set a property-base. All props will be relative to this path.<br />
* '''global (depreciated):''' by setting this to <tt>true</tt>, all objects using the same material as the defined object(s) (via <tt><object-name></tt>) will be affected by the animation. This is preferred to listing several objects in <object-name> tags. It's not only faster, but also doesn't break animations by forcing objects together. <span style="color:red; text-decoration: underline;">This tag is no longer supported</span><br />
<br />
'''Notes:'''<br />
* Numbers are clamped to 0.0-1.0, except "shininess", which is clamped to 0-128.<br />
* By appending <tt>-prop</tt> each of the material properties can read its value from another property.<br />
<br />
=== Ambient ===<br />
<source><br />
<ambient><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</ambient><br />
</source><br />
<br />
=== Diffuse ===<br />
<source><br />
<diffuse><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</diffuse><br />
</source><br />
<br />
=== Emission ===<br />
{{Main article|Howto: Illuminate faces}}<br />
<source><br />
<emission><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
<factor-prop>controls/lighting/panel-norm</factor-prop><br />
</emission><br />
</source><br />
<br />
Emission colors are multiplied by the factor-prop value. 1 is maximum color intensity, while 0 is the minimum. Colors are calculated according to the [http://en.wikipedia.org/wiki/RGB_color_model RGB color model].<br />
<br />
=== Shininess ===<br />
Shininess is clamped to 0-128.<br />
<source><br />
<shininess>105</shininess><br />
</source><br />
<br />
=== Specular ===<br />
<source><br />
<specular><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</specular><br />
</source><br />
<br />
=== Texture ===<br />
Used for the [[Livery over MP]] system.<br />
<br />
<source><br />
<property-base>sim/model/livery</property-base> <br />
<texture-prop>engine</texture-prop> <br />
<texture>KLM.png</texture> <br />
</source><br />
<br />
=== Transparency ===<br />
<source><br />
<transparency><br />
<alpha-prop>rotors/tail/rpm</alpha-prop><br />
<factor>-0.0015</factor><br />
<offset>1</offset><br />
</transparency><br />
</source><br />
<br />
=== Threshold ===<br />
<source><br />
<threshold>0.001</threshold><br />
</source><br />
<br />
== Texture Animations ==<br />
<br />
Applying different matrix transformations to the textures of an object.<br />
<br />
=== Textranslate ===<br />
A very important animation for cockpits! This animation moves textures over a surface.<br />
<br />
<source><br />
<animation><br />
<type>textranslate</type><br />
<object-name>Object</object-name><br />
<property>autopilot/settings/target-speed-kt</property><br />
<bias>0.0001</bias><br />
<factor>0.001</factor><br />
<step>100</step><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''bias:''' Adds an offset to the property before factor/step. A small value is needed to compensate for [http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems floating point accuracy].<br />
* '''factor:''' property * factor * texture width/height = the amount of pixels that the texture should be translated. If your texture is 256 pixels, an textranslate of 0.1 will result in the texture moving with 26 pixels, into the direction specified by the axis settings.<br />
* '''step:''' the step size at which the texture is translated. If this is set to 0.1, the texture will only be translated at 0.1, 0.2, 0.3 etc.<br />
* '''axis:''' the direction in which the texture is translated. Y is up/down, while X is left/right.<br />
<br />
=== Texrotate ===<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>texrotate</type><br />
<property>some/property/path</property><br />
<factor>25</factor><br />
<offset-deg>25</offset-deg><br />
<center><br />
<x>0.5</x><br />
<y>0.5</y><br />
<z>0</z><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>0</y><br />
<z>1</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
=== Textrapezoid ===<br />
<br />
<source><br />
<animation><br />
<type>textrapezoid</type><br />
<object-name>HUD.l.canvas</object-name><br />
<property>/hud/trapezoid-correction</property><br />
<side>bottom</side><br />
</animation><br />
</source><br />
<br />
* '''side''': side of quad which should be scaled (''top'' (default)/''right''/''bottom''/''left'')<br />
<br />
=== Texmultiple ===<br />
<br />
Only one texture matrix can be applied to each object. With ''textmultiple'' multiple texture animations can be combined into a single matrix, applied to the specified object.<br />
<br />
<source><br />
<animation><br />
<type>texmultiple</type><br />
<object-name>HUD.l.canvas</object-name><br />
<transform><br />
<subtype>textranslate</subtype><br />
<property>/hud/offset-x</property><br />
<axis><br />
<x>1</x><br />
<y>0</y><br />
<z>0</z><br />
</axis><br />
</transform><br />
<transform><br />
<subtype>textranslate</subtype><br />
<property>/hud/offset-y</property><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</transform><br />
<transform><br />
<subtype>textrapezoid</subtype><br />
<property>/hud/trapezoid-correction</property><br />
</transform><br />
</animation><br />
</source><br />
<br />
== Object interaction animations ==<br />
=== Enable-hot ===<br />
Scenery objects are automatically defined as solid by FlightGear, meaning that an aircraft can taxi on them and/or crash when touching. For certain objects (groundmarkings, beacon light-beams etc.) this might be an unwanted feature. The solidness can be disabled with the following animation:<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<enable-hot type="bool">false</enable-hot><br />
</animation><br />
</source><br />
<br />
* '''enable-hot:''' can be either true or false. Remember that objects are automatically solid, so it should not be necessary to set this at all when wanting solidness.<br />
<br />
=== Interactions ===<br />
<source><br />
<animation> <br />
<type>interaction</type> <br />
<object-name>Object</object-name> <br />
<interaction-type>carrier-wire</interaction-type> <br />
</animation> <br />
</source><br />
<br />
* '''interaction-type:''' can have the following values:<br />
** '''carrier-catapult:'''<br />
** '''carrier-wire:''' makes the object act as an arresting wire, as used on [[aircraft carrier]]s.<br />
<br />
== Direct manipulation animations ==<br />
=== Knob / slider (v. 2.11-) ===<br />
{{Main article|Knob / slider animation}}<br />
<br />
=== Pick ===<br />
{{Main article|Howto: Make a clickable panel#Pick}}<br />
<br />
== Shadow Handling ==<br />
There exist several possibilites for handling of shadows. <br /><br />
See '''[[ALS_technical_notes|ALS Technical Notes]]''' and more specific '''[[ALS_technical_notes#ALS_fuselage_shadow_effect|Fuselage Shadow Effect with ALS]]''' for a relatively simple shadow handling.<br /><br />
See '''[[Project Rembrandt]]''' which - amongst other functionality - implements a very realistic shadow mapping.<br />
<br />
== References ==<br />
{{Appendix|all|<br />
* {{cite web |url=http://www.opensubscriber.com/message/flightgear-devel@flightgear.org/958955.html |title="material" animation (and the bo105 as an example) |first=Melchior |last=Franz |date=22 March 2005 |work=FlightGear-devel mailinglist }}<br />
* {{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01546.html |title=flash animation |first=Frederic |last=Bouvier |date=22 Feb 2006 |work=FlightGear-devel mailinglist }}<br />
}}<br />
<br />
<br />
[[Category:Aircraft enhancement|Animate models]]<br />
[[Category:Howto|Animate models]]<br />
[[Category:Modeling|Animate models]]<br />
[[Category:Scenery enhancement|Animate models]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_February_2017&diff=107067FlightGear Newsletter February 20172017-02-23T04:21:36Z<p>Flug: /* Things to try in your new JSBSim Camel: */</p>
<hr />
<div>{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter January 2017]].}}<br />
<br />
{{Newsletter-header|February 2017}}<br />
<div style="border-bottom: 3px double #BBB"><br />
{| width="100%" |<br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Development news}}<br><br />
{{Newsletter-cover-header|In the hangar}}<br><br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Scenery Corner}}<br><br />
{{Newsletter-cover-header|Community News}}<br><br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Contributing}}<br><br />
[[#Translators required|Translators required]]<br><br />
[[#FlightGear logos|FlightGear logos]]<br><br />
[[#Screenshots|Screenshots]]<br><br />
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small><br />
|}</div><br />
==Development news==<br />
<br />
===Bombable Add-on: Update 4.6 now available - Full Compatibility with FG 2016.x.x===<br />
The [[Bombable]] add-on--which converts FlightGear into full fledged combat flight simulator, with realistic weapons, dogfighting, bombing, and strafing--either with AI opponents or via multiplayer, has been updated to version 4.6.<br />
<br />
The new version of Bombable brings full compatibility with FlightGear through 2016.4.4.<br />
<br />
Download the Bombable add-on, or find out more, on the [[Bombable|Bombable wiki page]]<br />
<br />
[[File:Bombable-Camel-vs-Camel.png|framed|center|The Bombable Add-On features aircraft from World War I through modern times]]<br />
<br />
== In the hangar ==<br />
<br />
===JSBSim Sopwith Camel Updated to Ver. 2.0alpha===<br />
Flug's JSBSim Sopwith Camel has undergone major revisions and the 2.0alpha version of the aircraft has been released. <br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=4&t=19584&start=45#p305653 More information and download the JSBSim Camel here]<br />
<br />
[[File:real-sopwith-camel-1917-vs-flightgear-2017.png|framed|center|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
<br />
====Major features of the new release:====<br />
* '''Greatly updated/refined flight dynamics model''', even more closely adhering to the historically reported behavior of the aircraft<br />
* '''Crashes modeled''' - parts break, dust, explosions, etc. <br />
[[File:JSBSim-camel-bad-crash.jpg|framed|right|JSBSim Camel: Bad Crash]]<br />
* '''Completely new sound design''' - hear when you are rolling, landing gear makes contact, wind buffeting etc<br />
* '''Ground interactions''' - tail drag, wheels, wingtip, etc dragging surface kicks up dust<br />
* '''Water landings''' - you can successfully ditch in water, kicks up spray & other effects<br />
* '''Friction effects and bumps''' - you can land or take off on almost any suitable land, but you will notice increased drag from e.g. tall grass, bumps, and you might break a landing gear if you're not careful. Use ''''n' key to nudge the aircraft''' if you get stuck in a hole or ditch.<br />
* '''New Inspect Aircraft View''' - based on Walk View, this allows you to easily get various views near the aircraft<br />
<br />
[http://www.youtube.com/watch?v=QOXPFoV-JTI View a video demo of an early version of some of these features.]<br />
<br />
====Things to try in your new JSBSim Camel: ====<br />
* '''Crash landing''' <br />
[[File:JSBSim-camel-ground-effects.jpg|300px|thumbnail|right|JSBSim Camel Ground Contact Effects]]<br />
* '''Hard landing'''<br />
* '''Over-g/overspeed'''<br />
* '''Inverted flight'''<br />
* '''Land in a random field''', try to take off again (use 'n' as needed for nudges, and '''menu Camel/Repair''' as needed--because you WILL need it).<br />
* '''Water landing''' - try both a controlled ditch and hard landing <br />
* '''Scrape a wing''' on takeoff or landing<br />
* '''Nose over''' on takeoff or landing (menu Camel/Repair afterwards . . . )<br />
* '''Take off, land and do touch-and-go landings''' while viewing from external view (Model View or Inspect Aircraft View)<br />
* '''How fast can you do a level 360 degree turn''' left or right? Real Camel pilots could do it 8-10 seconds level flight to level flight.<br />
* '''Spins and recovery''' - try powered stall and unpowered stall in level flight; pulling into a stall at 45, 60, and 90 degree bank angles, etc. How about a stall from inverted flight? Can you figure out how to enter a flat inverted spin from inverted flight--as reported by WWI Camel pilots?<br />
* Take offs and landings in '''calm weather, headwind, crosswind, tailwind'''. Can you successfully take off and land in a strong crosswind, for example?<br />
* Take offs and landings in calm weather, headwind, crosswind, tailwind. Can you successfully take off and land in a strong crosswind, for example?<br />
* '''Loops, barrel rolls, split-s turns, wingovers, hammerheads,''' other typical acrobatic and fighter maneuvers. What happens if you pull the stick back moderately or hard at the top of a loop?<br />
[[File:JSBSim-camel-nosing-over2.jpg|framed|left|JSBSIM Camel: Nosing Over]]<br />
* Install the '''[http://wiki.flightgear.org/Bombable Bombable] add-on and dogfight''' other Camels, Spads, Fokkers, etc.<br />
* Or '''dogfight via multiplayer''' with [http://wiki.flightgear.org/Bombable Bombable]<br />
<br />
Note that the JSBSim version of the Camel included in the pack is the primary emphasis of this release. The JSBSim FDM and effects mentioned above are the point of the release. The aircraft model is identical to the FG Camel, so you won't see anything new there! And the release also includes a YASim version of the Camel that is Bombable compatible but doesn't include any other special effects or FDM development of the type outlined above.<br />
<br />
In short, to see fly the *JSBSim Camel*. In the FG aircraft menu, look for *Sopwith Camel 1F.1 (JSBSim, Historically Accurate FDM & Weapons, Bombable-compatible, ver 2.0)*.<br />
<br />
Version 2.0alpha is a pre-release and may be refined further (based on user feedback) before the final release. However, the release is fully functional and generally well tested.<br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=4&t=19584&start=45#p305653 More information and download the JSBSim Camel here]<br />
[[File:JSBSim-camel-tumbling2.jpg|728x576px|framed|center|JSBSim Camel: Tumbling to a stop]]<br />
<br />
== Scenery corner ==<br />
== Community News ==<br />
== Contributing ==<br />
=== Translators required ===<br />
{|<br />
| [[File:en.gif]]<br />
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].<br />
|-<br />
| [[File:fr.gif]]<br />
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].<br />
|-<br />
| [[File:de.gif]]<br />
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.<br />
|-<br />
| [[File:nl.gif]]<br />
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].<br />
|-<br />
| [[File:es.gif]]<br />
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].<br />
|-<br />
| [[File:cat.gif]]<br />
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].<br />
|-<br />
| [[File:pt.gif]]<br />
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].<br />
|}<br />
<br />
=== FlightGear logos ===<br />
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.<br />
<br />
=== Screenshots ===<br />
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].<br />
<br />
==== Screenshot of the Month ====<br />
If you want to participate in the screenshot contest of February, you can submit your candidate to [https://forum.flightgear.org/viewtopic.php?f=19&t=31597 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=31597#p304721 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of February.<br />
[[Category:FlightGear Newsletter|2017 02]]<br />
[[Category:Changes after 2017.1]]<br />
[[de:FlightGear Newsletter Februar 2017]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_February_2017&diff=107066FlightGear Newsletter February 20172017-02-23T04:21:04Z<p>Flug: /* Development news */ bombable</p>
<hr />
<div>{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter January 2017]].}}<br />
<br />
{{Newsletter-header|February 2017}}<br />
<div style="border-bottom: 3px double #BBB"><br />
{| width="100%" |<br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Development news}}<br><br />
{{Newsletter-cover-header|In the hangar}}<br><br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Scenery Corner}}<br><br />
{{Newsletter-cover-header|Community News}}<br><br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-header|Contributing}}<br><br />
[[#Translators required|Translators required]]<br><br />
[[#FlightGear logos|FlightGear logos]]<br><br />
[[#Screenshots|Screenshots]]<br><br />
<small>[[#Screenshot of the Month|Screenshot of the Month]]</small><br />
|}</div><br />
==Development news==<br />
<br />
===Bombable Add-on: Update 4.6 now available - Full Compatibility with FG 2016.x.x===<br />
The [[Bombable]] add-on--which converts FlightGear into full fledged combat flight simulator, with realistic weapons, dogfighting, bombing, and strafing--either with AI opponents or via multiplayer, has been updated to version 4.6.<br />
<br />
The new version of Bombable brings full compatibility with FlightGear through 2016.4.4.<br />
<br />
Download the Bombable add-on, or find out more, on the [[Bombable|Bombable wiki page]]<br />
<br />
[[File:Bombable-Camel-vs-Camel.png|framed|center|The Bombable Add-On features aircraft from World War I through modern times]]<br />
<br />
== In the hangar ==<br />
<br />
===JSBSim Sopwith Camel Updated to Ver. 2.0alpha===<br />
Flug's JSBSim Sopwith Camel has undergone major revisions and the 2.0alpha version of the aircraft has been released. <br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=4&t=19584&start=45#p305653 More information and download the JSBSim Camel here]<br />
<br />
[[File:real-sopwith-camel-1917-vs-flightgear-2017.png|framed|center|Real Sopwith Camel 1917 vs FlightGear JSBSim Camel 2017]]<br />
<br />
====Major features of the new release:====<br />
* '''Greatly updated/refined flight dynamics model''', even more closely adhering to the historically reported behavior of the aircraft<br />
* '''Crashes modeled''' - parts break, dust, explosions, etc. <br />
[[File:JSBSim-camel-bad-crash.jpg|framed|right|JSBSim Camel: Bad Crash]]<br />
* '''Completely new sound design''' - hear when you are rolling, landing gear makes contact, wind buffeting etc<br />
* '''Ground interactions''' - tail drag, wheels, wingtip, etc dragging surface kicks up dust<br />
* '''Water landings''' - you can successfully ditch in water, kicks up spray & other effects<br />
* '''Friction effects and bumps''' - you can land or take off on almost any suitable land, but you will notice increased drag from e.g. tall grass, bumps, and you might break a landing gear if you're not careful. Use ''''n' key to nudge the aircraft''' if you get stuck in a hole or ditch.<br />
* '''New Inspect Aircraft View''' - based on Walk View, this allows you to easily get various views near the aircraft<br />
<br />
[http://www.youtube.com/watch?v=QOXPFoV-JTI View a video demo of an early version of some of these features.]<br />
<br />
====Things to try in your new JSBSim Camel: ====<br />
* '''Crash landing''' <br />
[[File:JSBSim-camel-ground-effects.jpg|300px|framed|right|JSBSim Camel Ground Contact Effects]]<br />
* '''Hard landing'''<br />
* '''Over-g/overspeed'''<br />
* '''Inverted flight'''<br />
* '''Land in a random field''', try to take off again (use 'n' as needed for nudges, and '''menu Camel/Repair''' as needed--because you WILL need it).<br />
* '''Water landing''' - try both a controlled ditch and hard landing <br />
* '''Scrape a wing''' on takeoff or landing<br />
* '''Nose over''' on takeoff or landing (menu Camel/Repair afterwards . . . )<br />
* '''Take off, land and do touch-and-go landings''' while viewing from external view (Model View or Inspect Aircraft View)<br />
* '''How fast can you do a level 360 degree turn''' left or right? Real Camel pilots could do it 8-10 seconds level flight to level flight.<br />
* '''Spins and recovery''' - try powered stall and unpowered stall in level flight; pulling into a stall at 45, 60, and 90 degree bank angles, etc. How about a stall from inverted flight? Can you figure out how to enter a flat inverted spin from inverted flight--as reported by WWI Camel pilots?<br />
* Take offs and landings in '''calm weather, headwind, crosswind, tailwind'''. Can you successfully take off and land in a strong crosswind, for example?<br />
* Take offs and landings in calm weather, headwind, crosswind, tailwind. Can you successfully take off and land in a strong crosswind, for example?<br />
* '''Loops, barrel rolls, split-s turns, wingovers, hammerheads,''' other typical acrobatic and fighter maneuvers. What happens if you pull the stick back moderately or hard at the top of a loop?<br />
[[File:JSBSim-camel-nosing-over2.jpg|framed|left|JSBSIM Camel: Nosing Over]]<br />
* Install the '''[http://wiki.flightgear.org/Bombable Bombable] add-on and dogfight''' other Camels, Spads, Fokkers, etc.<br />
* Or '''dogfight via multiplayer''' with [http://wiki.flightgear.org/Bombable Bombable]<br />
<br />
Note that the JSBSim version of the Camel included in the pack is the primary emphasis of this release. The JSBSim FDM and effects mentioned above are the point of the release. The aircraft model is identical to the FG Camel, so you won't see anything new there! And the release also includes a YASim version of the Camel that is Bombable compatible but doesn't include any other special effects or FDM development of the type outlined above.<br />
<br />
In short, to see fly the *JSBSim Camel*. In the FG aircraft menu, look for *Sopwith Camel 1F.1 (JSBSim, Historically Accurate FDM & Weapons, Bombable-compatible, ver 2.0)*.<br />
<br />
Version 2.0alpha is a pre-release and may be refined further (based on user feedback) before the final release. However, the release is fully functional and generally well tested.<br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=4&t=19584&start=45#p305653 More information and download the JSBSim Camel here]<br />
[[File:JSBSim-camel-tumbling2.jpg|728x576px|framed|center|JSBSim Camel: Tumbling to a stop]]<br />
<br />
== Scenery corner ==<br />
== Community News ==<br />
== Contributing ==<br />
=== Translators required ===<br />
{|<br />
| [[File:en.gif]]<br />
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].<br />
|-<br />
| [[File:fr.gif]]<br />
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].<br />
|-<br />
| [[File:de.gif]]<br />
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.<br />
|-<br />
| [[File:nl.gif]]<br />
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].<br />
|-<br />
| [[File:es.gif]]<br />
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].<br />
|-<br />
| [[File:cat.gif]]<br />
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].<br />
|-<br />
| [[File:pt.gif]]<br />
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].<br />
|}<br />
<br />
=== FlightGear logos ===<br />
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.<br />
<br />
=== Screenshots ===<br />
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].<br />
<br />
==== Screenshot of the Month ====<br />
If you want to participate in the screenshot contest of February, you can submit your candidate to [https://forum.flightgear.org/viewtopic.php?f=19&t=31597 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=31597#p304721 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of February.<br />
[[Category:FlightGear Newsletter|2017 02]]<br />
[[Category:Changes after 2017.1]]<br />
[[de:FlightGear Newsletter Februar 2017]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Bombable&diff=107065Bombable2017-02-23T04:19:10Z<p>Flug: /* Versions */</p>
<hr />
<div>{{Infobox subsystem<br />
|image = Bombable4 4 600.png<br />
|name = Bombable Addon<br />
|started = 2009<br />
|description = Addon for FlightGear that adds support for dogfighting, damage, and AI bots.<br />
|status = Under active development (01/2014)<br />
|developers = Flug<br />
|folders = https://github.com/bhugh/Bombable<br />
}}<br />
<br />
[[File:camel-through-wing.jpg|thumb|[[Sopwith Camel]]]]<br />
[[File:spad-vs-camel.jpg|thumb]]<br />
[[File:warthog-down-on-bay-bridge.jpg|thumb|[[A-10 Warthog]]]]<br />
<br />
'''Bombable''' is an addon for [[FlightGear]] that adds bombs, weapons, damage, fire, and explosion effects to FlightGear that work with the main [[aircraft]], [[scenery]], [[AI]] aircraft and other AI objects, and [[multiplayer]] aircraft objects. Bombable turns FlightGear into a combat flight simulator.<br />
<br />
[https://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772#p43772 Download the current version of the Bombable add-on here.]<br />
<br />
== Features ==<br />
* [[Multiplayer]] dogfighting.<br />
* AI scenarios that allow you to use any FlightGear aircraft that can shoot weapons and/or drop bombs for air-to-air, air-to-ground, and anti-maritime combat missions against AI tanks, [[jeep]]s, ships, and aircraft that will fight you.<br />
* Explosion and burning when you crash.<br />
* Damage added to your aircraft when you exceed the [[Howto: Define limits|aircraft's limitations]] (excessive g-force, exceeding V<sub>NE</sub>, etc.).<br />
<br />
== Downloading and using in FlightGear ==<br />
* [http://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772 Download Bombable on the Flightgear Forums thread for Bombable] or [http://brenthugh.com/flightgear/bombable4-5b.zip using this direct link to the .zip file]<br />
* Instructions for installing and using Bombable are included in the Docs directory of the download file.<br />
<br />
== List of Bombable Aircraft ==<br />
[[Sopwith Camel]], SPAD VII, [[Fokker Dr.I]] Triplane, [[A6M2 Zero]], F6F Hellcat, [[Fairchild Republic A-10 Thunderbolt II|A-10 Warthog]], [[UFO]], and other included aircraft such the [[Polikarpov I16]].<br />
<br />
== How to add Bombable to a FlightGear aircraft ==<br />
* [[Howto: Adding Bombable to FlightGear Aircraft]]<br />
<br />
== Related articles ==<br />
* [[Howto: Dogfighting over Multiplayer with Bombable]]<br />
* [[Dicta Boelcke]] rules for dogfighting by the WWI aces<br />
* [[Bombable_Development_Roadmap]]<br />
<br />
== Bombable video ==<br />
{{#ev:youtube|PirnWJHZtcg}}<br />
<br />
== Readme ==<br />
* http://wiki.flightgear.org/Bombable_Readme<br />
<br />
== History ==<br />
FlightGear seems to have most all the pieces under the hood to make an excellent platform for simulating historical military aircraft, dogfighting and fighter plane tactics with aircraft of different eras, and bombing runs and other tactics from various historical eras, and other aircraft simulations that could depend on FlightGear's realistic, underlying flight models.<br />
<br />
Some aircraft have implemented limited weapons, armament, and explosions. The A-10 Warthog was released, including an AI scenario for the A-10 to bomb M-1 tanks, which then exploded realistically.<br />
<br />
The Bombable add-on was designed to put all the available FlightGear elements together as a proof of concept to see if FlightGear can be a realistic simulator for aircraft that include weapons and armament, working with AI aircraft and over Multiplayer, including:<br />
<br />
* Realistic impact detection and damage assessment<br />
* Damage tracking over AI and Multiplayer and communication of impacts and damage levels over Multiplayer<br />
* AI aircraft, vehicles, and ships that can evade, attack, and generally act realistically<br />
* Explosions, fires, and so on, upon damage and crash<br />
<br />
Bombable was developed with the idea that in a realistic flight simulator environment, the rules and techniques of dogfighting and aerial warfare--like the World War I [[Dicta Boelcke]], by Oswald Boelcke, one of the first great aces of the war--would naturally develop and naturally play out.<br />
<br />
== Status ==<br />
As of January 2014 (Bombable 4.5) the status is:<br />
* Damage impact detection is the most advanced element in Bombable. It is greatly improved over FG's native impact detection system, and the framework is in place for further refinements or as a model for FG to implement more refined impact detection internally.<br />
<br />
* Damage tracking and communication over Multiplayer works well in a very lightweight with a very low data rate. However, only a general damage percentage is tracked and communicated. Damage to different locations or systems is not simulated.<br />
<br />
* AI aircraft behavior is controlled by a Nasal script that modifies FlightGear's AI system. This is Bombable's weakest point--in many ways the Nasal script is simply fighting the underlying AI code for control of the AI aircraft. Creating more realistic/intelligent AI fighter aircraft will require greater integration with FlightGear's AI systems. That is a problem for programmers--but for users, the AI aircraft now move, attack, and evade with reasonable realism.<br />
<br />
* AI aircraft weapons systems are simulated through a probabilistic approach. And shown visually via FlightGear's Particle System. At this time it appears that creating and tracking AI weapon projectiles via FlightGear's submodel system, which simulates submodel dynamics and impacts precisely, is technically difficult and would have a drastic negative impact on the FlightGear framerate. Bombable follows the more promising of simulating AI weapon fire using FlightGear's particle system, which allows for visual display of numerous moving particles with little to no effect on the framerate and calculating weapons hits mathematically in a simple way that has minimal impact on framerate.<br />
<br />
* '''AI aircraft move vertically &ndash; and do loops''': AI aircraft now move much more realistically in the vertical direction. They do loops, dive, and all the rest. Their behavior (climb rates, dive rates, and so on) matches those of the corresponding FG aircraft. This makes for a much more realistic 3-D dogfighting experience in FlightGear.<br />
<br />
* Proof of concept for explosions, fires, weapons damage animations, and crash animations is in place. All these elements could be refined for greater realism.<br />
<br />
* '''Realistic roll rates for ai aircraft''': Roll rates are one the most important factors determining the effectiveness of fighter aircraft-- aircraft that can roll faster can turn faster. Now the roll rate for AI aircraft in scenarios can be customized, and bugs in the roll & turn routines for AI aircraft have been fixed.<br />
<br />
* '''Significant performance improvements''': Bombable now makes much less of an impact on your framerate, and much less stuttering & slowdown at key points, like when numerous machine gun rounds are impacting.<br />
<br />
* '''Relocate any scenario to your location''': Have an AI scenario based in San Francisco, but want to fly in London? No problem, just hit a button in the Bombable menu and your scenario comes to you, wherever you are. Damage levels for AI aircraft and objects are re-set. It's like loading a new scenario without having to re-start FlightGear.<br />
<br />
* '''Re-spawn AI aircraft & objects''': After you have shot down (or been shot down by!) AI aircraft or objects in scenarios, you can instantly re-spawn them and try again. (Available in the Bombable menu.)<br />
<br />
The last two are kind of game changers. With FG 2.12's ability to load and unload scenarios instantly and easily, and Bombable's ability to move scenarios to wherever you are, anywhere in the world, scenarios are now flexible and moveable.<br />
<br />
== Versions ==<br />
<br />
[https://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772#p43772 Download the current version of the Bombable add-on here.] Below is information about previous versions and updates. <br />
[[File:Bombable-Camel-vs-Camel.png|300px|thumbnail|right|Camel v. Camel in Bombable]]<br />
<br />
=== Version 4.6 (2/2017), compatible with FG 2016.4.4 and earlier versions ===<br />
Small tweaks for 100% compatibility with FG version 3.0 through 2016.4.4.<br />
<br />
=== Version 4.5b (01/2014, compatible with FG 2.12.1 and earlier versions) ===<br />
Version 4.5b works with FG 2.12.x and has some improvements that take advantage of FG 2.12's new AI scenario handling system.<br />
<br />
In addition, 4.5b has some improved aircraft, tweaks AI aircraft performance and realism, and fixes a few bugs.<br />
<br />
=== Version 4.5 (04/2013, compatible with FG 2.10) ===<br />
Flug just uploaded a new version of Bombable that is compatible with FlightGear 2.10.0--in fact, it should work with all 2.X versions of FlightGear.<br />
<br />
http://brenthugh.com/flightgear/bombable4-5.zip<br />
<br />
Thanks to Voudoun da Vinci for helping track down some of the problems and the fixes.<br />
<br />
Bombable is still pretty new to FG 2.10, so please let me know if you find any problems. Message in this thread is the best way.<br />
<br />
FYI part of the package is a new, greatly improved, historically accurate (to the degree I could make it so!) JSBSim FDM for the Sopwith Camel.<br />
<br />
The idea was to make the Camel fly like a real Camel--not just when flying safely well within the envelope like a commercial pilot, but when taking it to the edge and beyond, as real combat pilots did in WWI.<br />
<br />
Not easy to fly--but a lot of fun to try. It's SopwithCamel-Bombable (JSBSim), included in the Bombable distribution.<br />
<br />
Bombable is now compatible with FG 2.10 (as well as 2.8, 2.6 and earlier versions) and includes a new, far more realistic and true-to-life JSBSim flight model for the Sopwith Camel.<br />
<br />
* The new JSBSim version of Sopwith Camel is far more realistic as a fighter aircraft, implementing nearly every documented flight characteristic of the original Camel. The new JSBSim Camel is very quirky and difficult to fly--just as the original Camel was. See separate file documenting the JSBSim flight model. To try the new Camel flight model, in FGRun select:<br />
<br />
* sopwithCamel-Bombable<br />
* Sopwith Camel 1F.1 (JSBSim, Experimental, Guns/Bombable)<br />
<br />
* Improvements to make Bombable more compatible with FG 2.10 (as well as 2.6 and 2.8):<br />
<br />
* Continue to refined workaround for the FG bug allowing only one particlesystem per XML file. <br />
<br />
* Workarounds for a stricter XML parser that was adopted by FG somewhere between FG 2.4 and 2.10. Several of the aircraft XML files would not parse due to the special or foreign characters included in comments. <br />
<br />
* Updated sound files to mono format (required by FG 2.10 3-D sound system).<br />
<br />
* Minor updates/bugfixes to aircraft, scenarios<br />
<br />
=== Version 4.4 ===<br />
Version 4.4 is a complete revamping of Bombable into more of a complete, cohesive system for Multiplayer and AI dogfighting and bombing. The accuracy of all the basic functions has been improved and made more realistic, and a number of new "Bombable- compatible" aircraft have been included, from WWI fighters to modern-day jet fighters.<br />
<br />
* '''Weapon hit detection greatly improved''': Complete re-vamped system for detecting your weapon hits on AI or Multiplayeraircraft. It is no longer limited by FG's built-in, large "damage cylinder". It now extends the weapon's flight path within that cylinder to determine precisely how close the weapon hit on your target--allowing muchbetter modeling of hits, damage, and results.<br />
<br />
* '''Damage analysis system greatly improved''': In addition, the damage analysis system has been updated to calculate and use the momentum of weapons as the basis for determing damage of weapon hits. This has proven to be far more realistic and gives much better results thanthe previous ad-hoc method.<br />
<br />
* '''Greatly improved damage impact animations''': Previous versions of Bombable relied on FG's built-in impact animations. The result was that FG often showed the damage impact explosion when the projectile had actually made a clean miss of the aircraft. In Bombable 4.4, this problem is solved, with impact explosions being shown exactly where Bombable calculates they happen, and only when Bombable detects an actual hit with damage. So you have much tigher correspondence between what you see and whatdamage is recorded.<br />
<br />
* The impact animations work for all types of small and large caliber guns and bombs. The system uses FG's excellent particle system to draw the gun and bomb impacts with almost not impact on framerate, and far less jerkiness than FG's usual submodel method. As a bonus, the new animations look much, much better as well, and the visual of the impact matches the actual damage of the impact quite well--that is, the visual size of a bomb explosion closely matches the actual damage area of the bomb; small caliber weapons hits show as smallerimpacts that large caliber weapons, etc.<br />
<br />
* '''Your own weapons can damage you''': Drop a bomb on your own aircraft or too near it? You'll see the results--damage to your aircraft. This makes bombing runs far more realistic--if you get too close to the bomb impact, you'll feel the results.<br />
<br />
* '''Impact visuals, smoke, and fire shown on scenery''': If you drop a bomb on a scenery or a building, you see an explosion and a long-lasting fire &ndash; just as you do when you bomb a jeep, tank, or airplane. Previously, the bombs, guns, rockets, and other armament only had an effect on AI and MP aircraft, tanks, ships, and so on. Now armament hits affect almost everything in the FlightGear world.<br />
<br />
* '''Re-spawn AI aircraft''': After you have shot down (or been shot down by!) AI aircraft in scenarios, you can instantly re-spawn them and try again. (Available in the Bombable menu.)<br />
<br />
* '''Bombable Fokker DR.1 fixed''': Fixed/update the Fokker Dr.1 aircraft. It is now the same aircraft as distributed in FG 2.4.0 but with added historically accurate guns and an aircraft help file.<br />
<br />
* '''Bombable Grumman F6F Hellcat added''': Added a new Bombable-compatible aircraft, the Grumman F6F Hellcat. This makes a great foil to the A6M2 Zero, as they fought against each other in WWII. (As always, mucho thanks must go to the authors of the F6F aircraft--all I've done is update the weaponry to be historically accurate and add a thin veneer of tweaks to make the aircraft completely compatible with Bombable. All credit for aircraft design, systems, FDM, and everything else goes to the original authors, in this case EmanuelBaranger and others.)<br />
<br />
* '''New scenarios''': New scenario to show off the F6F, one to show offthe Bombable UFO, and one to help with testing: <br />
** BOMB-LakeTahoeWWIIB17BombersWithF6FCover.xml<br />
** BOMB-MarinCountyUFOInvasion.xml<br />
** BOMB-Kansas-City-Bombable-Testbed.xml <br />
<br />
* '''Bombable A-10 Warthog added''': The A-10 is the best plane to fly several scenarios and including it in the package means that it can be used to fly multiplayer bombable as well. It has several tweaks making it easier to use with the Bombable package and also improves an annoying bug where the A-10 slows FG's framerate massively after a few re-init/re-locates. (Again, all credit to the A-10 original authors--all I have done is adda few Bombable tweaks and specifics.)<br />
<br />
* '''Bombable UFO added''': This is mostly for testing; keys 1-9, 0, q, and w fire different weapons. A working AI version is included--so you can have dueling Bombable UFOs over Multiplayer or try the UFO dogfighting scenario (surprisingly fun!). Also a testbed scenario is included, and using the UFO with the BOMB-Kansas-City-Bombable-Testbed.xml scenario is the easiest way to test most Bombable functions, aircraft, and AI aircraft. (Based on FG's stock UFO, but with Bombable capabilitiesadded.)<br />
<br />
* '''Bomb damage''': Reconfigured damage impact of bombs; the bombs now act--lookand create damage--far closer to real data.<br />
<br />
* '''New menu''': Re-vamped Bombable menu with new/streamlined/more sensible options.<br />
<br />
* '''Reset damage''': In the new Bombable menu you can reset damage for main aircraft and AI aircraft and objects.<br />
<br />
* '''Bombable scenarios renamed''': Renamed all scenarios that come with the package with prefix "BOMB-". This should make it easier to find the scenarios and also update or remove them when necessary.<br />
<br />
* '''Smaller smoke/fire option''': A small fire option, used where appropriate, so that fires/explosions/damage don't always look sooverly huge.<br />
<br />
* '''Unusable aircraft removed''': Removed unused/unusable aircraft from the distribution. Some of these are perfectly fine for general flying, but weapons or other features don't work well with Bombable, and having them listed in the menus when they didn't really work made forconfusion.<br />
<br />
* '''Scenario fixes''': Some scenarios were not loading properly for some people in ver. 4.3. This might be because of inconsistencies in the case of some file and directory names. I worked on resolving thisissue, but please let me know if it is still happening.<br />
<br />
* '''Scenarios renamed''': Renamed all scenarios to start with "BOMB-". This should help us keep straight which scenarios work with Bombable and also troubleshoot and track down & fix problems with scenarios.<br />
<br />
* '''AI weapons improved''': AI weapons now malfunction when the AI aircraft, vehicle, or ship is damaged.<br />
<br />
* '''Misc. updates''': Updated included AI aircraft and scenarios to fit with the new impact detection system.<br />
<br />
* '''For bombable aircraft designers''': If you have designed aircraft to use with Bombable, you should look at the sample AI aircraft provided to see updates to the Bombable dimensions, vulnerabilities, and weapons sections. You will need to re-tool your aircraft slightly, but when finished the results will be much better.<br />
<br />
* '''Bug fixes''': Various small bug fixed and improvements, fixed a lot of the programs with scenarios, AI Aircraft, directories.<br />
<br />
See the To Do file (many of which have now been done) for many more changes, updates, and improvements.<br />
<br />
=== Version 4.3 ===<br />
* Multiplayer dogfighting is now working in FG 2.4.0. (It broke sometime in the FG 2.X.X. series.) Use one of the MP-dogfighting- enabled planes included in the packet (Sopwith Camel-Bombable/Yasim, SPAD VII-Bombable, or FKDR1-Bombable/JSB, or A6M2-Bombable/YASim--use the versions marked as Guns/Bombable, not the default FG installs) and make sure your opponent does the same--you will both be able to shoot and damage each other, see damage reports, etc.<br />
<br />
* Weapons on AI aircraft--which will shoot at you as you attack them--can now be placed in different locations and aimed indifferent directions.<br />
<br />
In combat, they will shoot you if that location/direction is lined up with you. The AI B-17 Bomber included in the package will shoot at you from the rear; the M-1 tank will shoot towards the front at about a 45 degree angle, Jeep will shoot forwards and upwards,Ferries will shoot forward or backwards, etc.<br />
<br />
The result is a far more realistic experience. Shooting bombers used to be like shooting fish in a barrel--now between the bombers shooting at you and the fighter planes coming in from high cover, you're lucky to score a few small hits and get out of therealive . . .<br />
<br />
* The AI Weapons system was generally improved and weapon strength, direction, size, location, and effectiveness can be specified in the XML file for each AI aircraft type. (If you're creating your own Bombable-enable aircraft, just add weapons specs in the WEAPONSsection of AI aircraft; see enclosed AI/Aircraft files for examples.)<br />
<br />
* Generally tweaked AI aircraft, attack & weapons routines, and AI scenarios for a better, more realistic experience. In particular,try:<br />
** MarinCountyWWIIBombersWithCover.xml (fly A6M2-Bombable/YASim)<br />
** MarinCountyCamelInvasion1-Simple.xml (fly Sopwith Camel-Bombable/YASim) <br />
<br />
* Again worked on the problem of getting AI aircraft to climb and dive more realistically instead of sedately. The AI aircraft are farmore realistic/active in the vertical direction now.<br />
<br />
* Bombable no longer overwrites existing aircraft or anything else in FG's installation. It will add new aircraft and a few other Bombable-specific files. All new/added aircraft have the suffix -Bombable. Bombable will overwrite-replace things from its ownprevious installation, but no other files.<br />
<br />
Generally when flying Bombable's AI scenarios or flying over multiplayer with another person using Bombable, your best experience will be to use one of the aircraft provided (and identifiable by the -Bombable extension) or another aircraftspecifically set up to use Bombable's capabilities.<br />
<br />
=== Version 4.2 ===<br />
* Made numerous changes/updates/improvements related to getting Bombable working with FG 2.4.0.<br />
<br />
* Found the FG 2.4.0 "reinit" problem in both M-1 and Jeep in AI/Aircraft & fixed<br />
<br />
* Reconfigured the damage calculations for light weapons in the test_impact function. Result may be that it is harder/takes more hits than before to damage aircraft or objects. If it is too hard you can select both "Easy Mode" and "Super Easy Mode" together to make it quite a bit easier to both hit targets and create damage. This still needs some refinement but it is setting the groundworkfor a better, more consistent way of dealing with damage.<br />
<br />
* Small refinements in display, damage reports, etc.<br />
<br />
* FG 2.4.0 is doing this crazy thing where it reinitializes AI objects in scenario repeatedly and also (sometimes!) slips in non-AI objects like joystick inputs for initialization as AI/scenario objects. This results in massive slowdowns and other bizarre behavior. So I've set up checks to disallow repeated re-inits of AI objects and only allow AI and Multiplayer objects (as opposed joystick input devices, etc) to initialize themselves with Bombable. The ultimate solution here is a FG code fix, but in the meanwhilesome of the worst effects might be mitigated.<br />
<br />
=== Version 4.0 ===<br />
This is a beta release that works with Flightgear 2.4.0. Some AI aircraft characteristics have changed in FG 2.4.0 so there are someproblems and different behavior in the AI aircraft.<br />
<br />
* Removed the "reinit" command in bombable.nas that made FG 2.4.0 croak.<br />
<br />
* Removed the mp_broadcast.nas file that is no longer necessary with FG 2.4.0 (and in fact the old version included with Bombable made FG2.4.0 choke).<br />
<br />
* FG 2.4.0 doesn't make the weight or mass of the armament available on impact (previous versions}}} did!), so a kludgy work-around wascreated.<br />
<br />
* Numerous other tweaks and bug fixes.<br />
<br />
=== Version 3.0p ===<br />
* This is a bit of an alpha release and has not been as thoroughly tested with all scenarios as previous releases.<br />
<br />
* '''AI aircraft are more mobile vertically''': AI Aircraft dodge and chase you more vertically, diving and climbing.<br />
<br />
* '''Various bugfixes'''<br />
<br />
=== Version 3.0o ===<br />
* '''AI aircraft shoot at and damage you''': When in an AI dogfight, if you let the AI aircraft get into position they have a chance to shoot at and possibly damage you. This is working best with WWI AI Aircraft (Camel, SPAD, Fokker) as in the Marin County Camel Invasion scenarios, but it will also work with the Zero and Warthog scenarios.<br />
<br />
* '''Mostly fixed menu/options save/restore bug''': Some of the options still don't save/restore correctly, but most do now.<br />
<br />
* '''Numerous other bugfixes/small improvements'''<br />
<br />
=== Version 3.0n ===<br />
* '''AI aircraft dodge and "attack" realistically''': AI dogfights just became 10X as realistic, as fighter planes will turn and attack, just as fighter planes did in WWI and WWII. Try the Marin County Camel Invasion and Marin County Zero Invasion scenarios for a taste of how this works. (No weapons for AI aircraft yet--maybe in the future.)<br />
<br />
* '''New scenario &ndash; B-17 bombers with fighter cover''': Fly out of Marin Ranch and attack a squadron of 6 B-17 Bombers. As you do so, the fighter squadrons descend and swarm you. They don't fire at you (yet! fodder for future versions!) but they turn aggressively towards you, evade your shots, etc., just as real fighters would.<br />
<br />
* '''Damaged ai aircraft crash more realistically'''<br />
<br />
* '''Greatly improved, more realistic damage analysis''': Damage assessment for guns is a lot more realistic, giving greater damage when you hit closer to the center of the object and allowing for the possibility that even small arms might strike a vital or explosive point, causing catastrophic damage. For instance, you can now damage the Nimitz or Eisenhower*--though it's still tough to sink.<br />
<br />
* '''More realistic fire starting''': One of the chief causes of combat aircraft damage is the fires that even small caliber weapons can cause--and fires are even more likely with heavier ammo that includes incendiary (high explosive) materials. Bombable now models that any hit may start a fire, and heavier rounds are more likely to start files. Fires progressively damage the aircraft and eventually bring it down. Beware that fires sometimes go out before completely disabling the aircraft--so monitor the enemy aircraft to make sure they do not recover and escape.<br />
<br />
* '''More realistic aircraft smoke starting''': Similar to fire starting, each damaging hit has the possibility to cause damage that causes the aircraft to emit a trail of smoke. The bigger/closer the hit, the more likely to cause this damage.<br />
<br />
* '''Bombable preferences/settings saved and restored at startup'''<br />
<br />
* '''Fixed excessive damage report problem''': Aircraft would continually report damage even after objects received 100% damage--now fixed.<br />
<br />
* '''Numerous small bugfixes'''<br />
<br />
* Note: You can bomb the Nimitz/Eisenhower carriers if you have the bombable carriers add-on: http://forum.flightgear.org/viewtopic.php?f=2&t=7082<br />
<br />
=== Version 3.0m ===<br />
* Positive and negative G-force limits are now settable separately (most aircraft have different limits for positive vs negative G, so this adds some realism)<br />
<br />
* Bugfixes on damage & damage report<br />
<br />
* Every hit now registers via on-screen popup (vs previous behavior of only showing damage when it increased past multiples of 5%)<br />
<br />
* Bugfixes on g-force damage that caused extraneous very high g forces to cause random damage<br />
<br />
* Bugfixes in multiplayer communication, fixed problems when MP is disabled or doesn't exist<br />
<br />
* Bugfix on bombable multiplayer unload (runtime error "listenerids") and improvement to unload routines<br />
<br />
* Fixed Easy/Super Easy Mode malfunction (Super Easy Mode never engaged; new default mode is Easy Mode which should give same performance as previous default mode)<br />
<br />
* Tuned damage/vulnerabilities on ferries (San Francisco Ferry Invasion scenario)<br />
<br />
=== Version 3.0L ===<br />
* '''Overspeed detection/damage'''<br />
<br />
* '''G-force and overspeed detection optional''': Switches in the Bombable menu to turn it off; turned off by default except for planes included in Bombable package.<br />
<br />
* '''Vulnerabilities framework for primary aircraft''': Allows max acceleration, max speed parameters to be set individually per aircraft (main aircraft) and then damage from overspeed/overacceleration is accrued when those limits are exceeded.<br />
<br />
* '''Blackout/redout tunable per aircraft''': Allows blackout & redout values to be set per aircraft--for instance to reflect that WWI aircraft had no pressure suits or special high-G training. This will help level the playing field and create uniformity in MP dogfighting with similar aircraft.<br />
<br />
* '''G-force and overspeed limits and damage amounts tuned''': For the four aircraft included in the Bombable package (A6M2 Zero, Sopwith Camel, SPAD VII, Fokker DR1) the g-force damage & overspeed damage parameters have been individually tuned and are fairly realistic.<br />
<br />
* '''Fires only for appropriate damage''': Overspeed & overacceleration (g-force) damage doesn't start a fire, though it will still rack up 100% damage and shut you down.<br />
<br />
* '''Numerous bugfixes'''<br />
<br />
=== Version 3.0k ===<br />
* '''Excessive G-force damages your aircraft:''' Excessive g-force now adds damage to your airframe and can even make you crash. To avoid damaging your aircraft due to excessive g-force, always fly with blackout/redout turned on and avoid pulling g-forces much beyond those that make you blackout or redout.<br />
<br />
* '''Zeros over marin county scenario:''' Marin County Zero Invasion scenario added.<br />
<br />
=== Version 3.0j (private release) ===<br />
* '''Burn/smoke on crash:''' Aircraft now catch fire, burn, and instantly go to 100% damage when they crash. This is broadcast via MP so others will see you burn when you crash.<br />
<br />
* '''A5mw zero for dogfighting:''' A6M2 ready for MP dogfighting included in release.<br />
<br />
* '''A6M2 Zero:''' Added historically accurate guns and cannons (fire with e and E) to A6M2 Zero.<br />
<br />
* '''Bombable A62M Zero:''' Included Bombable version of the AI A6M2 Zero from Hellcat's Carrier Bombable project, but also made a few tweaks/improvements to he AI A6M2 for improved realism. See http://www.4shared.com/file/235605076/6101800f/carrier_bombable.html<br />
<br />
* '''Dogfighting:''' Greatly improved dogfighting/multiplayer communication of damages<br />
<br />
* '''Bugfix DR 1:''' Added keyboard firing switch to Fokker DR 1 (use the 'e' key to fire the weapons).<br />
<br />
* '''Bugfixes:''' Many other miscellaneous bug fixes and improvements.<br />
<br />
=== Version 3.0i ===<br />
* '''Reset resets damage:''' In dogfighting, resetting or using the Location menu to change your location resets your damage to 0% and broadcasts that to others flying with you via multiplayer<br />
<br />
* '''FlightGear 2.0 compatible:''' Tested and works with FG 2.0 as well as FG 1.9 and CVS versions between 1.9 and 2.0<br />
<br />
* '''Bugfixes:''' Various small bugfixes<br />
<br />
=== Versions 3.0 through 3.0h ===<br />
* '''Bombable/shootable:''' Code to make objects, AI aircraft, MP aircraft bombable and shootable.<br />
<br />
* '''Moving AI bombable/shootable objects:''' Code to allow AI aircraft, naval vessels, and surface vehicles to move (sort of) realistically and act as bombable/moving aerial targets.<br />
<br />
* '''Scenarios:''' Bombing and dogfighting scenarios using these AI aircraft.<br />
<br />
* '''Multiplayer dogfighting:''' Code to allow multiplayer (MP) communication of damage to aircraft, allowing multiplayer dogfighting<br />
<br />
* '''Aircraft enhancements--weapons and dogfighting:''' Three WWI era aircraft enhanced with historically accurate weapons systems and prepared for MP dogfighting (Sopwith Camel, Fokker DR1, SPAD-VII)<br />
<br />
* '''Contrails and smoke:''' MP aircraft capable of dogfighting, and some other MP and AI aircraft automatically have contrails and engine smoke trails. This makes it possible to locate the aircraft when doing MP dogfighting and generally adds to the realism.<br />
<br />
== External links ==<br />
* [http://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772 Download Bombable, Bombable forum thread]<br />
<br />
[[Category:Bombable]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Bombable&diff=107064Bombable2017-02-23T04:18:44Z<p>Flug: /* Versions */</p>
<hr />
<div>{{Infobox subsystem<br />
|image = Bombable4 4 600.png<br />
|name = Bombable Addon<br />
|started = 2009<br />
|description = Addon for FlightGear that adds support for dogfighting, damage, and AI bots.<br />
|status = Under active development (01/2014)<br />
|developers = Flug<br />
|folders = https://github.com/bhugh/Bombable<br />
}}<br />
<br />
[[File:camel-through-wing.jpg|thumb|[[Sopwith Camel]]]]<br />
[[File:spad-vs-camel.jpg|thumb]]<br />
[[File:warthog-down-on-bay-bridge.jpg|thumb|[[A-10 Warthog]]]]<br />
<br />
'''Bombable''' is an addon for [[FlightGear]] that adds bombs, weapons, damage, fire, and explosion effects to FlightGear that work with the main [[aircraft]], [[scenery]], [[AI]] aircraft and other AI objects, and [[multiplayer]] aircraft objects. Bombable turns FlightGear into a combat flight simulator.<br />
<br />
[https://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772#p43772 Download the current version of the Bombable add-on here.]<br />
<br />
== Features ==<br />
* [[Multiplayer]] dogfighting.<br />
* AI scenarios that allow you to use any FlightGear aircraft that can shoot weapons and/or drop bombs for air-to-air, air-to-ground, and anti-maritime combat missions against AI tanks, [[jeep]]s, ships, and aircraft that will fight you.<br />
* Explosion and burning when you crash.<br />
* Damage added to your aircraft when you exceed the [[Howto: Define limits|aircraft's limitations]] (excessive g-force, exceeding V<sub>NE</sub>, etc.).<br />
<br />
== Downloading and using in FlightGear ==<br />
* [http://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772 Download Bombable on the Flightgear Forums thread for Bombable] or [http://brenthugh.com/flightgear/bombable4-5b.zip using this direct link to the .zip file]<br />
* Instructions for installing and using Bombable are included in the Docs directory of the download file.<br />
<br />
== List of Bombable Aircraft ==<br />
[[Sopwith Camel]], SPAD VII, [[Fokker Dr.I]] Triplane, [[A6M2 Zero]], F6F Hellcat, [[Fairchild Republic A-10 Thunderbolt II|A-10 Warthog]], [[UFO]], and other included aircraft such the [[Polikarpov I16]].<br />
<br />
== How to add Bombable to a FlightGear aircraft ==<br />
* [[Howto: Adding Bombable to FlightGear Aircraft]]<br />
<br />
== Related articles ==<br />
* [[Howto: Dogfighting over Multiplayer with Bombable]]<br />
* [[Dicta Boelcke]] rules for dogfighting by the WWI aces<br />
* [[Bombable_Development_Roadmap]]<br />
<br />
== Bombable video ==<br />
{{#ev:youtube|PirnWJHZtcg}}<br />
<br />
== Readme ==<br />
* http://wiki.flightgear.org/Bombable_Readme<br />
<br />
== History ==<br />
FlightGear seems to have most all the pieces under the hood to make an excellent platform for simulating historical military aircraft, dogfighting and fighter plane tactics with aircraft of different eras, and bombing runs and other tactics from various historical eras, and other aircraft simulations that could depend on FlightGear's realistic, underlying flight models.<br />
<br />
Some aircraft have implemented limited weapons, armament, and explosions. The A-10 Warthog was released, including an AI scenario for the A-10 to bomb M-1 tanks, which then exploded realistically.<br />
<br />
The Bombable add-on was designed to put all the available FlightGear elements together as a proof of concept to see if FlightGear can be a realistic simulator for aircraft that include weapons and armament, working with AI aircraft and over Multiplayer, including:<br />
<br />
* Realistic impact detection and damage assessment<br />
* Damage tracking over AI and Multiplayer and communication of impacts and damage levels over Multiplayer<br />
* AI aircraft, vehicles, and ships that can evade, attack, and generally act realistically<br />
* Explosions, fires, and so on, upon damage and crash<br />
<br />
Bombable was developed with the idea that in a realistic flight simulator environment, the rules and techniques of dogfighting and aerial warfare--like the World War I [[Dicta Boelcke]], by Oswald Boelcke, one of the first great aces of the war--would naturally develop and naturally play out.<br />
<br />
== Status ==<br />
As of January 2014 (Bombable 4.5) the status is:<br />
* Damage impact detection is the most advanced element in Bombable. It is greatly improved over FG's native impact detection system, and the framework is in place for further refinements or as a model for FG to implement more refined impact detection internally.<br />
<br />
* Damage tracking and communication over Multiplayer works well in a very lightweight with a very low data rate. However, only a general damage percentage is tracked and communicated. Damage to different locations or systems is not simulated.<br />
<br />
* AI aircraft behavior is controlled by a Nasal script that modifies FlightGear's AI system. This is Bombable's weakest point--in many ways the Nasal script is simply fighting the underlying AI code for control of the AI aircraft. Creating more realistic/intelligent AI fighter aircraft will require greater integration with FlightGear's AI systems. That is a problem for programmers--but for users, the AI aircraft now move, attack, and evade with reasonable realism.<br />
<br />
* AI aircraft weapons systems are simulated through a probabilistic approach. And shown visually via FlightGear's Particle System. At this time it appears that creating and tracking AI weapon projectiles via FlightGear's submodel system, which simulates submodel dynamics and impacts precisely, is technically difficult and would have a drastic negative impact on the FlightGear framerate. Bombable follows the more promising of simulating AI weapon fire using FlightGear's particle system, which allows for visual display of numerous moving particles with little to no effect on the framerate and calculating weapons hits mathematically in a simple way that has minimal impact on framerate.<br />
<br />
* '''AI aircraft move vertically &ndash; and do loops''': AI aircraft now move much more realistically in the vertical direction. They do loops, dive, and all the rest. Their behavior (climb rates, dive rates, and so on) matches those of the corresponding FG aircraft. This makes for a much more realistic 3-D dogfighting experience in FlightGear.<br />
<br />
* Proof of concept for explosions, fires, weapons damage animations, and crash animations is in place. All these elements could be refined for greater realism.<br />
<br />
* '''Realistic roll rates for ai aircraft''': Roll rates are one the most important factors determining the effectiveness of fighter aircraft-- aircraft that can roll faster can turn faster. Now the roll rate for AI aircraft in scenarios can be customized, and bugs in the roll & turn routines for AI aircraft have been fixed.<br />
<br />
* '''Significant performance improvements''': Bombable now makes much less of an impact on your framerate, and much less stuttering & slowdown at key points, like when numerous machine gun rounds are impacting.<br />
<br />
* '''Relocate any scenario to your location''': Have an AI scenario based in San Francisco, but want to fly in London? No problem, just hit a button in the Bombable menu and your scenario comes to you, wherever you are. Damage levels for AI aircraft and objects are re-set. It's like loading a new scenario without having to re-start FlightGear.<br />
<br />
* '''Re-spawn AI aircraft & objects''': After you have shot down (or been shot down by!) AI aircraft or objects in scenarios, you can instantly re-spawn them and try again. (Available in the Bombable menu.)<br />
<br />
The last two are kind of game changers. With FG 2.12's ability to load and unload scenarios instantly and easily, and Bombable's ability to move scenarios to wherever you are, anywhere in the world, scenarios are now flexible and moveable.<br />
<br />
== Versions ==<br />
<br />
[https://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772#p43772 Download the current version of the Bombable add-on here.] Below is information about previous versions and updates. <br />
[[File:Bombable-Camel-vs-Camel.png|300pxthumbnail|right|Camel v. Camel in Bombable]]<br />
<br />
=== Version 4.6 (2/2017), compatible with FG 2016.4.4 and earlier versions ===<br />
Small tweaks for 100% compatibility with FG version 3.0 through 2016.4.4.<br />
<br />
=== Version 4.5b (01/2014, compatible with FG 2.12.1 and earlier versions) ===<br />
Version 4.5b works with FG 2.12.x and has some improvements that take advantage of FG 2.12's new AI scenario handling system.<br />
<br />
In addition, 4.5b has some improved aircraft, tweaks AI aircraft performance and realism, and fixes a few bugs.<br />
<br />
=== Version 4.5 (04/2013, compatible with FG 2.10) ===<br />
Flug just uploaded a new version of Bombable that is compatible with FlightGear 2.10.0--in fact, it should work with all 2.X versions of FlightGear.<br />
<br />
http://brenthugh.com/flightgear/bombable4-5.zip<br />
<br />
Thanks to Voudoun da Vinci for helping track down some of the problems and the fixes.<br />
<br />
Bombable is still pretty new to FG 2.10, so please let me know if you find any problems. Message in this thread is the best way.<br />
<br />
FYI part of the package is a new, greatly improved, historically accurate (to the degree I could make it so!) JSBSim FDM for the Sopwith Camel.<br />
<br />
The idea was to make the Camel fly like a real Camel--not just when flying safely well within the envelope like a commercial pilot, but when taking it to the edge and beyond, as real combat pilots did in WWI.<br />
<br />
Not easy to fly--but a lot of fun to try. It's SopwithCamel-Bombable (JSBSim), included in the Bombable distribution.<br />
<br />
Bombable is now compatible with FG 2.10 (as well as 2.8, 2.6 and earlier versions) and includes a new, far more realistic and true-to-life JSBSim flight model for the Sopwith Camel.<br />
<br />
* The new JSBSim version of Sopwith Camel is far more realistic as a fighter aircraft, implementing nearly every documented flight characteristic of the original Camel. The new JSBSim Camel is very quirky and difficult to fly--just as the original Camel was. See separate file documenting the JSBSim flight model. To try the new Camel flight model, in FGRun select:<br />
<br />
* sopwithCamel-Bombable<br />
* Sopwith Camel 1F.1 (JSBSim, Experimental, Guns/Bombable)<br />
<br />
* Improvements to make Bombable more compatible with FG 2.10 (as well as 2.6 and 2.8):<br />
<br />
* Continue to refined workaround for the FG bug allowing only one particlesystem per XML file. <br />
<br />
* Workarounds for a stricter XML parser that was adopted by FG somewhere between FG 2.4 and 2.10. Several of the aircraft XML files would not parse due to the special or foreign characters included in comments. <br />
<br />
* Updated sound files to mono format (required by FG 2.10 3-D sound system).<br />
<br />
* Minor updates/bugfixes to aircraft, scenarios<br />
<br />
=== Version 4.4 ===<br />
Version 4.4 is a complete revamping of Bombable into more of a complete, cohesive system for Multiplayer and AI dogfighting and bombing. The accuracy of all the basic functions has been improved and made more realistic, and a number of new "Bombable- compatible" aircraft have been included, from WWI fighters to modern-day jet fighters.<br />
<br />
* '''Weapon hit detection greatly improved''': Complete re-vamped system for detecting your weapon hits on AI or Multiplayeraircraft. It is no longer limited by FG's built-in, large "damage cylinder". It now extends the weapon's flight path within that cylinder to determine precisely how close the weapon hit on your target--allowing muchbetter modeling of hits, damage, and results.<br />
<br />
* '''Damage analysis system greatly improved''': In addition, the damage analysis system has been updated to calculate and use the momentum of weapons as the basis for determing damage of weapon hits. This has proven to be far more realistic and gives much better results thanthe previous ad-hoc method.<br />
<br />
* '''Greatly improved damage impact animations''': Previous versions of Bombable relied on FG's built-in impact animations. The result was that FG often showed the damage impact explosion when the projectile had actually made a clean miss of the aircraft. In Bombable 4.4, this problem is solved, with impact explosions being shown exactly where Bombable calculates they happen, and only when Bombable detects an actual hit with damage. So you have much tigher correspondence between what you see and whatdamage is recorded.<br />
<br />
* The impact animations work for all types of small and large caliber guns and bombs. The system uses FG's excellent particle system to draw the gun and bomb impacts with almost not impact on framerate, and far less jerkiness than FG's usual submodel method. As a bonus, the new animations look much, much better as well, and the visual of the impact matches the actual damage of the impact quite well--that is, the visual size of a bomb explosion closely matches the actual damage area of the bomb; small caliber weapons hits show as smallerimpacts that large caliber weapons, etc.<br />
<br />
* '''Your own weapons can damage you''': Drop a bomb on your own aircraft or too near it? You'll see the results--damage to your aircraft. This makes bombing runs far more realistic--if you get too close to the bomb impact, you'll feel the results.<br />
<br />
* '''Impact visuals, smoke, and fire shown on scenery''': If you drop a bomb on a scenery or a building, you see an explosion and a long-lasting fire &ndash; just as you do when you bomb a jeep, tank, or airplane. Previously, the bombs, guns, rockets, and other armament only had an effect on AI and MP aircraft, tanks, ships, and so on. Now armament hits affect almost everything in the FlightGear world.<br />
<br />
* '''Re-spawn AI aircraft''': After you have shot down (or been shot down by!) AI aircraft in scenarios, you can instantly re-spawn them and try again. (Available in the Bombable menu.)<br />
<br />
* '''Bombable Fokker DR.1 fixed''': Fixed/update the Fokker Dr.1 aircraft. It is now the same aircraft as distributed in FG 2.4.0 but with added historically accurate guns and an aircraft help file.<br />
<br />
* '''Bombable Grumman F6F Hellcat added''': Added a new Bombable-compatible aircraft, the Grumman F6F Hellcat. This makes a great foil to the A6M2 Zero, as they fought against each other in WWII. (As always, mucho thanks must go to the authors of the F6F aircraft--all I've done is update the weaponry to be historically accurate and add a thin veneer of tweaks to make the aircraft completely compatible with Bombable. All credit for aircraft design, systems, FDM, and everything else goes to the original authors, in this case EmanuelBaranger and others.)<br />
<br />
* '''New scenarios''': New scenario to show off the F6F, one to show offthe Bombable UFO, and one to help with testing: <br />
** BOMB-LakeTahoeWWIIB17BombersWithF6FCover.xml<br />
** BOMB-MarinCountyUFOInvasion.xml<br />
** BOMB-Kansas-City-Bombable-Testbed.xml <br />
<br />
* '''Bombable A-10 Warthog added''': The A-10 is the best plane to fly several scenarios and including it in the package means that it can be used to fly multiplayer bombable as well. It has several tweaks making it easier to use with the Bombable package and also improves an annoying bug where the A-10 slows FG's framerate massively after a few re-init/re-locates. (Again, all credit to the A-10 original authors--all I have done is adda few Bombable tweaks and specifics.)<br />
<br />
* '''Bombable UFO added''': This is mostly for testing; keys 1-9, 0, q, and w fire different weapons. A working AI version is included--so you can have dueling Bombable UFOs over Multiplayer or try the UFO dogfighting scenario (surprisingly fun!). Also a testbed scenario is included, and using the UFO with the BOMB-Kansas-City-Bombable-Testbed.xml scenario is the easiest way to test most Bombable functions, aircraft, and AI aircraft. (Based on FG's stock UFO, but with Bombable capabilitiesadded.)<br />
<br />
* '''Bomb damage''': Reconfigured damage impact of bombs; the bombs now act--lookand create damage--far closer to real data.<br />
<br />
* '''New menu''': Re-vamped Bombable menu with new/streamlined/more sensible options.<br />
<br />
* '''Reset damage''': In the new Bombable menu you can reset damage for main aircraft and AI aircraft and objects.<br />
<br />
* '''Bombable scenarios renamed''': Renamed all scenarios that come with the package with prefix "BOMB-". This should make it easier to find the scenarios and also update or remove them when necessary.<br />
<br />
* '''Smaller smoke/fire option''': A small fire option, used where appropriate, so that fires/explosions/damage don't always look sooverly huge.<br />
<br />
* '''Unusable aircraft removed''': Removed unused/unusable aircraft from the distribution. Some of these are perfectly fine for general flying, but weapons or other features don't work well with Bombable, and having them listed in the menus when they didn't really work made forconfusion.<br />
<br />
* '''Scenario fixes''': Some scenarios were not loading properly for some people in ver. 4.3. This might be because of inconsistencies in the case of some file and directory names. I worked on resolving thisissue, but please let me know if it is still happening.<br />
<br />
* '''Scenarios renamed''': Renamed all scenarios to start with "BOMB-". This should help us keep straight which scenarios work with Bombable and also troubleshoot and track down & fix problems with scenarios.<br />
<br />
* '''AI weapons improved''': AI weapons now malfunction when the AI aircraft, vehicle, or ship is damaged.<br />
<br />
* '''Misc. updates''': Updated included AI aircraft and scenarios to fit with the new impact detection system.<br />
<br />
* '''For bombable aircraft designers''': If you have designed aircraft to use with Bombable, you should look at the sample AI aircraft provided to see updates to the Bombable dimensions, vulnerabilities, and weapons sections. You will need to re-tool your aircraft slightly, but when finished the results will be much better.<br />
<br />
* '''Bug fixes''': Various small bug fixed and improvements, fixed a lot of the programs with scenarios, AI Aircraft, directories.<br />
<br />
See the To Do file (many of which have now been done) for many more changes, updates, and improvements.<br />
<br />
=== Version 4.3 ===<br />
* Multiplayer dogfighting is now working in FG 2.4.0. (It broke sometime in the FG 2.X.X. series.) Use one of the MP-dogfighting- enabled planes included in the packet (Sopwith Camel-Bombable/Yasim, SPAD VII-Bombable, or FKDR1-Bombable/JSB, or A6M2-Bombable/YASim--use the versions marked as Guns/Bombable, not the default FG installs) and make sure your opponent does the same--you will both be able to shoot and damage each other, see damage reports, etc.<br />
<br />
* Weapons on AI aircraft--which will shoot at you as you attack them--can now be placed in different locations and aimed indifferent directions.<br />
<br />
In combat, they will shoot you if that location/direction is lined up with you. The AI B-17 Bomber included in the package will shoot at you from the rear; the M-1 tank will shoot towards the front at about a 45 degree angle, Jeep will shoot forwards and upwards,Ferries will shoot forward or backwards, etc.<br />
<br />
The result is a far more realistic experience. Shooting bombers used to be like shooting fish in a barrel--now between the bombers shooting at you and the fighter planes coming in from high cover, you're lucky to score a few small hits and get out of therealive . . .<br />
<br />
* The AI Weapons system was generally improved and weapon strength, direction, size, location, and effectiveness can be specified in the XML file for each AI aircraft type. (If you're creating your own Bombable-enable aircraft, just add weapons specs in the WEAPONSsection of AI aircraft; see enclosed AI/Aircraft files for examples.)<br />
<br />
* Generally tweaked AI aircraft, attack & weapons routines, and AI scenarios for a better, more realistic experience. In particular,try:<br />
** MarinCountyWWIIBombersWithCover.xml (fly A6M2-Bombable/YASim)<br />
** MarinCountyCamelInvasion1-Simple.xml (fly Sopwith Camel-Bombable/YASim) <br />
<br />
* Again worked on the problem of getting AI aircraft to climb and dive more realistically instead of sedately. The AI aircraft are farmore realistic/active in the vertical direction now.<br />
<br />
* Bombable no longer overwrites existing aircraft or anything else in FG's installation. It will add new aircraft and a few other Bombable-specific files. All new/added aircraft have the suffix -Bombable. Bombable will overwrite-replace things from its ownprevious installation, but no other files.<br />
<br />
Generally when flying Bombable's AI scenarios or flying over multiplayer with another person using Bombable, your best experience will be to use one of the aircraft provided (and identifiable by the -Bombable extension) or another aircraftspecifically set up to use Bombable's capabilities.<br />
<br />
=== Version 4.2 ===<br />
* Made numerous changes/updates/improvements related to getting Bombable working with FG 2.4.0.<br />
<br />
* Found the FG 2.4.0 "reinit" problem in both M-1 and Jeep in AI/Aircraft & fixed<br />
<br />
* Reconfigured the damage calculations for light weapons in the test_impact function. Result may be that it is harder/takes more hits than before to damage aircraft or objects. If it is too hard you can select both "Easy Mode" and "Super Easy Mode" together to make it quite a bit easier to both hit targets and create damage. This still needs some refinement but it is setting the groundworkfor a better, more consistent way of dealing with damage.<br />
<br />
* Small refinements in display, damage reports, etc.<br />
<br />
* FG 2.4.0 is doing this crazy thing where it reinitializes AI objects in scenario repeatedly and also (sometimes!) slips in non-AI objects like joystick inputs for initialization as AI/scenario objects. This results in massive slowdowns and other bizarre behavior. So I've set up checks to disallow repeated re-inits of AI objects and only allow AI and Multiplayer objects (as opposed joystick input devices, etc) to initialize themselves with Bombable. The ultimate solution here is a FG code fix, but in the meanwhilesome of the worst effects might be mitigated.<br />
<br />
=== Version 4.0 ===<br />
This is a beta release that works with Flightgear 2.4.0. Some AI aircraft characteristics have changed in FG 2.4.0 so there are someproblems and different behavior in the AI aircraft.<br />
<br />
* Removed the "reinit" command in bombable.nas that made FG 2.4.0 croak.<br />
<br />
* Removed the mp_broadcast.nas file that is no longer necessary with FG 2.4.0 (and in fact the old version included with Bombable made FG2.4.0 choke).<br />
<br />
* FG 2.4.0 doesn't make the weight or mass of the armament available on impact (previous versions}}} did!), so a kludgy work-around wascreated.<br />
<br />
* Numerous other tweaks and bug fixes.<br />
<br />
=== Version 3.0p ===<br />
* This is a bit of an alpha release and has not been as thoroughly tested with all scenarios as previous releases.<br />
<br />
* '''AI aircraft are more mobile vertically''': AI Aircraft dodge and chase you more vertically, diving and climbing.<br />
<br />
* '''Various bugfixes'''<br />
<br />
=== Version 3.0o ===<br />
* '''AI aircraft shoot at and damage you''': When in an AI dogfight, if you let the AI aircraft get into position they have a chance to shoot at and possibly damage you. This is working best with WWI AI Aircraft (Camel, SPAD, Fokker) as in the Marin County Camel Invasion scenarios, but it will also work with the Zero and Warthog scenarios.<br />
<br />
* '''Mostly fixed menu/options save/restore bug''': Some of the options still don't save/restore correctly, but most do now.<br />
<br />
* '''Numerous other bugfixes/small improvements'''<br />
<br />
=== Version 3.0n ===<br />
* '''AI aircraft dodge and "attack" realistically''': AI dogfights just became 10X as realistic, as fighter planes will turn and attack, just as fighter planes did in WWI and WWII. Try the Marin County Camel Invasion and Marin County Zero Invasion scenarios for a taste of how this works. (No weapons for AI aircraft yet--maybe in the future.)<br />
<br />
* '''New scenario &ndash; B-17 bombers with fighter cover''': Fly out of Marin Ranch and attack a squadron of 6 B-17 Bombers. As you do so, the fighter squadrons descend and swarm you. They don't fire at you (yet! fodder for future versions!) but they turn aggressively towards you, evade your shots, etc., just as real fighters would.<br />
<br />
* '''Damaged ai aircraft crash more realistically'''<br />
<br />
* '''Greatly improved, more realistic damage analysis''': Damage assessment for guns is a lot more realistic, giving greater damage when you hit closer to the center of the object and allowing for the possibility that even small arms might strike a vital or explosive point, causing catastrophic damage. For instance, you can now damage the Nimitz or Eisenhower*--though it's still tough to sink.<br />
<br />
* '''More realistic fire starting''': One of the chief causes of combat aircraft damage is the fires that even small caliber weapons can cause--and fires are even more likely with heavier ammo that includes incendiary (high explosive) materials. Bombable now models that any hit may start a fire, and heavier rounds are more likely to start files. Fires progressively damage the aircraft and eventually bring it down. Beware that fires sometimes go out before completely disabling the aircraft--so monitor the enemy aircraft to make sure they do not recover and escape.<br />
<br />
* '''More realistic aircraft smoke starting''': Similar to fire starting, each damaging hit has the possibility to cause damage that causes the aircraft to emit a trail of smoke. The bigger/closer the hit, the more likely to cause this damage.<br />
<br />
* '''Bombable preferences/settings saved and restored at startup'''<br />
<br />
* '''Fixed excessive damage report problem''': Aircraft would continually report damage even after objects received 100% damage--now fixed.<br />
<br />
* '''Numerous small bugfixes'''<br />
<br />
* Note: You can bomb the Nimitz/Eisenhower carriers if you have the bombable carriers add-on: http://forum.flightgear.org/viewtopic.php?f=2&t=7082<br />
<br />
=== Version 3.0m ===<br />
* Positive and negative G-force limits are now settable separately (most aircraft have different limits for positive vs negative G, so this adds some realism)<br />
<br />
* Bugfixes on damage & damage report<br />
<br />
* Every hit now registers via on-screen popup (vs previous behavior of only showing damage when it increased past multiples of 5%)<br />
<br />
* Bugfixes on g-force damage that caused extraneous very high g forces to cause random damage<br />
<br />
* Bugfixes in multiplayer communication, fixed problems when MP is disabled or doesn't exist<br />
<br />
* Bugfix on bombable multiplayer unload (runtime error "listenerids") and improvement to unload routines<br />
<br />
* Fixed Easy/Super Easy Mode malfunction (Super Easy Mode never engaged; new default mode is Easy Mode which should give same performance as previous default mode)<br />
<br />
* Tuned damage/vulnerabilities on ferries (San Francisco Ferry Invasion scenario)<br />
<br />
=== Version 3.0L ===<br />
* '''Overspeed detection/damage'''<br />
<br />
* '''G-force and overspeed detection optional''': Switches in the Bombable menu to turn it off; turned off by default except for planes included in Bombable package.<br />
<br />
* '''Vulnerabilities framework for primary aircraft''': Allows max acceleration, max speed parameters to be set individually per aircraft (main aircraft) and then damage from overspeed/overacceleration is accrued when those limits are exceeded.<br />
<br />
* '''Blackout/redout tunable per aircraft''': Allows blackout & redout values to be set per aircraft--for instance to reflect that WWI aircraft had no pressure suits or special high-G training. This will help level the playing field and create uniformity in MP dogfighting with similar aircraft.<br />
<br />
* '''G-force and overspeed limits and damage amounts tuned''': For the four aircraft included in the Bombable package (A6M2 Zero, Sopwith Camel, SPAD VII, Fokker DR1) the g-force damage & overspeed damage parameters have been individually tuned and are fairly realistic.<br />
<br />
* '''Fires only for appropriate damage''': Overspeed & overacceleration (g-force) damage doesn't start a fire, though it will still rack up 100% damage and shut you down.<br />
<br />
* '''Numerous bugfixes'''<br />
<br />
=== Version 3.0k ===<br />
* '''Excessive G-force damages your aircraft:''' Excessive g-force now adds damage to your airframe and can even make you crash. To avoid damaging your aircraft due to excessive g-force, always fly with blackout/redout turned on and avoid pulling g-forces much beyond those that make you blackout or redout.<br />
<br />
* '''Zeros over marin county scenario:''' Marin County Zero Invasion scenario added.<br />
<br />
=== Version 3.0j (private release) ===<br />
* '''Burn/smoke on crash:''' Aircraft now catch fire, burn, and instantly go to 100% damage when they crash. This is broadcast via MP so others will see you burn when you crash.<br />
<br />
* '''A5mw zero for dogfighting:''' A6M2 ready for MP dogfighting included in release.<br />
<br />
* '''A6M2 Zero:''' Added historically accurate guns and cannons (fire with e and E) to A6M2 Zero.<br />
<br />
* '''Bombable A62M Zero:''' Included Bombable version of the AI A6M2 Zero from Hellcat's Carrier Bombable project, but also made a few tweaks/improvements to he AI A6M2 for improved realism. See http://www.4shared.com/file/235605076/6101800f/carrier_bombable.html<br />
<br />
* '''Dogfighting:''' Greatly improved dogfighting/multiplayer communication of damages<br />
<br />
* '''Bugfix DR 1:''' Added keyboard firing switch to Fokker DR 1 (use the 'e' key to fire the weapons).<br />
<br />
* '''Bugfixes:''' Many other miscellaneous bug fixes and improvements.<br />
<br />
=== Version 3.0i ===<br />
* '''Reset resets damage:''' In dogfighting, resetting or using the Location menu to change your location resets your damage to 0% and broadcasts that to others flying with you via multiplayer<br />
<br />
* '''FlightGear 2.0 compatible:''' Tested and works with FG 2.0 as well as FG 1.9 and CVS versions between 1.9 and 2.0<br />
<br />
* '''Bugfixes:''' Various small bugfixes<br />
<br />
=== Versions 3.0 through 3.0h ===<br />
* '''Bombable/shootable:''' Code to make objects, AI aircraft, MP aircraft bombable and shootable.<br />
<br />
* '''Moving AI bombable/shootable objects:''' Code to allow AI aircraft, naval vessels, and surface vehicles to move (sort of) realistically and act as bombable/moving aerial targets.<br />
<br />
* '''Scenarios:''' Bombing and dogfighting scenarios using these AI aircraft.<br />
<br />
* '''Multiplayer dogfighting:''' Code to allow multiplayer (MP) communication of damage to aircraft, allowing multiplayer dogfighting<br />
<br />
* '''Aircraft enhancements--weapons and dogfighting:''' Three WWI era aircraft enhanced with historically accurate weapons systems and prepared for MP dogfighting (Sopwith Camel, Fokker DR1, SPAD-VII)<br />
<br />
* '''Contrails and smoke:''' MP aircraft capable of dogfighting, and some other MP and AI aircraft automatically have contrails and engine smoke trails. This makes it possible to locate the aircraft when doing MP dogfighting and generally adds to the realism.<br />
<br />
== External links ==<br />
* [http://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772 Download Bombable, Bombable forum thread]<br />
<br />
[[Category:Bombable]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Bombable&diff=107063Bombable2017-02-23T04:18:20Z<p>Flug: /* Versions */</p>
<hr />
<div>{{Infobox subsystem<br />
|image = Bombable4 4 600.png<br />
|name = Bombable Addon<br />
|started = 2009<br />
|description = Addon for FlightGear that adds support for dogfighting, damage, and AI bots.<br />
|status = Under active development (01/2014)<br />
|developers = Flug<br />
|folders = https://github.com/bhugh/Bombable<br />
}}<br />
<br />
[[File:camel-through-wing.jpg|thumb|[[Sopwith Camel]]]]<br />
[[File:spad-vs-camel.jpg|thumb]]<br />
[[File:warthog-down-on-bay-bridge.jpg|thumb|[[A-10 Warthog]]]]<br />
<br />
'''Bombable''' is an addon for [[FlightGear]] that adds bombs, weapons, damage, fire, and explosion effects to FlightGear that work with the main [[aircraft]], [[scenery]], [[AI]] aircraft and other AI objects, and [[multiplayer]] aircraft objects. Bombable turns FlightGear into a combat flight simulator.<br />
<br />
[https://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772#p43772 Download the current version of the Bombable add-on here.]<br />
<br />
== Features ==<br />
* [[Multiplayer]] dogfighting.<br />
* AI scenarios that allow you to use any FlightGear aircraft that can shoot weapons and/or drop bombs for air-to-air, air-to-ground, and anti-maritime combat missions against AI tanks, [[jeep]]s, ships, and aircraft that will fight you.<br />
* Explosion and burning when you crash.<br />
* Damage added to your aircraft when you exceed the [[Howto: Define limits|aircraft's limitations]] (excessive g-force, exceeding V<sub>NE</sub>, etc.).<br />
<br />
== Downloading and using in FlightGear ==<br />
* [http://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772 Download Bombable on the Flightgear Forums thread for Bombable] or [http://brenthugh.com/flightgear/bombable4-5b.zip using this direct link to the .zip file]<br />
* Instructions for installing and using Bombable are included in the Docs directory of the download file.<br />
<br />
== List of Bombable Aircraft ==<br />
[[Sopwith Camel]], SPAD VII, [[Fokker Dr.I]] Triplane, [[A6M2 Zero]], F6F Hellcat, [[Fairchild Republic A-10 Thunderbolt II|A-10 Warthog]], [[UFO]], and other included aircraft such the [[Polikarpov I16]].<br />
<br />
== How to add Bombable to a FlightGear aircraft ==<br />
* [[Howto: Adding Bombable to FlightGear Aircraft]]<br />
<br />
== Related articles ==<br />
* [[Howto: Dogfighting over Multiplayer with Bombable]]<br />
* [[Dicta Boelcke]] rules for dogfighting by the WWI aces<br />
* [[Bombable_Development_Roadmap]]<br />
<br />
== Bombable video ==<br />
{{#ev:youtube|PirnWJHZtcg}}<br />
<br />
== Readme ==<br />
* http://wiki.flightgear.org/Bombable_Readme<br />
<br />
== History ==<br />
FlightGear seems to have most all the pieces under the hood to make an excellent platform for simulating historical military aircraft, dogfighting and fighter plane tactics with aircraft of different eras, and bombing runs and other tactics from various historical eras, and other aircraft simulations that could depend on FlightGear's realistic, underlying flight models.<br />
<br />
Some aircraft have implemented limited weapons, armament, and explosions. The A-10 Warthog was released, including an AI scenario for the A-10 to bomb M-1 tanks, which then exploded realistically.<br />
<br />
The Bombable add-on was designed to put all the available FlightGear elements together as a proof of concept to see if FlightGear can be a realistic simulator for aircraft that include weapons and armament, working with AI aircraft and over Multiplayer, including:<br />
<br />
* Realistic impact detection and damage assessment<br />
* Damage tracking over AI and Multiplayer and communication of impacts and damage levels over Multiplayer<br />
* AI aircraft, vehicles, and ships that can evade, attack, and generally act realistically<br />
* Explosions, fires, and so on, upon damage and crash<br />
<br />
Bombable was developed with the idea that in a realistic flight simulator environment, the rules and techniques of dogfighting and aerial warfare--like the World War I [[Dicta Boelcke]], by Oswald Boelcke, one of the first great aces of the war--would naturally develop and naturally play out.<br />
<br />
== Status ==<br />
As of January 2014 (Bombable 4.5) the status is:<br />
* Damage impact detection is the most advanced element in Bombable. It is greatly improved over FG's native impact detection system, and the framework is in place for further refinements or as a model for FG to implement more refined impact detection internally.<br />
<br />
* Damage tracking and communication over Multiplayer works well in a very lightweight with a very low data rate. However, only a general damage percentage is tracked and communicated. Damage to different locations or systems is not simulated.<br />
<br />
* AI aircraft behavior is controlled by a Nasal script that modifies FlightGear's AI system. This is Bombable's weakest point--in many ways the Nasal script is simply fighting the underlying AI code for control of the AI aircraft. Creating more realistic/intelligent AI fighter aircraft will require greater integration with FlightGear's AI systems. That is a problem for programmers--but for users, the AI aircraft now move, attack, and evade with reasonable realism.<br />
<br />
* AI aircraft weapons systems are simulated through a probabilistic approach. And shown visually via FlightGear's Particle System. At this time it appears that creating and tracking AI weapon projectiles via FlightGear's submodel system, which simulates submodel dynamics and impacts precisely, is technically difficult and would have a drastic negative impact on the FlightGear framerate. Bombable follows the more promising of simulating AI weapon fire using FlightGear's particle system, which allows for visual display of numerous moving particles with little to no effect on the framerate and calculating weapons hits mathematically in a simple way that has minimal impact on framerate.<br />
<br />
* '''AI aircraft move vertically &ndash; and do loops''': AI aircraft now move much more realistically in the vertical direction. They do loops, dive, and all the rest. Their behavior (climb rates, dive rates, and so on) matches those of the corresponding FG aircraft. This makes for a much more realistic 3-D dogfighting experience in FlightGear.<br />
<br />
* Proof of concept for explosions, fires, weapons damage animations, and crash animations is in place. All these elements could be refined for greater realism.<br />
<br />
* '''Realistic roll rates for ai aircraft''': Roll rates are one the most important factors determining the effectiveness of fighter aircraft-- aircraft that can roll faster can turn faster. Now the roll rate for AI aircraft in scenarios can be customized, and bugs in the roll & turn routines for AI aircraft have been fixed.<br />
<br />
* '''Significant performance improvements''': Bombable now makes much less of an impact on your framerate, and much less stuttering & slowdown at key points, like when numerous machine gun rounds are impacting.<br />
<br />
* '''Relocate any scenario to your location''': Have an AI scenario based in San Francisco, but want to fly in London? No problem, just hit a button in the Bombable menu and your scenario comes to you, wherever you are. Damage levels for AI aircraft and objects are re-set. It's like loading a new scenario without having to re-start FlightGear.<br />
<br />
* '''Re-spawn AI aircraft & objects''': After you have shot down (or been shot down by!) AI aircraft or objects in scenarios, you can instantly re-spawn them and try again. (Available in the Bombable menu.)<br />
<br />
The last two are kind of game changers. With FG 2.12's ability to load and unload scenarios instantly and easily, and Bombable's ability to move scenarios to wherever you are, anywhere in the world, scenarios are now flexible and moveable.<br />
<br />
== Versions ==<br />
<br />
[https://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772#p43772 Download the current version of the Bombable add-on here.] Below is information about previous versions and updates. <br />
[[File:Bombable-Camel-vs-Camel.png|300px|framed|thumbnail|right|Camel v. Camel in Bombable]]<br />
<br />
=== Version 4.6 (2/2017), compatible with FG 2016.4.4 and earlier versions ===<br />
Small tweaks for 100% compatibility with FG version 3.0 through 2016.4.4.<br />
<br />
=== Version 4.5b (01/2014, compatible with FG 2.12.1 and earlier versions) ===<br />
Version 4.5b works with FG 2.12.x and has some improvements that take advantage of FG 2.12's new AI scenario handling system.<br />
<br />
In addition, 4.5b has some improved aircraft, tweaks AI aircraft performance and realism, and fixes a few bugs.<br />
<br />
=== Version 4.5 (04/2013, compatible with FG 2.10) ===<br />
Flug just uploaded a new version of Bombable that is compatible with FlightGear 2.10.0--in fact, it should work with all 2.X versions of FlightGear.<br />
<br />
http://brenthugh.com/flightgear/bombable4-5.zip<br />
<br />
Thanks to Voudoun da Vinci for helping track down some of the problems and the fixes.<br />
<br />
Bombable is still pretty new to FG 2.10, so please let me know if you find any problems. Message in this thread is the best way.<br />
<br />
FYI part of the package is a new, greatly improved, historically accurate (to the degree I could make it so!) JSBSim FDM for the Sopwith Camel.<br />
<br />
The idea was to make the Camel fly like a real Camel--not just when flying safely well within the envelope like a commercial pilot, but when taking it to the edge and beyond, as real combat pilots did in WWI.<br />
<br />
Not easy to fly--but a lot of fun to try. It's SopwithCamel-Bombable (JSBSim), included in the Bombable distribution.<br />
<br />
Bombable is now compatible with FG 2.10 (as well as 2.8, 2.6 and earlier versions) and includes a new, far more realistic and true-to-life JSBSim flight model for the Sopwith Camel.<br />
<br />
* The new JSBSim version of Sopwith Camel is far more realistic as a fighter aircraft, implementing nearly every documented flight characteristic of the original Camel. The new JSBSim Camel is very quirky and difficult to fly--just as the original Camel was. See separate file documenting the JSBSim flight model. To try the new Camel flight model, in FGRun select:<br />
<br />
* sopwithCamel-Bombable<br />
* Sopwith Camel 1F.1 (JSBSim, Experimental, Guns/Bombable)<br />
<br />
* Improvements to make Bombable more compatible with FG 2.10 (as well as 2.6 and 2.8):<br />
<br />
* Continue to refined workaround for the FG bug allowing only one particlesystem per XML file. <br />
<br />
* Workarounds for a stricter XML parser that was adopted by FG somewhere between FG 2.4 and 2.10. Several of the aircraft XML files would not parse due to the special or foreign characters included in comments. <br />
<br />
* Updated sound files to mono format (required by FG 2.10 3-D sound system).<br />
<br />
* Minor updates/bugfixes to aircraft, scenarios<br />
<br />
=== Version 4.4 ===<br />
Version 4.4 is a complete revamping of Bombable into more of a complete, cohesive system for Multiplayer and AI dogfighting and bombing. The accuracy of all the basic functions has been improved and made more realistic, and a number of new "Bombable- compatible" aircraft have been included, from WWI fighters to modern-day jet fighters.<br />
<br />
* '''Weapon hit detection greatly improved''': Complete re-vamped system for detecting your weapon hits on AI or Multiplayeraircraft. It is no longer limited by FG's built-in, large "damage cylinder". It now extends the weapon's flight path within that cylinder to determine precisely how close the weapon hit on your target--allowing muchbetter modeling of hits, damage, and results.<br />
<br />
* '''Damage analysis system greatly improved''': In addition, the damage analysis system has been updated to calculate and use the momentum of weapons as the basis for determing damage of weapon hits. This has proven to be far more realistic and gives much better results thanthe previous ad-hoc method.<br />
<br />
* '''Greatly improved damage impact animations''': Previous versions of Bombable relied on FG's built-in impact animations. The result was that FG often showed the damage impact explosion when the projectile had actually made a clean miss of the aircraft. In Bombable 4.4, this problem is solved, with impact explosions being shown exactly where Bombable calculates they happen, and only when Bombable detects an actual hit with damage. So you have much tigher correspondence between what you see and whatdamage is recorded.<br />
<br />
* The impact animations work for all types of small and large caliber guns and bombs. The system uses FG's excellent particle system to draw the gun and bomb impacts with almost not impact on framerate, and far less jerkiness than FG's usual submodel method. As a bonus, the new animations look much, much better as well, and the visual of the impact matches the actual damage of the impact quite well--that is, the visual size of a bomb explosion closely matches the actual damage area of the bomb; small caliber weapons hits show as smallerimpacts that large caliber weapons, etc.<br />
<br />
* '''Your own weapons can damage you''': Drop a bomb on your own aircraft or too near it? You'll see the results--damage to your aircraft. This makes bombing runs far more realistic--if you get too close to the bomb impact, you'll feel the results.<br />
<br />
* '''Impact visuals, smoke, and fire shown on scenery''': If you drop a bomb on a scenery or a building, you see an explosion and a long-lasting fire &ndash; just as you do when you bomb a jeep, tank, or airplane. Previously, the bombs, guns, rockets, and other armament only had an effect on AI and MP aircraft, tanks, ships, and so on. Now armament hits affect almost everything in the FlightGear world.<br />
<br />
* '''Re-spawn AI aircraft''': After you have shot down (or been shot down by!) AI aircraft in scenarios, you can instantly re-spawn them and try again. (Available in the Bombable menu.)<br />
<br />
* '''Bombable Fokker DR.1 fixed''': Fixed/update the Fokker Dr.1 aircraft. It is now the same aircraft as distributed in FG 2.4.0 but with added historically accurate guns and an aircraft help file.<br />
<br />
* '''Bombable Grumman F6F Hellcat added''': Added a new Bombable-compatible aircraft, the Grumman F6F Hellcat. This makes a great foil to the A6M2 Zero, as they fought against each other in WWII. (As always, mucho thanks must go to the authors of the F6F aircraft--all I've done is update the weaponry to be historically accurate and add a thin veneer of tweaks to make the aircraft completely compatible with Bombable. All credit for aircraft design, systems, FDM, and everything else goes to the original authors, in this case EmanuelBaranger and others.)<br />
<br />
* '''New scenarios''': New scenario to show off the F6F, one to show offthe Bombable UFO, and one to help with testing: <br />
** BOMB-LakeTahoeWWIIB17BombersWithF6FCover.xml<br />
** BOMB-MarinCountyUFOInvasion.xml<br />
** BOMB-Kansas-City-Bombable-Testbed.xml <br />
<br />
* '''Bombable A-10 Warthog added''': The A-10 is the best plane to fly several scenarios and including it in the package means that it can be used to fly multiplayer bombable as well. It has several tweaks making it easier to use with the Bombable package and also improves an annoying bug where the A-10 slows FG's framerate massively after a few re-init/re-locates. (Again, all credit to the A-10 original authors--all I have done is adda few Bombable tweaks and specifics.)<br />
<br />
* '''Bombable UFO added''': This is mostly for testing; keys 1-9, 0, q, and w fire different weapons. A working AI version is included--so you can have dueling Bombable UFOs over Multiplayer or try the UFO dogfighting scenario (surprisingly fun!). Also a testbed scenario is included, and using the UFO with the BOMB-Kansas-City-Bombable-Testbed.xml scenario is the easiest way to test most Bombable functions, aircraft, and AI aircraft. (Based on FG's stock UFO, but with Bombable capabilitiesadded.)<br />
<br />
* '''Bomb damage''': Reconfigured damage impact of bombs; the bombs now act--lookand create damage--far closer to real data.<br />
<br />
* '''New menu''': Re-vamped Bombable menu with new/streamlined/more sensible options.<br />
<br />
* '''Reset damage''': In the new Bombable menu you can reset damage for main aircraft and AI aircraft and objects.<br />
<br />
* '''Bombable scenarios renamed''': Renamed all scenarios that come with the package with prefix "BOMB-". This should make it easier to find the scenarios and also update or remove them when necessary.<br />
<br />
* '''Smaller smoke/fire option''': A small fire option, used where appropriate, so that fires/explosions/damage don't always look sooverly huge.<br />
<br />
* '''Unusable aircraft removed''': Removed unused/unusable aircraft from the distribution. Some of these are perfectly fine for general flying, but weapons or other features don't work well with Bombable, and having them listed in the menus when they didn't really work made forconfusion.<br />
<br />
* '''Scenario fixes''': Some scenarios were not loading properly for some people in ver. 4.3. This might be because of inconsistencies in the case of some file and directory names. I worked on resolving thisissue, but please let me know if it is still happening.<br />
<br />
* '''Scenarios renamed''': Renamed all scenarios to start with "BOMB-". This should help us keep straight which scenarios work with Bombable and also troubleshoot and track down & fix problems with scenarios.<br />
<br />
* '''AI weapons improved''': AI weapons now malfunction when the AI aircraft, vehicle, or ship is damaged.<br />
<br />
* '''Misc. updates''': Updated included AI aircraft and scenarios to fit with the new impact detection system.<br />
<br />
* '''For bombable aircraft designers''': If you have designed aircraft to use with Bombable, you should look at the sample AI aircraft provided to see updates to the Bombable dimensions, vulnerabilities, and weapons sections. You will need to re-tool your aircraft slightly, but when finished the results will be much better.<br />
<br />
* '''Bug fixes''': Various small bug fixed and improvements, fixed a lot of the programs with scenarios, AI Aircraft, directories.<br />
<br />
See the To Do file (many of which have now been done) for many more changes, updates, and improvements.<br />
<br />
=== Version 4.3 ===<br />
* Multiplayer dogfighting is now working in FG 2.4.0. (It broke sometime in the FG 2.X.X. series.) Use one of the MP-dogfighting- enabled planes included in the packet (Sopwith Camel-Bombable/Yasim, SPAD VII-Bombable, or FKDR1-Bombable/JSB, or A6M2-Bombable/YASim--use the versions marked as Guns/Bombable, not the default FG installs) and make sure your opponent does the same--you will both be able to shoot and damage each other, see damage reports, etc.<br />
<br />
* Weapons on AI aircraft--which will shoot at you as you attack them--can now be placed in different locations and aimed indifferent directions.<br />
<br />
In combat, they will shoot you if that location/direction is lined up with you. The AI B-17 Bomber included in the package will shoot at you from the rear; the M-1 tank will shoot towards the front at about a 45 degree angle, Jeep will shoot forwards and upwards,Ferries will shoot forward or backwards, etc.<br />
<br />
The result is a far more realistic experience. Shooting bombers used to be like shooting fish in a barrel--now between the bombers shooting at you and the fighter planes coming in from high cover, you're lucky to score a few small hits and get out of therealive . . .<br />
<br />
* The AI Weapons system was generally improved and weapon strength, direction, size, location, and effectiveness can be specified in the XML file for each AI aircraft type. (If you're creating your own Bombable-enable aircraft, just add weapons specs in the WEAPONSsection of AI aircraft; see enclosed AI/Aircraft files for examples.)<br />
<br />
* Generally tweaked AI aircraft, attack & weapons routines, and AI scenarios for a better, more realistic experience. In particular,try:<br />
** MarinCountyWWIIBombersWithCover.xml (fly A6M2-Bombable/YASim)<br />
** MarinCountyCamelInvasion1-Simple.xml (fly Sopwith Camel-Bombable/YASim) <br />
<br />
* Again worked on the problem of getting AI aircraft to climb and dive more realistically instead of sedately. The AI aircraft are farmore realistic/active in the vertical direction now.<br />
<br />
* Bombable no longer overwrites existing aircraft or anything else in FG's installation. It will add new aircraft and a few other Bombable-specific files. All new/added aircraft have the suffix -Bombable. Bombable will overwrite-replace things from its ownprevious installation, but no other files.<br />
<br />
Generally when flying Bombable's AI scenarios or flying over multiplayer with another person using Bombable, your best experience will be to use one of the aircraft provided (and identifiable by the -Bombable extension) or another aircraftspecifically set up to use Bombable's capabilities.<br />
<br />
=== Version 4.2 ===<br />
* Made numerous changes/updates/improvements related to getting Bombable working with FG 2.4.0.<br />
<br />
* Found the FG 2.4.0 "reinit" problem in both M-1 and Jeep in AI/Aircraft & fixed<br />
<br />
* Reconfigured the damage calculations for light weapons in the test_impact function. Result may be that it is harder/takes more hits than before to damage aircraft or objects. If it is too hard you can select both "Easy Mode" and "Super Easy Mode" together to make it quite a bit easier to both hit targets and create damage. This still needs some refinement but it is setting the groundworkfor a better, more consistent way of dealing with damage.<br />
<br />
* Small refinements in display, damage reports, etc.<br />
<br />
* FG 2.4.0 is doing this crazy thing where it reinitializes AI objects in scenario repeatedly and also (sometimes!) slips in non-AI objects like joystick inputs for initialization as AI/scenario objects. This results in massive slowdowns and other bizarre behavior. So I've set up checks to disallow repeated re-inits of AI objects and only allow AI and Multiplayer objects (as opposed joystick input devices, etc) to initialize themselves with Bombable. The ultimate solution here is a FG code fix, but in the meanwhilesome of the worst effects might be mitigated.<br />
<br />
=== Version 4.0 ===<br />
This is a beta release that works with Flightgear 2.4.0. Some AI aircraft characteristics have changed in FG 2.4.0 so there are someproblems and different behavior in the AI aircraft.<br />
<br />
* Removed the "reinit" command in bombable.nas that made FG 2.4.0 croak.<br />
<br />
* Removed the mp_broadcast.nas file that is no longer necessary with FG 2.4.0 (and in fact the old version included with Bombable made FG2.4.0 choke).<br />
<br />
* FG 2.4.0 doesn't make the weight or mass of the armament available on impact (previous versions}}} did!), so a kludgy work-around wascreated.<br />
<br />
* Numerous other tweaks and bug fixes.<br />
<br />
=== Version 3.0p ===<br />
* This is a bit of an alpha release and has not been as thoroughly tested with all scenarios as previous releases.<br />
<br />
* '''AI aircraft are more mobile vertically''': AI Aircraft dodge and chase you more vertically, diving and climbing.<br />
<br />
* '''Various bugfixes'''<br />
<br />
=== Version 3.0o ===<br />
* '''AI aircraft shoot at and damage you''': When in an AI dogfight, if you let the AI aircraft get into position they have a chance to shoot at and possibly damage you. This is working best with WWI AI Aircraft (Camel, SPAD, Fokker) as in the Marin County Camel Invasion scenarios, but it will also work with the Zero and Warthog scenarios.<br />
<br />
* '''Mostly fixed menu/options save/restore bug''': Some of the options still don't save/restore correctly, but most do now.<br />
<br />
* '''Numerous other bugfixes/small improvements'''<br />
<br />
=== Version 3.0n ===<br />
* '''AI aircraft dodge and "attack" realistically''': AI dogfights just became 10X as realistic, as fighter planes will turn and attack, just as fighter planes did in WWI and WWII. Try the Marin County Camel Invasion and Marin County Zero Invasion scenarios for a taste of how this works. (No weapons for AI aircraft yet--maybe in the future.)<br />
<br />
* '''New scenario &ndash; B-17 bombers with fighter cover''': Fly out of Marin Ranch and attack a squadron of 6 B-17 Bombers. As you do so, the fighter squadrons descend and swarm you. They don't fire at you (yet! fodder for future versions!) but they turn aggressively towards you, evade your shots, etc., just as real fighters would.<br />
<br />
* '''Damaged ai aircraft crash more realistically'''<br />
<br />
* '''Greatly improved, more realistic damage analysis''': Damage assessment for guns is a lot more realistic, giving greater damage when you hit closer to the center of the object and allowing for the possibility that even small arms might strike a vital or explosive point, causing catastrophic damage. For instance, you can now damage the Nimitz or Eisenhower*--though it's still tough to sink.<br />
<br />
* '''More realistic fire starting''': One of the chief causes of combat aircraft damage is the fires that even small caliber weapons can cause--and fires are even more likely with heavier ammo that includes incendiary (high explosive) materials. Bombable now models that any hit may start a fire, and heavier rounds are more likely to start files. Fires progressively damage the aircraft and eventually bring it down. Beware that fires sometimes go out before completely disabling the aircraft--so monitor the enemy aircraft to make sure they do not recover and escape.<br />
<br />
* '''More realistic aircraft smoke starting''': Similar to fire starting, each damaging hit has the possibility to cause damage that causes the aircraft to emit a trail of smoke. The bigger/closer the hit, the more likely to cause this damage.<br />
<br />
* '''Bombable preferences/settings saved and restored at startup'''<br />
<br />
* '''Fixed excessive damage report problem''': Aircraft would continually report damage even after objects received 100% damage--now fixed.<br />
<br />
* '''Numerous small bugfixes'''<br />
<br />
* Note: You can bomb the Nimitz/Eisenhower carriers if you have the bombable carriers add-on: http://forum.flightgear.org/viewtopic.php?f=2&t=7082<br />
<br />
=== Version 3.0m ===<br />
* Positive and negative G-force limits are now settable separately (most aircraft have different limits for positive vs negative G, so this adds some realism)<br />
<br />
* Bugfixes on damage & damage report<br />
<br />
* Every hit now registers via on-screen popup (vs previous behavior of only showing damage when it increased past multiples of 5%)<br />
<br />
* Bugfixes on g-force damage that caused extraneous very high g forces to cause random damage<br />
<br />
* Bugfixes in multiplayer communication, fixed problems when MP is disabled or doesn't exist<br />
<br />
* Bugfix on bombable multiplayer unload (runtime error "listenerids") and improvement to unload routines<br />
<br />
* Fixed Easy/Super Easy Mode malfunction (Super Easy Mode never engaged; new default mode is Easy Mode which should give same performance as previous default mode)<br />
<br />
* Tuned damage/vulnerabilities on ferries (San Francisco Ferry Invasion scenario)<br />
<br />
=== Version 3.0L ===<br />
* '''Overspeed detection/damage'''<br />
<br />
* '''G-force and overspeed detection optional''': Switches in the Bombable menu to turn it off; turned off by default except for planes included in Bombable package.<br />
<br />
* '''Vulnerabilities framework for primary aircraft''': Allows max acceleration, max speed parameters to be set individually per aircraft (main aircraft) and then damage from overspeed/overacceleration is accrued when those limits are exceeded.<br />
<br />
* '''Blackout/redout tunable per aircraft''': Allows blackout & redout values to be set per aircraft--for instance to reflect that WWI aircraft had no pressure suits or special high-G training. This will help level the playing field and create uniformity in MP dogfighting with similar aircraft.<br />
<br />
* '''G-force and overspeed limits and damage amounts tuned''': For the four aircraft included in the Bombable package (A6M2 Zero, Sopwith Camel, SPAD VII, Fokker DR1) the g-force damage & overspeed damage parameters have been individually tuned and are fairly realistic.<br />
<br />
* '''Fires only for appropriate damage''': Overspeed & overacceleration (g-force) damage doesn't start a fire, though it will still rack up 100% damage and shut you down.<br />
<br />
* '''Numerous bugfixes'''<br />
<br />
=== Version 3.0k ===<br />
* '''Excessive G-force damages your aircraft:''' Excessive g-force now adds damage to your airframe and can even make you crash. To avoid damaging your aircraft due to excessive g-force, always fly with blackout/redout turned on and avoid pulling g-forces much beyond those that make you blackout or redout.<br />
<br />
* '''Zeros over marin county scenario:''' Marin County Zero Invasion scenario added.<br />
<br />
=== Version 3.0j (private release) ===<br />
* '''Burn/smoke on crash:''' Aircraft now catch fire, burn, and instantly go to 100% damage when they crash. This is broadcast via MP so others will see you burn when you crash.<br />
<br />
* '''A5mw zero for dogfighting:''' A6M2 ready for MP dogfighting included in release.<br />
<br />
* '''A6M2 Zero:''' Added historically accurate guns and cannons (fire with e and E) to A6M2 Zero.<br />
<br />
* '''Bombable A62M Zero:''' Included Bombable version of the AI A6M2 Zero from Hellcat's Carrier Bombable project, but also made a few tweaks/improvements to he AI A6M2 for improved realism. See http://www.4shared.com/file/235605076/6101800f/carrier_bombable.html<br />
<br />
* '''Dogfighting:''' Greatly improved dogfighting/multiplayer communication of damages<br />
<br />
* '''Bugfix DR 1:''' Added keyboard firing switch to Fokker DR 1 (use the 'e' key to fire the weapons).<br />
<br />
* '''Bugfixes:''' Many other miscellaneous bug fixes and improvements.<br />
<br />
=== Version 3.0i ===<br />
* '''Reset resets damage:''' In dogfighting, resetting or using the Location menu to change your location resets your damage to 0% and broadcasts that to others flying with you via multiplayer<br />
<br />
* '''FlightGear 2.0 compatible:''' Tested and works with FG 2.0 as well as FG 1.9 and CVS versions between 1.9 and 2.0<br />
<br />
* '''Bugfixes:''' Various small bugfixes<br />
<br />
=== Versions 3.0 through 3.0h ===<br />
* '''Bombable/shootable:''' Code to make objects, AI aircraft, MP aircraft bombable and shootable.<br />
<br />
* '''Moving AI bombable/shootable objects:''' Code to allow AI aircraft, naval vessels, and surface vehicles to move (sort of) realistically and act as bombable/moving aerial targets.<br />
<br />
* '''Scenarios:''' Bombing and dogfighting scenarios using these AI aircraft.<br />
<br />
* '''Multiplayer dogfighting:''' Code to allow multiplayer (MP) communication of damage to aircraft, allowing multiplayer dogfighting<br />
<br />
* '''Aircraft enhancements--weapons and dogfighting:''' Three WWI era aircraft enhanced with historically accurate weapons systems and prepared for MP dogfighting (Sopwith Camel, Fokker DR1, SPAD-VII)<br />
<br />
* '''Contrails and smoke:''' MP aircraft capable of dogfighting, and some other MP and AI aircraft automatically have contrails and engine smoke trails. This makes it possible to locate the aircraft when doing MP dogfighting and generally adds to the realism.<br />
<br />
== External links ==<br />
* [http://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772 Download Bombable, Bombable forum thread]<br />
<br />
[[Category:Bombable]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=Bombable&diff=107062Bombable2017-02-23T04:17:37Z<p>Flug: /* Versions */</p>
<hr />
<div>{{Infobox subsystem<br />
|image = Bombable4 4 600.png<br />
|name = Bombable Addon<br />
|started = 2009<br />
|description = Addon for FlightGear that adds support for dogfighting, damage, and AI bots.<br />
|status = Under active development (01/2014)<br />
|developers = Flug<br />
|folders = https://github.com/bhugh/Bombable<br />
}}<br />
<br />
[[File:camel-through-wing.jpg|thumb|[[Sopwith Camel]]]]<br />
[[File:spad-vs-camel.jpg|thumb]]<br />
[[File:warthog-down-on-bay-bridge.jpg|thumb|[[A-10 Warthog]]]]<br />
<br />
'''Bombable''' is an addon for [[FlightGear]] that adds bombs, weapons, damage, fire, and explosion effects to FlightGear that work with the main [[aircraft]], [[scenery]], [[AI]] aircraft and other AI objects, and [[multiplayer]] aircraft objects. Bombable turns FlightGear into a combat flight simulator.<br />
<br />
[https://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772#p43772 Download the current version of the Bombable add-on here.]<br />
<br />
== Features ==<br />
* [[Multiplayer]] dogfighting.<br />
* AI scenarios that allow you to use any FlightGear aircraft that can shoot weapons and/or drop bombs for air-to-air, air-to-ground, and anti-maritime combat missions against AI tanks, [[jeep]]s, ships, and aircraft that will fight you.<br />
* Explosion and burning when you crash.<br />
* Damage added to your aircraft when you exceed the [[Howto: Define limits|aircraft's limitations]] (excessive g-force, exceeding V<sub>NE</sub>, etc.).<br />
<br />
== Downloading and using in FlightGear ==<br />
* [http://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772 Download Bombable on the Flightgear Forums thread for Bombable] or [http://brenthugh.com/flightgear/bombable4-5b.zip using this direct link to the .zip file]<br />
* Instructions for installing and using Bombable are included in the Docs directory of the download file.<br />
<br />
== List of Bombable Aircraft ==<br />
[[Sopwith Camel]], SPAD VII, [[Fokker Dr.I]] Triplane, [[A6M2 Zero]], F6F Hellcat, [[Fairchild Republic A-10 Thunderbolt II|A-10 Warthog]], [[UFO]], and other included aircraft such the [[Polikarpov I16]].<br />
<br />
== How to add Bombable to a FlightGear aircraft ==<br />
* [[Howto: Adding Bombable to FlightGear Aircraft]]<br />
<br />
== Related articles ==<br />
* [[Howto: Dogfighting over Multiplayer with Bombable]]<br />
* [[Dicta Boelcke]] rules for dogfighting by the WWI aces<br />
* [[Bombable_Development_Roadmap]]<br />
<br />
== Bombable video ==<br />
{{#ev:youtube|PirnWJHZtcg}}<br />
<br />
== Readme ==<br />
* http://wiki.flightgear.org/Bombable_Readme<br />
<br />
== History ==<br />
FlightGear seems to have most all the pieces under the hood to make an excellent platform for simulating historical military aircraft, dogfighting and fighter plane tactics with aircraft of different eras, and bombing runs and other tactics from various historical eras, and other aircraft simulations that could depend on FlightGear's realistic, underlying flight models.<br />
<br />
Some aircraft have implemented limited weapons, armament, and explosions. The A-10 Warthog was released, including an AI scenario for the A-10 to bomb M-1 tanks, which then exploded realistically.<br />
<br />
The Bombable add-on was designed to put all the available FlightGear elements together as a proof of concept to see if FlightGear can be a realistic simulator for aircraft that include weapons and armament, working with AI aircraft and over Multiplayer, including:<br />
<br />
* Realistic impact detection and damage assessment<br />
* Damage tracking over AI and Multiplayer and communication of impacts and damage levels over Multiplayer<br />
* AI aircraft, vehicles, and ships that can evade, attack, and generally act realistically<br />
* Explosions, fires, and so on, upon damage and crash<br />
<br />
Bombable was developed with the idea that in a realistic flight simulator environment, the rules and techniques of dogfighting and aerial warfare--like the World War I [[Dicta Boelcke]], by Oswald Boelcke, one of the first great aces of the war--would naturally develop and naturally play out.<br />
<br />
== Status ==<br />
As of January 2014 (Bombable 4.5) the status is:<br />
* Damage impact detection is the most advanced element in Bombable. It is greatly improved over FG's native impact detection system, and the framework is in place for further refinements or as a model for FG to implement more refined impact detection internally.<br />
<br />
* Damage tracking and communication over Multiplayer works well in a very lightweight with a very low data rate. However, only a general damage percentage is tracked and communicated. Damage to different locations or systems is not simulated.<br />
<br />
* AI aircraft behavior is controlled by a Nasal script that modifies FlightGear's AI system. This is Bombable's weakest point--in many ways the Nasal script is simply fighting the underlying AI code for control of the AI aircraft. Creating more realistic/intelligent AI fighter aircraft will require greater integration with FlightGear's AI systems. That is a problem for programmers--but for users, the AI aircraft now move, attack, and evade with reasonable realism.<br />
<br />
* AI aircraft weapons systems are simulated through a probabilistic approach. And shown visually via FlightGear's Particle System. At this time it appears that creating and tracking AI weapon projectiles via FlightGear's submodel system, which simulates submodel dynamics and impacts precisely, is technically difficult and would have a drastic negative impact on the FlightGear framerate. Bombable follows the more promising of simulating AI weapon fire using FlightGear's particle system, which allows for visual display of numerous moving particles with little to no effect on the framerate and calculating weapons hits mathematically in a simple way that has minimal impact on framerate.<br />
<br />
* '''AI aircraft move vertically &ndash; and do loops''': AI aircraft now move much more realistically in the vertical direction. They do loops, dive, and all the rest. Their behavior (climb rates, dive rates, and so on) matches those of the corresponding FG aircraft. This makes for a much more realistic 3-D dogfighting experience in FlightGear.<br />
<br />
* Proof of concept for explosions, fires, weapons damage animations, and crash animations is in place. All these elements could be refined for greater realism.<br />
<br />
* '''Realistic roll rates for ai aircraft''': Roll rates are one the most important factors determining the effectiveness of fighter aircraft-- aircraft that can roll faster can turn faster. Now the roll rate for AI aircraft in scenarios can be customized, and bugs in the roll & turn routines for AI aircraft have been fixed.<br />
<br />
* '''Significant performance improvements''': Bombable now makes much less of an impact on your framerate, and much less stuttering & slowdown at key points, like when numerous machine gun rounds are impacting.<br />
<br />
* '''Relocate any scenario to your location''': Have an AI scenario based in San Francisco, but want to fly in London? No problem, just hit a button in the Bombable menu and your scenario comes to you, wherever you are. Damage levels for AI aircraft and objects are re-set. It's like loading a new scenario without having to re-start FlightGear.<br />
<br />
* '''Re-spawn AI aircraft & objects''': After you have shot down (or been shot down by!) AI aircraft or objects in scenarios, you can instantly re-spawn them and try again. (Available in the Bombable menu.)<br />
<br />
The last two are kind of game changers. With FG 2.12's ability to load and unload scenarios instantly and easily, and Bombable's ability to move scenarios to wherever you are, anywhere in the world, scenarios are now flexible and moveable.<br />
<br />
== Versions ==<br />
<br />
[https://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772#p43772 Download the current version of the Bombable add-on here.] Below is information about previous versions and updates. <br />
[[File:Bombable-Camel-vs-Camel.png|framed|right|Camel v. Camel in Bombable]]<br />
<br />
=== Version 4.6 (2/2017), compatible with FG 2016.4.4 and earlier versions ===<br />
Small tweaks for 100% compatibility with FG version 3.0 through 2016.4.4.<br />
<br />
=== Version 4.5b (01/2014, compatible with FG 2.12.1 and earlier versions) ===<br />
Version 4.5b works with FG 2.12.x and has some improvements that take advantage of FG 2.12's new AI scenario handling system.<br />
<br />
In addition, 4.5b has some improved aircraft, tweaks AI aircraft performance and realism, and fixes a few bugs.<br />
<br />
=== Version 4.5 (04/2013, compatible with FG 2.10) ===<br />
Flug just uploaded a new version of Bombable that is compatible with FlightGear 2.10.0--in fact, it should work with all 2.X versions of FlightGear.<br />
<br />
http://brenthugh.com/flightgear/bombable4-5.zip<br />
<br />
Thanks to Voudoun da Vinci for helping track down some of the problems and the fixes.<br />
<br />
Bombable is still pretty new to FG 2.10, so please let me know if you find any problems. Message in this thread is the best way.<br />
<br />
FYI part of the package is a new, greatly improved, historically accurate (to the degree I could make it so!) JSBSim FDM for the Sopwith Camel.<br />
<br />
The idea was to make the Camel fly like a real Camel--not just when flying safely well within the envelope like a commercial pilot, but when taking it to the edge and beyond, as real combat pilots did in WWI.<br />
<br />
Not easy to fly--but a lot of fun to try. It's SopwithCamel-Bombable (JSBSim), included in the Bombable distribution.<br />
<br />
Bombable is now compatible with FG 2.10 (as well as 2.8, 2.6 and earlier versions) and includes a new, far more realistic and true-to-life JSBSim flight model for the Sopwith Camel.<br />
<br />
* The new JSBSim version of Sopwith Camel is far more realistic as a fighter aircraft, implementing nearly every documented flight characteristic of the original Camel. The new JSBSim Camel is very quirky and difficult to fly--just as the original Camel was. See separate file documenting the JSBSim flight model. To try the new Camel flight model, in FGRun select:<br />
<br />
* sopwithCamel-Bombable<br />
* Sopwith Camel 1F.1 (JSBSim, Experimental, Guns/Bombable)<br />
<br />
* Improvements to make Bombable more compatible with FG 2.10 (as well as 2.6 and 2.8):<br />
<br />
* Continue to refined workaround for the FG bug allowing only one particlesystem per XML file. <br />
<br />
* Workarounds for a stricter XML parser that was adopted by FG somewhere between FG 2.4 and 2.10. Several of the aircraft XML files would not parse due to the special or foreign characters included in comments. <br />
<br />
* Updated sound files to mono format (required by FG 2.10 3-D sound system).<br />
<br />
* Minor updates/bugfixes to aircraft, scenarios<br />
<br />
=== Version 4.4 ===<br />
Version 4.4 is a complete revamping of Bombable into more of a complete, cohesive system for Multiplayer and AI dogfighting and bombing. The accuracy of all the basic functions has been improved and made more realistic, and a number of new "Bombable- compatible" aircraft have been included, from WWI fighters to modern-day jet fighters.<br />
<br />
* '''Weapon hit detection greatly improved''': Complete re-vamped system for detecting your weapon hits on AI or Multiplayeraircraft. It is no longer limited by FG's built-in, large "damage cylinder". It now extends the weapon's flight path within that cylinder to determine precisely how close the weapon hit on your target--allowing muchbetter modeling of hits, damage, and results.<br />
<br />
* '''Damage analysis system greatly improved''': In addition, the damage analysis system has been updated to calculate and use the momentum of weapons as the basis for determing damage of weapon hits. This has proven to be far more realistic and gives much better results thanthe previous ad-hoc method.<br />
<br />
* '''Greatly improved damage impact animations''': Previous versions of Bombable relied on FG's built-in impact animations. The result was that FG often showed the damage impact explosion when the projectile had actually made a clean miss of the aircraft. In Bombable 4.4, this problem is solved, with impact explosions being shown exactly where Bombable calculates they happen, and only when Bombable detects an actual hit with damage. So you have much tigher correspondence between what you see and whatdamage is recorded.<br />
<br />
* The impact animations work for all types of small and large caliber guns and bombs. The system uses FG's excellent particle system to draw the gun and bomb impacts with almost not impact on framerate, and far less jerkiness than FG's usual submodel method. As a bonus, the new animations look much, much better as well, and the visual of the impact matches the actual damage of the impact quite well--that is, the visual size of a bomb explosion closely matches the actual damage area of the bomb; small caliber weapons hits show as smallerimpacts that large caliber weapons, etc.<br />
<br />
* '''Your own weapons can damage you''': Drop a bomb on your own aircraft or too near it? You'll see the results--damage to your aircraft. This makes bombing runs far more realistic--if you get too close to the bomb impact, you'll feel the results.<br />
<br />
* '''Impact visuals, smoke, and fire shown on scenery''': If you drop a bomb on a scenery or a building, you see an explosion and a long-lasting fire &ndash; just as you do when you bomb a jeep, tank, or airplane. Previously, the bombs, guns, rockets, and other armament only had an effect on AI and MP aircraft, tanks, ships, and so on. Now armament hits affect almost everything in the FlightGear world.<br />
<br />
* '''Re-spawn AI aircraft''': After you have shot down (or been shot down by!) AI aircraft in scenarios, you can instantly re-spawn them and try again. (Available in the Bombable menu.)<br />
<br />
* '''Bombable Fokker DR.1 fixed''': Fixed/update the Fokker Dr.1 aircraft. It is now the same aircraft as distributed in FG 2.4.0 but with added historically accurate guns and an aircraft help file.<br />
<br />
* '''Bombable Grumman F6F Hellcat added''': Added a new Bombable-compatible aircraft, the Grumman F6F Hellcat. This makes a great foil to the A6M2 Zero, as they fought against each other in WWII. (As always, mucho thanks must go to the authors of the F6F aircraft--all I've done is update the weaponry to be historically accurate and add a thin veneer of tweaks to make the aircraft completely compatible with Bombable. All credit for aircraft design, systems, FDM, and everything else goes to the original authors, in this case EmanuelBaranger and others.)<br />
<br />
* '''New scenarios''': New scenario to show off the F6F, one to show offthe Bombable UFO, and one to help with testing: <br />
** BOMB-LakeTahoeWWIIB17BombersWithF6FCover.xml<br />
** BOMB-MarinCountyUFOInvasion.xml<br />
** BOMB-Kansas-City-Bombable-Testbed.xml <br />
<br />
* '''Bombable A-10 Warthog added''': The A-10 is the best plane to fly several scenarios and including it in the package means that it can be used to fly multiplayer bombable as well. It has several tweaks making it easier to use with the Bombable package and also improves an annoying bug where the A-10 slows FG's framerate massively after a few re-init/re-locates. (Again, all credit to the A-10 original authors--all I have done is adda few Bombable tweaks and specifics.)<br />
<br />
* '''Bombable UFO added''': This is mostly for testing; keys 1-9, 0, q, and w fire different weapons. A working AI version is included--so you can have dueling Bombable UFOs over Multiplayer or try the UFO dogfighting scenario (surprisingly fun!). Also a testbed scenario is included, and using the UFO with the BOMB-Kansas-City-Bombable-Testbed.xml scenario is the easiest way to test most Bombable functions, aircraft, and AI aircraft. (Based on FG's stock UFO, but with Bombable capabilitiesadded.)<br />
<br />
* '''Bomb damage''': Reconfigured damage impact of bombs; the bombs now act--lookand create damage--far closer to real data.<br />
<br />
* '''New menu''': Re-vamped Bombable menu with new/streamlined/more sensible options.<br />
<br />
* '''Reset damage''': In the new Bombable menu you can reset damage for main aircraft and AI aircraft and objects.<br />
<br />
* '''Bombable scenarios renamed''': Renamed all scenarios that come with the package with prefix "BOMB-". This should make it easier to find the scenarios and also update or remove them when necessary.<br />
<br />
* '''Smaller smoke/fire option''': A small fire option, used where appropriate, so that fires/explosions/damage don't always look sooverly huge.<br />
<br />
* '''Unusable aircraft removed''': Removed unused/unusable aircraft from the distribution. Some of these are perfectly fine for general flying, but weapons or other features don't work well with Bombable, and having them listed in the menus when they didn't really work made forconfusion.<br />
<br />
* '''Scenario fixes''': Some scenarios were not loading properly for some people in ver. 4.3. This might be because of inconsistencies in the case of some file and directory names. I worked on resolving thisissue, but please let me know if it is still happening.<br />
<br />
* '''Scenarios renamed''': Renamed all scenarios to start with "BOMB-". This should help us keep straight which scenarios work with Bombable and also troubleshoot and track down & fix problems with scenarios.<br />
<br />
* '''AI weapons improved''': AI weapons now malfunction when the AI aircraft, vehicle, or ship is damaged.<br />
<br />
* '''Misc. updates''': Updated included AI aircraft and scenarios to fit with the new impact detection system.<br />
<br />
* '''For bombable aircraft designers''': If you have designed aircraft to use with Bombable, you should look at the sample AI aircraft provided to see updates to the Bombable dimensions, vulnerabilities, and weapons sections. You will need to re-tool your aircraft slightly, but when finished the results will be much better.<br />
<br />
* '''Bug fixes''': Various small bug fixed and improvements, fixed a lot of the programs with scenarios, AI Aircraft, directories.<br />
<br />
See the To Do file (many of which have now been done) for many more changes, updates, and improvements.<br />
<br />
=== Version 4.3 ===<br />
* Multiplayer dogfighting is now working in FG 2.4.0. (It broke sometime in the FG 2.X.X. series.) Use one of the MP-dogfighting- enabled planes included in the packet (Sopwith Camel-Bombable/Yasim, SPAD VII-Bombable, or FKDR1-Bombable/JSB, or A6M2-Bombable/YASim--use the versions marked as Guns/Bombable, not the default FG installs) and make sure your opponent does the same--you will both be able to shoot and damage each other, see damage reports, etc.<br />
<br />
* Weapons on AI aircraft--which will shoot at you as you attack them--can now be placed in different locations and aimed indifferent directions.<br />
<br />
In combat, they will shoot you if that location/direction is lined up with you. The AI B-17 Bomber included in the package will shoot at you from the rear; the M-1 tank will shoot towards the front at about a 45 degree angle, Jeep will shoot forwards and upwards,Ferries will shoot forward or backwards, etc.<br />
<br />
The result is a far more realistic experience. Shooting bombers used to be like shooting fish in a barrel--now between the bombers shooting at you and the fighter planes coming in from high cover, you're lucky to score a few small hits and get out of therealive . . .<br />
<br />
* The AI Weapons system was generally improved and weapon strength, direction, size, location, and effectiveness can be specified in the XML file for each AI aircraft type. (If you're creating your own Bombable-enable aircraft, just add weapons specs in the WEAPONSsection of AI aircraft; see enclosed AI/Aircraft files for examples.)<br />
<br />
* Generally tweaked AI aircraft, attack & weapons routines, and AI scenarios for a better, more realistic experience. In particular,try:<br />
** MarinCountyWWIIBombersWithCover.xml (fly A6M2-Bombable/YASim)<br />
** MarinCountyCamelInvasion1-Simple.xml (fly Sopwith Camel-Bombable/YASim) <br />
<br />
* Again worked on the problem of getting AI aircraft to climb and dive more realistically instead of sedately. The AI aircraft are farmore realistic/active in the vertical direction now.<br />
<br />
* Bombable no longer overwrites existing aircraft or anything else in FG's installation. It will add new aircraft and a few other Bombable-specific files. All new/added aircraft have the suffix -Bombable. Bombable will overwrite-replace things from its ownprevious installation, but no other files.<br />
<br />
Generally when flying Bombable's AI scenarios or flying over multiplayer with another person using Bombable, your best experience will be to use one of the aircraft provided (and identifiable by the -Bombable extension) or another aircraftspecifically set up to use Bombable's capabilities.<br />
<br />
=== Version 4.2 ===<br />
* Made numerous changes/updates/improvements related to getting Bombable working with FG 2.4.0.<br />
<br />
* Found the FG 2.4.0 "reinit" problem in both M-1 and Jeep in AI/Aircraft & fixed<br />
<br />
* Reconfigured the damage calculations for light weapons in the test_impact function. Result may be that it is harder/takes more hits than before to damage aircraft or objects. If it is too hard you can select both "Easy Mode" and "Super Easy Mode" together to make it quite a bit easier to both hit targets and create damage. This still needs some refinement but it is setting the groundworkfor a better, more consistent way of dealing with damage.<br />
<br />
* Small refinements in display, damage reports, etc.<br />
<br />
* FG 2.4.0 is doing this crazy thing where it reinitializes AI objects in scenario repeatedly and also (sometimes!) slips in non-AI objects like joystick inputs for initialization as AI/scenario objects. This results in massive slowdowns and other bizarre behavior. So I've set up checks to disallow repeated re-inits of AI objects and only allow AI and Multiplayer objects (as opposed joystick input devices, etc) to initialize themselves with Bombable. The ultimate solution here is a FG code fix, but in the meanwhilesome of the worst effects might be mitigated.<br />
<br />
=== Version 4.0 ===<br />
This is a beta release that works with Flightgear 2.4.0. Some AI aircraft characteristics have changed in FG 2.4.0 so there are someproblems and different behavior in the AI aircraft.<br />
<br />
* Removed the "reinit" command in bombable.nas that made FG 2.4.0 croak.<br />
<br />
* Removed the mp_broadcast.nas file that is no longer necessary with FG 2.4.0 (and in fact the old version included with Bombable made FG2.4.0 choke).<br />
<br />
* FG 2.4.0 doesn't make the weight or mass of the armament available on impact (previous versions}}} did!), so a kludgy work-around wascreated.<br />
<br />
* Numerous other tweaks and bug fixes.<br />
<br />
=== Version 3.0p ===<br />
* This is a bit of an alpha release and has not been as thoroughly tested with all scenarios as previous releases.<br />
<br />
* '''AI aircraft are more mobile vertically''': AI Aircraft dodge and chase you more vertically, diving and climbing.<br />
<br />
* '''Various bugfixes'''<br />
<br />
=== Version 3.0o ===<br />
* '''AI aircraft shoot at and damage you''': When in an AI dogfight, if you let the AI aircraft get into position they have a chance to shoot at and possibly damage you. This is working best with WWI AI Aircraft (Camel, SPAD, Fokker) as in the Marin County Camel Invasion scenarios, but it will also work with the Zero and Warthog scenarios.<br />
<br />
* '''Mostly fixed menu/options save/restore bug''': Some of the options still don't save/restore correctly, but most do now.<br />
<br />
* '''Numerous other bugfixes/small improvements'''<br />
<br />
=== Version 3.0n ===<br />
* '''AI aircraft dodge and "attack" realistically''': AI dogfights just became 10X as realistic, as fighter planes will turn and attack, just as fighter planes did in WWI and WWII. Try the Marin County Camel Invasion and Marin County Zero Invasion scenarios for a taste of how this works. (No weapons for AI aircraft yet--maybe in the future.)<br />
<br />
* '''New scenario &ndash; B-17 bombers with fighter cover''': Fly out of Marin Ranch and attack a squadron of 6 B-17 Bombers. As you do so, the fighter squadrons descend and swarm you. They don't fire at you (yet! fodder for future versions!) but they turn aggressively towards you, evade your shots, etc., just as real fighters would.<br />
<br />
* '''Damaged ai aircraft crash more realistically'''<br />
<br />
* '''Greatly improved, more realistic damage analysis''': Damage assessment for guns is a lot more realistic, giving greater damage when you hit closer to the center of the object and allowing for the possibility that even small arms might strike a vital or explosive point, causing catastrophic damage. For instance, you can now damage the Nimitz or Eisenhower*--though it's still tough to sink.<br />
<br />
* '''More realistic fire starting''': One of the chief causes of combat aircraft damage is the fires that even small caliber weapons can cause--and fires are even more likely with heavier ammo that includes incendiary (high explosive) materials. Bombable now models that any hit may start a fire, and heavier rounds are more likely to start files. Fires progressively damage the aircraft and eventually bring it down. Beware that fires sometimes go out before completely disabling the aircraft--so monitor the enemy aircraft to make sure they do not recover and escape.<br />
<br />
* '''More realistic aircraft smoke starting''': Similar to fire starting, each damaging hit has the possibility to cause damage that causes the aircraft to emit a trail of smoke. The bigger/closer the hit, the more likely to cause this damage.<br />
<br />
* '''Bombable preferences/settings saved and restored at startup'''<br />
<br />
* '''Fixed excessive damage report problem''': Aircraft would continually report damage even after objects received 100% damage--now fixed.<br />
<br />
* '''Numerous small bugfixes'''<br />
<br />
* Note: You can bomb the Nimitz/Eisenhower carriers if you have the bombable carriers add-on: http://forum.flightgear.org/viewtopic.php?f=2&t=7082<br />
<br />
=== Version 3.0m ===<br />
* Positive and negative G-force limits are now settable separately (most aircraft have different limits for positive vs negative G, so this adds some realism)<br />
<br />
* Bugfixes on damage & damage report<br />
<br />
* Every hit now registers via on-screen popup (vs previous behavior of only showing damage when it increased past multiples of 5%)<br />
<br />
* Bugfixes on g-force damage that caused extraneous very high g forces to cause random damage<br />
<br />
* Bugfixes in multiplayer communication, fixed problems when MP is disabled or doesn't exist<br />
<br />
* Bugfix on bombable multiplayer unload (runtime error "listenerids") and improvement to unload routines<br />
<br />
* Fixed Easy/Super Easy Mode malfunction (Super Easy Mode never engaged; new default mode is Easy Mode which should give same performance as previous default mode)<br />
<br />
* Tuned damage/vulnerabilities on ferries (San Francisco Ferry Invasion scenario)<br />
<br />
=== Version 3.0L ===<br />
* '''Overspeed detection/damage'''<br />
<br />
* '''G-force and overspeed detection optional''': Switches in the Bombable menu to turn it off; turned off by default except for planes included in Bombable package.<br />
<br />
* '''Vulnerabilities framework for primary aircraft''': Allows max acceleration, max speed parameters to be set individually per aircraft (main aircraft) and then damage from overspeed/overacceleration is accrued when those limits are exceeded.<br />
<br />
* '''Blackout/redout tunable per aircraft''': Allows blackout & redout values to be set per aircraft--for instance to reflect that WWI aircraft had no pressure suits or special high-G training. This will help level the playing field and create uniformity in MP dogfighting with similar aircraft.<br />
<br />
* '''G-force and overspeed limits and damage amounts tuned''': For the four aircraft included in the Bombable package (A6M2 Zero, Sopwith Camel, SPAD VII, Fokker DR1) the g-force damage & overspeed damage parameters have been individually tuned and are fairly realistic.<br />
<br />
* '''Fires only for appropriate damage''': Overspeed & overacceleration (g-force) damage doesn't start a fire, though it will still rack up 100% damage and shut you down.<br />
<br />
* '''Numerous bugfixes'''<br />
<br />
=== Version 3.0k ===<br />
* '''Excessive G-force damages your aircraft:''' Excessive g-force now adds damage to your airframe and can even make you crash. To avoid damaging your aircraft due to excessive g-force, always fly with blackout/redout turned on and avoid pulling g-forces much beyond those that make you blackout or redout.<br />
<br />
* '''Zeros over marin county scenario:''' Marin County Zero Invasion scenario added.<br />
<br />
=== Version 3.0j (private release) ===<br />
* '''Burn/smoke on crash:''' Aircraft now catch fire, burn, and instantly go to 100% damage when they crash. This is broadcast via MP so others will see you burn when you crash.<br />
<br />
* '''A5mw zero for dogfighting:''' A6M2 ready for MP dogfighting included in release.<br />
<br />
* '''A6M2 Zero:''' Added historically accurate guns and cannons (fire with e and E) to A6M2 Zero.<br />
<br />
* '''Bombable A62M Zero:''' Included Bombable version of the AI A6M2 Zero from Hellcat's Carrier Bombable project, but also made a few tweaks/improvements to he AI A6M2 for improved realism. See http://www.4shared.com/file/235605076/6101800f/carrier_bombable.html<br />
<br />
* '''Dogfighting:''' Greatly improved dogfighting/multiplayer communication of damages<br />
<br />
* '''Bugfix DR 1:''' Added keyboard firing switch to Fokker DR 1 (use the 'e' key to fire the weapons).<br />
<br />
* '''Bugfixes:''' Many other miscellaneous bug fixes and improvements.<br />
<br />
=== Version 3.0i ===<br />
* '''Reset resets damage:''' In dogfighting, resetting or using the Location menu to change your location resets your damage to 0% and broadcasts that to others flying with you via multiplayer<br />
<br />
* '''FlightGear 2.0 compatible:''' Tested and works with FG 2.0 as well as FG 1.9 and CVS versions between 1.9 and 2.0<br />
<br />
* '''Bugfixes:''' Various small bugfixes<br />
<br />
=== Versions 3.0 through 3.0h ===<br />
* '''Bombable/shootable:''' Code to make objects, AI aircraft, MP aircraft bombable and shootable.<br />
<br />
* '''Moving AI bombable/shootable objects:''' Code to allow AI aircraft, naval vessels, and surface vehicles to move (sort of) realistically and act as bombable/moving aerial targets.<br />
<br />
* '''Scenarios:''' Bombing and dogfighting scenarios using these AI aircraft.<br />
<br />
* '''Multiplayer dogfighting:''' Code to allow multiplayer (MP) communication of damage to aircraft, allowing multiplayer dogfighting<br />
<br />
* '''Aircraft enhancements--weapons and dogfighting:''' Three WWI era aircraft enhanced with historically accurate weapons systems and prepared for MP dogfighting (Sopwith Camel, Fokker DR1, SPAD-VII)<br />
<br />
* '''Contrails and smoke:''' MP aircraft capable of dogfighting, and some other MP and AI aircraft automatically have contrails and engine smoke trails. This makes it possible to locate the aircraft when doing MP dogfighting and generally adds to the realism.<br />
<br />
== External links ==<br />
* [http://forum.flightgear.org/viewtopic.php?f=6&t=5742&p=43772 Download Bombable, Bombable forum thread]<br />
<br />
[[Category:Bombable]]</div>Flughttps://wiki.flightgear.org/w/index.php?title=File:Bombable-Camel-vs-Camel.png&diff=107061File:Bombable-Camel-vs-Camel.png2017-02-23T04:16:41Z<p>Flug: User created page with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=Bombable Add-on: Camel vs Camel}}<br />
|date=2017-02-22<br />
|source={{own}}<br />
|author=[[User:Flug|Flug]]<br />
|permission=<br />
|other versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-by-sa-4.0}}<br />
<br />
<br />
<br />
[[Category:Bombable]]<br />
[[Category:Bombable aircraft]]<br />
[[Category:Add]]</div>Flug