HebaruSan

Is it 5? I spotted 2, 7, 8, and 9, which did I miss?

If you let the forum software censor the original word, then we can figure out what it was.

I don't remember, is it also gradual if you click the warp bar section to jump to 1x directly?

In case this helps anyone else: My frustration with VAB2 mostly ended after I realized I could middle-click a part to center the camera on it.

Here are the community manager's replies stating they were still trying to reproduce it and asking for saves and craft files: https://forum.kerbalspaceprogram.com/topic/217838-not-slowing-down-on-reentry/?do=findComment&comment=4295765 https://forum.kerbalspaceprogram.com/topic/217838-not-slowing-down-on-reentry/?do=findComment&comment=4295831

Summary "Good" saves that were created as per user intention, and therefore have undergone a process of at least casual consideration as to the value of the current game state, can be auto-deleted when a new auto-save is created in response to a background timer. Details There are two kinds of saves: Auto and manual. Auto-saves are (mostly) created in the background on a timer in a rotating bucket of 4; once the bucket is full, the oldest one is automatically deleted when the next auto-save is generated, which makes sense to save space and clutter. Auto-saves are generated unconditionally, and if the user loses a craft due to (say) the explode-on-docking bug, and the user does not wish for that state to be preserved, the only way to prevent a subsequent auto-save is to load immediately. Otherwise the auto-save bucket can gradually fill up with what the user would consider "useless" saves, and older "valid" ones are lost. Manual saves are immune from this auto-deletion; they endure forever. This makes sense because the user has specifically requested that game state to be preserved. When you exit the game, it prompts you to save before exiting (I cannot capture a screenshot because I'm not in Windows at the moment). This raises a question: Is this a manual save or an auto save? The answer seems to be that these saves go into the auto-save bucket, which means that even though the user has specifically thought about it and requested that game state to be preserved, it can be lost later without the user requesting it. Suggestions Treat saves created when the user clicks "Save and Exit" as manually created saves, immune from auto-deletion.

The devs speak consistently about how "user stories" drive their priorities, meaning that functionality would be built and improved based on what the game needs to do to deliver the intended experiences. In an ideal world*(asterisk the size of Kerbin), this would mean that after the devs move the "feature/science" branch into testing, the testers would, among many other things, try running a sample return mission from Duna with rovers and docking, note the flips and explosions, and then update the existing bug reports for those problems in the internal bug tracker to indicate, "Severity increased because this impedes For Science! User Story #3." Then those bugs would percolate to the top of one of the fixing queues, be assigned to a developer, and get fixed before release. *(asterisk the size of Kerbin) - We do not live in that world, so some degree of falling short is to be expected. In particular, their failure to reproduce the old "re-entry accelerates pods back out of the atmosphere if they've ever been staged" bug after very clear and specific user reports indicates that the testers take shortcuts (and don't realize when it might be a good idea to avoid them), so a full end-to-end test mission may not happen. The prioritization system they're using may not cause the right bugs to be assigned out as needed. The devs may not be able to fix such bugs in the allotted time. But those are questions of adequate dev/testing practices, not whether the next release should include new features. If Intercept manage to get their processes to a point where they can be relied upon, it should be perfectly feasible to ship new features alongside whatever bug fixes are most needed for them to be enjoyed. In other words... Same here. Now when I rage-quit, the period of never-wanting-to-play-again is much shorter; before I know it, I can't help thinking "What if I tried X instead?", then I try it, and half the time I'm able to move past the previous showstopper problem. (This is somewhat helped by the changes to the save system, which ensure that "persistent.sfs" doesn't trap me in a post-bug state anymore. I can pretty reliably return to the last-good state.)

Cool, in that case I can just refer you to everything else I've written after the first sentence. And back on topic, I am also seeing much higher FPS in this patch. I never thought this PC would last this long. Bravo!

What "multiple paths" and "multiple processes" are you referring to, exactly? I'm not quite following the point you're making. If you mean a user having the option to revive an old issue versus starting from scratch, then sure, I've seen plenty of drive-by comments on the CKAN bug tracker that in fact had nothing to do with the original issue. But if there's not going to be a quick and easy way to revive a report, then when a user puts in the effort to clearly and completely document a problem (another recently auto-closed bug report of a still-current issue, Incorrect/Buggy Units and Values in CB Information, is particularly good here), it probably shouldn't be archived by an automated process without anyone marking it as probably-fixed.

That's true if an issue is complex and has been worked on. In this case, a very simple UI issue (a label in the settings says "auto-hide" instead of "show") has been auto-closed at a new release after not being worked on. That's simply no way to run a bug tracker. "Returned" applies only to bugs the developers think they fixed. That's not what happened here.

Hmm, that's not just a headache, it's a pretty significant duplication and waste of effort to re-submit an identical description of something that has already been filled out. I hope you won't be too offended if I say that I feel I have better ways to spend my free time. Maybe bugs that haven't been worked on shouldn't be auto-archived as if they had been?

What's the process for un-archiving an existing bug report? I just confirmed that this one is not fixed, but it has been moved to the 0.1.4.1 archive section and can no longer be upvoted: https://forum.kerbalspaceprogram.com/topic/219775-in-the-settings-the-auto-hide-navball-in-mapview-does-the-opposite-on-is-off-off-is-on/ Maybe this is @Anth's domain now?

Is there a prize for guessing correctly, like guessing the number of gumballs in a jar at a county fair? It will happen when it happens, and none of us really has any idea (as the previous post so aptly demonstrates). My gut says 5 years till the last roadmap piece is released, but if that's right or wrong... so what?

Absolutely. In my book, the instantaneous surface scanning was the biggest missed opportunity in KSP1. A well-known model that made orbital parameters significant in interesting and planet-specific ways was just ignored and replaced by something boring. There's even the potential for replay value: In real life, you don't just scan a surface once. New instruments are created to answer new science questions with new missions. And you know that a new player is going to screw up the scanning orbit the first time or two, so the chance to do it over again but more efficiently offers a satisfying gameplay opportunity.

Reported Version: v0.1.5.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 10 | CPU: i7-3770K | GPU: GTK 1060 6GB | RAM: 32 GB Precision rendezvous and docking requires fine manipulation of the velocity relative to the target. In the original game this could be done by switching the navball into target mode and moving the retrograde marker around till you were on top of your target. In the sequel, the target-relative retrograde marker and the target relative velocity both give misleading readings while your craft is rotating. If your actual center-of-mass relative velocity is 0.8 towards the target, but your cockpit's rotation gives it a relative velocity of 1.5 m/s, that can be shown as anything from -0.7 to 2.3 m/s, and the marker moves all around based on the movement of the cockpit rather than reflecting the movement of the overall craft. Both values temporarily reset to "true" if you press "./" to start and stop time warp, then drift away again as you rotate to perform the maneuvers needed for rendezvous. This adds a layer of UI/UX frustration to the challenge of docking, since the player must now guess what the actual relative velocities are and/or attempt to remember precisely where the markers were the last time time warp was engaged. The target-relative velocity should be calculated relative to the craft's center of mass, and rotating should not affect it at all.

The underlying setting says "Show", but the UI says "Auto-hide". This could be fixed extremely easily by editing the string in the UI to match the name of the setting.

Well, if they ever manage it to fix it in the base game, maybe a community manager can tag me, and I'll be happy to re-evaluate it and update my Steam review. Until then, this is a frankly shocking disparity between what the game implicitly promises in the VAB and what it delivers on the runway.

That's correct, these tanks are not intended to ever decouple. They're supposed to be part of one fuselage.

This level of strutting (13 per side) is apparently not sufficient to keep these tanks together at launch. Composing my negative review on Steam shortly...

Let's concentrate the discussion on the issue you submitted rather than duplicating it here, please. https://github.com/KSP-CKAN/CKAN/issues/3919

Checking again, I think I mentioned the wrong setting. "Include plane change burns in Δv display" would be the one that makes temporary maneuvers in the background; "Generate plane change burns" I think controls what happens when you click to create a maneuver.

You can also try turning off "Generate plane change burns" in Astrogator. It looks like Alarm Enhancements hooks into maneuver creation and doesn't like it when Astrogator does that from a background thread.

Manual installation is unnecessary. CKAN has a system for setting compatibility tolerances according to the user's preferences. You can tell it that if a mod author published an update for KSP1 1.12.2, it should treat that as compatible with 1.12.5. FYI to @Xaned Kerman: No mod author is going to react to your threads by updating their mods, because your demands are made out of ignorance and there are things that have already been pointed out to you that you can do right now to install these mods with CKAN!! Click and learn if you are serious about wishing to install the above mods! https://github.com/KSP-CKAN/CKAN/wiki/User-guide#Choosing-compatible-game-version

Specifically, "SovietRockets": https://github.com/KSP-RO/SovietRockets https://github.com/KSP-RO/SovietRockets/blob/master/GameData/RN_Soviet_Rockets/R7/master/r7_bvgd_engine.cfg

Indeed, I mis-stated point 3 (the creator even tours the VLTI earlier in the video); the hoped-for development was the ability to do visible light interferometry with computers instead of physically with big pipes of light.