Jump to content

Floyd1212

Members
  • Posts

    1018
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. We definitely ignore the NAK messages, but we still consistently see plenty of other issues. Double messages received RQST for PP not always working some team members receiving data while others do not (and we are all still sitting on the tarmac together) data not being sent from the CPG, but the same data works when sent from the PLT
  2. How much time/space are you giving yourself to transition? There's the "slow and smooth" approach, which should mean gradual adjustments all the way to hover over a longer deceleration, but shouldn't be too much drama. And then there's the "stand it on its tail" approach, which requires large amounts of collective and pedal right at the end as you are coming to a stop. I personally do a trim reset before starting the transition, and don't trim again until settled in the hover. This is not the recommended method, but that is the way my muscle memory is set, and holding the FTR during the whole transition would be a much different feel.
  3. Let me start by admitting that I did not read all 73 pages of the thread, so forgive me if this has been addressed already... I am trying to troubleshoot an issue where teleportToPoint of a group results in the new group not respecting the "Hidden on MFD" setting of the original group. Is there a var I can pass when calling this function to keep the new units hidden? For example, in the Apache, when I enable SHOW > COORD SHOW > PLANNED TGTS/THREATS the enemy SAMs are displayed on the TSD. When I enable SHOW > COORD SHOW > ENEMY UNITS Control measures for other enemy units are shown on the TSD. This shouldn't be happening if Hidden on MFD is checked for the unit group in the ME, which it is for the original groups being teleported. Any suggestions on resolving this?
  4. Sorry, what I was describing was the correct way to do it in 2D, which is also how it is shown in the manual. I was only pointing out to the OP that not only do you have to get your head on-axis with the BRU (bullseye pattern centered), but you also have to have the HMD looking straight down the tube (LOS reticle aligned with the bullseye). In his original post, it wasn't clear he was achieving both of these at the same time. VR users that render the IHADSS in both eyes do run into trouble getting things properly aligned. There are other threads that discuss techniques for this, including the "cross-eyed" method.
  5. Don't forget, the LOS reticle on the IHADSS (the cross in the middle) also has to be centered on the bullseye, while the bullseye is centered in the tube. Is that what you mean?
  6. 1) Sending them one at a time with RFHO seems to be the only way we have found, as well. I was also expecting to be able to send a whole set of targets, but maybe that is still coming? Maybe part of the LINK functionality? (I have heard the LINK function as having to do with linking the TADS to the FCR, so I'm not sure.) 2) Using DataLink, you can send over all of your targets points (and other points) at once, replacing the points the receiving aircraft has in their database. Wags shows how to do this in his video series, if you haven't messed with it yet. You can also select a single Txx point on your TSD and use XMIT to send it to a specific wingman. They cannot fire on this target directly, but can now use it as a DIR TO point, or as a ACQ source. Only RFHO sends enough info to your wingman for him to launch an RF missile while staying behind cover. One more note: After you perform your FCR scan and have a bunch of returns, you can use the TGT function on the FCR page to store all of the returns into your database at once, then use the DL functions to send all your targets to your wingman at once. Edit: After re-reading your initial post, it sounds like you are already sharing targets that way in your first part, so I'm not sure what you are asking in your second part.
  7. I have seen drivers get updated in Windows to where the triggers suddenly become a single axis, resting at 50%, instead of two independent axis from 0-100%, and wondered if that may have broken your Joy2Key remapping. But it sounds like everything still works outside of DCS, so not sure what the issue is.
  8. Do your triggers show up as a single split-axis, or as two independent axis?
  9. Yeah, I'm not sure Copilot is doing you any favors with that description. Try Googling the terms "settling with power" and "vortex ring state" that scoobie mentions above, and read up on those subjects from reputable sources. Also, don't ever reduce the engine power back from the FLY position (all the way forward). You can manipulate the collective as needed to fly the helo how you want, but leave the power levers alone.
  10. @Raptor9 Can you ask the team to take a look again with the new info and tracks above? Thanks!
  11. It's a known bug, that will hopefully get fixed one day. Another workaround that is mentioned in that thread when ground air is not available, is to move your cyclic around after starting the engine(s). The APU off/on method doesn't always work for me.
  12. I think the official answer is that FCR is not fully supported in multi-crew yet. Coming soon.
  13. Here are two tracks recorded specifically for this bug report, so they are very short and to the point. The XMIT NAK bug is reproduced here, in addition to a couple more bugs that are likely related to multi-crew. In the tracks, you can observe: #1 loads into first air-frame alone Orig ID is predefined in the ME as "11" Callsign is predefined in the ME as "1-1" #2 loads into second air-frame, and a human CPG joins him Orig ID is predefined in the ME as "12" Callsign is predefined in the ME as "1-2" #1 and #2 both switch Battery On and APU On #1 adds #2 to DL on Preset 3 FM1 by typing in C/S and ID, and sets TEAM and PRI for 1-2 #2 adds #1 to DL on Preset 3 FM1 by browsing the MBR DIR and finding 1-1 and adding Notice member 1-1 is added twice to the DL group. This happens when there is a human CPG in the aircraft. The second instance is deleted from the group, and TEAM and PRI are set for 1-1 At this point, DL is setup correctly for each aircraft. #1 sends #2 a text message The message is received twice by #2 #1 gets a XMIT NAK FM1 message, even though the message is received #2 sends #1 a text message The message is received twice by #1 #2 gets a XMIT NAK FM1 message, even though the message is received Hope this helps reproducing some of these issues. DL Bugs - 1-1 Solo.trk DL Bugs - 1-2 Multi-Crew.trk
×
×
  • Create New...