FalcoGer

consider this a bug report on camera position not being the same for replays then. Aside from graphics settings, the replays should be the exact same thing, no matter the settings of those who play it.

would be nice if this got pushed up the priority list. because this is ridiculous

The BRU brightness in the PLT seat is controlled by whoever last set their brightness knob. The same goes for the CPG. This allows the CPG to set the brightness for the pilot, and the pilot to set the brightness for the cpg. This is the case both in SP as well as MP with george (and seat switching) and with Multicrew. To reproduce: CPG set PRI brightness MAX PLT set PRI brightness MAX PLT enter boresight mode and observe BRU CPG decreases PRI brightness Obseve PLT BRU brightness decrease according to the CPG brightness setting Track attached CPG_head_pos_and_BRU_linked.trk

I don't know why this isn't reported yet, it's very blatantly obvious, or maybe it was, but I didn't find anything that seemed related. So here we go: When entering the CPG seat, the default camera positon is very far forward and to the right of the center, to the point where you can't even see the buttons on the left MFD. This has been confirmed by multiple people that I spoke to. To reproduce: Disable head tracking or use rotation only head tracking device Enter aircraft Enter CPG seat Observe camera position Workaround: Every time you enter the CPG seat in a new aircraft, use RCTRL + RShift + numpad to shift the camera default position. Track attached. Just a guess on my end is that It might have to do with an attempt to fix the CPG head 3d model position being stuck in the seat cushion, but the camera position was also moved, or moved instead. CPG_head_pos_and_BRU_linked.trk

I agree, those need additional help to make a smooth transition. But my solution works for cyclics with springs, which is what most people use. it also doesn't hinder any additional method (such as a controls indicator for matchup) for springless cyclics. It should be fast to implement quick and dirty (have george trim during handover) and immediately fix the problem for everybody who uses the default trim method. Later when george uses trim properly during flight, which would take more changes and more time and is less of a priority, this quick solution can be taken out. A controls indicator for the other cockpit would be helpful in any case, even without george and a real human, particularly for those without springs.

The easiest solution (for players) would just be for george to use the trim, such that when handover occurs, neutral stick and pedals are what the last inputs were from george. This has the added benefit that that is how a real human would handle the aircraft anyway. Furthermore you don't depend on overlays and helpers to kill your immersion.

@Raptor9Could you please clarify whether that is a game design choice (in which case I think it should be changed) or a thing the real aircraft does (in which case that's fine)? Do you mean to say that, in the real aircraft, when the CPG sets in his rocket quantity, then that doesn't update the setting in the rear unless coop is selected? That seems like a strange design choice since gun salvo size is updated. If that's how it is though, I have no issues. Or to put it more clearly: In the real aircraft, if the copilot sets a rocket quantity, does that immediately affect the rear cockpit's setting or not? If the front pilot updating the rocket quantity does set the rear seat's quantity as well in the real aircraft, then I consider this a bug. If I ask my human CPG to set a rocket quantity, I would expect him to do that for me, even if I have no intention of using a COOP engagement at that time. Same with guns, just as I would expect him to set a direct-to waypoint for me even though he isn't going to fly there himself. If my CPG has nothing to do and I'm busy flying the aircraft, then I have no problem letting him set up the aircraft systems, update waypoints, clean up target points, set the altimeter, gun burst length, laser codes, and such. And rocket quantity is one of those things that I like to delegate because I'm busy flying, the CPG is idle and bored. And if I say, set up rocket salvo size of 2, then he does it for me, even though I won't be shooting rockets for another 30 minutes. Then when I do shoot my rockets, I expect things to work the way I asked for. That's how I see it. Thus him saying "Setting rocket quantity to X", and then when I shoot my rockets and it's not X, that's a bug.

When asking george to update the rocket quantity, he doesn't actually do it until the pilot also selects the rockets while he has rockets WAS-ed. This can create a scenario where the pilot assumes the rocket quantity is set to what was asked of george earlier and then using rockets when george is not on rockets himself using the old quantity setting. To reproduce: PLT WAS rocket George ask rocket QTY to ALL PLT De-WAS rocket Make sure no target is tracked Ask George to set rocket QTY to 1 Ask George to De-WAS to laser only WAS rockets yourself Press and hold trigger All rockets are fired despite george "setting rocket quantity to 1" Track attached. george_rocket_no_update.trk

OSB T6 doesn't update when switching to "No Video" on the video select page. To reproduce: Go to VID page Select TADS Select No Video Observe "TADS" on T6 Repeat with other options in step 2 Observe T6 sticking to whatever was last selected Track attached. vid_src_no_update_on_no_video_selection.trk

When no generator power is available and george was asked to track a target, he will spam the "Aircraft Armed" message over and over again. steps to reproduce: Turn master arm OFF Ask George to track a target Ask George to laze the target Go to A/C -> ENG -> SYS and disable both generators Listen to George's insightful commentary about the power failure Track attached. apkws_mws_and_armed_spam_no_gen_and_armed_status_mismatch_mfd_button.trk

When shutting down the aircraft while master arm is armed (gnd ovrd) and then starting the aircraft again, the button indicates aircraft safe while the MFD indicates aircraft armed. Steps to reproduce: Enable ground override and master arm Shutdown engines and battery and APU Wait for power loss Start battery and APU Check WPN page, showing ARM while button shows SAFE Track attached. apkws_mws_and_armed_spam_no_gen_and_armed_status_mismatch_mfd_button.trk

Track attached apkws_mws_and_armed_spam_no_gen_and_armed_status_mismatch_mfd_button.trk

The A10's APKWS laser guided rockets set off the missile warning system. The very same rocket motor is used for the unguided variants of the 70in hydra, which do not set off the missile warning system. That is inconsistent and impossible. Either it sets it off or it does not. The system should only care about what it sees, and not whether the game classifies something as a missile or a rocket.

When points are created, they are not synchronized to a CPG joining later. This happened before the second person joined the server, not sure if that is required or if it's enough to join the aircraft late. This also happened with a cold start and on a dedicated server. To reproduce: Enter cold apache Start aircraft Create waypoints Have CPG join the server, then the aircraft Have CPG check points Due to this being a multiplayer issue that happened during a long session, a trackfile is not available at this time. It will be provided once I find someone willing to make it with me.

Please only one report per thread and be more descriptive. 1. I get large frame drops in TV mode when looking at a forest and reported that earlier. Despite multiple people also having that issue and me providing both a track and video evidence it's "can't reproduce, so i guess it doesn't exist, case closed". More here: 2. I can hover just fine 3. Hellfires do struggle to hit a moving object, especially when further away or when the target is moving fast, but I have no real data to compare to, so I can't comment on if that's accurate or not. At the same time GBU12s have no such issues and almost always hit on a good track.

It's still a thing, especially with the TV camera and when pointing into the woods at a shallow angle.

I would like that the robbie tank or extra ammo capacity is not a mission editor option, but rather a loadout option in the rearm screen. This has multiple advantages: It's more flexible, mission designers can use the loadout restrictions to force one way or another if they want, but it also allows users who fly the mission to choose what they want if they permit it. Making it a checkbox in the mission editor will prohibit any changes dynamically and users couldn't change things after the fact, even if the mission designer would like that. It's preventing ui clutter. Putting it as yet another checkbox just invites it being forgotten to be set to the correct value and adds complexity to an interface that doesn't need to be there. Less is more and a clean interface goes a long way to user experience. Adding it as an extra option in the ground crew comms menu also is out of place, and it doesn't allow mission editors to prohibit the options if they desire so, unless an extra checkbox is added (please, no more checkboxes for super specific things that can be added into existing systems!) It also requires a special case for programming, and special cases are bad for maintainability and expansion. Unless it's something really, really special, it shouldn't be a special case. It can't be easily overlooked during mission design. Putting it in loadout is more visible to the designer of the mission than some checkbox in an unrelated, easily overlooked place, like the FCR checkbox is now (please also move that to loadout for the same reason). Pylon and weapon configuration is something routinely done during the mission design process for any airframe. Including gun ammo in that workflow prevents it being forgotten about. It's integrating with an already existing system. Weight calculations are already in the loadout screen, as are the options and (software) systems for extra tanks from the loadout screen. It can be treated just like any other external fuel tank on the software side. The only code changes would be to change the maximum amount of gun ammo as per selection, but that has to be done anyway. Perhaps some stations could be marked as cold rearm only, requiring the aircraft to shut down, while others are hot rearmable. Some aircraft already can only be rearmed while shut down, this system could incorporate them into one system simply by marking all their pylons as cold rearm only. This consolidates functionality into a more general form. Generalization is good software design as it's more flexible and allows expansion more easily. It makes sense from a UX perspective. Users would expect the loadout screen to be where to change the configuration of the aircraft. Anywhere else feels out of place and would have to be looked for. Generally special options in the mission editor should be avoided if it can be helped. FCR, Robie Tank (both are loadout options that concern the configuration of the aircraft) and pilot priority (that's a user preference, not an aircraft or mission thing) are examples of misplaced options that should really be somewhere else.

It happened a few times to me. It tends to happen during maneuvers, side slipping or trying to circle around an area, keeping the nose in some direction. But it has also happened in relatively straight flights but with a lot of slip.

Sometimes this thing just does uncommanded rolls, all the way around. Typically I'm high enough to recover but it's irritating. I'd be happy to upload the dozens of 300M track files where this happens, but there is a limit of 5MB on this forum. They'd rather allow the hosting of terrabytes worth of liveries for some reason.

It was supposedly fixed, thus the new issue report. It would be great if automation were in place to prevent regression and reintroducing old bugs.

Same here. Loading times were pretty long before, now they're way worse. Framerate is 0 for a good minute or so before I then sit over an ocean and can see the ground and buildings load in ever so slowly. Even the map takes forever to load now. Also running DCS on an M.2 NVMe SSD, though the rest of my hardware is somewhat lacking.

Actually that's exactly the reason. You probably flew the ka-50 before that to get 64/0. ah_64_wrong_chaff_flare_count.trk Ah great... the rearm menu interactions don't show in track files. Here's how to reproduce then. Place A10C-II and AH-64D in mission as client. Set A10C-II's chaff count to 120 and flare count to 240 Start mission in A10C-II Open rearm menu and set chaff and flare count to 240/240 Wait for rearm to complete Eject from A10C-II Enter AH-64D Open rearm menu Observe bug (Chaff count is 60) Some of this is probably not required.

I've had it show 60/60 once after jumping into an A10C-II. The A10C-II started with 120/240, which I adjusted to 240/240. After that I hopped into the AH64 and it provided me with 60/60, but when I opened the rearm screen again to take a screenshot it was 60/30 as it should. Couldn't reproduce since, so I didn't bother to post because it'd be "track replay or you're wrong"

I never use autoranging. It's just too slow to do. Just set your man range to 800 and the rounds will typically land on your cross. offset your aim by watching the bullet impacts. For rockets use coop, or again use offset aiming from where the rockets land.

You can usually create a waypoint by providing an existing point as the coordinates for the new point. in MP the CPG terrain point (CAQ) can't be used, despite being present for the pilot (although every other point can not be created due to a bug). Furthermore when creating the point and then using the cursor to select the terrain point for the new point's coordinates, the cursor coordinates will be used instead of the coordinates of the point under the cursor (T56). Track attached. server-20221106-222341.trk