I feel they are missing an opportunity to work with the dedicated fans who build the modding scene and incorporate well-designed, highly embraced mods into the game with reference to the modder in the credits as a tribute.
The modding scene, I believe is one of the main reasons KSP has survived as long as it did as each mod provides more replayability and overall enjoyability. The game menu screen hyperlinks to the forums when it should just be working with CKAN to integrate modding seamlessly; everything you suggested has been conceptualized and worked on by a dedicated fan of the game who decided to spend hours learning KSP's API (which looks designed as an afterthought than an actual API, the docs will prove this).
I hope they upgrade the Unity3d engine to a version with .netframework 4.0 support so developers can create mods with a surplus of functions and robust features and optimization possibilities that we have been missing out on, currently, KSP is running on .netframework 3.5 which is limiting working being done by the guys at
The mod is great, the guys working on it are actively pumping out fixes and things like Weapons mods kinda work-ish..... But the point is that the game could be so much better if the mods were handled better, we have a mod called ModManager that helps mods, mod... I hope people see the redundancy and inefficiency this current experience provides rather than what the game could be if the modding scene was more widely embraced with.
People have stated in this thread that memory utilization and optimization issues persist in the game; which is a contributing factor to why the next update should have .netframework4 https://blogs.msdn.microsoft.com/pfxteam/2008/10/10/parallel-programming-and-the-net-framework-4-0/
Task Parallel Library alone would improve multicore performances on machines, considering KSP is running on a CPU based game engine I would imagine the additional support for parallelism, the Managed Extensibility Framework for further mod compatibility and stability (less crashes and faster startup times). This is without even mentioning Managed Profile Guided Optimization.
Not only that but the asynchronous modules and handlers that 4.0+ provides would provide a smoother multiplayer experience, which I'd personally enjoy so I have a little stake in having everything updated. And Dual-mode socket support.
Back to the quote:
" like reasons to explore the planets' surfaces, more planets"
"realistic aero physics"
"another star system"
"Reasons to boldly go"
"discover like another civilization"
It's silly to think we have all these great tools, yet heavily un-utilized in the grand process.
"And there are plenty of mods to give me those features now. " Console release had an array of missing features and stability issues that while modding, in general, would not solve. But simply providing console version with the tools needed to run using everything provided by Microsoft hardware, which certainly would have been compatible with net framework 4 for that multicore support, the experience would have been an improvement to the one we received.
This also highlights the replayability factor modding provides a game.
Maybe they will allow us to script our own missions? That would be a nice compromise to having the same mission constantly and providing a replayable game.
I think this quote highlights the limitations of a small dev team, attempting to work on a project that is quickly becoming cumbersome and falling into a trap where the game development is being interjected by Bug Fixing and catchup patchwork, which is highly speculative with only bases on the weekly posts provided by the staff team and the updates provided by SteamDB which can monitor the changes in depots (scratchpad_3 started getting updates before Christmas and has not really stopped since the holiday): https://steamdb.info/app/220200/history/
They are updating the QA builds as they said, they certainly are not lying, but there is no way to find out for sure how active development is at the studio as the depot is obviously passworded and therefore hashed to the public:
They could just be actively updating textures, we don't know unless someone at the team blogs about it... More transparency would be grand.
If the posts provided by the staff contained insight into the actual sprint timetable they are working on or provide an active bugtracker which allows the ability for those who have dedicated time providing mods and support for this game to maybe contribute and provide help with the core mechanics that the team are having issues implementing or design on, which the team feels the need to keep hidden and provide illusive timetables at the expected time. I understand why the team do not want to state on the record a fixed date, but I feel its unfair for the community to be expected to feel excited about this: https://imgur.com/a/gWp4b
when the team could have easily messaged @linuxgurugamer and @DMagic for an agreement to add these to the update:
Those EVA suit textures need time to test...
At least the team confirmed that the kerbals will have new heads
Also spending time modeling new sizes of models instead of working with @starwaster or even just take notes from his code to scale up the number of objects in the game without the need to spend time on each size of the model.
I believe these criticizations of our beloved game is fair as I don't want to see the game fail at becoming something spectacular.