FalcoGer

As a human it's not too hard to identify targets visually. I wish george would be more specific in his list. A tor is a different beast from an SA8 or tunguska, which you can just about outrange, but all of them are MR sams.

would be easier if they sent states instead of control inputs and try to go deterministic from there. How do I know? Well when there is a desync with the CPG being slaved and on my end he's not, and he presses the slave button, it get's swapped so he's deslaved on his end and slaved on mine. Or he has a desync on which mfd page is open and suddenly an FMC channel disengages when he presses the corresponding button even if he's on a completely different page. the programmers have decided to send button presses to the other cockpit to try and maintain synchronization. Instead of saying "I turned the laser on" to the pilot it says "I pressed L5 on the left MFD". And if there is a desync at any point in a series of steps, you get hard to track and annoying bugs, in effect pressing random buttons if the screens didn't match. Speaking of that, a workaround to fix a mismatched slave is to make the CPG go slaved on his end. For the pilot it will be jumpy. Then make him go to fixed acquisition source and slave to that. after that normal operations can be resumed. This works because changing acquisition sources will force a state of not being slaved either way.

I don't see what this has to do with display exports. I'm not running display exports and had my engine shot out twice today, both times the status bar on the bottom said 46% RPM even after shutdown. This is an old bug, and I thought it had been fixed. I guess it's a regression.

vulkan is a hardware abstraction layer. it allows a uniform interface for software to access features on the graphics card. in the case of DCS vulkan has the potential for great performance boost as it allows for a rendering pipeline to be split and parts of it to be reused. for example with direct x you need two whole render pipelines for both eyes in VR while in vulkan you can split them off, reducing the workload of your gpu by nearly 50%. Of course it needs to be programmed that way. just using vulkan doesn't mean anything will be better just by itself.

When selecting a point from the coord page as acquisition source with L1-L6, this doesn't close the page when any point's info is expanded. This is especially annoying when having used the "search" feature, because it automatically expands the point info. To reproduce: 1. TSD 2. Coord 3. R1-R6 to expand point information 4. Try to select (any) point as acquisition source with the corresponding button on the left Track attached expanded_point_info_no_coord_close.trk

While the AD target/threat symbol is a thing in the real apache, I argue that having the target/threat file filled up with lots of "AD" is silly. The red clutter reduces situational awareness and finding actual threats is made harder because of it. Another downside is that the limited space of 50 entries in the target/threat file is being used up rather rapidly. Instead I propose to replace the friendly "AD" threat files with friendly "AD" control measures, which will show up as blue instead of red, not take up the space in the threat table and don't give an arbitrary, generic target threat ring, which isn't a threat at all anyway. The Label for those "AD" control measures may be an abbreviation of the sam system in use, perhaps what it's ident would be as a target/threat if it were hostile. Eg an enemy hawk site would be a threat with ident "HK" while a friendly hawk site would be a control measure with ident "AD" and a freetext of "HK". Discussion here:

Some aircraft require to be shut off to rearm them also. I think it's only sane to expand the system to tag individual slots to be not hot-rearmable.

I agree. It should be more clear what options do. Having cryptic names like that shouldn't fly. sorry.

I think it's cumbersome to have special options in the ground crew comm menu. Just include the refueling probe into the rearming screen into a special slot.

I agree. having to bind two buttons just to open the cover (which isn't animated by the way) just to then hit emergency jettison is quite annoying. I'm sure in real life they just slip their thumbnail under the cover, flick it up and press. Sadly few of us have some sort of cover we have on our switches that act as a button when lifted.

I agree. There should be a way to at least allow the option, set globally for the PIC, to have smooth transitions without awkward button presses, mouse grabbings, clickings and such. I never fly with people I don't have some sort of voice communication with anyhow, because it's just pointless.

Later people will want to fly with or without the radar. And people will not want to rely on the mission editor to check that tickmark to include the MMA. I propose against the move to make special cases and adding bloat to interfaces where it is not required and instead integrate the MMA and IAFS/Extra ammo into the loadout of the apache into special slots, such as present in the F18C hornet for smoke. Instead of adding special checkmarks, the MMA and IAFS/Extra ammo can be included into such special slots in the loadout screen. This wouldn't just remove an extra checkbox from the mission editor. This makes the ME less complex and confusing and the mission designer can't forget to check/uncheck the box. This would also allow more flexibility for everybody involved. For instance such an approach would tie into the stockpile system already in the game. Having a limited amount of radars available. It would also tie into the existing system of prohibiting the equipment if the mission designer really doesn't want the apaches to have a radar he can just forbid it. Most of all it would automatically allow anyone who flies to change their configuration on the apron/farp as the situation demands without the need to change the mission file or to provide identical aircraft with the only difference to be the internal configuration. To top it all of it would also immediately integrate into the weight and balance system in the rearm screen, showing updated weights. Don't force people into what the mission designer has to pick. If he wants to lock down the options, then he's free to do so with the existing prohibited equipment system. But if he wants to provide all options to the pilots, then the current system just doesn't work. The other approach to solve this that I see is to add special cases to the ground crew menu to install/remove the MMA and/or IAFS. But special cases are bad because it takes time to develop, things go wrong and it's inflexible if you want to expand later on. Use the existing infrastructure, don't invent new UI where it isn't needed, give options. Of course adding the MMA is a special case. It shouldn't be done while the engines are running while other armaments may be loaded or exchanged with spinning blades. I still think it's better to be able to tag different slots to be hot loadable while others require a cold aircraft and expand the capability of the reload screen rather than invent new wheels.

Yes. I want to play that specific mission that doesn't include the radar. The solution is clearly to make my own mission to have the radar. That was sarcasm. The solution is to have the MMA equipable while the mission is going, preferably through the rearm screen as that then ties into the forbidden equipment feature from the mission editor if the mission designer really wants to prohibit radars. It would also tie in nicely with the weight display. The only issue is the aircraft having to be shut down for the MMA to be added or removed but other stores being able to be replaced with the rotor spinning. I also plead for the same system to be used for the aux fuel tank/extra gun ammo. Why invent extra stuff and special cases all the time when you can use the existing system and expand the capabilities of that.

LMC keeps relative motion to the target. For that it needs accurate ranging. Jumps in ranges will result in jumps in angular speed of the tads. Which is also why you need reasonable ranging before you first turn it on.

This happened to me a few times and I find it somewhat annoying. When I have a target stable in my crosshair with LMC enabled I keep on firing muh lazor, as one does to do a LOBL SAL hellfire shot. Then when the missile comes off the rail, it sometimes happens that the laser hits the missile. This causes an immediate jump in target range from several thousand meters to a couple tens of meters. The LMC now thinks the target which before had a relative motion is suddenly much closer and the TADS needs to move at light speed to keep up with it. Suddenly the laser points all the way left, I loose the target visually, the missile goes stupid. Is this realistic? If so, how am I supposed to do a LOBL shot with LMC on? What should I do differently? It happens rarely enough that it's not a massive deal, but often enough to be really annoying when it does happen.

Refactoring: Changing code so it is more readable without changing behavior. Performance may change in either direction. Optimization: Changing code so it is more performant without changing behavior. Readability may change in either direction. Not optimizing: Display worse graphics to make it go faster. Example optimization: Use the same model and texture for both rifles to save on memory and disk space while giving the same result on the screen.

By giving the target/threat point the ident AD, you label it to be a generic, friendly air defense. Any "threat ring" it gives you would be a arbitrary, generic value, which of course has no relation to the actual site and it's capabilities. Also you need to differentiate between a target/threat point with ident "AD", a control measure with ident "AD" (which is blue and which I think is more desirable) and the actual air defense sitting there and threatening things (not you), which you abbreviate as AD multiple times. Great. Now that that's cleared up, I still think it's an issue of having them on the TSD and would rather have blue symbols (aka control measures with the sam type as label). Threat rings don't give you any info anyway, having them in CM helps clarity and SA and allows for easier deletion without the risk of deleting actual threats and leaves more room for actual target points in general. Gepards should be a threat symbol "GP", which will give you the actual threat ring for a gepard adu, if it is hostile. Otherwise a AD control measure with label GP would be fine, because there is no such thing as a blue target/threat symbol with GP to give you the actual threat ring. Again AD threat rings are an arbitrary distance and don't give you any valuable information. Until we get a mission planner to put down points, lines, routes, radio presets, counter measure presets and so forth, I think this is the easiest and fastest solution.

It's not unreasonable to think that there are 50 manpads strewn about in a large city. And suddenly you got yourself 50 threat points on your hand. I like to fly on rotorheads. People deploy air defenses on captured positions and throughout the map. There really are a lot of units. It's also not unreasonable to deploy 2 or 3 AAAs, 2 or 3 short range sam systems and a long range sam on an airport. and suddenly you already have 7 threat points. You do that with 5 airports and place a few around in other places and you're already full on the threat file. I think you exagerage.

How they work is classified. Their capabilities and what it looks like on the screen is very much publically accessible. For instance the RFI threats are shown on the inner box/circle of the TSD/ASE with a special symbol that looks like "X X" for a coarse detection and with an arrow between the Xs for a fine detection. A fine detection is possible in a specific arc in front of the RFI antennas. The RFI coarse and fine detection areas are shown on the RMAP and GMT pages for the FCR page as well. Up to 10 such tracks can be displayed at any one time. The primary RFI threat is highlighted. You may press the cued search button to slave the radar to the primary RFI threat and attempt a correlation. That will switch the radar to GMT if not already in GMT or RMAP mode and set the scan width according to the target emitter. You may select any RFI threat with CAQ to set it's bearing as your aquisition source. I could go on and on about this. You can read all about how it looks and what it's capable off. As long as ED models that, I'm happy. There is neither a need, nor are our computers capable of handling the simulation of the individual antenna elements, FPGAs for signal processing and electrical signals in the wires. I'm not talking about the RWR or RFI anyhow. I'm talking about the target/threat symbols with ident "AD", which stands for "Friendly Air Defense". This is nonsense, since a friendly air defense should never be a target or threat. I propose that it should instead be a control measure with ident "AD", which WILL show up blue on the map, giving better SA. You can still correlate RFI and RWR. You should care. After all it's a SIMULATION. So it should be as close to the real thing as one can make it. Indeed. That's why i propose not to put it into the target/threats file but instead into the control measures file, because it's not a target/threat, but you still want to know where they are. The thing is, if the target/threat symbol for friendly air defense is red in the real appache, then it should be red here, too. But in that case, I think that having a red symbol is counterproductive. I would much rather have a blue symbol, and a CM is the way to do just that. Because friendly control measures are, in fact, presented in blue on the TSD. Friendly units are not targets or threats, and thus should not be classified as such. Especially automatically.

I mistyped. Unknown is yellow of course. The symbol being a cloverleaf type thing.

I was under the impression that STT is shooting a single, narrow beam of maybe 0.1°-2° at a target, ignoring everything else to allow for a high refresh rate. Given that physical reality, I would also think that RWR indications should STOP for everybody outside that cone instead of going ballistic. Please fix. Some of those reports are 5 (!!!) years old, and it's quite annoying.

All control measures for enemy units are red, while for friendly units they are blue. Those are default nato symbol colors for friendly/enemy units, with unknown being yellow and neutral being green. All but AD in the target/threat category are of course in the "targets and threats" list. But a friendly air defense unit is neither a target, nor is it a threat, thus a placement in this category is silly. The fact is though, that the apache has a threat symbol for AD and it means Friendly Air Defense. Unfortunately ED decided to plaster it all over our MFD, and since it's all red it's very hard to filter out. The -10 manual doesn't explicitly say which color the symbol is and all the diagrams are black and white and I couldn't find any other information. It's friendly, and the apache's MFDs are capable of displaying blue icons, and friendly CMs are colored blue, and having it red would mean more filtering and workload required for the crew. Considering all these factors, I think a smart design decision would be to make the AD target/threat to display in blue. ED displays them as red, as is every other target and threat symbol, all of which, but that single one, make sense to be red. Is the red coloring correct? If it is, I would like the automatic ADs replaced with AD control measures (still friendly ADUs, but in blue, with the default nato symbol for air defense), with a freetext name that reflects the type of ADU. This leaves the target/threat list more spacious for actual targets and threats while providing better visuals and SA for the crew by not showing a sea of red, half of which might be friendly. If it is not, I would still like to see friendly ADUs to be put in as control measures, just to keep the threat list for actual threats and targets.

Clearly instead of trying to sync the aircraft state at the start and then tracking user inputs, they should just send aircraft states between the stations.

What is The NOE/A mode doing? I read that it's the NOE/Approach mode for the FCS and i gather it has something to do with the stabilitor but what does it do? Apparently it doesn't automatically engage with engine start when weight on wheels (but would turn on when power is applied in the air if that was the last state it was in)

When playing in multicrew on a server where neither pilot is host, the cpg can not use the keybind to engage the night vision scope (the default light amplification goggles). The same keybind works just fine when in single player and switching seats.