Leaderboard

It would be nice to have something come from bug reports. I don't mind bugs and problems in early access, that's to be expected. What I do mind is being treated that way when I take the time out of my day, and the days of other people who help me make those multiplayer related bug reports, reproducing them and posting them here with detailed steps on how to reproduce them and uploading tracks. And after all that, nothing is done, no acknowledgement is given, no communication, no updates, just nothing at all. Those people I do those bug reports with feel increasingly frustrated and more unwilling to do it, because they get the feeling that nothing comes of it. And if they get that feeling then something is wrong because either a) Really nothing comes of it, or b) That something comes of it, but it isn't communicated properly and both of those things are issues that should be fixed. I don't know which it is, so I will assume the latter to give the benefit of the doubt. I have posted well over at least 50 bug reports, some recent, some a long time ago, and recently just a single reply from the forum- or DCS staff. I have paid a lot of money, I am taking my time to report bugs, because I want the module to be as good as it can be, and I get ignored. I feel like I'm wasting my time, working for you, for free. I admit that a good portion of those are minor details, not important or often used, but as a big fan I want every detail to be accurate and working. Other bugs are indeed more concerning and relevant to major elements of the aircraft. Some are duplicates, but that can't be helped if a forum is used to keep track of bugs and people using different words to describe things so it can't always be found via search. Furthermore, once a thread had been looked over and marked as "Needs track replay", "needs more information", or "Investigating", it seems like no one every checks on it after a track or more information has been provided ever again. No updates are being made from "reported", if it ever gets to that, to "fixed", except for a select few, very major bugs. On one occasion I was reporting a bug, with video evidence of it, showing it and giving detailed steps on how to reproduce that bug. I have since talked to at least 5 other people who experience that very same bug while no one I asked claim that they did not have that same bug. For me and every one of them the bug comes about by literally pressing 2 buttons in the cockpit and nothing else. Yet claims are made that this can't be reproduced. I did not have a track file at the time but it was requested. The thread was marked as "Investigating". 3 days later the track was provided, showing the bug. In 6 months since then, not a single download of those track files has been made, nor was there any further comment, and nor was the bug actually fixed since then. I don't know if I'm crazy or something, but to me it seems that asking for something, then being given the thing and then ignoring it for half a year seems just a little absolutely rude to me. Since this had been "investigated", this bug is still present half a year later. Granted it's a small inconvenience, and nothing game breaking, but all the same it's disappointing and most of all I feel like I'm being treated like a moron, and as a result, of course I get a little grumpy and frustrated at times and less faithful that my bug reports actually are taken seriously at all. I don't think that's how you should treat your customers who, mind you, are paying for your product. The least you could do is show some appreciation. I feel this should be addressed and improved. To improve the situation I would like bug reports to be updated once their status changes, not just on the initial reading of the report more efforts be made to merge the reports of the same bugs A notification be given if a report has been read and/or confirmed/reproduced A list of known bugs be published and kept up to date, such that the list be easily checked before posting a report, possibly with status updates such as "fixed for next release", until a proper bug tracker is implemented Be revisited once more information/tracks are provided Be acknowledged again once said information/track was provided Be appreciated more I understand that DCS is a large project and that the forums are big and several bug reports for all different modules come in and that not everything can be taken care of right away, that certain things need to take priority over others. But on the other hand, asking for a track and then no downloads or replies in 6 months, or no comments after several weeks is just not explainable by that. There are several people that are paid to manage the forum. And If i can take my evening to look through the bug report sections of a few aircraft and check for new posts, then so can they. Keeping track of bugs with a forum is generally just horrendously inefficient. Personally, I think a new, streamlined bug tracker system should be put in place to link bug reports and software development closer together, such that when the team finishes working on a bug, the bug tracker is updated for everyone to see, including your customers, allowing the simple merging of reports. There are plenty of good, open source bug trackers out there that will do the job just fine. Integrating them of course would take a week or two, but version control and a good bug tracker will make development a lot easier and more streamlined. Taking issues seriously and being appreciative of the community creates a better environment for everybody involved. People feeling like "Writing bug reports is pointless because they're ignored anyway", and that is a quote from some people I asked before to help me report bugs, must be a red flag. The very fact that they think this way lies in how they perceive the efforts being made here. This must be addressed if you want your community to stay engaged with the product you are trying to sell. We're all enthusiasts in a niece hobby, we're passionate about military aircraft and we're passionate about details. Neglecting those that raise issues with either the product itself or with how things are handled generally will create a toxic environment where everybody is frustrated. I don't want that. What I want is an open discourse with an open company that can be both proud of it's achievements while also admitting to it's faults and failures and that is open to suggestions to improve and criticism. Sorry for the rant.

Regarding a bug tracker I can't agree with all of that. bug trackers are invented to reduce the workload of managing the reports of bugs, classifying them, prioritizing them, keeping their status up to date, collecting relevant facts, for example where such issues might arise, and consolidating evidence and potential approaches to fixing them. Putting an effort into creating or setting up such an environment would actually reduce the workload of sifting through the forums, which are ill suited for the task, both for those people that look for bugs and those that fix them. It is far more work to do that in a forum, which is designed to share opinions and facts and which is not suited to search for bugs or keeping their status up to date. Many bugs on the forum are not labeled or labeled as reported or investigated when they are in fact fixed. Some bugs are regressions that were reintroduced but are then labeled as fixed already. It makes it hard for people to keep track of what's real and what's simply not been updated. Furthermore when looking at the bug report forum, it's obvious that the amount of threads can only really grow. There will be 10, 20, 50 pages of bug reports, and some will slip through the cracks simply because the bugs on pages 2-30 are fixed, but the bugs on page 31 are never seen ever again. In a bug tracker you simply filter out the stuff that has been fixed and you are left with a list of known bugs or alleged/unconfirmed bugs, drastically reducing the chances of a bug not being looked at. There is also no need for a "second tracker". One should be plenty enough. Any internal comments could stay internal, no one is asking you to share your source code or reveal how "personal conversations" on the bug tracker can even happen. I implemented a version control system for my company while another member of our team implemented a bug tracker. Took me a few days to set everything up for everyone and him a week or two before something reasonable was working well enough for use. It really just comes down to designing the database and a user interface and the queries that are done between the two. Regarding the frustrations of people The fact that people are frustrated and may think that nothing is done, that the team is incompetent, etc, points to a miscommunication. That is the whole problem I'm trying to address here. Of course other projects have some trolls on their forum, other projects have people discontent. But when I look at DCS specifically, it seems way worse. Personally I feel way more frustrated than with other projects I have posted bug reports for, both production software and games. Blaming people for posting is fair, but that doesn't mean you can just ignore their posts. They still need to be classified and disregarded, and for the right reasons. Take yourself for example. I asked that Air Fire and Arty datalink would be implemented. I read the TM, it outlines the procedure step by step, it shows drawings of what the MFD screens look like each step of the way. You come along and say "That's not how it works, it's a misconception", "Won't be implemented". Despite it being part of the aircraft IRL. I understand that it was never used because radio exists, but in DCS it would tie in nicely. No further information was given on why it was "a misconception". I'm fairly confident that the team uses the very same TM to model the aircraft (while simultaneously forbidding any mention of it on the forum). I understand that it won't be implemented tomorrow or next week, but it would be nice to have in 2 years. My understanding of a simulator is, if the real aircraft can do it, and if it's public knowledge on how it looks, what the procedures are and what the end result is, then the simulator should simulate it, even if the implementation details aren't known (the format of the data link packages, package sizes, frequencies, encryption schemes, etc). It also doesn't help that some bugs have been around for decades and that people have fixed them by changing a single number in a lua file, yet this is not officially done, thus breaking IC, for instance. I'm not sure if that is true, but it would point to some deeper problems with the whole process. Of course people form their opinions on lacking information because there is no information. When I see certain things, I can only assume how they came to be from what I am provided, and what I am provided is the multitude of problems and my own experience working on software projects, though of course much smaller in scale than DCS. For instance a Mig 29 locking somone up 45° off bore and you being 45° on the other side still gives you a spike despite being nowhere near the line of sight line, you being 300 miles away and sitting in an aircraft shelter. This has been around for many years now and still not addressed. How can this be? Especially since it's such an obvious issue. Put a single Mig29 in a mission and basically the whole server gets spiked. And that's not even one of those tiny little details, like a single obscure aircraft function not working correctly when certain, specific conditions are met, like the windshield wiper knob not being able to be turned to high without generator power, which was fixed. Another example is when I see the problems in synchronization in the apache between the seats. I conclude from the dozens of bugs that I observe and the way they happen and from experience, that synchronization works by sending which button is pressed and then separately keeping track of what should happen with the aircraft, and not by sharing the aircraft state. Initial synchronization of some states is done when the second person joins, creating the possibility to forget or mis-synchronize them (for example C AUX tank status, APU status, etc). If I had to come up with a system, I'd write the class for each aircraft system and then transmit that state when the other client asked for it, for example to display it on some interface in the aircraft. Instead it seems like cockpit button presses are synchronized instead. Since DCS uses UDP, some packages might get dropped and then you get one off bugs that can't be reproduced. For example just yesterday my CPG was setting up a route and suddenly the COM->MAN->VHF Tone got turned on for me, but not for him, some time earlier some FMC channels just turned off when my CPG was doing something completely unrelated. It's impossible to recreate, if I were to report this bug, it would be "can't reproduce, no track", never to be seen again and that's why I didn't bother. And when I point out that the whole approach is wrong, I get told "you don't have enough information to even know what the approach is", which is true, but on the other hand I can not get the information either. So either I ignore the problem or I must assume what the problem is through what evidence I'm given. Of course seeing stuff like this is frustrating. And I'm not the only one to feel that way.

I think most people here will eventually get both the Phantom and F-15E, but if they were to come out at once, what would I buy - a jet that requires me to actually pay attention and learn stuff or yet another MFD button-pusher? Hmm, maybe this will inform my decision...

I have to agree with FalcoGer. It is very frustrating to spend time and energy finding bugs and then find that they are not followed up and reported appropriately. Two examples: https://forum.dcs.world/topic/304743-eufd-warning-util-hyd-level-low-when-unlocking-tail-wheel-on-any-carrier/#comment-5059668 or https://forum.dcs.world/topic/306016-gun-shakes-on-movement-while-lasing/#comment-5054968 Unanswered for half a year. Not even a statement that the matter is under investigation or anything like that.... This is very frustrating for your customers who are trying to let you know that something is wrong. I would also like to see better communication and quality in bug reports. We're happy to help with more track files or videos or give you log files, but we need active feedback from you. And I would appreciate ED commenting on how they feel about it and what actions they will take. Introducing a bugtracker would be very helpful.

Yes the steam sale for individual modules is live now Thank you and enjoy

I have uploaded a few updates as follows (see first post for links to downloads): Tu-214R v1.2.0123: Fixed a bug preventing proper display of 64514 livery and aircraft configuration. O-2A Skymaster v1.1.0123 - bug fixes, added texture and model details, new livery, gunsight, SUU-11/A minigun pod, and more

If there is any wing sweep at all, the wing tip lights are replaced by the wing glove lights.

Airplane Simulation Company C-130J

With the new PBR materials added to the Viggen last month it was finally time for me to rework the camouflage pattern, the decals, and also adding and changing some of the external details of the aircraft. Made with a modified version of the new templates. The liveries can be downloaded: HERE Get them while they're in stock! (97/100) Liveries included: F15 wing (152. div.) - A plain aircraft with no additional decals F10 wing (101. div.) - Same as the one above, but with the addition of the ghost decal on the tail F21 wing (211. div.) - Same as the top one, but with discolored and worn out paint F21 wing (211. div. Akktu stakki) - Same as the F15 livery but with custom nose art - IRL it's a SF37 that is painted like this Enjoy! More:

I’ve just returned to DCS after a break of a few years, attracted by all the specialist cockpit kit now available, new models like the FA/18, the promise of a dynamic campaign coming soon and what was now possible with exciting kit like the Elgato Streamdeck. I have very limited desk space in my den and I wanted to construct some sort of Hornet cockpit that I could easily and quickly set up to play and stow when I was finished. After a lot of market research I settled on the various Winwing control panel offerings. Here’s my experience for what its worth, hopefully anybody considering buying the WinWing panels may find it informative. I started off by buying the Winwing Hornet UFC panel. It took just over a week to get from China to the UK and pleasingly I wasn’t charged any customs or tax. I was very pleasantly surprised by both the quality of the kit and it’s ease of set up. I ran the SimAppPro software from Winwing, downloaded and installed the Hornet config file and the UFC just worked perfectly (although I subsequently ran into some glitches - see below). The thing looks and works just like the UFC panel in the Hornet. Although it’s made from sturdy plastic and feels pretty solid it is actually very light which is perfect for me as I wanted a light weight pit setup. Based on that experience I ordered 3 MFD units from Winwing, both the button panels and the actual displays. Again it only took just over a week for it all to arrive but this time I was charged custom fees and tax. I found setting up these units more complicated but once up and running they worked great. Again lighter than I expected but the actual displays are very crisp and clear. There are quite a few extra buttons on the MFD frames you can program with anything you want. The MFDs are bigger than the Thrustmaster Cougar MFDs. Over all I think these panels, both the UFC and the full MFD displays, are good value for money and I would recommend them. There are however a few issues that would be buyers should be aware of. First all the panels come with attachable stands but these are pretty restrictive in that only two positions are possible, neither of which met my needs, and because the panels are so light if you try pushing the buttons with them sitting in the upright position they move and/or fall over. So they work best attached to something. I didn’t want to attach them to the desk as I wanted to be able to stow them away easily so I built a lightweight thin timber sheet panel box, with a slightly inclined front panel, onto which I attached the various Winwing panels. This means I can just lift the entire structure on and off my desk in one go. This leads to my first criticism which is that the back of all the panels have a small raised area, so if you want to attach them to a flat backing surface you have only a limited grip area and attaching them to a surface is a bit tricky. I did it with a combination of velcro on the raised area and a small wooden weight bearing rail for them to sit on on the tilted front surface. The Three MFDs and the UFC require seven USB sockets so I attached a powered USB hub at the back of my panel box and only need to plug in one USB cable and a power cable to get the whole thing working. All the panels come with nice long USB cables, over a metre in length, so I needed to use cable clips to stow away all the various cables neatly at the back of my panel box. However you cannot install the occasional firmware updates via a USB hub, so when the a firmware update becomes available I will need to pull each panel off the velcro to attach it directly via a USB cable to my PC. A bit of a pain. . The display panels for the MFDs need to be arranged in the Windows display setup in portrait mode underneath the main monitor. Unfortunately because I am regularly detaching the MFDs from my PC I found that Windows kept resetting the position and orientation of the three MFD displays meaning I had to rearrange them each time. I could not find a way to force Windows to remember the MFD display orientations but I found an easy solution in the app Displayfusion, which you can use to set the position of the displays properly then save it as a configuration that can be invoked though a key combination (which I have set up as a Streamdeck button). I still have a weird glitch where one of the MFD displays keeps showing the Windows task bar but I just set the Task Bar to autohide and that solves that. The final problem I had was caused by fact that I was the using the HUD only view a lot more because I don’t need to see the cockpit instruments most of the time as I have the hardware panels. However I found for some reason this view interrupts the instrument feed to the Winwing UFC panel so the instrument display would freeze and the unit would become unresponsive. Going back to the default cockpit view, with the UFC visible on the main screen, reestablishes the connection and solves this problem. To sum up. Very pleased with this Winwing kit, I’ve finally got a DSC cockpit that’s easy to move in and out of position and it makes flying a real pleasure. Here's a couple of photos. One shows the back of my instrument panel with all the cable management and the USB hub. The other shows the instrument panel in place and in use

Not sure if his mod will match your attempt at wit. His criticism is welcome and informative.

Thanks! You are most definitely correct. And I'm most aware of the trajectory issue. As you guessed, it's part of the current limitations. If I make the trajectory less shallow it won't be able to hit short range targets. But I continually try to find new ways to implement the weapons, and if I find a better way I will implement it straight away. Thanks for the suggestion, I'll put it on the list for now. The next release will be the BTR-4E.

First off, let me begin by saying that I am not a community manager, so I don't speak for them as individuals or for their department. However, their job is far beyond simply "looking at a few bug reports for a few aircraft." They monitor, moderate and manage the entire forum to ensure individuals are not abusing the rules, attacking each other, or posting slander, restricted information, or forbidden topics. On top of all of that on the forum, they also do the same for the other social media channels: Discord, Youtube, Facebook, and interact with the community in other ways like on Reddit. Of course, the community managers are not the only ones checking bug reports or interacting with the community. You also have ED internal testers that do the same, as well as other ED employees that do as well; to include translators, manual writers, and I'm sure some dev members. Admittedly, I'm still a newcomer so I'm not familiar with the forum screenames of all the ED team members, this is just from what I've observed. Switching gears, another thing that can be seen is that whenever a feature is announced for one product, the players that use other products that are subject to contemporary features often immediately demand to know when their favorite module is getting the same treatment. When it was mentioned the F-18's radar was being re-factored, the F-16 players wanted to know when the F-16 would get it, despite already announced it would be. When it was mentioned the F-16's DTC was in progress, the F-18 players wanted to know when the F-18 would get it, despite already announced they would be. Despite the fact that it was announced multiple times that each of these respective aircraft would get these features, everyone wants the features in their preferred aircraft first and as soon as possible above any others. Following that, if any newsletter does not talk about an upcoming feature for a specific module, there is often times the inevitable thread that starts where players assume the feature might have been cancelled, shelved, or delayed, even if a previous newsletter mentioned it as still being worked on. This starts a long cycle of debate back and forth until the community managers are forced to lock a thread and assure everyone that nothing has changed, there just isn't news to share. What does all of this have to do with how bug reports are managed? Well, nothing; at least in itself. The reason I am typing out this short novel is to articulate not only how busy the community managers are in trying to keep fires from starting or putting out existing fires across the various channels (some of which continuously progress in real-time, like Discord), but that communication itself between the community and the ED team members can be a significant challenge. To many players, they only see their little slice of the forums, whether it be their wishlist or bug report, or they only see what is (or isn't) happening for their favorite DCS module. But to the community managers and other ED employees, it is everything, all the time. What the vast majority of the player-base sees is only the tip of the iceberg of the amount of effort that it takes to manage the interactions with the community, or the development time that is being spent to produce such complex aircraft and environments. I myself am taking a good slice out of my workflow today to read this thread, consider the appropriate response, compose this message, and then proof-read it several times to ensure that it is a measured and appropriate response. I do this in a methodical way because, as an ED team member, I do not have the luxury of posting whatever I please whenever I want, or respond in a half-cocked manner. It is my responsibility to ensure that what I say is accurate, level-headed and not driven by an emotional response, and does not reveal or state anything that has not been approved for public consumption. Forum members are under no such obligations outside of the forum rules and guidelines. Regarding bug reports, they could post anything that could be caused by interference from user-mods, hardware input issues, user error, a misconception to how something should work, or any number of reasons why something "doesn't seem right". If it seems like some bug reports are missed, some in fact are. Some get missed, some get overlooked, some sound very similar to the one that was looked at last week, etc. We are human, with much more work tasked to us each work day than many realize. Many of us work more hours than we are required, to include the weekends. We do this because, like you, we are passionate about DCS World and we want it to not just succeed and grow, but we want it to be fun as well. Unfortunately, quite often the absolute worst case is assumed; that ED team members or our 3rd party dev team partners are lazy, evasive, incompetent, don't know what we are doing, only care about sales, don't respect the community, blame players for issues, don't like to communicate with the community, ignore bugs because we don't want to fix them, etc. When these statements are repeated endlessly on the forum and other channels, even though it is borne of false hyperbole, kneejerk reactions to announcements, or community members with an ax to grind, this is not just disheartening to ED team members, it also creates discontent among the community itself and makes it very difficult to consider how we should communicate in the future. Everything we do is met with both positive and negative reactions, but more often than not the negative reactions are the loudest and most promulgated statements on these community channels. Even when information is provided in a very honest and facts-based manner, it may still be met with a negative reaction or blowback from other players. This could be because they do not get the answer they expected, there may be a cultural or language difference, or because they don't like it because they don't like it. Again, we are all human, and I'm pretty sure we all want the same thing, which is to have a fun and engaging form of entertainment that caters to our fascination of high-performance aircraft and their place in history. But please keep in mind, to use an analogy a second time, only the very tip of the iceberg is seen. I cannot stop anyone from basing their opinions on limited knowledge of what is happening behind the scenes, but we purposely avoid posting information that we do not know to be accurate, that does not reflect a known solution to an issue or bug, or is not a future development plan that is both set in stone and already publicly announced. We are not always perfect at this, but if a change occurs, we always let the community know; even when it may result in backlash. Honesty is important, but is only useful if it is based in facts, not speculation or assumption. But speaking honesty based on fact is a two-way street, just as respect is a two-way street. Bug-reporting standards are there to ensure efficiency in handling of such reports, it is not there to serve as a "gateway" criteria before a bug is considered, nor does it serve as a "guarantee" that a bug can be reproduced, reported, or fixed. If a bug report is provided with a simple paragraph with no track file but still marked as "reported", this does not constitute a break in the bug-reporting standards. It may have been seen by a member of the volunteer closed beta testers or another ED team member, and is already known and reported. If a bug report is still marked as "investigating" for months, the bug may have simply been moved to a back burner due to higher priorities. Yes, I can see how this might support the idea of a public bug tracker, but as already mentioned in the above paragraphs, or in the post below, the manpower requirements in maintaining this would be astronomically high, much more than many realize. It is very easy to cast stones when, due to lack of information, there is nothing to contradict or refute personal biases or assumptions. If a player sees a lack of communication as disrespect, neglect, or lack of appreciation for their bug-reporting efforts, that is certainly not our intent nor is that what is happening. We cannot, and will not, simply mark every single public bug report with a blanket cookie-cutter tag to make it look like every bug report has been utilized in the development of DCS products, but we also have no control over what any player tells themselves or the community to fill a vacuum of information.

You have entered the code for the launcher, but it is not active, so the AGM-88 does not see anything. The code for "SD" Snow drift SR is 107, not 115.

Yes, of course. Currently, R-3S in the development in the DCS core.

Ridiculous thread title. HB gave an update on the 12th around this. From

Prccowboy, what do you think about this? I think these two could be a great addition to the DCS world) 1) RQ-4A Global Hawk (USAF) 2) RQ-4D Phoenix (NATO) Specifically UAVs with registrations below are regularly seen near borders of Ukraine and in the Black Sea nowadays according to open resources.

The updated F4 is out!

Corrected the jg 301 group marker. added jg2 tailband template but will have to slim it down cause uvw´s.. enlarged the swastika Also some more dirt blockout.

I will welcome the opportunity to learn to navigate and combat simulate in an analog jet. Analog Combat Simulator.. lol.

Updated 3/22/23 Makes canopy glass clear. Should apply to all modules but only tested on A10C-II, Hornet, A4E-C, Black Shark 3, and Viper. Adjustments: Last value of line 101 adjusts opacity. Default is 1 and 0 will be completely clear. Mod is preset to 0.2. Shadow on the glass is removed by default for better frame rate. If you want to restore the shadow, remove the comments (//) at beginning of line 88 and 89. Notes: This mod may also affect MFD and HUD glass if the module uses same material. Does not pass IC as of DCS 2.8.5 on 5/18/23 Install: Extract to DCS Main install path or use Mod manager. DOWNLOAD

Users have posted on Discord and Facebook about this issue, so I am sharing a fix for it here. If you have any questions please ask. The updated lua file includes safe-guards to protect against using null objects when the player's aircraft crashes. Here is a file-diff of the added checks if anyone is curious. Although this is a simple 1 line change, Winwing has not resolved the issue for some time now. Myself and others have filed bug tickets but no fix as been put out by Winwing and often the response is along the lines of "repair your lua file or re-install SimApp Pro". Both of which are not the solution . I hope users find this fix helpful. Only applies to those who play on multiplayer servers Steps to fix: Download the the fixed wwtExport.lua file. Replace the existing file in `<USER>/Saved Games/<DCS_INSTALL>/Scripts/wwt/wwtExport.lua` Note: SimApp Pro may override this file until Winwing updates SimApp Pro. requring you to re-add the updated file. Play online and die/re-slot without losing in-game sync data such as light/vibration. Steps to reproduce issue: Use a Winwing device such as take-off panel, combat panel, F16 Ex Stick, or anything that uses in-game data to match state. Load into a multiplayer server Ensure Winwing device matches plane state (AA/AG lights, Landing gear, stick vibration, etc). Crash the airplane Re-slot in same or different plane type slot Notice AA/AG lights do not work, landing gear light does not flash, no stick vibration, no light sync. Pull up the logs located at: `<USER>/Saved Games/<DCS_INSTALL>/Logs/dcs.log` and notice the error message This is due to an accessing an object that is null, the fix above includes a working lua file to avoid this. 2023-01-24 18:07:26.835 ERROR Lua::Config (Main): Call error LuaExportActivityNextEvent:[string "C:\Users\Preston\Saved Games\DCS.openbeta\Scripts/wwt/wwtExport.lua"]:164: bad argument #1 to 'type' (value expected) stack traceback: [C]: ? [C]: in function 'type' [string "C:\Users\Preston\Saved Games\DCS.openbeta\Scripts/wwt/wwtExport.lua"]:164: in function 'sendNet' [string "C:\Users\Preston\Saved Games\DCS.openbeta\Scripts/wwt/wwtExport.lua"]:217: in function 'LuaExportActivityNextEvent' [string "C:\Users\Preston\Saved Games\DCS.openbeta\Scripts/wwt/wwtExport.lua"]:255: in function <[string "C:\Users\Preston\Saved Games\DCS.openbeta\Scripts/wwt/wwtExport.lua"]:254>.

Old CH-47D version please

Hello, Want to share one of my projects: 3D printing cyclic for DCS AH-64D. I have design based on pictures a 3D model which can be print, assemble and wire with simple commercial components. The model is available here: https://www.cgtrader.com/3d-print-models/hobby-diy/other/ah-64d-apache-cyclic-3d-printing-model-with-electric-componenets

So I am going to jump in the front seat for Raptor as his gunner, I am sure we will be shot down in a ball of flames in no time Bug Tracking A long time ago Kate mentioned the idea of a public track, we looked at it, we examined it and we decided against it. When she first talked about it I thought, well that could be a good thing. No more bug reports on the forum, all of them entered into the bug track directly... Then I look at the forum, and for every good report there are two incomplete reports. The devs are even more critical about how a bug is reported than we are. Me, Scott, Raptor and others take a lot of reports and make the work for the dev team. Then I thought, well ok, we still report them, but users can see them. Well no, some bugs are deemed lo priority, some take longer to fix, some take discussion before being addressed some take research to be done. Would that help or hurt to see all the communication. Some would love it, some would hate it. Well then, maybe they just see the bug reported and status... Well sure, that works for bugs that are fixed right away, for other, well... its just another thing to be frustrated about when it sits there for a long period of time without action. Well what does that leave us. The forums. So we try and do better and mark things fixed when they get fixed. Internally we are marking things as user reports and a link to the thread in hopes to help this, but its still far from perfect. We are trying. A tracker just doesn't make sense for us right now, we do not have the manpower to support it, we it would just be another source of aggravation for those waiting for a fix important to them. Maybe one day it will make more sense or we will be staffed to be able to support it, right now no. The forums makes the most sense, and me and the team doing a better job to update posts as well. Not an answer most will want or accept, but it is the answer now. Opinions aside, that is how it will be for now. People Frustrations I would love one day to come on the forums or Discord or wherever and have 0 people frustrated. As you pointed out, other games have the same issues, or similar. I do not agree that DCS World is worse, maybe you do not see us as better, but I do not see us as worse, for whatever that is worth. As far as ignoring posts, we really do not go out of our way to ignore posts. We may triage the bug forums trying to tackle the most critical and important that we feel need addressed right away, and because of this some may slip through the cracks. We do not ignore reports though even if it takes us time to get back to them we generally try and get back to them. If people make reports missing info, incomplete reports, etc, those might be skipped over with a simple missing info tag and reply. I randomly picked one of yours and I can see how you might be frustrated: Playing devils advocate had you included a track with your initial report it might not have slipped through the cracks as it seemingly has now. This is not an excuse for us to have not gotten back to it, but I want to show you that making a proper report can get things looked at faster. As a side note about a bug tracker that users were involved in, this could be the same issue there. So in conclusion, yes we can do better relating information back to the forums about fixes and the status of bugs. You also have to consider the size of the task, and how you may be focused on a handful of bugs, we are juggling hundreds each personally, and then the Devs and management are making a plan based on that. If you think DCS is worse than other games, its the sheer complexity of the game that probably makes these seemingly simple tasks seem so slow and unresponsive.

Binary thinking fails again. Windage AFFECTS dropping bombs, straffing, landing, hovering, canyon flying low level... basically EVERYTHING IN DCS.

No need for sarcasm, Urbi's criticizes specific aspects of this Mod in a polite way and focusing on the Mod and not its author. His views are valuable to many of us, as he has shared a lot of his own work here ( https://www.digitalcombatsimulator.com/en/files/filter/sort-is-date_desc/user-is-urbi/apply/ ) and has collaborated on many aircraft Mods, like the Civil Aircraft Mod .. ... So, he is not airing empty criticism like many others do. Hopefully the Mod's author will strive to improve the Mod and reduce its shortcomings.

A 1950s Korean map would have to be the priority. I just think the later eras would be nice to have, as the Koreas have had quite a few border clashes that could have turned into a war since 1953. I know it won't be as easy as the Marianas so it would make sense to sell them as seperate maps which get loaded based on the date. This is the reason I am constantly screaming about the lack of Red Army and air force assets in the World War II asset pack. Right now all we can really do is shoot down MiG-15s and strafe lend lease vehicles that happened. I could see a Cuba goes hot scenario, but we would need the Soviet Navy

The HIMARs are an incredible asset to introduce into the game, it seriously helps this game's environment feel more modern. I have notices the GMLRS has a low trajectory, impacting the target at a very shallow angle. It often gets blocked by large buildings or trees. I understand the variety of limitations placed on modders by the DCS framework, but is this something that can be adjusted?

I will look into it, thanks

I already think the Ka-50 is so beautiful. I would love the Ka-52, but that's not going to happen.

@BIGNEWY This one seems to be incorrectly marked as "correct as is". While it's no big deal (just like the OP states), the pilot saying the true bearing instead of magnetic is most certainly a bug (albeit a low prio one), and not "correct as is".

just a suggestion. try the same mission on your PC as an MP instance. there are a few different reasons the performance issues can show up. self GPU/CPU/RAM. which is not the case given your test. the amount of players on an MP server. loading as an MP server on your PC. can test this. or plain lag. this can also be tested.

i havent tried it yet, but the software i was looking to use to add some midi devices to my rig is midi2vjoy: https://github.com/c0redumb/midi2vjoy if you search forums for it you'll find some other threads like would also recommend joystick gremlin for general control customization, but it won't pick up midi devices. if midi2vjoy works and sends commands to vjoy, could likely use gremlin to customize the vjoy inputs from the midi device (axis curves, macros, etc): http://whitemagic.github.io/JoystickGremlin/

X Plane can use live weahter (I think MSFS can too) so I don't think the wind interacting with terrain is fixed, but dynamic like the rest of weather. I should also clarify that when I said the other sims model "this", I was referring to wind over terrain, not the grid method I was suggesting. The grid method would make sense to precompute currently since DCS doesn't have varying weather.

I've got nothing left to purchase, so that Eagle better come around soon. [emoji6] Sent from my MAR-LX1A using Tapatalk

The ETO DCS has been crammed into this late late war corner. With late 44 planes, but no correct map, mission assets etc. I hope that PTO DCS will be more rounded. With the Hellcat coming too we can do 43 era fights if we get the correct map comes a long. I think Solomons would be ideal. It works for Corsair and Hellcat. And the Wildcat if we ever get it. Aswel as P40, P39 and P38 I'd those planes ever come along. The Solomon (and surrounding area) saw fighting from Mid 42 to 44.

I just feel like the puristic people are the louder crowd on the forums. There will always be 2 factions, 2 squadrons, 2 wings, 2 villages, next to each other... The checkbox option on the Viper showed perfectly that mission builders can be in control whether MilSim or Casual missions are wanted. The crying was big back then, but now it really seems like everybody is happy, so for me it does seem like a very good solution. On one hand I can fully understand that it takes time to program stuff out of scope, and it will always be up to the developer to decide. But something can be "the most realistic simulation of ... something" and give nice game play options for people with different taste at the same time, I believe in that. I like Milsim game play as well, I just also like to do it in RAF role, or GAF role, or JASDF role, etc. IRL, at least in European air forces, it happen several times that equipment was used that wasn't supposed to be used in the first place -> called "Einsatzsofortbeschaffung". Would translate to something like "immediate war time integration". What I am not happy with is: hardcore people trying to teach non hardcore people what fun is. And I don't have the impression that it is the other way round. Loadout checkbox, not using it, restriction by mission date, there are already good solutions to solve this an make both factions happy. It just feels like loosing for the hardcore village for some reason.

Your ego is writing (virtual) cheques your (virtual) body can't cash!

Cause he made it up five seconds ago based on the reports of an extensive sample of the community consisting of him/herself and one or two friends from WWII sims. That aside, wasn't there somebody making a Hawker Hunter around here somewhere? I know there's a couple of early planes (MiG-17, G91, F-100) in the works, I thought the Hunter was, too, but I don't remember who had it.

RIP, old friend.

Oh it big alright. Big Large McHuge in fact.

If you accelerate time - be prepared for a corrupted track file as well. My rule of thumb is to make a backup (master) copy of any track file I want to use and never touch that one. If a track file becomes corrupt, I can then copy that back to the track directory to 'fix' the corruption. I would almost be willing to be a decent amount of money that a 2hr track file is going to be corrupt 'some how' before you get to 1:42:00 in using anything but zero acceleration. I hear some people can get away with up to 4x accelerate - but in my experience running with no acceleration yields best results (and still doesn't guarantee it's going to work correctly).

Please Show me where HB, RB, and Leatherneck mixed and matched Lots of vastly different blocks.... Into one module, and I dont mean "we'll leave this missile in the loadout for time period sake", I mean "we are gonna use half the systems from an early block then add systems from the later block at the same time for module balancing". F-14A, was the equivalent of a fleet bird, not mix-matched lots/block, there's literally 32 Blocks of the F-14A (1-12 were test aircraft), and most of them were modified by Sqns when delivered and never stayed Factory Set. F-14B, same concept, fleet bird, entirely different aircraft from the F-14A, But enough common elements to make developing 2 aircraft in one module cost effective. there's 3 blocks of the F-14B, the only difference between the 3 is which ones were new, which ones were upgraded from A, and which ones had the upgraded ECM Radios. Most Earlier Block F-14A/Bs were upgraded w/ the new ECM to match the Late Block B, the only difference being the engines and the gun vent. F-14D, entirely different from A/B, as everything has been converted from analog to digital. there's 3 blocks of the F-14D, again, denoting new, or rebuilt, as well as the last block . As for Lot 29 Front and Lot 24 Rear, have you not been paying attention. Lot 29 is HOL, Lot 24 is SCS, two ENTIRELY DIFFERENT PROGRAMMING LANGUAGES and Processors. Lot 29 also consists of several base components that are classified, AESA for one. without that, you dont have anything else.

Yes, press “F” for collective clutch. I have seen this bug but didn’t figure it out until now!

Everyone is entitled to their own opinion, so please keep it civil. Having said that, the AH-64D's FCR is like an optional external sensor pod. Removing it is simply removing a sensor option, nothing more. It would be like saying the F-16C is only iconic because of its HTS pod, and removing it somehow detracts from the aircraft in other ways aside from removing a sensor. I think that for many fans and advocates of the AH-64, its performance in Desert Storm prior to the FCR even existing, as well as its use in several conflicts in the past 20 years (such as Iraq, Afghanistan and Syria, 98% of which was without FCR's), is what has made this aircraft iconic and legendary in its own right.

Swedish Skin inbound !

Dear all, Merry Christmas and all the best for 2023! As the team prepares for some well-earned time off, here is where we are with the Hornet: Highest priority is on bug fixing. This includes, but it not limited to issues with the Harpoon, SLAM, and SLAM-ER behaviors, ASE dot behavior, etc. We are performing a ground up review of and refactoring of the Hornet flight model and flight control system. This also includes a large update to the landing gear model. New and improved pilot model. Once this is complete, we’ll do the same for the Viper. Refactoring the radar for more accurate performance. Once this is complete, we’ll do the same for the Viper. We’ve updated the ALR-67 to include new functions and symbols. Following the next Open Beta, tasks include: IAM loft cues. New bomb fuzes like DSU-33 and JPF. MUMI page and DTC. This will follow the Viper DTE page and DTC. A review of MSI functions based on available data for the version we are modeling. Please note that the above are just the highlights is certainly not 100% inclusive of all planned work. Kind regards, Wags