Thunk

Not sure if we're doing something wrong or if this is a bug. I have not been able to find anything similar reported either here or via Google. We have two players in an F-14 and a third player in a Hornet. Set F-14 Pilot's radio to 250MHz. (The problem occurs using either radio on any frequency, but for simplicity I'll focus on just the pilot's radio) Pilot and RIO can hear each other on ICS fine. Pilot can transmit to and receive from other aircraft fine RIO can transmit to and receive from other aircraft fine However, Pilot cannot hear RIO's transmissions on the radio. RIO cannot hear pilot's transmissions on the radio Since other aircraft can hear the transmissions, it seems that the keybinds are functioning. Since Pilot and RIO can both hear incoming transmissions on that radio, it seems volume level is fine. The crew just can't hear each other. We've tried it with 4 different players in multiple missions, always with the same results. It seems like transmitting mutes your transmission in your own headset to prevent echoing, but in the Tomcat is actually muting it to both crew members. But that's just a guess. Has anyone else experienced this in a Tomcat? Has anyone experienced this in any other multicrew aircraft? Logfile is attached. dcs.log

Still broken in 2.9.3.51704

Still broken in 2.9.3.51704

Using 2.9.3.51704, in the F-14A and F-14B, both front and back seats: adjusting the volume of a radio or ICS by turning the associated cockpit knob while a transmission is in progress immediately cuts off the transmission. It does not resume until the sender keys the mic again. This makes it very hard to adjust volume since you can't hear the actual volume change without requesting the other person to transmit again.

As of 2.8.7.42583, the behavior has changed slightly. In MT, the illuminated object now has a glow when painted that's fairly visible, and there is a beam but it's very very faint. So faint that it's easily washed out by moonlight. So faint it didn't even appear in the screenshots I took. But if you already know where to look, or can get a really dark background behind it, you can sometimes see it. Meanwhile, in ST, the beam is still quite bright slicing through the night. I tried this with both the UH-1 and the AH-64. So some improvement in 2.8.7.42583 MT, but still not on par with ST.

Isn't this the same issue, just via script, as this thread?

In open beta 2.8.6.41363, the behavior of S_EVENT_REFUELING and S_EVENT_REFUELING_STOP have changed. Single player still behaves the same as prior builds, but multiplayer has changed significantly. In single player mode, when USER connects to TANKER, event S_EVENT_REFUELING fires. The event.initiator is the USER's unit. When the USER disconnects, event S_EVENT_REFUELING_STOP fires. That event.initiator is also the USER's unit. The behavior is the same for both single threaded and multi threaded clients. This is consistent behavior as observed in prior builds. Multi player used to work the same way. But in 2.8.6.41363 the online behavior has changed. Now, when a USER connects to TANKER, event S_EVENT_REFUELING fires but the event.initiator is the TANKER instead of the USER. Furthermore, when the USER disconnects two S_EVENT_REFUELING_STOP events fire. The first lists the TANKER as the event.initiator. The second lists the USER as the event.initiator. Prior to 2.8.6.41363, start and stop events with the USER as the initiator fired in both online and offline play. Now, without an event indicating when the USER initiated refueling, it's impossible to monitor (and grade) the duration of players' refueling attempts. Please re-institute an S_EVENT_REFUELING event with the USER as the initiator in the multiplayer environment, to be consistent with both offline play and prior builds. ----Attachments--- Here are the relevant lines from the log file. Note the first line shows refueling started with the S-3 as the initiator. Then there are two refueling stop events, one for the tanker and one for the hornet. Server track file is also attached. 2023-07-05 03:14:22.571 INFO Scripting (Main): event:initiator_unit_type=S-3B Tanker,type=refuel,initiator_object_id=16894209,initiator_ws_type1=1,t=178.416,initiator_coalition=2,initiatorMissionID=1768, 2023-07-05 03:14:22.571 INFO APP (Main): wcTanker::onEvent:6 2023-07-05 03:14:22.571 INFO EDCORE (Main): (wcTanker::Channel)enterToState_:4 2023-07-05 03:14:25.591 INFO APP (Main): wcTanker::onEvent:9 2023-07-05 03:14:25.591 INFO EDCORE (Main): (wcTanker::Channel)enterToState_:5 2023-07-05 03:14:34.763 INFO APP (Main): wcTanker::onEvent:10 2023-07-05 03:14:34.763 INFO EDCORE (Main): (wcTanker::Channel)enterToState_:4 2023-07-05 03:14:34.763 INFO Scripting (Main): event:initiator_unit_type=S-3B Tanker,type=refuel stop,initiator_object_id=16894209,initiator_ws_type1=1,t=190.609,initiator_coalition=2,initiatorMissionID=1768, 2023-07-05 03:14:34.763 INFO APP (Main): wcTanker::onEvent:7 2023-07-05 03:14:34.763 INFO Scripting (Main): event:initiator_unit_type=FA-18C_hornet,type=refuel stop,initiatorPilotName=Thunk,initiator_coalition=2,initiator_ws_type1=1,t=190.609,initiator_object_id=16779010,initiatorMissionID=1767, server-20230704-211052.trk

It would be really helpful if the table in the unit list had another (sortable) column for "radio frequency." It would be really helpful to rapidly verify radio channel settings for all groups, especially in larger missions.

Since updating this morning to the MT build, labels sometimes do not appear in the left eye. It's 100% reproducible, but I have not found a pattern yet. For example, sometimes with two aircraft near each other, one displays labels in both eyes properly but the other only shows up in the right eye. In other cases, turning so that the aircraft is at the very left or right edge of the view makes labels appear in the left eye. other times, the labels disappear when the object is near the edge of the view and moving so that it's centered makes the label appear. Mirroring both eyes shows the left missing the label. See attached screen shot. The problem is present when watching the attached track file in VR. Confirmed in multiple missions. Windows 11 i9-12, 64GB RAM, 3090 with Quest2. Nvidia driver 531.18. DCS 2.8.3.37556 Open Beta No label left eye.trk

This might be a little off topic, but... This is a long shot, but a long time ago I saw a Navy cruise video featuring a search for a big-time Hollywood director interspersed between flight scenes. I believe it was a fairly old video, possibly even video-tape era. It was pretty humorous, featuring scenes acted-out in the styles of various well-known directors. Does anyone else remember this cruise video or have a link? Google and Youtube searches have failed to find this gem. Thanks, Thunk

Posting this in multiple threads to increase visibility. I've been seeing this same issue, with the radio items effectively scrambled across the assigned aircraft. After some testing, it appears that changing the trigger's EVENT TYPE from NONE to ON MISSION START cures the problem. I've tested it in 3 missions containing up to 14 flyable groups and so far it's held up with each group receiving the expected radio item. I also downloaded the mission from this thread and verified that after changing the EVENT TYPE that group1blue shows the correct radio item. Credit to @Flappie's findings in this thread, which provided a key clue:

@Flappie's findings provided a clue. I've been seeing this same issue, with the radio items effectively scrambled across the assigned aircraft. After some testing, it appears that changing the trigger's EVENT TYPE from NONE to ON MISSION START cures the problem. I've tested it in 3 missions containing up to 14 flyable groups and so far it's held up with each group receiving the expected radio item.

I'm a little late to the party, but would like to add: I had a similar problem and the same fix worked as well. In MP, with two people on the server, all was fine. but as soon as a 3rd person joined, my headset volume dropped to like 30% for both Discord and in-game headset sounds. I found this thread, disabled DCS VR Chat, restarted and all is fine again.

Bug: When watching a track file using VR, the pointer in the Jester Wheel tracks the user's head movements. If the viewer inadvertently moves the pointer away from it's original selection before the selection event plays, then the Jester Wheel stays stuck on screen for the entire track file. The pointer continues to follow the viewer's head movements, but cannot be closed. Can I reproduce it 100%: Yes. 100%. every time. If not 100%, how often out of 10: 10/10 How to reproduce/ description: Step1: Fly a mission using VR. Issue commands to jester using the wheel. Step2: Watch the track file using VR Step 3: When the Jester Wheel appears, look away. Notice that the jester wheel reacts to your VR head movements, not the originally recorded selection. Look somewhere so that the pointer is not on a valid selection, or just on a different selection than the original selection. Step 4: Jester Wheel stays stuck in the middle of the screen, with the ICS hiss continuing in the headset, for the remainder of the track. You cannot close it. It blocks the view for the rest of the replay. Expected result: When viewing a track file with VR, head movements by the viewer do not move the jester wheel pointer. The jester selection(s) made during the mission are faithfully replayed. Actual Result: When viewing a track file with VR, the viewer's current head movements are accepted by the jester wheel, which overrides the recorded selections in the trk file. DCS Version: OpenBeta 2.5.6.60966 System Specs: CPU i7 6700 GPU GTX1080 32GB RAM SSD OS: Win10 Peripherals: Joystick: Thrustmaster Cougar Throttle: Thrustmaster Cougar Pedals: Thrustmaster RCS Others: Headtracker: Quest 2 Mission File: Any F-14 mission file can reproduce this Log: Track: I don't know how to capture a track file showing that user inputs during replaying a track file changes the behavior of the track file. Video/ Screenshots: Mods: no mods

Track files captured using DCS 2.5.6.60966; however, this has been present in all versions I have tried so far. The system is I7-6700, 32GB Ram, GTX1080 and Oculus Quest2. Captured flying the "Free Flight" instant action mission. In the attached track file, the lead F-16 is shown as 440KCAS on the MFD when I'm in STT. Per the -34-1-1, figure 1-85, the target speed is displayed as KCAS on the MFD. I have the HUD velocity switch set to CAS (visible in the .trk). As you can see in the track file, I hold distance at 390KCAS and the closure rate on the MFD / HUD is 0kts. At 400KCAS, closure rate on the MFD / HUD is about +10kts and I'm clearly getting closer. Target speed 440KCAS, my speed 400KCAS with a closure rate of +10Kts and visibly getting closer doesn't add up. Next, I lock up the high-altitude target. It's speed is shown on the MFD as 460KCAS. per the labels, I do seem to be closing on the target. With my speed at 305KCAS, closure rate is shown as more than +100kts, which again doesn't add up. At the end of the second track file, I'm at 210KCAS and 0kts closure, holding position on the A-10, but the MFD shows its speed as 230KCAS. If that were true, closure should be -20kts, and I should be dropping back. If I set the HUD to TAS, the numbers are still off, but closer. Therefore, it appears that the target speed shown on the MFD in STT is inaccurate. https://1drv.ms/u/s!Au8NSvUcPq9khMsIukFPrIK2Wgf4Iw?e=bbWkgI https://1drv.ms/u/s!Au8NSvUcPq9khMsJHMSNjnPQtdfqdQ?e=uFzaRL Thanks, Thunk