Thunk

I'm probably just talking to myself here, but just for posterity, the pattern is: If an AI plane tanks, then the initiator of the REFUELING event is the AI unit. If a PLAYER plane tanks, then the initiator of the REFUELING event is the PLAYER unit. If a CLIENT plane tanks, then the initiator of the REFUELING even is the tanker unit, not the CLIENT unit, making it impossible to programmatically identify who is tanking.

Correction, it is *not* working in 2.9.13.6818. At least not completely: Single player: refueling and refueling_stop events fire as expected Single player mode but launched in a MP server: refueling and refueling_stop events fire as expected Hosted on a multiplayer: refueling shows the tanker as the initiator, refueling_stop shows the player as the initiator. This still makes it impossible to see how long the user was connected to the tanker.

Aha! Now it all makes sense. Thanks!

Hi, What are these red boxes called next to some, but not all, ground groups called? I've failed to find anything useful on google. I'd like to understand why they appear sometimes and how to make them go away. Thanks! null

It's working again in 2.9.13.6818. Wow!

@Squeaky_B My first impression with today's patch is: The same mission is getting blocked on the deck at exactly the same spot as before, except now it says "Awaiting Taxi Permission" instead of "Awaiting ATC status." So, I began experimenting and found some conditions where I can make things work. I didn't try these steps on the prior version, so I can't say whether this is new behavior in this patch, or if this would have worked in the prior version. I tried staggering the spawn of AI aircraft, so some don't appear for 30 seconds which adjusts where AI and players spawn on the deck. What I'm seeing happen is: If aircraft are in spawn points 1, 2, 3 and 4 and I spawn behind them (points 5, 6, 11, 12, 13) then this seems to be the problematic scenario. If I spawn in 5, 6, 11, 12, or 13 then I *must* wait for the aircraft in 1, 2, 3 and 4 to move first. If I do the first salute before those 4 have moved, the deck get stuck every single time with "Waiting for Taxi Permission." If I wait until 1, 2, 3 and 4 have started moving--even just a second after the 4th one moves--before I salute, then the deck keeps moving and everyone launches. I forced my spawn point to change by altering the delay of when the AI aircraft spawn in (up to 30 seconds after mission start). If I spawn anywhere else on the deck, I can salute immediately and begin moving without the deck ever getting jammed up. Since we can't directly control where we spawn on the carrier, I can't confirm these results 100%. However, what I described above, at least in my missions, seems to be repeatable. If I"m in 5, 6, 11, 12 or 13 (aka, forward of the island on the outer edge, on or by the elevators) then I must wait for any and all aircraft in 1, 2, 3 and 4 (those that spawned in The Street) to start moving before i salute otherwise the deck gets hung up with "Awaiting Taxi Permission." Although this is different than the layout you described, I'm somewhat encouraged that this seems to be working in my missions. Out of curiosity, are you saluting before the AI aircraft starts to move? What happens if you salute only after it moves? If you delay the AI's spawn for, say, 30 seconds, can you salute after it spawns in? Just grasping at straws here, trying to find a pattern.

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

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.

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