Flush Foot

If I had to guess what they’ll do before Exploration/Resources, I’d say ‘certain parts generate resources over time’, so having more of / bigger ‘things’ on your colony allow you to launch / fuel things more frequently (though I do also know this can be ‘bypassed’ via TimeWarp, but doing so could also affect ideal transfer-windows, so ¯\_(ツ)_/¯

So say we all, Combined-12 @Vortygont-07

Oh… is that what has been happening to me? (v0.2.1)

Possibly, or you just need to do a whole “bug report” (prompts for attachments) then a mod will recognize a thread exists and merge it over… you could include a reference to this thread’s URL in the write-up to really drive home the point that “here is the relevant thread/report I wanted to contribute to”.

Also in 0.2 and 0.2.1

I have also had to do the “hunt around for leftover nodes” after removing symmetried struts/fuel lines. (Edit: found the relevant report here) Probably not relevant here, but another symmetry & strut-behaviour I dislike is when you go straight down from an upside-down slanted tank/piece to one that is right-side up below it (to strut two stages together, for example) and the struts try to cross through the middle of the parts as if looking for the matching X-Y-Z coordinates on the other part, despite them being in opposite orientations.

Interesting… so your theory is that (among other things) launch clamps “increase the likelihood” of a bugged craft? Might recovering/deleting them from launchpad then allow the craft to return to a valid state?

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 9 5900X 12-Core Processor | GPU: RTX 3080 | RAM: 48GB DDR4 Reddit post: Only 1 other person responded in the affirmative Video: Staging indicators move during a burn (I do know that the 0.2.1 burn from the footage was 'a bit screwy' because I had changed staging before performing the burn, but I had experienced that 'sliding' behaviour 1-2 times before bothering to capture 'something' to show) Obviously this is not a huge problem (unless someone stages "as indicated" and not "when empty"), just 'odd' as it was not happening before. If I had to guess, I would say that on a 1000 m/s burn with 500 m/s remaining in the 'first' stage, the 'drop stage halfway (1/2) through burn' indicator shifts towards the right "as if" the whole 1000 m/s burn remains to be performed but with the marker now showing staging-event is planned as if the currently remaining dV [pretend it's 125 m/s by this point] was all that was available from the start, putting the staging indicator at 1/8 into the whole burn, not 1/2. To reproduce: (have not tested this, but it should work) Cheat a small probe with 2 small tanks and 2 small engines into orbit, each as their own stage. Ex: HECS core /1.25m decoupler/ Donut tank + Terrier /1.25m decoupler/ Donut tank + Terrier Plan a prograde burn to consume all of the craft's delta-v. Staging will be projected, likely after 48% (or so) of the burn has run. Perform the planned burn. Watch the 'stage separation indicator' shift right (even jumping past the "burn progress bar") Profit. Included Attachments: Manoeuvreplansdifferentinksp20.2.1(handbrake).mp4

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 9 5900X 12-Core Processor | GPU: RTX 3080 | RAM: 48GB DDR4 I know this is effectively a duplicate of No Trajectory Lines in Map View [Indicators Like PE/AP are Still Showing], but this is my first time encountering it as a persistent bug, especially in v0.2.1 ... If I could have directly/natively attached my report.zip to at reply on that thread, I would have done so. Game even seems to be *literally* handling the craft as if it was landed (movement speed in Tracking Station is perhaps 'wrong')... even offering to Recover from orbit Included Attachments: Duna4.json Missinglinesagain...maybeworse_logs.zip @DibzNr, do you know if there is a specific place to 'vote' on KERB entries' priorities? Or is it just based on volume of bug reports?

Looking forward to playing it again tonight! (Especially the automatic resumption of location-specific experiments! Took me a bit last night to realize the starlab was altitude- and biome-dependent… Edit: Maybe in 0.2.0 starlab was biome-aware "at all altitudes" but in 0.2.1 it definitely only cares about biomes in 'low orbit' and handles all of 'high orbit' as if it were a single biome.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 9 5900X 12-Core Processor | GPU: RTX 3080 | RAM: 48GB DDR4 ## Mission Description We're getting farther out in the <style="OBJ-Kerbol">Kerbollar System We're going to need to set up communications to keep getting signals Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Home 22H2 | CPU: AMD Ryzen 9 5900X 12-Core Processor | GPU: RTX 3080 | RAM: 48GB DDR4 I know this has existed for a while now, (though I could not find 'orbital lines' or 'no orbital lines' in a forum bug reports-search) but this is the worst I've ever had... all craft in various orbits have lost orbital lines, and this has persisted through quick-save/quick-load but apparently not through exiting to Desktop and reloading. Reviewing save-files for "ControlState": "FullControl" / "Situation": "Orbiting" has not worked as the two main vessels ("Duna_Lander_Mk3-6" and "Ike_Plus_Recovery-14") show the valid statuses, but have no lines. All other vessels in LKO thru GKO are similarly afflicted, and likely so is a Minmus relay. To replicate; open Tracking Station... (unless the "reboot" that finally fixed it for mine will also, automatically, make it functional for yours too) Included Attachments: MissingOrbitalLines_logs.zip .ipsImage { width: 900px !important; }

No worries! Lots of similar sounding reports have probably crossed your desks in these first few months , some related and others not so much

I thought I’d also reported this exact bug in the forums (with YT clip) a little earlier in April… I’ll look for it here, Reddit, Discord Found it! And Reddit Conversations happened in both threads: https://www.reddit.com/r/KerbalSpaceProgram/comments/12l4w3c/does_anyone_else_think_the_manoeuvremarker_is https://www.reddit.com/r/kerbalspaceprogram_2/comments/12m5ict/does_anyone_else_think_the_manoeuvremarker_is

And occasionally it tries to rename the KSC on you… but I’ve noticed this in launch-version and Patch 1 as well… haven’t tried it since Patch 2 though.

Can also use this https://spacedock.info/mod/3348/Savefile Pruner

There is also this (still just ‘temporary’ but perhaps easier to do) utility on SpaceDock: https://spacedock.info/mod/3348/Savefile Pruner Savefile editor, not a ‘true mod’

OneDrive link to the .zip that the "KSP2 Debug Reporter" generated <in which I made sure 'all 3' scenarios', plus the starting point's, save-files were included: https://1drv.ms/u/s!AnVDgr4UND5Pgc4AozXQ8j5yTrgcbQ?e=yLy4gl

I wonder if this is similar to my earlier report (and someone’s comment from today too)… Are you sure you have two craft post-separation? Or are they still ‘connected’ (even if only in the Kraken’s imagination)

I can think of two solutions to this: • Manoeuvre planner applies inputs in the same way the Manoeuvre node will respond (like where pulling up on Normal marker plans an all-normal burn even as Normal moves, causing the planned orbit to match what a full-duration Manoeuvre-hold burn provides) though this will be challenging when time-warping through a weeks-long interstellar burn without ‘course-correction’ • Manoeuvre planner’s predicted path is what the Manoeuvre node-marker points at, possibly adjusting course slightly if any off-axis thrusting takes the craft off the projected course (KSP 1’s manoeuvre-hold/marker behaves basically this way)

KSP 2 v0.1.2.0 Win10 22H2 5900X CPU 48GB DDR4 3200MHz RAM TUF RTX 3080 10GB From my Reddit post: Does anyone else think the "Manoeuvre-marker" is incorrect? [or just different from KSP 1?] What I mean by my post is this (and I will get got a video up later tonight to demonstrate my point): If I have a manoeuvre that is moderately 'normal/anti-normal' or 'radial in/out' [so not strictly prograde/retrograde] and I run the burn at 1x speed with SAS holding the manoeuvre all along, my full-duration burn has an appreciably different result than was planned, and the node/marker moves dramatically during the burn [this is most evident to me with normal/anti-normal inclination-matching burns]. The best I can figure is that the marker and burn are programmed to be [for example] 15-degrees to the normal of prograde, but the marker then continues to be that 15-degrees off prograde, even as prograde moves-normal. If I use SAS to marker-lock and then enter time-warp [no changes in orientation] or switch to the orientation-lock instead of the marker, the burn does basically what I want/expect it to do. In KSP 1, I know it 'assumed' you were dumping all velocity into the orbit in an instant, but the marker only moved around in response to off-nominal thrust, leaving you with a decently close match, most of the time. Am I hallucinating or other-thinking this, or have others noticed the same thing? [I've noticed this ***certainly*** since Patch 1 (v0.1.1.0), but I think even since launch (v0.1.0).] [<Long> video! Cliff notes: 28.2-incl.+raised Ap planned and Normal\/Manoeuvre-marker burns yielded 30.8-incl. and nearly-circular orbits while locked on initial marker gave planned orbit.]

I don't know if this is a bug or a design decision... that's why I went with the Engine Plate [kind of like a KSP 1 interstage fairing]

60 second clip of the results of the bug 'in action'

2.5m decoupler separates Eve interplanetary stage and the Engine-plate that has to be used to store the inflatable heat-shield [since nothing is able to attach to the bottom of that now]... I fire this decoupler via staging and I *hear* the sound, but no separation occurs. I go into parts manager to re-trigger the action, but nothing. If I reload a quick save (see quicksave_50.json) it usually is disconnected visually, but both halves are still acting 'as one' [SAS changing to prograde applies to both parts, for example]. Detach_Bug.json has been edited with the hope of 'deleting' the struts that connect both parts, but it appears that corrupted the save [FailedToLoad.png shows where THAT save gets stuck] Link to "Debug Reporter" output Post glitched and I retyped it... Forgot to include: KSP 2 v0.1.1.0 (no mods) Windows 10 22H2 AMD 5900X 12-core 48 GB DDR4 3200MHz 10GB ASUS TUF RTX 3080

90% certain it's "Orbital Assembly Building"... from either 'future colonies' functionality of assembling the colony on-orbit or orbital construction of vessels