• Hi Matt,

    If you need help crossing the bridge I'll be happy to help. To me the TMD is a playground. If you have never developed an aircraft for any of the other simulators then it is probably way easier to get into it. Otherwise you first have to unlearn how you think it works. The tmd itself is actually a very clean construct, it doesn't assume anything, it just does what you tell it to do. That can be overwhelming but also very empowering. To say it with the voice of today's children: its super OP.

  • Thanks Jan... if I succeed in getting that far I will no doubt need your kind assistance. At the moment I'm grappling with trying to learn how to use AC3D and things are at a very early stage. I tried the trial version while I had some time over the holiday and quite liked it, so I bought myself a copy. I've been 3D modelling for years (FSDS, 3DCanvas and MAX) but AC3D has its own quirks so no doubt it will be a steep learning curve.

    Matt

  • Hi Matt

    My biggest gripe with the TMD file is the lack of reference material, sure we have examples in the form of the other aircraft but no explanations. For example..we have

    <[output_free][AutopilotARMOutput][]

    or

    <[output][AutoThrottleActive][]

    So whats the difference between output and output_free, we also have

    <[sender][SenderSelectedAltitude][]

    just to add to the mix.

    There are many many more examples...A simple set of explanations for the most widely used would be a great help. I'm currently trying to get the autopilot up and running, all the example aircraft use push buttons, even the trusty old Cessna but the Starfighter uses switches and rotary knobs.

    Don't get me wrong, I actually like shouting at the TMD file and its great when things work in the sim, as a non programmer it just takes me far too long.

    If your thinking of making an aircraft then go for it, when you sit there in VR and look around the cockpit you have built its very rewarding and you'll say many times..

    "I MADE THIS" and :)

    Steve

  • Hi Steve and happy new year,

    the output sends a value from the physics thread to the graphics and sound threads. These have to be declared since only a minimum of values from the physics are actually observable in the graphics, most physical states just change how it behaves, not so much how it looks in a single graphics frame.

    Code
                <[output][ThisNameIsImportant][]
                    <[string8][Input][ThisCanBeAny.OutputThatCouldBeNonStandardOutput]>
                >

    It would be used whenever you want to keep the original name of the value like for a lever or for a discrete knob etc.

    The output_free does the exact same but does not alter the name of the variable.

    Code
                <[output_free][ThisNameIsIrrelevant][]
                    <[string8][Input][ThisNameIsTakenInstead.Output]>
                >

    I only use this if I have to, e.g. when one object has multiple outputs or non standard outputs. E.g. a jet engine would have .N1, N2, FuelFlow, etc.

    The sender is a completely different story. It sends values to the outside of the aircraft, e.g. to the external dll, to saitek panels, to external autopilot displays, to the simulated copilot and so forth.

  • Hi Jan

    Thanks for the reply and a happy new year to you too.

    I have noticed the Autopilot's are 1 of 3 types at the moment, namely Autopilot, autopilot_advanced and flight_controller_f18. Are these the only ones the sim recognises. I have tried to insert somethings from one into another and the sim spits out an error of the wrong type. The Starfighter has an autopilot which is more than the basic but not as advanced as the other 2.

    I am inclined to use the basic autopilot but can't find a way of setting mach as an input. The Starfighter autopilot simply has, mach hold, altitude hold and heading hold

    Steve

  • Hi Steve,

    Yes, these are the three types of autopilots in Aerofly. Only the advanced autopilot currently has a mach hold function.

    If you are really brave you can program an autopilot in the tmd file. You'll need three variables for the target speed, altitude and heading. Then you can use a mixlinear to create the difference of target minus is-value, scale that difference, send it to the actuators. When you also use an integral then you have your own PI controller.

    You could also use the basic autopilot for heading and altitude hold and then just create a feedback loop with the tmd to create a mach hold function. Or leave the mach hold open for later.

  • Hi Jan

    I have added Kormaron missiles to the Starfighter (Practice missiles of course to conform to IPACS over 4 year old policy as stated by Jeff elsewhere :)), I added the following dynamics entries

    <[rigidbody][LeftInnerPylon][]

    <[rigidbody][LeftKormaron][]

    <[multibody_joint][JointLeftWingLeftInnerPylon][]

    <[multibody_joint][JointLeftInnerPylonLeftKormaron][]

    I assume I link the Kormaron to the inner pylon and not the wing. Is this correct

    Steve

    Edit Do I also need to add aero entries for the Kormaron

  • Hi Jan

    Any chance you could explain the following entries from the UHF Frequency Display in the MB339.TMD


    <[tmvector2d][TargetPosition][ 28 200 ]>

    <[tmvector2d][TargetSize] [ 48 90 ]>

    <[tmvector2d][TargetScale] [ 512 512 ]>

    <[float64][TargetStride] [ 56 ]>

    <[tmvector2d][SourcePosition][ 0 896 ]>

    <[tmvector2d][SourceSize] [ 64 96 ]>

    <[tmvector2d][SourceScale] [ 1024 1024 ]>

    <[tmvector2d][SourceDotSize] [ 16 24 ]>

    <[float64][SourceStride] [ 64 ]>

    <[int32][DotPosition][12]>

    <[int32][TargetDecimalStride][6]>

    <[int32][TargetDotOffset][-4]>

    Also, I am unable to convert display_color.bmp when running the converter, report says the texture is not used but it is assigned, all others in the material convert fine, any ideas

    Thanks

    Steve

  • Hi Steve,

    the texture animation basically copies a rectangle section from one source texture to the target texture. The rectangles for the source and target are specified as scaled UV coordinates. For the scale we typically use 1024 or 2048, this means the ...Size and ...Position can be interpreted as pixels.

    In your example we copy a rectangle section with the lower left corner at x=0 and y = 896px (measured from the lower left corner of the source texture) and a height of 64px and a width of 96px from the source texture to the target texture position. The target texture is defined in the texture_animation which we usually call "DisplayTexture. In the "RenderList" for that target texture all the .Render draw calls are executed one after the other and each of the different displays draws either its texture animation or custom draw code like for the glass cockpits displays.

    When the source is a texture with numbers on it you can iterate through several positions and sample the source texture depending on the input. The offset between the numbers is the stride, there is a stride for the source and target. SourceStride means how far did you space the numbers on your source texture and TargetStride defines how far they should be placed on the target texture.

    The integer DotPosition is the number you have to multiply the stride with to get to the pixel coordinates of the decimal dot on the texture.

    The TargetDotOffset shifts the dot on the target texture left and right.

    TargetDecimalStride defines the gap of the decimal dot

    Regarding your texture converting issue: as far as I know you can assign the display source texture to a cube or some other blank object and it should convert just fine, even though your cube or canvas will not be used as a geometry in the tmd file. You could also temporarily assign it to some material to get it to convert.

  • Hi Jan

    Big thanks as always for the reply. The missing bit was using the lower left corner :D, now it makes sense

    I now have a moving map :), would like to be able to dim the map but coding so far refuses to do this. Will tackle the UHF repeater tomorrow. Does the HUD use a similar method. Not being able to see any of the HUD textures is a big drawback trying to understand things.

    Glad to say the "too do" list is getting smaller :thumbup: Still need to work out why the Starfighter nose gear bounces off the floor when the aircraft comes to a stop. Almost like the c of g is too far back making the nose too light.

    Managed to get the texture converted by placing it in the DR400

    My thoughts are turning towards the next project, mmmmm, something I have always wanted to model...perfection

    Steve

  • Hi Jan

    Is there a way to input a negative logic_range. I can get the stab light to illuminate between the positive range but unfortunately this is down trim so I need a negative range for up trim. Have tried a logic_invert prior to the entries, thinking this would invert the pitch trim as its only for a light and no light shows at all, if I do a logic_invert after the logic_range I get the light on up and down except for the 0.1 to 0.3 in down.

    <[logic_range][PitchTrimLightRange][]

    <[string8][Input][PitchTrim.Output]>

    <[tmvector2d][Range][ 0.1 0.3 ]>

    >

    <[multiplexer][PitchTrimLight][]

    <[string8][InputSelect][PitchTrimLightRange.Output]>

    <[string8][Inputs][ PitchTrimLightRange.Output OnGroundSensor.Output ]>

    >

    <[output_free][PitchTrimLightOutput][]

    <[string8][Input][PitchTrimLight.Output]>

    >

    Thanks

    Steve

  • Steve have you made the materials such that bare metal or silver paints are viable? and will a PSD paintkit be available?

    Lynx... ooh that would be good! When deciding what to build as my first AC3D project I did toy with the idea of a Westland Scout/Wasp but figured a Helicopter was a bit ambitious for a first.

    Matt

  • Hi Matt

    Still working on some texture maps, specular and reflection should allow bare metal. Finishing up the switches, just autopilot left, (and there have been oodles of them), then a final blast at the textures, paint kit to tidy up and oh yeah, sounds.

    Light at the end of the tunnel

    Steve

  • Hi Jan

    What is so special about buttons

    When ever I try to use a button as an input the code fails to find the button output. If I use the same code using a switch for an input it works just fine.

    Why do some buttons use an "input_active' before the output and others don't

    Steve

  • Hi Jan

    What is so special about buttons

    When ever I try to use a button as an input the code fails to find the button output. If I use the same code using a switch for an input it works just fine.

    Why do some buttons use an "input_active' before the output and others don't

    Steve

    The input_button has no physics output, just an automatic output to the graphics section. And it can trigger sounds but that is it.

    If the button should toggle something (on/off), then add the button and add a second thing: an input_binary -> output can be used in dynamics

    if the button should step through something: add a separate input_discrete -> output can be used in dynamics
    if the button should light up a lamp while it is depressed: use a separate input_active -> output can be used in dynamics

    if the button should perform some form of event: use a separate input_event -> calls other events, has no output either but can beform some one time action to change a state

    We do this to keep the logical function of the button away from the button itself. The button itself should be stupid, just moving into the panel when pushed and moving back out when released. The function it performs is not actually created by the button itself. In the real aircraft there is some computer chip that registers that an electric connection was made and that chip then performs a digital function. So yeah. Our input_button doesn't actually do much. All the effects of the button push are covered by logic elements like the input_binary, input_discrete, etc.

  • Hi Jan

    Still struggling with my fire test button coding

    I have 2 Fire annunciators. I would like to be able to press either one of these (through a hidden button behind each annunciator) to activate a simulated fire test system. The coding below allows me to press the right hand one and the annunciators light up, pressing the left turns them off. Pressing left first does nothing. This I would expect as it's coding to transfer from one to the other

    If I input different names in each input_button from the controls.TMD, either will turn them on but nothing turns them off.

    I guess I am barking up the wrong tree but I have tried discrete, active and event and they do not even light things up.

    Put me out of my misery PLEASE !!!!! =O=O

    <[input_button][FireTestButton1][]

    <[string8][Input][FireTest]>

    <[float64][InputValue][0.0]>

    >

    <[input_button][FireTestButton2][]

    <[string8][Input][FireTest]>

    <[float64][InputValue][1.0]>

    >

    <[input_binary][FireTest][]

    <[string8][Input][FireTest]>

    <[float64][Value][0.0]>

    >

    <[output_free][FireTestOutput][]

    <[string8][Input][FireTest.Output]>

    >

    Edit, Forgot to add, if I just use a single input_button and output this to my annunciators they both come on when the button pressed and go off on button release, so I know it can be done, for one button anyway :(

    Steve

    PS, I guess this topic is fast becoming a TMD wiki ;)

  • Try something like this:

    <[input_button][FireTest1Button][]

    <[string8][Input][FireTest1]>

    <[float64][InputValue][0.0]>

    >

    <[input_button][FireTest2Button][]

    <[string8][Input][FireTest2]>

    <[float64][InputValue][1.0]>

    >

    <[input_active][FireTest1][]

    <[string8][Input][FireTest1]>

    >

    <[input_active][FireTest2][]

    <[string8][Input][FireTest2]>

    >

    <[logic_or][FireTest][]

    <[string8][Inputs][ FireTest1.Output FireTest2.Output ]>

    >

    <[output_free][FireTestOutput][]

    <[string8][Input][FireTest.Output]>

    >