Aarnoman

DCS Version: DCS 2.5.6.59625 Brief description of bug: The 'AI Transmit Message' command is a commonly used command to send radio messages from a specific unit on a specific frequency. Typically, it displays the message on the top left side of the screen. However, on VR devices, such text fails to display completly. Expected behaviour: Text messages sent through the AI transmit message command should display on both normal screens and VR devices equally. Why is this important: As the AI transmit message command is commonly used in many missions and campaigns, this bug breaks many missions/campaigns, both free and official paid campaigns for VR users. I therefore consider this a moderate to high priority issue. To reproduce: (Example mission attached). 1) Create a mission with a player aircraft unit and a friendly AI ground unit. 2) Set the frequency of the player aircraft (255MHz used in example mission). 3) Use Set frequency command in friendly ground unit to set same freqency (255MHz in the example mission). 4) Create a Transmit Message command in the friendly AI unit. An audio beep was used in the example mission to confirm the message command was executed. Add a sample text message. 5) Create a trigger with a time more than command set to 15s or greater to allow mission to fully load. Use AI Set Task or AI Push task command to execute the transmit message command we set up for our AI unit. 6) Observe result: a) On normal displays, the message beep will play and message displays in top left corner. (Refer to screenshot nonVR). b) On VR devices, the message beep will play but text message WILL NOT display. (Refer to screenshot VR). NonVR: Note the message displaying succesfully on the Left side of screen. ("beep boop: APC Ground-1 transmitting on 255.") VR: Note the message NOT displaying on left side of screen: (no "beep boop: APC Ground-1 transmitting on 255." is displayed this time, with same mission) TransmitMessageTest.miz

This is still an active bug. The impact of high polling rate appears solved with current patch - 2.5.6.59398. However, stickiness with slow movements remains, as a result of minimum 'speed gates'. Follow instructions of video in original bug report to replicate - very slow movement of mouse in external camera view will result in smooth motions of a set speed, with fixed velocity. This results in 'stuttering' experience when threshold in increase/decrease of lateral mouse movement exceeds the threshold to move on to the next rotational speed. If this description is unclear let me know, I can make another video demonstrating the issue more clearly.

DCS Version: DCS 2.5.6.59398 Brief description of bug: ZSU-57-2 is unable to hit slow moving targets flying straight legs. This is as AP-tracer rounds are used against air targets (these where historically used against ground targets only). Air targets should be engaged with HE-fragmentation rounds. The use of AP-tracer rounds only defeats the purpose of the ZSU-57-2 as an air defence unit, as it is unable to hit them. To reproduce: See attached track file. Tested with 1xA10c flying short legs over battery of 6x ZSU-57-2. Only AP-tracer rounds are used, with no direct hits scored after 8 minutes of mission runtime. Further info: This is not a bug, the ZSU-57-2 has historically very poor track record against air targets due to optical FCS and none-airburst ammunition. As a result it was almost exclusively used against ground targets and very slow moving aircraft, namely helicopters. The current depiction of the ZSU-57-2 appears to be consistent with historical accounts and resources on the internet in terms of its lethality against air and ground targets. ZSU-57-NoHits2.trk

Also, the mission editor manual would also imply the behaviour stays consistent as expected: And agreed, makes escort missions very tedious to set up as many triggers are needed for behaviour, which quickly gets convuluted. The current ROE behaviour has a purpose, but it should be a seperate selectable ROE "cautious - engage within 2km".

Same here, has been going downhill steadily over the last few OB updates too.

Hi BN, thank you for checking in with the team. Although the team is of the opinion it is "correct as is", I disagree. The behaviour for "return fire" should be the same against both AI and human entities, as it creates needless confusion (this bug report was created as three people independently came to the conclusion the behaviour was bugged as a result of missions breaking when AI aircraft were replaced by human clients). I propose that the ROE "return fire" for human players is changed to be identical to the behaviour against AI players. The current ROE "return fire" behaviour against human players should be added as a new ROE behaviour, perhaps "cautious - engage within 2km". This would avoid any further confusion in the future, particularly as this is very poorly documented from within the mission editor, and actively contradicts the indicated behaviour of "return fire" as it engages human players offensively.

Any update on whether this is a bug? Was especially confusing for me setting up a FARP using invisible FARP object and the AV-8.

DCS Version: DCS 2.5.6.57264 Brief description of bug: AI ROE "return fire" is not respected against human players (set as either 'client' or 'player' in missione editor). Expected behaviour: AI should respect ROE setting, and not engage human player until it has been engaged. To reproduce: See attached mission file. On the left is the setup with a blue client unit (red jet will not obeye ROE "return fire"). On the right the blue unit is set as AI. Note how the red unit respects ROE "return fire" and does not engage the blue AI unit. This same behaviour would be expected against human controlled units. Extra notes: The "return fire" ROE setting works as intended against other AI units. This ROE setting is only disobeyed against human entities (set as 'player' or 'client' in mission editor). ROE_ReturnFireBug.miz

I have reported this bug with track/sample mission here: https://forums.eagle.ru/forum/englis...to-lag-pursuit

DCS Version: DCS 2.5.6.57264 Brief description of bug: SA-2 SAM sites miss their target 100% of the time if target velocity is greater than ~300 knots. Expected behaviour: SA-2 SAM's should be able to hit targets within effective weapons range (misses should be possible, but not 100% of the time). This problem is likely exacerbated by lack of proximity fuzing (missile never detonates prior to passing target). Why is this important: SA-2 sites currently serve no Air-defence function in game with the exception of very slow moving targets, as Pk is 0 for any target moving at velocity > ~300 knots. To reproduce: See attached mission file using an AI with threat reactions disabled. Sample track included. Further information: this report, which still remains unadressed. SA2-Test.miz SA-2 Bug.trk

I second prior suggestion of interactable page(s) that can be drawn or written on, specifically for Nineline and other mission specific information. Additionally, having such function in VR would be a good addition, including positioning of kneeboard in 3D space (a la VR kneeboard mod). Lastly, button to lock aspect ratio to avoid all this stretching, or just be unable to 'squish' kneeboard images in the first place.

I am a strong supporter for both polygonal trigger zones and border violation detection, both would expand the capabilities of mission designers immensely.

Great idea, would be very useful for expanding night ops.

I am under the impression that such features are planned when (eventually) they release the data cartrige/mission planning core feature for DCS. The development team has mentioned it a few times following the Hornet requested features poll, where the decision was made to make these two features part of DCS core as opposed to locking behind a single plane. I agree with all points discussed in the previous two posts, will make a monumental difference to cohoesion and planning capabilities, particularly in public servers.

I think you are posting in the wrong thread. Holy necromancy.

Had a lot of fun learning how to make tracking shots in DCS, resulting in this short cinematic. Would love some thoughts on what was done well and what could be improved in the future. If anyone is interested in how specific shots were achieved please leave a message and I will be able to talk you through it.

Appears to be the same issue outlined here: https://forums.eagle.ru/forum/english/digital-combat-simulator/dcs-world-2-5/bugs-and-problems-ai/controller-profiles-and-problems-ab/151991-mouse-look-not-smooth?t=152300

I am able to replicate. This is a new issue introduced with DCS Version 2.5.6.57264. This issue affects all external camera view (F2/F3/F4/F11). Internal view (F1) is unaffected.

DCS Version: DCS 2.5.6.57264 Brief description of bug: When the mouse uses a high polling rate (such as 500hz or 1000hz), external camera movements become ‘sticky’. This effect is independent of frame time. Even on low polling rates, issues with 'speed-brackets' exist. Expected behaviour: External camera movement should remain smooth regardless of mouse polling rate. As most modern computer mice use 1000hz polling (particularly ‘gaming mice), this problem affects a major proportion of the DCS userbase. Why is this important: This sticky mouse movement creates a false perception of in-game lag when external cameras are used. This issue particularly affects content creators making videos with DCS. To reproduce: Ensure mouse polling rate is set to 1000hz. In my testing, I have used my default 1600DPI setting, with the problem appearing to persist even when set to higher DPI of 3200. Enter a mission with a unit on the ground. Enter external view (eg F2). Note this problem affects any external view (F2/F3/F6/F7/F11 have all been tested with reproduction of the issue). Move mouse slowly left or right in a smooth, continuous motion. Note that camera movement will become ‘sticky’. Alter speed of movement slightly to be slower/faster. Observe distinct ‘speed-bands’, where the rotation is smooth but not reflective of mouse speed. For more information, consult attached video. Note these distinct speed-bands are NOT the same bug as polling rate. Speeds bands and polling rate appear to be interacting synergistically to produce the effect of stutters however. [*]After observing this effect, lower mouse polling rate to 500hz and repeat steps 2-6. Observe for a reduction in magnitude of the ‘stickiness’ effect. [*]Repeat steps 2-6 after lowering mouse polling rate to 125hz Observe ‘stickiness’ effect has reduced further. [*]Observe that at all polling rates, there is a set minimum speed below which cannot rotate. It appears the current in-engine implementation of camera rotation has fixed ‘speed bands’, further contributing to non-smooth camera rotation behaviour. Note this problem affects rotation in both pitch (up-down) and yaw (left-right) axis. As far as I am able to elucidate from the data gathered, the 'stickiness' due to polling rate and speed bracket issue are related but not the same bug. However, I have reported as one bug here as they operate synergistically in producing the overall effect that is similar to lag stutter. All testing was conducted with no dropped frames (constant 60fps). Video documenting this effect: Mission file used to for testing attached. CameraTest.miz

Thank you for investigating it, great to hear that the likely culprit has been identified. Looking forward to it being fixed down the line, no rush. Just happy it's been looked at. Thanks again for the awesome improvement you've brought to the soundscape.

As a fellow GTX 1080 user, I can sympathise.

Wow this should be incorporated into the base game. Awesome work!

Yeah, definitely an area that has a lot of potential for optimisation with no drawback. I am surprised we still have not had input from any ED staff members, this seems like very low hanging fruit in optimising resource use (even if there is no net fps gain, freeing up VRAM is important to reduce load stutter, as well as opening up VRAM for other textures).

Thank you for that explanation, I was not aware that the firecracker sound was a result of supersonic cracks rather than impact. With that information, I still think there is an issue with time of flight and onset of the firecracker sound, which you appear to have identified as well. I am basing this off the fact that the muzzle velocity of the Gau-8 projectiles is ~1010 m/s, which is considerably faster than speed of sound (340m/s). At the ranges used in testing (please refer to attached mission file for replication), the firecrack sound still appears noticably earlier than any projectile impacts when observing from the target location. This should not be possible as the projectiles were travelling at supersonic speed for the entire duration. Thank you for taking the time to reply and statement to investigate this further. If I am correct in thinking you are one of the staff member responsible for developing this update to the soundscape, I want to once again commend you on the awesome work. It really is a game changer for me personally. Thank you.

I would like to preface this bug report by thanking the ED team for the excellent work on the A10C sound update. It has been a phenomenal improvement to the soundscape, the team members involved should be very proud of their work. However, one small issue was introduced with the change, relating to the time of onset of the 'firecracker sound'. I have created a video to more clearly demonstrate the bug, why it is an issue, and how it compares to real life footage. Please take the time to watch the video, as it much more clearly demonstrates what I mean, it is very difficult to explain in words alone. Now on to the bug: Version: 2.5.6.57264 Bug description: First part of Gau8 impact sound plays prematurely (before round impacts). Detailed report: Terminology: Effectively, with the sound update introduced in the 2.5.6.57264 update, there are now three distinct parts to the Gau-8 soundscape: [sound 1] The ‘firecracker’-like initial sound. [sound 2] The thudding impact sounds, in time with the explosions. These appear to be unchanged from the old impact sounds present prior to the sound update. [sound 3] The ‘brrrrt’ sound originating from the gun. Additionally, it should be noted DCS utilises realistic speed of sound delay to in game sounds, and has been considered in the demonstration of this bug. Bug in action: Currently, [sound 1] and [sound 2] should be occurring simultaneously, as both are caused by weapon impact with the ground. However, [sound 1] currently occurs prematurely – slightly before any rounds have impacted. This results in noticeable splitting between these two sounds, especially at increased distance from target. Demonstration video 1: I have compared the sound to many videos of A10C gun runs, with all demonstrating [sound 1] and [sound 2] occur simultaneously. Examples include: (included in demonstration video) (a compilation video, only some clips relevant) For in game comparison, here is a second demonstration video also showing this split of [sound 1] and [sound 2]: The mission used for testing is attached, with the vehicles serving as distance markers. Use F7 to reach the appropriate vehicle to observe from, the AI A10C will make passes every ~2 minutes. A10AudioTest.miz