KUAR

For my money, the most useful/interesting IG content tends to be (in decreasing order): - Patch Notes - Bug status reporting and patch Predictions - Longer term dev work and roadmap development - Dev diaries for either of the above (far more interesting to have a deep dive but it takes more effort to create so typically covers less ground. Still more please if someone has the capacity and something really interesting to talk about) - Challenges and Community Highlights vaguely entertaining but I don't have much free time to engage with them ATM) - AMA (tend to be a bit short on new information)

Yeah, my KSP log was only 2-300 hours (albeit over a short timeframe!) so fewer learned behaviours to shake. Sorry about my insufferable pedantry, I think I knew full well what you were on about.

Thanks for making that clearer. I'm not surprised that I assumed the trigonometric definition over the geometric - one is useful in the physics I studied, the other less so! I do see how you're defining it and why it's conceptually useful. However... I'm going to get a bit picky though as I fear you're playing a bit fast and loose with dimensions. We should remember that the DeltaV is a change in velocity whereas an orbit describes an object's position and so one is a derivative of the other, not a component of. They aren't defined in the same space. So, the normal relations between a conic section and its secant don't apply. In that sense, while one can claim that the desired change in velocity is parallel to the prograde vector at periapsis, it makes no physical sense to claim that it is a vector which intersects an orbit. A velocity vector has no spatial position, no start point or end point. It's apples to oranges.

It was something I noted (and appreciated) in KSP2 that RTGs do now have a lifespan, albeit I don't think with an exponential decay. It is the case, albeit with continuous output up to such a date.

I have to ask...when you and Herbal are talking about the secant, of which angle are you talking and to what value are you ascribing it as a multiplier? I do generally get trigonometry (studied crazy amounts of maths for a physics degree) and can apply it to circular motion here when I think about it. But you're clearly using it as shorthand here for a more complete expression.

I really like this analysis. The time delay of science labs, ISRU, etc. was only a problem in as much as you needed to start and stop a time warp. There was no constraint over the amount of time one could spend on the surface of a planet, or in transit to/from it. Perhaps one way to introduce some temporal jeopardy is in Science/Career Mode, to have a time limit on certain missions by which point the scientific benefit available to be reaped starts to diminish? Or - for interstellar - perhaps the transfer windows are so rare that there's an imperative to get to a point where you can exploit it? I'm really not sure how I feel about an overall time pressure though that isn't a take-it-or-leave-it challenge. Perhaps something should be swept up in optional difficulty modes.

Thirded

Can you get a video of your issue? There are one or two features of the VAB which aren't always intuitive, but aren't exactly bugs either. I suspect something along those lines.

I do appreciate what you're saying. It's definitely how it's set up though. Next time you're in it, check the orbital lines closely. There are three parts to your trajectory when you plan - one old orbit, one predicted orbit, and one non-conic trajectory which represents your predicted path under acceleration. I think it adds more benefits than drawbacks personally but I see your point about periapsis burns. As long as you keep the burn time short with respect to the orbital period, it shouldn't be a real issue - and if the burn time isn't short, then you'll have inefficiencies no matter which planning style is used. However if I were worried about it then I could plan an ideal periapsis kick by aiming to keep the new periapsis at roughly the same position as the old one. Alternatively I could set the node to start on the Pe, see how long it is, and bring it back by that many seconds using the Manoeuvre Node Planner mod. I think we'd have found the drawbacks of symmetric nodes an issue when it comes to interstellar engines and the new properly scaled Xenon engine though

No, not true. The two games have literally defined what the nodes mean differently. It was the first thing I noticed when planning nodes in KSP2.

I thought the change was clear but it is how it's designed to work, even if it's got some bugs still in it (I don't particularly like the burn time countdown and preferred the dV remaining indicator of KSP1). In KSP2 you are absolutely supposed to start directly on the node, it's for logically sound reasons. The two versions are designed quite differently with regards to manoeuvre nodes. In KSP1 the program assumes that you carry out the burn and change your velocity instantly. Therefore, it's mathematically impossible to perfectly execute it but in most cases it's a sufficiently good approximation to start the burn a half duration before the node. If the duration is small compared with the orbital duration, it's not an issue. But escaping from LKO with a Xenon engine for instance would lead to a very different trajectory. In KSP2 it tries to factor in the duration of the burn as well as the velocity vector change to give a more accurate prediction. The most intuitive way to plan this therefore is to specify the START of the burn time. Perhaps this is important for future interstellar engines which might have crazy long burn times. OK so there's still issues - it's difficult to precisely execute a normal burn without numbers to go off, there are bugs in it, it doesn't factor in staging I suspect, and you can't specify a variable heading for your burn which is dead useful on big inclination changes for instance or long gravity well climbs. But I can see why the philosophy has changed and agree with it.

One issue with that is that multi-point attachment wasn't (until recently) routinely supported. In all decouplers currently, there is a single node which is just stiffer if the decoupler is bigger. The apparent visual size increase is just cosmetic. Multi-point attachment was recently bespoke to the craft, as in struts or autostrut. Nonetheless the recent change to multi-point attachment for procedural wings may be applicable?

I'm one of those 300. Right now, I've got weak-ish hardware, so am very slow anywhere near the surface, and am also suffering from bugs like everyone else. I also regret the paucity of parts and the fact that the UI seems less capable than even vanilla KSP 1.12.5 I think I play it partly out of stubbornness, partly out of loyalty, partly out of curiosity, and partly because I'm not sure I could go back to having non-procedural wings (I know there's mods). I only play an hour or so per day on average, possibly less. I certainly used to put far more time into KSP1. I've got hope that it will continue to develop. I choose to believe the developers when they claim to be working on long-term improvements as well as the immediate bug-fixes, so perhaps the perceived rate of change will increase when the base engine is stabilised. But there's no denying that to me it's a lot less fun than KSP1 at the moment. I'm just not very good at going backwards, that's all.

It's literally at the top of this very page...is it not there for you?

If you're not already aware, pressing CAPS LOCK limits the deflection of the control surfaces to an extent better suited to planes rather than rockets. It's not exactly what you're after, but it may help.

I agree, it'd be good

I thought that was only in the VAB?

There's loads of good Youtube videos out there. In KSP2 a basic plane (as opposed to an SSTO) is fairly straightforward. Common mistakes: - Not paying attention to Centre of Mass vs Centre of Lift. The CL should be maybe 5% back from the CM (give or take a fair bit for taste). - Wheels too far back / too far apart / trying to control direction. Deactivate steering in Parts Action Window and make sure the rear wheels are not too far back from the CM. A set of wheels under the cockpit and a set under each wing. - Turn SAS off if you're getting runaway corrections! - Having too much control surface / wrong configuration. A basic setup for a fast jet would be canards dedicated to pitch; ailerons dedicated to roll; and a rudder dedicated to yaw. You can limit what axis each control surface works in via the PAW. - Controlling it like a spaceship. Control it like a plane - to turn, first roll then pitch up a bit. - Not understanding the fine controls required for flight. If you press CAPS LOCK, it reduces the deflection of control surfaces so it's a bit more manageable at high speed; and if you hold ALT while pitching up/down it adjusts the default trim. I think that's the first set of bug-fixes but I'd be happy to have a look at a craft of yours if you want to upload it somewhere!

I understand that they are in the process of literally replacing some key parts of the engine with v0.2.x I'm not sure of the extent of it but I do hold out hope that there's a plan there. Glass half full!

They're making steady progress. I'm giving them the benefit of the doubt for a bit longer. But, yes, my last two missions have ended exactly like you describe there with those two bugs. Really frustrating.

@Anth12 another merge with this I suspect

This would also achieve a good reduction in CPU load I reckon and would satisfy most users. Wing attachments should probably flex and perhaps also where node attachments are mismatched or something like that. For inline parts, stress should cause connections to fail rather than flex in my humble opinion. Not a fully fleshed out answer I'm afraid, but part of one! I bet that some enterprising people would find a way to turn this paradigm (some parts simulate flex and others don't) into a kraken drive or something but I reckon that figuring how to exploit systems, then deciding if you want to use the exploit or not, is part of the KSP DNA. It's engineering, just a discipline that doesn't exist IRL. You could put huge effort in to eliminate all exploit possibilities but somebody will always find a way to beat it, and if they can't somebody will mod to enable it.

Foolproof steps, works despite bugs. This isn't necessarily the most efficient, but it'll work. Get to orbit. Ensure orbit is circular. To achieve this, warp to periapsis; face prograde; and burn until Pe/Ap are equal. Ensure orbit is co-planar with the Mun. To achieve this: Right click on Mun and "set as target". Warp to AN/DN. These are your ascending or descending nodes. Turn Normal (if DN) or Anti-Normal (if AN). Burn until inclination equals zero. At any point on the orbit, create a new manoeuvre node. Drag the prograde icon until your predicted Apoapsis is at or just beyond the Mun's orbit. It should take about 850 m/s of dV, give or take a couple of dozen. It's possible but unlikely that you'll get an intercept from wherever you first plonk your node; if so, great. If not, grab the manoeuvre node by the central ball and drag it around the orbit until you get an intercept. Do your best to tweak it so that the course change when you get to the Mun is as sharp as possible - that's a good indicator that you've got a close encounter. You can also look at the numbers but I won't go into that now. Carry out the burn. Get to the node, point prograde, and burn until your actual orbital line matches up with the predicted line. I don't trust the KSP2 burn indicator at the moment, too many bugs. You should now be on an intercept trajectory. Perform a mid-course correction. Warp to halfway or 2/3 of the way to the Mun. You'll probably be on some wacky trajectory when you get there - you can right click on the Mun and "Focus" if you want to see. Create a new node a little ahead of your craft and play with the sliders. This is your chance to learn how adjustments affect orbits so I won't go into detail - trial and error! You want to get a fairly close approach to the back side of the Mun (especially if you want to land) so you can end up in an anti-clockwise orbit (when viewed from the North pole). When you get into the Mun's SOI, you can start planning your capture burn. At or near Periapsis, plan and execute a retrograde burn until you're in an orbit. Once you're in orbit you're safe and can start tweaking it to get it equatorial/polar as you wish, or circularise, or start planning your landing. Note on circularising & plane adjustments. When I say "warp to", actually you want to come out just before. This is so that first, you can point in the right direction before needing to start your burn; and also so that you can start your burn just before. When burning, watch the node (Pe/Ap/AN/DN whatever) and if it's becoming further away, slow down/stop your burn; if it's getting closer, speed up your burn. The aim is to stop your burn when you get to the node's position. A bit of trial and error will help you to understand the concept here.

I'm not sure where you're looking. However, one possible source of 0.1x errors to keep an eye out for when you go to (university?) next year is when using kilograms for mass and Newtons for force. 1 kg under 1 Newton accelerates at 0.1g, or ~1m/s2. I hope you enjoy your studies, I'm a physics grad and really enjoyed it. Steer clear of condensed matter/crystals though - at least if you're like me! I enjoyed astrophysics so much more (probably because you normally only have to integrate in one dimension rather than three

There's a space for suggestions/bug reports here.