FalcoGer

Perhaps another approach could be saying it isn't working when in fact it isn't implemented at the time. I think that would be more accurate, realistic and avoid some confusion (while admittedly causing different confusion). It also isn't wasted effort on the programmer's part as the "failed" messages could pop up when the equipment actually fails later when it is properly implemented instead of ripping out the old placeholder and putting something new in, the old system now being essentially useless, the work done to create it worthless. Another example: Say IFF isn't implemented at the time. You get an IFF bit fail on startup, letting you know that it isn't working (which it isn't). Now IFF does gets implemented (we hope). But you can still use the code of non working IFF if you zero out your codes or if your IFF equipment gets shot up. That said, not sure how that applies to ice detection and if there is any indication of anti ice equipment not working or if there is any test in the apache at all. For all intents and purposes, there is 'no ice'. So maybe it should just say that, even in the clouds at -20°C

I find it curious why they chose to cycle no indication, light, medium and heavy icing every few seconds instead of just displaying nothing until anti-ice is properly implemented. It just confuses people. Though it is funny how you get "Heavy" icing in Dubai at 40°C FAT.

I don't understand this Vx thing. Isn't the best climb angle for tight spaces 90° up? Infinite height for 0m over the ground, basically altitude/distance, but distance = 0.

It's supposed to remember the last video setting and only show the menu when no video was selected or when you open the menu with the R6 button if video is showing. I have however noticed the menu popping up for a very brief time when it tries to show tads after selecting the VID button. I haven't tested other video sources though. Only after that it disables the menu like it should.

Would be nice if such stuff is in the change notes so it avoids confusion like this.

If all internal tanks were full, wouldn't the limiting factor be the fuel flow rate to the engine, which should be identical, thus leaving both sides of the external tanks with the same amount of fuel until they're both dry? I mean why would you put on external tanks when there is room still in the internal tanks? I don't know much about the apache, but it would make sense to me to fill up the aircraft first, then fill the external tanks to whatever is required instead of filling the external tanks full and then filling the aircraft halfway, leading to a fuel imbalance. I haven't done any experiments with the tanks though, aside from putting them on for weight, which is horrendous. They're pretty useless in DCS aside from science. Aside from that, why would you put on external tanks anyway? A full fuel load gives you nearly 2 hours of flying time and it's not like you can take off with 4 external tanks anyway since you'll be so heavy that you can't hover, even IGE. You're going to run out of munitions long before you run out of fuel and anyone who designs a mission should know better than to have a 1 hour trip to your target, since that's just boring.

It would be nice if this was patched in a somewhat timely manner as a hotfix, even rolling back to the old version until the flight model has been fixed is better than the current state, or maybe just officially edit that fmconfig and remove the vrs effect for the apache for now and put it back in after testing for any game breaking effects such as this one. Any workarounds by editing the FM by hand of course results in a failed integrity check. Since I only play online, this is not an option. This bug makes flying rather impossible. I'm no real pilot or particularly skilled, but before I was able to be relatively stable and allow engagements, now the aircraft breaks away, I loose control and even full left rudder doesn't do anything except driving my power requirements to 120%, at which point I must decrease collective, causing me to sink. Then suddenly the aircraft seems to think: "Oh you want full left rudder? sure, here you go." and it yaws hard left, literally trying to kill me. What little control I had left at the time now goes out the window and I loose another 200ft to recover, because of course I need to build airspeed and drop my collective to avoid the rotor to stall out. Any missiles being on the way at the time are of course trashed. This is completely breaking this aircraft and make it unusable in a hover, only allowing running engagements. And it's not like this only happens every now and then, it happened every single flight for me since the update, both with and without wind and everyone I talked to also experienced this issue in short order after the update. It's literally impossible to hover stable for more than 15 seconds or so. Disabling the yaw SAS channel also does nothing to help this.

I don't typically change the symbology when CPG, since I'm watching TV anyway and changing symbology messes with the pilots helmet display as they are synchronized (are they supposed to be?). But I have noticed that as pilot they symbology will change twice in rapid succession, which has been a bug with multiple other things. Maybe there is some deeper root cause that needs fixing instead of patching individual buttons that don't work all the time. All of those things also have in common that it only happens in multicrew.

That wording is a bit off, but I agree. More options are always better. At the same time you can't clutter the UI. Again, the best solution would be to just allow people to place that stuff where they want it, if they want it, before they take their slot, or better yet is just available on any friendly airbase in the escape menu, and save it in a local file, able to load it later once more, possibly with some sane preplaced points that may be moved or deleted or with a simple button that just clears everything. After changing your points in that mission planner, you just reload your DTC and you get all the nice things that we can't have right now. Also the problem with your approach of special options is that you might want different settings for different missions. And the problem with that is that the mission designer then needs to take care of setting that, which is almost always a bad choice. They might not care, the mission designer getting very specific settings that make no sense in some or most contexts, just cluttering things and making things confusing. The solution I proposed was just to fix the immediate problem of getting literally hundreds of CM points that give you no benefit at all and cause all manners of problems. The specific problems I have with preloaded locations are I can't make my own because the database is full It takes the fun away in finding where the enemy is Of course some such locations should be placed, if it is briefed or just makes sense if you know it. If your task is to engage a specific enemy armor group holding at a point, then of course you want that CM on your map. I think another solution that should be relatively easy and quick to implement is to just invert the checkbox in the mission editor. "Show location on MFD" instead of "Hide location". Then you specifically can design your missions around units that you want the pilots to know about as a special state instead of a default state. That way any dynamically generated units just don't get that flag set and are hidden by default. Also if the mission designer just didn't care, then you don't get clutter either way. So it all comes down to "DTC please", I guess. It's such an important feature to add for so many aircraft and for so many reasons. Being able to edit waypoints, CMs and TGs, lines, areas, radio presets, chaff and flare presets, pre planned weapon targets and so forth in a nice GUI while on the ground and in game is one feature that's sorely missing and that really should be a thing for all aircraft that have any sort of internal storage for data of any kind.

It is kinda hard to find material showing how a particular system works, adding further constraints just makes the whole matter more complicated. If you have some footage of IAT being used in a training environment or some army instruction video feel free to replace the video with one that shows the same thing without the killing. But the reality is that weapon systems are designed to destroy the enemies ability to fight, and that includes killing them. If people don't want to watch the video, then they shouldn't click the play button or follow the link, but those people were killed either way, if you watched it or not and ignoring that fact by looking away won't change that. Besides all that it's blurry enough, it might as well be censored. I for one am glad that I now understand what it's supposed to look like and get a general idea on how it works. I mean was anyone complaining about it? Edit: I thought you meant the video with the vehicles that is still available up top. Not sure if my rant applies to the one you deleted.

I don't mind auto populating friendly troops. What I do mind is that it just eats up the entire database of points. I don't need 10 clustered CMs to tell me where a friendly airbase is. A single CM would be fine. I suggest a solution that groups unit groups together into one CM symbol if they are within say 5 nm. The symbol to be used should be indicative of the most relevant unit in that group. If there is any medium to long range air defenses in that group (hawk, nasams or patriot) then "AD" should be used, because then you know you can go there for cover. Otherwise a nice priority list would be naval, air defense (excluding manpads), AAA, armor, artillery, mechanized (apc & ifv) and infantry depending on the type and in that order. For example there are 4 groups on a blue airbase, all within a circle of 5nm. A group of infantry standing near the apron for looks, maybe a manpad or something, a group of trucks and humvees and support vehicles, a patriot site with a vulcan, a group of tanks. Then just plonk down a single AD on the patriot and ignore anything else within a 5nm radius of it. The algorithm to generate those points, very very roughly, could look something like this: Loop through priority list [naval, air defense, AAA, armor, artillery, mech, infantry] loop through coalitions (in order: friendly, hostile, neutral) if (current priority == air defense or current priority == naval) and (coalition == hostile), then loop through all air defense types, sorted descending by engagement range loop through all groups in coalition if (not hidden on mfd) and (group contains current air defense type) and (distance(unitLeaderPosition, nearestTGalreadyPlaced) > cutoff for enemy air defenses) and (number of TGs < limit), then generate appropriate TG and place it on the unit leader else // not enemy air defense loop through all groups in coalition if (not hidden on MFD) and (unit contains unit type of current priority list item) and (distance(unitLeaderPosition, nearestCMalreadyPlaced) > cutoff for enemy units) and (number of CMs < limit), then generate appropriate CM and place it on the unit leader The distance cutoff may be tied to the unit type though, for example naval formations tend to be larger in scale, but then again, they should also be in a single group, only to generate a single CM anyway. This approach has a few benefits. First of all, of course, it doesn't clutter the database with lots of groups clumped together, as it often happens. You don't really care that there are 20 groups sitting at a farp. What you care about is not to shoot them and knowing they are friendly. Obviously there are instances when you do care about such things, for example if there is also artillery sitting on that farp, you might wanna call for fire and knowing it is there is helpful, but then again you should probably be briefed about it in the first place. But more often than not, you do not and you just need a general overview of who is where. Secondly it mostly provides the points in an order that you care about. so if you do run out of space for CMs, you don't get random hostile infantry on airports 500 miles away, but instead you get air defenses and tanks first. It also generates TGs mostly in the order that you care about, although I was just quickly hacking together a solution to fix the immediate problem. There are better ones that uses a different priority for enemy air defenses, for example a metric that takes into account the distance from the spawn point, the distance from the planned route (mind you, not just the waypoints) and the engagement ranges for those sams. Because, again, you don't care about that SA10 200miles away as much as that AAA sitting on your route between WP3 and WP4, even if it has a way larger engagement zone. Of course you don't just want to take into account the waypoints, as dynamic sessions often don't have any or just generic points of interests that have nothing to do with the missions that are generated. A different, more viable solution may generate a more complex metric for every group deciding how "relevant" it is to you. Then CMs and TGs are generated in the order of relevancy decided by that metric function. Again, the lone infantry 500 miles away is probably not going to matter a whole lot, but that SA15 15 miles from your route and the AAA sitting right on WP6 might be a lot closer in relevancy for you. Whatever the case though, please do not generate unneccessary CMs. If you do have the database space, sure, feel free to generate 6 CMs on a farp. Just make sure that at the end of the process there are a few slots free. Additionally I propose that there should be a maximum, say 30 or 40 CMs placed, such that you have some space to work with for manual points. Furthermore a cutoff distance should probably be used, say 100nmi, beyond which no CMs are generated, because it's unlikely that you have to fly that far, and if you do, your CPG has plenty of time to punch in the numbers on the way. Of course the most optimal solution would be that no control measures would be generated at all and there was some sort of interface that allows you to plan your missions, in particular on multiplayer, where you can edit waypoints, place control measures, lines, areas and target points yourself on the map, change preset radio frequencies and most importantly save the whole thing to be loaded again after you inadvertently forgot to place that SA13 target point and ran straight into it instead of having to do it all over again.

It seems that: < 10 000m displays the actual range 10 000m - 15 000m displays "9999" > 15 000m or sky doesn't update the display at all, but should be 9999, which is the bug. Also do you really need a track replay for something like this? I've seen you accept reports without one, and this really is very simple to test. In fact it's hard not to notice when just flying any mission at all.

I know it was reported before, but it was also reported to be fixed before. And I don't think anyone got a good track of it either yet. Also excuse my ridiculous flying. I was just messing about, really.

Seems to be illusive and random. I doubt I can replicate it in a short track myself. If it is related to the damage, one might be able to replicate it by having the part fail in a scripted manner. I might test that later.

i clicked it with the mouse. The key binding is empty. The bug occurs for me in dedicated and self hosted, even as the host, and is 100% reliable on all maps, hot and cold start aircraft.

Here is the track. I was host and CPG. I also made a video in case it doesn't show in the track. https://www.twitch.tv/videos/1583698322 server-20220906-202617.trk

This issue still persists. I got lucky (or unlucky) and got hit in just the right way due to reckless flying while messing about and got hit in just the right way. It even happened during singleplayer. Also in the track is me not getting shot anymore by the LPD, or any other enemies after that hit occured. And the AI wingmen don't do what they're told to do either. Here's the track. Or rather here would be the track if the track wasn't 5362kB and thus I can't upload it. I also can't upload split archives because apparently "file type not supported". Would be great if I could upload the track here. But here you go. I'll probably delete it in a few months. https://drive.google.com/file/d/1WLkqLROhebuM8huMLFQsF6lqCsPYsf7w/view?usp=sharing

Issue happens only in multicrew. I'll try to make another track.

I found that joining again makes it work once more, even a different CPG joining again works.

I don't think it's related. when joining, it just assumes the FMC to be in some state, and it's never synced to begin with. Either way, I don't think button presses should be syncronized to begin with. It should be the intent sent to the aircraft that should be syncronized. If CPG sends "FMC Coll OFF", then that should be sent to the pilot, not "L4 pressed" related, but closed.

I was flying on a mission, we were shot and the radar altimeter failed, the display reading a static number. Because I would rather not be given false info I asked the CPG to turn off the radar altimeter. After he did so on his end, it was still enabled on my end, but instead the FMC Magtrim turned off. Sadly no track, as it's 270MB large. Testing with local server behaved as expected (radar altimeter turned off as designed). May be dedicated only, or might be related to the load, at the time I was running 12FPS.

After leaving his seat, the windscreen wiper was moving for the CPG seat on external view, but CPG never touched the wiper knob. Also the pilot doesn't see the wiper moving from inside or outside when that happened. server-PLT-fmc-sync_no-points-and-route_wipers-moving-no-input.trk client-CPG-fmc-sync_no-points-and-route_wipers-moving-no-input.trk

The FMC channels are not syncronized when the CPG joins. For him it's always all channels on, except for NOE, no matter what the status is for the pilot. To reproduce 1. Pilot enters aircraft 2. Start A/C 3. Disable FMC channels, for example pitch, roll, yaw and collective 4. CPG joins 5. CPG sees all channels in default configuration 6. Any changes toggle on both sides so that they're always not in sync, ie. if the CPG turns something off it turns it on again for the pilot. Tracks attached. server-PLT-fmc-sync_no-points-and-route_wipers-moving-no-input.trk client-CPG-fmc-sync_no-points-and-route_wipers-moving-no-input.trk

Here is the track. Contains multiple bugs, but you see me adding waypoints before the CPG joined, after he joined and trying to add some after he left. Setting direct to doesn't work and editing the route doesn't work either anymore after he left. client-CPG-fmc-sync_no-points-and-route_wipers-moving-no-input.trk server-PLT-fmc-sync_no-points-and-route_wipers-moving-no-input.trk

Also when entering "0.1" it displays "0", which I find curious.