I don't want to restart the arguments but I have created an issue on the bugtracker asking the devs to re-check this because I think it is still too sensitive for normal flight:
http://www.il2bugtracker.com/issues/230

The reason for posting here is to ask people to vote on it.

It is not a claim about what the cutout G figure should be, that is documented, it is a request for the devs to re-check the FM.

So please don't vote on it because you agree/disagree with the documented evidence. Vote on whether or not you think the devs should re-check it.

On a similar note I notice that once an engine cuts out you cannot restart it usually and have to deadstick somewhere. It this realistic? I know the Merlin had a Koffman starter but was that also required when using airflow to turn the engine over? Or is there a technique I am missing other that throttle 10% and purring 'i'

I recently found that the throttle had to be closed then cracked (mixture rich) before trying a re-start in the air. I have done this about three times. I also suggested it to someone on ATAG a few days ago and it worked for him.

GUYS if you feel the Merlin cutout is too sensitive you need to go and vote for the devs to review it. The vote is in danger of turning into a 'reds versus blues' for all the wrong reasons instead of a request for the devs to check it.
http://www.il2bugtracker.com/issues/230

I do not have an issue with over sensitivity of the cutout. Actually it almost feels like old IL2 to me.

What I miss is that we do no longer have the two stage cut out as it should be.

I have a question about the bug tracker.

I understand that some things in the FM and DM may seem far from what we expect. But to me it is perhaps a flaw of the FM or DM but not a bug. For me a bug is rather linked to a mistake in programming. I personally would prefer to have a bug tracker for the devs clear of contentious issues linked to FM and DM so that the devs get the real programming problems that need to be really fixed.

I suggest to separate FM/DM issues from bugs if you really feel that you need a sort of voting for FM issues.

PS: I have also some small concern about voting for FM/DM things a little bit (but expressed with all respect so please do not take offence). I understand that as a community we can help the devs by pointing out FM issues but shall we really have a vote on something on the FM that people FEEL to be wrong? This may quickly escalate to a blue vs red voting contest because quite a few people do - rightly or wrongly - have the FEELING that the FM of their favorite ride is undermodelled. I'd rather have a FM issue tracker open after the discussion has brought up some facts via documents for everyone to learn and make up their mind.

I vote negative just because this sentence. How you dare call them unfair, when You are who garbles the others votes? Ok then, just to understand: If the title says: "Merlin Engine: Negative 'G' cutout too sensitive.", the "NO" means: No, it isn't sensitive. Everything else is just bulls*it :evil:

As I explained in the bug tracker....

"OK, I accept what you say about the title. I should have named it "Request to devs to re-check the G value for the Merlin negative g cutout point", a bit of a mouthfull but that is what I am asking for as I described in my first post (in the tracker).

I think it is too sensitive and I want them to check it. Why would anyone not want something checked that someone thinks is wrong? I am not asking for a change of cutout g value, I just think the devs may have go it wrong given they are trying to create historically correct FMs using historical documentation, in this case setting the cutout point to about 0.1g - or is the historical data what your really arguing against?"

and as I said in an earlier Tracker post

"Why do I think it is too sensititve? Years of reading decriptions and reports which make me suspicious, plus I installed a G meter in the A2A simulations Spitfire 1a and my 'perceived vertical rate of change' necessary when pushing over to hit 0.1G in that aircraft is a world away from the same observation of the cutout point in CoD. And before you ask I did not compare it with A2A's actual cutout point but observed the rate of change of vertical direction necessary to hit 0.1G. It is not scientific but points to the CoD Merlins being too sensitive."

To my understanding the engine in question had a strongly modified carburretor, its functioning hence being quite different from that of the early spits. So not so useful to my understanding. If you believe otherwise please indicate the text sections that support your view.

I think comparing two flight simulators and saying that one is wrong because they differ is a bit uhm ... well, far far from any proof of whatsoever.

Stormcrow, I'm not offering that as proof (although two 'accurate' sim FMs should give a similar result), it was just a comparison which, among other things, makes me think it isn't correct.

I'm not trying to start a war. I'm just asking them to re-check it or perhaps even confirm that it has been looked at under the new patch. It was admitted before October 2011 that it was wrong, it was adjusted at the October 2011 patch and I think I read somewhere that it was set at 0.5G pending further work but I can't confirm that. In any case it just needs a response from the devs.

There's no need for some of the acrimonious reaction that occured in the tracker - and yes, I apologise for questioning the negative-voting 'blues' motives but it was a knee-jerk reaction to their tracker posts attacking this request and my perceptions instead of just expressing their view by voting on it and possibly even offering something to support their voting reasons. Their view (and tbh yours) that it is ok is no more valid than my feeling that it isn't. We can't prove it either way without a cockpit G-meter so we have to ask the devs.

I'm fairly sure it's wrong and I just want it looked at.

Actually I remember the discussion on the cut off behaviour in its release state very well. In fact the devs never said that the g levels were wrong but they understood that the way it was implemented led to some oversensitivity. BTW back then the concern was merely that turbulences were enough to cause the first stage of cut out. So the devs eliminated basically the first stage of cut out completely while it actually should have been there. To my feeling (as you put forward your feelings I may too) they just should have removed the instant first stage cut out due to turbulences by putting in some inertial behaviour of the first stage cut out to render it more insensitive to small to medium turbulences.

I also do thing that the current cut out is not over sensitive.

BTW I do not understand what you expect them to do. You want them to check the g level from which cut out occurs. So you want to know the number and that's it? Or do you want them to make it less sensitive whatever g number they have used? If the latter is the case please provide some historic documents that supports your view that g level has to be improved.

First I don't think light turbulence would cause cutout - and that was confirmed to me by a current MkI Merlin III Hurricane display pilot - but in the release version it blipped continuously in level flight. Second, the documented data is in the Tracker, 0.1G cutout according to the Royal Aircraft Establishment who tested for it in the aircraft in 1940. Third there are a number of reasonable estimates of what the delay might be to cut and recovery including the opinion I posted way back from the Hurricane display pilot I mentioned plus buried away somewhere some documents giving an opinion at the time.

What do I expect them to do? What they said when they committed to as accurate modelling of FMs as possible by checking whether the documented data is incorporated into the flight model or if the FM is still using an estimated value for the last patch. Its that simple and I don't understand why anyone would want to say "No! Don't check it!" What is there to be afraid of? Either its correct or it isn't.

No amount of discussion here will answer this, only they know.

Why do I get no engine cut out at all? Some setting that I have somehow missed?

Make sure all relevant engine settings (CEM especially) are on.

IIRC in the release version cut-out was at 0.5 G and was reduced to 0.1 G with a patch. Luthier stated these values.

There is way to much "feeling" in bugtracker issue. I think it should be possible to get the G force using a mission script to verify the values. It's possible to log the position (x, y, z), speed and the time, should be enough to calculate the G forces, shouldn't it?

Someone should collect the reference material to find out at which value the engine should cut. Someone else should test the implementation by doing flight test and calculate the G force.

Then we have something to compare and don't need to talk about feelings and opinions.

Thought I saw it posted somewhere around here that it was documented to happen at .9G?

"Someone should collect the reference material to find out at which value the engine should cut."

That data is given (linked) in the original Tracker request.

"Someone else should test the implementation by doing flight test and calculate the G force."

That is precisely what the Bug Tracker entry asks the devs to do.

I don't want to offend you but did you read the Bug Tracker entry and Description?

THANK you, Banks

there's this parameter
[Misc.: Machine Overload under Acceleration]
/// <para>Indicates overload in m/s/s.</para>
/// <para>Generic subtype (-1) shows accelerometer, being 0 under normal conditions;</para>
/// <para>Subtype 0 shows acceleraton along machine's X axis;</para>
/// <para>Subtype 1 shows acceleraton along machine's Y axis;</para>
/// <para>Subtype 2 shows acceleraton along machine's Z axis.</para>

if doing the test from level flight Z axis should work ok- i've got it reading to a 'speedbar' atm but only in integers (that's all i needed:rolleyes: )

Yes it is.

Am I missing something here (I haven't bothered reading the whole thread everyone in here is too cantankerous) or are people expecting the Merlin flooding problem to turn on and off at a particular G setting like a switch ?

As far as i recall the flooding was not instant and neither was the recovery, anecdotally the flooded Merlin engines would eventually clear and self restart if still spinning, but certainly not instantly.

IIRC the document stated "reduction of 0.9g" so it meant 0.1g. But I don't have the document, I think it was posted from IvanK.

0.1G is the documented value. Though changes were made I don't believe it is at this value in the FM yet. All I believe that was changed was the actual "effects" side of the cutout. A 0.1G pushover is a LOT more than one would use in day to day type general flying .... like entering a cruise descent.

The source paragraph comes from the reference document in the UK national archives AVIA 13/234. The Devs have a complete copy of this document. The "G number line" is mine to illustrate how I think things should happen in game. Reference G in Straight and level flight is 1.0G.

http://i40.photobucket.com/albums/e2...NegGonset2.jpg

Interesting document. The G value given is likely correct but the suggested reason for cut out whilst not totally wrong only accounts for the initial momentary "splutter" the full cut out was for a totally different reason.

From Technical Order T. O. No. 02-55AC-2

"An idiosyncracy of the original SU carburetor was a condition known as "rich cutout" caused by negative g. In fact, the negative g cutout was a two-stage event. At the onset of negative g, fuel was forced to the top of the float chamber, which exposed the main jets to air. This caused the first, momentary lean cutout (Fig. 4.31). If a negative g condition continued, the floats reacted to the reverse of normal conditions and floated the wrong way, that is, they floated to the bottom of the float chamber. The needle valve opened wide, allowing full fuel pressure from the engine-driven pump to flood the carburetor. And excessively rich mixture was then admitted to the supercharger, causing the more serious rich cutout."


Note the two stage process over a period of time... which is why I was commenting that having the engine suddenly cut at a particular G figure is highly unrealistic.

I agree the 0.1g value is the ONSET only and we should be seeing a more complex event. The graphic is only a small excerpt from the original document. The original "style" of the cutout modelled in CLOD was better imo though starting way to early, and still does imo. A reasonable fix would be to take the original model which had depth (splutter to cutout etc) but have it starting at the 0.1g value.

I did some tests using a modified version of a script called BlackBox which I found elsewhere on the forums to capture the RPM cut and G value.

Chart is attached. It seems the cutout is set to 0.5G and seems instantaneous. You can see the 'highest' G-value cut, the third red line from the left. Others are just more examples. 0.1G it definitely ain't.

The chart shows RPM vs G-force and the G-cut is easily seen just before the characteristic RPM overshoot that occurs after it recovers.

You Merlin flyers need to vote on this unless its already in hand. Many very minor bugs and features have more votes than this.
http://www.il2bugtracker.com/issues/230

From an earlier discussion there was the conclusion that there is a two stage cut out, one arriving quite early the second later IIRC.

Up to know only one is simulated while it should be both.

Great work klem. Are you going to add this to the top section of the bug tracker report?...had a quick look but couldn't see it. Cheers.

yes alrdy discussed with even some kind of calculation.

Merlin flyer hve to keep in mind that flying was done a different way at the time (and nobody likes neg G).

Did the German had there an advantage ? Certainly. And this is why the allied took the efforts to cancel this by their own design. It's all abt BoB and post BoB.

This debate will be only legitimate if we were discussing a 1943 simulation.

Take it as it goes : as soon as your pushing the stick frwd your eng start starving -> RPM decrease slightly then rapidly -> eng sputter (single cylinder miss firing) then the carb is empty the eng stop -> traction vector is null, you feel instantly the drag that was compensated by the eng power (your pilot head shld lean frwd-> then the carb is full and cylinder flooded -> the eng rev is maintained by the prop and the air stream -> then eng restart -> Sputtering (rich condition) -> then back to normal.

Remember that at a time when fuel cells were not wallowed, pilots were used to experienced eng cut out while manoeuvring.

I really don't understand this debate. Change your habits pull and don't push... Easy. Damn nobody ask you to turn gay !

Great work Klem 0.5g was the original FM setting. As suspected the value has never been changed just the cut effects.

I really don't understand this debate. Change your habits pull and don't push... Easy. Damn nobody ask you to turn gay !

I think you are missing the point Tomcat. No one is disputing the phenomena just the onset. The fact is normal every day control inputs like setting up a cruise descent can result in the cutout they didn't in real life for such everyday piloting tasks .... it was referred even back in the day as "Negative G cutout or effect". All we are suggesting is getting the onset values correct.

"Take it as it goes : as soon as your pushing the stick frwd your eng start starving".... No only if you exceed a given threshold G. Stay below that threshold and you should have any 'negative" :) effects.

Thx to the doc you have provided, we hve alrdy computed the inner pressure in the carb and the fuel flow and see that the flow is impacted with even a very minor value of neg accel.

That is why the cut out effect start as soon as you are in condition where the load is < 1G. There is no physical delay unless it is very low (the 0.1G value). Of course the effects are marginal (slight rpm decrease). But here they are.

It's wrong to search for a magical number where you wld experienced a transition. It's simply progressive all around the 1G down to 0G load in an asymptotic way (1/x² as it's is a pressure value).

The question is now:

would, if the FM was set to cut out at 0.1g, the acceleration measured ingame at the same place as in RL corresond to 0.1g?

I do not know but I could well imagine that what is shown as 0.5g ingame as acceleration is something different from what was measured during the RL flight trials and might just not correspond to 0.5g in RL.

So perhaps the 0.5g could well correspond to the RL 0.1g case (tbc by devs). At least at this moment we cannot exclude as we do not know how the ingame acceleration is obtained.

Are we also sure that the ingame acceleration given is the acceleration in the symmetrical plane of the aircraft? or just a lateral acceleration hence including side forces?.

I agree that historically pilots did not just push the stick forward, they would bank and dive away in a diving turn (just like in the movies) or even split S.

However the complaints seem to be that the cutoff occurs even in normal flight.

Given turbulence or a vigorous transition from climb to level flight, it should occur.

A second related document is in the UK National Archives "AVIA 18/1281 Tests of RAE devices for the reduction of "Negative G" engine cutting on merlin engined fighter aircraft". This document details flight test data on 3 devices (Including the Schilling orifice ... though its called the RAE Restrictor .... PC in action back in the 40's).

It compares each of the devices to an unmodified aircraft. In the tables presented the G used to induce cutout are in the order of -0.5G up to -1.5G. Though emphasis of the document is on the time taken to recover from cutout rather than preventing it, despite the document title.

Given the document is not looking at specifically preventing cutout itself but rather minimising the time of the cutout it needs to be put into perspective when using it to decide on initial cutout values. However it is of interest (imo) that reasonable values of Negative G were used (i.e. significantly less than 0G) in all the tests.... i.e. not just smooth nose position changes.

In our discussion here we are only interested in unmodified systems. The jpg below is from the document referring to an unmodified or "Normal Fuel System" aeroplane

http://i40.photobucket.com/albums/e2...eggdevices.jpg

That document clearly states:

Pretty clear cut but I am surprised at the amount of time it took for the Merlin to recover, 6-10 seconds and averaging ~8 seconds.

No wonder the Luftwaffe makes note of the effectiveness of bunting.

Agree 100%

In the sim the engine will frequently cut out when making fine adjustments to trim in level flight -- which seems a tad excessive.

Its worth pointing out that the Shilling modifications (which involved more than just fitting the famous flow constrictor) main effect was to substantially delay the onset of the second stage flooding cut-off. The shilling orifice was a stopgap.

The "Shilling Orifice" did not actually fix the problem, just delayed its onset a few seconds. Sustained inverted flight was still impossible in a Shilling equipped Spitfire, that required a pressure carburetor.

What you need is a G meter. That does seem kind of excessive. I got the game and can check it out.

The chart I made is based on acceleration measurements taken from the game and are effectively a G-meter (accelerometer):
cur_Plane.getParameter(part.ParameterTypes.Z_Overl oad, 0); is acceleration in the fore/aft plane
cur_Plane.getParameter(part.ParameterTypes.Z_Overl oad, 1); is acceleration in the lateral plane
cur_Plane.getParameter(part.ParameterTypes.Z_Overl oad, 2); is acceleration in the vertical plane, renamed G-force on the chart.

At the moment of the 0.5G cut there were very small fore/aft and lateral g-forces of -0.04g and +0.02g respectively (slight speed reduction and slight sideslip). Its close enough to indicate that the cutout occurs well before 0.1G.

Readings were taken every 300 mSecs. Unfortunately we cannot add instruments to the cockpit so we can only draw data from the game parameters.

Ok that already helps a lot. But I still do not know which point the acceleration provided by cur_Plane.getParameter(part.ParameterTypes.Z_Overl oad, 2) corresponds to (I assume z-axis here is body axis not lift-axis which should have to be confirmed by devs too). Does it really correspond to the acceleration measured by the g-meter in the flight tests that stated a 0.1g threshold for the second stage cut-out? It is important to make sure that we do not compare apples with pears.

Not to mention the engine cutting as you taxi out of a hangar down a tiny 6 inch slope. :)

Which begs the question: How ever did the a/c take off without having an engine quit at the wrong time? Airfields weren't exactly billiard table smooth.

The maddox parameters do not tell us but I assume it is through the CoG. I have to assume that the parameters returned by the game are those used by 1C in development.

As far as I know there is no historical data to identify the location of the accelerometer used in the 1940 tests but it seems reasonable to suppose it would be close to the CoG to aviod variable components like moment arms during rotation. As a repeatable reference it may not have been necessary to measure the g figure at the precise location of the carburettor bowl if the reduced/negative G were induced gradually.

Of course, rapid rotation would create a larger g force at a remote moment arm-end than at the CoG but if the accelerometers in the 1940 tests and the 1C model are both at the CoG then they are a reasonable comparison.

As you say the devs know the answers to this, ours is really a side discussion with proposals wildy varying from "any g reduction" to "-1.5 or more". I just thought readers would be interested to know what the game is telling us.

Is there a way to show the flown z-axis g load while flying, for instance in one of the windows? Would be great to do so for flight testing.

you can use a method such as this?
http://simhq.com/forum/ubbthreads.ph...ml#Post3347984

just change parameters to the one(s) you're interested in

I think this is one of my first posts here, but I came to the forum for just this reason. Really enjoying Cliffs of Dover now but this is a real spoiler.

I am finding the engine cuts when taxying out of a hangar. I don't think the RAF or Rolls Royce would accept an engine that cuts out so easily that it can't even make it out of a hangar.

There has to be something wrong with it for this to be the case. I haven't read all 25 pages because I would lose the will to live, but is there any news about and developments in relation to this issue?

Cheers,

OD.

They've only forgotten to put a quarter second delay before the onset of the cutout.

...and it cuts at 0.5G instead of 0.1G