fly/flightgear
1
0
Fork 0
Code Activity
flightgear/src/AIModel/submodel.hxx

146 lines
3.4 KiB
C++
Raw Normal View History

David Culp: Right now the code is not very configurable, and there is only one submodel per airplane possible. It is implemented as an SGSubSystem, just like the electrics, vacuum, etc. systems. To make it work you need to make a release binding like this (for my joystick trigger): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then, each airplane that uses the system should have something like this added to its *-set.xml file (note that this does *not* go within the <sim></sim> tags): <systems> <submodel> <serviceable type="bool">true</serviceable> <amount type="int">70</amount> </submodel> </systems> Future improvements will include: 1) more configurability, so the user can create multiple submodels, and can assign them different locations, and pitch and yaw adjustments, and nitial velocity. 2) sound? 3) a more accurate calculation of the submodels location at any pitch/roll/yaw. 4) a way to pre-load the model, so the AI code doesn't have to parse the model every time it creates an instance. I think that's all of it.
2004-08-22 16:22:18 +00:00
// submodel.hxx - models a releasable submodel.
// Written by Dave Culp, started Aug 2004
//
// This file is in the Public Domain and comes with no warranty.
#ifndef __SYSTEMS_SUBMODEL_HXX
#define __SYSTEMS_SUBMODEL_HXX 1
#ifndef __cplusplus
# error This library requires C++
#endif
#include <simgear/props/props.hxx>
#include <simgear/structure/subsystem_mgr.hxx>
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
#include <AIModel/AIBase.hxx>
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
#include <vector>
#include <string>
SG_USING_STD(vector);
SG_USING_STD(string);
David Culp: Right now the code is not very configurable, and there is only one submodel per airplane possible. It is implemented as an SGSubSystem, just like the electrics, vacuum, etc. systems. To make it work you need to make a release binding like this (for my joystick trigger): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then, each airplane that uses the system should have something like this added to its *-set.xml file (note that this does *not* go within the <sim></sim> tags): <systems> <submodel> <serviceable type="bool">true</serviceable> <amount type="int">70</amount> </submodel> </systems> Future improvements will include: 1) more configurability, so the user can create multiple submodels, and can assign them different locations, and pitch and yaw adjustments, and nitial velocity. 2) sound? 3) a more accurate calculation of the submodels location at any pitch/roll/yaw. 4) a way to pre-load the model, so the AI code doesn't have to parse the model every time it creates an instance. I think that's all of it.
2004-08-22 16:22:18 +00:00
Move the submodels code from the Systems manager into it's own Subsystem manager.
2004-10-22 09:58:24 +00:00
class FGSubmodelMgr : public SGSubsystem
David Culp: Right now the code is not very configurable, and there is only one submodel per airplane possible. It is implemented as an SGSubSystem, just like the electrics, vacuum, etc. systems. To make it work you need to make a release binding like this (for my joystick trigger): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then, each airplane that uses the system should have something like this added to its *-set.xml file (note that this does *not* go within the <sim></sim> tags): <systems> <submodel> <serviceable type="bool">true</serviceable> <amount type="int">70</amount> </submodel> </systems> Future improvements will include: 1) more configurability, so the user can create multiple submodels, and can assign them different locations, and pitch and yaw adjustments, and nitial velocity. 2) sound? 3) a more accurate calculation of the submodels location at any pitch/roll/yaw. 4) a way to pre-load the model, so the AI code doesn't have to parse the model every time it creates an instance. I think that's all of it.
2004-08-22 16:22:18 +00:00
{
public:
Vivian Meazza: Testing revealed that the code was not reading y-offset - a typo in the original code, and roll was in the wrong sense. All readily fixable, and it now works.
2004-09-07 19:10:10 +00:00
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
typedef struct {
Vivian Meazza: Testing revealed that the code was not reading y-offset - a typo in the original code, and roll was in the wrong sense. All readily fixable, and it now works.
2004-09-07 19:10:10 +00:00
SGPropertyNode* trigger;
SGPropertyNode* prop;
Vivian Meazza: The calculation of submodel mass from weight has been moved from AIBallistic to Submodel so that it is calculated only once, rather than on every iteration as a present. The parameter <contents> has been added, primarily so that droptanks will have the proper mass. It is the path to an appropriate property containing a weight in lbs. Care has to be taken with the use of <contents> because after a reset there appears to be a delay in submodel instantiation (dt not properly reset???) and the weight property is not always picked up before it is set to zero in the key bindings. Slightly hard to explain. It works fine if FGFS has not been reset though. There is a partial solution which involves the rejigging of the fuel and gui nasal scripts, but there is still the visible delay in instantiation to be resolved. I've nearly done the nasal fixes, which will form part of an update to the Hunter only. I'll probably complete those later today.
2004-09-27 14:24:20 +00:00
SGPropertyNode* contents_node;
Vivian Meazza: I have added <Cd> and <weight> to the input parameters in the submodels.xml script. Raw data may be used, thus avoiding the need to guestimate <eda>. Eda remains, but should now be used to enter the proper cross-sectional area.
2004-09-22 08:47:05 +00:00
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
string name;
string model;
double speed;
bool slaved;
bool repeat;
double delay;
double timer;
int count;
double x_offset;
double y_offset;
double z_offset;
double yaw_offset;
double pitch_offset;
David Culp: Silly me. I was starting the timer at zero, so the first tracer didn't fly until 0.25 seconds after pulling the trigger. Now the timer starts at the same value as "delay", so the first round comes out immediately. Also, I've added an optional configuration attribute that allows you to change the ballistics of the submodel. This allows parachutes, or anything else that has ballistics different from a bullet. The attribute is called "eda", which is the equivalent drag area. Default value is 0.007, which gives the same ballistics as the current tracers. Increasing this value gives more drag. A value of 2.0 looks good for a parachute. math stuff ######################################################################## The deceleration of the ballictic object is now given by: [ (rho) (Cd) ] / [ (1/2) (m) ] * A * (V * V) where rho is sea-level air density, and Cd and m are fixed, bullet-like values. So the calculation is: 0.0116918 * A * (V * V) The value "A" is what I'm calling the "eda" (equivalent drag area). ######################################################################## A parachute model will have to be built so that the parachutist's feet are in the forward x-direction. Here is the submodel.xml config I use for "parachutes": <submodel> <name>flares</name> <model>Models/Geometry/flare.ac</model> <trigger>systems/submodels/submodel[0]/trigger</trigger> <speed>0.0</speed> <repeat>true</repeat> <delay>0.85</delay> <count>4</count> <x-offset>0.0</x-offset> <y-offset>0.0</y-offset> <z-offset>-4.0</z-offset> <yaw-offset>0.0</yaw-offset> <pitch-offset>0.0</pitch-offset> <eda>2.0</eda> </submodel>
2004-08-26 16:25:54 +00:00
double drag_area;
David Culp: Here are small changes that allow one to set a life-span for submodels.
2004-08-30 09:11:59 +00:00
double life;
Add the missing buoyancy patch.
2004-09-01 21:05:04 +00:00
double buoyancy;
Vivian Meazza: I've added another parameter to the submodel - wind. It's activated by the entry <wind>true</wind> in the ../submodel.xml file. If true, the submodel is affected by the local wind, otherwise not. The parameter defaults to false. This is useful for exhausts and smoke, and possibly all objects.
2004-09-05 09:45:34 +00:00
bool wind;
David Culp: Here are some things I've added to the submodel code. First, I added a first_time value that is true when the trigger is pressed and false when the trigger is released. The true value is also made false after the first pass through release(). Release() then uses this to force the first dt (per salvo) to be zero. I was hoping this would make the submodel appear closer to the airplane, but I don't notice a difference with the tracers. In a prior test I found that the first dt is about 2.5 times larger than subsequent ones. Maybe this will be effective with slower submodels, like smoke, contrails, etc. Secondly, I updated the IC.elevation and IC.azimuth calcs to correctly add in the yaw and pitch offsets, corrected for bank angle. Actually this is still an estimation. A proper calculation will sum the submodels vector with the airplane's vector. Until that's done only models which are fired forward will have proper IC.
2004-09-09 08:40:08 +00:00
bool first_time;
Vivian Meazza: I have added <Cd> and <weight> to the input parameters in the submodels.xml script. Raw data may be used, thus avoiding the need to guestimate <eda>. Eda remains, but should now be used to enter the proper cross-sectional area.
2004-09-22 08:47:05 +00:00
double cd;
double weight;
Vivian Meazza: The calculation of submodel mass from weight has been moved from AIBallistic to Submodel so that it is calculated only once, rather than on every iteration as a present. The parameter <contents> has been added, primarily so that droptanks will have the proper mass. It is the path to an appropriate property containing a weight in lbs. Care has to be taken with the use of <contents> because after a reset there appears to be a delay in submodel instantiation (dt not properly reset???) and the weight property is not always picked up before it is set to zero in the key bindings. Slightly hard to explain. It works fine if FGFS has not been reset though. There is a partial solution which involves the rejigging of the fuel and gui nasal scripts, but there is still the visible delay in instantiation to be resolved. I've nearly done the nasal fixes, which will form part of an update to the Hunter only. I'll probably complete those later today.
2004-09-27 14:24:20 +00:00
double contents;
Vivian Meazza: As a result of recent requests, I've implemented the ability to switch off aerodynamic stabilisation: This has to be added to the submodel.xml files: <aero-stabilised>false</aero-stabilised> When false the submodel retains the pitch given at instantiation. It defaults to true.
2004-10-28 08:29:15 +00:00
bool aero_stabilised;
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
} submodel;
typedef struct {
double lat;
double lon;
double alt;
Vivian Meazza: Testing revealed that the code was not reading y-offset - a typo in the original code, and roll was in the wrong sense. All readily fixable, and it now works.
2004-09-07 19:10:10 +00:00
double roll;
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
double azimuth;
double elevation;
double speed;
Vivian Meazza: I've added another parameter to the submodel - wind. It's activated by the entry <wind>true</wind> in the ../submodel.xml file. If true, the submodel is affected by the local wind, otherwise not. The parameter defaults to false. This is useful for exhausts and smoke, and possibly all objects.
2004-09-05 09:45:34 +00:00
double wind_from_east;
double wind_from_north;
Vivan Meazza: The maths, so far, is now correct. Roll and pitch are now both in the correct sense. The aircraft velocity is added correctly to the submodel velocity, and the submodel is now visible when instantiated. However, the velocity is measured at the aircraft centre. To be totally correct we ought to take into account the aircraft's rotational velocity. We have pitch rate and roll rate available, but not yaw rate (small anyway).
2004-09-14 08:27:55 +00:00
double speed_down_fps;
double speed_east_fps;
double speed_north_fps;
double total_speed_down;
double total_speed_east;
double total_speed_north;
Vivian Meazza: I have added <Cd> and <weight> to the input parameters in the submodels.xml script. Raw data may be used, thus avoiding the need to guestimate <eda>. Eda remains, but should now be used to enter the proper cross-sectional area.
2004-09-22 08:47:05 +00:00
double mass;
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
} IC_struct;
Move the submodels code from the Systems manager into it's own Subsystem manager.
2004-10-22 09:58:24 +00:00
FGSubmodelMgr ();
~FGSubmodelMgr ();
David Culp: Right now the code is not very configurable, and there is only one submodel per airplane possible. It is implemented as an SGSubSystem, just like the electrics, vacuum, etc. systems. To make it work you need to make a release binding like this (for my joystick trigger): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then, each airplane that uses the system should have something like this added to its *-set.xml file (note that this does *not* go within the <sim></sim> tags): <systems> <submodel> <serviceable type="bool">true</serviceable> <amount type="int">70</amount> </submodel> </systems> Future improvements will include: 1) more configurability, so the user can create multiple submodels, and can assign them different locations, and pitch and yaw adjustments, and nitial velocity. 2) sound? 3) a more accurate calculation of the submodels location at any pitch/roll/yaw. 4) a way to pre-load the model, so the AI code doesn't have to parse the model every time it creates an instance. I think that's all of it.
2004-08-22 16:22:18 +00:00
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
void load ();
David Culp: Right now the code is not very configurable, and there is only one submodel per airplane possible. It is implemented as an SGSubSystem, just like the electrics, vacuum, etc. systems. To make it work you need to make a release binding like this (for my joystick trigger): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then, each airplane that uses the system should have something like this added to its *-set.xml file (note that this does *not* go within the <sim></sim> tags): <systems> <submodel> <serviceable type="bool">true</serviceable> <amount type="int">70</amount> </submodel> </systems> Future improvements will include: 1) more configurability, so the user can create multiple submodels, and can assign them different locations, and pitch and yaw adjustments, and nitial velocity. 2) sound? 3) a more accurate calculation of the submodels location at any pitch/roll/yaw. 4) a way to pre-load the model, so the AI code doesn't have to parse the model every time it creates an instance. I think that's all of it.
2004-08-22 16:22:18 +00:00
void init ();
void bind ();
void unbind ();
void update (double dt);
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
bool release (submodel* sm, double dt);
void transform (submodel* sm);
Vivian Meazza: Testing revealed that the code was not reading y-offset - a typo in the original code, and roll was in the wrong sense. All readily fixable, and it now works.
2004-09-07 19:10:10 +00:00
void updatelat( double lat );
David Culp: Right now the code is not very configurable, and there is only one submodel per airplane possible. It is implemented as an SGSubSystem, just like the electrics, vacuum, etc. systems. To make it work you need to make a release binding like this (for my joystick trigger): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then, each airplane that uses the system should have something like this added to its *-set.xml file (note that this does *not* go within the <sim></sim> tags): <systems> <submodel> <serviceable type="bool">true</serviceable> <amount type="int">70</amount> </submodel> </systems> Future improvements will include: 1) more configurability, so the user can create multiple submodels, and can assign them different locations, and pitch and yaw adjustments, and nitial velocity. 2) sound? 3) a more accurate calculation of the submodels location at any pitch/roll/yaw. 4) a way to pre-load the model, so the AI code doesn't have to parse the model every time it creates an instance. I think that's all of it.
2004-08-22 16:22:18 +00:00
private:
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
typedef vector <submodel*> submodel_vector_type;
typedef submodel_vector_type::iterator submodel_vector_iterator;
submodel_vector_type submodels;
submodel_vector_iterator submodel_iterator;
Vivian Meazza: Testing revealed that the code was not reading y-offset - a typo in the original code, and roll was in the wrong sense. All readily fixable, and it now works.
2004-09-07 19:10:10 +00:00
float trans[3][3];
float in[3];
float out[3];
double Rx, Ry, Rz;
double Sx, Sy, Sz;
double Tx, Ty, Tz;
float cosRx, sinRx;
float cosRy, sinRy;
float cosRz, sinRz;
double ft_per_deg_longitude;
double ft_per_deg_latitude;
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
David Culp: Right now the code is not very configurable, and there is only one submodel per airplane possible. It is implemented as an SGSubSystem, just like the electrics, vacuum, etc. systems. To make it work you need to make a release binding like this (for my joystick trigger): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then, each airplane that uses the system should have something like this added to its *-set.xml file (note that this does *not* go within the <sim></sim> tags): <systems> <submodel> <serviceable type="bool">true</serviceable> <amount type="int">70</amount> </submodel> </systems> Future improvements will include: 1) more configurability, so the user can create multiple submodels, and can assign them different locations, and pitch and yaw adjustments, and nitial velocity. 2) sound? 3) a more accurate calculation of the submodels location at any pitch/roll/yaw. 4) a way to pre-load the model, so the AI code doesn't have to parse the model every time it creates an instance. I think that's all of it.
2004-08-22 16:22:18 +00:00
double x_offset, y_offset, z_offset;
double pitch_offset, yaw_offset;
Vivian Meazza: I have added <Cd> and <weight> to the input parameters in the submodels.xml script. Raw data may be used, thus avoiding the need to guestimate <eda>. Eda remains, but should now be used to enter the proper cross-sectional area.
2004-09-22 08:47:05 +00:00
static const double lbs_to_slugs; //conversion factor
David Culp: Here are files to get automated contrails working. I've set up contrails for the 737, using my simple, untextured contrail model. Vivian has made another contrail model, but I'm still trying to get his to work. I'm hoping others will try to make contrail models also. Here's some code that defines a top to thermals. When the top of a thermal is reached the strength is phased-out linearly over the next 100 feet of altitude. At first I tried just capping the thermal at the top, but the change in thermal strength was too fast for the FDM to handle well. Included is a new version of the thermal scenario that includes a top (height-msl) to the thermal. The default value is 5000 feet.
2004-11-07 14:46:21 +00:00
double contrail_altitude;
Vivian Meazza: Testing revealed that the code was not reading y-offset - a typo in the original code, and roll was in the wrong sense. All readily fixable, and it now works.
2004-09-07 19:10:10 +00:00
SGPropertyNode* _serviceable_node;
SGPropertyNode* _user_lat_node;
SGPropertyNode* _user_lon_node;
SGPropertyNode* _user_heading_node;
SGPropertyNode* _user_alt_node;
SGPropertyNode* _user_pitch_node;
SGPropertyNode* _user_roll_node;
SGPropertyNode* _user_yaw_node;
David Culp: Here are some things I've added to the submodel code. First, I added a first_time value that is true when the trigger is pressed and false when the trigger is released. The true value is also made false after the first pass through release(). Release() then uses this to force the first dt (per salvo) to be zero. I was hoping this would make the submodel appear closer to the airplane, but I don't notice a difference with the tracers. In a prior test I found that the first dt is about 2.5 times larger than subsequent ones. Maybe this will be effective with slower submodels, like smoke, contrails, etc. Secondly, I updated the IC.elevation and IC.azimuth calcs to correctly add in the yaw and pitch offsets, corrected for bank angle. Actually this is still an estimation. A proper calculation will sum the submodels vector with the airplane's vector. Until that's done only models which are fired forward will have proper IC.
2004-09-09 08:40:08 +00:00
SGPropertyNode* _user_alpha_node;
Vivian Meazza: Testing revealed that the code was not reading y-offset - a typo in the original code, and roll was in the wrong sense. All readily fixable, and it now works.
2004-09-07 19:10:10 +00:00
SGPropertyNode* _user_speed_node;
SGPropertyNode* _user_wind_from_east_node;
SGPropertyNode* _user_wind_from_north_node;
Vivian Meazza: I have added <Cd> and <weight> to the input parameters in the submodels.xml script. Raw data may be used, thus avoiding the need to guestimate <eda>. Eda remains, but should now be used to enter the proper cross-sectional area.
2004-09-22 08:47:05 +00:00
SGPropertyNode* _user_speed_down_fps_node;
SGPropertyNode* _user_speed_east_fps_node;
SGPropertyNode* _user_speed_north_fps_node;
David Culp: Here are files to get automated contrails working. I've set up contrails for the 737, using my simple, untextured contrail model. Vivian has made another contrail model, but I'm still trying to get his to work. I'm hoping others will try to make contrail models also. Here's some code that defines a top to thermals. When the top of a thermal is reached the strength is phased-out linearly over the next 100 feet of altitude. At first I tried just capping the thermal at the top, but the change in thermal strength was too fast for the FDM to handle well. Included is a new version of the thermal scenario that includes a top (height-msl) to the thermal. The default value is 5000 feet.
2004-11-07 14:46:21 +00:00
SGPropertyNode* _contrail_altitude_node;
SGPropertyNode* _contrail_trigger;
Vivian Meazza: I have added <Cd> and <weight> to the input parameters in the submodels.xml script. Raw data may be used, thus avoiding the need to guestimate <eda>. Eda remains, but should now be used to enter the proper cross-sectional area.
2004-09-22 08:47:05 +00:00
David Culp: Right now the code is not very configurable, and there is only one submodel per airplane possible. It is implemented as an SGSubSystem, just like the electrics, vacuum, etc. systems. To make it work you need to make a release binding like this (for my joystick trigger): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then, each airplane that uses the system should have something like this added to its *-set.xml file (note that this does *not* go within the <sim></sim> tags): <systems> <submodel> <serviceable type="bool">true</serviceable> <amount type="int">70</amount> </submodel> </systems> Future improvements will include: 1) more configurability, so the user can create multiple submodels, and can assign them different locations, and pitch and yaw adjustments, and nitial velocity. 2) sound? 3) a more accurate calculation of the submodels location at any pitch/roll/yaw. 4) a way to pre-load the model, so the AI code doesn't have to parse the model every time it creates an instance. I think that's all of it.
2004-08-22 16:22:18 +00:00
FGAIManager* ai;
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
IC_struct IC;
David Culp: Here are some things I've added to the submodel code. First, I added a first_time value that is true when the trigger is pressed and false when the trigger is released. The true value is also made false after the first pass through release(). Release() then uses this to force the first dt (per salvo) to be zero. I was hoping this would make the submodel appear closer to the airplane, but I don't notice a difference with the tracers. In a prior test I found that the first dt is about 2.5 times larger than subsequent ones. Maybe this will be effective with slower submodels, like smoke, contrails, etc. Secondly, I updated the IC.elevation and IC.azimuth calcs to correctly add in the yaw and pitch offsets, corrected for bank angle. Actually this is still an estimation. A proper calculation will sum the submodels vector with the airplane's vector. Until that's done only models which are fired forward will have proper IC.
2004-09-09 08:40:08 +00:00
David Culp: Right now the code is not very configurable, and there is only one submodel per airplane possible. It is implemented as an SGSubSystem, just like the electrics, vacuum, etc. systems. To make it work you need to make a release binding like this (for my joystick trigger): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodel/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then, each airplane that uses the system should have something like this added to its *-set.xml file (note that this does *not* go within the <sim></sim> tags): <systems> <submodel> <serviceable type="bool">true</serviceable> <amount type="int">70</amount> </submodel> </systems> Future improvements will include: 1) more configurability, so the user can create multiple submodels, and can assign them different locations, and pitch and yaw adjustments, and nitial velocity. 2) sound? 3) a more accurate calculation of the submodels location at any pitch/roll/yaw. 4) a way to pre-load the model, so the AI code doesn't have to parse the model every time it creates an instance. I think that's all of it.
2004-08-22 16:22:18 +00:00
};
#endif // __SYSTEMS_SUBMODEL_HXX
Vivian Meazza: I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I have neither added the rotational speed to the submodel, nor yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine.
2004-09-17 16:32:58 +00:00
Vivian Meazza: I have added <Cd> and <weight> to the input parameters in the submodels.xml script. Raw data may be used, thus avoiding the need to guestimate <eda>. Eda remains, but should now be used to enter the proper cross-sectional area.
2004-09-22 08:47:05 +00:00
Vivian Meazza: The calculation of submodel mass from weight has been moved from AIBallistic to Submodel so that it is calculated only once, rather than on every iteration as a present. The parameter <contents> has been added, primarily so that droptanks will have the proper mass. It is the path to an appropriate property containing a weight in lbs. Care has to be taken with the use of <contents> because after a reset there appears to be a delay in submodel instantiation (dt not properly reset???) and the weight property is not always picked up before it is set to zero in the key bindings. Slightly hard to explain. It works fine if FGFS has not been reset though. There is a partial solution which involves the rejigging of the fuel and gui nasal scripts, but there is still the visible delay in instantiation to be resolved. I've nearly done the nasal fixes, which will form part of an update to the Hunter only. I'll probably complete those later today.
2004-09-27 14:24:20 +00:00
Copy permalink