Rongor

Tbh I wasn't aware the A-10C II did ever receive a gateway function already, be it with the implementation of the ARC-210, before or afterwards. So in my world, seeing a L16 Viper, Hornet or any flight's PPLI on the TAD seems wrong at this point, regardless A-10C or A-10C II, so I think the OP has a valid point. ED's manual for the A-10C II doesn't mention any gateway at all. Regarding datalink and TAD, it specifically focuses on SADL, which is incompatible to L16. I don't see how the fact that we can see L16 PPLIs on the TAD is basis for the assumption that we received a gateway capability. For now its a bug, unless ED confirms this is intended as simulating a gateway in any of the both A-10Cs we have.

No idea what DTC issue you are assuming, since the partition containing navigational points hasn't been implemented so far. As above, its a result of a wrong utilization of the route tool. Enter elevations, otherwise any point will default to 6523 ft. Also FIX would be the wrong method to "fix" this, as 1. this is an altitude issue and 2. you would only adjust a correct alignment to a different one (with a wrong system altitude).

What you describe there is the result of you not entering elevations in the route tool. You seem to assume the route tool will set each new STP at ground by default. It doesn't. By default its at some 6500 ft or so. I can agree this isn't optimal but you just have to deal with it. If you ignore this and load in your route with all STPs at 6532 ft, its only correct to expect the TGP pointing into higher elevations, touching the ground only in the distance if at all.

You never mentioned exact boresight distances and stations. Also you didn't mention these for your handoff attempts. So this could still all be coincidental. For each of the both smart stations carrying Mavericks, you have to boresight independently. After both boresightings, both stations' Mavericks will point exactly at the TGP's POV only at the exact distance, relative nose bearing and elevation as both the TGP and the respective station's Mavericks were in the moment of boresighting. If you boresighted the left station at 4 NM and then later attempt to handoff to a Maverick at 8 NM, a maverick hanging under your port wing will point to the right of the target. If you boresighted the starboard station at 8 NM distance and 4000 ft altitude and then later try to handoff to a maverick on that station from 20000 ft and in 4 NM distance, the Maverick will also point to the right of the target and the chance of seeing errors in elevation will be be high.

With today's 2.9.19.13478 this seems to be fixed.

Can confirm this has been fixed with today's 2.9.19.13478

DCS 2.9.18.12722 - 22.07.2025 A lot of nice stuff has been added in July. Read more about how George as CPG is managed on pages 582-603 in the manual. \Eagle Dynamics\DCS World\Mods\aircraft\AH-64D\Doc\DCS AH-64D Early Access Guide EN.pdf

I can replicate this. Precondition for this to happen is that George has armed the weapons at least once before you end your flight. Then ordering to shut down after landing will end up in his "aircraft is armed" loop, regardless if you wait for him to finish shutdown before cutting power or not. less than a minute trackfile attached. Hot start on runway. Brief takeoff, random PHS slave search (so George does arm), landing. Ordering shutdown. Waiting until completed, cutting engines. "aircraft is armed" loop. George shutdown aircraft armed.trk

Cruise and TAS boxes don't really correspond well in regard to RaNGe and ENDurance. In my example best range Q is shown as 64% TRQ in the Cruise box, while the TAS box is showing 117 kts as the maximum range speed. Max endurance Q is supposed to be 41% at a speed of 71 kts. Lets focus on maximum range speed, 64% at 117 kts. Bottom line is, these tandem values are impossible to achieve in DCS. With a TRQ of 64% I merely achieve 104 kts in level flight (I even allowed a slight descend to keep that speed), so around 12% lower speed than required for maximum range as per the TAS box info. Also the fuel flow in the Cruise box for 64% Q is predicted 991. Checking on the Fuel format page, the calc flow for the current 64% is 1170 in total, which is 18% above the prediction of the PERF format page. Brad mentioned in discord that drag can affect the values. But I am a bit surprised to see the deviations being that enormous. Even in case the prediction fails to be accurate, how can predicted Q and speeds mismatch that far? No, I can't provide any real world data on "how it should be". Rather I am clueless if this is wanted as designed and want to bring this to your attention in case a further refinement is required. Its the size of difference, which lets me doubt that this is correct. Yet maybe it is? If these deviations are realistic, I am curious how the PERF data can be of use in any meaningful way IRL when in fact the values are unreliably off from the actual state of your flight. I wouldn't even know what to actually aim for when attempting maximum range flight, 64% torque or 117 kts? Or are these parts of the PERF page ignored IRL due to their inaccuracies and at least for maximum endurance I rather have to rely on the SFR of the FUEL page? This is a few moments of my flight, before the screenshot above was made. (unlisted video)

A new guy stumbled over this and reported it in the discord. I never did notice this myself so I am not sure its a (recent) bug or has been like this all the time... For some reason the Escape menu lists "manual" in the Huey and when opened it does introduce the player to game modes. Is this intended?

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