AVaughan

Hey I just worked out TT plan for finishing KSP 2. They figure that chatbots are writing code now. If they wait a few years they will get good enough that they can just feed them the design documents, and out will come a working version of KSP 2.

I can imaging an automated process that runs an overnight build every night from source control. The build is then automatically uploaded to steam, which shows activity, without anything actually changing other than the build timestamp.

I doubt they would hire anyone to look after either version, but just let it sell as is. Pay for forum hosting, have someone available to answer any emails from steam or any of the other storefronts, and that would be that.

At bare minimum, I think you would have to beat what they expect from residual KSP 1 + KSP 2 sales over the next couple of years, then add enough extra to make it worthwhile for them to sell. (I don't see any signs that they are desperate to sell, I guess that might change when the next GTA releases, if it isn't well received).

@Meecrob So any news? Did anything come of this?

The way to cope with large vessels is to use mods that add larger fuel tanks, and larger engines. Large fuel tanks replace multiple smaller fuel tanks. Replace 4-5 Nervs with a single larger 2.5m nuclear engine with the similar total thrust and isp, or 7+ Nervs with a 3.75m or 5m version. That lets you reduce part count, which means you can still have huge vessels and a decent framerate.

Pretty sure I saw the Private Division label is still in the splash screen, so it is only the launcher that they removed, (which might mean that the web server the launcher talks to is going away).

Some people want things that are just never going to happen. I've played through the KSP2 exploration mode campaign, and overall it wasn't too bad. Definitely some bugs, plenty of rough edges, but perfectly playable. Performance was reasonable and perfectly playable on my mid range hardware. (Intel 12500, RTX 3050 64GB ram). Admittedly my largest craft was probably only 100 or so parts, so nothing really large. It desperately needs some QoL improvements, but those could have come during early access. A better maneuverer node editor, an alarm clock with the ability to add transfer dates. The worst problem was landed craft jumping off the ground and falling over when you left or returned to their physics bubble. Linux works fine. I've been using it since 2002. Works fine, just don't expect it supplant Windows on the desktop anytime soon.

That sounds like a lawyer who is prepared to take $10,000 to look at the case, and then they will probably tell you how many more $$$ you need to pay to get it to court. If they are honest they will probably tell that prospects of winning at court are slim, but they will keep taking your money just as long as you are prepared to keep paying.

Take 2 announced that development on several titles was being cancelled. Then a few weeks later there were layoff notifications. The studio is being closed. 70 layoffs. Which would be pretty much everyone working on KSP 2.

I actually think they made a mistake in going for interstellar travel that way. Even their new manoeuvre node editor seems to only generate burns in a constant cartesian co-ordinate frame. Whereas if you really want to do long durations burns efficiently, (eg ion engines) you want to be able to do burns that are always parallel to your prograde vector, so I'm not sure their new manoeuvre node code would result in efficient multi-year burns for an interstellar voyage. (It would probably generate a burn that would work, but with significate penalties for much of the burn not being prograde, when compared to a more optimised burn). I'm only part way through the exploration mode campaign, but given the way that sems to be focused on monuments presumably left behind by some predecessors, they might have been better off with the Kerbals finding some sort of a gateway on a planetoid in an asteroid field at one of Jool's Lagrange points. Land on a surface portal there, then trigger a transfer to another system. Still wants ships with high dV, to rendezvous with a planetoid at Jool's lagrange points, then need more dV to get anywhere from another Lagrange point, and more dV, if you want to return science/samples/Kerbals. So still want more advanced engines than KSP 1. Whilst it isn't hard physics, what we would have got from generations ships would have probably skipped much of the hard physics/engineering problems of interstellar ships. (eg Life support over generations, shielding against debris when traveling at significant fractions of light speed). That sort of approach wouldn't have needed much beyond what KSP 1 could do as far as orbital mechanics (mainly the need to simulate multiple solar systems, rather than just one), and wouldn't have required players to warp through tens/hundreds or even thousand of years of interstellar travel.

I've been told by someone who worked on KSP 1 whilst Nate and Co were working on KSP 2, that they started with the KSP 1 source code, then changed the bits they wanted to change. Hence many of the same bugs, (often including bugs that had been fixed in KSP 1, because they removed the fixes).

None of which says anything about whether development will continue past when the layoffs take effect. If development doesn't continue, then that means the project is basically dead, and they are just milking what revenue they can from the corpse. (And yeah none of that needs to be officially announced. Although I would argue that they should update the steam and epic game store roadmaps to reflect that development is either paused or cancelled. Not doing that is arguably misleading consumers and would probably be illegal where I live). I can't see them making any money from officially announcing that they are ceasing development. So most likely they will delay announcing that the project is paused/cancelled for as long as they reasonably can. That way sales will continue, at least from people who aren't aware of the situation and don't read the recent reviews. (Quite possibly their official, for the record, position will be that no final decision on the fate of the game has been made, but I would interpret that as more an excuse to avoid saying development of the game is cancelled, than a sign that they intend to continue later).

If they were moving production to a different studio, I would have expected them to have said so by now. The virtual silence on the topic as the community implodes is pretty damning. They have nothing to say that we want to hear, so they say nothing at all. Don't forget that they announced that that they are cutting costs and that several projects were cancelled weeks before the WARN notice. As far as I'm aware we still haven't had an official announcement of what projects were cancelled, but it seems pretty likely that KSP 2 was one of them.

The game is not going to end up good, unless they keep developing it. Nothing they have said gives me any confidence that will happen. the pretty much complete silence on the topic actually makes me think they have already killed future development, and all we can realistically hope for is one more patch before everybody finished work. (And even that patch is iffy). Think about it. If they had a plan to continue development, would they have waited this long to say so?

Your perspective is very different to mine. From my point of view ksp 2 has pretty much all the same bugs as ksp 1, plus plenty of new bugs of its own. (Now many of those new bugs could probably be easily fixed, but we haven't had patch in 3 months, and I'm not sure we will ever get another patch). Yesterday I tried to play KSP 2 for the first times since shortly after the Science release. This time I rage-quit after re-flying the same mission 3 times, because on all three attempts my parachute failed to properly deploy. (That is the sort of bug that I would have hoped would have been quickly fixed in patch of hot-fix released within a couple of weeks. Since it is the sort of mission ending bug that can cause players to rage quit, you would think it would have been a priority to push a fix out. But 3 months later, it still exists. I have no idea if we will even get another patch, let alone whether it will address that bug). The previous time I tried to play it I gave up bothering after Mun/Minmus landers repeatedly left the surface every time I timewarped, loaded the game, or otherwise caused scene changed, or even boarded a kerbal from the surface. (Yes KSP 1 has also had similar issues, but this seemed worse, and was definitely worse that I would normally experience in a typical modded ksp 1 install). So as far as I'm concerned ksp 2 has most of ksp 1 bugs, and plenty of new ones of it's own. It also seems to be missing a whole bunch of advanced features that KSP 1 has (eg fuel priority). It is has a UI full of questionable choices that make the UI harder to read at a glance, take up more space than necessary and the whole UI seems full of counter intuitive behaviours. (Maybe I'm just too used to ksp 1's UI). Pixelated fonts/graphics when the UI should be crisp and clear for easy reading, I still don't understand how or why the VAB UI decides to clone a workspace every time I revert and load/edit an existing design. The whole UI feels like it might have been together for a simple iphone/tablet style games, not for a complex simulation. Other design choices make me think that Nate (or maybe his bosses at TT/PD) wanted to make a simple cartoony ksp 1 style game where things constantly break in a cartoon manner. (Witness the trailers and their wobbly rockets. Witness Nate wanting wobbly rockets even after has was told by a squad employee that wouldn't go down well with the existing ksp1 fan base. Witness advanced UI options like toggleable auto-structs and fuel priorities being removed. Witness how simple the science parts are). That vision is at odds with the more complex simulation I want, and the complex missions I like to do, where if something breaks unexpectedly, often I either have to reload or fail the mission.

Source? It's not that I think you are wrong, just that I hadn't heard that information, and Nate is the last person I want to see 'saved' from the layoffs.

So the science update seems to finally get KSP 2 to a state where I'm considering buying it. Before I do, I just want to double check what sort of copy protection KSP 2 has, and whether there is any difference between Steam and Epic Game Store version. I haven't been paying much attention to KSP 2 after the disappointing state of the game at early access launch. One of the things I like about KSP is the fact that it will run without internet access, and without needing Steam to be started first. It will also run if I copy the KSP install outside of the the steam directory, and run it from there. This has advantages for modded playthroughs (no risk of KSP updates breaking mods in the middle of a playthrough), and also means the game is playable even when I'm without internet access. (Note that when they added the launcher to KSP about 12 months ago the launcher itself wouldn't run properly without internet access, but it was still easy enough to just start KSP.exe directly, so I don't consider that a problem). So does KSP 2 work if you copy it outside the Steam/EGS install directory? Does it work without needing Steam or EGS to be started first? Does it work without internet access? (Bypassing a launcher by launching the game directly is fine, and what I would normally do when starting KSP anyway). How are mods installed in KSP 2? Is there something equivalent to CKAN, or are they hosted on Steam workshop or some other service? Also are there any differences between the Steam and Epic versions that affect any of the above, or that might affect which store I might wish to purchase from?

Are you sure that they can afford thinner steel? Wouldn't the fuel tanks still be pressurised to the same pressure? Wouldn't the aerodynamic loads on launch likely be similar? (Admittedly aero loads might be lower with no flaps, but hoop stress for the tanks would be the same, if the internal pressure is the same). Don't you still need at least one centre SL engine with it's gimbal for control during burns if one of the 3 vacuum engines fails? (With 6 vacuum engines, you could shutdown the opposite engine instead, but all the same I'm not sure SpaceX and NASA would choose to make design changes from a standard starship in a way that might reduce redundancy in the event of an engine failure on the Lunar lander). Do you really want to make the lunar lander taller? Isn't the CoM already going to be uncomfortably high? (Yes that can be managed, but why would they choose to make the lander even taller)? I haven't done the maths, but wouldn't refuelling the lander in Lunar orbit (at/near gateway), then letting the fuel tanker aerobrake into Earth orbit, (or more likely re-enter directly from the Moon) be more fuel efficient than using fuel for the lunar lander to capture to LEO, especially given that under your proposal you need to land that fuel on the Moon, then launch it back into Lunar orbit? Can't one stretched tanker make an LEO to Lunar Gateway trip with enough fuel in lunar orbit to refuel the lunar orbiter, and still have enough fuel to return to earth. Possibly even with enough margin for a small cargo hold and some supplies/cargo. And doesn't refuelling at Gateway allow the option of significantly heavier payloads to the Lunar surface? If you are going to do an in space cargo transfer or in space resupply/refurbishment, then I'm not sure that LEO is enough better than gateway to justify the disadvantages? Other than shorter round trip comms for any remote controlled operations controlled from Earth, what advantages does it have? Doesn't anything that needs to replaced still need to wait for a launch from Earth? (Ok yes, sending something to lunar orbit needs more than just a launch from Earth, but if you are already supporting Lunar Gateway with regular supply runs via starship, isn't it just some extra cargo next launch to Gateway)? I'm sure SpaceX is aware. (In fact today was a pretty good reminder). Why do you think their Lunar lander proposal seems to have small landing engines mounted high up.

Noting the location of a celestial body against the stars gives you more than orientation. Each such observation gives you a vector from that body to your position at that time. Two or more simultaneous observations of different celestial bodies in different areas of the sky should give you a point where the vectors intersect (or their closest approach to each other, since no measurement is error free).

If an engine has failed for an unknown reason, all the other engines on the same aircraft might also be susceptible to the same issue. (What if the cause is fuel contamination, or something else that is common to all the engines on the same plane).

Assuming you have a decent clock and decent optics, then measuring the position of the Earth/Moon/Venus/Mars/Jupiter/Saturn against the stars should be enough to triangulate your position. (You can also cross-check and calibrate your IGU's orientation against the stars the same way).

Just watching the livestream now. One quick takeaway. https://youtu.be/L5QXreqOrTA?t=953 So looks like it is still possible that some early starships might still get landing legs, rather than SpaceX attempting to catch them. (Worth mentioning that 30 seconds earlier he was talking about landing on the Moon/Mars, and so maybe he was referring to Lunar/Martian versions).

I think you miss understood what I was saying. A piece of my post you didn't quote. I am suggesting that proc tanks enable you to replace multiple smaller tanks with a small number of larger tanks. That can be done without changing the amount of fuel, or the TWR (assuming that tank mass scales with tank volume, which is true for KSP 1 tanks, and not considering the impact of possibly adding an engine plate).

Assuming that semi-proc parts let you build longer/bigger tanks than are available in stock, then part counts for many large rockets would shrink. (If the tanks were twice as long, then you only need half as many tanks for the same amount of fuel. If they are twice the diameter and twice as long, then potentially you could cut tanks by up to a factor of 8). Optionally you could also add optional switchable nose cones and engine plates as part of the tanks, further reducing both part count and unity joints. If the optional nose cones were the same as the existing nose-cones, then you can actually retain most of the lego style rocket building. Yes there will be cases where the part count remains the same. Some of that will be because players are building curved structures from the existing parts, and a simple semi-proc tank implementation probably isn't going to help with curved structures. There are potentially also players who will build as big a rocket as they can, perhaps limited by the performance they are willing to tolerate.