Aarnoman

To echo what has already been mentioned - I use VIACOM for voice control of the F10 menu in VR. - Helios for display export (wannabe simpit that is not there yet, but hopefully in time ). - DiCE for countermeasures in the hornet, since we still don't have DTC/a system like the JF-17 For specific files/uses please see the above posts, the developers of all three have already posted in this thread now.

I would also like flags changed to named variables - as is standard for virtually every scripting language out there. Flags are unwieldy, difficult to keep track off once your mission has more than 5-10.

+1

+1, just came across this in flights as well.

DCS Version: DCS 2.5.7.10869 Brief description of bug: Embarking/disembarking appears to work very inconsistently, if it works at all. AI units often fail to disembark, embarking is slow (with group units stopping and individually approaching the transport unit), or failing to embark entirely. Expected behaviour: The embarking/disembarking system needs a rework to be more logical, as currently embarking needs to be set on both transport and cargo unit. Additionally, the current system is complex and rarely yields the expected results, is inconsistent with the style of most other To reproduce: 1) Run example mission an observe AI behaviour. Note the following: - Erratic AI helicopter behaviour, with unusal turns/uncommanded repeat landing at waypoint 0/etc. - AI slowly entering helicopter 1 by 1. - AI infantry failing to disembark - Failure to move on to last waypoint despite the landing action being of timed duration. Why is this important: Embarking/disembarking is an important core functionality for infantry, and moreso in the light of the upcoming heli-centric modules like the AH-64D and recent Hind release. As it is not possible for mission editors to easily use embark/disembark functionality due to unusal AI behaviour/inconsistent results/general headache that is trying to wrangle the incompetent ground AI, these functions are rarely if ever used in missions. I do not consider the current system functional as it often requires greater than half an hour of waypoint tinkering to get expected results, often for no clear reason. This system likely needs to be rebuilt from scratch as thhe current system is not servicable. | EmbarkDisembark.miz

I strongly support OP's request, it adds immense possibility for mission creators to tell more interesting stories, while also allowing for increased depth and complexity (e.g. IFF/ROE considerations with unknown contacts, more 'false' contacts on radar, intercept/escort missions, and breathing a bit of life to an otherwise sterile sky).

Hi, likely the same bug as here:

DCS Version: DCS 2.5.7.10869 Brief description of bug: Radio items can be added to specific coalitions/groups using the "Radio item add for coalition" and "Radio item add for group" commands in the mission editor. However, this currently does not refresh correctly on mission starts, with previously created radio items carrying over to new units inappropriately. It appears that the radio items displayed for the testing unit on mission creation carry over to all units by default as a result of this bug. This only occurs on the first client unit entered. Verbal Example: -2 client units: "Group1" and "Group2", both on blufor. -Trigger with "once", with "Radio Item Add to Group" for group 1 and group 2 set up, announcing "Group1" and "Group2" on the radio item. -Start mission. Enter Group 1 as client. F10 radio item should read "Group 1". - Restart mission, this time entering the client unit Group 2. Check F10 radio item, it will continue to incorrectly read "Group 1". This results in radio items not appearing when they should for client units, and inappropriate radio units appearing for others. From my testing it appears the radio items present for the very first client unit entered by the mission editor will be what any other client units see in their F10 menu, with the coalition and group ignored. See example mission attached. Expected behaviour: Both "Radio Item Add for Group" and "Radio Item Add for Coalition" should only be added to the respective coalition/group selected, and refreshed appropriately on mission starts. To reproduce: (Example mission attached). ----- Brief description of Mission 1) Load example mission. It includes 3 client units: "Group1BLUE", "Group2BLUE", "Group3RED" 2) Note the trigger construction. It includes: - Radio Item add (should be visible by any unit). - 2x Radio Item add for coalition (should be visible by appropriate coalition) - 3x Radio Item add for group (should be visible only by the specific group). 3) On creation of this mission, the first test unit used was the GROUP3RED client unit. This means that the radio items added for any unit will be "Group3Red Check", "Red Coalition", "General Radio Check", even if the unit selected is not this unit. ------ Reproduction steps: 1) Start mission from mission editor. 2) Enter Blue -> Group1BLUE unit. 3) Check radio items. Note that the inappropriate radio items "Group3RED Check", "Red Coalition Check" are displayed, even though the entered unit is not either and these should not be displayed. 4) Restart the mission and repeat above with Group2BLUE. Note the same inappropriate radio items are added. 5) Exit to spectator -> reenter Group1BLUE. Note that now the correct radio items are present ("Group1BLUE Check", "Blue coalition"). This same bug can also be reproduced by launching the mission on a dedicated server. Why is this important: Currently breaks missions using radio items if unique items used, and multiple clients are present. Additionally, it creates significant confusion for the mission editor as radio items do not behave as expected when testing with multiple client units. Side notes: From my testing it appears that the very first client unit entered by the mission editor becomes the "saved state" of radio items on first launch of the mission. These only correctly reset on selecting a unit -> entering the plane (clicking the fly button) -> returning to spectators -> reselecting a role. It is a very unusual bug that is difficult to report in words, if there is ongoing lack of clarity/difficulty reproducing it I can create a video demonstration. Additional Note 2: In certain situations it is possible to have these radio items carry over to a seperate mission entirely. I have not yet been able to reproduce this consistently, but will update the bug report further if it is discovered. RadioItemTestCaucasus.miz

He does explain it pretty well in his post:

+1

I think ED could learn from the mantra "don't let perfect be the enemy of good enough". As it stands, based on the white paper a few months ago the requirements they have set themselves for new AI models is so ridiculously high it is no wonder a single model seems to take a month to develop. In my opinions they would benefit from loosening this slightly - as much as I like the quality of models, I would be much happier with half the quality but twice the volume of models released.

+1, can we please have a custom kneeboard folder for Syria so we can add appropriate aerodrome charts please.

Who is this for: Users who have good internet connection, but DCS standalone download speed is significantly slower than other downloads (torrents, steam, etc). Process: 1. Open windows command prompt as administrator (search CMD, right click "Command Prompt" -> Run as administrator). 2. Type netsh interface tcp show global 3. Check output, which should look like this: 4. If "Recieve Window Auto-tuning Level" is not set to normal, proceed to step 5. 5. Type netsh int tcp set global autotuninglevel=normal and hit enter. 6. Output should be "Ok" if command applied correctly. 7. Reboot computer. 8. Start standalone. Your download speed should now be increased. Why this works? Windows Auto-tuning optimises TCP traffic recieve window, optimising download speed. This is generally disabled by default as it may decrease speeds on older routers. For more information, see here. How do I undo the changes made? There should generally not be any good reason to disable window auto-tune level. However, if you wish to do so: 1. Open command prompt as administrator as above. 2. Type netsh int tcp set global autotuninglevel=disabled and hit enter. 3. Reboot computer.

Regarding removing trees/map objects, you can already do this using trigger zones and sceneryRemoveObject command.

I am very supportive of such an addition.

Show your support on these two related wishlist threads

Are you running any mods? I am unable to replicate your issue, my units follow waypoint on road as intended. Alternatively, can you post an example missions with this issue?

There is a similar wishlist thread from just a few days ago that ties in well with this:

+1, would be very useful feature.

No. DCS does not use an older unreal engine, therefore it would take a complete remake to switch engines. This is not feasable or realistic.

This area was a new addition in last patch, and it is unclear whether Ugra will make this area more detailed in the future.

Part 2: Placeable static vehicle defensive position models (For part 1 of this wishlist post, please click here) As was discussed prior, berms and defensive entrenchments are crucial in modern ground warfare, allowing for the creation of effective cover and concealment in a short time span. Currently, we lack the ability to place defensive positions in DCS without resorting to mods, as no static models are included in the current version. This wishlist item is for the inclusion of a variety of static models of vehicle defensive emplacements. This is distinct from the berms in Part I of the wishlist post, as these vehicle emplacements would be static models analogous to other static objects currently available in DCS. Note the long berms almost surrounding the defensive positions, while the vehicle defensive emplacements are small - only protecting individual vehicles. These are shown in blue. Defensive vehicle berm surrounding Israeli artillery. A destroyed Iraqi tank sitting in a defensive emplacement. Defensive vehicle emplacements in Syria, protecting an MLRS site. Expected implementation in DCS: I would like to see a set of static objects acting as emplacements. These would have a collision mesh, thereby allowing for units within the emplacement to have some additional protection from incoming rounds. By being static objects, mission editors would be able to freely place these anywhere on the map. We already have several defensive emplacements as static map objects in the Syria map. I would expect to see several variations of these in terms of construction material and size, but as freely placeable static objects. An excellent example of how this should be implemented is seen in the model available in the Frenchpack mod: In mission editor In game demonstration of the frenchpack placable defensive emplacement. Note the effective protection offers to the front and sides from both air and ground level attacks, while still allowing the vehicle to engage targets effectively. A set of vehicle defensive emplacements on Syria. Note the variations in size. I would like to see other such variations as placeable static objects. What would it add to DCS? Gameplay and visual benefits would be similar to placeable berms, providing effective cover and concealment for ground units allowing for a significant tactical challenge. This would benefit all aircraft with A2G capability by creating more interesting and immersive mission considerations, while adding to the visual fidelity of the ground war. This would particularly benefit the new set of flagship ED modules, including the Mi-24 Hind, AH-64D Apache, and PC’s OH-58 Kiowa. For a full breakdown of benefits, please see the section covering gameplay and realism benefits in Part I of this wishlist, discussing berms. Concluding remarks: Like with defensive berms discussed in Part I, defensive vehicle emplacements offer mission editors a significant upgrade in crafting convincing defensive positions. Furthermore, it offers a significant gameplay addition by creating a more challenging environment to fight in, offering ground vehicles some protection from both ground and air engagements. The upcoming set of flagship ED modules, including the Mi-24 Hind, AH-64D Apache, and PC’s OH-58 Kiowa would all immensely benefit from this by allowing mission editors to create significantly more believable and immersive ground environment. I would consider this a high priority feature, as it will add significantly to the detail possible for the ground combat environment, while requiring very little work from ED – the models needed for such defensive positions are simple, as most are quite literally just small mounds of dirt. This negates much of the need of creating exact-to-specification models as would be required for vehicles or other units, as is standard operation procedure for ED per their recent whitepaper on the unit model creation process. As such defensive emplacements can be used in any setting (WW2 to contemporary, any map – Caucasus to Syria) it is a feature with limited work required while significantly adding to the DCS core. Therefore, I hope that this is seriously considered and discussed by ED, with involvement of both primary mission editor developers and model developers. Thank you for your consideration. With Kind regards, Yoyo

Part I Wishlist: Placeable berms using spline implementation For Part 2, click here. Abstract This wishlist post will be discussing placeable defensive berms ("earthen defensive walls"), using a spline-based implementation similar to that seen in TDK (terrain development kit). Such an implementation will offer numerous benefits to the DCS community - both gameplay and graphic wise, significantly enhancing the possibilities of core DCS in both free and paid missions/campaigns, of particular benefit to players of the new line-up of DCS helicopters. Notably, as a significant amount of groundwork has been laid through TDK, it would be realistically possible to port/integrate this as a native feature of the mission editor with limited amount of work needed from developers. Part 2 of this post will discuss static object vehicle defensive entrenchments, found here. An introduction to defensive emplacements and berms Military engineering and earthworks have been of critical importance, both historically and contemporarily, in ensuring successful military operation. From disorganised insurgent groups to well-funded armies of first world nations, the manipulation of the environment has long been a cornerstone in increasing the odds of successful defence and more effective engagement. Vietnam era base with prominent berms surrounding it, providing both cover and concealment Modern Berms in Syria “Berms” refers to an earthen wall, which creates a barrier in the terrain and acts as a defensive wall. They can act as an effective obstacle against vehicles – including many APC’s and tanks – while being easily scaled by infantry. They can be rapidly constructed, and act as effective protection for personnel, vehicles, and equipment from both direct and indirect enemy fire. Berms are found in most defensive positions in conflict zones and are often rapidly erected to allow for better control of newly gained territory. Perhaps one of the best conflicts to illustrate this is the Syrian civil war, where the following berms were placed by an advancing Syrian army in the span of a few days to hold new ground: Defensive berms constructed rapidly to hold new ground in Syria. See attached .kml google earth file for ground references of these and more. How could it be implemented? Interestingly, the ED TDK (terrain development kit) already allows for creation of berms. These currently only feature on the Syria map, and appear as follows: Berms as map objects on Syria, in the Golan Height region. The same berms, seen in game. The system used in TDK to create these berms appears to be splines. This essentially means vertices (These can be thought of as “points” or “nodes”) are created, with lines connecting each vertex sequentially. This set of vertices with lines connecting them is referred to as a spline. A shape (the final berm) is a repeating 3d object (a simple model of a straight berm defining geometry+texture) that is then repeated along the entire length of the spline, creating the continuous berm. Splines in general principle can be selected to either have straight or curved connections between vertices – in the case of TDK, it is clear splines can be curved as demonstrated by the existing berms on Syria, which have a smooth, curved appearance. For a demonstration of splines as they typically appear in video game level editors, see this video here: (https://youtu.be/hbMikfPf16Q?t=139). The purpose of this explanation is to outline that the technology to create splines is already a native feature of the Edge engine – however, it is currently only available in the TDK and not the mission editor. Therefore there is potential to port this feature to the mission editor, as no changes to the map geometry need to be made for inclusion of spline-based berms: they are additive in nature, as opposed to a trench which would have to remove part of the map geometry. The berms would therefore act in much the same way as normal placeable static object such as buildings or units in terms of game logic. Expected implementation in DCS: My wishlist request is to make such a tool available in the DCS mission editor, where the mission creator can place berms by setting multiple vertices, with berms created in the lines connecting these vertices – “splines”. This would maximise utility, as the overall shape of the berms can then be dictated by the mission creator, instead of being limited to several fixed presets as would be the case with a placeable static model. It would be expected for these placable berms to have a functioning collision model, thereby protecting from weapon impact. The implementation of such a feature using splines would have another advantage. This system would be extendable to placing any other continuous object so long as 3d models were created for them. Practical examples would include walls and HESCO barriers, both which would immensely to extend the ability for mission editors to alter the natural environment to suit gameplay and mission purposes. This is therefore an effective future-proof system, with significant potential for iteration and expansion. Expected workflow would be as follows: · User clicks to create a sequential line of vertices (points), with lines connecting each vertex in a sequential order. This creates the spline. · On the right-hand side, the user would select the shape (3d object) that will be repeated along the length of the spline. This shape would define the geometry and texture of the object, for example dirt/wall/HESCO/etc. Multiple presets may exist, such as “Dirt sandy”, “Dirt brown”, etc to allow for a better fit with the environment/map. · An optional checkbox would define whether the lines connecting the vertices are straight between points, or curved. Note the orange points (user clicks create these), with yellow lines connecting the points to form a spline. On the right, the type of berm (“Dirt Sandy”, “Dirt Caucasus”, etc) can be selected. What would it add to DCS? · Gameplay · Berms to act as identifiable ground markings. This may be used for the purpose of delineating frontlines or general area of operations, act as landmarks, or add to the ambience of mission design. In structured sets of missions such as campaigns, new berms may be created to clearly portray changes to the ground conflict, such as advances made or areas of static fighting (increasingly built-up defensive emplacements on either side over the span of multiple missions). · Berms provide some limited protection from both direct and indirect weapons. For example, it may prevent the use of guided missiles or rockets from low altitude, as they may hit the dirt wall as opposed to the enemy behind it. It also provides some extra incentive to use features such as the JDAM terminal attack heading to increase the likelihood of a successful attack. Note that if berms are created with limited space beside the vehicle (example image), it may even protect from near misses by absorbing most of the blast. This may be used to create an interesting tactical challenge for the player. The request for close vehicle berms as static placeable can be found in part two of this wishlist request, linked at the end. · It will add significantly to helicopter gameplay, including the newly released Mi-24 and future AH-64D Apache and Oh-58 Kiowa, by creating a more interesting ground environment to fight in and against. · Creates a more interesting environment, with many tactical considerations, for combined arms players. · Realism · Berms add to the authenticity of the ground environment, adding variety by allowing mission editors to alter the environment in meaningful ways. · In real life, berms are heavily used in nearly all defensive positions of semi-permanent or permanent nature and may be quickly erected to hold gained ground. This is due to their inherent ease of use, speed of setup, and reasonable degree of protection and concealment offered. · Bases, i.e. FOBs used for helicopter operations, would look much more lifelike by adding berms as a defensive perimeter. Concluding remarks: The ability to place berms using splines in the mission editor would significantly enhance the capabilities of creating a more lifelike ground environment: · Both immense graphical and gameplay benefits, as outlined previously. · Adds to the toolkit of mission and campaign developers, allowing for a clearer communication of the ground war environment and frontline advances/losses. · Furthermore, if such a system was implemented using splines as opposed to static placeable models, it could easily be extended to placing HESCO barriers, walls, fences, etc with minimal work from the ED team, thereby futureproofing the system. Many thanks ED for the previous additions to the mission editor; I hope this wishlist item is too seriously considered and discussed as it would allow immense capability with limited work (as much of the foundation has been laid in the implementation within TDK). I hope the primary developer(s) for the mission editor and terrain development kit both see this post, as they would be most knowledgeable on how such a feature could be ported/implemented. I would consider this a medium to high priority addition, as implementation would likely be minimally to moderately resource intensive, with most of the pre-existing groundwork laid in TDK. This is weighed against the significant expansion of capabilities of mission designers in creating a more immersive ground environment. This is particularly important now given the release of the Hind, and the soon upcoming flagship Apache and Kiowa module – all which would benefit immensely from such an enhancement. Moreover, as DCS core addition all other users engaging in A2G warfare would also reap a significant upgrade in terms of both visual and gameplay fidelity. This implementation is designed in conjunction with a part 2 wishlist for placeable static vehicle defensive emplacements, which are a separate thread for clarity and convenience. Please click here for part 2.

Source to the contrary, based on Maestr0's posts in the Syria preview thread dating back to March/May 2021.

Agreed on all points.