Flagrum

If you set up a flight in the ME, the primary comms freq. is synchronized with the pre-configured frequencies of the radios (and with the default comms freq. of the whole flight). In case of our AH-64 this is channel 1 of the ARC-164. If you change the freq. in the upper portion, it also automatically changes radio channel #1 and vice versa. The datalink presets corresponds to those pre-configured radio frequencies. So by default, PRESET1 corresponds to radio channel #1, PRESET2 to radio channel #2 and so on. Thus, using PRESET1 (= ARC-164 chan.# 1 = AI flight primary comms. freq.) should and does work. The issue is now, that PRESET1 is not assigned to the radio when entering the cockpit. Instead, the ARC-164 is set to MAN and the primary comms. frequency, while all other radios get their appropriate DL preset correctly assigned to it. You have to manually assign PRESET1 to the radio - then also the DL functions work. I assume, this is due to the way the radios are initialized at mission start: assign DL presets assign primary comms. frequency to the whole flight and thus, overriding the DL preset Did I miss here something, or is this really a bug/quirk? Or how could I get the correct DL preset assigned to the ARC-164 automatically? You have to redo the DL preset settings for the other members of your flight, yes. But you can't even adjust the radio channel frequencies for your AI flight members. I am not sure, if those are inherited from the flight lead or if you are stuck with the default frequencies in this case in order to get it to work. Until now, AI flight members simply had no use of any other radio other than the one for the primary flight comms freq., aka ARC-164 ch. #1. So why would they inherit the other radio settings anyways? But in my test, I just kept everything at the defaults - except the primary comms. frequency / channel #1 of the ARC-164. This allowed me to a) talk to my wingman just fine and also b) use DL functions over that radio/frequency. The other radios / frequencies I did not investigate (yet). But anyways, while there are still other open questions, my main concern right here is just why the DL Preset setting for exactly the radio / channel, which is used as the primary comms. frequency, is not transferred into the cockpit, while for all other radios it does work. Note: I am only talking about Single Player with AI flight members! ___ (This is a repost of of the main forum as it is not being moved here)

You are looking at the roles and capabilities of the RL aircraft - so I am not sure how relevant this might be for you. But I would also research a bit the maturity and the available documentation / manuals of these DCS products.

Hi ED Team Is this a known issue and/or already reported as a bug? Then please move this thread to the Bug section then, if appropriate. Or did I just miss something else here? Thanks!

Sooo ... did you guys already start with the rework? How is it coming along? Any chance that we will get an updated manual this year?

I guess, the answer is no. As they would have posted them already if there were any news - as they always claim. So no news, no progress... But I'd like to bump this thread anyways - to still raise awareness to the fact that there are still people eagerly waiting. (I know that asking these kind of questions is considered inpolite - but so is this kind of "ghosting".)

You have to redo the DL preset settings for the other members of your flight, yes. But you can't even adjust the radio channel frequencies for your AI flight members. I am not sure, if those are inherited from the flight lead or if you are stuck with the default frequencies in this case in order to get it to work. Until now, AI flight members simply had no use of any other radio other than the one for the primary flight comms freq., aka ARC-164 ch. #1. So why would they inherit the other radio settings anyways? But in my test, I just kept everything at the defaults - except the primary comms. frequency / channel #1 of the ARC-164. This allowed me to a) talk to my wingman just fine and also b) use DL functions over that radio/frequency. The other radios / frequencies I did not investigate (yet). But anyways, while there are still other open questions, my main concern right here is just why the DL Preset setting for exactly the radio / channel, which is used as the primary comms. frequency, is not transferred into the cockpit, while for all other radios it does work. Note: I am only talking about Single Player with AI flight members!

If you set up a flight in the ME, the primary comms freq. is synchronized with the pre-configured frequencies of the radios (and with the default comms freq. of the whole flight). In case of our AH-64 this is channel 1 of the ARC-164. If you change the freq. in the upper portion, it also automatically changes radio channel #1 and vice versa. The datalink presets corresponds to those pre-configured radio frequencies. So by default, PRESET1 corresponds to radio channel #1, PRESET2 to radio channel #2 and so on. Thus, using PRESET1 (= ARC-164 chan.# 1 = AI flight primary comms. freq.) should and does work. The issue is now, that PRESET1 is not assigned to the radio when entering the cockpit. Instead, the ARC-164 is set to MAN and the primary comms. frequency, while all other radios get their appropriate DL preset correctly assigned to it. You have to manually assign PRESET1 to the radio - then also the DL functions work. I assume, this is due to the way the radios are initialized at mission start: assign DL presets assign primary comms. frequency to the whole flight and thus, overriding the DL preset Did I miss here something, or is this really a bug/quirk? Or how could I get the correct DL preset assigned to the ARC-164 automatically?

Hi Razbam team! How is the work on the manual for this module progressing? The F-15 shipped with a quite decent manual - so I assume that now some capacity is being invested into the Av8B manual? Thanks! -- Flagrum

I understand that this is not a wishlist thread. Still ... you might want to consider: - implementing some sort of "visual cockpit exploration mode". Tool-tips are ok to remind you of the function of some cockpit element. But with a dedicated exploration mode, a user could for example click on switches and gauges and get a small popup with some (brief) newbie-friendly explanation of what it actually does. This exploration mode could either be activated when you are inside the cockpit, or maybe even as a new, dedicated training resource (accessible from the main screen). A dedicated learning resource could probably allow better to implement, for example, additional aids, like highlighting related cockpit elements, etc. - implementing some sort of visual aid to help setting up the Snap Views. Using the shortcuts with 15 keys on the num-pad + 2-3 modifiers is a finger breaking exercise, and I avoid fiddling around with it like the plague.

The F-15E is now released, even with a very decent manual. So ... can we assume that the Harrier and the Harrier manual will now get some sort of priority? I mean, it is now ... how many years ...?

Yes, before launch. If my target is beyond 2.5 km, the default mode is LOAL. But if the target is moving, the missile will use LOBL. So, how does the missile know that it is supposed to lock on before the launch if the target is farther away than 2.5 km? How does it know that the target is moving?

The radar Hellfire will use LOBL if the range is less than 2.5 km OR if it is a moving target. But how does the missile know if it is a moving target? If the target is closer than 2.5 km, it will lock right on anyways and should not really have to worry if the target is moving or not. But what if the target is further away? It will default to LOAL - until it knows the target is moving and then enter LOBL mode. But how does this "knowing" actually work? I assume, the helo has to tell the missile, right? Do I have to use MTT or LMC? Just manually following the target will probably not do the trick?

I find it difficult to keep the a/c in a stable, steady attitude when I use FTR. There is always at least a tad bit of difference in the effective control inputs, compared to the last trimmed position and what the SCAS thinks what is necessary. Now, when depressing FTR, the SCAS reduces it's input until we are back to my last trimmed setting. No matter how small the difference is, it is always noticeable to me - so sensitive as the Apache is. This usually then interferes with my intended maneuvering as I have no way to anticipate it (i.e. without active Controls Indicator). This is most noticeable - and annoying - for example, when I am in a hover with active hover hold. If I try to change my heading and depress FTR, I am already drifting all over the place, most likely inducing involuntarily some PIO on top of it ...

Happened to me all the time - until I made it a habit to disable the parking brake and unlocked the tail wheel.

But without appropriate radar illumination, the precision should be rather low, right? It is then basically just INS guided?

So I just dreamed it? o.O

The cameras are aligned to the horizon, so the direction where they are looking does not really change. Only the altitude (and therefore slant range) would change a few feet ...

I'm looking forward to it...

The Situal Awareness Cue of the TPOD, the small square that indicates where the TPOD is looking at - in relation to it's boresight position (= aircraft center line), is not behaving correctly. The SA cue is supposed to give a top-down view of where the TPOD is looking, with the aircraft in the center of the MFD: I.e. if the TPOD looks straight ahead at a target designation, the SA cue is supposed to be in the center top of the MFD. If it is looking somwhere at my 3 o'clock, it should be on the right side of the MFD. And so on. This is the behaviour in the Harrier, as long as I fly wings level. But any maneuvering of the a/c causes the SA cue to swing arround at the perimeter of the MFD. Banking and also pitch changes make the SA move to left and right and even seemingly looking at the 6 o'clock position - all while the TPOD reticle is still visible in the HUD and only 1-2 degreess left/right/above/below the acutal flight path marker (i.e. the SA cue should be shown at about the 12 o'clock position on the MFD). Note: if the TPOD is slaved to the velocity vector (SLV VV), the SA cue is always correctly exact at the center top of the MFD, regardless of any maneuvering. This leaves me with the impression, that the SA cue position is calculated based on the relative position of the TPOD reticle and the velocity vector on the HUD glass plane (instead of where they both are actually pointing at in the outside world). av8b tgp sa cue.trk

I seem to remember that some time ago a new ME feature was introduced: changing which unit of an AI group is the first one, the lead one (marked with a "1"). Iirc, it was some sort of keyboard short-cut that one had to hold while clicking at the new 1st unit in the mission editor ... Does anyone know? Thanks!

Update to my last posting: I simplified the test case - no more conditions, just a simple route: The Humvee should simply follow the waypoints 1...2...3...4...5 and when reaching 5 it should start over again at 1. Each time it passes a waypoint, a message is transmitted of which wpt was just passed. After 1 or 2 rounds, it starts to get erratic again and the transmissions do not match the actual position of the vehicle. And here as well, the AI starts skipping waypoints. test go wpt2.trk

I think, the issue is not the conditions set for this action. It seems to me rather that there is a general bug in the "switch waypoint" logic. The behaviour of the AI after a "swicht waypoint" seems to be rather erratic. I made a test mission with a Humvee, which is supposed to drive continuous in a either left hand circle or right hand circle. One waypoint decides which direction to take: left hand or right hand. Once the AI took the left hand route (using "switch waypoint"), things go downhill. This is the path the AI took (2/3 of the time left hand route - although 50% probability was set ... but might be a coincidence): The route setup in the ME: It almost looks like the AI sometimes "forgets" what it was doing or is supposed to be doing. I.e. once arrived at WPT 9 (lower left corner), it should stay "ON ROAD" - but as can be seen in the first screenshot, it randomly veers off into the meadows, wiggling around as if it can't decide which WPT it is supposed to head for next. It even skips one or more WPTs occasionally. The DCS.log might support this hypothesis as well: (.TRK and TacView attached) Tacview-20221230-211848-DCS-test go wpt.zip.acmi test go wpt.trk

Nobody noticed the track. Nobody knew the original posting was changed as such changes don't highlight the thread and everyone involved probably did not bother to re-read the whole thread letter by letter, but focussed on his actual reply to NLs request for a track. It's not always "this attitude on the forums here" ....

Nobody will be notified nor the thread highlighted for a new posting if you just edit old postings.

What I found on the internet about it: it's a cockpit programmable delay fuse and is supposed to be used penetrate the forrest canopy of wooded areas. I.e. the fuse detects hitting branches, but delays the action for some ms in order to get rocked closer to the ground. There is also an other option that is supposed to delay the action after penetrating light cover, i.e. (wooden) roofs of dug out shelters.