Posts by Jet-Pack (IPACS)

    Actually I found that the slider 100% is not even far enough for some days. There are days where you can see very far!
    E.g. I've seen the alps from over 100km away at 2500m high up on several days.

    And if you are at cruise altitude on an airliner you might be able to see thunderstorms some several hundred miles away. Or at least I've seen a CB when we flew over Frankfurt and I could still see it as we were descending on the approach into Berlin. That's roughly 300+ km of visibility. This works because at this high altitude the horizon line is also that far away plus you get the extra 10km of height of the CB... So from the ground you couldn't see it but from up high, yup.


    And I eventually want to see weather that far out in Aerofly. It would be mind blowing to fly towards a thunderstorm for more than an hour and see it getting bigger and bigger on your wind screen until you are just the tiny little airplane underneath it. Would also be cool to see some flashes of light at night.

    My throttle problem (Saitek quadrant) is a little different. When controlling twin jets, the in-sim aircraft throttles do not move in unison. Generally, throttle/engine 1 is sluggish or sticks and I have to move it over the range to bring it in line with engine 2. Retard is fine as both sticks actuate the reverser switches, However, when reverting to forward power the throttles do not keep together and cause a drift from centre on the runway.

    This problem does not manifest itself in P3D, XP 11 or Flyinside Simulator, and the control set-up in AFS2 shows both axes moving in tandem.

    Can you please double check that each of your axes is just controlling one input in aerofly?

    Delete all throttle assignments and then reassign each axis.

    If you click on your saitek quadrant in the list of the control devices in the control settings, are all of the axes well calibrated? Do they "stick" on this settings page, too and do they move in unison there? If no then a calibration of the device in Aerofly could fix that; if yes then we'll have to investigate further.

    The download speed depends on your internet provider and the Steam servers, both of which we can't affect from here :)

    Just let it run overnight or pause the download, shut down the computer and then resume it later.

    If you compare it to shipping the DVDs.... well 8 hours is not that long, is it :D

    You can't execute the dll directly from visual studio. Just build the dll and then start aerofly like normal.

    Edit: I just downloaded the sdk, opened the solution in visual studio, in the solution explorer: right click on the project, select properties, change windows SDK version to highest I had, left everything else like in the sdk, OK.

    Clicked Build - Build Solution.

    Then opened steam, started Aerofly from there and up comes a new window that shows all the messages being send to the external dll.

    So I can confirm this still works!

    Great. So no mass reduction and no engine cut out but for perestain 's pilot journey it would be fit for purpose to stick a fuel level into the tsc before launching fs2 and there could be a penalty for the fuel low light coming on e.g. Emergency landing/recovery/repair.

    Yes you can just change the fill level in the tmd file (tsc is for scenery only) and if you are really brave you then manually pull the mixture out and try to glide it in. But the cessna doesn't actually glide all that well, so yeah. good luck with that LOL

    Looks more like a countdown timer to me. It has no relation to anything you do. Right now the 'visual fuelflow' is more some sort of gimmick. As said before, once it hits zero the times stops but you simpy keep flying. There also is no change in weight which is why you can so easily skip a part of flight using the Location screen: your weight at arrival will be the same as your take off weight anyway.

    This is not correct, its not just a countdown, we actually simulate fuel flow and fuel pressure on the each of the fuel lines and also simulate fuel valves, etc.. (see my post above)

    To clear up a few things here...

    - The fuel flow in the Cessna (and Learjet and A320) is physically simulated, that means yes, the fuel decreases over time, depending on how much is actually consumed by the engines. We also simulate fuel pressure on the fuel lines, fuel valves and fuel pumps. When you look at the A320 fuel ecam page and turn off the fuel pumps you can see some drastic changes.

    - Fuel mass currently stays constant, so no change in weight and balance as of today.

    - Engines currently don't cut out when the tanks are empty, which was implemented as a safety precaution because the code for the fuel tanks was quite new at the time. We have to simulate the engine actually sucking in fuel and then starving off when no fuel flow is received. But with a little bit of faking it should totally be possible to cut the engine when fuel tanks are empty. But we don't want to fake that, so the engine just continues running.

    - The mentioned posting of mine with the "fuel used" value, well that is just the value on the display, that is running a simulation of the fuel flow and then calculating the fuel used from that, this is similar to what real airliners do. They can measure the fuel level directly but have to do all kinds of tricks to account for pitch attitude, temperature and pressure changes. So actually integrating the fuel flow is still done in modern airliners as far as I know. But again, this is just a display value, such value won't impact the engines or weight even if we are at a point where we simulate weight loss...

    Now to the initial question... :)

    Hello,

    I found out that the low fuel warning in the C172 never illuminates so I've played around with the settings in the TMD file and had to change the logic condition from 0.01892705 to 16.01892705 to finally see the warning below average 5 gallons.

    Just wanted to let you know.

    Code
                <[logic_greater][LeftFuelLow][]
                    <[string8][Input0][16.01892705]>  //<[string8][Input0][0.01892705]>
                    <[string8][Input1][LeftFuelTank.Output]>
                >

    Also, I have a question for Jan Jet-Pack (IPACS) : is there a way to calculate a random value for the fuel fill level?

    Code
                // 26 Gal avgas with 0.780 kg per l avgas
                <[fuel_tank][LeftFuelTank][]
                    <[float64][MaximumQuantity][76.768]>
                    <[float64][FillLevel][0.22]> --> random formula with result between say 0.30 and 0.80
                    <[string8][InputPressure][LeftWingFuelLine.Output]>
                    <[string8][AddFlow][LeftWingFuelLine.AddFlow]>
                >

    I think I meant to use the fuel tank fill level, not the actual fuel quantity. Right now the logic_greater is comparing 1.8% to the fuel quantity in kg, that can't work! :D So you're change is correct here, it should trigger either when reaching 16kg (roughly 5gallons) or it should trigger at 1.8% fill level.

    Randomizing the fill level is currently not possible. The tmd would be the wrong place for that. This would be added when we implement weight and balance for all aircraft and then you might see a menu option to randomize payload and or fuel.

    All units are SI units, which is a good thing, because you don't need to remember "ah fuel was in this or that uni". No, all is SI:

    Fuel Flow is kg/s, 0.01 means 0.01kg/s or 0.6kg/min or 36kg/h (just converting seconds to hours here)

    n1 is fraction from 0.0 to 1.0, multiply that by 100% and you get your typical n1 readouts in percent... 0.7 would be 70%

    Fuel used is not a physical property of the aircraft, that is why there is no fuel used per default. If you look into the a320.tmd you will find an integral that sums up the fuel flow over time to give you the fuel used. With the fuel flow being in kg/s and the time being in seconds this gives you fuel used in kg (which we can only do because of the SI units! otherwise we would spend all computing power on unit conversions)

    Vertical speed would be in m/s,

    Altitude in meter,

    Speed in m/s,

    Ground speed in m/s,

    Rotation speeds in rad/s

    Rotation angle in rad,

    Mass in kg,

    Fuel in fuel_tank in kg,

    All lengths in m,

    Area in meter squared,

    Pressures in Pascals,

    Time in seconds,

    Power in Watts,

    Thrust in Newtons,

    Voltage in Volts,

    Amperage in Amps,

    Resistance in Ohms,

    Heading in rad measured from E going counter clockwise (mathematically positive direction),

    Use <[float64][IdleFraction][0.01]> to change the idle percentage, e.g. <[float64][IdleFraction][0.65]>

    But then it may start rolling =O

    Our engine model may not be flexible enough for that but we plan to change the engine model once we tackle engine start.

    As we posted several times in the past: we did not forget about the mobile version and with every day that we work on the desktop version we also improve the next mobile version since they share a lot of the code. We usually don't give any sort of estimation regarding the "when" question.

    Does this impact on the flight characteristics or is it a visual thing.

    It does, yes. We believe that the physical deflection should equal the optical deflection, everything else would be unrealistic. If you want less lift at the same deflection, there is a parameter for that. If you want more drag at the same deflection, there, again, is already a parameter for that.

    If you want to change just the visual angle you can do so with the AngleMax parameter. But if you look at your flaps from the side and actually measure the flap angle with like a triangle you should see a proper 45 degree angle. It might look too much but 45 degrees is a lot compared to other aircraft!

    <[uint32][InputID][FuelFlow.Output]> needs to be changed to EngineFuelFlow.Output since the name of the output is not "FuelFlow", its "EngineFuelFlow". You could of course also rename the output object to just "FuelFlow".

    To make your life easier you can also rename that "FuelFlowInput" object in the graphics section to just "FuelFlow" (but also rename all occurances in the graphics section like FuelFlowInput.Output)

    (0.0 0.0) (700000.0 5.0891) (1400000 10.178)

    That would be the mapping of the pressure gauge. For 1400000 pascals the angle is 10.178 rad or 583.15 degrees.

    This is the maximum reading on the gauge, so yes that is a high pressure :)

    These mappings work as linear interpolations, first figure is a tick on the input scale, second number is the output value for that input.

    So for an input of 0.0 output is also 0.0, for input 700000.0 output is 5.0891 and so on.