t_v

They have already said in an earlier video (I think it was the celestial architecting one) that they had deprecated that UI, so I’m not sure why it was shown in the dev diary. Maybe that footage was form a while ago?

Well, I can’t see anything here. Unless someone finds something on another platform, I don’t think they posted anything today. Edit: sorry, the team just posted something. It is in dev diaries

Sorry for misconstruing your previous statement, I should not have assumed your intent.

So, apparently on top of awards, there are a ton of reveals for new games. Usually, these are games no one has seen before, but some people think KSP will re- reveal again. I’m not sure that it will, but I think that that is what people are talking about.

They are being cynical, the release of halo Infinite does not have an impact at all and they are comparing it to us talking about the game awards, with the implication that those don’t make a difference either. I don’t now about the game awards so I can’t tell if they could have a reveal or not.

Sarcasm? No, definitely not.

So, you lose a lot more energy proportional to the amount of energy that your propellant releases, but you get a lot more energy out of your propellant. Or at least that’s my understanding of it. Essentially, the reaction going on in the NERV produces less energy than a small nuclear explosion per unit of fuel, which is enough for the pulse engine to have a higher isp than the NERV. In terms of bombs vs liquid fuel, the packing density makes less of a difference than the material that you use. Remember, NERVs heat up regular fuel via a small amount of nuclear catalyst, whereas the Orion engine contains fuel that is almost entirely fissile material, packing a much higher energy density than the fuel. One thing to note is that as you get into fusion engines, those engines will rapidly outpace the isp of the Orion and the NERV, because fusion creates a lot more energy than fission per mass of reactant (at least I think so). If you have played modded, the powerful nuclear engines that you have probably played with are fusion, and in those cases having a nozzle (or at least a magnetic nozzle) is helpful for capturing all of the energy.

99%!? How are you so good at predicting weather?

I think that it is very important to distinguish between numbers like we are being shown here and mathematical formulae, abbreviated to maths in this thread. In particular, I want to try to explain @Bej Kerman’s comment which created this reply. I get the feeling that a fair few games have numbers in them that players interact with, from survival games managing resources to strategy games managing… well, resources, even to platformers which represent their numbers in distances in a tile system. One thing platformers do well is that the numbers are presented very intuitively and are well incorporated into the games, literally being the levels, which allows players to more easily interact with them, and I feel like KSP could also do a bit of a better job making their presentation of numbers more intuitive. But I digress. The point is, lots of games have numbers present, but don’t ask players to consciously do math with them. In a game of Civilization, I might be factoring in lots of numbers, from troop movement times to manufacturing delays, but I never feel that I am consciously working out the math, even though I am doing it constantly. The same thing applies to KSP. I have these numbers and I fiddle with maneuvers and I do math around delta-v, aerodynamics, electricity, comms, and even heat in modded environments constantly. But it doesn’t feel too math-intensive because there is a calculator always present in the game in the form of all those readouts above. Now, I am not at all opposed to the option to have those calculators be visible as opposed to just getting the result of the calculation, but the point here is that the numbers currently present are not to be classified as the same thing as the suggested formulas. They occupy different places in people’s brains even though they are connected, and so the case for formulas needs to be predicated on something other than the current delivery of information in the game.

In terms of stats, it has a higher isp than the NERV and a much much higher thrust, so it will probably be in the middle of the tech tree, rather than near the bottom, although hopefully with a lot of engines above it. Also, for recurrent missions, I’d like a menu where you can manage the frequency of missions or even cancel them to balance resource transfer rates.

In theory I agree with this, but I feel that the implementation has to be really good for it to work, which might rule it out of the stock game. First, the default options need to appeal to the least interested people, so the math should be off by default to not scare away math-phobic people. Second, the UI can’t simply display equations but instead needs to let players interact with the math in a way that is relevant to the mission. For me, this means a menu where players can see the equations with numbers plugged in and can enter a desired characteristic (orbital period, inclination, apoapsis etc) and then see the changes that need to be made to get that, and then on top of that there would need to be an easy way to integrate that with maneuvers, probably with a one-click to create maneuver option. The benefit to this is that you could really get precise and make much more complicated maneuvers such as getting gravity assist chains by tweaking orbital period without having to fiddle with stuff. But all of this is very very difficult to get right and imo, it should not be implemented into the game if it is half-complete, as that would worsen the game for a lot of people.

Decidedly not, but say I had a large craft spiraling through the system, I would want to be able to take my depleted craft and hitch a ride towards a planet, and I could turn off the thrust for a few hours while I get around to docking

Well, as long as that probe is burning at a constant thrust, it’s trajectory would be set (as in you could see the trajectory spiral that the initial post was proposing, and that spiral is not changing) and the times it would need to slow down warp would be already calculated and stored, so likely the worst interruption to your interstellar mission is a probe that is slowly spiraling from a ringed planet and passes through the rings, slowing the warp, although this interruption probably wouldn’t last more than one pass through said rings. Other than that, most missions can simply follow their pre calculated trajectories without worrying about time step, similar to how it is done in the current game. Essentially, thrust under time warp will work just like regular time warp but with a different looking trajectory, and in some rare cases will just end up slowing your time warp down for a few moments. Edit: for the UI, a simple toggle probably wouldn’t work. One user story that I want to submit to the devs is “I want to be able to rendezvous my (normal?) craft with one that is under constant thrust” which means that I need to see on my map screen both a normal orbit and the constant thrust orbit, so it cannot be a toggle. Either there needs to be an automatic way to identify a craft as constant thrust, or there needs to be a way to set it on a craft-by-craft basis.

Yeah, rotation seems like a nightmare, but going back to the problem of stuff like SOI changes, I’m optimistic because we’ve seen that the devs have already implemented systems that do better than simple steps in the form of collision detection. As @K^2 has pointed out, there are many problems with managing short-time events at high warp, because depending on the step size, the events will play out differently. To fix this, an algorithm can be run to detect the times at which the time step needs to be reduced, such as when flying through a ring or entering an SOI. As people pointed out, an algorithm like this is computationally expensive, but I think that can be countered by the fact that it only has to be run when changing parameters, and not throughout the course of the trajectory. So overall, I think that attaining realism doesn’t require a smaller time step all the time, just a one-time-run function that will determine when to apply those smaller time steps. Another thing that I want to bring to the discussion is UI. I don’t want to see my trajectory for if I continually thrusted for most craft, only the current trajectory so that I can cut off thrust at the correct moment, but for really weak ion engines I would appreciate it. So how to differentiate it? First, I don’t want two trajectory lines at once, because that would be really annoying and all the nodes would clog the screen. Second, I don’t want engines to be preset one way or the other. Maybe I want to use my Daedalus as a landing engine and want to see my landing trajectory without having to contantly cut the engine to check it. So I think there should be a key bindable toggle to switch the trajectory mode. It is really not a perfect solution and adds to the mass of functions that have to be memorized because they ate bound to keys, but the point of this is to start a discussion on how to best handle trajectories in the UI

Looking at the VAB user interface, it has essentially been confirmed that you can keep the parts from a ship to minimize cost. I would also like a good way to complete multiple synchronous missions, even though with multiplayer you can have the other person pilot the other half.

We’ve seen the “lapat” file which has trees and grass, and which is presumably a different planet. The vegetation also looks similar to Kerbin, indicating that the planet orbits a similar star and that evolution took it down a similar path. Perhaps the kerbal universe was populated by panspermia and the end game will be to find an origin planet, hence the kraken which will presumably be pointing to another planet in the third secret message. I’d be fine with having actual moving animals as long as they are stuff like the kraken, where interaction is limited and it is not taken as a serious species but rather as a mysterious plot point.

I’m pretty sure this is also a feature in KSP 1 with rigid attachment. You can enable it by enabling advanced tweakables in settings or through the editor extensions redux mod.

Wait, in that photo it says "cost/stock" which I think means that you can keep the parts when you recover a craft and use them to rebuild the craft! So on top of all of the other design optimizations, you can try to go for low cost by recycling parts from other missions! This is already kind of derailing, but that is so cool.

I don't know if anyone has done this before in here, but the cinematic trailer showcases a lot of parts, and I want to discuss them. First, the bad stuff. I didn't notice any radiators that looked different from KSP 1. the biggest engines just had a whole lot of the same small radiator, and they were all the same material. If we are going to have small craft with high-power engines, I would like to see a small but powerful endgame radiator. Also, unless some serious optimization has been done, all of those small structural parts are going to seriously lag out the game. Next, the good stuff. Colonies can have absolutely immense parts, and ships share some parts with colonies, as the Daedalus ship had the exact same tanks as the dock it was attached to. Solar panels have a larger maximum size in the last colony, and there are absolutely immense dishes for long range communication. There are larger tires than before, and they don't have long attachment sections which means they are more customizable. There is also a new pod for rovers, which has a sort of hexagonal profile (not sure if this will be expanded into a whole "rover" size class but I'd like to see at least a cargo bay and battery section/probe core with the same profile) which is shown with a large stick antenna and the new storage containers, which are hexagonal. (still not sure why sci-fi has settled on the hexagon when a sphere or cylinder contains more volume for the same surface). Now, the sort of overlooked stuff. The rotating habitats don't appear to be one pair but actually a collection, with a center rotating section and an outer ring, which can be attached to the center by multiple points, indicating that the way that attachment works is going to be different than KSP 1. Or it could just be one part, but it doesn't look that way. Second thing, some ships have comms dishes put on spokes far from the central body. I'm not sure why this would be, unless it had something to do with interference and radiation, but then wouldn't keeping the dishes close to the craft, safe behind the radiation barrier be better? Anyways, that's all I found interesting. If there are more things in other gameplay clips that provide more information, put them below!

This is without skybox dimming, right? Because the moon in both of those shots would apparently overpower the stars by a significant margin. (in both shots a piece of the moon that is sunlit is visible, and from the rociante shots we know that even a sliver of light is enough. Also, even if the craft was orbiting with the moon eclipsing the sun, they would still not be able to see stars as demonstrated by images of Pluto taken at high exposure where stars are not visible due to a halo effect.) I agree with Delay here, that mods will implement many options that a dev would not have the time for, but I would still like to see some sort of dimming feature. However, I don't want it to be fully realistic, as I think those two images quoted above look great, and a fully realistic sky dimming feature would remove those.

Depending on how they manage dynamic loading, the RAM at any one time can probably be kept down to roughly the sum of the textures on screen, which is one planet+ probably 100 different part models, which could theoretically fit into 2 gigabytes, if they recycle textures (I don’t need to have a different texture for different sized blocks of metal, I can just have a “metal” texture)

Essentially, the system does just that. It has calculations to see if it will collide with objects within a certain time interval (sort of like a hitbox elongated to a certain time interval, but more optimized) and then in the tick that has the collision in it, it makes sure the vessels are in the right place to collide (this actually takes an extra tick, as you can see in the video, the red capsules are frozen for a tick all stuck together, which allows the collision calculation to happen) and then the calculation of which parts go where happens and things fly back off.

If this is implemented, having API hooks to connect it to other things via mods (I don't expect the devs to implement cameras on monitors in IVA but a mod could do it) would be nice.

Ok, so not to jump into whatever semantic argument is going on here, I feel like you (@PDCWolf) are having a different discussion than the other side. You are arguing, as far as my understanding goes, that the sky around a celestial body near, or even far from, a star is black, and therefore this should be implemented in the game. You have proven multiple times now that on the day side of any celestial body or orbiting far from the night side, the light from the sun will overpower the stars, even at ocular dynamic ranges. You have also proven that light reflecting off a craft is also enough to do so. The only time that you should be able to see stars is looking from a window away from the star and landed on the night side of a planet with a clear/nonexistent atmosphere. Done, you did it. No more need to prove that the sky is black in space. (don't pick the specifics of that, you know what I mean.) In your mind, more realistic effects= better visuals, and therefore sky dimming is a must. But this is not true for everyone. Many of the opposing people are not arguing that the sky shouldn't be black, but instead that it is not good for visuals. Before you argue (or avoid this argument as you have done for the last few posts on the matter, once again you know what I mean, don't make me enumerate all the posts), consider that this is a purely subjective stance. I may want the sky to be black, someone else might want the sky to have stars. There really is no ultimate argument to defeat an opinion, because it is an opinion and not a fact. So, how about instead of arguing whether the sky should dim for realism, which has been proven multiple times already by you and others in this thread, try either (a) closing this discussion with a request for a sky dimming option or (b) debating over whether a black sky looks better rather than whether it would exist or not.

This sounds really cool, but can someone post a link to any spot where a KSP 2 dev mentioned VR? I'm not sure it is actually planned or even potentially planned as of now.