Warmbrak

I have the same problem. Device Analyzer picks up other devices but not my Combined Thrustmaster device I actually need it for.

With the F-15E I get a lot of miss-selections to take control of the HUD with the current implementation. To take control of the HUD one has to: Press Castle; then Press Castle Forward Short (overriding the base function). This needs to be be done quickly in succession otherwise it does not work. I find that holding the Castle Press a bit longer before scrambling for the Castle Forward improves the chance to get it right, but half the time I end up invoking the base Castle Forward Short and switching between A/A & A/G Master modes instead. Seeing that there is no implementation for the Castle Forward Long command, can we please get a simplification to assign the Take Command HUD function to the Caste Forward Long press? If this is not an option and future Take Command Enable actions will be implemented, please increase the listen duration of the Castle Press command so that the Castle Forward override can be detected more reliably.

Running on 2.8.8.43489 Open Beta and I can confirm there are performance issues with the L compared to the M (and other helicopters such as the AH-64D). This is especially prevalent at night in the city environments. I set up a night mission in Cyprus and took the same scenic flight with the M and L version. M is buttery smooth, but the L version struggles with the lights and in some case the framerate drops from close to 100 down to single digits where it becomes impossible to fly. I don't get the stutters, but something in the L version definitely eating frames. I have also experienced strange 'demons' in the flight model where the airframe feels like it wants to tilt over to the right (low speeds, not retreating blade stall). In one case I landed it softly and wanted to take off again and it simply tilted on the right skid and the main rotor touched the ground - this never happened before. I have attached the basic mission - 3 slots are available, L, M & AH-64D for comparison, local time 23:00. F_SYR_Heli_Training1.miz

The livery was updated to V1.2 featuring larger roundels, as well as a new heavily worn scheme. Here is another South African scheme for the Hind based on the 80's Puma/Oryx livery. It comes in two flavors: Early 80's with old SAAF roundels Late 80's featuring modern SAAF roundels These can be downloaded in the file section: https://www.digitalcombatsimulator.com/en/files/3331029/

I just released update V1.2 for my three-tone livery that is available in the file section: https://www.digitalcombatsimulator.com/en/files/3330922/ The latest update includes a heavily weathered version of the skin and resizing of the decals. I have also been working on a 80's livery based on the Puma/Oryx that will come with two versions, old and new markings. This will be a separate download and has been uploaded for review; will hopefully be available soon.

Here is the livery: https://www.digitalcombatsimulator.com/en/files/3330922/

I am working on a Modern SAAF livery at the moment. null

Great news, thanks @peyvolt!

I added the probe to the excellent SAAF Mirage F1AZ skin versions and have the same issue with the untextured refuelling probe. Did you manage to find a solution?

Thanks for all the links; I do watch his channel but didn't look at all those videos. I fly open beta. To be fair what I am seeing may not be loops but they are definitely spiral climbs with a huge energy advantage that sees the AI outrunning and outperforming me all the time. Even if I don't try to climb with the AI and turn horisontal instead I still can't match it. Flying against humans in the past I can easily work out what I did wrong when it happened, but the AI seems to employ "aerial magic" sometimes. A year or so ago I tried the viper against an AI MiG-21 and got my butt kicked a few times - those were probably more akin to vertical loops now that I think about it. At recruit level difficulty I would expect AI to make mistakes and not have near perfect energy management. The AI flying into the ground after a few minutes is also not right - I would rather see the the AI try to disengage and RTB rather than crashing into the ocean, possibly due to fuel starvation. I don't expect AI to perform like humans but there are basic things that can be introduced to make them appear more realistic. I'll catch up on those videos, thanks again.

I took a break from DCS for a few months and picked up the excellent Mirage F1 from Aerges. Started doing radar work and air-to-air with the AI and it looks like the same issues persist today. AI (on recruit difficulty) has seemingly near perfect energy management skills up to the point where I am thinking "Wow, how did we go from similar energy states in a horisontal scissor to the MiG 21 suddenly doing a booming circle climb running circles around me?". Same with the F-4E; that fight basically ended up with the Phantom doing slashing attacks on me; as soon as I extended and built up energy it was on my again, I had to defend and once I win the scissor he would just extend in a climb, leaving me in the dust. I thought I would try the Viggen as it usually does not retain energy well after a few turns. Wrong. I could stay in the circle on its 4/8 position but it was impossible to gain any distance on him to attack with the cannon. These fights mostly ended with maneuver kills - AI finally flies into the ground. The MiG-21 once just stopped fighting and flew in a straight line all of a sudden, probably due to low fuel state. The one fighter I managed to beat a few times was the MiG-23 using boom & zoom tactics until I was able to get into a position to Fox 2 him. I know I am not great with air-to-air but I have flown a lot of online over the years and I can usually hold my own. The AI just still feels wrong. I remember the AI in LOMAC and Flanker being much more enjoyable back in the day. It is disappointing to see that over a year later the AI situation still hasn't changed much. I always wonder how this affects all the paid campaigns, or do they try to avoid air to air as much as possible or focus on BVR instead?

Folks on our multiplayer server are complaining about this exact issue today - came here looking for a fix. Pretty disappointed that this has not been dealt with, especially if this has been reported internally.

I can't remember if this has been there for a while, but I noticed this while testing the 2.7 Open Beta. When using the OFP2 rocket pod (I haven't tested other Russian rocket pods) on the Mi-8 and KA-50 (I haven't tested it on other aircraft), the lower poly LOD version of the POD is offset slightly lower than the high-quality one. This is most evident when using the aircraft flyby camera as demonstrated here: https://youtu.be/ib85EGXXZN8

I will double check alignment, but the coordinate was good. The navigation marker was located perfectly on the building, so a CCRP drop would have been effective. The TD when switching to AG mode was off by almost 30 miles. With the actual steerpoint being where intended I don't see it as an alignment/coordinate issue. I am tired of using precision weapons to be honest. In most squad missions I can pre-plan deliver JSOWs in the F-18 from more than 30 miles away and take out targets in multiple locations. I prefer an 80's mission setting where Hornets and Vipers still had to rely on CCIP and CCRP bombing modes, and CCRP bombing of hardened targets through cloud cover was the preferred method of bombing; the aircraft systems were designed for that. Obviously one could use the ground FCR to confirm target location and lock it up, but we don't have the luxury to do that in DCS yet. I understand how your comment was intended, no worries and I appreciate it. But saying no one would ever do that is not entirely correct.

This is not a steering line issue; the TD is off by 30 miles.

I stay away form the F-16 to avoid disappointment as much as possible, but every now and then I give in and set my expectations pretty low. One of the missions on a favourite server involves demolition of the Assad building on the Syria map. SEAD flights have cleared a path to the target and I thought using the Viper with four MK-84s would be an exciting proposition. The loadout would not include a targeting pod. With the new clouds possible obscuring the target, I wanted to use a CCRP delivery and programmed a steerpoint right on the target. While the navigation information provided by the steerpoint appeared to be good, I noticed that when switching to AG mode and selecting CCRP for the MK-84s that the CCRP square and targeting information was not focussed on the steerpoint. I looked around but with the lack of a default GM and associated snowplow and related buttons missing there was no way for me to reset the CCRP marker to the steerpoint. The only way I was able to relocate the CCRP marker was to slew it visually onto the building. Did I miss something obvious or is this basic feature not present in the F-16 yet?

I haven't flow the Mirage in a while and have been testing out different air-to-ground loadouts. I am having problems with the 4 x GBU-12 setup with the two bags under the wings; the first GBU releases without a problem (I bomb a JTAC lased target from about 12,000ft up with about a 5 degree nose up attitude in CCRP. After the second release I hear a bang that usually results in damage on the belly of the aircraft and I usually lose the functionality of one of my main landing gear legs. During the release I am pulling at least 1G or slightly more, so I am not flying into the GBU. This has happened twice in a row now which leads me to think that there might be an issue with how the GBU-12's come off the pylons in close proximity. Has anyone else experienced this?

Grimes, thank you very much for your help! I had some trouble getting it working as I initialised my script file based on a trigger at mission start with time more than 10. This resulted in an error message although I was confident in my syntax; I changed the starting trigger from Mission Start to No Event instead and it worked. I am now able to set up custom flags, set the values after conditions are met and print results to the screen for a specific candidate by passing the unit name. With my mission being used in a relatively closed environment and then ends once all participants completes the course I hope to avoid the flaws you have pointed out. This will save a me lot of time in future when setting up similar scenarios. Thanks again.

Thanks for responding Grimes. I think I understand what are you are saying but again I have trouble visualising how this would be implemented and play out. In my mission for instance the number of participants is capped to 8 players, and these are differentiated by 8 x F/A-18C slots, each in their own group. At the start of the mission I want to create the object/table that will house all the information. Seeing that not all players may be have logged in at the start of the mission, I will only detect once they are in by detecting a spawn slot being allocated, or for that group ID to pass a trigger check. If I understand correctly, I can call the script from your example at the start of the mission to declare the container 'players' and the two functions. With players being set to local, it cannot be accessed by any other do script or script files, but I can call the createPlayer and unitSetAtWP functions from any do script or script file subsequently? So the first candidate passes the first trigger. I now know there is a human occupying that slot (or I can detect the slot being taken up, but don't know how to do that yet). At the first trigger for candidate 1, I call 'createPlayer(CD1)', where CD1 is the group name of candidate 1's F-18 I specified in the ME? That will then create a '2D' table entry where the list pEntry gets added into the list/array 'players'. Call the same function for similar triggers for the other candidates will then insert their entries into the 'players' list. Sorry for repeating what you have written, but I am writing it out in the way that I understand it and will hopefully make it easier to catch things that I may be misunderstanding. I will test this out in the ME, thanks again!

Premise I have built a multiplayer mission that will test the ability of 8 participants where each follow a set of waypoints, and destroy targets with specific weapons. Upon landing, they taxi to an area, lower their tail hook (F-18) and receives their score (pass or fail). Each participant requires 6 conditions to be tracked for a total of 48. Using the ME and triggers to test for various conditions, I have a LOAD of triggers that caters for each individual candidate. Repurposing the mission becomes a nightmare based on the sheer number of triggers that need to be managed. My Goal To replace the 48 flags with an object that I can instantiate for each participant - OR - create a data object that can track x number of conditions for y number of candidates, set when instantiating the object. For each participant I would like to store a string with the participant's name, and then basically a boolean for each of the conditions. After the data object is instantiated at the start of the mission, I would like to access it using functions to set the conditions for each boolean for a specific participant id. Some of the functions would include testing for pre-defined conditions including the final evaluation. My Challenge I can read and understand code much better than I am able to produce it, and my LUA skills are limited. I have read the threads regarding LUA scripting for DCS in the ME, and I have seen examples of class definitions where such a data container can be defined, and member functions to access it. The problem is I don't really know how it all fits together, and even if something like this is going to work. Can I create a lua file that defines the class and member functions at the start, and can I in the same file instantiate the object, or do I need to instantiate if after the definition lua file has been called using DO SCRIPT? Is that object global, and can it be accessed by all subsequent DO SCRIPT calls to the member functions? It is safe to say that I know enough to be dangerous in this area. My Request I know it takes a lot of time for someone to look into something like this and I am not asking anyone to write any scripts for me. I have been looking for working examples missions that I can study by looking at the ME and the LUA files to try and understand how it all fits together, but I am probably looking in the wrong places as I can't seem to find anything. I am sure there are existing frameworks out there that might be able to do what I want, but I am trying to learn and understand the basics and would like to avoid those for the moment. If someone can please share with me an example they have that may shed some light on how these things fit together and how my goals can be accomplished it will be greatly appreciated - or point me in the right direction.

I don't want a refund - I would like to get it fixed. Even though it is a hit & miss affair there are some features that I simply can't do without. I took an hour long drive with a LAV-25 on the Syria map on Saturday through the mountains east of Beirut; I had a lot of fun, but it isn't hard to spot where the shortcomings are. DCS physics aside, there are many quality of life changes that can be made that will not require core changes to the engine. The question we are all asking: Is ED spending time/going to spend time to improve CA? Until we get a clear answer we can argue until we are blue in the face. It is something that people have spent time on, and I believe we are entitled to some kind of response. Imagine where we could have been today if user mods were possible for CA? Imagine having modded vehicle interiors, controls that made sense (and that actually worked), and all these mods would require ownership of CA. Imagine how popular this addon could be for DCS and how many sales ED would get? It is good to dream sometimes...

I have to come out and say that I did not consider all the possibilities regarding unlimited fuel/ammo. I did not mean to berate your original post @DimSim - my apologies if it came out as such. If there was genuinely a requirement from ED's many private/commercial clients (military, contractors, test-pilot schools etc.) to change this mechanic to suit their training requirements I suppose it would have been implemented by now. It is also possible that more robust settings are available in the commercial version of DCS and not in the consumer flavour we have. It is not a popularity contest, and I can see now there are legitimate reasons for expanding this mechanic. Where it fits into ED's priority list where development time costs money I can't say. DCS is full of 'cheat' mechanics and these are necessary to compensate for many factors that can simply not be accounted for on a PC platform. As many here have rightly stated, there could be a benefit of expanding these mechanics to better suit training and development needs. To me the original post was a little bit vague and I felt the request could easily be accommodated with the current functionality in some way or another. Hopefully you are able to convince ED to spend the time and make this feature available in some form or another.

I must be then - Since Flanker 1 I have never had the need for unlimited fuel or weapons; I would just restart the mission and do it over again.

Very true @QuiGon! I think there is a fair bit of frustration amongst the Bombcat enthusiasts that have been waiting for this feature since the launch. As always, we just need to be patient and hope we live long enough to see these features in DCS.

I would be disappointed if the devs allocated time away from more important tasks to enhance a cheat mechanic that has very little use in the greater scheme of things. For realistic weights for landings, just turn the cheats off for that mission; no need to do it all in one mission.