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

364 lines
12 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.cxx - models a releasable submodel.
// Written by Dave Culp, started Aug 2004
//
// This file is in the Public Domain and comes with no warranty.
#include "submodel.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 <simgear/structure/exception.hxx>
#include <simgear/misc/sg_path.hxx>
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
#include <Main/fg_props.hxx>
#include <Main/util.hxx>
#include <AIModel/AIManager.hxx>
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
#include <AIModel/AIBallistic.hxx>
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
const double FGSubmodelMgr::lbs_to_slugs = 0.031080950172;
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
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
{
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: 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
x_offset = y_offset = 0.0;
z_offset = -4.0;
pitch_offset = 2.0;
yaw_offset = 0.0;
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
out[0] = out[1] = out[2] = 0;
in[3] = out[3] = 1;
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
string contents_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
contrail_altitude = 30000.0;
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
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
{
}
void
Move the submodels code from the Systems manager into it's own Subsystem manager.
2004-10-22 09:58:24 +00:00
FGSubmodelMgr::init ()
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
load();
Move the submodels from the /systems proprty subtree into /ai instead.
2004-10-28 08:44:24 +00:00
_serviceable_node = fgGetNode("/sim/submodels/serviceable", true);
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
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
_user_lat_node = fgGetNode("/position/latitude-deg", true);
_user_lon_node = fgGetNode("/position/longitude-deg", true);
_user_alt_node = fgGetNode("/position/altitude-ft", true);
_user_heading_node = fgGetNode("/orientation/heading-deg", true);
_user_pitch_node = fgGetNode("/orientation/pitch-deg", true);
_user_roll_node = fgGetNode("/orientation/roll-deg", true);
_user_yaw_node = fgGetNode("/orientation/yaw-deg", true);
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
_user_alpha_node = fgGetNode("/orientation/alpha-deg", true);
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
_user_speed_node = fgGetNode("/velocities/uBody-fps", true);
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
_user_wind_from_east_node = fgGetNode("/environment/wind-from-east-fps",true);
_user_wind_from_north_node = fgGetNode("/environment/wind-from-north-fps",true);
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
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
_user_speed_down_fps_node = fgGetNode("/velocities/speed-down-fps",true);
_user_speed_east_fps_node = fgGetNode("/velocities/speed-east-fps",true);
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
_user_speed_north_fps_node = fgGetNode("/velocities/speed-north-fps",true);
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
_contrail_altitude_node = fgGetNode("/environment/params/contrail-altitude", true);
contrail_altitude = _contrail_altitude_node->getDoubleValue();
_contrail_trigger = fgGetNode("ai/submodels/contrails", true);
_contrail_trigger->setBoolValue(false);
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 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
ai = (FGAIManager*)globals->get_subsystem("ai_model");
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: 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
Move the submodels code from the Systems manager into it's own Subsystem manager.
2004-10-22 09:58:24 +00:00
FGSubmodelMgr::bind ()
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
Move the submodels code from the Systems manager into it's own Subsystem manager.
2004-10-22 09:58:24 +00:00
FGSubmodelMgr::unbind ()
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
{
Tie the count into the property tree instead of using snprintf every frame. Add the life-timer to the property tree under sim/time/elapsed-sec for AI object animation (blending and/or scaling).
2004-08-30 11:13:29 +00:00
submodel_iterator = submodels.begin();
while(submodel_iterator != submodels.end()) {
(*submodel_iterator)->prop->untie("count");
++submodel_iterator;
}
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
Move the submodels code from the Systems manager into it's own Subsystem manager.
2004-10-22 09:58:24 +00:00
FGSubmodelMgr::update (double dt)
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
if (!(_serviceable_node->getBoolValue())) return;
David Culp, Vivian Meazza: Last night I sent these new files to Vivian to fix a problem he found. Since we can have more than one submodel we need more than one "count" property. The new code creates a property systems/submodels/submodel[n]/count for each submodel. Vivian is using this count property for his sound.
2004-08-26 12:27:39 +00:00
int i=-1;
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
Melchior FRANZ: - don't treat *every* child in the xml as submodel, especially not a "param" block - do not only *enable* the contrail flag above some altitude, but also disable it below
2005-03-31 08:54:04 +00:00
_contrail_trigger->setBoolValue(_user_alt_node->getDoubleValue() > contrail_altitude);
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
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_iterator = submodels.begin();
while(submodel_iterator != submodels.end()) {
David Culp, Vivian Meazza: Last night I sent these new files to Vivian to fix a problem he found. Since we can have more than one submodel we need more than one "count" property. The new code creates a property systems/submodels/submodel[n]/count for each submodel. Vivian is using this count property for his sound.
2004-08-26 12:27:39 +00:00
i++;
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
if ((*submodel_iterator)->trigger->getBoolValue()) {
David Culp: This is n idea from Vivian, it allows setting the count to a negative number which will give unlimited submodels (as long as the trigger is true). This is useful for contrails.
2004-08-30 09:15:04 +00:00
if ((*submodel_iterator)->count != 0) {
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
release( (*submodel_iterator), dt);
}
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
} else {
(*submodel_iterator)->first_time = true;
}
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_iterator;
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
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
}
bool
Move the submodels code from the Systems manager into it's own Subsystem manager.
2004-10-22 09:58:24 +00:00
FGSubmodelMgr::release (submodel* sm, double dt)
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
{
Vivian MEAZZA: "Implement the repeat function for submodels. Default value is 'false' "
2006-01-30 22:08:53 +00:00
// only run if first time or repeat is set to true
if (!sm->first_time && !sm->repeat) return false;
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
sm->timer += dt;
if (sm->timer < sm->delay) return false;
sm->timer = 0.0;
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
if (sm->first_time) {
dt = 0.0;
sm->first_time = false;
}
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
transform(sm); // calculate submodel's initial conditions in world-coordinates
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
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
FGAIBallistic* ballist = new FGAIBallistic;
ballist->setPath(sm->model.c_str());
ballist->setLatitude(IC.lat);
ballist->setLongitude(IC.lon);
ballist->setAltitude(IC.alt);
ballist->setAzimuth(IC.azimuth);
ballist->setElevation(IC.elevation);
ballist->setRoll(IC.roll);
ballist->setSpeed(IC.speed);
ballist->setDragArea(sm->drag_area);
ballist->setLife(sm->life);
ballist->setBuoyancy(sm->buoyancy);
ballist->setWind_from_east(IC.wind_from_east);
ballist->setWind_from_north(IC.wind_from_north);
ballist->setWind(sm->wind);
ballist->setCd(sm->cd);
ballist->setMass(IC.mass);
ballist->setStabilisation(sm->aero_stabilised);
ai->attach(ballist);
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: This is n idea from Vivian, it allows setting the count to a negative number which will give unlimited submodels (as long as the trigger is true). This is useful for contrails.
2004-08-30 09:15:04 +00:00
if (sm->count > 0) (sm->count)--;
David Culp, Vivian Meazza: Last night I sent these new files to Vivian to fix a problem he found. Since we can have more than one submodel we need more than one "count" property. The new code creates a property systems/submodels/submodel[n]/count for each submodel. Vivian is using this count property for his sound.
2004-08-26 12:27:39 +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
return true;
}
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
Move the submodels code from the Systems manager into it's own Subsystem manager.
2004-10-22 09:58:24 +00:00
FGSubmodelMgr::load ()
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
{
Move the submodels from the /systems proprty subtree into /ai instead.
2004-10-28 08:44:24 +00:00
SGPropertyNode *path = fgGetNode("/sim/submodels/path");
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
SGPropertyNode root;
if (path) {
SGPath config( globals->get_fg_root() );
config.append( path->getStringValue() );
try {
readProperties(config.str(), &root);
} catch (const sg_exception &e) {
SG_LOG(SG_GENERAL, SG_ALERT,
"Unable to read submodels file: ");
cout << config.str() << endl;
return;
}
}
Melchior FRANZ: - don't treat *every* child in the xml as submodel, especially not a "param" block - do not only *enable* the contrail flag above some altitude, but also disable it below
2005-03-31 08:54:04 +00:00
vector<SGPropertyNode_ptr> children = root.getChildren("submodel");
vector<SGPropertyNode_ptr>::iterator it = children.begin();
vector<SGPropertyNode_ptr>::iterator end = children.end();
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
for (int i = 0; it != end; ++it, i++) {
Melchior FRANZ: - don't treat *every* child in the xml as submodel, especially not a "param" block - do not only *enable* the contrail flag above some altitude, but also disable it below
2005-03-31 08:54:04 +00:00
// cout << "Reading submodel " << (*it)->getPath() << endl;
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* sm = new submodel;
Melchior FRANZ: - don't treat *every* child in the xml as submodel, especially not a "param" block - do not only *enable* the contrail flag above some altitude, but also disable it below
2005-03-31 08:54:04 +00:00
SGPropertyNode * entry_node = *it;
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
sm->trigger = fgGetNode(entry_node->getStringValue("trigger", "none"), true);
sm->name = entry_node->getStringValue("name", "none_defined");
David Culp, Vivian Meazza: Last night I sent these new files to Vivian to fix a problem he found. Since we can have more than one submodel we need more than one "count" property. The new code creates a property systems/submodels/submodel[n]/count for each submodel. Vivian is using this count property for his sound.
2004-08-26 12:27:39 +00:00
sm->model = entry_node->getStringValue("model", "Models/Geometry/rocket.ac");
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
sm->speed = entry_node->getDoubleValue("speed", 2329.4 );
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
sm->repeat = entry_node->getBoolValue ("repeat", false);
sm->delay = entry_node->getDoubleValue("delay", 0.25);
sm->count = entry_node->getIntValue ("count", 1);
sm->slaved = entry_node->getBoolValue ("slaved", false);
sm->x_offset = entry_node->getDoubleValue("x-offset", 0.0);
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
sm->y_offset = entry_node->getDoubleValue("y-offset", 0.0);
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
sm->z_offset = entry_node->getDoubleValue("z-offset", 0.0);
sm->yaw_offset = entry_node->getDoubleValue("yaw-offset", 0.0);
sm->pitch_offset = entry_node->getDoubleValue("pitch-offset", 0.0);
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
sm->drag_area = entry_node->getDoubleValue("eda", 0.034);
David Culp: Here are small changes that allow one to set a life-span for submodels.
2004-08-30 09:11:59 +00:00
sm->life = entry_node->getDoubleValue("life", 900.0);
Add the missing buoyancy patch.
2004-09-01 21:05:04 +00:00
sm->buoyancy = entry_node->getDoubleValue("buoyancy", 0);
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
sm->wind = entry_node->getBoolValue ("wind", false);
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
sm->first_time = false;
Vivian Meazza: I've made appropriate changes to Readme.submodels to reflect the variation of Cd with Mach number. Spitfire.submodel has been changed to use the variation of Cd with Mach number Submodel.cxx has been changed so that the default value of Cd is the subsonic Cd of a non-boat tailed bullet.
2004-10-02 14:30:18 +00:00
sm->cd = entry_node->getDoubleValue("cd", 0.193);
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
sm->weight = entry_node->getDoubleValue("weight", 0.25);
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
sm->aero_stabilised = entry_node->getBoolValue ("aero-stabilised", true);
Vivian Meazza: I've made appropriate changes to Readme.submodels to reflect the variation of Cd with Mach number. Spitfire.submodel has been changed to use the variation of Cd with Mach number Submodel.cxx has been changed so that the default value of Cd is the subsonic Cd of a non-boat tailed bullet.
2004-10-02 14:30:18 +00:00
sm->contents_node = fgGetNode(entry_node->getStringValue("contents", "none"), true);
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
sm->trigger->setBoolValue(false);
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
sm->timer = sm->delay;
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
sm->contents = sm->contents_node->getDoubleValue();
Move the submodels from the /systems proprty subtree into /ai instead.
2004-10-28 08:44:24 +00:00
sm->prop = fgGetNode("/ai/submodels/submodel", i, true);
Tie the count into the property tree instead of using snprintf every frame. Add the life-timer to the property tree under sim/time/elapsed-sec for AI object animation (blending and/or scaling).
2004-08-30 11:13:29 +00:00
sm->prop->tie("count", SGRawValuePointer<int>(&(sm->count)));
Vivian MEAZZA: "Implement the repeat function for submodels. Default value is 'false' "
2006-01-30 22:08:53 +00:00
sm->prop->tie("repeat", SGRawValuePointer<bool>(&(sm->repeat)));
Tie the count into the property tree instead of using snprintf every frame. Add the life-timer to the property tree under sim/time/elapsed-sec for AI object animation (blending and/or scaling).
2004-08-30 11:13:29 +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
// sm->prop->tie("contents", SGRawValuePointer<double>(&(sm->contents)));
// sm->prop->tie("contents path", SGRawValuePointer<const char *>(&(sm->contents_node)));
Tie the count into the property tree instead of using snprintf every frame. Add the life-timer to the property tree under sim/time/elapsed-sec for AI object animation (blending and/or scaling).
2004-08-30 11:13:29 +00:00
submodels.push_back( sm );
David Culp, Vivian Meazza: Last night I sent these new files to Vivian to fix a problem he found. Since we can have more than one submodel we need more than one "count" property. The new code creates a property systems/submodels/submodel[n]/count for each submodel. Vivian is using this count property for his sound.
2004-08-26 12:27:39 +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
submodel_iterator = submodels.begin();
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: 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, Vivian Meazza: Last night I sent these new files to Vivian to fix a problem he found. Since we can have more than one submodel we need more than one "count" property. The new code creates a property systems/submodels/submodel[n]/count for each submodel. Vivian is using this count property for his sound.
2004-08-26 12:27:39 +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
Move the submodels code from the Systems manager into it's own Subsystem manager.
2004-10-22 09:58:24 +00:00
FGSubmodelMgr::transform( submodel* sm)
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
{
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
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
// get initial conditions
// get the weight of the contents (lbs) and convert to mass (slugs)
sm->contents = sm->contents_node->getDoubleValue();
IC.mass = (sm->weight + sm->contents) * lbs_to_slugs;;
// cout << IC.mass << endl;
// set contents to 0 in the parent
sm->contents_node->setDoubleValue(0);
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
IC.lat = _user_lat_node->getDoubleValue();
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
IC.lon = _user_lon_node->getDoubleValue();
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
IC.alt = _user_alt_node->getDoubleValue();
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
IC.roll = _user_roll_node->getDoubleValue(); // rotation about x axis
IC.elevation = _user_pitch_node->getDoubleValue(); // rotation about y axis
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
IC.azimuth = _user_heading_node->getDoubleValue(); // rotation about z axis
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
IC.speed = _user_speed_node->getDoubleValue();
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
IC.wind_from_east = _user_wind_from_east_node->getDoubleValue();
IC.wind_from_north = _user_wind_from_north_node->getDoubleValue();
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
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
IC.speed_down_fps = _user_speed_down_fps_node->getDoubleValue();
IC.speed_east_fps = _user_speed_east_fps_node->getDoubleValue();
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
IC.speed_north_fps = _user_speed_north_fps_node->getDoubleValue();
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
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
in[0] = sm->x_offset;
in[1] = sm->y_offset;
in[2] = sm->z_offset;
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
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: 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
// pre-process the trig functions
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
cosRx = cos(-IC.roll * SG_DEGREES_TO_RADIANS);
sinRx = sin(-IC.roll * SG_DEGREES_TO_RADIANS);
cosRy = cos(-IC.elevation * SG_DEGREES_TO_RADIANS);
sinRy = sin(-IC.elevation * SG_DEGREES_TO_RADIANS);
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
cosRz = cos(IC.azimuth * SG_DEGREES_TO_RADIANS);
sinRz = sin(IC.azimuth * SG_DEGREES_TO_RADIANS);
// set up the transform matrix
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
trans[0][0] = cosRy * cosRz;
trans[0][1] = -1 * cosRx * sinRz + sinRx * sinRy * cosRz ;
trans[0][2] = sinRx * sinRz + cosRx * sinRy * cosRz;
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 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
trans[1][0] = cosRy * sinRz;
trans[1][1] = cosRx * cosRz + sinRx * sinRy * sinRz;
trans[1][2] = -1 * sinRx * cosRx + cosRx * sinRy * sinRz;
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 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
trans[2][0] = -1 * sinRy;
trans[2][1] = sinRx * cosRy;
trans[2][2] = cosRx * cosRy;
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
// multiply the input and transform matrices
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: 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
out[0] = in[0] * trans[0][0] + in[1] * trans[0][1] + in[2] * trans[0][2];
out[1] = in[0] * trans[1][0] + in[1] * trans[1][1] + in[2] * trans[1][2];
out[2] = in[0] * trans[2][0] + in[1] * trans[2][1] + in[2] * trans[2][2];
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 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
// convert ft to degrees of latitude
out[0] = out[0] /(366468.96 - 3717.12 * cos(IC.lat * SG_DEGREES_TO_RADIANS));
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 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
// convert ft to degrees of longitude
out[1] = out[1] /(365228.16 * cos(IC.lat * SG_DEGREES_TO_RADIANS));
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 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
// set submodel initial position
IC.lat += out[0];
IC.lon += out[1];
IC.alt += out[2];
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 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
// get aircraft velocity vector angles in XZ and XY planes
//double alpha = _user_alpha_node->getDoubleValue();
//double velXZ = IC.elevation - alpha * cosRx;
//double velXY = IC.azimuth - (IC.elevation - alpha * sinRx);
// Get submodel initial velocity vector angles in XZ and XY planes.
// This needs to be fixed. This vector should be added to aircraft's vector.
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
IC.elevation += (sm->yaw_offset * sinRx) + (sm->pitch_offset * cosRx);
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
IC.azimuth += (sm->yaw_offset * cosRx) - (sm->pitch_offset * sinRx);
// For now assume vector is close to airplane's vector. This needs to be fixed.
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
//IC.speed += ;
// calcuate the total speed north
IC.total_speed_north = sm->speed * cos(IC.elevation*SG_DEGREES_TO_RADIANS)*
cos(IC.azimuth*SG_DEGREES_TO_RADIANS) + IC.speed_north_fps;
// calculate the total speed east
IC.total_speed_east = sm->speed * cos(IC.elevation*SG_DEGREES_TO_RADIANS)*
sin(IC.azimuth*SG_DEGREES_TO_RADIANS) + IC.speed_east_fps;
// calculate the total speed down
IC.total_speed_down = sm->speed * -sin(IC.elevation*SG_DEGREES_TO_RADIANS) +
IC.speed_down_fps;
// re-calculate speed, elevation and azimuth
IC.speed = sqrt( IC.total_speed_north * IC.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
IC.total_speed_east * IC.total_speed_east +
IC.total_speed_down * IC.total_speed_down);
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
IC.azimuth = atan(IC.total_speed_east/IC.total_speed_north) * SG_RADIANS_TO_DEGREES;
// rationalise the output
if (IC.total_speed_north <= 0){
IC.azimuth = 180 + IC.azimuth;
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
}
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
else{
if(IC.total_speed_east <= 0){
IC.azimuth = 360 + IC.azimuth;
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
}
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
}
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: 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
IC.elevation = -atan(IC.total_speed_down/sqrt(IC.total_speed_north *
IC.total_speed_north +
IC.total_speed_east * IC.total_speed_east)) * SG_RADIANS_TO_DEGREES;
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
Move the submodels code from the Systems manager into it's own Subsystem manager.
2004-10-22 09:58:24 +00:00
FGSubmodelMgr::updatelat(double lat)
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 latitude = lat;
ft_per_deg_latitude = 366468.96 - 3717.12 * cos(latitude / SG_RADIANS_TO_DEGREES);
ft_per_deg_longitude = 365228.16 * cos(latitude / SG_RADIANS_TO_DEGREES);
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
}
David Culp, Vivian Meazza: Last night I sent these new files to Vivian to fix a problem he found. Since we can have more than one submodel we need more than one "count" property. The new code creates a property systems/submodels/submodel[n]/count for each submodel. Vivian is using this count property for his sound.
2004-08-26 12:27:39 +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
// end of submodel.cxx
Add the missing buoyancy patch.
2004-09-01 21:05:04 +00:00
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
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: 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