FalcoGer

I want to do the reports. I want to help. But if people think that of you, then it's no wonder they're getting attitudes. Come on, hop into the cockpit with me, it'll take 15 minutes and you get 3 bug reports in one track.

It's the truth though. I asked 5 people, and every single one said. "Sure, let's fly and do a mission, but I don't want to do bug reports." It's also true that this should not fall on the shoulders of your users. We do it anyway because we like the product to get better. All I said was that I'll get back to you with a track, since you put a lot of value on that, apparently. I mean if this is the sentiment your users are getting, then clearly something is wrong. null

When in the Inst subpage on the TSD, the HDG option allows values from -360 to 360 inclusive. It also allows decimal values. It seems a bit strange, but might be intended. Should probably check if it's accurate or not. What's also strange is that "-360" results in a display of "0" while "0" and "360" result in a display of "360", which is definitely a bug. Either with ED or the apache. Track attached. INST_HDG_strange_values.trk

When the pilot disables one or more FMC channels in the A/C Utility menu, this is not reflected on the CPG's side when he joins. May only happen on dedicated, not tested on local. What's more, when the CPG then disables the FMC channel on his end, it is turned on for the pilot. The status of the FMC should be synced, not the button presses. Unable to provide a track because people would rather fly and have fun instead of tracking down bugs with me for no compensation. Once I find someone who is willing to spend their valuable time for testing that should've been done by the devs in the first place, I'll upload a track here. In the meantime, feel free to test yourself for a change.

Not sure if it happens locally, but on a dedicated server, after the CPG leaves the seat, the pilot with george as CPG can no longer create waypoints. I've heard, but not tested myself, that you also can no longer add points to a route. When another CPG joins again, it works once more. Unable to provide a track, because people would rather play their game instead of wasting their time with me to track down ED's bugs. Once I find someone, I will make a track for you. In the meantime, feel free to test it yourself.

Sorry, i had a few words missing there. What I mean is when you disable the "Trim" option in the FMC section of the A/C utility page, trim doesn't recenter the stick anymore. Since there is a disconnect between the real apache stick and our hardware, that's an issue. If it's not an issue it's at least inconsistent with the behavior of the center trim cheat.

When disabling the "Trim" function in the A/C utility page under the FMC section, the trim button doesn't work anymore to set the stick center position even with the "Central position trimmer mode". The issue with that is that the real apache stick is held in position when the trimmer button is pressed while that is not the case with the strick I have here, springs still inside. On top of that the center trim cheat command still works to reset the stick to center, but you can't trim it anywhere else unless you re-enable the trimmer in the helicopter. So which one is it? Can you put the stick in a new center position or can you not? fmc_trim_nonsense.trk

So I was getting annoyed with the collective FMC channel doing whatever it pleases and so I just disabled it. Then I noticed that I'm still getting the tone and advisory, even with all fmc channels turned off. Curiously I wasn't getting a tone with the magnetic trimmer disabled. fmc_nonsense.trk

Not sure if correct, but even with the collective channel turned off, the apache displays symbology and advisories for altitude hold. When other channels are off, engaging the attitude hold modes is not allowed and no symbology is displayed. seems inconsistent but not sure if correct or not. fmc_nonsense.trk

Even when only making small adjustments, the collective FMC channel keeps running away. Maybe I don't understand it right, but it feels very annoying. On top of that it also makes adjustments outside the white region indicated by the controls overlay. fmc_nonsense.trk

I guess I was wrong once more. Thanks for clarifying.

I think it's less likely a problem if the direct to being set is in the alpha flight route. Requires more testing though. Didn't check latest patch yet. Most problems seemed to occur when setting a direct to for a new waypoint that isn't in a route or a new target point that wasn't in the database before.

Only the inner pylons can connect to the main fuel tanks. the outer pylons can only pump fuel to the inner pylons. Did you perhaps attach the fuel tanks only to the outer pylons? In that case you won't be able to select them.

The newer apache variants adopt the more sane "change the standby frequency only" strategy, which is how radios with a frequency buffer typically behave in aviation radios. For the 64D-2 we have, this should be correct as is now.

pretty sure two patches ago the standby frequency wasn't changed when you typed a new one in.

I did some testing. It works fine as I described. Putting in a new frequency now puts it into primary (which is a bit odd, but that's how the old apaches worked), pushes the old primary to standby and the old standby to oblivion. I haven't noticed anything odd when switching yet.

is :00 right? looks odd. Also I reported that a few months ago, but no one wants to listen and it's always "need track replay" with you guys. Well not always. Just always when I report a bug, despite a step by step description and 100% reproducibility.

When the CPG uses the laser, the pilot's helmet shows range source to be the laser (*) and the range is the laser range. I understand this is how coop rockets should work (??), but even when the gun is WASd, the laser range updates the range for the pilot, which seems wrong. Is that correct behavior?

I understand it's to practice with the pnvs and sensors. OP said they use the bag without pnvs. thank you for clarifying.

Again, AH-64 is not rated for IMC/IFR. You can fly at night, but you can't fly in no vis (cloud, fog, dust storm, night with pnv+tads failure). The GPS is not certified for the level of precision necessary and the radar is only to be used as an augmentation only, not as a replacement for visual reference.

To clarify: The apache uses letters to identify laser codes. You set your LRFD/LST and missile seeker's to lase on or search for those codes by letters. The actual laser code is identified by a number. You can assign valid numbers to each letter. For example if you have your missiles and your own laser on some letter, say "C", you can change the code for C and all associated laser codes that are set to C will change accordingly. The actual laser will pulse in specific patterns described by the numeric laser code, which is what laser trackers or weapon seekers will search for.

Okay, I have figured out what is happening, I think. This is two bugs. As CPG (not sure if pilot is affected) in multiplayer only, using CAQ will select the marked point as acquisition source, but then immediately switch to an invisible terrain point (T56). The pilot will only see the selected point, not the terrain point. The terrain point is invisible, but hovering the cursor over where you clicked enter will show the white cross with "CPG" in the center of the screen with the black circle on the cursor indicating a valid selection option. The other bug is happening as CPG (not sure if pilot is affected) in multiplayer only also. When selecting a point from the coord page and it's not from the first page, it seems to select a random point. Here is a track from both pilots. The problem occurred around the time of the second (?) mission I think, where we were to engage an APC near a compound. CPG was host: https://drive.google.com/file/d/1damWLSp2HNUDn3cyl5ojqfup1ALG98-2/view?usp=sharing **Edit** Turns out it's more complicated than that. It's weird. Here's a video to go with it (1:34:50).

Today this happened to me. I was trying to set the acquisition source to some target points. I tried CAQ, but it would briefly select the point under the cursor as acqusition source then switch to T56, but without creating any terrain points. I don't know what the TADS was slaving to, it certainly wasn't the point as indicated by the nav range. Then I tried directly going for the point numbers in the COORD page. That was a complete mess. It selected any random target point except the one I wanted. I am not sure what happened. Track file is too big to upload and too big to be useful, but I have footage of the issue, which happened at around 58 minutes and 20 seconds. I'll try to get a track as soon as I find someone who will ED's job of testing and bug reporting for them (for free) with me.

I downloaded the installer for the dedicated server. When I first ran it, it said it wanted 50GB or so of hard drive space. So I made that space by deleting some stuff. Then it would install. Then afterwards, it popped up with "start download now", which of course is what I wanted. Then It told me I suddenly need 160GB of storage space. Could you please make up your mind BEFORE you make me uninstall and remove stuff please? Also would be great if I could install only what I needed. If I am never going to host missions on certain maps then there is no point in downloading the terrain data for those maps. Hard drive space isn't free you know. Would be great to have an option to not install everything.

Dedicated. Either way if ED's programmers had any sense it shouldn't matter. But then again you get funny bugs like switches behaving differently depending on if the power is on or not. And I don't mean like solenoid held switches, but the windscreen wiper knob. Or funny bugs like the radio selectors working differently depending on if it was a hot or cold start. Ridiculous. In my opinion they should cease all feature work for half a year and instead do a big refactoring, and then nothing but bug squashing. There is so much apparent code duplication, and every copy is behaving differently. Sure, it would stall stuff out, but in the end all future development would be a lot simpler, faster and bug free. And if there is a bug you need to fix it once, not everywhere you copy and pasted your faulty code. And then you write a unit test to prevent regression. ED's developers do an amazing job, giving us the best combat flight sim there is. And then you get stuff like this that just shows what a catastrophe the codebase must be. You get the same sensors providing the same information to the same screens. And yet there are 2 different results in the same aircraft. This should be impossible. But yet here we are, 2 different implementations for the same thing in the same aircraft. One works, the other one does not. If they do use the same code, which they should, then the code doesn't get the same input. Otherwise it would produce the same output, clearly.