DirtyFret

That is a good place to start. Teeter has compiled a comprehensive package that is easy to use. http://forums.eagle.ru/showthread.php?t=142996

Thanks for the honest and sincere update. I wish you the best as a team.

Nice job Teeter, I use your mod pack. Thanks for the hard work. May I suggest adding or even changing the credits for the GAU-8 Dispersion correction mod/tweak. The correction method was discovered and presented by Flagrum and would be nice if he was credited for it. I just packaged his solution into a JGSME format. THanks

Thanks Devrim. That is a pity . Although the "neck" that this gives us really shines only in the fighters imo. That being said, I actually have no problems in the Mi-8 (all seats work fine) with this "neck" and problems only in the Huey. Rather oddly, the UH-1h is on the supported list in the first post of this thread but not the Mi-8. P.s. I am flying the Mi-8 with your cockpit mod Devrim, thanks for that

Hey , I am having a small issue with this mod in the UH-1h. It totally destroys the view from the co-pilot seat (see pic. attached). I did a DCS repair and removed all mods apart from this and the problem persisted. Removing the "neck mod" corrects this issue. My problem is that this mod is ABSOLUTELY AWESOME with every other module I own. Any ideas/solutions how to fix this issue in the Huey would be much appreciated. THanks

Thank you for taking the time and watching them. :thumbup: I 100% agree with you, without extensive testing there is no way of knowing why this odd behavior is seen and what is the cause. This exactly what I was hoping I have done with the .trk files and the vids I posted earlier.:smilewink:

Well this got interesting. If someone is in doubt about the validity of Pistons claim I would politely encourage them to watch the tracks I posted with actual the inconsistent cue behaviour and no weather/wind cockng of the rockets into the wind. The rockets deviate into the same direction as the MK82 and 30mm shells. The tracks show: The M151 rockets being affected by the wind in the same direction as other munitions The RKT cue behaving erratically; intermittenly correcting to the right and then suddenly to the left In my humble opinion there is little doubt that there is fault somewhere in the RKT wind correction. I have not been able to reproduce this bug in CCIP Bombing nor GUN mode( in other they work fine for me).

Absolutely fine with me although I have a sweet spot for accurate definition and description of an issue and subseqent evidence/proof of mentioned issue . Anywaysn - good job spotting this inconsistent behaviour :thumbup: P.s. if/when anyone sees this issue with CCIP bombing reticule , pls save a.trk a share it.

Ofc, but the chances of anything being done about a bug increase drastically if we can tell :"when you do X, you see Y" accompanied with hard evidence (.trk, screenshot, vid etc). I personally wouldn't want ED diverting any resource/debuggers/coders from their F/A-18,carrier ops, NTTR and DSCW2.0 teams to go on and trying to debug a huge amount of code lines (IFFCC, LASTE , CDU, winds, etc) without a solid description of the bug and what systems it afflicts and when. . just my 2 cents

You have a keen eye for details , whats not to backup :thumbup:, I haven't been able to cause the CCIP Bombing reticule to show wrong corrections. I do admit that I haven't tested it as extensively as the gun and RKT. Do you happen to have or .trk files so I could meddle with that too?

I've tested different (some ridiculous) hypotheses in an effort to pinpoint what suddenly corrects the behavior and then suddenly causes it to go awry but It seems completely random in preliminary testing. The only consistency that I found, is that the state(correct-to-incorrect) changes only when new LASTE correction values (regardless of how many) are entered.

I've been testing this also and I can attest that something fishy is going on. First of all: Not all IFFCC calculations are wrong according to my test but Piston is correct; something is wrong. GUNS, CCIP (bombing) works correctly with wind correction in both 0 wind ME and with 40knots crosswinds. However, the RKT wind correction is definitely weird(=wrong). I havent yet tested CCRP mode a vid demonstrating the same effect seen in Pistons screenshots: although suddenly and occasionally while playing around the RKT cue would appear to work fine :doh: The second vid was recorded with strong wind from 353 while flying a course of ~270 Attached are two tracks with the sudden correct behaviour, both tracks are horrendously long and tidious to watch. The sudden "correct" behaviour occurs at around 05:30 minute mark in both trk:s, then the rest of it is me trying to replicate and then correct the bug. :D RKTCorrectbehavioursuddenly.trk RKTCorrectbehavioursuddenly2.trk

Interesting , will test this. Although as I understood ,many ppl have confirmed that wind correction is working correctly . As per example: the virtual gunsmoke competition and its contestants(http://forums.eagle.ru/showthread.php?t=144821)

What I see is that the G ALT is very slow to respond to alt changes(compared to the other methods). As discussed on the runway it shows AGL 0 instead of MSL and in level flight in aprox. 10 sec G ALT = RDR ALT. During maneuvering and landing the difference between the two (RDR ALT & G ALT) gets bigger. On landing G ALT showed -10 and during the rollout stabilized to 0 (AGL) again. So you didn't do anything wrong it can and it went into the negative digits. :thumbup:

I dunno man, I tested it at Batumi which is more or less on the sea so that's probably why. So instead of MSL it shows you AGL similarly like they give you QFE and not QNH on take off. I guess that is wrong but still the other statements I made stand. If the IFFCC cannot give you a proper solution it doesn't give one at all.

Indeed it is a possibility that it is "half or less modeled" but I think the possibility also exists that we just don't understand how complex the RL system is and neither we know how the DCS is simulating these systems and their backup/redundacies. What I can tell you is that you can get GPS and INS: FOM 6 which causes a FOM* for the blended mode of EGI navigation(=bad :smartass:). Additionally this causes that no targetting solution (GUN, CCIP or CCRP reticules) are shown on the HUD. The gun fires and bombs pickle but I have no idea where :D G ALT also for fine for me, it shows 0 when landed when FOM is 1 and properly aligned. When FOM 6 it shows a good enough approximation to the real value. When disabling the GPS by keeping it on INIT mode and selecting POS SOURCE to GPS , the CCIP, CCRP INVALID error is shown. What I havent been able to alter is the EVE value. According to the DCS manual this is only valid for the NAV mode so at least in the simulation it doesn't play a role for CCIP, CCRP. If I cause a fault on the CADC baro and alt sensor and go with INS FOM 6 and GPS FOM 6 and disable radar altimeter i cannot get a solution just again a CCIP INVALID message. So in conclusion I would speculate that the CADC, IFFCC use all available data presented to them to attain a accurate position and altitude for the aircraft and if this condition is cannot be fulfilled a targeting solution is not presented as a reticule. I haven't found a way to "fool" the virtual IFFCC to providing me a false solution (yet). So I personally concur that while the CADC, IFFCC might not be 100% modeled it might be more than just "half or less". :pilotfly: p.s. If you want to test around, GPS is degraded by ZEROIZE function, and INS is degraded by not letting it align properly. You can also temporarily disable the GPS by forcing it to INIT mid-flight and keeping it as a POS SOURCE anyway.

Good point Piston. It is stated:" ..may cause a bias error as great as 250 feet in the geometric altitude displayed on the HUD." (T.O 1-432) No mention of error to the elevation/altitude that the IFFCC uses. Pure conjecture though - they might possibly be the same thing ( HUD geo alt and computed elevation for the IFFCC). Attempting CCIP and CCRP with degraded GPS aligment (FOM> 4 for example) and baro pressure wrong would certainly give more insight on how the IFFCC target computing is modelled. I'll give it a go once I get back in the virtual pit.:pilotfly:

Apologies I misunderstood what you meant. Did you happen to check the EVE value or the GPS altitude (G ALT) on the POS INFO page? Maybe the accuracy of the solution has something to do with the multitude of compensating mechanisms built-in to the system. E.g. bias correction based on EGI GPS altitude, static port installation error, dynamic lag, nonstandard air temperatures, calibration point values etc. etc. It would be quite logical actually that in an air-frame that has three redundacy NAV systems and a plethora of other safety backups for systems, that an extremely crucial and vital calculation (elevation/altitude) would also have more to it than just a QNH knob to rely on.

I am not sure if I understand correctly what you mean, but just changing the QNH in-flight wreaks havoc on the altitude readings. Now it would be interesting if one could find out if this meddling with the BARO will actually change the EVE value in the GPS page and the effectiveness of the IFFCC in game.

I didn't either :D. I believe that the 250feet mentioned would be a worst case scenario - as in the pilot actually dialing a totally wrong QNH or actually trying to get a wrong altitude. Additionally it seems that the LASTE creates a calibration point for altimeter setting and air mass on takeoff roll so the value you input on the ground also affects the calculation. (T.O p. 1-432) So if you wanna test it, I'd suggest to go crazy on the ground with the pressure setting and then double crazy in the air with it while using CCIP in active pause mode, just as you described earlier. :laugh: :joystick: I guess by switching to DELTA mode. Apparently you are able to create a "in-flight" calibration point with the DELTA mode. I would speculate that this becomes a necessity if the Estimated Vertical Error (EVE) becomes too great (>50feet) with BARO. I havent actually tried (yet) to degrade EVE. It would be interesting if someone could do it. Disclaimer: I have no idea of what i am talking about , I just skimmed the manual, flew around in DCS and took a screenshot. ;)

Holy mother of simulation modelling. That indeed explains it. I am in a state of shock and awe that/if this is modeled. :blink: Thank you for the link.

Yes I believe you are correct , as I understood by reading the T.O.1A-10C-1 flight manual , that switch between BARO, DELTA and RADAR just selects how the elevation of your aircraft is computed.This is then used to calculate you aircraft elevation above the intended target in CCIP, GUNS and CCRP modes. Additionally it does a few other things: "Selects altitude source to be used for CCIP/CCRP TDC generation, INS HUD and overhead updates, offset, and overhead marks elevation computations." T.O.1A-10C-1 p. 1-423

Hey . ReconStewarts vid is very helpful, concise and clear on this subject imo. I recomend.

:cry: 3 minutes? Holymoly - please teach me master. It takes me like 30 minutes. P.s. Not sarcasm , please share tips if you have the time or patience

Welcome and I bet you will learn to love the Black Shark in sim-mode. I encourage you to just go "full-sim" mode and enjoy the shark to its fullest potential. There is a lot to learn but a step-by-step approach worked for me.:thumbup: Oh, and do remember that the autopilot isn't trying to kill you, it just needs you to familiarize yourself with its inner workings. :book: Plenty of excellent YouTubers out there who do tutorials on the Black Shark.