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

334 lines
10 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>
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
const double SubmodelSystem::lbs_to_slugs = 0.031080950172;
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
SubmodelSystem::SubmodelSystem ()
{
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;
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
}
SubmodelSystem::~SubmodelSystem ()
{
}
void
SubmodelSystem::init ()
{
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();
_serviceable_node = fgGetNode("/sim/systems/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: 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
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
SubmodelSystem::bind ()
{
}
void
SubmodelSystem::unbind ()
{
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
SubmodelSystem::update (double dt)
{
David Culp: Here is an update for the submodel system. This will allow submodels to be defined for any aircraft, and there are no default submodels. To use this submodel system you need to set up a binding (slight change in property name from last one, but you can use any property name you like, as long as it matches the name in the submodels.xml file, see below): <button n="0"> <desc>Trigger</desc> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">true</value> </binding> <mod-up> <binding> <command>property-assign</command> <property>/systems/submodels/trigger</property> <value type="bool">false</value> </binding> </mod-up> </button> Then in your *-set.xml file you need to define a path to the configuration file (similar to the way the electrical system is now done): <sim> ... <systems> <electrical> <path>Aircraft/Generic/generic-electrical.xml</path> </electrical> <submodels> <serviceable type="bool">true</serviceable> <path>Aircraft/FW190/submodels.xml</path> </submodels> </systems> ... </sim> Then you put the submodel configuration file in your aircraft's directory. I've attached a file, submodels.xml, that can be used to define a gun that works just like the former one did. There are two things remaining to be done. One is to change the function SubmodelSystem::transform() to properly position the submodel. This will require some complicated matrix code that I might borrow from Yasim.
2004-08-26 08:38:43 +00:00
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 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
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
SubmodelSystem::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
{
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
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
FGAIModelEntity entity;
entity.path = sm->model.c_str();
entity.latitude = IC.lat;
entity.longitude = IC.lon;
entity.altitude = IC.alt;
entity.azimuth = IC.azimuth;
entity.elevation = IC.elevation;
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
entity.roll = IC.roll;
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
entity.speed = IC.speed;
entity.eda = sm->drag_area;
entity.life = sm->life;
entity.buoyancy = sm->buoyancy;
entity.wind_from_east = IC.wind_from_east;
entity.wind_from_north = IC.wind_from_north;
entity.wind = sm->wind;
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
entity.cd = sm->cd;
entity.weight = sm->weight;
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
ai->createBallistic( &entity );
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
SubmodelSystem::load ()
{
int i;
SGPropertyNode *path = fgGetNode("/sim/systems/submodels/path");
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;
}
}
int count = root.nChildren();
for (i = 0; i < count; i++) {
// cout << "Reading submodel " << i << endl;
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
SGPropertyNode *prop;
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;
SGPropertyNode * entry_node = root.getChild(i);
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 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->cd = entry_node->getDoubleValue("cd", 0.295);
sm->weight = entry_node->getDoubleValue("weight", 0.25);
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;
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
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 = fgGetNode("/systems/submodels/submodel", i, true);
sm->prop->tie("count", SGRawValuePointer<int>(&(sm->count)));
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
SubmodelSystem::transform( submodel* sm)
{
Vivian Meazza: Testing revealed that the code was not reading y-offset - a typo in the original code, and roll was in the wrong sense. All readily fixable, and it now works.
2004-09-07 19:10:10 +00:00
// get initial conditions
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: 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.mass = sm->weight * lbs_to_slugs;
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
SubmodelSystem::updatelat(double lat)
{
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
Copy permalink