Hi Steve, alpha maps require a png format or tif or other formats that have a transparency.
Posts by Jet-Pack (IPACS)
-
-
Display More
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. -
Hi Steve, Did you export the model into the tgi format again? (I'm assuming you have, you just haven't mentioned it probably)
After the export do you see any tm.log errors from the exporter?
-
-
-
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.
-
Do I understand this correctly: You want to switch from the DVD version over to the Steam version and keep your DLCs?
As far as I know the two contributors Valve and Aerosoft don't share user data or licenses or purchase IDs, so this is probably not possible.
-
50 cm in front of a monitor
Recommended distance is higher though. And who knows if he is flying in VR, could be only a few cm
-
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
-
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
-
That's why I zoom in a lot more in aerofly. It feels a lot more realistic that way
-
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?
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! 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.
-
The jump in fuel flow when the afterburners kick in.... well what defines an afterburner? You basically dump lots of fuel into the hot exhaust gases... So I would expect a sudden increase in fuel flow (its a feature not a bug)
-
Hi Jan
Once again thanks for the help
I now have working RadAlt, Oil pressure, EGT, FuelFlow (sort of as it jumps from 50% to 100%), N1, Nozzle position and VSI. Just fuel and hydraulics and that's the simple stuff done.
It's very frustrating, time consuming and dis-heartening not knowing what units the gauges work in and how little information there is available, for instance, fuel flow seems to be a percentage going from 0 to 1. I would have thought this would have been in kgs/hour or Kgs/min. Is this why the sim fails to record fuel used as it doesn't know what units to use. There was very little wrong with the code but even after inputting your correction it still failed to work until I saw it just move at full power, after much time and effort I finally realised it was a percentage. Lots of time wasted
I would also like to access N2 rather than N1 as N1 seems to give strange values but the sim fails to find N2. The idle speed is currently 10% when it should be 65%, don't see any way to adjust this. Engines in fast jets don't have N1 or N2, that's the domain of bypass and free turbine engines, they just have %RPM
Steve
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
Our engine model may not be flexible enough for that but we plan to change the engine model once we tackle engine start.
-
Sadly, the tm.log is not available if you don't have an accout at the aerosoft forum...
Same here... HiFlyer, if you are registered in the aerosoft forums can you please kindly ask him to post his problem as a new thread here in the ipacs forums?
-
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!
HI Jan
Yet more TMD questions whilst taking a break from vertices pushing
I managed to get the Vario to work so pushed on with a simple gauge, or so I thought. Have I mentioned I hate programming and the TMD file
This is the entry you placed in the TMD file for me.
<[output][EngineFuelFlow][]
<[string8][Input][Engine.OutputFuelFlow]>
>
I added this entry in the GraphicObjects section after the vario entry but the needle remains much like me, fat-dumb-happy and refuses to move
// Fuel Flow
<[graphics_input][FuelFlowInput][]
<[uint32][InputID][FuelFlow.Output]>
>
<[graphics_mapping][FuelFlowMapping][]
<[string8][Input][FuelFlowInput.Output]>
<[tmvector2d][Map][(0.0 0.0) (45.3 4.188) (90.71 5.759) ]>
>
<[hingedbodygraphics][FuelFlowNeedle][]
<[uint32][PositionID][Fuselage.R]>
<[uint32][OrientationID][Fuselage.Q]>
<[string8][GeometryList][ FuelFlowNeedle ]>
<[uint32][InputAngle][FuelFlowMapping.Output]>
<[tmvector3d][Axis][ -0.9659 0.00000 0.2588 ]>
<[tmvector3d][Pivot][ 6.0680 -0.2487 0.3323 ]>
<[float64][AngleMax][1.00]>
// <[string8][InputIllumination1][InstrumentLighting.Output]>
// <[string8][InputIllumination0][PanelLighting00.Output]>
>
The flow is 45.3 kg/min at 4.188 radians and 90.71 at 5.759 ( fill afterburner I assume)
I can follow what should happen but no idea where it all breaks down
Steve
<[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.