LameLefty

Yeah I noticed oddities with EC usage on launch day but it’s been way low on my radar. I have run into circumstances where I’ve run out of electricity though - I had a booster stage time warping to a maneuver node on the night side of Kerbin and couldn’t make the maneuver because batteries were dead. I had left SAS engaged pointing prograde, and the vessel had a large control/reaction wheel unit installed. During time warp behind the planet, with solar panels eclipsed, the batteries did drain. However, with just a command pod or small probe, I’ve yet to see any significan EC usage.

It might also be they are using both distributed development and offsite testers, all of whom would have access to depots and builds separate from what’s available to customers through the Steam consumer interface.

[snip] The stuff discussed in this thread is not new for any company in the world when economic conditions shift and investors get nervous. Middle managers and a few leaders take the obvious falls, lower level people get pressured to work harder with often (not always) some layoffs. Alternately, there are no layoffs but staffing levels are reduced through attrition (those who leave are not replaced). People buckle down and hopefully hang on until financial and economic conditions improve. I would venture to say the very same thing has happened to more than a few of the people on this forum if they are old enough to have worked for a decade or more.

I have been a member of the forums since March 2013. The date of my profile says April because I also remember The Great Forum Crash of April 2013 that swallowed up and destroyed several weeks’ worth of posts without backups (thanks, Squad!). I actively participated in every KSP release and submitted numerous bug reports from versions 0.19 through about 1.2, and even won a contest where I got to name a Kerbal for one of the bugs I reported. I’ve posted a LOT of techniques and suggestions for people struggling to understand the basics of rocketry, rocket design, aerodynamics and orbital mechanics, much of which is informed not only by thousands of hours of playing KSP but also by my education as an aerospace engineer. I hope to do more of the same throughout the development of KSP2.

Yep, I get all that. Thing is, the current system "sort of" works the way I want and expect it to anyway. Go to a craft on a trajectory in space, anywhere. Start off with some prop in your tanks, so the system lets you create a working node. Doesn't matter how much, just some. Now go to Map view, click somewhere along your current trajectory to create a node. Grab one of the axis handles and start dragging. The node will give you a helpful NO FUEL annotation message or words to that effect (I'm away from my PC right now so I might have misremembered how its phrased). Same thing with the burn progress indicator. It will be red from the point at which you run out of propellant during the estimated burn time. The fact that the vessel will be out of propellant well before the end of the maneuver does not stop you from creating (and planning) such a maneuver in the first place. So my proposal would be to do the same thing if you have no propellant (or if the game - due to existing bugs - THINKS you have no propellant, as happened to me). Mark the Map view with NO FUEL or whatever, color the burn duration red for its full length, whatever UI cue you want. My suggestion merely extends the existing cues and would make the entire experience consistent, regardless of how much propellant remains in the vessel at the start of the plan.

The Mun arches are cool. I guess I'm spoiled - the very first time I landed on the Mun in KSP (March or early April 2013?), I happened to be passing very low over the northern rim an equatorial crater where a Mun arch is located totally by accident. I ended up landing within walking distance. It was a pretty great introduction to the world of KSP to find something so surprising and delightfully mysterious so early after my exposure to the game.

What does that even mean?

Boy, that’ll show ‘em! I expect the first patch minutes after your sternly-worded missive.

I want to add, too, that is *is* possible, just about, to fly very close to a direct-assent orbit in KSP2, much like most rockets do it in the real-world today, and do it completely manually. The method is, once you see your Ap getting very close to what you want your final circular orbit to be, point your craft nose down toward and then below the horizon. Keep pitching down while you burn until the Ap is no longer increasing, or at worst increasing very slowly. At this point, you are adding velocity and shaping your orbit further and further oblong, pushing your IIP (initial impact point) of your Pe on the surface of Kerbin ever further downrange, until eventually your Pe goes positive and starts climbing rapidly. You will have to pay close real-time attention to the Ap numbers as you fly, and control your pitch up and down while you climb to keep that Ap more or less constant. It's been many years (pre-MechJeb circa version 0.19) since I had to do this regularly, but I've gotten reasonably good at it again. Yesterday I flew an ascent like this that required under 100 m/s to properly circularize a 110 km circular orbit. And since the ascent is nearly direct, the time to Ap was almost half an orbit around, so plenty of time to carefully craft a maneuver node for that final burn.

See, this gets back to what appears to be some fundamental issues (to me, an actual aerospace engineer) between what I expect and want to use a "maneuver planner" for, versus how the feature is implemented in the game at present. If I'm in orbit around Jool, for instance, and I want to know how much my velocity needs to change in order to change my trajectory and end up on a return trajectory to Kerbin, the ACTUAL AMOUNT OF THAT VELOCITY CHANGE does not depend one iota on my current mass, how much propellant I have in the tanks, or what the T/W ratio is of my craft at any point in time. I just need to know how much faster and in precisely what direction to go. To calculate everything precisely and make a good estimate of burn time, motion during the burn, etc. I do need to know all that stuff. But the net change of velocity is all that ultimately matters in the ideal case.

Well, I want straight to #4, haven't yet bothered with #1 or any of the others (yet). No mods, but there is a major Duna spoiler here, so be warned if you want to be surprised.

At least the Facebook posts haven't stopped.

This should probably go in the Gameplay subforum, but yes. The real world has nothing like “SAS” to hold rockets stable during launch. and it appears KSP is going to be more like the real world for launchers than KSP1’s over-powered SAS. Design your rockets to be less “long-and-heavy-at-the-end”, or else start your gravity turn way later, outside most of the atmosphere. Long and heavy-nosed rockets will (and ways have in the real world) required fins for pitch control. Engine gimbaling can only do so much. Too bad KSP2 doesn’t yet have something like KSP1’s aero-forces visualization. If it did and you put fins on your rocket, you’d see how much force was being required to counteract the pitching moment from all the mass at the payload end.

Probably, but in a game with ancient artifacts scattered around the solar system, I prefer to imagine there’s more going on with poor little Dres than just natural processes.

SAS has worked fine for me, most of the time. For my use-case (rockets and spacecraft, not aircraft or rovers), I’ve found it tends to work just fine during ascent and most of the time in space. I have had one instance in ~30+ hours of play when SAS just simply stopped working entirely. I had to save, quit the game and reload and then it worked again. The other SAS failing for me is failing to follow/track the maneuver node. That happened to me most recently this past Saturday when I had a very light probe and a frankly over-powered core stage trying to boost it to interplanetary speeds. I resolved that by limiting the throttle of the engine to 50% and the gimbal range to 30%. After that, SAS held the pointing accurately though that burn and subsequent course corrections.

So, it’s not really part of the “lore” as such, and certainly not as plainly anomalous as the “Stargate” Munarch, or the statues on Minmus, Duna and Tylo, but there’s something intriguingly “off” about Dres. Most people by now realize it has a set of small rings now, but when you het a chance, take a look at the equator - it’s got a prominent ridge line now that seems to circumscribe the entire planet. It looks almost like something got the little planetoid spinning so fast, it created an equatorial ridge and threw material off into space that formed rings.

You guys are noticing a combination of the lack of water physics yet in the game, plus Unity’s signature texture-tiling. The physics will be fixed eventually. The textures being tiled may or may not be alleviated or made less obvious over time.

Yep. I adore that mod. I desperately hope it gets ported to KSP2. In the meantime, it’s hard-core, old school “pushing” and “pulling” the velocity vector marker onto the target marker. Satisfying but so much slower and less precise and efficient.

This afternoon's adventure was to return to Jool and orbit Laythe. Made it with a tremendous about of dV to spare with this little probe, so I'm likely next time to send a probe lander. I have to say two things: first, the new cloud and terrain features for Laythe are spectacular. I love the lighter color water in the shallow, coastal areas, the dune textures, and the mountainous regions. Second, the current maneuver node UI and inability to display local conics makes all this a lot harder than it should be by KSP1 standards, even doing it all manually without the help of MechJeb or one of the maneuver node tools.

KSP2 seems to calculate the resultant orbit based on estimating the burn over time (which is much more realistic than stock KSP1, which assumes a simplistic instant acceleration applied at a point). So to get better circular orbits, you will have to add some radial component, either radial in or radial out, depending on your initial apoapsis altitude and whatever periapsis altitude you ended up with when you stopped your burn. The higher your initial Ap, the easier it is to get a good final orbit because it is likely to require less radial component to get close Ap and Pe values.

Among other things, I visited Dres. The visuals alone make this lonely dump-of-a-minor planet worth visiting now.

Even the rudimentary recording systems as it is currently implemented is … interesting. Most of my flights, after a safe recovery of the crew, show absurdly high maximum G forces. A standard orbital flight will almost always show about 138Gs. One was well over 1,000Gs. That alone to me indicates that there’s some seriously buggy physics math in the game someplace and probably also helps explain why ships fall apart, and phantom rotational forces causing ships to spin uncontrollably, etc. Assuming that data is valid, of course. Recording all that data in high fidelity tick-by-tick might be very useful for a development/debugging perspective but it will completely overwhelm local storage in all but the simplest save file.

If you’re running some idiotic forum joke, let it go. Dres has been in the game since 0.18 and I’ve visited it multiple times in KSP1. https://wiki.kerbalspaceprogram.com/wiki/Dres

LOLwhut? Dres has been in the game since the beginning. It’s got rings now, but it’s not a new planetary body.

Almost certainly no orchestra involved. Very likely the composer, a good set of DAW hardware and tracking software, and a bank of hardware and/or software instruments. But in any case, get to Duna. The music is fablulous. Conversely, the music in the Jool SOI is very plaintive, almost yearning. I wonder what that's all about?