Rongor

I remember how at some point ED implemented the TGP needing a full restart (manually chin station power off/on) after rearming on ground (since its counted as a new TGP). Now the AAQ-33 isn't affected by this. Landing with a working ATP and then rearming doesn't affect the AAQ-33 at all. It simply continues to operate just fine. I have no idea if this is intended to work differently for the ATP now (well thanks if it is, so we don't have to endure the ATP's 12 minutes initialization after each rearming) but in case ED has simply forgotten to apply the same logic as with the AAQ-28, I just wanted to give notice

Dropped LGBs don't track moving targets in point track. Impact is around the area the target has been put into point track. Not sure the laser is active at all. I did see this issue with auto lase and manual lase. Stationary targets in area track/INR have no issues when attacked with laser guidance. Even manually slewing of the laser spot across the ground is changing bomb trajectory as expected. Issues only arise in point track. Trackfile shows GBU-12 attack on moving tank. Tank is getting point tracked. Laser is auto-lasing 15 seconds before impact. GBU-12 doesn't show any sign of steering attempts. A-G is on CMBT. TGP code and bomb code are default 1688. AAQ33_PointTrack_no_Laser.trk

no workaround needed. Offset Aimpoint is what its called.

You create an offset aimpoint for that steerpoint. Get into the Destination Offset Aimpoint DED pages and add the given range and bearing. Procedure is explained in the manual page 204.

When spawning a Hornet, regardless hot or cold start, selecting the Guard channel in any of the two radios will show an empty frequency. Players won't be able to transmit or receive on Guard. Workaround is to load the DTC Comm partition via the MUMI page (default DTC will do, without entering and selecting a DTC in the manager) I am not sure this should be required. Same issue for the C-preset. 2 radio G and C.trk

Thanks, regarding the TMS aft, that will do. Why though? It is supposed to maintain line of sight to coordinates, which it can do fine (within accuracy limits) during masking and switching steerpoints. What would be the purpose of a single TMS aft to exit POINT or AREA correlation if even basic INR is also requiring an image to correlate? So far I understood that INR is maintaining the line of sight to coordinates, even when slewed. That is exactly why it is recommended to switch from AREA or POINT to INR before the TGP is getting masked. This is contradicting the manual, which clearly states that there isn't any image processing in INR. Which only makes sense: Since the TGP doesn't need an image to stabilize on a set of coords when switching steerpoints, why would it need an image to maintain line of sight (of course this won't be pin point accurate) on the most recent coords we slewed on? This is basically the idea behind exiting the correlation track modes into INR, so I am a bit confused now about your comment claiming otherwise. page 382:

I might be willing to believe that this is accurate only I can't see any argument presented why this should be the case. What you describe is exactly what I described before. I am glad you experienced the same as I did. Only how is this any hint that this is accurate? I know that the TGP is attempting to correlate an image, only I don't see how this is a reason to prevent TMS AFT from functioning. On the contrary, TMS AFT would be the logical method to stop the failing correlation by putting it into basic INR. Also the CZ next to OSB9 is evidence there is a Cursor Zero available. You can achieve it by pressing that OSB, so what is the benefit of locking out TMS aft to force the pilot to take his hand off a control to press it? This effectively means an unnecessary degradation of HOTAS capability (admittedly a temporary and arguably unimportant one) and I can't see why avionic designers would intentional prevent TMS aft to function in this very moment. I don't. What I expect is the TMS functions to work normal. Which in this case TMS aft doesn't for unknown reasons. It may be accurate yet I don't see how we know it is.

Regularly, the TGP will enter temporarily INR track mode while slewing, then the recent track mode is recommanded once slewing stops. Occasionally, the TGP enters a continuous INR AREA or INR POINT track. This will reliably happen when the TGP is masked. I noticed that during this state, actuating an exit out of AREA or POINT and then CZ is impossible to achieve by the usual 2x TMS aft. Pressing the CZ OSB will reliably return the TGP to the steerpoint, which often is a quick way to exit unintended masking while surveying the area. Only the TMS aft won't do in this case. While in a continuous state of INR AREA or INR POINT, TMS LEFT, FWD and RIGHT will still work normally, so it is still possible to switch TV/WHOT/BHOT and cycle between INR POINT and INR AREA. Only TMS aft is ignored. In the track we see me heading towards steerpoint 1 which is ahead of us. I then switch to steerpoint 2 which is behind us. The TGP following to the new steerpoint is ending up masked and INR AREA or INR POINT are displayed continuously. After applying a bit of slew, I then press all the TMS directions, all do work, only TMS aft is ignored. CZ by OSB does clear the CZ. When in regular POINT, AREA or INR, TMS aft behaves normally and applies CZ/ returns to INR and then applies CZ with 2nd press. 65 seconds track attached. no TMS aft to INR.trk

Intro: I really appreciate the DTC feature coming to life and as well seeing it being introduced step by step, so that we can provide feedback while its still evaluated and improved. This thread is no criticism, I only provide my point of view, which may be totally off of what most others think but also might potentially adress what lot of other people think. My point of view is that of a player mainly starting DCS to get into some MP server, then spawning into some dynamic slot and possibly doing so multiple times while staying on the joined server. Situation: Currently, when spawning into a role slot, we then enter the DTC management screen, by either opening it in the mission planner before spawning or after spawn by a keypress from within the cockpit. Then we have to do the following steps: 1. Click on the conspirative "File" clickspot 2. click on "import" 2. navigate to a folder we will have to create before manually when saving a DTC we did populate from within the mission editor. 3. select the specific DTC there 4. done The tedious thing about this is, that we have to do all of this every time we join a server, and whenever we have to respawn in that same slot. All while the drop down list in the same screen for loading a DTC "available mission files" seems to be left without any use. Let's change this: Suggestion: Have DCS create DTC folders for each installed DTC-capable module in the savegames section. DTCs you create for this module should then save there by default. Like this: If you then join into a server and open up the DTC management screen, the "load" drop down list should automatically be populated with all the DTCs found in the folder of the very module you are currently accessing the DTCs for. Maybe even rename the item in the manager from "available mission files" to "available DTC". So players would only need to select a file in this drop down list and then click load. The whole folder navigation and file selection would then be obsolete. - Icing on the cake would be the DTC manager autoselecting the DTC file you used on your most recent flight on that module. Advanced Suggestion: Maybe it would be beneficial to eventually be able to save DTC files from within the DTC manager, especially the moment we get access on the nav/target points partitions and tactical stuff (just insert the specific name for whatever respective module, of course an AH-64 will have different format than a Viper) but also MFD configurations and radio/datalink presets often see a need to be adjusted while on a server mission for repeated use, so it would be great to "edit" the DTC while on ground and then save it for any future use in similar/same mission conditions. Thank you ED!

page 407

Too bad your F10 map screenshot doesn't show LL, you chose to display MGRS there... Unless TTI is running a date before 28 March 1994 (top right corner of F10 screenshot shows they do not) and/or you didn't turn the INS mode knob to NAV after alignment, there is no reason to assume you would see any noticeable drift at all, as the INS is a blended solution constantly combining INS and GPS. Read more on this in the linked article below. Yet as your INS DED page confirms, the INS does know where you are, so the offset of steerpoints will most likely have a different reason. @Tholozor's suggestion is pointing into the obvious direction. Always look out for CZ in your MFDs and press it when you require steerpoint accuracy again after playing around with some SOI (read more on this on page 303 in ED's manual) Especially use of HTS can easily cause offsets in the 20 NM range.

Using these lots of exclamation marks in the opening post and underlining of statements makes a possibly valid bug report seem like an unnecessary attempt to make the issue appear as the huge scandal that will shake up the entire DCS community. It won't.

This has been reported long ago You can simply ignore it and continue the mission.

These are interesting layers, but don't correspond with the issue, which is the current way dynamic spawns work. Expecting players to read up which airfield historically did serve which limited types of aircraft before spawning is ignoring the fact that most servers use map modules for any kind of fantasy conflicts and the artillery you remind us of here will simply not be there. Braunschweig's runway is about 1 NM long. Even on Tal Siman on Syria you can land an F-16 while the runway there is only half that long. Denying players the use Braunschweig for jets for historic reasons is kind of ridiculous. There are concrete spawn points at Braunschweig, so its perfectly fine for jets. The legacy spawn system doesn't have any issues with this. This thread wouldn't exist before the Dynamic slot system had been invented. What we are seeing here is simply the new Dynamic slot system causing conflicts by randomly putting too heavy aircraft on too soft ground. Telling people what is historic and what isn't and that you think they are supposed to use helicopters is not helpful.

Another multicrew duo reported this happening today in the DCS discord... https://discord.com/channels/542985647502393346/551106084157390874/1375428945914363966 also, use of grayscale confirmed