AVaughan

It's been a while since I used GT as well. My current game is RO and RP-0. A few years ago I did successfully use GT in RO as well, but that took too much fiddling with the parameters of the initial turn to be worth while. Another possible reason for being too flat/failing to make orbit is pitching over too much in the initial pitchover. (GT's defaut guess is tuned for a default sized kerbin. On a x3.2 you probably want to pitch over around 5-6 degrees).

I've used Gravity turn in a few x3.2 games without problems. (Although I always set the launch parameters myself, and never let GT attempt to optimise them). If you are burning up in atmosphere, then you are either turning too aggressively, and/or have too high a TWR on the lower stage(s). I suggest a takeoff TWR of between 1.2 and 1.4, (maybe as much as 1.8 if using short burn time SRBs). Then each subsequent stage should have a TWR of around 1.2 at ignition.

This is a legal matter. Squad really shouldn't make any official statement without getting that statement cleared by the relevant legal department. And T2's legal department would have most likely told them not to comment, because any official comment could potentially undermine the EULA, if it ever came to court. For the same reason I didn't expect T2's management or legal department to comment. So probably the only comment Squad could have made is something equivalent to "This is the new EULA. We have been told not to comment further." Would that have actually helped? (Personally I think a non-comment like that would just have inflamed the discussion).

I'm guessing based on similar problems with RSS. Try reverting kopernicus to version 1.3.1-3. The later versions of kopernicus made some changes that broke some mods.

Kopernicus has also made some changes in the last few weeks that might have broken New Horizons. If you are on 1.3.1, try kopernicus v1.3.1-3 https://github.com/Kopernicus/Kopernicus/releases/tag/release-1.3.1-3 . Also be aware that kopernicus is very sensitive to the version of ksp you are running (they _must_ match). So if you aren't on 1.3.1, you will need to track down a version of kopernicus that matches your ksp version.

If you really want realistic mods then you should check out RP-0. (KCT is strongly recommended when playing RP-0).

Back when I tried Kerbalism I had problems with a craft in Kerbin orbit. I kept running low on EC. At least once when I switched to it it was in full sunlight, roughly halfway through the day section of its orbit. But Kerbalism though it was in shadow. Whilst the problem would happen intermittently, loading an saving the game was enough to solve it.

No we got your point. The problem is we don't agree with your point. Please do not conflate people disagreeing with your point, with people not listening to you. BTW you are also completely ignoring the points other people are making. That is your right. But if you are just going to re-iterate the same point and ignore everything anybody else says, then please stop accusing us of missing your point. 1. I agree there was something that was referred to as Asteroid Day DLC. I'm not sure whether that was the official squad term, but I remember players referring to it as "Asteroid day DLC". It was free in the sense that players didn't need to buy it. But that is completely irrelevant to whether new dlc produced in 2018 should be free. 2. I don't recall who made that dlc. I have no idea whether it was made by a Squad employee, possible in their own free time, then just rolled out as an official mod. Or whether it was made by someone who wanted to promote asteroid day, and then donated to squad, with an arrangement that squad would release it as an official mod/dlc. Or whether NASA or ESA or someone else paid Squad (or possibly another modder or developer) to make it and arranged for Squad to release it, to help promote asteroid day. (In the last case whilst it might have been free to players, someone got paid to make it, and possibly Squad got paid to release it). But again it that is completely irrelevant to whether Squad should charge for new dlc. 3. Let me repeat the point that I and other posters made a few posts ago, but which you keep ignoring. If you want Squad to keep working on KSP, then they need an income stream. It can be selling new copies of the game, or selling dlc. No income stream will mean no further further development of ksp, and no more patches. I have no idea how many new copies of KSP they sold in 2017, but by now I expect sales are tapering off. Most people who are interested in KSP have probably already bought a copy. So that leaves the choices of selling dlc, or abandoning KSP development. No matter how much you think new content for existing games should be free, the realities of the real world is that someone needs and income stream to pay the salaries of the developers working on ksp, otherwise there will be no more patches. (And remember that, as I understand things, patch 1.4 will be free, it's just the new content that Squad are charging for). 4. Do you remember games like Football Manager 2018? Because that sort of yearly or bi-yearly release is the only way to keep a game/franchise running without selling dlc. And instead of optionally buying dlc occasionally, that is buying a new full priced version of the same game every year or two. I'd much rather Squad sells new content as optional dlc and makes periodic free patch releases than the alternative of them stopping work on ksp and start working on ksp 2020.

I get your point. But do you understand what the consequences of your attitude would be? Developers would release a game. Push out a patch or two for the worst bugs a few weeks or a few months later, then start working on another game. If they can't sell dlc, then once the sales of the existing game start to level off, their is no reason for the developers to keep improving the game. So at that point they will stop working on the game, and start working on something else. Possibly ksp v2, possibly another game entirely. The only reason a shipping game likely to get long term support is because people buy dlc. You might not like that, but that is the way the world works. No financial reward means no reason to pay developers to work on a shipping game. In the long run, if you want a supported version of the game that works, you will need to buy a new copy, at full price, every 1-2 years.

Personally I would rather recommend the pc version. Mods add a lot to ksp. You don't need a particularly powerful pc to run ksp. I'm using a 7 year old pc with an i7-860 cpu and a HD5770 graphics card, and that runs ksp fine. Would I get better performance and pretty graphics from a more powerful pc? Sure. Can my pc cope with all the graphical mods that really improve the graphics? Nope. But my pc is probably roughly the same performance as the ps4 or xbox one, and those mods won't be available for the console versions anyway.

So an word on an updated demo yet?

It wouldn't surprise me if most of Squad's testing was focused around testing the game with what they consider default options. So if activating advanced tweakables has unexpected side effects it's possible that's why bugs were missed during testing. And you don't really need anything in the advanced tweakable menu, so it should be viable for console players to test whether disabling advanced tweakable fixes their issues.

Maybe try the Janitors closet mod .

Do you have the latest module manager? v3.0.4 Atm (There have been multiple updates in the last few days, and one of those fixed the same issue for me).

Follow up to my last post. [X] science is known to cause stuttering, and a modified dll is available in the [X] Science thread. Unfortunately the maintainer seems to missing, so it might not get an official update for a while. The fixed dll also has some minor behaviour changes. The fixes mean that it now only looks at experiments that are available in the current SOI. From the description of the changes, I'm guessing that RSS + RP-1, with lots of bodies and lots of experiments, is probably affected more than stock.

I've seen similar stuttering which I think is caused by some sort of interaction with [X] science. (If I don't have a [X] science window open the game doesn't stutter. It also seemed to affect Nathan Kell in his RP-1 campaign).

Going back on topic. I'm pretty sure that multithreaded physics simulations have existed for quite a few years. eg from wikipedia However I don't know whether any existing multithreaded physics libraries meet ksp's needs and whether any of them could be integrated into unity. Regarding the slowdowns with large part counts, ksp could probably implement something similar to a welding mod, where when two similar objects of similar diameter are attached, (eg 2 fuel tanks), they could be welded into one part, at least for most physics calculations. Ideally the editor could even detect that fuel tanks are not only node attached to their parent, but also surface attached to another part in the tree, and 'weld those multiple tanks into one tank. As long as all tanks that are welded this way are all part of the same stage, the only time you need to consider them as separate items is when one of them collides into the ground/another vessel, and when calculating heating during re-entry . That would improve stiffness of large craft, and could also significantly reduce the number of parts you need to calculate physics for. I'm also not sure how much physics calculations ksp does for "physicsless parts" eg things like rcs, lights, most science instruments, most parts that only surface attach. Conceptually they don't need to be considered for most physics calculations. You only need to do some simple stuff, eg check for pressure damage, and transfer heat to/from their parents during re-entry. But that is all linear in number of parts, and not O(n^2).

Drills extend out, and then down. So if they are lifting your base, then they are positioned too low. The kraken shaking things to bits is often physics causing pieces to vibrate. One tick things are in the wrong position relative to each other, so there is a physics force accelerating them towards the correct position. When they get to the correct position, they have too much momentum to stop instantly, so they continue moving. Another few ticks later they are again in the wrong relative positions, so there is a physics force accelerating them the otherway. Long thin structures are often problematic that way. Sometimes struts/autostruts help, sometimes they make things worse. Sometimes you can save things by timewarping for a few seconds. (No physics is applied during timewarp).

That sort of thing happens on pc as well. I try to test any new design on the launchpad before sending it to other planets.

Personally if you have a failure mod, then I think things like batteries should be able to fail, but most of the time that should be a non-catastrophic failure, ie the battery no longer holds any charge and becomes useless. Same sort of thing for solar panels. And with enough tech and "practical in use testing" things like batteries and solar panels should end up with a mtbf measured in years. (Though deployable solar panels might have a significant chance of failing to extend/retract).

I generally try to land some of my manned Mun or Minmus missions in whatever biomes I haven't already farmed from Kerbin. Flying planes to the poles is just too boring for me.

There used to be a demo available. That was effectively your ksp free version.

But it seemed fine for me, so I'm not sure what the issue is that you think should be fixed. The only thing I can think of is people either trying to fly the turn themselves, and not doing a good job of it, or throttling down at the wrong time, when the tutorial explicitly says that that rocket doesn't need to throttle down. Given how much control authority that rocket has in the lower atmosphere it is very easy to overshoot when trying to steer. Hence my comment about needing to use fine controls, and why I'd suggest letting Val just follow the provided target marker. (Something the tutorial also suggests).

Personally, for a new player, I'd recommend initially just letting target lock steer. that does a good enough job. Afterwards you can replay it steering manually, if you want.

So I tried the orbital tutorial in a completely vanilla 1.3.1 install, followed the instructions and reached orbit with 58 oxidiser and 48 liquid fuel left. (I did have Val follow the target marker, rather than fly the turn myself, but the instructions suggested that, so I consider that to be following the instructions). So it's possible to get that rocket to orbit in the tutorial, and I'm not sure what is the cause of the problem you are having? Edit: I also flew a manual turn, and reached orbit with 48 oxidiser left. (I did need to enable fine controls. With those steerable fins, that rocket has way too much low altitude control authority for my tastes).