v81

That's not what Mike has an issue with. As part of a bundle the sale is completely useless to anyone that has one or the other already. I was seriously considering buying the Tomcat, but i already own the Hornet, and that will be the case for hundreds of others. Doesn't seem well thought out. Anything on sale as a bundle should be on sale individually as well or else ED are simply going to miss sales from existing customers.

With all due respect I think the forums are a better place to get feedback prior to such a massive change that is knowingly game breaking for a large portion of the playerbase. Good or bad, OpenBeta is treated as 'release' for the bulk of the MP community, and making such a massive change without consultation is just not sensible. I think the bulk of the frustration and fear are from several things, a few of what I list here others have repeatedly voiced... 1) Lack of communication / consultation. 2) The scale of the change 3) That it sets a precedent leaving us in fear it could happen again. 4) That other more important and overdue things aren't being worked on. For number 4 I submitted .miz files for fixed Su-25T training missions several (4?) years back, I literally did the work for ED, and ED sat on them and did nothing until years later, when they were actually (partially) fixed just recently. This issue put off new comers to the sim for years. Also on #4 a large portion of overdue or corrected functionality is provided by others in the form of files that now break IC, it's ultimately a slap in the face to people who have been doing ED's work for them. Did no one spare a thought for the likes of Warthog Project and others who rely on this functionality along with untold thousands of others?, and the time and effort they put into promoting DCS and sharing what they learned. Was it really necessary for us to lose the obvious functionality of CMDS and viewport configs? If these things are exploitable they should have been fixed behind the scenes, not by removing what is essential functionality for some of us. BIGNEWY, a lot of us just want to know how this happened, and want some assurance it won't happen again. The vast majority of DCS users are advanced in terms of following development and I think a bit of communication is owed. Lack of consultation and communication seems to be the core issue here, and is sadly a recurring theme when any drama happens, despite promises from ED staff that this would be improved on.

Quoting @BIGNEWY from another thread. What cheats and exploits? We've been smacked over the head with no warning with this game breaking nightmare.... and there is no justification? What exploit were you trying to prevent by removing the ability to have instruments exported? What exploit was solved by removing the ability to set personalised CMD profiles? I'm really keen to find the genesis of this decision making. Someone knowingly did this, and surely should have known the obvious repercussions. DCS is build on the modding community, a large portion of the user base is running one mod or another, with many of them actually dependant on the mods for functionality (display exports, elevator trim fix, RWR fix, etc..) and overdue convenience (Dice, custom quick starts). The idea of coming up with a list of affected mods in that other thread so as they may be 'considered' doesn't sit right with me. My concern is, that the gate is being shut here for future mods that don't exist yet, and given how reliant I've become on mods, often providing functionality ED can't/won't/haven't yet I'm pretty bothered by it. I can see 1 thing happening for sure, many servers are going to ditch IC requirement either by necessity, protest or both. ED needs to wheel this back in full immediately. Whatever it was that was trying to be achieved needs to be done in a better and smarter way. White listing a limited selection of current mods and forcing future mods (when the majority simply provide near essential functionality) to go through what WILL BE a difficult, slow and convoluted process and even face a prospect of a ban hammer is ridiculous and should not be the solution. Removing exploitable items from these plain text config files seems to be a vastly superior idea, whilst leaving us the customisation we need to set-up our sims as we see fit. To ED I say... Don't make us justify our mods that you already know are good and sensible. How about you justify why IC got so broadly expanded with zero community consultation knowing full well it would break things. Are we going to have a good business / client relationship here, or are you placing yourselves as overlords and us as mere peasants? I think the above is more than reasonable and healthy debate should be allowed.

Been seeing this a lot lately. Click an airfield to get nav beacon freqs, ICAO id etc... and no data panel.

Trying to look at the Shkval in the main pit and in the export is terrible. The attached example happens to be looking unusually good, so not a good example, will post back when i am in different lighting conditions next.

Same issue here, and it's bugged me for ages but never thought to make a thread for it. But now there is one I'll toss my hat in too. Attached is the Physical layout, 2560x1440upper display and 1024x768 in the lower right. DCS main viewport is on the upper display only with the lower one for exports. My controls and Autopilot indicators are stretched vertically in this configuration as if their size is based on the overall height. I'd love to make them smaller, even smaller than default would be great. Also the AI gunner controls for the Mi8 and UH1 appear on the lower display. Helios.lua

I've not noted the exact figures, but i have experienced what seems like this issue. Especially when using illumination rockets on Georgia at War during night ops. Sometimes too many rockets seem to fire, sometimes none will fire.

Should this be appearing whilst actually trying to use HARMS in TOO mode? It's quite annoying trying to switch between and handoff targets only to have the HARM display replaced with PLBK

Necroing here, but keen to see STM32 support myself. Currently using a MEGA2560 and even with it's extra ram (8KiB vs 2KiB) over the micro I'm still running out.

Totally agree.. It would have been less annoying if it had released this way, but the fact that it was once by default in English/Metric and they at some point swapped it without consulting the community really annoyed me. Instead of doing the work to swap it they could have left it as is and in a crude way to describe it, copy pasted it and made a 2nd version in english/imperial. Ultimately would have been the same amount of initial work with the exception of adding another cockpit option to the settings. Metres to feet multiply by 3 and round up. (eg 6000m x3 = 18,000ft wind it up a bit and call it ~ 20,000) Feet to metres go one third of the figure and round down. eg opposite of above. Kts to KM/h double it and round down. KM/h to knots, halve it and round up. All very approximate. The ultimately annoying part is that it was once correctly in Metric and was changed whilst i wasn't watching. Additional annoying part is that now there is inconsistency across modules, with the Mig21, Ka-50, Mi-8 etc retaining metric in their English pits.

Have found a few things, and more at night about the Mi8's electrical logic that do not stack up. Without a chart or schematic i can't be sure, but here are a few issues i'd love to find answers for. The panel lighting seems to be low voltage DC powered, seems sensible and realistic. However the lights remain (unrealisticly) dim until the main engine generators and rectifiers are bought online. Assuming the lighting is incandescent you'd expect at least 70-80% brightness until nominal operating voltage is achieved. Also does the APU gen not charge the batteries and supply power to the same bus these lights are on? Switching the APU gen on does not bring the lighting up as i expect it might. The most obvious issue is the R828 radio, it remains non functional until the main gens are online. I'd expect it would come online with both inverters powered up making the radio usable for any pre-startup work required. There probably are more affected systems but these 2 i encounter on a regular basis. Can this be looked at, and if possible can someone point me at a bus diagram, I'd love to look at it more closely myself both as a flight sim and and electronics geek.

The community could bring to much to DCS if ED would be more accommodating. I encourage ED to support this.

Damn that was quick, much appreciated. I believe this idle/stop feature is beginning to appear on other moderate to high end throttles now, this is a nice little quality of life feature that a few people will appreciate.

Still pretty keen to see a fix for this myself. I don't say too much, and don't ask for too much, but the issues with older modules and older paid DLC missions are getting to be really annoying. I have a bunch of campaigns I paid for and many have bugs, some even well known and well reported, but still not acted on for years, no exaggeration, literally years. Just one random example - Su27 Ultimate Argument Campaign, over 4 years from issue reported to solved... For downloaded user content it's annoying but forgivable, but when I hand money over for something it needs to work consistently, or if broken needs to be returned to proper functional status ASAP. Alternately if a product is going to have a limited working lifespan then it needs to be advertised that way. Sorry to rant but this is getting really annoying. It wouldn't be such a big deal if it were not true that a vast majority of the products for sale are either incomplete or have long standing issues (or BOTH!). Put plainly the failure rate is too high. If a product exists with a price attached to it in the store then it should be tested with every release. Got a small team and limited resources? then at least listen to the users for reports and fixes. I still find it incredible that the introduction training missions for DCS World are faulty and highly likely to leave a bad taste for potential new players. Try approaching the Su-25T Landing - hard training mission from the perspective of a new player. And as co-incidence has it the Su-25T Shkval mission also had issues that are relevant to this very thread, the lazy fix being that the time of day for that mission was changed, though I do at least salute the fact that something was done about it, having it not work in front of a new player with little understanding of the mechanics and why it wasn't working was a bad look.

A few years back i was happy that the L39 pit could be read in English but still used the native units. Seems now this is no longer the case with Avionics Language set to English. If i set the option to Native the Abris in the Ka-50 changes to Russian. Can we have it back the way it was please? Or at least have a per aircraft option for this. It's kind of annoying and is inconsistent across modules, the same settign that changes the L39's airspeed to knots does not change any other aircrafts airspeed units (that I'm aware of, certainly is the case for the Mi8, Ka-50 and Viggen). I fly both the L39 and Ka-50 quite a bit and have to leave a server to switch back and forth between the Native and English option. Additionally it's also deceptive, as a setting named 'Avionics Language' should not change units of measurement, only the actual language of the Avionics.

I have solved this issue for myself and offer this to anyone interested... In DCS World OpenBeta\Mods\aircraft\C-101\Input\C-101EB\joystick\default.lua (or the equivalent C-101CC directory) Add the line {down = device_commands.Button_118, up = device_commands.Button_118, cockpit_device_id = devices.SYSTEMS, value_down = 0.0, value_up = 0.5, name = _("Throttle Detent - HOTAS off/idle"), category ={_('Left Console'), _('Throttle lever'), _('Flight Control')}}, I added mine under the existing section '--Throttle panel' Now when the throttle is in the off position on the HOTAS it matches in the pit, and when released from off and into the idle position this is also mirrored in the pit. No button pressed needed (outside the single hidden button in the throttle controller). A new binding will appear named "Throttle Detent - HOTAS off/idle" which you will bind the sticks off position to (just move the throttle lever into and out of the off detent when binding). @Vibora Would love to see this make it into the game proper. Can you or your team please make it happen?

Bindings exist, but none to suit the inbuilt off/idle function of the Thrustmaster Warthog Throttle. For this to work it needs an action for both button down (Stop) and button up (Idle). Not sure you're aware of the inbuilt functionality of the stop detent in the warthog, disregard if you already are. The TM Warthog Throttle has 2 buttons, 29 for right throttle and 30 for left, that are pressed and held down when the throttle lever is in the OFF/STOP detent. The A-10C module uses this to recognise automatically when the throttle lever is moved out of or in to the OFF detent with no other action by the user, replicating the function of the real aircraft. The Viggen module had this added to it by request and now it's off/idle detent works great with the TM Warthog throttle and similar units. The Viggen's implementation... {down = 3004, up= 3005, cockpit_device_id = devices.ENGINEPANEL, value_down = 1.0, value_up = 1.0, name = "High-pressure fuel valve (HOTAS Cut off)", category = "Motor"}, The A-10CII's implementation... {combos = {{key = 'JOY_BTN30'}} ,down = iCommandLeftEngineStop , up = iCommandLeftEngineStart, name = _('Left Engine Throttle Set OFF') , category = _('Systems')}, {combos = {{key = 'JOY_BTN29'}} ,down = iCommandRightEngineStop, up = iCommandRightEngineStart, name = _('Right Engine Throttle Set OFF'), category = _('Systems')}, I'm not real good at Lua, but could probably figure out a solution for the C101

As per title, seems a bit silly to not include such a binding for what would be one of the most common applications of the TM Throttle / C101 off/idle. I suspect I could do this in game files myself but it gets rather annoying to have to mod a bunch of bindings in and then have them lost next update. So.. Please Aviodev?

Sadly no. I just re-checked and the L-39 is definitely in knots. Out of interest i set both the avionics and cockpit language to native and it was still in knots. It's worse than i thought. I did used to be in KMh, and infact the current manual still has it in KMh, but no options i pick in game get it to show in KMh as it once did. That's why i made this thread, a precedent exists where ED did a Russian pit (albeit a Czech aircraft) and the dials are not metric. Goes against the Ka-50 which is KMh no matter what. ::edit:: Seems i can still get the L-39 to show metric by setting units to 'metric'. That said i was afraid this might force western airframes to metric, but doesn't appear so in the A-10C II at least. The settings are either inconsistent or non intuitive. Either way it's not ideal.

Just per the title.. Maybe it already is that way, but can't be sure. The EN pit for the L39 used to be in the airframes native units but a year or 2 ago it changed. This upsets missions, briefings etc that are created for the airframe that wish to use the original KMH / Metres units. Also outside of fully learning the native language it's nice to work as closely with the native pit as possible.

I'm still trying to piece the facts together. Not heard anything from official sources, they seem to have gone radio silent over the last few years.. It seems that the official / original DCS bios github is still occasionally active, in particular adding / updating the modules (Viper, Tomcat etc..). As far as support and maintenance outside of modules goes it's complete silence. DCS BIOS core has a latest release of Nov 13 2019 - not all that old or unreasonable. Unresponded issue go back to Jan 2019 DCS BIOS Arduino Library latest release April 30 2017 There are multiple unresponded pull requests for it going back to 2017 Far as the Arduino Library goes, Talbot McInnis (https://github.com/talbotmcinnis/dcs-bios-arduino-library) has been making strides. Latest code is a week old at the time of this post. Have also been advised that Flightpanels is also looking after some DCS BIOS code. https://github.com/DCSFlightpanels/dcs-bios My current situation, just had a massive cleanup, need to put back together my workbench. Will be a thing i do in about 2 weeks. At that point I'll be right on to testing the Arduino library that includes STM32 support using an STM Blue Pill. Not everyone's cup of tea, but a ~$3 micro with more performance than Arduino could be handy. After this I'll be looking to test some STM dev boards with higher pin counts. Kudos to DCS BIOS people for their time and effort. Might just be taking a well deserved break? Edit to add.. Dead might be and exaggeration.. as mentioned above there are multiple forks and others are continuing the work. There was talk of the DCS BIOS guys wanting to ditch Arduino and go with some kind of RS485 solution, not my bag baby, i already have Arduinos and similar coming out my ears.

For anyone that finds this as a search. Enquiries outside this forum basically show DCS BIOS is dead, bar for the changes / additions to/of modules. For micro controller library support (Arduino library) this seems to have move to talbotmcinnis , github https://github.com/talbotmcinnis/dcs-bios-arduino-library I have discussed the adding of support for STM32 with Talbot and this was received very warmly. I'll be testing this out in just over a week, and if all goes well we'll gain the ability to use a potentially cheaper micro controller with significantly more horsepower.

Not looking for more ports, looking for more memory (SRAM) in the micro controller side. One issue that required some code in the Arduino was the PVI-800 output from DCS BIOS is a pain as the strings don't include the commas, the commas are separate outputs and the arduino needs to process the string and put the commas in the right place. I know it's a non issue for someone using a 7 segment display and separate LED's for the commas, but that's not what I'm doing. Am driving an LCD for a multi purpose / multi aircraft pit and want to have it perform a different function per module. Same screen / Arduino is doing F/A-18 UFC, A-10C CDU and a whle bunch of other things. It changes function seamlessly on cockpit change. But... we've run out of SRAM. So it's not about inputs / outputs, it's about the lack of support for anything but a basic 8 bit Arduino. There is a pull request ... https://github.com/dcs-bios/dcs-bios-arduino-library/pull/27 ...that has been untouched for coming up 3 years that says it adds STM32 support. I'll be trying it once I get my workbench sorted again, if it works then we go from the most powerful MCU option being the 8bit 16MHz Mega 2560 with 256Kb Flash and 8Kb SRAM to something like this... https://stm32-base.org/boards/STM32F407ZGT6-Euse-M4-DEMO-Large An ARM based 32bit MCU @ 168MHz with 1024Kb FLASH and 192Kb SRAM (24x more than the most powerful DCS BIOS compatible Arduino. For about the same cost as an Arduino MEGA 2560

Sweet, have posted there. I'm keen on STM32 support as the mega 2560 is proving inadequate. There is a pull request in the original DCS BIOS Arduino library repo that claims to add this support, but it's not been actioned in 2 years.

Using what?? Also have i posted in the wrong place? Inputs and Outputs seemed appropriate.