Moonshine

even with just guns you should be able to use the AG radar together with other sensors like a TGP. maybe you just want to do some recce? i doubt that would be done in NAV where you cant see sensor symbology in HMCS

thanks for clarifying

But what does it do if i have a steerpoint offset induced but am not in any FTT (so there is nothing to reject)? because on the TGP, first TMS aft returns to INR track and TMS aft again REMOVES the steerpoint offset.

So there is no „TMS aft“ function associated with the AG FCR cursor slewing (before a SPI has been designated via FCR as then it would just reject it again like you said)? maybe i have to reword my question if you use the AG FCR (no matter which mastermode) the cursor is on the currently selected steerpoint „slaved“. Now start slewing the cursor on the radar screen but do not designate anything. After that you want to return the cursor so it is back to the original steerpoint location. You can achieve that by pressing CZ on the OSB, but not with TMS aft. Whereas with every other sensor selected as SOI, TMS aft would do the same as the CZ button does

Not sure i understand that part correctly. So CZ is an SPI logic, not limited to the TGP. If i slew the cursor on the AG-FCR, TMS aft will not CZ the cursor back to its original SPI location (slaved to a STP). Only the OSB will do that for me. Is that intended? Because when HUD is SOI and i slew the steerpoint diamond in NAV (or any VIS mode weapon, DTOS etc when in AG mastermode) TMS aft will remove the offset induced by slewing

@itn might be related:

make sure you dont run any mods and if still having issues, run a full dcs cleanup and repair

Yeah give it time, use the pull up cue as a guide during your run to release. It shows the 4G mark, maintain that and youll be fine. Also note that the FPM has to be as centered as possible on the ASL, if not, bombs will miss or if too far off, bombs will not release at all

havent had any trouble with it, all bombs fell within a reasonable margin of error (no wind, all errors originate from inaccurate flying of the ASL during the pull up to release) make sure you keep your speed, dont immediately pull up when the cue appears. you might fall out of range again due to bleeding speed, pulling up too steep or both. i plug the burner shortly before i start my pull up and once the pull up cue appears, give it a second or two before you actually start pulling, that way you should stay well within release parameters CCRP_toss_MK84.trk CCRP_toss_CBU87.trk CCRP_toss_MK82.trk

keybind didnt do anything for me. i even put it on a different keybind (without using any modifier like alt or ctrl or anyhing), it never saves anything (in the viper). edit for the ones that have similar issues: i went into Saved Games\DCS.openbeta\Config\View and opened "snapview.lua". then i deleted the whole section of the aircraft i had issues with, only then opened the game and wanted to set the view the way i like it agian. funny enough that worked. after closing the game again, the newly set values can be found agian in the snapview.lua. edit 2; the culprit seems to be the line "ViewAngleVertical". "snapview.lua" files from older DCS versions (under savedgames) had a value of 0 - which somehow with one of the recent updates seem to cause the "zoomed out" view. where as the new settings i got from deleting everything first puts it at a value of 60 in my case..

indeed, good find. same happens to me. GUARD_channel_transmit_with_preset.trk

it makes playing the modules affected quite rough, not enjoyable at all. hope that gets a hotfix otherwise we are screwed over the festive period i did just now run a full repair and cleanup, still the same, no mods either.

great, now even the workaround doesnt work anymore, i start fully zoomed out, press Rctrl+Num0 twice, reset the zoom and instead of being at the zoom level my default custom cockpit angle should be it is back to being fully zoomed out. not useable at all. and the "save cockpit angle" keybind (Ralt+Num0) does not do a thing anymore @BIGNEWY can you guys look into this (agian)?

any news on that?

not sure why you are using the backup radio just to use guard to transmit, you can do that in normal operations by setting the respective radio switch to guard instead of squelch upon returning the switch back to squelch, you are back to the frequency you have previously had selected as either your UHF or VHF radio GUARD_channel_transmit.trk

lots of it in here. Last statement was „working ad intended but still WIP“. the jet currently doesnt represent whats in the ED manual, but funny enough ED manual represents whats im the real manual.. oh well

didnt do anything. still the same issue

be in nav, set the TPOD to A-G mode. it will be looking at the selected steerpoint. from there, slew freely as youd like

Master mode does not matter, all you need to make sure that HUD is SOI (or when on the MARK DED page you cycle through until you get to HUD, that makes the HUD SOI automatically). TMS UP long to get the symbology in the helmet, then look at whatever you want your markpoint to be, TMS up again, to stabilize the position, from there you can finetune it by TDC slew and finally, TMS UP again to lock it in demonstrated it using NAV mode first, then AG - PRE mode for GPS guided bombs HMCS_MARK.trk

still starting with the "wrong" FOV. only after 2x RAlt+Num0 its back to what it should be.

@Lord Vader was the fix already implemented? or is what im seeing still the "old issue"?

Did not test it yet edit: tested just now, seems to be better but still not really good. after designating the "new" location with the pod, pressing Enter will update the system. however the final location of the updated steerpoint seems to shift or hang in the air compared to what was just designated with the pod. for examples: in my test i first want the steerpoint to be at the start of the runway on the white lines. somehow the final location is off by a couple 10m then i try it again with a parking hangar and later on with the ATC building, still the same. for general navigation given no GPS years this is surely "good enough" but to correct coordinates for bombing something this surely isnt unless the target can be visually picked up before employment. not saying this isnt realistic, its just the observation of whats happening now with it. bottom line, the "updated" steerpoint location doesnt end up to be in the center of the TGP crosshair as it was originally designated. or the elevation doesnt match. then again, in the DED the elevation seemed correct. NAV-Fix-TGP.trk Edit 2: seems something with the elevation is off. after designating, it adds 200 feet somehow. you can see it in the TGP page, top left the elevation number NAV-Fix-TGP_2.trk

Observed the same. Didnt disappear even after putting pod in standby and or turning the hardpoint completely off