Jump to content

Huey's new performance profile discussion


Recommended Posts

So I've decided to make a set of posts here that are a bit different, educational, if you will.
First will be a post explaining the fairly straightforward process someone would go through to correct the performance of this module. (in simple steps)
Second will be a post explaining how you would go about profiling the performance of this aircraft entirely by yourself.

 

As a note, this is as much about HOW it would be done as it is about the ORDER in which it SHOULD be done. (if anything the order is the most important part as doing it in some messed up order would make it more difficult)
I'm not going to talk about what the flight model parameters actually look like or how the devs themselves would go about fixing it. Just general strokes of "correct this after checking this"

So how would we start fixing the performance?

Well first, torque calibration should be noted. The torque gauge in the huey was not perfectly accurate, and gave different readings in each huey IRL.
However, each aircraft was provided with an engine data plate, this plate included plenty of data, but the one piece we are looking for is the torque calibration factor.

How they measured this was fairly simple. What did the torque gauge read at 1125ft/lbs of shaft torque?
That's it.
Now, if at 1125ft-lbs of engine torque, the torque gauge reads 61.4449346228909 PSI, it would actually be perfectly calibrated.
In an ideal world, all hueys would have their torque gauge read this way, but they don't.

However this is a simulator. Some huey torque gauges DID read that way. So, calibrating ours to read that way would be a great first step to simplifying the process to fixing the performance.

TLDR

1125ft-lbs of shaft torque at 61.4449346228909 PSI of gauge torque would make our huey's power per torque line up with all of the performance metrics. This makes everything easier.

So where do we go from there? 

Next would be correcting the amount of power provided at different engine throttle settings.

This graph.
image.png

 

 

 


After that, we get into the fun stuff.


The next step would be correcting the tail rotor.
You might be wondering what effect the tail rotor has on the overall performance. In terms of authenticity and accuracy? Quite a lot.

The huey's tail rotor can draw upward of 170+SHP at full left pedal. This would change the torque gauge by 8PSI. Yeah, think back to the other graphs and how much 8PSI changes things.

First we need to understand how the tail rotor would be set up. How it would be rigged, if you will.
It is different for every aircraft, some have less total travel, others have more, but overall the balance should be the same.
image.png

Blade travel range is what you are looking at here,
Pedal full left, provides a blade pitch of -17.5 degrees
Pedal full right, provides a blade pitch of +8.9 degrees, yes you read that correctly, PLUS 8.9.
Pushing the right pedal all the way in should actually cause the tail rotor to push the nose to the right faster than torque alone can.

However, before EVEN THAT, we need to correct something else.
The gear ratios.
image.png

For whatever reason, in DCS the tail rotor to main rotor gear ratio is actually 5.5:1, you can test this yourself easily, the gear ratio doesn't change with RPM.
Go hop in a huey, set it to third person, and press the starter
Watch how many times the tail rotor rotates in the time it takes the main rotor to rotate once.

Fix the gear ratio, then rig the tail rotor.
Currently in the DCS huey, the full right position on the pedals actually draws the least power from the engine, this is incorrect.
The pedals should be neutralized (producing no thrust, thus drawing the least power) 66% from full left. IE to the right of the center position, but not all the way right.

From there the next step would be tweaking how much power the tail rotor draws. 170shp at full left should be sufficient.
Additionally, you would correct how much thrust the tail rotor provides in the same way we are about to correct the main rotor thrust, however the tail rotor seemingly doesn't actually produce thrust in DCS, only the relevant torque and anti torque forces.


After this would be correcting the lift generated by the main rotor at different power (collective) settings.
You might think this would be a difficult metric to determine, however, we have the exact data we need to make this an extremely simple affair.

This graph is a performance profiling of the huey in an OGE hover.
Out of ground effect means that the performance benefits of being near the ground are not a factor as the hover altitude is high enough that they do not affect the aircraft anymore.

This means exactly what you think it does. It means that the amount of thrust generated by the rotor is exactly the same as the mass of the aircraft.
A huey at 7700lbs hovering out of ground effect would be producing, you guessed it, 7700lbs of total net downward thrust.
This means the chart even takes into account the amount of downward force generated by the rotor pushing air against the body of the aircraft.

This graph is an EXACT representation of how much effective thrust the rotor generates for any given power setting. It also includes the position the pedals would need to be in as well.

image.png

 

But how do we read this chart? Well, with a little math, of course. I know, don't worry, the math is fairly basic.

image.png

I know, I know, the symbols look scary, but don't worry, they're just variables like A B C D.
Here they are.
image.png

Allow me to write it out for you.

Power Coefficient = ((SHAFT HORSEPOWER*550)/((0.02289013*PRESSURE INHG/(TEMPERATURE C +273.15))*1809.56*(((ROTOR RPM*2π)/60)*24)^3))*10^5

Thrust Coefficient = (TOTAL THRUST IN LBS/((0.02289013*PRESSURE INHG/(TEMPERATURE C +273.15))*1809.56*(((ROTOR RPM*2π)/60)*24)^2))*10^4

As a reminder, our atmospheric test variables are normalized to 15C and 29.921255347142inHg, and the huey tends to spin its rotor at 324rpm.

So, in these conditions, a total thrust of 7700lbs would produce a thrust coefficient of  26.99843261, and 780shp would produce a power coefficient of  18.47226921

Check those values on the graph, congratulations, you can now read the graph.

 

From there, it would be adjusting flight model parameters until the out of ground effect performance matched the graph. The rotor would then be producing the right amount of thrust for any given power setting.

Then the ground effect parameters would be tweaked so that they could match their respective graphs as well.
All 3 graphs are combined on this one.
image.png

 

 

 

Things get more complicated after this, and I apologize, but I am going to speed up at this point and make it even simpler.
With the rotor producing the correct amount of thrust while the aircraft is stationary, next comes correcting the amount of thrust while the aircraft is moving.

This is far more complicated as it not only involves dynamic airflow, but also drag.
As the helicopter gains speed, the rotor begins to produce more thrust for any given power setting. At 60knots true airspeed the rotor is the most efficient, it takes the least amount of power to keep the aircraft flying at this speed.

Effectively, correcting this would just be adjusting the parameters that determine aircraft drag and the amount of thrust gained from forward flight.

However, this is not something easily detailed. It is also effectively impossible to profile in DCS as an end user.
While, for the hover chart, we could assume that the thrust coefficient was equal to the total weight of the aircraft. This is not the case for forward flight.
In forward flight, the thrust coefficient involves an unknown variable we can not reliably obtain, cable tension. In the hover chart, this variable was easily predicted to be zero, however forward flight requires more thrust than the total weight of the aircraft. We cannot determine that in a simple manner. However, the developers should be able to.

From there would be correcting the rate of climb per horsepower, however, with all the other parameters corrected, this SHOULD fall into place on its own.

Lastly would be correcting the performance at different altitudes, however at this point, you get the idea. Check the data, compare it to how it performs in DCS, adjust the parameters until it's correct.

I'm going to take a break and come back at some point with a post about how you can profile all these parameters yourself where possible to the exact same degree that I have done for this thread. Potentially even higher.


Edited by Tim_Fragmagnet
  • Like 9
  • Thanks 5
Link to comment
Share on other sites

  • ED Team

Hi all, 

just to keep you all updated the team are making adjustments and the fuel issue is being addressed. 

thank you

  • Like 4
  • Thanks 6

smallCATPILOT.PNG.04bbece1b27ff1b2c193b174ec410fc0.PNG

Forum rules - DCS Crashing? Try this first - Cleanup and Repair - Discord BIGNEWY#8703 - Youtube - Patch Status

Windows 11, NVIDIA MSI RTX 3090, Intel® i9-10900K 3.70GHz, 5.30GHz Turbo, Corsair Hydro Series H150i Pro, 64GB DDR @3200, ASUS ROG Strix Z490-F Gaming, HP Reverb G2

Link to comment
Share on other sites

  • 2 weeks later...

Tim is a rockstar and has given amazing input here! And that was before I just looped back to see several new posts.

I saw notes for todays patch where we have two new WIP updates, but the wording did not seem very comprehensive…

Is this still being worked on? A ways to go I presume?

How are the improvements in this patch thus far?

  • Like 1

All modules & maps | VR only (5950x, 4090, Reverb G2)

Link to comment
Share on other sites

I have redone the fuel profile for the new update, and have compiled it into the main post. I will write up the post about how to profile everything within a few days

image.png

 

20PSI 1391lbs fuel 170 minutes.trk

30PSI 1391lbs fuel 139.5 minutes.trk

50PSI 1391lbs fuel 100.5 minutes.trk

 

 

 

Something feels off about the droop compensation, it feels far too weak now. I'll have to test that more.


Edited by Tim_Fragmagnet
  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

I'm going to open with this, I am not looking for perfection, I am merely looking for "Good enough".
Additionally, this is about the PERFORMANCE, model, not the flight model.
This is about making the engine use the correct amount of power and fuel for any specific flight profile.

So, profiling the huey. Where to begin.
Well I feel it prudent to start with the torque calibration factor once again. This isn't something you can profile, but understanding what it is allows you to understand the potential flaws in the current method of profiling.

So, what is the torque calibration factor. As simple as possible, this is the value the torque gauge reads while the engine is putting out 1125ft-lbs of torque. So why is it important? The Torque Calibration factor is important because ED has not provided one for our huey, and it is effectively impossible to determine as a client.

Therefore, we will assume a calibration factor of 61.4. As shown by the calibration factor chart, this provides a 1:1 representation of indicated to calibrated torque, what you see is what you get. 50psi, is 50psi. 

image.png

It is, however, still important to understand the implications of doing this. If our huey were tuned for a calibration factor of say, 66, our torque gauge at a reading of 50, would actually be corrected to a torque of around 43, a difference of 7psi. Conversely at a calibration factor of 54, 50psi indicated would instead actually be a real torque of well over 50psi.
However, as per the graph, this error gets lower and lower as the indicated PSI gets lower and lower. This means that to correct for an anomalous calibration factor, you cannot simply just shift the entire graph up or down. It would need to be adjusted for each datapoint. Additionally, note that the correction is always in one direction, if your calibration factor is above 61.4, your indicated PSI ALWAYS reads high, if your calibration factor is below 61.4, your indicated PSI ALWAYS reads low, it doesn't change throughout the range of torque.

However, all data for the real huey is presented in calibrated torque. So if we assume our huey has a calibration factor of 61.4, this would mean that the graphs generated through empirical tests should match up nearly identically with the real thing.

So.

Where do we begin?
First, here is the test mission.

Huey Test 15C 29.92inHg.miz

Lets start with the static tests.

Let's start with the fuel test, the goal here is to profile how much fuel the engine uses for any specific volume of power usage.
The method is actually fairly simple.
First, use the cargo trigger included in that mission file to add 10,000 weight (it's in kg) to the huey. This will prevent our aircraft from moving during this test.
Next, with the aircraft hotstarted on the ground, we raise the collective until we reach the desired volume of power (torque) we wish to test at. Then we time how long it takes for the engine to run out of fuel, you can use the F2 menu's time for this as the huey's clock isn't entirely accurate.
Then we repeat for multiple different volumes of power.

With our data gathered, we must process it so it is usable on our reference graph.

image.png

We must provide fuel use in pounds per hour in relation to the amount of specific shaft horsepower used.

We have the time it takes to drain all the fuel in minutes
We have the indicated torque required to drain the fuel in this time

Starting with turning the fuel to lbs/hour, that's actually fairly simple.
60/time in minutes, then multiplied by the total fuel load drained (max fuel is 1391lbs, max fuel will provide the most accurate data)
So (60/170)*1391=490.94lbs/hour


Now we will turn torque in to shaft horsepower.
Take the Torque in PSI and the Rotor RPM, and process those 2 pieces of data through this formula.

3.88*((10^-3*ROTOR RPM)*((17.76*PSI)+33.33))=Total Shaft Horsepower

Now that we have processed the data, we can plot it on the graph.
Do note, that formula is only for the UH-1H.


So, the next static test is the power/throttle profile, which can additionally be used to chart EGT data as well.

This involves checking how much power is provided for any specific volume of N1 on the N1% gauge.
Since you now already know how to turn torque and rotor RPM into shaft horsepower, this is simple.

Using the stationary huey, measure at torque values specifically marked on the torque gauge (20,25,30,35,etc) and then observe the N1% on the gas producer gauge. (this is more accurate than the other way around.)
While you are doing this, gather EGT data as well for each point you measure.

Convert the torque to shaft horsepower, and then plot the data on this graph.

image.png

Then using the EGT data you also gathered during this test, plot it on this graph.
Do note that this graph is in Fahrenheit so you have to convert C to F.

image.png


So, those are the tests that can be done without moving the aircraft.

Up next are the flight tests, we'll start with hover tests.


I will refer to the previous post for a more detailed description of the hover test and will simplify it here.

Simply put the aircraft into a hover at several different weights, and at heights of 2ft,5ft, and out of ground effect (over 60ft but ideally less than 100ft), and record the torque required at each point.

Process the data with these formulas. (you can obtain the shaft horsepower from the earlier formula to convert torque into shp)

Power Coefficient = ((SHAFT HORSEPOWER*550)/((0.02289013*PRESSURE INHG/(TEMPERATURE C +273.15))*1809.56*(((ROTOR RPM*2π)/60)*24)^3))*10^5

Thrust Coefficient = (TOTAL THRUST [gross weight for this test] IN LBS/((0.02289013*PRESSURE INHG/(TEMPERATURE C +273.15))*1809.56*(((ROTOR RPM*2π)/60)*24)^2))*10^4

And then graph the processed data on this graph.

image.png

With the hover data completed we move onto forward flight.

I have thrust coefficient graphs for the huey in forward flight, however they are unusable by us as clients for reasons stated in the previous post. So we will use the torque chart presented to us in the huey's operator's manual.

Specifically the sea level one, because if this one isn't correct, that means the baseline performance isn't correct to begin with.

We will also no longer be correcting for the 2 square ft of drag added by the IR suppressor, as not only does it not affect the flight model in any way other than weight right now anyway, we should profile the base, unmodified performance of our variant of the huey, in the same configuration it was profiled in for our data.

To do so is fairly simple.

In the F2 view during gameplay you are provided with a status bar at the bottom of your screen, within this bar is a measurement of your speed. By default it is set in IAS, however if you press CTRL+T it should toggle it to TAS unless you have rebound this.
All flight tests are measured in TRUE airspeed. Not indicated. Using the F2 meanue provides the actual TAS of the aircraft before any speed gauge inaccuracies are modeled.

Simply fly the aircraft at a bunch of different speeds and weights and record the torque for each condition.
Ideally you don't fly to a specific speed, instead you fly to a specific torque, as the torque gauge is harder to read, so using its marked points allows for more accurate data collection.

Multiple sets of data for the same condition can be done by restarting the flight and doing it again. This can help remove any outliers in the dataset.

Do not forget to use the unlimited fuel setting to prevent the data from being skewed by the reduction in weight from the fuel consumption during flight.
Additionally, do not forget to make sure the mission is not overriding the unlimited fuel setting, thus making your aircraft consume fuel regardless, without your knowledge of it doing so.

image.png


Up next, the rate of climb data.

This is obtained by flying at 55-60knots TAS at different power settings (torque) at a specified weight (7700lbs for this test), and then noting your rate of climb.
Interestingly, the data shows a minimum reduction in rate of climb at different altitudes, so it shouldn't matter up to 10,000ft
If you want to one up me in this area, record multiple sets of the data for different altitudes. Just remember to keep adjusting your flight to maintain your speed and torque.

image.png

Up next is the max power speed per altitude data.
While I could provide the data to derive the graph for this test, it's tedious and annoying, so I recommend just using the one I have already made. (it involves taking many tables of data and interpolating it)

The test is simple. At 7500lbs, fly as fast as you physically can in level flight at different altitudes. Ignore all restrictions, egt limits, torque limits, Vne, all of them. Crank the collective and go. If you can't keep the nose down, lower the collective, and flag that datapoint.

Here is the graph.

image.png

So where do we go from here?
Well for now, I'm sure you have enough to think about.



However I have some things to think about and process for myself


The data is probably for another thread.

 

But it does make me smile.

image.png

image.png

 

 



Until next time, keep that mind sharp.


Edited by Tim_Fragmagnet
  • Like 4
  • Thanks 2
Link to comment
Share on other sites

12 minutes ago, Tim_Fragmagnet said:

I'm going to open with this, I am not looking for perfection, I am merely looking for "Good enough".
Additionally, this is about the PERFORMANCE, model, not the flight model.
This is about making the engine use the correct amount of power and fuel for any specific flight profile.

So, profiling the huey. Where to begin.
Well I feel it prudent to start with the torque calibration factor once again. This isn't something you can profile, but understanding what it is allows you to understand the potential flaws in the current method of profiling.

So, what is the torque calibration factor. As simple as possible, this is the value the torque gauge reads while the engine is putting out 1125ft-lbs of torque. So why is it important? The Torque Calibration factor is important because ED has not provided one for our huey, and it is effectively impossible to determine as a client.

Therefore, we will assume a calibration factor of 61.4. As shown by the calibration factor chart, this provides a 1:1 representation of indicated to calibrated torque, what you see is what you get. 50psi, is 50psi. 

image.png

It is, however, still important to understand the implications of doing this. If our huey were tuned for a calibration factor of say, 66, our torque gauge at a reading of 50, would actually be corrected to a torque of around 43, a difference of 7psi. Conversely at a calibration factor of 54, 50psi indicated would instead actually be a real torque of well over 50psi.
However, as per the graph, this error gets lower and lower as the indicated PSI gets lower and lower. This means that to correct for an anomalous calibration factor, you cannot simply just shift the entire graph up or down. It would need to be adjusted for each datapoint. Additionally, note that the correction is always in one direction, if your calibration factor is above 61.4, your indicated PSI ALWAYS reads high, if your calibration factor is below 61.4, your indicated PSI ALWAYS reads low, it doesn't change throughout the range of torque.

However, all data for the real huey is presented in calibrated torque. So if we assume our huey has a calibration factor of 61.4, this would mean that the graphs generated through empirical tests should match up nearly identically with the real thing.

So.

Where do we begin?
First, here is the test mission.

Huey Test 15C 29.92inHg.miz

Lets start with the static tests.

Let's start with the fuel test, the goal here is to profile how much fuel the engine uses for any specific volume of power usage.
The method is actually fairly simple.
First, use the cargo trigger included in that mission file to add 10,000 weight (it's in kg) to the huey. This will prevent our aircraft from moving during this test.
Next, with the aircraft hotstarted on the ground, we raise the collective until we reach the desired volume of power (torque) we wish to test at. Then we time how long it takes for the engine to run out of fuel, you can use the F2 menu's time for this as the huey's clock isn't entirely accurate.
Then we repeat for multiple different volumes of power.

With our data gathered, we must process it so it is usable on our reference graph.

image.png

We must provide fuel use in pounds per hour in relation to the amount of specific shaft horsepower used.

We have the time it takes to drain all the fuel in minutes
We have the indicated torque required to drain the fuel in this time

Starting with turning the fuel to lbs/hour, that's actually fairly simple.
60/time in minutes, then multiplied by the total fuel load drained (max fuel is 1391lbs, max fuel will provide the most accurate data)
So (60/170)*1391=490.94lbs/hour


Now we will turn torque in to shaft horsepower.
Take the Torque in PSI and the Rotor RPM, and process those 2 pieces of data through this formula.

3.88*((10^-3*ROTOR RPM)*((17.76*PSI)+33.33))=Total Shaft Horsepower

Now that we have processed the data, we can plot it on the graph.
Do note, that formula is only for the UH-1H.


So, the next static test is the power/throttle profile, which can additionally be used to chart EGT data as well.

This involves checking how much power is provided for any specific volume of N1 on the N1% gauge.
Since you now already know how to turn torque and rotor RPM into shaft horsepower, this is simple.

Using the stationary huey, measure at torque values specifically marked on the torque gauge (20,25,30,35,etc) and then observe the N1% on the gas producer gauge. (this is more accurate than the other way around.)
While you are doing this, gather EGT data as well for each point you measure.

Convert the torque to shaft horsepower, and then plot the data on this graph.

image.png

Then using the EGT data you also gathered during this test, plot it on this graph.
Do note that this graph is in Fahrenheit so you have to convert C to F.

image.png


So, those are the tests that can be done without moving the aircraft.

Up next are the flight tests, we'll start with hover tests.


I will refer to the first post for a more detailed description of the hover test and will simplify it here.

Simply put the aircraft into a hover at several different weights, and at heights of 2ft,5ft, and out of ground effect (over 60ft but ideally less than 100ft), and record the torque required at each point.

Process the data with these formulas. (you can obtain the shaft horsepower from the earlier formula to convert torque into shp)

Power Coefficient = ((SHAFT HORSEPOWER*550)/((0.02289013*PRESSURE INHG/(TEMPERATURE C +273.15))*1809.56*(((ROTOR RPM*2π)/60)*24)^3))*10^5

Thrust Coefficient = (TOTAL THRUST [gross weight for this test] IN LBS/((0.02289013*PRESSURE INHG/(TEMPERATURE C +273.15))*1809.56*(((ROTOR RPM*2π)/60)*24)^2))*10^4

And then graph the processed data on this graph.

image.png

With the hover data completed we move onto forward flight.

I have thrust coefficient graphs for the huey in forward flight, however they are unusable by us as clients for reasons stated in the previous post. So we will use the torque chart presented to us in the huey's operator's manual.

Specifically the sea level one, because if this one isn't correct, that means the baseline performance isn't correct to begin with.

We will also no longer be correcting for the 2 square ft of drag added by the IR suppressor, as not only does it not affect the flight model in any way other than weight right now anyway, we should profile the base, unmodified performance of our variant of the huey, in the same configuration it was profiled in for our data.

To do so is fairly simple.

In the F2 view during gameplay you are provided with a status bar at the bottom of your screen, within this bar is a measurement of your speed. By default it is set in IAS, however if you press CTRL+T it should toggle it to TAS unless you have rebound this.
All flight tests are measured in TRUE airspeed. Not indicated. Using the F2 meanue provides the actual TAS of the aircraft before any speed gauge inaccuracies are modeled.

Simply fly the aircraft at a bunch of different speeds and weights and record the torque for each condition.
Ideally you don't fly to a specific speed, instead you fly to a specific torque, as the torque gauge is harder to read, so using its marked points allows for more accurate data collection.

Multiple sets of data for the same condition can be done by restarting the flight and doing it again. This can help remove any outliers in the dataset.

Do not forget to use the unlimited fuel setting to prevent the data from being skewed by the reduction in weight from the fuel consumption during flight.
Additionally, do not forget to make sure the mission is not overriding the unlimited fuel setting, thus making your aircraft consume fuel regardless, without your knowledge of it doing so.

image.png


Up next, the rate of climb data.

This is obtained by flying at 55-60knots TAS at different power settings (torque) at a specified weight (7700lbs for this test), and then noting your rate of climb.
Interestingly, the data shows a minimum reduction in rate of climb at different altitudes, so it shouldn't matter up to 10,000ft
If you want to one up me in this area, record multiple sets of the data for different altitudes. Just remember to keep adjusting your flight to maintain your speed and torque.

image.png

Up next is the max power speed per altitude data.
While I could provide the data to derive the graph for this test, it's tedious and annoying, so I recommend just using the one I have already made. (it involves taking many tables of data and interpolating it)

The test is simple. At 7500lbs, fly as fast as you physically can in level flight at different altitudes. Ignore all restrictions, egt limits, torque limits, Vne, all of them. Crank the collective and go. If you can't keep the nose down, lower the collective, and flag that datapoint.

Here is the graph.

image.png

So where do we go from here?
Well for now, I'm sure you have enough to think about.



However I have some things to think about and process for myself


The data is probably for another thread.

 

But it does make me smile.

image.png

image.png

 

 



Until next time, keep that mind sharp.

 

I know, right?

Link to comment
Share on other sites

Thank you for all your contributions Tim.

ED, any update here? Can we at least get an ingame checkbox that passes integrity check to use old model, or will this fully be resolved next update? I miss my Huey 😕

  • Like 2

All modules & maps | VR only (5950x, 4090, Reverb G2)

Link to comment
Share on other sites

Geeze - the Huey has become a fast boiiii..... 😅 

I had big troubles to slow it down after it accelerated to near stall speed in a blink. Feels ... weird.

I just flown the new FM for the first time after a while and some hours in the Gazelle. I have to admit - in comparison, something feels off.

  • Like 3

"Muß ich denn jedes Mal, wenn ich sauge oder saugblase den Schlauchstecker in die Schlauchnut schieben?"

Link to comment
Share on other sites

  • 2 weeks later...

I have cleaned up the torque/speed graph and adjusted it to represent the huey in a clean configuration. (If you don't want to model the huey as having its clean configuration performance, you shouldn't let us take off the IR suppressor.)
I have also extended the transmission limit data.

image.png

 

 

image.png


Edited by Tim_Fragmagnet
  • Like 5
  • Thanks 6
Link to comment
Share on other sites

Tim, you are awesome, thanks for your dedication to this. A lot of us LOVE the Huey and are bummed by the current state of things, and no doubt you are providing information quite helpful to getting it all sorted.

ED, I understand we are all on the open beta branch and this is part of the beta process! With that in mind, I am wondering if there has been further progress on getting this sorted out for the many passionate Huey pilots here?

  • Like 4

All modules & maps | VR only (5950x, 4090, Reverb G2)

Link to comment
Share on other sites

On 7/8/2023 at 5:27 PM, dsc106 said:

Tim, you are awesome, thanks for your dedication to this. A lot of us LOVE the Huey and are bummed by the current state of things, and no doubt you are providing information quite helpful to getting it all sorted.

ED, I understand we are all on the open beta branch and this is part of the beta process! With that in mind, I am wondering if there has been further progress on getting this sorted out for the many passionate Huey pilots here?

They already promoted this Huey work to the Stable version. Worse, it's from a version before they fixed the throttle-skids connection.

Link to comment
Share on other sites

14 hours ago, daniellegraham said:

I just updated the open-beta version, and I found that I need a way more left pedal(around 85%) for take-off than before.

Is that real in life?

Probably not. Tim probably has some data floating around indicating the tailrotor isn't producing enough thrust, among other things. If I understand correctly, ED is working with Tim to adjust things further.

  • Like 1
Link to comment
Share on other sites

On 7/11/2023 at 8:57 PM, SMH said:

They already promoted this Huey work to the Stable version. Worse, it's from a version before they fixed the throttle-skids connection.

What are you talking about? Last stable release was May 5, Huey new engine profile was introduced to open beta on May 18. Am I missing something?

  • Like 1

All modules & maps | VR only (5950x, 4090, Reverb G2)

Link to comment
Share on other sites

16 hours ago, daniellegraham said:

I just updated the open-beta version, and I found that I need a way more left pedal(around 85%) for take-off than before.

Is that real in life?

No it's a work in progress and currently way off. See above for how to put it back to how it was, at least somewhat. 

Oh, maybe you're right. I fly the OB so not sure. Could have sworn it was though, sorry.

Link to comment
Share on other sites

  • 3 weeks later...

After several updates with no Huey changes it's starting to feel like this effort has been abandoned. If so, could we please just roll it back to how it was before the DCS 2.8.5.40170 Open Beta - 18.05.2023 update? Again, it was FINE before, the ONLY issue was the RPM needles didn't split. (But it behaved as if they were split. It seems to be an instrumentation error only.)


Edited by SMH
  • Like 1
Link to comment
Share on other sites

15 hours ago, SMH said:

After several updates with no Huey changes it's starting to feel like this effort has been abandoned. If so, could we please just roll it back to how it was before the DCS 2.8.5.40170 Open Beta - 18.05.2023 update? Again, it was FINE before, the ONLY issue was the RPM needles didn't split. (But it behaved as if they were split. It seems to be an instrumentation error only.)

 

Been merged to stable now. What's that saying again about Open Beta being a test branch?

  • Like 3
Link to comment
Share on other sites

  • ED Team
1 minute ago, ColinM9991 said:

Been merged to stable now. What's that saying again about Open Beta being a test branch?

Stable means just that, it is stable. We look for crashes that will stop gameplay. 

The work on the UH-1H will continue and when ready will be patched. 

thanks

  • Like 1

smallCATPILOT.PNG.04bbece1b27ff1b2c193b174ec410fc0.PNG

Forum rules - DCS Crashing? Try this first - Cleanup and Repair - Discord BIGNEWY#8703 - Youtube - Patch Status

Windows 11, NVIDIA MSI RTX 3090, Intel® i9-10900K 3.70GHz, 5.30GHz Turbo, Corsair Hydro Series H150i Pro, 64GB DDR @3200, ASUS ROG Strix Z490-F Gaming, HP Reverb G2

Link to comment
Share on other sites

  • 4 weeks later...

Then why did you patch it with work that clearly wasn't ready?

Please just put it back to how it was at the start of the year. This isn't an Early Access module, we shouldn't be having it removed from usefulness for major portions of a year.

  • Like 2
Link to comment
Share on other sites

23 hours ago, SMH said:

Then why did you patch it with work that clearly wasn't ready?

Please just put it back to how it was at the start of the year. This isn't an Early Access module, we shouldn't be having it removed from usefulness for major portions of a year.

As much as I might agree that the rollout has been half-baked, it is by no means "removed from usefulness".

It's actually a far more effective module now. Yes things are obviously wrong/janky, but in terms of utility it's been an upgrade so far.

Though I do understand the upset at the FM feeling very wrong atm.

  • Like 1
Link to comment
Share on other sites

19 hours ago, MoleUK said:

As much as I might agree that the rollout has been half-baked, it is by no means "removed from usefulness".

It's actually a far more effective module now. Yes things are obviously wrong/janky, but in terms of utility it's been an upgrade so far.

Though I do understand the upset at the FM feeling very wrong atm.

You realize they could make any module they wanted super-effective UFOs that defy the laws of physics, right? This is a simulator, not reality. But the goal is to simulate reality, not sci-fi.

Would the Mustang be more effective if it went Mach 2? Sure. Would that be what I fly a high realism-sim for? Nope!

  • Like 1
Link to comment
Share on other sites

17 hours ago, SMH said:

You realize they could make any module they wanted super-effective UFOs that defy the laws of physics, right? This is a simulator, not reality. But the goal is to simulate reality, not sci-fi.

Would the Mustang be more effective if it went Mach 2? Sure. Would that be what I fly a high realism-sim for? Nope!

Who told you about the secret Mach 2 Mustang project! Off to area 51 with you!

  • Like 2

i7 13700k @5.2ghz, GTX 3090, 64Gig ram 4800mhz DDR5, M2 drive.

Link to comment
Share on other sites

21 hours ago, SMH said:

You realize they could make any module they wanted super-effective UFOs that defy the laws of physics, right? This is a simulator, not reality. But the goal is to simulate reality, not sci-fi.

Would the Mustang be more effective if it went Mach 2? Sure. Would that be what I fly a high realism-sim for? Nope!

Yes, I was however responding to the idea that it was "removed from usefulness for major portions of a year". That hasn't happened at all.

Nothing in this sim is 100% accurate, far from it. But yes I understand the complaints re: the Huey as it's obviously not right as is. But also: It was VERY wrong before the update to the engine. So if accuracy is your major complaint, you can't really go back to the old FM either as that wasn't anywhere near accurate.

The current Huey is closer to accurate than the old one overall , as much as some won't want to admit it.


Edited by MoleUK
  • Like 1
Link to comment
Share on other sites

4 hours ago, SMH said:

Because it's glaringly wrong. You can't even keep it in ground effect (where it should naturally want to stay in). You just shoot up with boundless energy, needing nearly full left pedal deflection to counteract! It's ridiculous!

Weigh it down with as much as you can atm, that offsets it a bit. As a bonus you can/will hit 140 knots cruise when heavy enough.

Yes it feels wrong. But it's also clear at this point that the old model was waaaaaaay off. It might have "felt" better, but it wasn't a UH-1H, it was actually very significantly underpowered.


Edited by MoleUK
  • Like 1
Link to comment
Share on other sites

  • 1 month later...

I believe we’ve all been patient and at this point the delay on fixing this module is downright offensive.

I would have expected a fix within 1-4 weeks maximum, given that a fix could have constituted a reversion to the prior state until fully corrected.

There has been no word at all on forthcoming changes and it has essentially ruined my favorite module for several months now. I understand that some tweaks are indeed an actual improvement in accuracy, but the negative net effect has been thoroughly discussed and demonstrated.

  • Like 3

All modules & maps | VR only (5950x, 4090, Reverb G2)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...