Jarmak

This has not been true for a long time now. The purpose of a system is what it does, and the open beta branch has not served as a beta test release in as long as I can remember. It doesn't matter what you call it, if you focus all your marketing and promotion on the open beta as if it is the main product, and go so far as recommend it over your stable version to the multiplayer community, it is your main branch. It has long felt to me like the actual distinction has been one of consumers who are eager for new features vs commercial/institutional customers who require a much higher service level guarantee. This is the cause of much of the frustration when "it's open beta" is given as an excuse for truly game-breaking bugs; you can't push people to open beta and then scold them when they're upset it doesn't work. That said, I don't want to drag ED when they're in the middle of making a good decision. This is a very welcome development and I'm glad to hear it.

First off, I want to be very clear that I understand this plane is in early access, early early access at that, and if I thought for a second this was a matter of waiting for things to be finished I wouldn't make this post. But, these exact issues still haunt the harrier module years after leaving early access, and the nature and consistency of issues point to a failure of management process, design choices, and/or priority rather than a specific technical issue or bug that needs to be squashed. The handling of discreet controls is sub-standard for a module released in 2023. Why are we missing discreet binds? Why are what there are for discreet binds not in their relevant control sections, but instead all thrown haphazardly in a "abstract for joystick" section? Why are rotary axis inverted and only use half their throw as if they were the user-made custom binds instead of properly coded? Why are some many of them broken? Why does it require arcane knowledge to get the idle/stop detent to function properly with a joystick that has them when this has been a standard feature of any module that has them since at least the hornet, and technically even the OG A10 did it if you were rocking the TM Warthog throttle? The entire approach, including even how the control binds menu is organized, just screams management that doesn't realize expectations have changed in this regard since the Huey and original A10 were the marquee DCS modules. This was arguably a failing of the AV8 in 2017; six years later after so many modules have done this so well it just looks sloppy. It feels like the core binds were made to not include physical rotary axis, most multi-position switches made to be toggles bound to push buttons, and then some intern was given the task of cobbling together enough extra discreet and axis binds using clickabledata.lua to make the people with fancy joysticks happy. Contrast this with any Heatblur or mainline ED module released from the F18 onward (2018). With seemingly few exceptions controls binds seems to be made 1:1 with aircraft controls and switch states first, and then abstractions such as cycling toggles or if/else binds added to add accessibility. This is not an issue that will be fixed by collecting bug reports and patching things to minimally workable. This is a structural issue that won't be corrected until RAZBAM realizes that the interface between their simulated systems and the user's physical controls is tantamount to the user experience, and decides to devote some resources to it like it's a proper priority instead of using the same approach that was arguably already outdated in 2017. It doesn't matter how much your pour into in-depth authentic simulation of systems if the people who care about that most are stuck on the other side of an archaic control layer that feels like we're back trying to hack HOTAS controls into Tie Fighter. It's not about bugs or technical issues, those are expected with EA and the positive examples I mentioned all had them--god knows the hornet had nagging controls bugs for years--this is about repeating poor, outdated design choices that are out of place in a full-price marquee module in 2023. Honestly, it feels like RAZBAM still thinks the size of the userbase with switchboxes/panels is still so niche that it's not worth spending more than the absolute minimum amount of resources on us.

I'll try the more permanent install option. I thought setting the wwt folder to read-only would prevent it from getting overwritten by simapppro

I keep having an issue where this works the first time I copy the wwt folder and boot dcs, but then never again afterwards. Looking at the log it shows the script start up (in my case the harrier) and then shortly thereafter says "export stopped" for no discernable reason. Any ideas what could cause that?

After doing a fresh install of DCS I cannot get export scripts to run at all. I've done a fresh install of the DCS-ExportScript folder twice, I've tried commenting out everything else I have in export.lua, I've confirmed I have the module in the ExportModules folder, and still nothing. I'm not seeing an export.log file even being generated. I'm a little bit at a loss where to even go from here, does anyone have any ideas? edit: disregard, it's working now, I'm a little confused because I opened export.lua in notepad instead of code and the ExportScript line was duplicated where it wasn't in code. I fixed/saved it in notepad and forced code to revert to the saved version and now everything works.

Be warned, they do not appear to actually honor preorders. They just released stock for new sales and didn't fill my preorder. One of my friends put a brand new stocked order in Sunday night that is already processing for shipment for material I have an unfilled preorder for. When I contacted customer service to ask why material was released for new sales without filing existing back orders they just sent me a generic message about being eager for my stuff.

As someone who actually does project management as a job IRL you don't have a public test build, you have a primary public release that you are releasing as WIP, and a backup stable build that your community barely touches. There are a wide variety of methods used by software firms to keep their open betas and test builds from becoming the primary version their customer's are using, in order to avoid this very issue. ED does pretty much exactly the opposite of that and spends all of it's marketing promoting the open beta releases while barely mentioning the stable version. As an extremely predictable result the primary product your customer base is consuming is the open beta, and that customer base is going to have some expectations of a base level of functionality. And honestly, it really doesn't matter what you think about it, what you label things, or how much you argue about it. Your customers have developed expectations as the very predictable result of decisions you've made in how you position the product, and they're going to be upset if you don't meet them. Telling them they're not allowed to be upset is just going to make them more upset; this is marketing 101 stuff. Positioning it as a WIP/Open Beta buys you a lot of leeway to have glitches or temporary downtime in functionality, but tapping the open beta sign at your power users when they're upset it's just straight not working for them anymore is not going to get you anywhere productive.

So I'm guessing the whole the purpose of a system is what it does bit went right over your head. ED focuses it's marketing and community building on the open beta, it doesn't matter if they labeled it "super experimental don't ever try this unless you're ready to suffer" it is the version the entire community is based around. You don't hype up the beta branch and focus all your outreach efforts on it then try to hide behind it's a beta, give me a break. You can't functionally play multiplayer without being on open beta.

Go back to stable is dumb, that's not what the multiplayer community is built on, that's not the community ED has fostered. A system's purpose is what it does, and labeling it open beta does not change the fact the community they have built runs the open beta as the de facto standard and expects a bare level of basic operability out of it.

Having similar issues in the Apache, the CMWS in particular seems to be causing me massive CPU frametime issues. Sitting in parking in and flipping it on and off causes my CPU frame time to nearly double while it's on. Goes bad as soon as the bit test finishes, goes away the second I switch it off.

No you're not missing anything, those two pages are showing contradictory information. It is impossible that this is correct as is, both pages can't both be correct when they contradict each other.

This is incorrect, the Y scale on the AZ/EL is given as an upper and lower angle, not altitude. The distance to target does not change the scan volume as given by an angular measurement. To give a little more explanation, what changes with distance on the AZ/EL page is the linear distance the bounds of the box represent.

Helps a bunch! Thanks!

Any chance you could provide dimensions for mounting? For example if it mounts to a pit with machine screws from the front what size screws and how are the mounting holes laid out?

Finally put this together and now winwing is releasing one that goes with the throttle. :(