MechBFP

Yup that is my guess as well with the exception being sandbox mode.

We would need a graph of single burns done at different attitudes between the two ships when capturing into an orbit to see if/when there is a trade off between the two. I highly doubt that burning at a higher orbit (which reduces the Oberth effect but improves the maneuver efficiency) with the higher ISP engines would be worse in the majority of that graph. I suspect that you would almost always be better off in the vast majority of that graph in fact.

I think their usage will be much more applicable once resources are in the game, as presumably nukes will be more difficult to obtain resources for.

As long as you are using them for deep space purposes only (I assume you aren’t trying to land with them, but you did bring up their impact tolerance…) then they will be better than all other methalox engines for that same purpose. But it sounds like you aren’t using them for their intended role.

They are essentially useless if you have a nuke, because similarly you need a large mass to make them useful, and it you have a large mass then nukes are superior in every way that matters at that point.

I’m just checking out at this point. Probably come back when colonies comes out, then check out for another 8 months or whatever it takes for something interesting to happen.

You called it haha.

If you start your burn early (like what you would do in KSP1) but point prograde the entire time, what is the result?

This is what I have found. Burn at the start time indicated, but then completely ignore the timer and simply look at the trajectory. I have never had an issue doing this. However if I try to follow the timer it only sometimes works.

This. Not sure if it can be rebound or not yet though, as I would prefer ` as well.

As the saying goes "don't feed the trolls". All you are doing is giving them attention with a thread like this, which is what they want in the first place.

Once again someone conflates criticism with rudeness.

Sometimes when I envision how the KSP 2 code actually works I just imagine a state machine that just picks which state to go using a random number generator.

While I agree the game needs a lot of bug fixing and polish still, new content is needed in order to be able to identify and fix issues that otherwise wouldn’t be identified because of the lack of a use case to run into those issues or general player disinterest resulting in a lack of feedback. In spite of that however I do hope the game starts to get some polishing passes soon because a I feel like a lot of these issues are simply a waste of time for the player to report because Intercept shouldn’t be so oblivious to the state of their own game that they actually need those reports to know they are a problem. It would be a better use of everyone’s time if the issues that players can run into are actually things that are more rare and/or require specific conditions to trigger.

The title should be updated to indicate it impacts all SRB's lest someone doesn't read this bug report properly and only fixes that one.

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i7-8700 CPU @ 3.20GHz, 6 Core(s), 12 Logical Processor(s) | GPU: Geforce GTX 1070TI | RAM: 16GB The arrow to the right of the staging that lets you see expanded DV details, such as your TWR is missing in flight for a rocket with 1 stage. If you click the + button to add an empty stage, it appears and works as expected. See the following screenshots. Included Attachments:

On the right side of the staging display there is a little arrow you can press to show the current TWR in flight. Can you expand that and confirm what the TWR is?

I haven’t had much time to try the new patch but so far it appears the orbital camera is indeed fixed, despite it missing from the patch notes, so your mileage may vary on that I suppose.

The two missions to land large masses on Minmus and Duna are both large difficulty spikes. That is fine if there was a difficulty rating or something to indicate to the player of that, as having optional challenges is a good thing. The mission to land and return 10 Kerbals from Eve is probably the most difficult mission possible in the Kerbolar system, expect possibly some grand tour missions. Same comment as before regarding letting the player know the difficulty. Landing near the SPOILER on Duna is also a large spike because of the lack of a trajectory estimate, resulting in either lots of trial and error, using a spaceplane, or dropping straight down and guesstimating the distance required to take into account the planet rotation while falling.

Any news on the ongoing camera rework/fixes would be appreciated. I assume the standard orbital camera is still broken in this release?

Glad to hear it. Ya it really is a head scratcher why it does that. That setting is there so it can uses the integrated GPU on applications that don’t need much rendering power, like Stardew Valley or what have you, as it conserves some power. However as you have seen it regularly picks the wrong one for applications that definitely need the GPU, so it is better to just always use the GPU for all applications and avoid the issue.

Search the bug reports, almost everything.

Fix the camera system.

That CPU has integrated graphics so make sure you are actually running the game using the GPU. In the NVIDIA control panel you can tell it to always use the GPU for every application. See if that helps.

Overall I dont think going back to KSP1 design is a good idea, as the new VAB controls do have some benefits, but there are definitely a need to change a couple things. 1) The ability to manually scroll the camera up and down the rocket. 2) Remove the camera automatically centering its self on parts, or moving the camera at all unless the player specifically requested it to be done, and intentionally. Maybe a couple others as well, but I think these are the worst offenders.