FalcoGer

When the CPG enables LMC while tracking a target with IAT, the TADS camera desynchronizes between the PLT and CPG crew stations. The PLT sees the camera at a dead stop while the CPG has the camera moving. I wasn't quite sure what caused the synchronization issues so I had the CPG perform different things before we figured out the LMC thing. Steps to reproduce: Both crewmember join aircraft PLT sets up TADS video on one MFD CPG uses IAT to track a moving target CPG enables LMC (with good laser range) CPG tries to adjust the aimpoint on the target using LMC Notice desync between the two views Server track is me as PLT, other track is CPG Ah64Issues-20230126-233247.trk server-20230126-223145.trk

I have had the same issue, but only with the apache (I didn't test every aircraft though). I thought I did something wrong.

Probably releated, or at least fixable with the same patch CPG shouldn't generate his own points and just receive the points from the pilot after he joined.

Still an issue in latest release. This also causes the aircraft to be "dead" to AI, so you can't repair it because the ground crew doesn't respond. It also stops AI units from shooting at you, so you have basically cheat mode on if this happens. At the same time it doesn't count as an aircraft loss on the score board. If the aircraft is "dead", then kill (explode) it. (janky quick fix) If the aircraft is still flying, don't say it's "dead" until it has actually exploded from damage taken. (preferred)

Regarding a bug tracker I can't agree with all of that. bug trackers are invented to reduce the workload of managing the reports of bugs, classifying them, prioritizing them, keeping their status up to date, collecting relevant facts, for example where such issues might arise, and consolidating evidence and potential approaches to fixing them. Putting an effort into creating or setting up such an environment would actually reduce the workload of sifting through the forums, which are ill suited for the task, both for those people that look for bugs and those that fix them. It is far more work to do that in a forum, which is designed to share opinions and facts and which is not suited to search for bugs or keeping their status up to date. Many bugs on the forum are not labeled or labeled as reported or investigated when they are in fact fixed. Some bugs are regressions that were reintroduced but are then labeled as fixed already. It makes it hard for people to keep track of what's real and what's simply not been updated. Furthermore when looking at the bug report forum, it's obvious that the amount of threads can only really grow. There will be 10, 20, 50 pages of bug reports, and some will slip through the cracks simply because the bugs on pages 2-30 are fixed, but the bugs on page 31 are never seen ever again. In a bug tracker you simply filter out the stuff that has been fixed and you are left with a list of known bugs or alleged/unconfirmed bugs, drastically reducing the chances of a bug not being looked at. There is also no need for a "second tracker". One should be plenty enough. Any internal comments could stay internal, no one is asking you to share your source code or reveal how "personal conversations" on the bug tracker can even happen. I implemented a version control system for my company while another member of our team implemented a bug tracker. Took me a few days to set everything up for everyone and him a week or two before something reasonable was working well enough for use. It really just comes down to designing the database and a user interface and the queries that are done between the two. Regarding the frustrations of people The fact that people are frustrated and may think that nothing is done, that the team is incompetent, etc, points to a miscommunication. That is the whole problem I'm trying to address here. Of course other projects have some trolls on their forum, other projects have people discontent. But when I look at DCS specifically, it seems way worse. Personally I feel way more frustrated than with other projects I have posted bug reports for, both production software and games. Blaming people for posting is fair, but that doesn't mean you can just ignore their posts. They still need to be classified and disregarded, and for the right reasons. Take yourself for example. I asked that Air Fire and Arty datalink would be implemented. I read the TM, it outlines the procedure step by step, it shows drawings of what the MFD screens look like each step of the way. You come along and say "That's not how it works, it's a misconception", "Won't be implemented". Despite it being part of the aircraft IRL. I understand that it was never used because radio exists, but in DCS it would tie in nicely. No further information was given on why it was "a misconception". I'm fairly confident that the team uses the very same TM to model the aircraft (while simultaneously forbidding any mention of it on the forum). I understand that it won't be implemented tomorrow or next week, but it would be nice to have in 2 years. My understanding of a simulator is, if the real aircraft can do it, and if it's public knowledge on how it looks, what the procedures are and what the end result is, then the simulator should simulate it, even if the implementation details aren't known (the format of the data link packages, package sizes, frequencies, encryption schemes, etc). It also doesn't help that some bugs have been around for decades and that people have fixed them by changing a single number in a lua file, yet this is not officially done, thus breaking IC, for instance. I'm not sure if that is true, but it would point to some deeper problems with the whole process. Of course people form their opinions on lacking information because there is no information. When I see certain things, I can only assume how they came to be from what I am provided, and what I am provided is the multitude of problems and my own experience working on software projects, though of course much smaller in scale than DCS. For instance a Mig 29 locking somone up 45° off bore and you being 45° on the other side still gives you a spike despite being nowhere near the line of sight line, you being 300 miles away and sitting in an aircraft shelter. This has been around for many years now and still not addressed. How can this be? Especially since it's such an obvious issue. Put a single Mig29 in a mission and basically the whole server gets spiked. And that's not even one of those tiny little details, like a single obscure aircraft function not working correctly when certain, specific conditions are met, like the windshield wiper knob not being able to be turned to high without generator power, which was fixed. Another example is when I see the problems in synchronization in the apache between the seats. I conclude from the dozens of bugs that I observe and the way they happen and from experience, that synchronization works by sending which button is pressed and then separately keeping track of what should happen with the aircraft, and not by sharing the aircraft state. Initial synchronization of some states is done when the second person joins, creating the possibility to forget or mis-synchronize them (for example C AUX tank status, APU status, etc). If I had to come up with a system, I'd write the class for each aircraft system and then transmit that state when the other client asked for it, for example to display it on some interface in the aircraft. Instead it seems like cockpit button presses are synchronized instead. Since DCS uses UDP, some packages might get dropped and then you get one off bugs that can't be reproduced. For example just yesterday my CPG was setting up a route and suddenly the COM->MAN->VHF Tone got turned on for me, but not for him, some time earlier some FMC channels just turned off when my CPG was doing something completely unrelated. It's impossible to recreate, if I were to report this bug, it would be "can't reproduce, no track", never to be seen again and that's why I didn't bother. And when I point out that the whole approach is wrong, I get told "you don't have enough information to even know what the approach is", which is true, but on the other hand I can not get the information either. So either I ignore the problem or I must assume what the problem is through what evidence I'm given. Of course seeing stuff like this is frustrating. And I'm not the only one to feel that way.

I would like very high resolution chart maps (1:12.5k) for cities and airports showing individual buildings, streets and other such features in the "Ciy Graphics" format (probably typo in the TM).

It would be nice to have something come from bug reports. I don't mind bugs and problems in early access, that's to be expected. What I do mind is being treated that way when I take the time out of my day, and the days of other people who help me make those multiplayer related bug reports, reproducing them and posting them here with detailed steps on how to reproduce them and uploading tracks. And after all that, nothing is done, no acknowledgement is given, no communication, no updates, just nothing at all. Those people I do those bug reports with feel increasingly frustrated and more unwilling to do it, because they get the feeling that nothing comes of it. And if they get that feeling then something is wrong because either a) Really nothing comes of it, or b) That something comes of it, but it isn't communicated properly and both of those things are issues that should be fixed. I don't know which it is, so I will assume the latter to give the benefit of the doubt. I have posted well over at least 50 bug reports, some recent, some a long time ago, and recently just a single reply from the forum- or DCS staff. I have paid a lot of money, I am taking my time to report bugs, because I want the module to be as good as it can be, and I get ignored. I feel like I'm wasting my time, working for you, for free. I admit that a good portion of those are minor details, not important or often used, but as a big fan I want every detail to be accurate and working. Other bugs are indeed more concerning and relevant to major elements of the aircraft. Some are duplicates, but that can't be helped if a forum is used to keep track of bugs and people using different words to describe things so it can't always be found via search. Furthermore, once a thread had been looked over and marked as "Needs track replay", "needs more information", or "Investigating", it seems like no one every checks on it after a track or more information has been provided ever again. No updates are being made from "reported", if it ever gets to that, to "fixed", except for a select few, very major bugs. On one occasion I was reporting a bug, with video evidence of it, showing it and giving detailed steps on how to reproduce that bug. I have since talked to at least 5 other people who experience that very same bug while no one I asked claim that they did not have that same bug. For me and every one of them the bug comes about by literally pressing 2 buttons in the cockpit and nothing else. Yet claims are made that this can't be reproduced. I did not have a track file at the time but it was requested. The thread was marked as "Investigating". 3 days later the track was provided, showing the bug. In 6 months since then, not a single download of those track files has been made, nor was there any further comment, and nor was the bug actually fixed since then. I don't know if I'm crazy or something, but to me it seems that asking for something, then being given the thing and then ignoring it for half a year seems just a little absolutely rude to me. Since this had been "investigated", this bug is still present half a year later. Granted it's a small inconvenience, and nothing game breaking, but all the same it's disappointing and most of all I feel like I'm being treated like a moron, and as a result, of course I get a little grumpy and frustrated at times and less faithful that my bug reports actually are taken seriously at all. I don't think that's how you should treat your customers who, mind you, are paying for your product. The least you could do is show some appreciation. I feel this should be addressed and improved. To improve the situation I would like bug reports to be updated once their status changes, not just on the initial reading of the report more efforts be made to merge the reports of the same bugs A notification be given if a report has been read and/or confirmed/reproduced A list of known bugs be published and kept up to date, such that the list be easily checked before posting a report, possibly with status updates such as "fixed for next release", until a proper bug tracker is implemented Be revisited once more information/tracks are provided Be acknowledged again once said information/track was provided Be appreciated more I understand that DCS is a large project and that the forums are big and several bug reports for all different modules come in and that not everything can be taken care of right away, that certain things need to take priority over others. But on the other hand, asking for a track and then no downloads or replies in 6 months, or no comments after several weeks is just not explainable by that. There are several people that are paid to manage the forum. And If i can take my evening to look through the bug report sections of a few aircraft and check for new posts, then so can they. Keeping track of bugs with a forum is generally just horrendously inefficient. Personally, I think a new, streamlined bug tracker system should be put in place to link bug reports and software development closer together, such that when the team finishes working on a bug, the bug tracker is updated for everyone to see, including your customers, allowing the simple merging of reports. There are plenty of good, open source bug trackers out there that will do the job just fine. Integrating them of course would take a week or two, but version control and a good bug tracker will make development a lot easier and more streamlined. Taking issues seriously and being appreciative of the community creates a better environment for everybody involved. People feeling like "Writing bug reports is pointless because they're ignored anyway", and that is a quote from some people I asked before to help me report bugs, must be a red flag. The very fact that they think this way lies in how they perceive the efforts being made here. This must be addressed if you want your community to stay engaged with the product you are trying to sell. We're all enthusiasts in a niece hobby, we're passionate about military aircraft and we're passionate about details. Neglecting those that raise issues with either the product itself or with how things are handled generally will create a toxic environment where everybody is frustrated. I don't want that. What I want is an open discourse with an open company that can be both proud of it's achievements while also admitting to it's faults and failures and that is open to suggestions to improve and criticism. Sorry for the rant.

To reproduce Create a mission with an apache (hot) and a ground unit that moves reasonably quickly and set it to be visible on the MFD Create a waypoint for the ground unit to move to Join the pilot seat Wait for the ground unit to have moved a noticeable distance (> 100m) Have the CPG join the aircraft Compare coordinates

It IS an issue because you don't make the majority of the missions that you play. At least I don't. Sometimes I cobble together something, but most times I just play other people's missions, especially online. It also IS an issue because "Just leave one or two as ref" is what mission makers should be doing, but instead the default is to show them all. The default should be to not show units and opt into showing them. It also IS an issue because ever since this was implemented, the CM database was always completely full, even for smaller missions that just had a few units around bases and farps as flavor, not really doing much. More here:

The problem Loading any mission, even small ones will rapidly clutter up the control measure database. This leads to the crew being unable to add their own CMs as well as be general clutter and unhelpfulness during the mission. The fact that every group creates it's own control measure is the most pressing issue. The fact that the mission editor option is to "Hide from MFD" is not selected by default, or rather that it's not "Show on MFD" and deselected by default. Causes a lot of extra clicking to hide extra units from the map when in reality the mission editor probably only wants to show a few of them by default and, at least the missions I fly for, simply don't bother to click that hide checkmark. It also doesn't help that FARPs and Airbases are taking up a good chunk of the CMs, even though it is very unlikely that you'll ever go to them, especially enemy held ones or those that are very far away and not anywhere near your waypoints. Furthermore, every enemy control measure appears to be Enemy armor, friendly armor or friendly air defense. The apache has a great many different control measures to place down depending on the type of vehicle used. Overall the generation of the control measures is too aggressive, incoherent, cluttered and has no real logic to it. For instance when I placed a couple of trucks down, the contoll measures were generated in order from furthest away to closest, when in reality the one furthest away is probably the least concern. They were also classified as armor, when in fact it was just ural utility trucks without any weapons. The solution Make the option Show on MFD opt in, instead of opt out. By default units are hidden unless they are explicitly marked. This prevents excessive clutter from units that do not need to or make no sense to make available on the MFD, such as units which are mobile and on the move at the time of loading into the aircraft. Generate control measures in the order of relevancy to the mission. For example prioritize units along the planed route of flight. If no route is present, generate them based on distance from the starting position. Generate the control measure type of the most defining unit in the group. For example: - If there is infantry and a BTR, it's mechanized infantry - If it's a tank and a BMP, it's armor - If it's artillery and air defense, it's artillery - If it's infantry, bmp and air defense, it's air defense - if it's infantry and a brdm, then it's a scout - If it's an aircraft in the air, do not generate a airborne control measure because that aircraft is probably going to move. - If it's an aircraft on the ground that isn't just sitting there is is going to take off, don't generate that control measure either Some more thought needs to go into that of course to come up with a reasonable list of units and combinations of units and what you'd classify them as. It might be reasonable to shift that to the mission editor though to only group units that make sense to be grouped and have a different group for a different purpose in the mission. Still a group of BMPs is different from only infantry, and that's different from infantry with a BMP. If there already is a control measure of the same type in a given range (say 2000m), then do not generate a new control measure. So 50 groups of one infantry men do not generate 50 control measures in one spot but rather just one of them. Limit the number of automatically generated control measures to 40 or so to allow the users to add their own if they need to. Generate the control measures once, when the PLT joins the aircraft.When this is eventually implemented, generate them again when they load the data cartridge after a ground rearm/refuel, at which point the cartridge would have been updated. Then when the (human) CPG joins, synchronize the points with him, and not let him generate his own points, potentially different from the PLTs points, as it happens now. Do not generate control measures for enemy farps or bases, or bases very far away that are not near your waypoints. If enemy units are near those, then add those as CMs, if they are of high enough priority (near your waypoints or starting position and of sufficient capability to out prioritize other units) Obviously out of those solutions some need to be tweaked and more thought put into them. But I think it should be relatively easy to implement a few of them, such as the maximum limit to allow some space for user CMs.

I believe this needs to be addressed. Any reasonably sized mission will instantly blow up the CM database.

When the CPG dispenses flares, it does not update the flare counter on the CMWS panel. The actual flare count stays consistent though (ie. you can't dump more than 60). I was the server in the CPG seat, client was PLT Ah64Issues-20230122-190026.trk server-20230123-015155.trk

When joining an aircraft, the control measure points are generated independently of the points already in the aircraft's system. This leads to a de-synchronization when the CPG joins an aircraft after the units for which a point has been generated have moved. Pay attention to the coordinates in the track files. Server was me, in the CPG seat. Client was PLT. server-20230123-015155.trk Ah64Issues-20230122-190026.trk

That did the trick. it also saves the head rotation, not just the translation, so look straight forward when you do that.

might want to move this one out of the bug reports section

No need for commitment. Just find random people on discord and usually you'll have a good time. Wingman Finder (also has multicrew text channel): https://discord.gg/dcs-wingman-finder-454442975590612993 Multicrew Finder: https://discord.gg/Vf4vcjSe Just ask and you might get a replay to hop in with you and fly on one of the many servers that host generic, campaign like missions, like hoggit, grayflag, flashpoint levant, rotorheads or any of the others. or you could self host. Personally, I think george isn't good enough to replace a real person. A real person can handle all the systems and radio comms for you, george can barely shoot straight.

Any news on this? Also not talking about threat rings. I'm talking about shading the digital map in areas that are visible, either from threat points, your own aircraft, or some terrain point and an altitude set via the TSD. This is similar to how the KA50's ABRIS displays air defense threats as colored areas depending on your altitude.

Is this planned or not? Personally I think it would really add a lot of usability to the digital map. For those who don't know, the FFD is a database of lines and areas on the map which are colored on the digital map. Currently the digital map only shows the altitude of the terrain and quite literally nothing else. What the FFD allows is to color in relevant areas such as, but not limited to, Forests Cities Lakes Swamps/Marshland and display lines for Rivers Roads Power lines Railroads All in different colors. Along with other tools, such as vis shading, this would make the digital map a lot more useful, even more so than the current chart map.

When starting a cold aircraft the INU says it's 55m confident. When creating a new point, that new point's default coordinates is on the north pole. The TSD waypoints and routes are visible, despite the aircraft either thinking it's on the north pole or 55m confident about it's position. And when selecting CTR they line up perfectly with the aircraft. The TSD PP (Present Position) is perfectly accurate before alignment The confidence jumps instantly from 55m the second power is applied to a couple of meters after alignment. The confidence doesn't go down anymore (less accurate), even if the INU is reset (new points on north pole again) or power is lost. In fact the INU's position confidence is 0m accurate after power down and restart, except the rest of the aircraft behaves as though it was a cold start after aircraft selection. None of that makes any sense, at least to me. I would expect the INU becoming more confident about it's position over time during the alignment, not instantly jumping from 55m to 7m. I would expect the INU to not know where it is at when the reset button is pressed. I would expect that the present position and the default for new waypoints becoming the INU's best guess and that they are the same. I would also expect the symbols for waypoints on the TSD to shift with the INU's confidence in the aircraft's heading and position. And I would expect the map to be available as soon as the INU thinks the aircraft is somewhere in some area that has a digital map stored, only shifted and rotated according to the INU's idea of where the aircraft is. Maybe some logic applies if the two INUs disagree by some margin that I'm not aware of, and in which case no map is shown and the aircraft is considering itself to be at the north pole. But then I would expect that PP is also on the north pole and any waypoints be a couple thousand km away and thus not visible on the TSD. INU_makes_no_sense.trk

I tried as well, didn't save. What's the keybinding to save a position called so I can check that I press the right buttons? No VR, just head tracking.

When the CPG switches off the IHADS power in the WPN->UTIL page, the PLT IHADS turns off. Is that correct? I thought they were independently operated by the two display processors?

Server track is me, self hosted, PLT. Other track is CPG joining after waypoints were created. Ah64Issues-20230116-145040.trk server-20230116-214715.trk

When joining the aircraft, the center tank status is not synchronized when the cpg joins the aircraft. This leads to a permanent desync. Fuel values in the center tank are synchronized either from the back seat or the active pilot, unsure which, regardless of the valve/pump status. Server track is PLT (Me), self hosted. Client track is CPG joining after aircraft startup. server-20230116-214715.trk Ah64Issues-20230116-145040.trk

From my observations, it seems like the method in which the TADS is synchronized between the CPG and the PLT, is that the CPGs inputs are fed to the PLT and then some complex code is used to calculate the same rotation for both clients independently. I propose that instead of synchronizing player inputs, the aircraft state be synchronized instead. Instead of sending "Man track controller x-axis 63% left for 0.08 seconds", you should just send a new tads camera position. This reduces code complexity and, more importantly is easily expandable later on as new systems to move the TADS are added. Code complexity is what breeds bugs and makes finding them, fixing them and expanding the system a time consuming nightmare. The make my point, current ways to move the TADS are: Man track controller - this is the only thing that always worked, I think LMC - this was initially broken, leading to desync and is now stable Slave to ACQ - this would often have a desynced state initially where it was slaved for CPG but unslaved for PLT, seems stable now IAT, this is currently broken, but at least this is known Others (turn off and on again and such, any others I might have missed) From this track record and other similar bugs is where I draw my conclusions about synchronization, because obviously I don't have the actual code, but this allows for some educated guesses. As you can see, it isn't ideal. A synchronization bug was introduced every step of the way which had to be fixed over months. In the future more systems will be added, which also need to be synchronized, and there is no reason to believe that without changing the method, those will also have problems initially: Laser spot tracker (LST) Radar Link Cued search (unsure if that moves TADS, possibly only with radar link?) Those would solve itself if only the CPG (or PLT) calculates the TADS new position (this code is needed anyway) for each update and sends that to the pilot, instead of the pilot also receiving the button presses and then more code is needed. This would also improve performance because the pilot doesn't need to compute the TADS position and just gets it's absolute value and perhaps a rotation speed from the CPG instead of having to calculate those values based on the CPGs inputs. This also has the benefit of self fixing if a desync does occur. Code exists once, bugs need to be fixed in a localized, private function if they exists. It's a good time for everybody involved. A principle in software design is that one thing does one thing. Let the TADS figure out it's position, then call up that position and send it to the pilots TADS. Whatever the current method is has had led to issues every time a new thing was introduced, doubtlessly adding development time to try and synchronize that system. Had a universal way to synchronize the system been implemented from the start, it would have been a lot easier to implement new methods to move the tads and be reasonably sure that it would just plug in and work, with only symbology needing to be synchronized or recalculated. To put it another way, the things you need to develop: TADS The 8 different ways to move the TADS A single, universal way to synchronize TADS based on where it's looking, with as few special cases as possible, avoiding complexity where at all possible Or TADS The 8 different ways to move the TADS 8 different, error prone (there were errors), complex code paths to synchronize where the TADS is looking based on what buttons the CPG had pressed. Just to me it looks like the second option is a nightmare for maintenance, finding bugs and expanding things. I understand that DCS is complex software, I'm just trying to add food for thought and maybe suggest an alternative way. All roads lead to rome as they say, but some are 3 lane highways and others are not. Please also understand that as a paying customer who has spent hundreds on this software and as a software developer myself, I am frustrated to see those things that to me look like obvious, bad architectural design choices. I don't know what thoughts went into those choices and I can't know. I can't even be 100% certain that those choices are what I think they are even though plenty of evidence points to them, and I don't feel like rummaging through assembly code (probably against ToS anyway). But from my perspective it's just frustrating to watch long times between updates, and every time there is a new sync bug when there is an update.

Still unresolved. Also apparently no one looked at this for half a year. If you are gonna ask for a track file, it would be great if you are going to look at it at least.