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.
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.
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>
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.
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.
