K^2

Not very high. Say, you have a 1L bottle that can take 5atm of pressure. (You might be able to go a bit higher, but not by much.) That's 1L of air compressed to 200mL and 800mL of water. If you were able to design the exhaust so as to uniformly accelerate all of the water, this is 4x105Pa * 2x10-4 m3 = 80J of energy applied to 0.8kg of water, giving you 14m/s exhaust, or ISP of about 1.4s. And this is the upper limit. Realistically, it's going to perform a lot worse. You can play a bit with proportions to improve it a little, but you're still going to be in that ballpark. Now, if instead of compressed air you used superheated steam, it is possible to do way better, because you can maintain high pressure throughout the work cycle. Still nowhere near what you'd want for an SRB, but getting into amateur rocketry territory. In fact, there was a guy by the name Mike Hughes who used to fly these to fairly impressive heights.

I'm generally against pre-orders as a monetization strategy. So if some of the content is to arrive at a later date, I would rather it be priced separately and make decision on whether or not to purchase it when it becomes available. That said, carving up content and deferring chunks to DLC so as to stretch out game's income generation has also become a bad pattern. But at least, DLCs are a good thing for most games on the net, and a lot of companies have managed to release good content post-launch without getting predatory about it. So it's still a much preferred route here.

That's not terribly alarming in context. It really looks like after some back and forward, Intercpet has taken a nearly clean slate approach after taking over the development. So really the game has been in proper production since sometime in late spring to early summer of 2020. We're less than a year in. At this point, if developers are generous enough to share, all we expect to see is some art and janky pre-alpha screenshots and footage. So far, we've seen some art and janky pre-alpha screenshots and footage. The 2019 images and trailer are basically glorified fan art at this point. Naturally, none of this gives concrete indications that adequate progress is being made, but I'm not really seeing any red flags, either. I get why T2/PD thought it's start building up the hype in 2019, based on a more contained vision of KSP2 being made by a smaller external team, but based on how things have gone, they jumped the gun way too early. This summer would have been right around time to drop a teaser based on current schedule. So have some patience. We'll see how the game is really going soon enough.

Under assumption that all the core features we expect from KSP and things that were promised from KSP2, such as star systems, colonies, multiplayer are all in, and we're talking about things that would make it extra. Stock robotic parts from day one. Some way to read and combine inputs from sensors, using output as custom axis. (Be it scripting, gates, or just extending action groups.) A way to keep more than one ship loaded for a short duration. E.g. for reusable booster recovery. (Tech will have to be solved for MP anyways.) More and better procedural generation on planets. Better reasons to build planes, rovers, or even boats for planetary exploration.

We don't really have any details yet, but I don't think there is any reason to make a game local network only in the modern day and age. It's safe to say that whatever Intercept will come up with, you'll be able to play with your friends remotely.

More recent versions of Unity have been better about utilizing threads, but it's still definitely a problem, especially, in terms of physics. There is some speculative indication that Intercept is not going to leverage the ECS/DOTS, which is what you want to spread load between cores efficiently in latest versions of Unity, so while we expect better thread usage, it's likely that single-thread performance is still going to be very important. If you have an older AMD processor, you might need to upgrade. Zen2 or later will probably be fine, as that matches Gen 9 consoles and competes favorably with similarly priced Intel processors in single-thread. To be on par with PS5, you want something like AMD Ryzen 7 3700X or Intel Core i7 10700K. You can go a bit older on Intel side and still match that performance, but older AMD processors might struggle due to poor single-thread performance. Of course, min-spec might be considerably lower. I'm just confident that it won't be higher than that if they want the game to perform well on Gen 9 consoles. Either way, right now is a bad time to buy CPU, so you might as well wait and see.

IIRC, GMod uses Lua scripts for that. People have found remote code execution exploits in Lua in the past in other projects. I don't know what the status of it in GMod is and how well sandboxed the scripting system is, so I'm not going to promise that it's safe, but it can at least be made sufficiently safe. In the modern world, JavaScript is far better for performance, security, availability of libraries and support, and ease of debugging than Lua is by a considerable margin. That wasn't quite the case back when GMod first appeared, so for legacy games like this, I don't mind Lua too much. For anything modern, if you are going with Lua instead of JS, you're objectively doing it wrong.

While I stand corrected - thanks, by the way - this only reinforces my point that salary to workers on far-away projects should be an important part of operational budgets for colonies and orbital shipyards. So it makes complete sense that building stuff not on Kerbin should still involve funds.

It's literally how optimization solvers work. Just to be clear, is the argument seriously, "This would be bad, because it's very hard to program?" Because that's not the case. Yeah, you can end up with another object getting in the way, and the actual trajectory not being the one you want, but that's going to be the case with any sort of planning. So long as you are getting correct maneuvers otherwise, you can simply drag the point around until you get a solution that works and gives you good fuel usage. Planning a transfer from LKO to Minmus isn't a challenge, it's a chore. Sure, it might make sense to have to do it once or twice to get the idea of how it works with maneuver nodes, but being able to simply drag out the trajectory thereafter is a great idea. And there is no significant technical challenge in it.

That can be a part of it. But it'd be good to have some of it achievement-based. We know that we will have supply routes. These can work in reverse as well, bringing materials back to Kerbin and generating income. It would be yet another reason to build colonies. Something like this can work for contracts-like system as well. If you needed to do the "position satellite" type contract once, and then you could set it up as a "route", it'd be far less annoying, but also gives you reward based on your performance. The cheaper you manage to make the launch, the more profit it will be generating for you.

Presumably, you have Kerbals actually overseeing construction, and presumably, they are still getting paid. It's no different to how you still want to be paid on a ship that's at sea for months at a time. Sure, you're not going to spend that money on the ship, but it doesn't mean that you signed up to do the work for free.

I don't think we've heard anything about it. But it looks like KSP2 is using the same monobehavior GameObject patterns in Unity as KSP, so DLL plugins would be the most straightforward and easiest way to make it happen. If they aren't planning for any serious Workshop integration, that might be all we get. But it is just me guessing. I would also like to know something a bit more concrete.

Not bad. It looks like you are using surfaces for everything. Have you tried using volumetrics to smooth it out? Edit: Wait, is the whole point to try and get it into a mod? Because then, yeah, you might not have access to these game-side. You can fake it with a bunch of planes and a clever shader, but that's a different level kind of work.

Are you suggesting using slave labor? On a serious note, though, adding currency as one of the resources creates more opportunities to balance gameplay and progression. You can always come up with a story justification to it, and you're just handicapping your design by throwing it away as one of your tuning knobs. I think currency costs should stay. But the way you generate income should be more related to progression than mindless grind.

I would honestly prefer something like the mission editor in Making History to work with multiplayer, so if we want to create multiplayer races, CTF, etc kind of games, it'd be easy enough to set up. I don't think that's something that Intercept should be trying to hard-code into the game, as we really have no idea what will and will not be fun. With a mission editor, community will figure it out incrementally.

Well, there's code and there's code. The problem with KSP mods is that they are distributed with a compiled DLL plugin. That can contain absolutely anything and is about as secure as running an executable you downloaded straight off the internet. In fact, in a lot of ways even worse, because it's easier to sneak a DLL file past antivirus software, as it might not match any known signatures, and malicious behavior is easier to obfuscate if you can use engine API for parts of it. So downloading a stranger's KSP mod is a huge risk. The reason this hasn't flared up yet is because KSP modding community is fairly niche and basically works on reputation. With KSP2 reaching for wider audience and if there will be Workshop support, this all goes out the window. A bad actor with burner Steam account and KSP2 key could hit thousands or tens of thousands of machines with malicious software, and that will make it worth it for somebody. There are ways to address it. Unfortunately, I haven't looked at either Cities Skyline or Truck Simulator mods, so I can't comment on these specifically, but there are safe (to within reasonable definition) ways to distribute code with UGC. The general approach is to create a sandbox for imported code. Even an executable is reasonably safe, because if you create a separate process with no kernel modules, and only provide your custom API, which is carefully designed to prevent malicious operations, then all the code can do is talk to your API and perform actions in the game. In that case, worst it can do is break something in the game. This is a lot of work, however, and I wouldn't even fully trust myself with something like this, so this would take a security expert hire to do this right. A better approach is to run the code in some sort of a VM. Now, there are plenty of stories where VMs have been exploited to gain arbitrary code execution, so not just any VM will do. Fortunately, the entire internet relies on existence of fast, reliable, and secure VMs - specifically, for JavaScript on web pages. Letting modders run JavaScript is an excellent way to have them extend the game without creating giant security holes. JavaScriptCore used by all iOS devices or V8 used by Chromium and Android devices are good candidates, as they are well tested and open source. The only disadvantage here for a game like KSP2 is that you'll need to make sure your API has JS bindings, but C# actually makes that very easy with Attributes. At work, we are using these to create Python bindings inside all of our C# tools, and while it's a bit of an effort to set up a custom attribute like this initially, thereafter, any API call you are using in parts code you want to be accessible from JavaScript would just take something like [JavaScript] attribute and just work. From there on, it's just a matter of making sure your API doesn't provide any arbitrary file or network I/O and you're set. Finally, you can run your own VM that you make sure cannot be exploited. It's hard to do in general, but as discussed in logic gates thread, VPL is actually a good way to achieve it. It's generally a lot easier to secure a node-based script, because all the relevant data can be required to be stored within a node. Then even if you transpile the VPL into bytecode for evaluation on conventional VM for efficiency, so long as you only distribute the raw VPL with your Workshop entries and your transpiler does good error checking, then you can have all the performance of a good bytecode VM with security and ease of use of VPL. Win-win-win, but not just any software engineer is going to be able to set all of this up. It requires a fairly senior person with background in scripting, so unless there is strong desire to have VPL in KSP2 in general, I would still go with JavaScript as a better option for Workshop. (Links all over the place, because I realized I'm using too much jargon and abbreviations.)

If the mod only contains assets, it's totally doable. But you don't want any mods with custom code coming through the Workshop. It's a huge vulnerability. Still, would be nice for mods that just add custom parts that rely on standard functionality.

@ARS Yeah, you can have a supersonic shock in water. The speed of sound is a lot higher, however, so it happens at much, much higher speed.

Per weight, LH2/LOX is pretty close to as good as it gets. Both F2 and ClF3 are better as oxidizers, but so much nope for being just a little better than oxygen here that I don't think anyone's even considering building an engine with these. I don't think there is any way to beat HF as your exhaust if we disregard engine materials, pumps, tanks, storage, etc. So that's probably as good as it gets. If it's important to you that your fuels are liquid at room temperature or you want higher density for smaller tanks, that's where the field opens up a bit, but we are already talking about combinations that are a lot worse than the above right away for these use cases.

Part of the problem is that I might not know what I'll need to launch in advance. Usually, in KSP, I can just open up editor, delete the top part of the rocket, and build the payload I need, then snap the rest of the rocket back on. In order to have pre-built rockets that took up construction time, you would really have to re-think how we design, build, and deploy rockets. I think that's a little too much. We are going to have supply routes. Maybe complexity of the rocket you assign to a route can influence how often a launch can take place, because it would take time to build that rocket. That'd be a neat little mechanic. But I'm not convinced it fits core gameplay.

What you care about is exhaust velocity, which comes down to 1) Amount of energy released, 2) Mass distribution of the products, and 3) Mechanical degrees of freedom in products. Being a strong oxidizer doesn't guarantee any of these things. While the reaction is likely to be very exothermal, it doesn't mean that a more reactive oxidizer gives you more energy. And if it gives you more energy but at a cost of heavier compounds in the exhaust, or if a lot of that energy goes into vibrational degrees of freedoms of complex molecules, then you're not getting more thrust out of it. There are other considerations too, but you might have ways to work around them with engine design. If you don't get high kinetic energy of combustion products, then you aren't going to fix it. And because of that, you can't just look at oxidizer in isolation. Same oxidizer will produce very different amounts of energy and complexity of products with different fuels. So you have to consider oxidizer/fuel as a package when discussing whether it has a potential to make good rocket propellant.

It's been a while, but I think Babylon 5 came close to these kinds of scenarios during the civil war arch, and the Earth-built fighters actually had very realistic physics.

Anything you can handle without breaking game physics or gameplay, especially in multiplayer, would be lackluster and boring. In principle, you can have stellar mass compact objects, be they neutron stars or black holes, but the reason these don't present a problem is because your ship will get destroyed by tidal forces way before you get to relativistic velocities and start causing problems. And that's why it doesn't matter much if it's a black hole or a neutron star from that distance - you are nowhere near the surface of a stellar mass neutron star, let alone the event horizon of a stellar mass black hole at that point. So it's just a compact object you wouldn't even be able to see that you can maybe use for an extreme Oberth maneuver. A supermassive black hole is far more exciting, as you can traverse its event horizon in one piece, but that comes with all sorts of technical problems. Orbits near event horizon aren't conic sections, so you have to properly integrate them as if you were doing n-body physics, and even then, doing so with relativity in mind is problematic. Time dilation alone, which diverges at actual event horizon, seems like an absolute gameplay barrier. So compact objects effectively come in two varieties, as far as implementing them in KSP goes. Game-breaking or boring. That said, one thing that might actually be exciting is a red giant / neutron star binary, with giant's atmosphere being swirled into the neutron star. And though you probably couldn't get close enough to that neutron star to have any real gameplay reason to do so, because yikes, it would, at very least, look absolutely spectacular, and could still be an interesting star system to explore. That's the only kind of stellar mass compact object that'd be worth having in KSP2, in my opinion.

For games like KSP, I kind of like the approach of things working correctly under the hood, and then presentation gets simplified for the player. Like, when you are running a rocket engine in the game, it needs to be fed oxidizer and fuel and will give you different thrust depending on the fuel flow and external pressure. But what you, as a player, get presented with, is just a throttle axis that you set as percentage of maximum thrust under given conditions. The game figures out for you where the engine should get fuel and oxidizer from and how much. In a similar vein, if we had some sort of a method for combining sensor readings to improve quality, I would probably expect the game to solve it correctly, such as by using Kalman filter, but that can be done completely in the background. As a player, all you should see is that if you collect more data, you get better precision. Of course, there is still a matter of when and what data should be combined. A classical use case in robotics is combining range-finders and accelerometers when you want to keep track of position and velocity. This sort of goes back to the GPS discussion above. Roughly speaking, if you have a GPS or similar distance-based measurement of your position, you can look at changes of position over time and compute your velocity. Because you are taking multiple measurements, you can have very precise measurement of your velocity even with significant uncertainty of position. So a GPS might only get your position within a few tens of meters, but it will track your velocity to within a fraction of a meter per second quite easily, because it will measure your position a bunch of times and take an average. Problem is, this kind of measurement takes a while to respond to any changes. Clear on the other side, you can measure accelerations and adjust velocity estimates rapidly. Problem is that the errors in this measurement accumulate over time, so if you try to measure velocity only from accelerometers, the result will drift over time. So the solution is you combine the two inputs, again, with something like Kalman filter. That can give you very precise velocity measurements that are stable over time and respond instantly to any acceleration. For the game, I suppose, this could be presented as a purely inertial navigation unit to begin with, which can only be so precise, and then can be "upgraded" by placing more and more satellites or ground stations to augment the position and velocity readings. That seems like a reasonable option to do something like this. Clear on the other side, of course, is the DIY approach. If we get scripting or some other means of performing algebraic and logical operations on sensor input, then it could be an interesting challenge to build your own filters for collecting and combining data from multiple sources. That does, however, start crossing into a different kind of game.

There is a lot you can do with existing sensors. Like, if you are on Kerbin and you need to get altitude, you can make an inverse pressure curve in KAL-1000, feed barometer reading to it as scrub position, and you'll get altitude on the output. Yes, only relative to sea level and only within the atmosphere of a specific body, but it's a great start. Likewise, an accelerometer fed into the play rate input of the KAL-1000 can be used as an integrating accelerometer. Infamously, a pair of gyros and a single integrating gyro accelerometer comprised the guidance of the V2 rockets, so you can do quite a bit with this. Of course, this is invention out of necessity, and it'd be easy enough to add a few extra sensors to make things a lot easier. A barometer might as well have a direct pressure-altitude readout that adjusts for whichever body you're on, provided it has atmosphere, of course. Gyros seem like a must. Ground radar can work great to give you altitude, up to a limit, relative to ground on any planet or moon. I am a bit less confident about something like GPS. Without having to build a constellation, it feels overpowered, and making something that works with arbitrary constellations a player might build becomes far more complex than simple sensors we are talking about. But since we are talking about KSP2, there is a piece of proposed tech that gives you GPS-like capability anywhere in the galaxy. Pulsar navigation is still very much in experimental phase, but it can, in theory, get you precision to within a few hundred meters anywhere you might reasonably end up going. And since it uses pulsars that nature was gracious enough to place for us already, it requires no special construction. Just a set of x-ray sensors and some analysis software to count the pulses and do the math.