What we wanted vs. what we got: Did anyone at Intercept actually play KSP 1?

[Meta Jonez]

It's great that KSP 2 looks and sounds as it does.  I just don't recall "Better graphics" and "Better sound" being at the top of anyone's list of things they wanted out of KSP2.  I recall, in varying orders, the top three were Colonies, Interstellar, and Multiplayer.  But I also recall, above all of these, was a desire for a clean codebase from which to build all these other new features.

KSP1, for all it's wonder and brilliance, had it's coding issues.  The game was built by people unfamiliar with the underlying organization needed to develop a game.  The code was written by a handful of people, all of whom came and went between it's inception and it's sale to TakeTwo, and documentation of that code at times left something to be desired.  The end result was bug-prone, at times unstable, and containing "quirks" in gameplay that were a result of nothing other than bits of code not playing well together; bits of code that were never going to play well together.

The prime hope of the KSP community was that KSP2 would be that clean codebase.  KSP2 would be a strong, solid foundation built by people familiar with both Kerbal Space Program  and game development protocols from the start, and that codebase would support (without the use of mods to "fix" things) that aforementioned list of desires.

Now, I should preface this by saying I do not write code.  I am not a programmer, and my deepest interaction with mods was changing a specific parameter, in a specific document, for a specific result, all under the guidance of the mod writer.  So, I cannot point to anything specific in KSP2 as evidence of poor coding, as I do not know enough to know if I am seeing things that need to be "tweaked" or refined, or if the underlying code is fundamentally flawed.

Having said that, I recall the release of No Man's Sky.  Here was a game that promised a universe of things to do and places to go, and delivered one of the most empty, mind-numbingly boring experiences gaming had to offer.

But what was there worked, and as time went on it became clear that those things worked very well, and the initial release was a strong and powerful base for what became the Cinderella Story of gaming: Nineteen major updates that added a wealth of ships, base-building, multiplayer, an explosion of flora and fauna, and many other features, both new and originally promised by the developer.

I don't see that strong codebase in KSP2.  What we have doesn't work well.  Some of the issues players encounter have an eerie similarity to the spaghetti-coded KSP1.  Like many players, I would have been thrilled with a release that offered nothing but Kerbin and the Mun, a handful of parts to get there, and a flawless implementation of basic KSP gameplay.  What we have, after 100+ hours in the game, appears to me like a lot of pretty that is varnishing over a quagmire of coding.  Knowing something of the game's development (see reddit user jxjq's excellent post for more on this: KSP vs KSP2: an ugly development history), I would not be surprised if this assessment proves correct.

I have also yet to see a post from anyone, on either Reddit or the KSP forums, who both codes for a living and believes we have a strong codebase with KSP2. I thought reddit user SpikeViper in particular illustrated well what he saw from the game in his reddit post: Outlook from a developer

In addition, in so many aspects of KSP2, the developers seemed bent on re-inventing the wheel, and producing something less than what we had in KSP1.  For all it's coding issues, there was a great deal that KSP1 got exactly right.  

There are decisions made here that makes me wonder if anyone working on KSP2 ever played KSP1.  If they had, they would know that the Burn Timer ought to include Dv and time to burn calculation that are dependent on the actual burn taking place, rather than one that just assumes I'm doing what it tells me to do;  it is not enough to just show me a burn bar moving from right to left, or a timer ticking down. They would know this WYSIWYG approach to the maneuver nodes is substandard to placing the node at a point and straddling that point with the burn.  They would know that the average KSP player is not going to "trust" the game and want to be far more precise in the time, direction, and duration of the burn than KSP2 will allow (or is even capable of?  I can't help but wonder.) The Burn Timer, and the placement and use of Maneuver nodes, in their present state, are both absurd.  

They would know that the visual cues in moving stages and stage components around in KSP2 are clearly substandard to that of KSP1.  They would know that pinning the little boxes they put around Apoapsis and Periapsis readings get in the way of needed information and UI on the map screen.  In contrast, KSP1 APO and PERI readings simply became transparent but readable if pinned, and did not interfere with other information on the screen.  

They would know that there was literally nothing to be gained by changing the camera controls in the VAB.  They would know exactly how irritating it is when the game keeps resetting your VAB camera.  They would know this whole "Workspace/Shipname" gimmick in the ship saving interface is actually a pain in the ass:  If I cannot save multiple ships under one workspace, what the hell is the point?  They would know that auto-populating the description with "Autosaved blahblahblah" also serves to further complicate things when trying to retrieve a saved ship.

They would know that we like and have a vested interest in the fate of our Kerbals, and don't care for them disappearing without explanation after a mission.

They would know the fonts they used look like they were lifted directly from the 1978 cabinet game Space Invaders, and that their map icons are similarly retro-looking, and that both detract from the game's supposed polish.

They would know that the tutorials, while overly verbose and not voiced in KSP1, were organized in a way that made sense and gave a wealth necessary of information to the player.  The KSP2 tutorials, while nicely polished, seem haphazardly organized and often information left out of the tutorials seemed to be left out because the game is incapable of letting the player make use of that info.  The whole thing seems dumbed down.  

I am reminded of the moment it dawned on me that the second Star Wars trilogy was not for me: it was written and directed for a different audience, with different goals (can you say merchandising?) in mind than the first three movies.  Is this what is happening with KSP?  Are we getting a game where, if you just do what the game tells you to, burn when it says burn, don't worry yourself with Dv calculations or useful tools like a precision node editor or fuel management, you get to land on the Mun and learn absolutely nothing?  Is Intercept hoping for a larger audience with a dumber product?

As I said, I've got a little over 100 hours in KSP2.  In KSP1 I've got over 900 hours registered through playing from Steam, and probably another 1500 in game time spread out over various mod implementations and pre-release versions.  I started with v 0.19.0 in 2013.  In it's current state, it is difficult to imagine I will get the same enjoyment out of KSP2.  I hope I am wrong.  I really do.

Edited March 25, 2023 by Meta Jonez
spelling

[Racster]

Totally agree with Mete Jones post.  KSP 2  just isn't as good as KSP 1 in so many respects. The UI has the look and feel of  something from  '80s console games.  It's difficult to use compared to the original and nothing extra  by way of compensation.     True the planetary rendering is very pretty, but sacrificing the KSP 1 manoeuvre / navigation and control  system isn't a price worth paying.

[kspnerd122]

I have to Agree, It does feel like they dumbed down the game to appeal to children, while also alienating veteran players in the process, I would have been perfectly fine with all the new promised features and visuals comparable to KSP1, but they literally went for visuals first before playable content and bug fixes.

[Bej Kerman]

19 hours ago, Meta Jonez said:

They would know that there was literally nothing to be gained by changing the camera controls in the VAB.  They would know exactly how irritating it is when the game keeps resetting your VAB camera.  They would know this whole "Workspace/Shipname" gimmick in the ship saving interface is actually a pain in the ass:  If I cannot save multiple ships under one workspace, what the hell is the point?  They would know that auto-populating the description with "Autosaved blahblahblah" also serves to further complicate things when trying to retrieve a saved ship.

I've heard complaints about the camera system from people who didn't realise MMB centered you on parts and people who weren't able to wrap their heads around how to save multiple vehicles, but so far I and others have only had nice things to say about it. Being able to keep progress on something like a space station in one save is nice and I'm not sure why you only have bad things to say about what's a massive improvement over KSP 1's clunky system, simply because of a few nitpicks you have. Making a mountain out of a molehill, perhaps?

19 hours ago, Meta Jonez said:

There are decisions made here that makes me wonder if anyone working on KSP2 ever played KSP1.  If they had, they would know that the Burn Timer ought to include Dv and time to burn calculation that are dependent on the actual burn taking place, rather than one that just assumes I'm doing what it tells me to do;  it is not enough to just show me a burn bar moving from right to left, or a timer ticking down. They would know this WYSIWYG approach to the maneuver nodes is substandard to placing the node at a point and straddling that point with the burn.  They would know that the average KSP player is not going to "trust" the game and want to be far more precise in the time, direction, and duration of the burn than KSP2 will allow (or is even capable of?  I can't help but wonder.) The Burn Timer, and the placement and use of Maneuver nodes, in their present state, are both absurd.  

I don't recall KSP 1 being this precise. I got told "why are you trying to do low orbit burns with low TWR engines?" rather than "Yeah, why were burns that are possible with low TWR engines not allowed by the old maneuver plotter?".

[Bej Kerman]

12 minutes ago, kspnerd122 said:

It does feel like they dumbed down the game to appeal to children

Making high ISP engines run off fuel types with a density that's closer to their real values? Properly permitting low TWR maneuvers? I don't see anything being dumbed down.

[Meta Jonez]

3 hours ago, Bej Kerman said:

I've heard complaints about the camera system from people who didn't realise MMB centered you on parts 

I went through the tutorial.  I do realize this.  But what good is being able to center on a part if the camera resets to default as soon as you try to move the camera around that part?

3 hours ago, Bej Kerman said:

and people who weren't able to wrap their heads around how to save multiple vehicles

The only way I've been able to save separate vehicles is by changing both workspace and craft name.  If I save a craft under the same workspace name as another craft, or a previous build of that craft, or as an addition to that craft, the original gets replaced, and only if I dig through autosaves of that craft might I be able to find the overwritten craft.

Indeed, if it is something complicated enough that people need "wrap their heads around it", then maybe a tutorial on the save system is in order.

3 hours ago, Bej Kerman said:

I don't recall KSP 1 being this precise. I got told "why are you trying to do low orbit burns with low TWR engines?" rather than "Yeah, why were burns that are possible with low TWR engines not allowed by the old maneuver plotter?".

In KSP 1 I can reliably create a Maneuver node and then burn it in it's entirety from the ship screen (as opposed to map screen) and it will be accurate.  In KSP2 I have to eyeball it on the map, because thus far, too often the resulting burn is not accurate without doing so.  There is just too little info displayed in the burn timer, and the orbits outside of time warp, at present are too unstable to dependably do otherwise.

In my experience, each person has their own mountains and molehills to deal with, and no two people are going to agree on which one a particular problem might be.  From where I stand, the re-invention (to the detriment of gameplay, IMO) of some of these game subsystems was needless and done in a way that offers less to the player than KSP1.

Edited March 26, 2023 by Meta Jonez

[Bej Kerman]

53 minutes ago, Meta Jonez said:

I went through the tutorial.  I do realize this.  But what good is being able to center on a part if the camera resets to default as soon as you try to move the camera around that part?

Eh? That's not intended behaviour. The camera works fine on my end and only centers in some edge cases.

53 minutes ago, Meta Jonez said:

The only way I've been able to save separate vehicles is by changing both workspace and craft name.  If I save a craft under the same workspace name as another craft, or a previous build of that craft, or as an addition to that craft, the original gets replaced, and only if I dig through autosaves of that craft might I be able to find the overwritten craft.

The game overwrites workspace A if you give workspace B the same name. I'm not seeing how this doesn't make sense. You just put down another pod in workspace B to add another vessel, you don't need to try giving two workspaces the same name. I get it might not be intuitive with how some things are labelled but I have no idea where people got the idea of overwriting workspaces to merge them.

53 minutes ago, Meta Jonez said:

In KSP 1 I can reliably create a Maneuver node and then burn it in it's entirety from the ship screen (as opposed to map screen) and it will be accurate.  In KSP2 I have to eyeball it on the map, because thus far, too often the resulting burn is not accurate without doing so.  There is just too little info displayed in the burn timer, and the orbits outside of time warp, at present are too unstable to dependably do otherwise.

Okay, yeah, I am really not seeing your angle because the KSP 1 planner was not in the least bit accurate for anything but vessels with enough thrust to approximate impulse maneuvers. The KSP 1 maneuver node did not account for thrust at all which is a terrible idea when you have both gravity and thrust enacting on your ship. You try to do a low TWR capture burn centered at 100,000m, but it sends you into the atmosphere because the game had the brilliant idea of you doing half the burn before the maneuver, lowering your periapsis. This makes little sense. The KSP 2 maneuver planner does take into account thrust - people have only had issues with the node indicator moving during the burn and throwing them off, but as long as you lock your vessel's heading before doing your burn using SAS or timewarp, you'll land pretty much where it said you'll land. I cannot say anything alike with KSP 1 which gives you an impulsive approximation and tells you to work around it with "start the burn at 50% the burn time before the node encounter" and all that. If KSP 1's planner is proving at all accurate for you, all I can say if that either you're not using the sorts of low-TWR vessels the new maneuver node is aimed at or you're simply so used to dealing with its inaccuracies that your brain does not instantly recall the times it's screwed missions over before.

[Meta Jonez]

In my experience with workspaces, as it were, a workspace is a container of sorts for any or all parts of a project.  I was expecting to be able to save Section A under Workspace01, Section B under Workspace01, Section C, etc. , and then be able to load all or some or one section under that workspace. Or Ship1 MkI, Ship1 MkII, etc, under Workspace Ship1, and be able to load different versions I've built of the same ship into their shared workspace for comparison, evaluation of changes made, etc.  Then I can see or work on all or some or one of those sections or ships.

In KSP1, I would name ships Shipname Mk I, Shipname Mk II, Shipname Mk III. to denote versions of the same ship.  Or StationPowerSec, SationHabSec, StationDockSec, for station sections.  I could see ships that belonged to the same class (based on what I named them), I could save sections of space stations as either subassemblies or separate ships, and merge them either way.

I can do this in KSP2, of course, but I have to fill out both workspace and shipname with the name for it to save.

It is certainly possible I am missing something with "Workspaces" in KSP2, but it doesn't seem to bring any additional functionality to the way I was saving ships, versions of ships, or ship/station sections in KSP1.

[Buzz313th]

Sounds to me like Bej knows his excrementse.  

 

[uglyduckling81]

KSP 2 is a disaster currently. Will it ever be fixed? I'm unsure. I'm glad I held off buying though. 

What I will say is KSP is still available to play, has thousands of mods to change any aspect of the game. Just go back to it and revisit KSP2 for a quick look each time a patch releases.

I've got a bunch of visual mods on currently. The game looks incredible.

[Bej Kerman]

12 hours ago, Meta Jonez said:

In my experience with workspaces, as it were, a workspace is a container of sorts for any or all parts of a project.  I was expecting to be able to save Section A under Workspace01, Section B under Workspace01, Section C, etc. , and then be able to load all or some or one section under that workspace. Or Ship1 MkI, Ship1 MkII, etc, under Workspace Ship1, and be able to load different versions I've built of the same ship into their shared workspace for comparison, evaluation of changes made, etc.  Then I can see or work on all or some or one of those sections or ships.

That doesn't make sense to me. Sounds like you're treating workspaces like folders rather than files.

12 hours ago, Meta Jonez said:

It is certainly possible I am missing something with "Workspaces" in KSP2, but it doesn't seem to bring any additional functionality to the way I was saving ships, versions of ships, or ship/station sections in KSP1.

In KSP 1, you couldn't drop a part next to your ship and start building a new vessel from that part within the same space. That's how you utilize KSP 2's system, it lets you drop parts without it going gray and the camera system has also been revamped to suit. KSP 1 forced you to put everything in different spaces. KSP 2 lets me build all my vessels relevant to mission X without saving a billion vessel files for the most inconsequential mission components. My tiny resource scanner probe doesn't need its own space, it can be put in the same space as the mothership.

10 hours ago, Buzz313th said:

Sounds to me like Bej knows his excrementse.  

I am not a he. But your compliment is noted.

[Kerbart]

Some of the concerns are legit, but the plea gets watered down by listing known bugs. For instance, Kerbals disappearing after a mission will be addressed in upcoming patch 2. Some of the decisions are clearly in the "I don't like it, so it's bad" category. You're in mission control, you're staring at a mission control monitor. A 1978 Space Invaders font and primitive icons emphasizes that feeling, a retina Calibri font does not. That's a styling choice. Perhaps we get skins in the future where you can  specify that, but I doubt it's "generally" considered a bad font choice.

There are also a slew of things that are attempts to improve the interface, or at the very least take a fresh look at things, The burn indicator is one of those things, very deliberately moved away from the navball (remember there are plenty comments "the navball is too busy"). Yes, there's information missing, and that's valuable feedback.

Be very careful stating "KSP2 is bad because it's not KSP1," which is, maybe unintentional, the tone of your post. Yes, that's the point. At least you're not making the mistake of saying that features are "not intuitive" — usually only for KSP1 players who have hundreds, if not thousands of hours under their belt. In the same sense. a tutorial that spends more time on "basics" is not "dumbed down," it's doing something that wasn't there in KSP1; showing a bit more of the why instead of just how.

That isn't to say that the game is perfect. It's Early Access, and to be honest, in a disappointing state. But things are not different because the dev team isn't aware of KSP1, I'd say it's the opposite. They are very aware of it, and trying out new things to improve the game, especially for those who never played it before.

There's two approaches to this subject. One is what you chose to, a emotional plea with many stylistic constructs that "scores points" with the audience that doesn't like KSP2. Like listing things that are known bugs, or known to be slated for improvement. And that's choice everyone is free to make. Another approach is a constructive approach, listing what was changed, how it worked originally, why the change doesn't work and how to improve it. And skip the known bugs, especially when you know they're being addressed in the upcoming  patch. What's the point of saying "hey devs, X doesn't work" when they clearly  know X doesn't work?

[Meta Jonez]

I'm not looking to score points (with whom?).   I'm not driving any bandwagon and could not care less if anyone but the devs read my post.  I am well aware that devs are very aware of KSP1, I was trying to make a point.  That awareness, in KSP2's current state, isn't all that evident to me.  Maybe we are talking a difference of style or taste as opposed to substance.  For me, primitive icons and fonts don't scream "Mission Control Monitor".  They scream "unfinished title with placeholder fonts and icons".  With this last patch they fixed the ability to pin Apoapsis and Periapsis info in the map.  Yet when I play, I can't help but wonder, in arriving at that solution, did no one notice the resulting boxes cover up needed information?  How could you not notice?  I am not saying KSP2 is bad because it is not KSP1.  I am saying that, while KSP1 had it's issues, there was a good deal that KSP got right, and a fair amount of that, from my perspective, seems to have been changed for change's sake alone.

I am aware that you can build multiple ships in one workspace.  I am still not getting why I have to save a ship or workspace or whatever you want to call it under two names, when one would suffice.

As for the maneuver nodes, Bej Kerman is right, you could not do low orbit, low-TWR burns in KSP1 for the exact reason he stated.  I avoided them like the plague in KSP1 for that reason, and frankly it didn't even occur to me to try in KSP2.  What I have tried to do is a simple inclination change to an orbit around the Mun, and following the KSP2 maneuver node target and burn timer has repeatedly left me with a trajectory right into the Mun's surface.

As for my tone, If we all approached the world the same way, it would be a boring place.  I wasn't disrespectful or rude.   You do you, and I'll do me.

[Bej Kerman]

5 minutes ago, Meta Jonez said:

They scream "unfinished title with placeholder fonts and icons"

again not seeing the angle here. Blender's default typeface is what screams "unfinished" to me, not a pixelated font designed/picked specifically for a game.

5 minutes ago, Meta Jonez said:

I am aware that you can build multiple ships in one workspace.  I am still not getting why I have to save a ship or workspace or whatever you want to call it under two names, when one would suffice.

Me neither, the naming scheme is a bit weird, but to try overwriting workspaces to merge them is a bit of a leap in logic for me. I still have trouble seeing it as anything but a vast improvement over KSP 1's editor seeing as dropped parts branch off into new vessels rather than turning gray.

5 minutes ago, Meta Jonez said:

As for the maneuver nodes, Bej Kerman is right, you could not do low orbit, low-TWR burns in KSP1 for the exact reason he stated.  I avoided them like the plague in KSP1 for that reason, and frankly it didn't even occur to me to try in KSP2.  What I have tried to do is a simple inclination change to an orbit around the Mun, and following the KSP2 maneuver node target and burn timer has repeatedly left me with a trajectory right into the Mun's surface.

I am not a he and stop using gendered language for people you don't know please I note you said you "followed the maneuver node target". The maneuver node drifts - if you want to follow the maneuver exactly, you want to set SAS to stabilise or enter timewarp for the duration of the burn or the maneuver will drift off where the non-impulsive plotter expected you to burn. I hope this helps.

Edited March 27, 2023 by Bej Kerman

[Meta Jonez]

5 minutes ago, Bej Kerman said:

again not seeing the angle here. Blender's default typeface is what screams "unfinished" to me, not a pixelated font designed/picked specifically for a game.

Me neither, the naming scheme is a bit weird, but to try overwriting workspaces to merge them is a bit of a leap in logic for me. I still have trouble seeing it as anything but a vast improvement over KSP 1's editor seeing as dropped parts branch off into new vessels rather than turning gray.

I am not a he and stop using gendered language for people you don't know please I note you said you "followed the maneuver node target". The maneuver node drifts - if you want to follow the maneuver exactly, you want to set SAS to stabilise or enter timewarp for the duration of the burn or the maneuver will drift off where the non-impulsive plotter expected you to burn. I hope this helps.

So you are saying, rather than setting the SAS to the maneuver node target, I should click on the SAS "lock" icon (for lack of a better name) before starting the burn?

In KSP1, in an inclination burn (particularly one made to maintain altitude) the maneuver node target usually drifted between splitting , for example, Retrograde and Normal, to splitting Prograde and Normal during the burn, and if you set your SAS to track the maneuver node target, it would do that.  What I am seeing in KSP2 - the only node drift I see happens when you set a maneuver node on an orbit that is unstable - by the time you get to the node, it sits separate from the orbit line.  In the described inclination change, the orbit was stable,  and in KSP2 the maneuver target hardly moves at all - certainly not the extent it should.   And the end result is almost invariably that the burn didn't get anywhere near the amount of pro/retro needed to maintain altitude and change inclination.  

 

I posted a video on this:  

If I am doing something wrong, I'd love to know what it is.

My apologies for the misgendering.

[Bej Kerman]

5 minutes ago, Meta Jonez said:

So you are saying, rather than setting the SAS to the maneuver node target, I should click on the SAS "lock" icon (for lack of a better name) before starting the burn?

Yes - this puts your vessel on the vector the planner is expecting. Even better if you use time warp, which completely eliminates any extra wiggling your vessel does. Just do this and you should no longer run into massive issues with maneuver drift.

7 minutes ago, Meta Jonez said:

My apologies for the misgendering.

Just as long as you keep this in mind

[Meta Jonez]

1 minute ago, Bej Kerman said:

Yes - this puts your vessel on the vector the planner is expecting. Even better if you use time warp, which completely eliminates any extra wiggling your vessel does. Just do this and you should no longer run into massive issues with maneuver drift.

Just as long as you keep this in mind

If this is how it works-I will test this out today- it is beyond me how this makes any sense.  Isn't the Maneuver Node target (just to be clear, I am not talking about Target itself, i.e. a moon I have selected, for instance), supposed to orient the craft in the direction of the burn?  Is that something different from  putting "your vessel on the vector the planner is expecting", because I'm reading as being the same thing. 

[Bej Kerman]

3 minutes ago, Meta Jonez said:

14 minutes ago, Bej Kerman said:

Yes - this puts your vessel on the vector the planner is expecting. Even better if you use time warp, which completely eliminates any extra wiggling your vessel does. Just do this and you should no longer run into massive issues with maneuver drift.

Just as long as you keep this in mind

If this is how it works-I will test this out today- it is beyond me how this makes any sense.  Isn't the Maneuver Node target (just to be clear, I am not talking about Target itself, i.e. a moon I have selected, for instance), supposed to orient the craft in the direction of the burn?  Is that something different from  putting "your vessel on the vector the planner is expecting", because I'm reading as being the same thing. 

The plotter assumes the vessel does not rotate at all during the burn but the maneuver marker moves anyway - KSP 1's marker drifted to compensate for any deviations but the KSP 2 marker doesn't need to do that. Bit weird but really it's an issue with the navball, not the plotter as most people usually blame it on that.

Edited March 27, 2023 by Bej Kerman

[Meta Jonez]

I just tested this.  You are correct in it's behavior.   So it looks like the navball orientation is governing the burn, rather than the burn governing the orientation of the navball.  In KSP1, in an inclination burn, it wasn't the MN target that drifted.  It was the Normal or Antinormal moving from one side of the maneuver node target to the other, as that is the axis I was changing.  What I see happening in KSP2 is, by choosing MN target instead of stabilize, it is rotating the craft to throughout the burn insure that the MN node's orientation to the N/AN  on the navball  doesn't change.

 

 . . . this is considered a bug, yes?  I may have missed it because, as you said, what I assumed was that the inputs I was giving to the Maneuver node were not being correctly calculated when figuring out what that meant in terms of either Dv or orientation of MN target.

Edited March 27, 2023 by Meta Jonez

[Meta Jonez]

1 hour ago, Bej Kerman said:

Me neither, the naming scheme is a bit weird, but to try overwriting workspaces to merge them is a bit of a leap in logic for me.

I was not thinking of Workspaces as folders but more like an Excel file, with different ships being different sheets.

Edited March 27, 2023 by Meta Jonez
clarity

[Sea_Kerman]

it would be cool if the maneuver target did move... in order to recorrect you back to the maneuver trajectory, like so

[Little 908]

13 minutes ago, Sea_Kerman said:

it would be cool if the maneuver target did move... in order to recorrect you back to the maneuver trajectory, like so

I agree, that would be an interesting feature

[rjbvre]

12 hours ago, Sea_Kerman said:

it would be cool if the maneuver target did move... in order to recorrect you back to the maneuver trajectory, like so

It's a neat idea, but wouldn't work in practice. You'd have to correct both your position and trajectory which could cause some really janky changes in attitude, which would probably cause even more deviation that would have to be corrected. I did like the ksp1 system which corrected for just attitude deviation, and could be avoided by changing SAS to lock. Then just like in real life you'd have a correction burn at some point.

Not being able to correct things perfectly automatically is a pretty good incentive to design well balanced craft with the center of thrust going through the center of mass. Just another way carefully designed craft are more enjoyable to fly.

[Bej Kerman]

1 minute ago, rjbvre said:

You'd have to correct both your position and trajectory

Your trajectory describes your position...?

1 minute ago, rjbvre said:

which could cause some really janky changes in attitude

If a deviation can put you on trajectory X from Y, then a set of deviations can put you on trajectory Y from X. In fact, isn't this one of the principals of orbital mechanics?

I really don't see the "but wouldn't work in practice". There's nothing stopping the node from offsetting a bit to aim you at your expected position then aiming away from your expected position as you approach your intended trajectory in order to ease back into the planned burn.

[rjbvre]

1 hour ago, Bej Kerman said:

Your trajectory describes your position...?

Correct. I was trying to simplify so my wording was clumsy. You're on a new trajectory with different positions and momentum.  You need to correct both (technically time too).

1 hour ago, Bej Kerman said:

If a deviation can put you on trajectory X from Y, then a set of deviations can put you on trajectory Y from X. In fact, isn't this one of the principals of orbital mechanics?

I really don't see the "but wouldn't work in practice". There's nothing stopping the node from offsetting a bit to aim you at your expected position then aiming away from your expected position as you approach your intended trajectory in order to ease back into the planned burn.

This is mostly correct. Just remember that all those correction burns will have their own deviations which need to be corrected for since your craft can't fly straight. The biggest problem though is that you're asking your craft to perform quick 180 degree turns for some of the corrections. You would have to take into account how quickly your craft rotates, and how much more of a deviation you'll end up with since presumably the thruster is on during the rotation. Add to that the fact that trajectories include time, you'll also have to perform your corrections so that you're at the right position with the right momentum at the right time. And all of this would have to work with any ship design. Is this technically possible? Probably. But is sure as hell isn't practical.

Edited March 29, 2023 by rjbvre