Meta Jonez

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

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.

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.

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.

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.

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.

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? 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. 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.

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.

5 minute demo on issues with inclination change burns & associated maneuver nodes,

Excellent responses. Looks like @weeee is holding the current record at 1.6 KM/s. Fantastic ride!

Ditto. Renaming anything in tracking station only renames the KSC, even if I never select the KSC after entiering Tracking Station. Renaming doesn't survive leaving and re-entering tracking station. I have never seen the game rename what I had selected to the new name, or have that renaming stick.

@Socraticat That's a nice lookin' bird . . . good luck!

I flew a modified K2 remotely to the Arch on the Mun, landed. Empty lander, no Kerbals made the journey. I then went back to KSC, back into the VAB, and loaded an identical ship, but this one with Bill, Valentina, and Tim Kerman, and went to the Launchpad. Here I noticed I had picked Tim, and not Jebediah, so I reverted to the VAB to swap Tim for Jeb. In the VAB, Bill, Valentina, and Tim are not available. Bob has occupied the first seat. Ok, not the first time Kerbals have disappeared. I load Jebediah, Bob, and Nedwise into the lander and Launch. We make it to the Mun, and I manage a landing within 1.2Km of the remote piloted capsule. I then go back to tracking center and take command of a second remote ship, this one empty of Kerbals, piloted remotely and carrying a rover. I land this on the Mun as well, all within 1.5km of each other and the arch. I go back to KSC, Tracking Station (I do this often, as I have found there is a better chance of avoiding the bug where you jump from one ship to another ( [ , ] ) and one falls through the ground. I have experienced this once on the Mun post-patch.) Here in the Tracking station both landers and the rover lander are listed, but lo and behold, the remote piloted lander now contains Bill, Valentina, and Tim. I take command of both ships from the Tracking Station to verify. Yes, all six Kerbals are now on the Mun, fully functional. The K2 was heavily modified, using 4 Methalox boosters in place of SRBs, and changing how much fuel was in the various stages, as well as sepratrons, parachutes for the booster stages, ladders, moved antenna, removed RCS. I put the small size Remote Guidance in between the capsule's parachute and capsule body. I don't think this bug has anything to do with the ship, but rather that the game felt it necessary for some reason to fill those seats in the remote Mun lander, and used the first Kerbals out of the VAB to do it. MB: Asus Prime z270-K CPU: Intel i7-7700K @4.2GHz Sys RAM: 32GB Gr Card: Nvidia GeForce RTX 2080 8GB

Trying to launch a rover to the Mun. Buggy as so many of these parts are, it has taken many many tries and rebuilds. Every @#$%$*#@(* time I revert back to the VAB, it puts Kerbals back in the rover seats, and half the time I do not catch it because I have a fairing on the lander part of the rocket. Isn't the revert supposed to revert to the ship as it was the moment I pressed the "Launch" button? If so, once I remove a Kerbal from those command seats ("Grumble" Seats) and go to launch, if I revert to the VAB I SHOULD NEVER HAVE KERBALS IN THOSE SEATS, unless I put them back in there manually.. Thank you.

486 m/s