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.