K^2

Nah. A Designer/Artists/Engineer leads + senior Eng is something you do for a new game, not a port. The recs for all four are way above what you'd expect for the title, so this is intended for a team that's going to grow. It can still be DLC, but spin-off sounds more likely. And yeah, that desc does make mobile unlikely. This is either stand-alone console/PC Unity title or a fairly serious DLC.

These things, they take time. So it's not out of the question. But it kind of sounds like a skeleton team for a pre-production work on something that hasn't even been fully approved, let alone announced. The fact that there's a Lead Designer and Lead Artist that go along with the two eng jobs sound about right for this as well. Whatever it is, it's definitely space-related, almost certainly still KSP IP, and is going to run on Unity. That still leaves a lot of room. Exciting. Good find.

These are partial derivatives. I'm not entirely sure what L is meant to stand for, but first one is how volume changes with pressure at constant temperature, second how it changes with temperature at constant pressure. These are related to compressibility and thermal expansion. I suspect that L might be "limiting" as in "limiting flow," which would make sense for a rocket exhaust, but I'm kind of guessing on it. Mass per mol. Critical velocity of the fluid. Abbreviation for "sonic velocity".

Not really. You can get 1T to 1km/s for about 140kWh, which is less than $100 of electricity from outlet. (Potentially, way less, depending on where you live.) It'd be more expensive to produce that power in space, of course, but it's still not a lot of energy. Recoil still has to go somewhere. If your launch system is in orbit, you can't exactly tether it. If ships are constantly coming and going, then maybe the net impact averages out pretty well, but if you're just using it to send things to outer Sol, you'll quickly run into a problem.

They're different states. It might sound like pointless demagoguery, but it actually matters when you start counting possible states a system can occupy. Say you have two coins. Each one can be heads or tails. You have 4 possible states. HH, HT, TH, or TT. But if you can't tell between the two coins - if they are truly indistinguishable on most fundamental level, then TH and HT are the same state, and there are only 3 possible states for the system. Elementary particles behave this way. You don't count exchanges as distinct states - they are all counted as a single state. And this actually has consequences on things like entropy of the system.

I wouldn't bother repositioning ISS. With this lift capacity, we can build a station whose habitable section is actually designed for 1G. Not to mention that you need the hub, the counterweight... This ought to be a new construction. And probably in much higher orbit to reduce tidal effects. Yeah. Black-body radiation page has a bit more info. Ooof. So I can probably dig into a bit more if you want, but the very short version is that all particles are identical. It is fundamentally impossible to tell between a particle moving and a particle being destroyed and new one created in the new location. In fact, the later is how we describe propagation of particles in QM. So this gets very philosophical very fast. I can claim that "they are all the same photon," as particles are indistinguishable. But I can just as easily claim that a photon only exists for an instance in time and no other photon is the same photon, because no photon at any other instance of time shares that same state (which includes time). Scatter, absorb, or both. It's not just about density, though. Water has almost the same density, but will cast only a very faint shadow, while there are plenty of gases opaque enough to absorb light. Interaction between light and matter can get fairly involved. Yeah, that's how radiative heat works. Of course, there can also be convection - if you hold your hand over a hot object, hot air rising from it might be heating your hand directly. Unless you're in a vacuum, it's almost always some combination of radiative heating and heat transfer from environment. this is just about the time it takes for energy to propagate out of the star's core. There are a whole bunch of state changes along the way, and this eventually leads to emission of light in photosphere via black-body radiation as described in an earlier link. It sounds like your understanding of the process is essentially correct and the article is just poorly written. Edit: Ninja'd by @AHHans I could have written a much shorter post.

I know we've been stuck for almost half a century without a superheavy, and that kind of warped our perception of what we can reasonably construct in space, but with SN20 scheduled to take flight this year, giving us ability to put 100+ T to LEO in one go, which is a quarter of the entire ISS mass, should we start talking about at least a tethered centrifuge station? It seems like a silly waste of time to even experiment with trying to acclimate astronauts on Earth when 500m of cable solves the problem pretty much completely in orbit.

Sort of, but linac is a lot cleaner. Rotation gives you an illusion that you can accelerate gently over time. But reality is that you are still moving in exact opposite direction from one side of the loop to the other. Which means you have to have accelerated in between. A circular rail just trades linear acceleration for centripetal, and you still have to deal with extreme G forces. With a linear accelerator, what you see is what you get. If you can build a rail 1km long, then you have 1km to get to whatever target speed you have in mind. Unfortunately, 1km is really, really not a lot for speeds we want to build up. In terms of practicality, not to rehash all the conversations again, unless you can get your cargo up to something like 10km/s at a significant angle up, a sea level rail-assisted launch just isn't helpful. If you want to get any sort of benefit from rail launch, the exit point has to be in rather thin atmosphere. As supporting something like this with a static structure is pretty much impossible, we kind of end up all the way back at launch loop concept. Which, you know, is a thing, but not exactly on currently achievable scale.

Flying in VR would certainly be a gimmick, but it's also so easy to set up VR in Unity... And if Intercept is already going to support mouse interactions in IVA, which sounds like they ought to even just for parity sake, adding ability to use hand sets to interact with controls is almost trivial. If there are any concerns, it might be worth marking it a beta feature, so as not be forced into supporting some weird edge-case problems, but it really is worth adding support even just for giggles at this point. And VR VAB sounds like great fun. Being able to walk around the rocket you are building giant-style might actually be a good way to build it. It only takes a few minutes playing with something as basic as Tilt Brush in VR to realize that building things out in 3D space is uniquely satisfying. The flip side, of course, is that this would actually require a special UI. And now it becomes a feature somebody would have to spend not insignificant amount of time against. So I'm honestly not sure it's worth it. Unless somebody takes this on as their onboarding or intern project, or even just goes overtime on, which does happen occasionally, I don't think it's happening.

Yeah, but a lot of games actually simulate recoil fairly realistically and have punishing ammo economy, so you learn to use bursts there as well. But I also agree with @JoeSchmuckatelli that, for a game, it's a style choice, and neither is the wrong way to do it. I was merely pointing out that there is no inherent reason for this to be a Russian vs Western choice in game design. It's true that U.S.-made FPS have lately been going far more into... I don't want to call it realism precisely, but maybe less suspension of disbelief? At least, as far as firearms themselves go. While Russian games still have a lot more of that old school Doom and Quake feel to them. Maybe because we got these games in Russia a bit later, and they are more recent in everyone's memory? Idk, but I grew up on Quake II, where recoil was something you learned to compensate for, but never a reason to let go of the fire key. And yeah, it's a completely different play style.

This is definitely game being a game. I don't have first-hand experience with Soviet/Russian military firearms, but I know plenty of people who do. Because AK family of rifles lacks burst mode, using short trigger pulls for controlled bursts was actually part of training. Simply letting 'er rip in auto is not a thing you were trained to do ever. Most of the time, the rifle would be in single fire mode, just like you'd expect on US counterparts. And just as you describe, even in a short burst, only your first round goes where you send it, the rest going way high due to recoil, meaning you'd only ever use this for suppression or at short range. So really, the biggest difference is that you don't have a handy 3-round burst mode on an AK, requiring a bit of practice to achieve similar effect with full auto on selector. Spraying bullets from anything but a mounted weapon is purely a game invention, as far as I can tell, and has no basis in fact regardless of country of origin.

"You'll need a notepad and a logarithmic ruler," is pretty typical of Russian game design. TBH, I'd probably veer that way myself if I haven't had real game designers slapping my hands. "No, bad Konstantin," they would say, "We are not going to edit this properties sheet with a hex editor. Gives us a GUI."

Yeah, that's kind of what I expect if both players are strangers. Given that loss of C2 just costing you time, it's basically a free double-or-nothing with added risk that the other player is thinking the same thing and you don't want them to get the drop on you. Without having some prior communication, the most reasonable thing is to start shooting. But that doesn't mean you can't team up for an ambush. There is very little benefit to attacking another C2 until there is loot to split, and opening fire just attracts attention. The reasonable thing to do is to just go your own way if there is no C1 or other loot in sight, and to temporarily team up for an ambush if there is a C1 you might take down. That said, player "culture" is important here. If it's common for other C2s to attack each other on sight, then you're not going to fix that simply with the fact that it's not the optimal strategy. In which case, your best option is to just stay out of everyone's way as much as possible. If any C2 is immediately a hostile, you win nothing by provoking combat. Yeah, you might win, and maybe you'll get a bit more loot out of it, but you just attracted attention, and now your odds are significantly worse. One more option, and this is definitely an "if you're good enough," and AI has predictable patterns, is to shepherd an AI. If you can stick to cover and still have good vantage on whoever that AI picks a fight with, you might get sufficient advantage if C1 player turns out to be not very good or already wounded, while still leaving yourself an option to make yourself scarce. It's a higher risk strategy but with higher frequency of good payout, so it might be viable for some players.

So presumably, C1 can't distinguish between C2 and AI on sight other than by observing behavior, meaning that C1 will probably attack C2 on sight, simply to avoid risk of letting AI or hostile C2 fire first. Any incidental loot you get from C2 is bonus in this case, but not primary motivator. In that case, correct C2 behavior is opportunistic scavenger. Consider other C2s and AI to be your team mates unless they show aggression towards you, but keep in mind that if there is shiny loot, like a C1 corpse, it will likely result in fight for the spoils. Avoid C1s - since they are unlikely to go look for you, it shouldn't be too hard. C1 players who charge after any C2 they see are unlikely to do well in the game, so at least, they should have weaker gear. So try to run away first, and then take the fight if chased. At the same time keep an eye out for opportunity to take out C1s with overwhelming numbers. Again, it'll likely result in a fight for the spoils, but it's a great opportunity to pick up good gear. The hard part to determine without playing the game is the threshold for risk. Is 2 on 1 good enough odds to risk it? From description, sounds like it's not. But maybe if you have 2 C2s to ambush and AI to create a distraction, that can work well enough. Ability to communicate with other C2s is a big part of what's going to set the balance here. If you can co-ordinate, there are a lot more situations where you should take the risk and try to take down C1. It also gives you an opening for bargaining instead of fight for the spoils. If there is no communication, you'll probably want a larger group to take down C1 and be prepared to tail it if it doesn't go well.

Ok, yes, if you have a flawless lens hundreds of km across and a laser source with coherence length several times that, you can project the beam to 10ly. I hope I don't need to explain why that's problematic from engineering perspective. Also, lasers with that fidelity don't exist, but we can get up to about 100km, so maybe that can be pushed a little. We might be able to do a lot better with microwaves, because we can actually adjust phases dynamically to create an effect of perfect lens of such size, which might be just as good for propulsion, but it won't be helpful in clearing the path at all, as the absorption is going to be pitiful. That said, if you're just sending an unmanned probe, maybe you just take the beating. Build your electronics with enough heft and redundancy to take the abuse from radiation and don't even worry about it. It's still going to be generating considerable drag, and you'll have to account for it in your acceleration phase, but even if you just cut out a cylinder 10ly long and 1,000km across, there's only about 125kT of matter. For comparison, if you made the 1,000km sail out of heavy duty kitchen foil, it would have a mass of 50MT. So if you don't get into hyper-relativistic speeds, you'll only lose a small amount of your velocity to drag on such a mission. On the net, my only correction to above would be replacing a laser with a maser, and this is with help of hindsight that we've developed way better means of manipulating microwaves compared to what we can do with optics at relevant power densities. There have been more recent proposals for probes with a lot more acceleration and, therefore, much shorter travel distance before they start coasting. These can be done with optical lasers, since you only need to project the beam, maybe, a few AU. Of course, these designs assume no return trip and either a rapid fly-by of target system or a completely independent braking mechanism.

This is fine while you're riding out of the system, since you're going with general direction of the solar wind, but once you're out in interstellar space, at about 90-100AU out, you're going to hit a "cross wind" sufficient to carry in matter from outside your direct path. Of course, you are unlikely to be using laser propulsion at these distances anyways, but in either case, you can't rely on this technique outside of Sol system. And, of course, you're going to have a whole new problem on arrival, as you're going to hit the solar wind of target star head on. The good news there, however, is that you'll actually want that drag to help you slow down, so using magnetic shielding is absolutely the right thing to do at destination. If you don't have active propulsion in interstellar, however, magnetic shielding might be generating too much drag...

If you have a strong magnetic field and are moving fast enough, you can ionize incident matter, so this isn't just for charged particles. Obviously, at that point, you are adding ionization energy to net drag, but this might be the only viable option for traveling at relativistic speeds, and the faster you go, the less significant is ionization energy loss compared to ram pressure. You do need a beam core AM or some variant of black hole drive to have the kind of power you need to make it work, but it's physically possible, at least, and it's unlikely you'd be getting to speeds where it's crucial to have without something like it anyways.

Yeah, but that's somewhat uncommon. The marginal utility of fuel is really low at that point, so it only makes sense when you need just a bit more oomph and you are using high ISP fuel, like LH2. Yes. Not just crewed, either. You rarely want to go much above 3g if you can help it even purely from perspective of efficiency while still ascending through atmosphere. Of course, if you're going up on solids, you might be forced into higher acceleration. So it varies, but generally, you don't see anything much above 3 - 3.5. So like I pointed out above, it's really not optimal. Ideally, you want to start your ascent at 2g and ramp up to 3 through gravity turn, then ease out a bit as you're exiting atmosphere and settling into your orbit. But this is wishes being horses kind of thing. With constraints of real engines, you usually start bellow 2g to build up to these 3-3.5 I've mentioned above. Getting 2.4g from the pad is an interesting choice. I have a feeling they're optimizing for something other than fuel use, exploiting the fact that solids are relatively cheap, and you can just have a bigger booster. I should take a look at what their ascent looks like.

I'm not sure that's possible with Unity, tbh. I mean, suppose, it took you 1s to compute one frame of physics, but there were not graphics stalls and you render on a separate thread. Common enough. You can probably keep rendering at 30 FPS on that thread and get 30 frames of graphics into that 1s of simulation. But until the simulation is finished, no positions are updated, so you have 30 frames of all the parts being in exact same place. At best, it looks exactly like if you simply ran at 1FPS. At worst, it looks a lot worse, because maybe the camera angles and FX are still updating, and now it looks like the rocket is just strobing from position to position in an otherwise normal framerate world. It is possible to interpolate, of course, but that has to be supported at engine level and would involve special kind of update path for physics objects. That seems like a lot of work for an edge case that shouldn't happen in most games. Of course, KSP isn't like most games, but I doubt Unity would implement this feature just for the few exceptions. And maybe I'm completely wrong about this, but I don't think there's a simple way to get around it without engine support. What's usually done is that physics runs at some multiple of graphics framerate. So if you are rendering at 30Hz, physics might update at 30Hz or 60Hz. Maybe even higher for a racing sim or something. But if either rendering or physics starts to lag, the framerate will drop for both. And then you get a choice of whether the time step in simulation gets very large and you get all sorts of instabilities, or you stop running sim at 1:1 with real time, and things slow down. But you are still getting choppy framerate, because your limiting factor is literally how often you can update where everything is.

That's the sort of thing they'll have to evaluate on a case-by-case. Some modules might be worth getting rid of, while others are easier to just keep around. It's not about weight, after all, but about drag, so there are a lot of places you can put a dead module where it won't make a big difference. Same deal for repairs. A puncture's easy to fix. But if the module was partially crushed by impact, it's probably too much risk. A module that might pop a seam at any moment is not worth keeping pressurized. I think, the biggest change from Mir, in part due to this accident, is how the cables between modules are managed. They had to sever them by hand when Spektr sprung a leak, cutting some of them IIRC, and that very nearly resulted in having to evacuate much, if not all of the station. I'm pretty sure ISS doesn't have anything you can't disconnect on a spot to shut a hatch. On the other hand, I haven't seen anything that looks like it might shut automatically. So if there is more serious damage completely exposing a section to the vacuum, I don't know if anyone would have time to do anything about it. Maybe somebody more familiar with ISS can correct this.

Nothing slow about rockets taking off. They do tend to have a bit less than 1g of acceleration from the pad, but not by a lot. And once some of the fuel burns off, it can be well over 2g. You can also do the math really easily. You need about 7.5km/s to orbit. Ignoring losses and ascent trajectory, that's a bit over 750s at 1g or 12.5 minutes. This is very rough estimate, but still, clearly far greater than ~8 minutes taken by typical rocket.

You'd be moving a smaller mass but a larger volume. I also expect hydrogen gas to have more viscosity at the same temperature, since lighter molecules are going to diffuse faster. So you are going to have a significantly higher pressure differential at higher flow velocity, and that means a lot more energy consumed pushing the gas through the pipe, but more importantly, it will require the pumping stations to be able to handle the higher pressure and power requirements. This might also put a limit on how far you can push gas along a given pipe, since they are rated to a specific pressure. So if the pressure differential has to be higher, some pipelines that are close to the limit might become overpressurized with hydrogen unless you subdivide the length and put additional pumping stations in the middle. This is definitely not a case of, "We'll just swap out the gas and everything will work." Some amount of retrofitting will have to be done. Hydrogen also leaks and ignites a lot easier, so there will be more accidents, further increasing costs. Whether that's significant, I don't know, but something to consider for sure.

I mean, it's not like they hired Erin Catto. The guy Intercept hired has the background, but unless he's been writing his own game physics engine in his free time, I don't think he has the experience. Given the background, I have very little doubt he can learn all of it, but that takes time. And part of the issue here is that you can't really fall back on PhysX for anything, as it has very poor performance in the thing that really matters here - collision detection. So to get high performance out of RUD on large, complex craft, you'd have to implement the whole physics engine. As in the sort of thing Havok does exclusively as their business model. Yeah, they have a lot of bells and whistles you don't need here, but to handle general carnage, you need collision tests between various primitives, preferably something you can farm out to multiple threads; a dynamic BVH to keep the test count reasonable, which also means a system that can update said BVH; to generate contact constraints for intersections in addition to any constraints that come from the structure; some way of splitting collision groups into islands; and finally, generic constraints solver, one that respects limits. This is a lot even if you know exactly what you're doing. But each of these also has a bunch of little gotchas that you wouldn't think about until you trip over them. I think I can write something like this at ship quality and fully optimized in about a year. But a) that's literally been part of my job for years and b) this isn't the only thing a physics programmer at Intercept is going to be doing. There is aerodynamics, orbital mechanics, various components that might interact with physics, and all the bugs in all the even remotely adjacent systems that are going to shake out. And this is Intercept physics programmer's first game job. Someone out of postdoc is no novice by any measure, but work at academia is very different from game studios, and it does take some adjusting. So yeah, it might sound like he has 2+ years to implement good physics for rockets in KSP2, but realistically, he has a few months of work he can dedicate specifically to that. Maybe a year total if we're being generous. I'm not going to say this is flat out impossible, but I would bet heavily against it. On the other hand, if we treat the rocket as a single body, things get a lot easier. You can either ignore all self-collisions or drastically reduce the number of tests you need to run. That way, you can rely on PhysX to handle collisions and any contacts generated. All you have to do, then, is reconcile any forces applied to the rocket. And again, if you start with assumption that the rocket is rigid, you can very cheaply compute approximate stress, use that to seed the undetermined multipliers, and then run one round of constraint solver specialized to weld constraints, which is a lot easier to handle. That's still a lot, but if you're experienced writing FEM code, there are a lot of similarities here. So I think they hired a person with the right background, and we'll see how much he manages to implement in the game. I think good framerate for high part count ships (~1,000 parts) in flight is a reasonable expectation and good frame rate when these ships blow up isn't. But we'll see. And we're still likely to get much, much better performance than in KSP in all situations. Both from general improvements to Unity engine and from work that Intercept's going to do to make KSP2 better. At least, there's no excuse for not making it better based on what I'm seeing.

PROCEDURAL WINGS! The rest is good too, but that just eclipsed everything else we got from this video, IMO.

Yeah, I don't think that's going away, sadly. I think, Havok physics would do a lot better, but it doesn't sound like we're getting that with KSP2. So the three options are either to re-compute all of the stress matrices on the fly as joints break and parts get destroyed, which is slow; to just give up and let PhysX do its thing, which is slow; or to re-write the physics solver completely from scratch, which is... I mean, it's actually not that difficult if you have experience with constraints solvers, but it's not something you just throw together in a month or two. You can build a prototype on this time scale, but then debugging, polishing, fixing some special cases... It's a lot of work. So I can't imagine us seeing completely custom generic solver in KSP2, and that means that bad performance during RUD on ships with excessive part count is unavoidable. But I'll take it if it's only during RUD and we can get good performance during flight. And a custom solver for this special case is very much doable with the time Intercept has and, hopefully, with this particular hire leading the work. Fingers crossed.