Fewer errors

[Actium]

6 hours ago, BIGNEWY said:

Overall I feel its positive feedback we are getting, but we will always listen to the negative feedback, it gives us insight and often gives us new ideas to work on.

Let me chime in with both. After a decade of playing (and scripting) ArmA followed by a 5 year milsim hiatus, I've jumped on the DCS train 2 years ago. Generally, I've had a pleasant experience playing the game (after upgrading to 64G of RAM to keep DCS from crashing). I didn't even know DCS is what I've always wanted, until I started playing it after getting sucked in by the Grim Reapers Youtube channel. Right now, nothing else compares to DCS, so until a superior alternative pops up – if ever, DCS will always be the benchmark for a good military aviation milsim experience.

While I don't have DCS street cred, I'm a software engineer by trade and I do have 20+ years of coding experience (concurrent, multi-threaded C/C++ systems programming). Eventually, I couldn't resist DCS Lua scripting. At that point, however, my DCS experience changed drastically, as my perspective shifted from mere entertainment seeking to software engineering:

1. The documentation – or better the lack thereof – is frankly embarrassing. Compared to ArmA – which I also cursed at times – and its comprehensive, official scripting docs, DCS is basically undocumented. That's an absolute no go for a product that depends largely on community content creation.
2. The DCS scripting API with its plethora of different, undocumented Lua states and another separate a_do_script() environment is terribly convoluted and thus unnecessarily complicated to work with, obviously exacerbated by the lack of documentation. I implemented a browser-based Lua console as a learning project just to figure out how everything works. What makes matters worse, is the need to maintain this improper API to avoid breaking API compatibility and a lot of community content along with it, as the recent net.dostring_in() change illustrated. Such incisive, breaking API changes should not be released without prior discussion with community developers and advance warning.
3. The scripting API is unnecessarily buggy, up to SEGFAULTS, due to an apparent lack of even basic testing [1, 2, 3, 4, 5]. Modern coding practices, even rudimentary unit tests, and the use of appropriate tools like AddressSanitizer (possibly combined with a bit of fuzzing) should prevent introducing and releasing with such bugs. Although adhering to such practices may sound like overhead, it'll pay for itself multiple times over by obviating a lot of time otherwise wasted by inefficiently debugging code weeks/months after having modified it.
4. The scripting API lacks very basic functions, e.g. Unit.setLife(), with ED hesitant to add it [1, 2, 3]. With the presumably dire state of the scripting system, I do however understand the reluctance to change anything.
5. There seems to be a lack of understanding for the needs of community developers. According to %DCS_INSTALL_DIR%/API/Sim_ControlAPI.html the net.dostring_in() function is entirely obsolete:

   Quote

   **NOTE:** There's no need for net.dostring_in anymore.
   You can return values from a_do_script() mission scripting API directly:

   This is grossly wrong. Many missions, mods, admin scripts, Olympus, etc. would seize to work without that very function.

6. The mission scripting engine is still vulnerable to arbitrary code execution via malicious mission files, despite a (temporary) mitigation being available. This matter deserves urgent attention.

7. All Lua scripting appears to run in the main loop without runtime constraints, allowing a single script with an infinite loop to freeze a client/server. That's an obvious performance issue. The first ArmA already had scheduled script execution.

8. The DCS core presumably relies on a global, locking, all-comprising, single-threaded event loop. Adding a (few) thousand units on the far side of the map (or planet), i.e., far outside of the visibility range, will slow the renderer to a crawl. Rendering is apparently not decoupled from the simulation (i.e., AI, pathfinding, logic, flight models, etc.), although it could and should be for obvious performance reasons. This is most likely owed to DCS' single-threaded legacy. I presume a lot of engineering effort will be required to fix this.

9. The elusive brown crater texture bug and the on-again, off-again multiplayer scoreboard issue, and more importantly the time it took to fix either of them, point towards the DCS core being non-trivial to maintain.

10. All of these issues indicate that there's a lot of technical debt within the DCS core.

Eventually, dealing with the bugs and issues caused by such technical debt will crush feature development. I agree with the previous posters that argue for better prioritization of core development time. More time should be allotted to improving the DCS core, including the scripting system and its documentation. Obviously, a full feature moratorium on the DCS core would be too much, as that would interfere with its business model. If strictly required for module releases, features need to be added.
However, IMHO, too much development time may have been spent on not strictly necessary features in the past, e.g., the aircraft radio integration of the voice chat system (everyone still uses SRS), the currently incomplete mission state save feature, the botched C-ares integration, and the recent net.dostring_in() mishap to name what's at the top of my head. 

I love DCS and I'm confident ED can turn the ship around. Take the necessary time to stabilize the DCS core (incl. documentation, pwees!) and postpone not strictly necessary feature work for the time being. I'm hopeful the community will understand. Ask the community for feedback early on before deciding on breaking changes (I feel like the scripting system will eventually need a complete, breaking overhaul). A publicly accessible bug tracker may be another improvement. Using the forum to file bug reports may be susceptible to oversight of straightforward bug reports [1].

[MiG21bisFishbedL]

5 hours ago, Actium said:

 

I love DCS and I'm confident ED can turn the ship around. Take the necessary time to stabilize the DCS core (incl. documentation, pwees!) and postpone not strictly necessary feature work for the time being. I'm hopeful the community will understand. 

Overall, great post. ED has righted itself in the past, it just takes agonizingly long for them to realize their errors in judgement. No one is going to deny the huge leaps that DCS has made, but wow there's a lot of unaddressed issues and certain minor issues take a mysteriously long time to address. It HAS gotten pretty damn frustrating, though. 

It's to the point I think the MiG-29A is my last first party purchase for a while. I really want the Hellcat, but looking at the issues that have stayed unaddressed in even their darlings like the F-16? For years? 

Yeah, less confidence in purchasing until someone realizes the project managers have the absolutely wrong priorities.