FalcoGer

Can it talk to Joint STAR? I know we don't have the E8 or similar aircraft in DCS, just curious.

it's literally boeing, you know the guys who build this thing, saying it does. Where is your source? Also feel free to correct any mistakes. Again, same source.

In multicrew (only checked MT build), ever since the update that claimed aircraft startup synchronization fixed, there has been a consistent desync during startup in that the throttle lever positions are not synchronized. When the pilot pushes the throttles from off to idle, they will instantly jump to the fly position for the CPG. Steps to reproduce: Join cold AH64 and wait for CPG Battery power APU On Engine starter left Throttle idle Ask CPG for the left engine throttle position The pilot throttle at this point is idle, but the CPG's throttle will be in the fly position. Same thing for the right engine. This results in the rotor rpm message being played back for the CPG, while not for the pilot. I made it my habit to only fully push the throttles to the fly position after the rotor rpm is in the green zone, such to avoid the warning message, but this is no longer possible for the CPG. Also any changes to the throttles made by the pilot are not reflected on the CPG side. It's either in the off detent or in the fly detent. I'll upload a track soon, sorry, couldn't find someone right now.

The ED manual says the symbol should be yellow for towers, it is in game, and from what I can tell from other sources it should be yellow in the real aircraft, too.

I found an image. It shows the pilot's cockpit of an AH-64 variant with the TSD page open. I don't recognize some of the symbols on there, what are they? This appears to be a star of some sort, labeled SHR. There are more of them, with different labels, this one appears to be the most in focus one there is. Then there are those chevrons with a dot on the bottom. They all seem to be labeled with numbers. I thought at first that maybe it's an emitter, but it's not yellow, the symbol doesn't look right and there are some that are not on the edge of the screen. It looks like some kind of terrain feature (aka hill) maybe? But that would be a hazard point, which would also show yellow. What are those? And how can I tell which AH64 variant this is?

The Apache has several different datalinks available. We will unfortunately only get 1 of them. The datalink works over the regular radio antennas. JVMF is only usable over FM radios, but we probably won't be getting JVMF anyway. There is AFAPD using the longbow protocol. Apparently some message formats are compatible with E8, F16 and A10 message formats (source: https://www.boeing.com/news/frontiers/archive/2005/september/i_ids4.html). We won't be getting any compatibility with other aircraft, would be neat though. AFAPD is usable with all the radios except the HF radio. AFAPD allows a wide variety of messages to be sent and received, in DCS this will likely only be possible between AH64s, and possibly the OH58 when it releases, since they were designed to work together. It can do transmission of all types of points, except terrain points (not sure about that one). All points of a specific type or individual ones. routes (individual and all) lines, areas and zones (priority and no fire zones) free text missions (orders) shot-at (bda) points and requests fcr targets position reports farm (fuel, ammo, rockets, missiles) reports and requests laser codes some other stuff I don't know how much of that we'll get, but probably not all of it. Most likely we'll get transmission of points, FCR targets, position and FARM at the very least. Most of the datalink functionality is accessed through the TSD and FCR pages. Some settings might be tuned in the bowels of the COM sub pages. The position datalink doesn't work like jets with datalink or the KA50 datalink though. It doesn't show any updating symbols on the TSD. This is because positions aren't updated continuously, but only when a report is manually sent. When receiving a datalink request, tone will play and a REC subpage will be added to the TSD where you can respond to queries, or not. You can also set up automatic responses. Data like position reports will be sent through the RPT (report) sub-page. FARM and SHOT-AT is available through the coord page. The point page is used to send individual points using the XMIT button. The FCR page will have a button (RF Hand-Off) where you can transmit targeting data to your flight members. Routes, all points of a type, text, missions, and laser codes will be sent through the comm page. Other datalink systems on the apache, which we will not get, are ATHS-TACFIRE, which is used to talk to artillery units using digital messages JVMF-Tactical Internet, which is used for situation reports, spot reports and also position reports. BFT is using this network in the apache. JVMF-Fire Support Net, used for air fire missions There is a simple text only link available for the HF radio, but I couldn't find more info about it.

There is a lack of documentation for this feature. I want to export Displays (particularly the bottom and left MFD of the hornet, and the CDU of the A10C) to be read in by a C# program. Everything I could find on the whole thing was basically this -- you can export render targets via shared memory interface -- using next functions -- LoSetSharedTexture(name) -- register texture with name "name" to export -- LoRemoveSharedTexture(name) -- copy texture with name "name" to named shared memory area "name" -- LoUpdateSharedTexture(name) -- unregister texture -- texture exported like Windows BMP file -- -------------------------------- -- |BITMAPFILEHEADER | -- |BITMAPINFOHEADER | -- |bits | -- -------------------------------- -- sample textures : "mfd0" - full SHKVAL screen -- "mfd1" - ABRIS map screen -- "mfd2" - not used -- "mfd3" - not used -- "mirrors" - mirrors Along with a few forum posts complaining about the feature being broken/not working/not using the correct bitmap header layout from 10+ years ago. I tried this export script -- REF: https://wiki.hoggitworld.com/view/DCS_export -- REF: https://wiki.hoggitworld.com/view/DCS_Export_Script local LOG_MODNAME = "MFD_EXPORT_TEST" log.write(LOG_MODNAME, log.INFO, "Initializing...") --Version 3 package.path = package.path .. ";" .. lfs.currentdir() .. "/LuaSocket/?.lua" package.cpath = package.cpath .. ";" .. lfs.currentdir() .. "/LuaSocket/?.dll" package.path = package.path .. ";" .. lfs.currentdir() .. "/Scripts/?.lua" local upstreamLuaExportStart = LuaExportStart local upstreamLuaExportStop = LuaExportStop local upstreamLuaExportAfterNextFrame = LuaExportAfterNextFrame local upstreamLuaExportBeforeNextFrame = LuaExportBeforeNextFrame local textureName = "mfd0" function LuaExportStop() if upstreamLuaExportStop ~= nil then successful, err = pcall(upstreamLuaExportStop) if not successful then log.write(LOG_MODNAME, log.ERROR, "Error in upstream LuaExportStop function" .. tostring(err)) end end -- runs once when the mission is stopped LoRemoveSharedTexture(textureName) end function LuaExportStart() if upstreamLuaExportStart ~= nil then successful, err = pcall(upstreamLuaExportStart) if not successful then log.write(LOG_MODNAME, log.ERROR, "Error in upstream LuaExportStart function" .. tostring(err)) end end -- runs once when the mission is started LoSetSharedTexture(textureName) end function LuaExportBeforeNextFrame() if upstreamLuaExportBeforeNextFrame ~= nil then successful, err = pcall(upstreamLuaExportBeforeNextFrame) if not successful then log.write(LOG_MODNAME, log.ERROR, "Error in upstream LuaExportBeforeNextFrame function" .. tostring(err)) end end -- executed before the frame is rendered. -- put stuff into the frame here end function LuaExportAfterNextFrame() if upstreamLuaExportAfterNextFrame ~= nil then successful, err = pcall(upstreamLuaExportAfterNextFrame) if not successful then log.write(LOG_MODNAME, log.ERROR, "Error in upstream LuaExportAfterNextFrame function" .. tostring(err)) end end -- runs after a frame was rendered -- fetch data from the game here LoUpdateSharedTexture(textureName) end log.write(LOG_MODNAME, log.INFO, "Done") And I'm trying to read the texture using this C# code using System.IO.MemoryMappedFiles; using System.Runtime.InteropServices; namespace MFDExportTest { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void pictureBox1_Click(object sender, EventArgs e) { using (var mmf = MemoryMappedFile.OpenExisting("mfd0")) { var bitmapHeaderAccessor = mmf.CreateViewAccessor(0, 14); BitmapHeader header; bitmapHeaderAccessor.Read<BitmapHeader>(0, out header); // Bitmap bm = Bitmap.FromStream(); label1.Text = BitmapHeader.ToString(header); } } } [StructLayout(LayoutKind.Explicit)] struct BitmapHeader { [FieldOffset(0)] char Signature1; [FieldOffset(1)] char Signature2; [FieldOffset(2)] UInt32 FileSize; [FieldOffset(6)] UInt32 Reserved; [FieldOffset(10)] UInt32 PixelDataOffset; [FieldOffset(14)] UInt32 HeaderSize; [FieldOffset(18)] UInt32 ImageWidth; [FieldOffset(22)] UInt32 ImageHeight; [FieldOffset(26)] UInt16 Planes; [FieldOffset(28)] UInt16 BPP; [FieldOffset(30)] UInt32 Compression; [FieldOffset(34)] UInt32 ImageSize; [FieldOffset(38)] UInt32 XResolutionPxPerMeter; [FieldOffset(42)] UInt32 YResolutionPxPerMeter; [FieldOffset(46)] UInt32 ColorsInColorTable; [FieldOffset(50)] UInt32 ImportantColorCount; public static string ToString(BitmapHeader header) { return string.Format("Sig: \"{0}\"\n" + "FileSize: {1}\n" + "Pixel Data Offset: {2}\n" + "Header Size: {3}\n" + "Image Dims: {4} x {5}\n" + "Number of Planes: {6}\n", "BPP: {7}\n" + "Compression: {8}\n", "Image Size: {9}\n" + "Image Resolution [px/m]: {10} | {11}\n" + "Color Table: {12} [{13}]", header.Signature1 + header.Signature2, header.FileSize, header.PixelDataOffset, header.HeaderSize, header.ImageWidth, header.ImageHeight, header.Planes, header.BPP, header.Compression, header.ImageSize, header.XResolutionPxPerMeter, header.YResolutionPxPerMeter, header.ColorsInColorTable, header.ImportantColorCount ); } } } But an exception gets thrown when trying to open the memory mapped file with What am I doing wrong? How can I read the screen content? If there were some way to export the text from the A10 CDU screen that would also be really good. If there is another way to find out if the hornet has an option boxed on the MFD other than analyzing pixels, that would be amazing

Currently supported aircraft: F16C F/A-18C (Waypoints can be entered, WRP is WIP) JF17 (Waypoints, Missile Route Points, Pre plan points, mark points and airfield can be entered) Ka-50/Ka-50-III (Waypoints, Fix Points, Airfields and Nav Targets can be entered) AH-64 (All point types and idents can be selected) AH64 DTC Feature to load ASE, Weapons, and COM PRESET data. A10C/A10C-II (points can be put in as either UTM/MGRS or L/L) OH-58D Planned: M2000 F15E AV8B Anubis' C130 Mod Possibly in the future: DTC features for certain aircraft (comms plan, IFF plan, countermeasure programs, MFD screens setup), only if a setup exists that enables consistent setup, no matter the aircraft state (if it's turned on, obviously)

Important: Bug reports and feature requests on GitHub issues only please, bugs reported here will likely go unnoticed. Thank you. Also pull requests are welcome. I wrote a program in C# a few years back. It used to only be able to convert coordinates into different formats. Eventually TheWay was released and with it came the option to add points to the aircraft in DCS easily. I became somewhat frustrated with the clunky interface and severe limitations, so I took the lua side of things from TheWay and edited the export script to fit my needs, and then I extended CoordinateConverter to do what TheWay can not. It is now in a state that I feel like is reasonable to release, but it still has some work to be done with it. It's very much only intended for my personal use, but I thought I'd share. It's also WIP and not all airframes are supported yet. I also don't own them all, so I can't test everything. You can find the program here: https://github.com/FalcoGer/CoordinateConverter/releases The main features include: Allows entering coordinates manually in any format Allows grabbing coordinates off the F10 map (the camera position, really), even when no aircraft is selected Automatically gets ground elevation for points, even in jets that don't have a ground elevation database Automatically shows a crosshair for selection when entering the F10 map (can be turned off) Uses only a single TCP connection between the program and DCS (TheWay uses TCP and UDP) Allows automatic coordinate entry into various airframes Allows different point types to be defined that are airframe specific, like AH64 point types and ident, F18 weapon pre plan points Allows using DCS's export function to import a list of unit locations, this automatically sets the correct point type Some utility functions, like deleting a range of points from AH64 (for example when CMs are spammed to the max) Easy saving/loading of points into JSON files (probably) correct MGRS rounding No javascript/electron Here is a feature video showing it off with the hornet Some pictures: Main Screen Unit importer (Class is what DCS says the unit is according to \Scripts\Database\wsTypes.lua, I'm quite aware that a Shilka is not a SAM) Update Jan 12th 2024 New AH64 DTC Feature! Save and Load your configuration for your favorite servers for COM Presets, ASE settings, WPN Settings and more!

When dropping the CBU-105 and CBU-103 the dispensers do fly towards the coordinates. But the 105's BLU-108 submunitions specifically get launched upwards and deploy a parachute, which then stay in the air for a few seconds. This phase in particular is very much not taken into account when calculating the bomb's impact point and winds that are even moderately strong do blow them off target very often. Is that a bug or is that supposed to happen? I would assume wind corrected means that it's taking the wind into account.

You can hold left-alt and left click on the map to get coordinates in all formats. You can then hit F1 again and the window stays up and you can plug in the numbers.

I want to export the currently selected unit on the F10 map. I have found `LoGetObjectById()` by browsing `Export.lua`, but I don't know how to get the ID of the object I have clicked on. I would like to get at least the position (lat, long, alt). coalition and name (typename) would be helpful but is not strictly required. Alternatively the object ID so I can get all that with the LoGetObjectById function mentioned above. I would also enjoy those things for when the user clicks on an airfields. If it's possible, the left alt + left mouse button marker would also be nice to export, is that possible? Is there some kind of comprehensive API documentation that I can search through?

That's normal because of how SAR works. The higher the offset, the cleaner the radar picture gets for the seeker. INU resets also helps for me. I still don't understand what the INU has to do with the radar missiles anyway. And even if it were involved, the offset in the INU itself and the target coordinates calculated from camera angle and laser range would cancel out anyway, even if it had 500 miles drift in it.

You have to deWAS, select SAL or power of the missiles some other way to reset their targeting data.

Going lock on before launch after launch? That is silly talk!

Didn't test the new patch yet, but the issues described don't really match with our experience with the missile hitting the same offset spot over and over. If there happens to be a target somewhere near that offset spot, it goes for that, otherwise it just hits the ground, not even a unit. I think this is the closest one to our issues: INU display didn't show misalignment, but on a hunch I had reset it anyway and that had helped Also that double explosion never happened. Might be a script running on the server. Most of the misses happened on hoggit gaw. From what I can tell, the missiles are using the INU, which they shouldn't. And even if they did, all the offsets would cancel out anyway, which they don't. And the INU drifts way too much, considering that it's getting GPS updates constantly, using a modern laser ring gyro and using ground doppler radar for keeping track of the position accurately. Modern airliners with the same laser ring gyro + GPS tech get maybe a few tens of meters of drift over 8h flights. And they don't even have the doppler radar feature. The apache getting a hundred meters drift after 20 minutes of flying seems ridiculous.

I only encountered this in multicrew, but I didn't really do any extensive testing (or much of any flying at all) alone. It also happened a few times with nothing going wrong, even when waiting for the INU to align fully before engine start and only with APU running. An in flight reset at the target site fixed it again, but it's annoying sitting there for 5 minutes, ready to fire but having to wait for the INU. This shouldn't happen.

I have noticed this as well that sometimes it works and sometimes it points the camera in the direction of the last slaved point for the pilot's video page. The bracket is still visible though if it happens to be within the field of view. Moving the camera snaps it back to where it should be. LMC on the other hand jerks around.

I think this has to do with flat shadows/no shadows. I have not noticed this since I upgraded my hardware and turned shadow quality up.

I read that gearboxes and tail rotor takes up to 20% of power away from lift and forward motion. Not sure where I read that number though. Getting 20% more useful power and less drag certainly would seem like it could make such a difference. In the end though it doesn't really matter if you get there in 30 minutes or 35. Stepping on the gas all the time isn't good for the environment and isn't worth the stress. Take it easy. Maybe take the bike or the bus instead of your personal helicopter.

I think they work. At least with trees. I only take the RCs if I take M151s because they offer more options with the same amount of boom as any other small rocket. Also I think taking AP is pointless because any HE rocket on a BMP kills it anyway with a direct hit and any miss with any rocket doesn't do anything at all. At least in DCS.

Fine. Then explain why when shooting missiles, all shots misses a stationary target 100% of the time by the exact same offset of a few tens of meters, even after a good INU alignment, even with engines off. And then after an in flight INU reset and re-alignment it hits every time from the same position. and it's not like the target data is bad either. Camera is rock steady with IAT. but LMC has same results. I don't think the INU has anything to do with this missile in the first place and yet, switching the inertial reference source gives different results. And it's not that I shout "I cast magic missile". The targets can be in an open field, 6km away, stationary and I'm in a perfect hover with no obstructions wide and far. This thing is so unreliable that we went back to carrying laser hellfires, because at least those hit the target the first time every time. Fire and forget is nice and all, but really pointless if you get a 0% hit rate. It seems like a bug, but I don't know enough about the missile to be sure. It's also hard to reproduce, because I don't fly with george and I don't know if the bug only occurs with multicrew. And it only happens after some time, and on busy servers, the track replays get very large very quickly.

Funny. Whenever my game crashes, it pops up the crash report in about 2% of all cases and the sample number is somewhat higher than yours, good for you. But why is this in the ah64 bug report section?

Still an issue with latest OB. Saving points as pilot before the copilot joins or the CPG creating marking targets and then disconnecting and then rejoining causes them to default to the points preloaded into the aircraft at mission start & whatever CMs get auto populated. Is this worked on still? Surely you reproduced it by now.

Fog doesn't affect them at all though. They can be sitting in a cloud on a mountain where you can't see the nosecone of your aircraft, but the AI will happily shoot you even without radar. Same goes for smoke, be it WP or an oil fire.