Posts by Jet-Pack (IPACS)

The performance shouldn't be impacted at all by this. Even if you send a couple hundred messages to aerofly it should handle just fine.

It may get very complicated to animate the hands though and will require quite a lot of work probably

Hi,

Well you can't directly talk to the human animation via dll but what you can do is send messages to the aircraft's physics simulation. These messages are being received all the time, e.g. by your joystick input or key presses, etc. From the aircraft's standpoint your dll is seen the same as a clickspot interaction with the mouse or the same as a button or key press or joystick movement.

The tmd file of the aircraft in question will have to be modified (text editor) and you have to add a message receiver. These are called e.g. "input_lever", "input_switch", "input_control", etc. They keep the last value received from the player interaction and hold it for the physics simulation (e.g. target for the actuator, etc.). You then output that data to the graphics via "output" or "output_free" objects.

Inside the DynamicObjects section add this:

            <[input_control][HandPosition][]
                <[string8][Input][YourExternalDLLMessageNameHere]>
                <[tmvector2d][Range][ -1.0 1.0 ]>
                <[float64][Value][0.0]>
            >
            <[output_free][HandPositionOutput][]
                <[string8][Input][HandPosition.Output]>
            >

On the graphics side (above the human graphics) a graphics_input has to be added, along with a graphics transformation.

            <[graphics_input][HandPosition][]
                <[string8][InputID][HandPosition.Output]>
                <[float64][Scaling][0.1]>
                <[float64][Offset][0.0]>
            >
            <[graphics_translation][HandRotation][]
                <[string8][Input][HandPosition.Output]>
                <[tmvector3d][Axis][ 1.0 -1.0 0.0 ]>
            >

This creates a transformation matrix that can be used by the bone model of the human graphics.

Inside the "Pose" of the human_graphics object you need to find the right bone to animate and just "give it" the input transform "HandRotation.Output".

I've taken the C172 and just replaced the throttle hand animation with the "HandRotation" from above.

Once you see the human model hand "do something" as you change your external dll message value then you have mastered the first step.

            <[graphics_human][Pilot][]
                <[string8][GeometryList][ PilotBody PilotHead ]>
                <[uint32][PositionID][Fuselage.R]>
                <[uint32][OrientationID][Fuselage.Q]>
                <[uint32][ShowInside][CameraCopilot CameraRearSeat CameraRearSeatSide]>
                <[bone_array][Bones][]
                    <[bone][element][0]
                       <[string8][Name][Bip01]>
                       <[tmvector3d][R0][ 0.0000 0.0000 0.9233 ]>
                       <[tmvector3d][X0][ 0.0000 -0.4418 0.0000 ]>
                       <[tmvector3d][Y0][ 0.4418 0.0000 0.0000 ]>
                       <[tmvector3d][Z0][ 0.0000 0.0000 0.4418 ]>
                    >
...
                >
                <[bone_array][Pose][0]
                    <[bone][element][0]
                       <[string8][Name][Bip01]>
                       <[tmvector3d][R0][ 0.7025 0.2278 -0.1222 ]>
                       <[tmvector3d][X0][ 0.4332 0.0000 0.0871 ]>
                       <[tmvector3d][Y0][ -0.0000 0.4418 -0.0000 ]>
                       <[tmvector3d][Z0][ -0.0871 -0.0000 0.4332 ]>
                    >
...
                    <[bone][element][91]
                       <[string8][Name][Bip01 R Hand]>
                       <[uint32][Parent][90]>
                       <[tmvector3d][R0][ 1.0618 -0.0457 0.0455 ]>
                       <[tmvector3d][X0][ 6.7418 0.8041 -0.6737 ]>
                       <[tmvector3d][Y0][ -1.4215 8.0747 -4.5872 ]>
                       <[tmvector3d][Z0][ 0.2566 4.6730 8.1462 ]>
                       <[string8][InputTransform][HandTransform.Output]> // previously ThrottleTransform.Output
                    >

I can assist you with any tmd questions along the way. But I haven't experimented with the external dll myself other than the example project with sends aileron and elevator signals, which is the same concept as what you are trying to do here. But I can't help you with "how do you get the data from leap motion into the external dll"

As we stated in the past, the external dll was never meant to support motion platforms and we made some optimizations to reduce the amount of data being send through to the dll in order to improve the connection to other external apps like FSWidgets that internally use a similar interface and share some of the code (as far as I'm aware). I'm not familiar with the implementation details myself, so please forgive me if I'm wrong here.

We are really sorry that this also affected already existing motion platforms but we weren't aware how many actually already existed at the time. We usually make these sort of optimizations before the feature is ever released to the public. That is one reason why we don't show off everything that we work on all the time. It get's people excited but if we decide not to release the feature the disappointment is also huge. In this case we took away an unofficial/unintentional feature which affected the already released product. We'll try and be more careful in the future to not accidentally release unintended features that may brake with future updates.

As mentioned above you can still interpolate between the individual messages that you receive and still have the option for a smooth motion platform without jerkiness if the receiving code doesn't just output the received data one-to-one to the motion platform. There may be a delay, yes.

Hm... we already have virtual hands visible for the usual hand controllers and I think it would create a conflict if we decide to add support for the leapmotion hands. This is not a aircraft specific feature and you would basically have to modify each aircraft and all of each aircraft's repaints to support this globally. And it would have to override the default aircraft files in order to work which is not ideal because after each small update on our side it could just wipe out these changes. And if we make an update to the options files you'd also have to change them... I'm afraid that's not going to work long term.

At the moment there are only very few examples of the option.tmc being used for something other than repaints. This is not an official feature yet because the menu is not part of the sim yet. But the internal file structure and loading of the option.tmc is working. One example is the Learjet 45 which uses it to change the fuel unit for example but it's an independant option, not bound to a repaint.

If I get time in the next couple of days or next weekend I can document the new option.tmc feature in our wiki.

There is no example of the options.tmc combined with the use of the external dll since this is the first time this is requested.

I guess the first step could be that you copy one aircraft, e.g. our default C172, to your user documents and then use the messages that the external dll sends to aerofly, physics inputs, physics outputs, graphics inputs and finally graphics transformations to animate the hands of the human model that is visible on the pilot seat when you switch to the copilot seat. If you get even one thing moving from your external dll via tmd over to the human animation then you can basically expect that the same concept works with the option.tmc.

What would you like to do with this?

In theory this should be possible with the option.tmc (per aircraft repaint/option) that were added a while ago. But I haven't tested that myself. In theory this option can be bound to a aircraft repaint (you could copy the default one) and it enables you to load additional models when the aircraft is initialized.

If you want to create a sort of knee-board, this should work. A map or chart rendering is probably not possible, other than what's already in the executable.

When it tips back on the tail the cg is just too far aft or the 3d model is incorrect and the wheels should be further back.

The ground interaction in Aerofly FS is done with simulated wheels as well as collisionhulls (that use the actual geometry).

What exactly is the issue?

Instead of marketing each aircraft as being able to reach cold and dark we would rather get every aircraft up to that level. We're talking about default aircraft here and not add-on products. It should be a uniform selection with similar features in all aircraft.

The oculus window has to stay in the background as far as I know.

If you remove the "-othervr" it should use the steamvr. I don't think the start tag "-steamvr" is recognized, it may just ignore that and work as if you had no tag at all.

Give us some time to try and reproduce this issue.

From what I understand it is working for you now when you leave the oculus window open or when you start with steam vr?

OK, so you have two versions of Aerofly FS 2 installed on the same PC, Steam and DVD/direct download version?

They will likely write to the same user documents Aerofly FS 2 main configuration file and if either of them has a newer update this could cause issues on the other installation.

What happens when you delete the main.mcf file (see https://www.aerofly.com/dokuwiki/doku.php/simulator:mcf) and then launch the stand alone version in 2D, non VR. Does that work on its own? And when you then connect the headset and launch the stand alone VR version: what does the tm.log show you after the crash. Can you please upload that tm.log file (see https://www.aerofly.com/dokuwiki/doku.php/simulator:log) (as a .zip or as .txt) so we can have a look what goes wrong and where it crashes? Thanks.

Pretty much all Just Flight aircraft for Aerofly are capable of reaching cold and dark as far as I'm aware.

The Piper Arrows stick to the rules of our default aircraft in that the default configuration is "on". This means you can switch between the Arrow and our default aircraft in flight without loosing the engine and you can crash and immediately take off again where as the other JF aircraft don't allow this. They used the hack of creating a cold and dark tmd and then just turn systems on as you select the mid air start or approach or takeoff positions. Of course this enables them of start the aircraft cold and dark on the parking spot but if you restart the sim it could also be loaded mid air. And this could break other features, especially once we do add a cold and dark option from the menu or then we rely on the default aircraft configuration to be "on".

I'm pretty sure this was answered in the past but it may also have changed since then.

Aircraft that reach cold and dark state with electrics and engines fully shut down:

Q400 - yes

C172 - yes

B58 - yes

C90 - yes

R22 - yes

Bücker Jungmeister - yes

A320 - almost. Engines can't be shut down yet in the release verison
LJ45 - almost, engines and hydraulics to go, similar to the A320.

The A320 and LJ45 already have a full electric system that can be shut down. So the cockpit does turn dark when you kill the generators and batteries.

Aerofly FS 2 saves the screenshots in your user documents in the "Aerofly FS 2" folder. But I believe F12 is the screenshot key for Steam, I'm not sure where Steam saves the files but in steam when you click on Aerofly you have a "Screenshots" link on the right with a link to "Manage my .... screenshots".

In that pop up select "shot on disk"

Well the quickest one is with the mouse...

There is no setting for this but I never had the feeling this was too slow. What device do you use?

That would be the copilot interface and the button that you circled in red is the "increase speed" command. The copilot then either manually takes the throttles and flies that speed or it uses the autothrottle selected speed for this.

The copilot does some internal calculations for the minimum and maximum speed it "wants to fly", so if you keep pressing the button or hold it down it will stop at some point depending on flaps, etc.

"little plane above"?
Are you talking about the copilot interface in the lower right corner of the screen?

The autothrottle of the A320 works pretty much as in real life. So if you think that's not correct then please contact airbus directly

The approach category cannot be selected, it is purely a result of the selected approach type, the airport infrastructure (e.g. ILS at the runway you want to land at) and internal system integrity checks such as availability of ILS receiver, etc. This category can increase up to CAT3 DUAL when both autopilots are engaged. But you don't select this manually and it also doesn't affect much. It certainly doesn't affect the selected speed.

When you push the approach button on the flight control unit (FCU) you arm the selected approach. This could be the ILS localizer and glide slope or a managed approach like a GPS approach. But this button should not directly affect the speed either. You have to push the speed knob in to tell the autopilot to use the automatic speed or pull it out in order to select a speed manually.

When landing with flaps 3 you have to select this in the MCDU as well as in the overhead on the GPWS panel. You can manipulate the approach speed on the approach performance page, yes. The field is called VAPP if I remember correctly from the top of my head.

Make sure to check out our official wiki for the Aerofly FS A320 flight tutorial.

Aerofly runs just as fast in HDD, SSDs mainly affect loading times. But since we load everything in the background it's barely noticeable. And once everything is loaded there should not be any performance difference what so ever.

I haven't found out why exactly this is happening. The fuel system implementation is not final and this bug is a result of this.

To me it looks like the origin of these objects is incorrect but they have been modeled to still be on the ground with the default mesh?

To explain this again:

If you use autoheight true then all objects are shifted up and down by the terrain mesh that is loaded. The object origin is moved up and down according to the elevation at that point. If your object origin is not underneath the object the same code is still executed so you are requesting the elevation somewhere else which probably isn't the same elevation underneath the main part of your object geometry.

Multiple objects should remain as individual objects and should not be grouped together. Otherwise you will see some objects floating.