Jump to content

"Request Repair" prerequisite triggers unreliable - "shut down your engine" conditions arbitrary


rogorogo

Recommended Posts

The "Request Repair" interaction in the ground crew section of the quickcomm menu is all to often followed by a:
"No can do - shut down your engine" 
(is it really "no can do" or is my recollection playing tricks on me" 🙂 ?)

-> when the engine is shut down, the fuel feed valves closed, the rotor brake on, the pump groups set to off and even the batteries and shaft generators turned off.
Over time I have isolated the issue to - in most cases - the engine throttle.

Explanation.
I have my engine throttle on my throttle quadrants top-wheel (it is never used, except for raising it to 100 on startup, since we do not have engine degradation). Even when putting the throttle (the wheel) back on the zero-state (in my case the neutral middle position "0" of the "wheel slider) DCS does either still register an input (with both Windows and Logitech software showing a zero and no input stutter) or some other logic trigger condition is not met.

That despite the engine being off, the fuel system shunted, the disc arrested and the rotor brake on and even the electrics closed down.

And while this in itself is - once again - a control input bug worthy of admonishemt and attention (and will not receive the latter) this can be a real nuisance when trying to do a "repair" instead of a gamey "respawn", further degenerating the multiplayer environment.

Mitigation:

More reliable trigger logic, please make up your mind what the actual necessary presets are, which are entirely undocumented.

While trigger checks like the rotor-brake make sense and may or may not be a boolean check, the engine throttle does not, moreso as there is a multitude of issues with input reliabily and input translation in general (see fe one variant of the pitch oscillations, various variants of trim bugs, added inputs, random control overrides, not-hardware related sudden input-stuters aso aso aso aso aso...) - so please reduce the prerequisites to the absolute safest and sensical minimum when there is no ambition to cohesively and coherently improve and go forward.

Track file:
https://drive.google.com/file/d/1rmY6RnfWXIMLTi7wAldJXfvGX89-Jov5/view?usp=sharing

Random trackfile for random realistic bug occurence, only the last 120 seconds of trackfile need to be paid attention to, showing a random occurence. As trackfiles are completely unreliable too (for how many years now ?) I hope the issue is correctly shown when the track is reviewed on a random system.

I do not run screenvideos as I have no application for them, also the "need trackfile" is the constant response and seemingly the only evidence accepted (instead of actual clientside logs, or at least a QR code based log in the track).

Link to comment
Share on other sites

For me, regardless of throttle setting or anything else. I only get repair trigger when RPM is exactly zero and EGT near ambient. It may take about 45 seconds for engines to full go to zero RPM. Manual says it takes 40 seconds to go from idle to 3% RPM upon shutdown. In my experience DCS is spot on for this figure. So until then, it’s registering engine as on

Be thankful it’s not real life where engines have to run at idle for 1 minute in summer and 2-3 minutes in winter for even cooling before shutdown😉

Another tip, turn off APU well before landing. If APU is on or shut off during landing, It may take another minute or so before it’s also at 0 RPM and ambient EGT. So make sure it’s always off before landing the same way you turn it off before takeoff, and you will reach quickest time to repair trigger by shutting of engines on ground. 


Edited by AeriaGloria
  • Like 1

Black Shark Den Squadron Member: We are open to new recruits, click here to check us out or apply to join! https://blacksharkden.com

E3FFFC01-584A-411C-8AFB-B02A23157EB6.jpeg

Link to comment
Share on other sites

vor 6 Stunden schrieb AeriaGloria:

For me, regardless of throttle setting or anything else. I only get repair trigger when RPM is exactly zero and EGT near ambient. It may take about 45 seconds for engines to full go to zero RPM. Manual says it takes 40 seconds to go from idle to 3% RPM upon shutdown. In my experience DCS is spot on for this figure. So until then, it’s registering engine as on

Be thankful it’s not real life where engines have to run at idle for 1 minute in summer and 2-3 minutes in winter for even cooling before shutdown😉

Another tip, turn off APU well before landing. If APU is on or shut off during landing, It may take another minute or so before it’s also at 0 RPM and ambient EGT. So make sure it’s always off before landing the same way you turn it off before takeoff, and you will reach quickest time to repair trigger by shutting of engines on ground. 

 

well.. and there is the reason actual bug-reports have to be extensive, and given how they are received and treated by the product provider, and under what conditions they have to be produced, less and less actual reports get gestated.

That is all well meant advice - but given that I have monitored the issue since day1 of ea-release, any fidelity can be disregarded.
That I never have the APU on in flight unless under very specific circumstances is a purely subjective me-issue (aka irrelevant) - but as for the actual bug, further clarification is needed.

Bug was encountered and tested with - among other conditions - also:

  • APU never running during sortie
  • APU shut down after landing
  • instrumentation full zero, soundboard full zero before shutdown of electrics
  • fail-condition message present after 5-10 minutes on pad (fe while making a beverage and a sandwich)
  • step-by-step shutdown of relevant systems, then random modules with decreasing relevance
  • various maps and weather conditions, temperatures
  • various damage states
  • various pad types
  • airfields

as for any real life references, I was under the impression that my original bug-report had made clear that they are topically irrelevant as clearly none of them remotely applies.
-> the reliable single reproduction is a INPUT (peripheral) engine throttle non.zero state or a failed condition despite INPUT (peripheral) engine throttle state (as monitored by 3rd party peripheral software and OS).

Any fidelic considerations thus  - again - can be disregarded as the bug would manifest nonetheless and also bugs have zero to do with design decisions, especially if that blatant in manifestation. So please - while constructive, productive, well intended - do not confuse the occasional glancer (the few that are left) with a topic that is - despite its suitability - unrelated to the technical actual bug.

 


Edited by rogorogo
Link to comment
Share on other sites

1 hour ago, rogorogo said:

well.. and there is the reason actual bug-reports have to be extensive, and given how they are received and treated by the product provider, and under what conditions they have to be produced, less and less actual reports get gestated.

That is all well meant advice - but given that I have monitored the issue since day1 of ea-release, any fidelity can be disregarded.
That I never have the APU on in flight unless under very specific circumstances is a purely subjective me-issue (aka irrelevant) - but as for the actual bug, further clarification is needed.

Bug was encountered and tested with - among other conditions - also:

  • APU never running during sortie
  • APU shut down after landing
  • instrumentation full zero, soundboard full zero before shutdown of electrics
  • fail-condition message present after 5-10 minutes on pad (fe while making a beverage and a sandwich)
  • step-by-step shutdown of relevant systems, then random modules with decreasing relevance
  • various maps and weather conditions, temperatures
  • various damage states
  • various pad types
  • airfields

as for any real life references, I was under the impression that my original bug-report had made clear that they are topically irrelevant as clearly none of them remotely applies.
-> the reliable single reproduction is a INPUT (peripheral) engine throttle non.zero state or a failed condition despite INPUT (peripheral) engine throttle state (as monitored by 3rd party peripheral software and OS).

Any fidelic considerations thus  - again - can be disregarded as the bug would manifest nonetheless and also bugs have zero to do with design decisions, especially if that blatant in manifestation. So please - while constructive, productive, well intended - do not confuse the occasional glancer (the few that are left) with a topic that is - despite its suitability - unrelated to the technical actual bug.

 

 

Sure, but it does appear to be a DCS wide attribute that engine must be at 0 RPM for repair to commence. Does it not?

 

  All I was meaning to say, is the amount of time it does take for the engines on board to completely shutdown, as that’s the message received in game, to “shutdown the engines.” Any peripheral bound to the throttle anyways would not completely shut down the engine at 0% either. 
 

   Perhaps I misremember other modules, but I don’t think it has ever been an instant “ground crew will perform repair” the moment after engine goes below idle, requiring time to completely spool down. Not to mention, there does seem to be a bug lately where repair will just never be performed and you never see a countdown despite getting a “copy,” which can cause issues unless you re slot

   Anyways, I am just saying my understanding of how the system work across all DCS modules, and that the Mi-24 has no reason to be special in this regard. If you wish for this change DCS wide, that may be Another matter entirely. If this is the bug where it flat out doesn’t occur despite 0 RPM and ground crew saying “copy,” Hopefully this track is able to help ED fix it 

  If your wish is for repair timer to start before 0 RPM, and ED responds to your wishes to change this for Mi-24, it would effect all modules. As there was a reason it was initially coded this way, I’m sure they wouldn’t do so without a justification 


Edited by AeriaGloria

Black Shark Den Squadron Member: We are open to new recruits, click here to check us out or apply to join! https://blacksharkden.com

E3FFFC01-584A-411C-8AFB-B02A23157EB6.jpeg

Link to comment
Share on other sites

I had that issue for the first time yesterday at RotorHeads server.

Landed damaged at FARP, switch off as per checklist (o% RPM both engines, 0% rotor and APU off), switch all switches off (except those fuses/breakers). After a minute or so of "No can do - shut down your engine" and switching on and off I managed to get the "copy" confirmation.

It looked like a bug for me. Maybe something to do with the engine that was damaged in flight and that I turned it off, closed it's fuel valves and turned off it's generator in flight. Just my 2 cents here but maybe DCS was expecting to me to turn both engines after landing and not to come for land with a already cold engine.

 

Link to comment
Share on other sites

4 hours ago, Sacarino111 said:

Hi.

A possible idea is to set a zero zone for the axel where the throttle is, so you can be sure the game  sees it as a "real zero" condition. If a slider, add some Dead Zone and X saturation as well.

Saludos.

Saca111

But that still wouldn’t change anything, the throttle only moves the engine from idle up to full auto. The individual ETL do exactly the same thing except going from idle, to auto in middle detent, to full at the end for each individual engine. Setting them at 0 or full doesn’t effect repair trigger at all. The engine can but shut off at any throttle position. 
 

The only thing that needs to happen for engines to die, is fuel supply to be cut. As long as that happens and engine RPM is 0, it doesn’t matter where your throttle, collective or any other controls are at. The only thing stopping you from repairing at a FARP/airfield of your coalition with the right vehicles would be the afore mentioned bug where the ground crew says copy but you get no timer 

5 hours ago, Quati said:

I had that issue for the first time yesterday at RotorHeads server.

Landed damaged at FARP, switch off as per checklist (o% RPM both engines, 0% rotor and APU off), switch all switches off (except those fuses/breakers). After a minute or so of "No can do - shut down your engine" and switching on and off I managed to get the "copy" confirmation.

It looked like a bug for me. Maybe something to do with the engine that was damaged in flight and that I turned it off, closed it's fuel valves and turned off it's generator in flight. Just my 2 cents here but maybe DCS was expecting to me to turn both engines after landing and not to come for land with a already cold engine.

 

99% of my flight experience in Mi-24 is on rotorheads, only place I’ve repaired. So don’t know if it might have to do weigh the scripts there, but I haven’t been able to view OPs track to see if they got “copy” from the ground crew and it just wasn’t mentioned 

  • Like 1

Black Shark Den Squadron Member: We are open to new recruits, click here to check us out or apply to join! https://blacksharkden.com

E3FFFC01-584A-411C-8AFB-B02A23157EB6.jpeg

Link to comment
Share on other sites

  • ED Team
On 4/18/2022 at 3:20 AM, AeriaGloria said:

Sure, but it does appear to be a DCS wide attribute that engine must be at 0 RPM for repair to commence. Does it not?

Correct this is the same for all DCS aircraft for a repair. 

@rogorogo

I am not seeing any issue here, the track replay may not play back correctly as you seem to fly into a tree and explode when I play it back, but for a repair to take place the aircraft must be stationary with 0 RPM 

thanks

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

vor 1 Stunde schrieb BIGNEWY:

Correct this is the same for all DCS aircraft for a repair. 

@rogorogo

I am not seeing any issue here, the track replay may not play back correctly as you seem to fly into a tree and explode when I play it back, but for a repair to take place the aircraft must be stationary with 0 RPM 

thanks

Well.. which is why trackfiles are not really - especially in the current state - feasible to gather logging for debugging. (trackfile was a random example - also that track spanned a long sortie with various interactions and no crashes, especially not in any trees)

Again another attempt to describe the bug in plain terms but beyond ambiguity:

  • damaged Crocodile module landed on pad (services available)
  • engines shut off, rpm at zero
  • engine THROTTLE at ZERO
  • fuel valves shut
  • pump groups turned off
  • rotor disc brake on
  • disc arrested (blade no longer spin)
  • electrics shut down
  • batteries shut down
  • systems shut down (on top of entire electrics and batteries off)

ground crew will reply with "no can do - shut down your engines" - for minutes, for tens of minutes and more.

Over time (observation span 1 quarter+) bug isolated to ENGINE THROTTLE.

Engine throttle (with everything else shut down, arrested, off and time passed) is not registered at zero, despite being at zero and input peripherals at zero (with no input stutter or input value detected by windows OS or peripheral software).

WORKAROUND:

Repeated throttling up and down (in a turned off Crocodile with arrested disc, shut engines, shut valves, shut electrics) and "request repair" until at attempt "x" of "y" ground crew will reply with "copy" (and timer later starts).

With throttle workaround successfull repair starts (as intended?) with engines off, fuel valves shut, first pump group off, rotor brake on and disc arrested but all electrics, systems and batteries running.

BUG MANIFESTATION:
bug manifestiation in conscious observation by me 2.7.6.13133-o-b to 2.7.11.22211-o.b

More detailed report and additional details as per other posts in the report.

Update:
new variant, potentially latent but now manifesting in over 50% of repairs in multiplayer scenarios per 2.7.11.22211-o.b -> after repair low hydraulic oil pressure warning, vanishing after startup, after takeoff random system failures, power outages and with working turbines and disc gradual loss of rotor rpm until auto-giro landing.

Conscious observation only with 2.7.11.22211-o.b - no separate bug report as not enough encounters for clear manifestation pattern.

Exemplary trackfiles could be provided - but see above (also again long, so only log-stamo of repair and post-repair flight relevant).


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

  • ED Team

We will watch for it in our tests, I will have the MP team watch for it. 

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

I would like to add that I experienced this exact problem yesterday.

My Mi-24 was in the same state as rogo's, and yet I could not repair, getting "no can do" for 5+ minutes before I gave up.

This is the first time I am encountering it, after flying the Mi-24 2-3 times a week since its EA release.

  • Thanks 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

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