Jognt

The few heating problems I encountered (mostly with the 1.875m pod) were ‘fixed’ by setting SAS to Surface mode instead of Orbit mode after selecting retrograde. 2000k is already ridiculously hot, so I doubt that that is the culprit.

I second this. Not sure why nothing changes when that button is pressed.

That workaround hasn’t been needed for over a year. Do not use.

If Squad goes SaaS, I’m blaming you.

Cool, thanks. I'll give that a try until a proper fix has been done. Let's be honest here.. it's not the game that can't do it.

What do you mean? Just mouse over the icon, mouse over the bars (all?), and it’ll work again when no longer mousing over?

I think we can expect them to unkerbal the things they kerballed in those free updates. We’re not talking about niche use cases here. Every freaking time I fuel transfer I have to do a dance with quicksaves and quickloads. That gets old real quick when you’re using reusable landers and stations.

If you do things very well for long enough you start to realize that you have to draw a line and say “Not doing that.” Because people will keep trying to get you to do more work for less money. Especially when modding in your free time. At some point “It should be an opportunity to do better!” starts sounding like “We’ll pay you in exposure!” It’s in the FAQ for a reason.

You sir, are a legend.

The orbit line changing during warp and jumping back to where it should be after warp is normal afaik. I'm talking about the orbit being different permanently.

That’s normal. It’s just zeroavc’s way of letting you know it’s doing its thing.

Hold ALT while pressing the < or > key if you want to use physics warp instead of on-rails/spaceWarp.

Lost my first Eve mission because I used "Warp to Maneuver" to warp to my 105km Pe burn to circularize and found myself to be a hot flaming mess inside the atmosphere. I've now installed a mod to auto-quicksave every minute. This game's bugs are ridiculous. *looks at non-discounted price & rolls eyes*

Anecdotal: I noticed last year when I was troubleshooting another problem by removing mods from GameData that the ‘all models show at once’ problem was gone after removing one half of my GameData. (Keeping dependencies present best I could) I never found out what caused my other problem and quit playing for a while, so unfortunately I never dug further with regards to the model thing, but maybe this can help those currently affected.

You’re better off creating a patch for that config or creating a pullrequest to make changes to the file in the actual mod distribution. Just in case: If you do make a separate patch, use NEEDS instead of FOR.

There you go, that's indeed one of the other options. When I was reading up on ModuleManager and its passes I did a lot of searches and came across several posts in this thread that detailed the reasoning behind adding passes, and the official guidance that came from it. When RTB posed his question he was unfamiliar with MM syntax. So repeating "It is recommended to not use FINAL in distributed software" should not be a surprise. Even a patch using FINAL can ruin games if someone else distributes their own FINAL patch on solar panels after Kopernicus. So if Kopernicus wishes to truly be safe from it, then an alternate solution would be recommended. These solutions can be anything from 'Assume other modders use the FOR pass for their mod and utilize the earliest pass that isn't FINAL to overwrite those changes' to 'Backup a user's savegame before loading it.' or even 'write completely new modules from scratch and ignore any existing solar panel modules.' All have their pros and cons. The guys that made MM what it is today put in a LOT of hours and a LOT of thinking to get it where it is today. I think it's a better idea to learn and understand where the best practice came from. I'm honestly baffled by the tone of your comments, so since I have said what I wanted to say: I wish you a good day and I'll let @R-T-B decide for himself. -Jognt

You and I both know that there are always plenty of options in programming. Ive read a few solid reasons to use final so far, but your comment is not one of them. I’d appreciate it if you did not make this personal. Programming allows for the creation of just about anything you can imagine. While not wanting to spend the time to write a solution is understandable, it’s a poor excuse for skirting guidelines IMO. In short: Its not okay to thrash a save. There’s just a LOT of ways to deal with that. FINAL is just the easiest. If RTB decides to stick with FINAL despite now knowing the ins&outs of it, then that’s his choice. Until then: He asked for feedback on his patch and got it. Key phrase being “beyond introducing additional complexity.” Look, RTB asked for feedback which I provided. That feedback can then be disregarded or ignored. But please don’t equate “It would take more time and effort to smooth this out than I have.” with “There’s no other choice!” Because the first is understandable, but the second is a lie.

@Lisias I understand the whole "Others are already/still ignoring the best practices, so we cannot be sure we beat even them unless we also ignore the best practice." intention. However: As long as all mods are treated equal there will be no way to 100% guarantee any one mod will always be last in any pass (though LAST and FINAL are both well after FOR/AFTER). So while one achieves less annoyed users at his/her doorstep by joining the racers, the race also continues, causing more annoyed users at others' doorsteps. I can understand where you're coming from, I just don't agree with it. Good luck with what is undoubtedly little work to leave as is, and quite a bit of work to find an ideal fix for. o7 My idealistic €0,02.

Use whichever you wish. I would however like to point out that LAST happens once FOR and AFTER are alphabetically 100% done. Lisias’ concern could be valid if this was not the case, but even then: FINAL is also processed alphabetically. Both will work. Having said that, I’d prefer following best practices. In this case: ‘use the first pass that produces the desired result’ and ‘try and avoid FINAL.’ In this case LAST would still cover every part/module that is altered in legacy/first/before/for/after passes. To see the order of patching passes: Check your local MM log.

Discussion about LAST versus FINAL for use in Kopernicus: GO! As far as I know LAST exists to ensure patching compatible with BEFORE, FOR, and AFTER passes without having to resort to FINAL. This in order to prevent another 'race to FINAL' occuring.

FINAL is safe, yes. But LAST exists to fix the race to FINAL. The LAST pass happens after all of the other passes have alphabetically been completed. LAST probably didn’t exist when FINAL was chosen. I recommend moving this to the MM topic though. There’s more knowledge there and we’re threadjacking the NF thread at the moment. Edit: Let's go here:

I’d replace :FINAL with :LAST[Kopernicus] to honor the “Please don’t use FINAL in distributions.” request. (LAST is effectively the same but allows for modifying modifications down the road.) Pass specifiers like FIRST/BEFORE/FOR/AFTER/LAST/FINAL are separate from conditional specifiers like NEEDS. Though AFTER functions like a NEEDS too. There is no reason to ship a mod with a patch that has NEEDS[thisMod] because it’ll always be true. NEEDS is for patches distributed in a way where it is uncertain if the conditional mod is present.

You guys are rockstars

Might I recommend sticking to the usual incremental numbering? Precisely to avoid confusion. People *will* google with version numbers. People *won’t* read the context. People *will* get confused.

Thanks a bunch!