Carbon715

Hello, I was beta testing a mission and noticed that my contrast I set on the tgp screen via the rocker would revert as soon as I switched the screen to another, such as the hsd. This also happens if you change the master mode from the tgp screen. I think its the contrast changing, it could be something else but hitting the contrast rocker again seems to revert it back to what the user set. Quick track attached showcasing it....marianas free flight. No mods used, clean caches. tgp contrast bug.trk tgp contrast bug2.trk

I'm not tracking what you mean by interplane other than talking to the ground guy (crew chief) Technically all that needs to happen is turn hot mic on (in the real thing) DCS doesn't require that to talk to the crew chief. Also you can only use UHF prior to engine online

You don't say... It's the principle of having a realistic simulation that's easy to model without lua edits possibly messing with integrity of the sim.

Title, white light isn't good for your night vision and isn't used in night ops

Aerial Tgt for convenience and from what I understand realism but as Hobel demonstrated, a moving target in general won't allow a boresight. So should this be investigated?

Very clever demonstration to show the issue as well

A. Because there is no option to have un boresighted mavs for the purpose of testing during air start. I don't have the time nor patience to cold start getting airborne and test something to see what's going on. B. Realistic boresighting target. Exactly my point/issue

Ok, I'll rephrase as I don't think it's to do with the recent sighting changes but rather not being able to Boresight off of a moving target, for example, your wingman. In the track I did an air start, maverick is already boresighted to the TGP, which is fine. It is expected that boresighting the maverick again will retain a close enough Boresight depending on the distance boresighted, due to parallax. When doing the boresighting procedure in the air, which is the recommended avenue for botesighting mavericks, I go to A2G master mode, bring up my WPN page, and I cursor enable to PRE. Now with my TGP I command to SP mode, and TMS up as TMS right doesn't work for whatever reason. WPN page SOIs, so I DMS down to get back to TGP to slew to the wingman in front of me flying. I Tms up over/near the wingman to gain a point track. The TGP now follows the flying aircraft while automatically SOIing the WPN page. Ok great, if I am extremely quick I can TMS up again (since the mav is already boresighted) and lock the wingman with the mav. Now I hit BSGT OSB , TMS aft, and everything is peachy. Now do all that again right up to when the WPN page SOIs again. Simulating a non boresighted maverick we slew a second or so and back to that wingman. Hit BSGT, TMS aft and now the TGP and Maverick are not boresighted to that distance, but rather a distance much much further. What appears to be happening is with the TMS to point track from the TGP, a point we shall say is made at that position the aircraft is in. Now once we are sleeping the mav seeker over to the aircraft, that distance between point initial and point final is growing, because the target aircraft is flying. Once BSGT is hit and TMS aft applied you can see the difference between where the TGP is looking and the Mav do not coincide anymore. If the target aircraft was not moving, I don't think this issue would be happening, same as designating a target on the ground and botesighting off that. The air boresighting on something moving is the issue, if that helps.

Ok so air start, caucuses. Mav is already boresighted due to air start, yes. Not the issue. Doing the boresight procedure should still render the mav boresighted to the tgp. If offset from a moving target after initial tms up, soi auto switches to mav (new?) TMS up with mav (this is in pre) and hitting boresight , then tms aft (1 sta of mav) should boresight however now there is an offset because the boresight target has moved from the original tms up of the tgp to the final location when mav boresight is hit and tms aft. If it doesn't make sense , Ill rephrase. TLDR Boresight on moving air target not working Air Boresight.trk

Well to be fair, closure rate is kTAS. kCAS is great for the intercept

FCR Target Speed kCAS is affected by wind speed. Attached is a track, set up wind speed to show. The difference in CAS displayed + the 20ish kt headwind is equal to what should be the displayed CAS on the FCR screen. Also the closure kTAS is affected by wind speed as well. Shows closure but no closure realistically. Track was on Kola. This moment is only about a 2kt closure to target. HUD kCAS , FCR TGT kCAS, Closure kTAS, and Windspeed Circled. Actual target speed flying form. FCR TGT SPEED CAS Affected by Wind.trk

The documents I have show CAS as well for tgt speed, explicitly saying "Calibrated Airspeed". As for closure I can't find anything denoting what kind of speed it's referenced off of. Edit* I found in a CM-34-1-1 closure is kTAS

I'll report back when I can and try TAS on my HUD. I've heard from around that altimeter setting in the mission itself is screwing with the speed and closure the FCR displays though. Again I'll test when I can.

Furthermore, the B/U radio will read REMOTE with c&I placed in UFC, and not a frequency

So I've noticed as I'm playing some paid viper campaigns, keeping speed or up with the AI is a PITA. So when I lock one up, I should get their speed/and closure, which I do. However it is off. Not by a ton but enough to where it's more trouble than it's worth using a lock method to reliably gauge speed and closure. Take for instance this image from BDs Gamblers Campaign mission 2 at the start. I lock this viper and get his speed as 274kts on the FCR. He is actually 271 when flying from. I am currently 303kts showing a closure of +40. That would indicate the target would be 263kts which the lock target still isn't. Is this an FCR issue or something else?

Something with the HAD happened along these lines that have been stated. Lead initiated a TDOA on a BB radar and it disappeared. After he could not even use his HAD even after power cycling. Me in my infinite wisdom decided to try the same thing. Lock the BB on the HAD, initiate TDOA with the wingman with TMS left long and the BB disappeared at some point screwing my HAD up as well. I also got some weird numbers on the HAD and it was unusable. Yes, I think IADS scripting of some sort was in this mission and is probably the culprit. I got a copy of the mission and was trying to duplicate with just myself and AI wingman but could not get this issue to duplicate. I did get the weird TGP drift mentioned in a track, that has been previously talked about. Attached is a picture of my HAD screen, I don't know if it's of any use, but I'll provide it. I recorded the whole mission as well. Attached is the TGP slewing weirdness as well I got trying to duplicate what is in the picture. If its of any help, great. If not, sorry to waste time. HTSHAD.trk

Also, this creates an offset and if not cleared or cursor zero, all stpts are offset by whatever the offset to the air target was.

What i mean is by it makes sense to make a SPI change in A/G mode of the TGP is, is that when I TMS up, Im creating a point track on a ground target - spi should move for weapon releasing/slaving etc. This effectively changes the stpt as well so all nav goes to this. When the TGP is in A/A mode and I command a TMS (point track again) on something flying whether its because the tgp slaved to an FCR lock or not, I don't know if it should move the spi/stpt. Currently the stpt will move when commanded TMS up on something flying. An Aim 120 or any such A/A weapon does not care what the spi/stpt is. The weapon essentially slaves to the FCR lock or in the case of IR weapons, an IR source. I don't have any evidence to the contrary, just common sense which is why I was asking clarification if this is indeed correct behavior. Again this is in NAV master mode with the TGP in A/A mode.

I'm unsure if this is correct but thought I would ask as it seems counter intuitive, but when commanding a point track (tms up) in A-A mode of the Tpod w/ an FCR track, the SPI is moved to that location. Logically it makes sense in A-G mode but doesn't for A-A mode. Is this correct behavior for our 2007 viper? Edit * This is only in Nav mode I noticed.

Hello and thanks for the kind words So far, I have only been able to yardstick successfully in multiplayer with other players. I don't know that is something that is implemented in SP or not, but curious to know as well!

Later OFPs allow you to decouple the TGP in CCIP. So we won't see that implemented.

I understand I will be of the absolute minority, but an option to have chocks already installed would be nice considering you won't see a viper not chocked starting up cold.

Same, at a loss. It's an ever so slight stutter panning the camera...enough to be annoying.

This, I have been away for a few months and came back to notice this annoying jitter stutter when panning around the cockpit randomly of my viper. Was never an issue before. Updated bios, reinstalled windows, fresh reset of everything, trip to the witch Dr, nothing has helped. Happens with track ir, locked to 60fps and should be butter especially with VRR. Not anymore. 13900k, 4090, 64gb ddr5 ram to name a few specs.

my firewalls allow, I figured it out. For some reason my steam account needed to be re bound to my standalone and my licenses transferred over again...Thanks guys