TriggerAu

The teams gone to town in polishing off the Δv bits for the simulation and display so that's all possible - is why there was the indication last time of giving it some time before modders should hook into that feature. In short you can "adjust" (all right disable) the Simulation and App, there are more hooks to control the simulation and performance, and the UI components all (we think) have overrides in the right spots so the components of the display can be reused by mods as well Hey I ressemble that remark! That cleanup was a great effort all round and helped to focus some important bugs to the top of the pile yeah. It was massively appreciated. Hopefully the reminder of the voting system helps more people to share what they care about to bring things to the top again.

Thanks @taniwha

And I responded, the process gives everyone more time to finish, find and fix things. Please hold the head shaking for a couple of releases and see how we go

Glad your liking em, the art guys will be glad to hear it Unfortunately for your question though thats one of those question that I can neither confirm nor deny - I wish I could, sorry

The Zip file on the store is now updated with the OmegaDeprecated folder removed

On the Store Zip file the ΩDeprecated folder should not be there and is causing some issues If you delete just that folder then things should come good as a workaround - we are working on a new zip as I type

roger, looking

Ones where it was a direct replacement have the same part names yes

The previous mk1Pod is still there in GameData, you could unhide it if you want to return to it, we also stored a number of the deprecated parts in GameData/Squad/zDeprecated for those interested

I think I kinda sorta answered that in one of the previous ones. Its aimed at improving a number of things to give people more time (which includes testers). I know I've had fun trying to do stuff in mods (hacky or not), but its always been good to be able to reach out to a dev to look at/ask questions - its one of the great things in our community for a long while

I didnt quote all the direct posts above as that would probs make this a bit too linky... On the release stuff, for myself the best I can hope for is that you all see improvements as we go in this process - its obviously not something we started this week, but the first release you will see from it Even outside of the number of releases question we've been very aware and careful of API and part changes between releases for a while now to try and not introduce issues that cause pain/work. If you look at 1.4.x there were 6 releases and only one needed mod recompiles in most cases - that was primarily due to the engine version change not API changes. I obviously cant speak to private information, but things like discussions around the best way to implement things always includes whats the impact on existing games, mods etc as part of the decision making process - same as severity and impact are part of bug discussions. Having less frequent releases (which is what this plan gives) means more time for modders, testers, artists, devs... everyone to do any work they need between releases Id be dumb to say that this new process will make things perfect, and I do know theres a lot of history in this game, its releases and mod impact. There is always a risk with any update, but I like to think that with the new processes, the frequnceny and the sharing of our plans its giving more to the community.

There are some very complex mods out there yes. The previous release history was 6+ releases a year, this process is designed to reduce that number and give some more info around timing etc to help everyone. I wrote a bit more on that earlier:

Those are good points for sure's, the second one is one of the reasons we've been working to better this for sure For the first one there's always room for improvement, and its a good note - we do have a number of modders in staff/test team, but you can never have too many

Im a Ninja! - woohoo

I feel here I can add some info from a dev directly, and hopefully alleviate some of that uncertainty. Its definitely not a plan to say whatever's in the development version at the end of three months is what gets released - there's been no "deadline" to push it out the door in this process. It is the next iteration in our improvement of processes becoming more mature and complete. We've been improving these over time for the last few years. For example, if you look at 1.4 there were 6 releases in 4 and a half months, those releases take time, planning and resources. And while we did have a lot of releases we were very careful with API changes that affect mods (since 1.3 we've been very careful with what API changes happen in revision releases). Even then we saw that the mod users (and authors) were getting pain from the "when will your mod work in 1.4.x" when almost all mods only needed a code update to go to 1.4.0 when the API changed and the versioning was causing pain with incompatibility messages that in a lot of cases didn't need a recompile. The process we are using doesnt preclude a "hotfix" for game-breaking bugs and making people wait 3 months, it includes a process to assess these sort of things and decide if the severity and impact of them means we should release a hotfix. To clarify, the intent is certainly not to rush anyone in any team (and ive not seen that from this cycle at all), and its not a "deadline" where a big list of stuff is chosen at the start of a 3 month period and everyone is told to have it all done in 3 months (thats unprofessional as hell, and unnecessary pain for everyone). It does give everyone an idea of around what time frame the next release will be, so we can all have an idea of when that's coming It's the latest iteration in our aim to continuously improve our processes and provide better experience.

Ill add to nestor's comments too. A lot of us read it every week yes, and many other forum threads too (including our own mod ones at times ). Just because we don't respond directly doesn't mean we don't appreciate, investigate, integrate or discuss the feedback - or have our own opinions too at times (all those pesky people who voted for the blue/red spacesuit ) I know I don't get down about feedback - whether good or bad - because its all feedback and its all input is valuable

Yes its settings file only and value 0->1 with 1 being the most opaque value - simliar to thethe UI_Opacity value in the file

Currently its a simple scale from the request, if your looking for an atmospheric curve model check out RealPlume

yeah that looks bad Is on my list to look at along with the time format stuffs

Hehe, Two of those I am the Modder - TWP and KAC. Maybe to expand on my comment, I set the version checking in the mods to be only the major and minor version, so the checking software/CKAN know its not revision dependent (ie. the third number of the version) and from the KSP side we have been very careful to avoid any changes in revision releases that change code signatures/behaviors etc. So for 1.4.0 I recompiled and fixed a few tweaks, for 1.4.1/2/3/4 and 5 nothing for me to do and the version checking config in the mods means it doesnt complain about it being incompatible when a new revision comes out I cant guarantee every mod will work like that obviously, but its definitely the intent to not change stuff that could impact mods as we have (and have had) many mod authors as developers who all understand the problem changes to the code/structures used by mods can cause, and appreciate the time commitment it is to maintain and improve them.

Hopefully you don't have to cause we try to not update anything that should affect mods in the revision releases. To my knowledge that's the case with all the 1.4.x releases. I updated mine for 1.4.0 as there's been no changes that need rework on those since, and pretty sure I've seen LGG (who maintains a massive list - I dunno where he finds the time) and some others too with the same.

Not every bug that gets worked on is listed in these, and I'd say that ones an oversight as we do have a fix for that yes. On the too fast/too slow patching cycle (hopes he doesn't get flamed for this) we have been pointedly not making changes in revision releases that affect mods (Unity upgrades, method signature changes, etc). This should mean that I compile a 1.4.x release of my mod and its all good and working as LGG mentioned above. That's not a guarantee, but we do aim to not affect mods and call it out in the release notes if there's a change that could have an effect. I do know there will always be cases where people will want faster/slower update cycles

Thanks, working with LGG on it

Just to let you know am looking into this one, If there is a bug/feedback number I can reference that would be super. Its altogether possible my bug tracker search fu is weak

Looking into this one - if theres a bug report number for it I can use that to track/keep it up to date