Flush Foot

Beat me to it @Dakota! I just noticed 'hi-res' on Discord and was about to share that link

'On the horizon', Colonies are. Perhaps the topic we are looking for, it now is. - Yoda Kerman

Oh, I really hope that's not how it works in v0.3 when Colonies (pre-resources) comes out... I have no problem needing to ship in the 'seeds' of the colony from Kerbin, but I really hope that there are gradual "part/fuel-generators" that just consume large sums of energy and produce loads of waste-heat to enable true off-world construction (or even 'role-playing' as if you've lost all contact with Kerbin, an orbital probe shows a smoking crater where once the KSC stood, and now your colony is Kerbality's only hope for the future, doable only because a sufficiently-advanced colony could be self-sustaining)

I think you mean "the opportunity is playing around all the bugs"... Last night, I took off from Gilly and realized that I was glitched into 'landed state' thereafter... so I promptly escaped Gilly's SOI and pillaged as many of Eve's biomes as I could reasonably hit be bothered to time warp to find myself over and got loads of juicy, juicy "Eve-surface" science

I made a post on another thread that is hopefully relevant here

I intended to do two near-identical craft, one launched within a fairing and the other not, except even the no-fairing test-vehicle wasn't playing nicely, so I gave it a double-length I-beam nose with a variety of sample-arms' positions along it for testing. Imgur album

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: Gigabyte RTX 4070Ti-Super | RAM: 48GB DDR4 I initially thought I might be imagining this, or that maybe decoupling a spent stage (two crafts / two burns) imparted a small rotation to my craft, but in Monday's play-session, I saw my craft (and I believe maneuver-marker, to which I was 'locked on') noticeably re-orient itself once the previous stage was released. <<I have video now showing this on a test / dummy craft>> My best guess is that, along with the moving 'separation indicator' reported here, the game recalculates where the burn "should" have been pointing all along, as if the whole burn was using the engine(s) now available to it. In the bug-package (craft, save-file), there is a vessel cheated up to 2700km x 2700km circular orbit, with a ~700 m/s delta-v first stage and a planned burn (calling for significant changes to Pe and inclination). Execute the burn locked onto the maneuver-marker as indicated. Upon detaching the spent-stage, the marker violently shifts itself by -40 degrees, (305-deg to 265-deg) which also leads to a dramatically different orbital outcome. <Edit / additional observation (2024-03-25)> Not even occurring solely when changing from high-thrust to low-thrust… it just happens any time staging occurs mid-burn; for example, I had a Jool craft with a central stack of Lrg Hydrogen tanks with a SWERV engine, 2 radial stacks of the same, and a final 2 radial stacks of tanks without engines (tanks fuel-line fed the radial+engines which then fed the central stack, à la asparagus) and when I dropped the ‘unpowered’ but still spent tanks mid-burn, my trajectory shifted, though perhaps less violently. </Edit> Included Attachments: Multi-stageManoeuvresinKSP20.2.1.mp4 Multi-stageManoeuvresMisbehavinginKSP20.2.1_logs.zip

Video is processing now, but I have footage of the confused maneuvers: I no longer think it applies to my original post/report though, so I will make a new one specifically for this.

I would have to do some serious testing / investigating to know for certain, but my hypothesis is that the game says (using hypothetical numbers): 25t of fuel through one 0.5t engine = 2,000 m/s delta-v 25t of fuel through three 0.5t engines = 5,700 m/s delta-v (it recognizes increased engine mass BUT it believes each engine gets to run through the whole 25t of fuel, not 1/3 of 25t each)

Worse / weirder still is that it seems (to me, anyways) as if even upon planting that "next-SOI plan" by panning the camera into position, the prograde/retrograde/other markers on the planner do not correspond to pro/retro in that SOI but instead they're related to your current SOI's vectors. Still looking forward to the day that stock-planner bestows upon us the gift of future-orbit planning (without having to timewarp into the future to see if 'now' is the best time to try a burn).

@Dakota, when you feed us the lions regularly, we're they're (probably / hopefully) less likely to snap at you

I would like to know what people are likely to prefer to see in-game when "Jool orbit capture-burn" is 4 years, 23 days, 5 hours, 12 minutes, and 17 seconds away, do you want the game to show the largest 2-3 items in the Maneuvre Planner? The smallest? 4Y:23D:5H 5H:12M:17S Other? Personally, I would prefer the first option; show me a less-precise (but “more complete”) time rather than telling me my 3200 m/s dV ion-stage will “only” last for 25 minutes and 43 seconds (as that staging-menu seems limited to 'two values'), please tell me instead I’m good for 1d:5h (then adjust/scale to 5h:59m when under 1 day and then 'down' to 59m:59s when under an hour) List of 'times' shown in-game (not necessarily exhaustive): Time for stage to consume all propellant Time until start of planned burn Planned burn's duration Time to next Ap/Pe (Ex: stage propellant-consumption duration seems to only show minutes & seconds, which can make gigantic Xenon/ion engines look like “45 minutes to run out” whereas you likely have days of available thrust) But what are yall's thoughts?

I could be imagining this, or maybe decoupling a spent stage (two crafts / two burns) did impart a small rotation to my craft, but in yesterday's play-session, I saw my craft (and I believe maneuver-marker, to which I was 'locked on') noticeably re-orient itself once the previous stage was released. My best guess is that, along with the moving 'separation indicator' reported here, the game recalculates where the burn "should" have been pointing all along, as if the whole burn was using the engine(s) now available to it. [I will try to test this hypothesis tonight too, along with the 1-3 others I said I would... I should really be writing these down somewhere]

I'll try to do so tonight too... though I'm starting to remember how much work it is to both play KSP2 and be an unofficial member of the QA dept

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: n/a | CPU: n/a | GPU: n/a | RAM: n/a In Matt Lowne’s 2024-03-09 Minmus video (25:09), I saw that: The message says, ”Bare witness to her brow, … Bare witness to her influence, … Six times the heavens… Bare witness to the Goddess…” Unless this is meant to be a ‘typo’ due to translation from unknown ancient language, “bare witness” could be read instead as “naked witness” while it would be “bear witness” to say “behold”, if I’m not mistaken.

I wonder if this is happening with other SOIs too... I was having 'tons' of fun last night with manipulating a manoeuvre to slow my approach to Moho without losing the (indicated, anyways) encounter. I also wonder if it happens only to moons of planets vs planets around stars, or if it happens with "Pe stays above target's orbit" vs your reported "Ap stays below target's orbit"...

I encountered this too... Last night (and I reported it, especially after spotting this post) and also in my previous session (but I was nearly done for the night and wasn't sure what to make of it); hopefully my report is spotted and merged in here "Soon.TM"

The way I usually attach logs/zips/craft-files/etc. is by submitting a standalone bug-report, either thinking it is truly unique or by directly citing the URL / title of an existing report and allowing the moderators to merge mine with the existing one, like: Which I may end up doing here tonight after some testing... I remember seeing a surface-sample arm on one of my craft saying "Blocked", but I also wasn't (yet) on the surface I was aiming for, so I had ignored it at the time.

I’ve certainly run into this a number of times, and I even believe Matt Lowne’s March 9 Minmus “Tutorial” video encountered that behaviour. (Will re-reply with link/timestamp if I can find it) 15:30

That’s half-right… you cannot select your trajectory in the new SOI while focused on the new body (that “detached” trajectory line) but if you look at the larger map, where you see Entering SOI > Pe > Exiting SOI markers, you can plant a manoeuvre along that trajectory, but it’s awkward (and unintuitive) to use, IMHO

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: Gigabyte RTX 4070Ti-Super | RAM: 48GB DDR4 Addition to: When my ion-propulsed probe was in Kerbolar space, it had no trouble (mercifully) doing acceleration under timewarp (using both Ion-only and Ion + Nuke H2). Now that I am in Moho's SOI and trying to burn off the last 100 m/s to capture into a reasonable orbit, acceleration under timewarp only results in fuel-burn, not orbital-modification... Is it possible that the problem has to do either with being in a 'smaller SOI' or having an escaping-trajectory? Included Attachments: AccelerateunderTimewarpstillnotworkinginsomecases(Post-v0.2.0)_logs.zip .ipsImage { width: 900px !important; }

It is especially messy since Prograde/Retrograde/etc. are "misaligned"... Pulling on Retrograde on a next-SOI-manoeuvre does not (at least, not usually) result in a circularization burn being planned out as the 'retrograde direction' according to the node is the same direction as if you were burning retrograde in your current SOI, except it is happening in the next one. This is particularly painful when dealing with a low TWR ionic probe and you're trying to determine if your encounter will provide enough time to circularize before escaping that SOI. If this is "expected behaviour", then I would hope for either an in-game GUI-toggle (kind of like in VAB, rotate/translate part locally vs globally) or a Settings-menu selector to go between 'KSP2 behaviour' and 'classic KSP1 behaviour', thanks.

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: Gigabyte RTX 4070Ti-Super | RAM: 48GB DDR4 Probably a duplicate of ShadowZone's report: I had not even registered "using Ctrl-Z" on my craft, but upon reading his post I did remember using it (once) since relaunching the game today. In my video, the struts going from the "decoupler" stage down to the radial boosters also had to be attached individually/manually as they completely refused to be placed with the "broken/false-symmetry". Included Attachments: Kerbalspaceprogram22024 03.11-19 45 17 01(handbraked).mp4 SymmetryFailure_logs.zip

Question… does the ‘Press F’ work climbing up and down the ladders at ‘intersections’ or only when climbing up?

Huh… I hadn’t even considered a “repair yard” functionality! Would it actually be ‘dock and edit’ or ‘recover and relaunch’ though?