Anth

These are somewhat complex calculations, and the one that will be on charge on fixing them would need to understand what the code should do, and then check what the code is doing instead. The code part is, indeed, not that hard - the worst part is to find where the problem is, and to do that, the dude would need to know the math needed and also the code. If this feature was working fine before, and suddenly stopped working, then one way out of the mess is to determine exactly the commit that got it screwed - access to the full history for the source code is, so, mandatory. A first step is to determine the very last public release with the feature working, and then walking up the commits from that point until it get screwed. Then a diff between the screwing commit and the previous one will fatally pinpoint the problem. Level of difficulty on the first method: hard . But it will probably be the faster one if you get capable workforce. Disclaimer: I'm not, I don't know all the math it's needed. Level of difficulty on the second, brute force method: trivial. But it will take a lot of man-hours - it's essentially a binary tree search where a node visit is a full compiling and then running the thing and look for the problem. This is what I would do, probably... Brute Force? The maneuver mode code is already connected to the already existing UI wouldn't take a lot of man hours to find. We aren't rebuilding the entire maneuver mode code to fix a tooltip issue or to change the first year and day from 0 to 1. It depends of how many people were working on the project at that time. Do you know the saying "9 pregnant women won't give you a baby a month for 9 months"? If you had a very few experts on the field, then they will probably get things right (or almost) at first time. The hard time is finding these huge experts on the field, then manage to lure them into working on a small software shop - no to mention having the money to pay the dudes. There's a reason you don't find NASA engineers working on small Marketing shops, right? But let's pretend for a moment that a NASA engineer decided to code KSP in 2012, instead of a crazy Brazilian dude that decided to go the masochist way : as soon as the game starts to get traction and the work starts to pile up beyound the capacity of the initial workforce, fatally new people will get hired to help them. And these people will not be NASA engineers, as these dudes are not easily available on the market. Now things start to get hairy, because the initial dude is not working on the code anymore, he's trying to teach the newcomers about how he had done things. Development slows for some time - what's rarely well received by whom is paying the extra money on the new hirings, they wants results faster. Probably some of the newcomers would be more experienced coders, but almost surely less experienced Space Engineers - and so, knowing most programmers of nowadays as I do, I'm pretty sure that old crappy code that was working fine were replaced by new, very well written code - but done by a dude that didn't know how to solve the problem himself and, so, will not realise when he/she does a mistake on the algorithm. (on a side note: I prefer to emphasise solid interfaces than solid code - give me solid interfaces, and the code crappyness is not a problem anymore, it can be replaced anytime without screwing up dependencies!) Now we have pressure to make things faster, as now the stakeholders are spending more money and they want the investment back as soon as possible (the dreadful "Time to Market" race). You have newcomers with more experience on coding replacing the "crappy code" but without enough knowledge about the problem being solved, and so without being aware of eventual mistakes being done. And new features being shoved on the backlog while the clock ticks. Do you get the picture? Having something done quickly and right is almost impossible unless you have top notch professionals all the way down. Given how KSP was incepted and how it was developed over time, I think it would be pretty hard to have things right at first. But once the team gets cohesion and motivation, they are able to rework the problems pretty fast after some time - as long they don't get burn on the process. "Cheap. Fast. Good. Pick two." Ok thats definitely more complicated than I expected. If it was me personally I would code/run/test, then see the result and then code/run/test again and again until its right. How can someone write some code and just expect it to work without testing it thoroughly? And we aren't talking about something complicated like robotics here. Its just a UI interface. Yes, but not a fatal one. Usually is easier to isolate bad code under a solid interface, and then develop the new features around the interface. Good Software is pretty much alike good hardware: you don't need to replace your car's transmission if you need to replace the car's brakes, do you? Spaghetti code becomes a serious problem when people adds new features over it, instead of adding new features around it. Easier saying than doing, no doubt: but there's a reason good developers are highly paid, right? Let me tell you a history that I had lived on the days I was working on embedded systems: we were working on a considerably complex product, we were a team of 5 and we have a lot of code from different vendors to stitch together. There were good code but written for a different system, there were absolutely terrible code written for the same system, and there wasn't enough of us to rewrite everything. Sounds familiar? How we managed to survive the mess? By writting wrappers. We defined a framework in which we would develop our product - and this framework, indeed, took a lot of work from all the team to get done right. We took months on it, and we only managed to accomplish that because the Manager had a solid background on development himself and agreed that the solution was solid - but hell, we took a lot of heat due the lack of "results" for a lot of time. Once the framework got ready, we wrote a Facade around every 3rd party code - essentially shelling code around our interfaces, writing code to convert things when needed. Some CPU were wasted on these conversions, and again some heat because CPU resources are usually limited on embedded systems - but, again, we got lucky because the hardware were over dimensioned for the task and we have some fat to burn. The only time we got screwed was when the Top Brass, worried about how slow were were developing the thing, decided to "help" by hiring contractors to accelerate the deliveries. It was not totally bad, the knowledge of the contractor effectively helped on some issues - but the dude was being paid by task, not time spent, and so he did things the faster he could - taking shortcuts over our framework and doing direct calls inside the components instead of using our public interfaces. Guess what? We lost months of development rewriting a good part of the code he wrote, not because the code was bad (some of it was, but if the thing works, then it works!), but because he didn't follow up our interfaces and made calls to things that wasn't meant to be called outside their contexts, completely screwing up the stacks of the threads and halting the whole system. At the same time, one of my colleagues, besides being a very good electrical engineer, was (frankly) a bad coder. But he did everything by the book, and almost none of his code was flagged with bugs. Hell, I was a way better coder than him, he reached me for help on the programming language now and then - and yet my bugtrack's size was twice of him's. (he had a better understanding of the hardware than me!!!) Well, after this wall of text, I think you must get caught the picture: Spaghetti code can be a hindrance or a problem - it's how the team copes with the code that decides which one. I am talking about a hindrance to fixing the bugs. Not a hindrance to the entire development of the maneuver mode. Well… Let's be careful on this one. There were capable professionals on the team, no doubt. Some more experienced, some rookies, some nice guys, some sas-moholes, the usual stuff as always. In a way or another there were good things being implemented, we can't say that the all the features were crap - not at all. IMHO what we had was some critical bugs pilling up without being fixed, to a point in which all the very good stuff being added could not be appreciated by the users. Why these bugs pilled up must be the key to answer your question. However, I don't know the facts I need to know to give you a answer for it. What I know is that it's possible to have a terribly incompetent team formed by very competent individuals - as well to have an incredibly productive team formed by rookies. You can save or doom a team by adding or removing a single dude... Most of the time, management is the key for the success of a Team, but it's premature (and probably unfair) to just blame management for all the problems - at least, without more information. And I, definitively, don't have much... The KSP2 early access video appears to have most of the original developers and ones I didn't even know of until I looked at the KSP1 credits. If their skill wasn't at an acceptable level then Intercept Games wouldn't have taken them all on. That's why it felt more like a management issue. Given the results we have nowadays, it's clear that the Team had failed on delivering the results expected from them. Lack of skill can be one reason for that, but my guess is that it was not the only one - perhaps not even the main reason. If I would make a bet, I would bet that over-confidence played a bigger role than the lack of skills. Some features should not had been allowed to be published at the state they were. Hell, some KSP releases had config files with merging problems (to the point I had written a lint tool for the config files) - at least this one is not about skills, I can tell you. Over confidence? That cant exist. If I was working on KSP1 and the free updates. I would be cringing on every update. My self confidence would be plummeting on every stupid bug that popped up when it shouldn't have been there at all. Something else is going on here. How do I force the quotes to collapse when viewed by others? My response is taking up too much room.

My main experience was with a small amount of Visual Basic years ago where there is a graphical window where a dialog box etc can be created and text boxes and labels and other things can be attached. Then there is code and attributes that is connected to the textboxes or whatever that is able to be interacted with on the window when tested. With Unity I have only made one mod for KSP that showed coordinates of individual parts of a craft using the action menu for a bug report relating to the robotic drift. That mod ended up helping with what eventually became 1.12.3 So to be honest my experience is kind of limited. But based on Visual Basic and the small tiny amount of experience with Unity I would have to see how the code links to the UI elements and see how it works before changing it. Note the following bug was fixed: Entering the exact time of a maneuver node in the UT text box moves the node around the proposed maneuver instead around the current orbit. The others weren't @Lisias (getting an expert) Can you please give me a hand for a second after my grandiose claims. Other than the phase angle bug above and possibly the ejection angle, how hard would these bugs be to fix in the maneuver mode? And how hard would they have been to get right in their initial development stage? And could the spaghetti code of KSP1 be a hindrance? Was this above the skill of the Squad developers? To clarify. The answer to the skill level question is NO. Most likely what happened is that they were working on Breaking Ground at the same time and they somehow forgot to thoroughly test the maneuver mode in amongst the mess of developing and testing the robotic parts.

You take that back! (I secretly hope you are right)

Six 1.7 Bugs I reported in relation to the maneuver mode: The Maneuver Mode starts from Year 0 Day 0. This causes issues because the Universe started from Year 1 Day 1. Ejection Angle changing constantly when its part of a maneuver node. It should be stuck in the exact time the maneuver is supposed to be happening (in the future) Somehow Phase Angle was locked on Kerbin as the center of all phase angles, when the sun is the center for a phase angle between Kerbin and Eve, Kerbin is the center for a phase angle between Mun and Minmus, Jool is the center for a phase angle between its moons. That never got fixed. UT time in the maneuver node tab doesn't work correctly under the Year:Day:Hour:Minutes:Second entry option (clock icon) Entering the exact time of a maneuver node in the UT text box moves the node around the proposed maneuver instead around the current orbit. The mouse over text doesn't change if the target is changed from Planet to Planet or Craft to Craft BUT does change if target is changed from Planet to Craft or Craft to Planet. This isn't hard programming. And the spaghetti code of KSP1 wasn't an excuse for these bugs. It just needed to be tested and fixed before the 1.7 release. With all the bug reports I have done for KSP1 and the secrets they showed me: KSP2...I am COMING FOR YOUUUUU!!! Be ready to RUMBLE!

@pmborgHow to make Mechjeb work with 1.12.4: Install Mechjeb 2.14.1 Install ModuleManager.4.2.2 You might be missing the Module Manager. It isn't an obvious dependency on the main thread but without it Mechjeb will fail to work at all.

Yeah I can agree with that. The price of US$50 instead of US$60 that was the original price tag is kind of proof of that. However Early Access for KSP2 is an excellent idea. I think without it KSP2 would have been less than optimal on release. Plus we get to see how well Intercept Games interacts with the community with an Early Access instead of a 1.0 release.

KSP bugs were consistent through out the development of KSP after 1.05 - 1.12.4 with bugs etc when Take Two didn't have the IP until 1.3.1 or 1.4. The bugs aren't on Take Two.

Take Two left Squad (management) to its devices for the DLCs and all the free updates. The DLCs were buggy, and 1.4 (after Take Two took over) to 1.12 were all overly buggy as well. KSP1 Management seems to just quit when development gets to 80% and doesn't go all the way. The KSP updates after Take Two acquired the IP could have made 1.4 - 1.12 way more robust by supervising the development more closely but didn't do anything obvious. What is KSP's biggest flaw? Its buggy and badly optimized. But we love it so much and work around the bugs because there's no alternatives. Take Two wanted KSP2. That was their main focus. Not KSP1. Not at all or KSP 1.4+ would have been vastly improved.

Correction for the following (note the bolded is my path and probably not yours): "D:\Steam\steamapps\common\Kerbal Space Program\KSP_x64.exe" %Command% -popupwindow This will break TweakScale for some reason. How to fix it is as follows: Create a shortcut within the KSP folder that isn't KSP_x64 (KSP_x64_Steam will work as a shortcut name. Thanks to @Gotmachine for the correction) Use "D:\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Steam" %Command% -popupwindow Enter that into the Launch Options and (crossing fingers) that will correct any problems with bypassing the Launcher enabling TweakScale and any other mod which does the same thing to work.

In my testing the only issue that I currently have with 1.12.4 is some error in the UI when I have the DLCs installed but that doesn't stop it from running or functioning (I launched a rocket into orbit with mechjeb to test it)

I can test for that in the broken launcher bypass Launch Options for steam

KSP2 has multiplayer as part of the roadmap. KSP2's foundation is built with multiplayer being a part of it (it was stated from the beginning). Not sure how it will be implemented though.

No idea but I seriously doubt that the DLCs were really made for the money making aspect. Their overall goal was to figure out how many people would buy them, then use that for KSP2. Then on top of that they would have added the fact a certain percentage of people liked KSP but hated the bugs and quit playing. I believe that Take Two are expecting to make a lot of money. Way more than The Outer Worlds that was also published under Private Division which did really good in the sales department.

What do players that play a game for 1000s of hours mean? That DLC's will make lots of money after the main release of the game because of people continuing to play KSP2 for longer than a normal game where people play for a while and then stop, like my playthroughs of the Mass Effect games. Lets consider the following: Do we want KSP2? Who got it for us? Take2 got it for us. Who did they pick? Star Theory/Intercept Games with a person whose a KSP nutcase who is Nate Simpson. Star Theory (who some went to Intercept Games) flew in well known KSP1 players (at least one from Europe) to their HQ in Seattle to ask them what they wanted for KSP2. Any other games that this is happened? Do we want KSP2 or not? So far everything took a while sure. But other than the Launcher I am fine with everything that has occurred so far. Take Two want their money. We want KSP2. I am good with that. What was the alternative? No KSP2.

Moderators thanks for going the extra mile with the translations and formatting issues. You are appreciated.

Both. We would first both get utterly pastered talking about the PDLauncher bypass tweakscale misunderstanding and then end up walking into doors. No. The walking into doors doesn't make sense....Someone overhears us and insults us both. We fight that person. No. We both belong to the same boxing club and then we end up fighting. Afterwards we both get a bloody mary? No. We meet. I am the windows guy. You are the Mac guy. We don't get on. We fight. A linux guy breaks us up. We become friends over bloody marys. Thats the most likely. Yeah. Yeah. Good. All sorted.

I stand corrected @LisiasI just watched the 2nd Enola Holmes movie with my mother. For some reason I can imagine you as an older Sherlock Holmes letting lose on the simpletons Pity we will probably never meet. You would be quite interesting to talk to face to face.

GotMachine is correct about having to change the shortcut. Make sure the shortcut is not KSP_x64 or KSPe will cause an error.

Oh I mean the bypass without the shortcut that GotMachine mentioned. Reinstalling Steam is what I did. And running KSP with the bypass without using a shortcut still caused Tweakscale not to see the DLLs

@LisiasWait you aren't having any problems with using the launcher bypass? I don' remember having any problems if I use KSP on steam without the bypass except that the borderless window command -popupwindow doesn't work. But if you are using the bypass and having no issues I have a theory why. And this is going to hurt to test.

I must love the torture of bugs considering I like to figure them out or find work arounds. Part of that though is to reduce the pain of others

Life unfortunately isn't perfect. Right I am off to add to my posts about the Launcher work around and make a proper post if one hasn't been done yet. nm theres already a post on the bypass and GotMachine has added a correction

This looks promising. Works Perfectly. Thanks @Gotmachine.. I think. I only tried it once. But tweakscale didnt have a heartattack

Using the executable via a shortcut should work fine. I haven't had the same issues when using it separately to steam.

I hope KSP2 is clear of such errors. Added new KSP.log files. to the github. Added log file with tweak scale which I had moved the dlls (Bypassing Launcher) Added log file with tweak scale installed from official download (Bypassing Launcher) Added log file with tweak scale installed from official download (With Launcher running as intended) You were right they were in the PDLauncher folder.