Darta01

April 23

Are you referring to the Delta-V required from launch to orbit? If so, you should describe your launch process so that we can understand your problem.

A really basic mistake I did when I first tried to go on a polar orbit in KSP, a long time ago when I didn't know anything about orbital mechanics, was to first launch into an equatorial orbit and then perform a 90° plane change maneuver to bring it in polar. I soon learnt a better way is to launch due North (or South), and perform a similar launch profile as for an equatorial orbit but with a different direction. This brings the spacecraft on an orbit close enough to polar so that correction maneuvers are cheap.

The optimal launch profile is to compensate for the planet's rotation

March 20

On 3/19/2024 at 12:51 PM, magnemoe said:

Yes, now I assume you can cooperate even in completive mode but its not default and stuff like science is not shared unless you actively share it like letting another sides kerbal enter your ship to get copy of science.

Reading your comment, a scene popped up in my mind: a scene ala The Expanse, where a player would do a hard deceleration burn towards another player's spacecraft in deep space, then jumping on EVA at high velocity to reach it and copy the science, and returning to its own ship before the other player could react... And then burning hard toward Kerbin before the adversary could launch a conter-mission to stop the science-pirate kerbal...

Competitiveness in KSP could lead to very interesting interactions

March 20

1 hour ago, Scarecrow71 said:

I don't think it's out of the ballpark to assume a sentient species that is space-faring - and going interstellar at some point - would have programmed their computers to do this for them. Heck, IRL our airplanes have automated functions that you could state "we should learn how to do".

If you want to land manually, great. But there's no reason to assume computers wouldn't do it for you.

Rocket launches are automated too IRL, but here we are, manually launching rockects because it is both fun and challenging. If landings are fully automatable, it would not be a space simulation game, just a space simulation

March 17

3 hours ago, Draslin said:

But while we are on the topic of the road map, doesn't it seem weird that something as basic as resource gathering doesn't show up until nearly the end of the road map? If those resources are used to build or research things, shouldn't that show up in the road map before those things are part of the game? Or isn't it weird that the resource gathering doesn't show up until after we crack interstellar travel? Is coming up with a convincing mining operation somehow more complicated or less important (or both) than working out interstellar travel? Seriously? I mean, this segues into one of the problems with KSP1, there was little to no reason to push out beyond the Kerbin SOI. Nothing is materially gained. It boils down to, I went because I could. So we'll be able to build colonies, great, but why? There is no economy and no resource gathering yet, so what's the motivation? Now lets take that question and make it interstellar. It just seems nutty to make something that should feel impactful into just another cog in a machine that's dull and grindy.

You talk about the roadmap as a progression tree for players: "resources show up after we crack interstellar travel". It is not, it is a list of development steps. We won't crack interstellar travel, the devs will. And yes, interstellar is easier to implement than resources, because it consists basically in placing new stars somewhere and new planets around them. The difficulty is more in the design variations than in the game mechanics. In game development it makes sense to first implement a simplified version of the final product you want and then after to refine the game loop.

When colonies will be here, we will build them because we will want to. The game is in early access, so the colonies are implemented in order for the players to test the new game mechanics brought with it: new parts, orbital construction, maybe ground-anchoring... Sure it would be nice to have other motivations to build colonies, but it is not the main goal of the update.

Besides this point, I agree that KSP2 is (and wants to be) simpler than KSP1, which can be disappointing for seasoned players who seek a challenging experience. Sure the first early versions of KSP1 without maneuver tools were challenging! But the additions of tools in the game to simplify the user experience didn't make it less fun.

Maybe you thought of the current state of KSP2 as a wannabe improved version of KSP1 final state. With this perspective, the simplified science gathering game loop can be disappointing. However, I think KSP2 game loop as planned by the devs will be different from KSP1 (launch, collect science, transmit/recover, spend points in the tech tree). They talked about it but I don't remember where. I think it will be a bit closer to an automation game: resource gathering improvement, supply lines improvement, and science gathering will be used to unlock parts but will be less significant than in KSP1. Some people will like it, some people won't, but for now we have to keep in mind the game loop is not complete, hence the lack of motivation for rocket launches

March 16

4 hours ago, Scarecrow71 said:

I love that the simple answer anyone ever gets is "You are playing the game wrong". In a game that is all but explicitly defined as being able to play any way you want, making a comment about what someone perceives in the game is simply playing it wrong.

You're not playing the entire game wrong in the sense that you can play whatever the way you want. However you are complaining about the characteristics of an object that, indeed, you're using wrong, and then you say this object is terrible.

To give an example in another game, it would be the same as using a shield in Skyrim to punch your ennemies with, and complaining it deals less damage than other weapons of similar value. Of course it is inefficient, because it is not meant for this purpose. In KSP as in real life, deep space engines are not meant to perform maneuvers requiring high TWR, that doesn't mean there are "terrible".

If you don't want to perform 10 minutes long burns (even if you can burn under time warp), that's you're choice, and low TWR engines are not meant for you

March 16

13 hours ago, The Aziz said:

But are much, MUCH lighter. Same size hydrogen tank with a Nerv will give 3 times more dv than an efficient methalox engine. And will weigh few times less, allowing smaller launch vehicle. I pretty much switched to hydrogen for most deep space missions, except maybe Duna because the requirements for a there and back trip are so low.

I don't remember where they are placed in the tech tree, I guess there are further than deep space methalox engines, right? It would be the only way to balance it for now, since we don't have resource gathering nor radiators yet (nuclear engines should procude a lot of heat so your spacecraft would weigh more due to radiators)

I'd say it's very realistic: IRL nuclear engines are OP in terms of ISP compared to conventional rocket engines. The reasons why we don't use them are engineering difficulties, heat management and the risk at launch if the rocket explodes. These difficulties don't exist in KSP, except for heat management but it is pretty easy to do in the game.

March 16

To make a part procedural, its characteristics and appareance need to be easy to compute. Wings are parallelogram with a few equations to set their lift and drag ratio. I'm guessing radiators will be similar (I wonder why we don't have procedural tanks...). Gravity rings however have a very complex look, I'm not sure it would be possible to make them procedural. And if the devs want to render the interior (which they did for every parts containing kerbals), it means the interior would also be procedural, which is a pain to compute.

March 15

4 hours ago, Scarecrow71 said:

An increase in dV does not equal an increase in efficiency when burning said fuel. Longer burns with more fuel do not necessarily equate to more efficient burns.

The idea of longer burns being less efficient is wrong and comes from the inefficient way the maneuver node is computed. I'm sorry for the shameless self-promotion, but I wrote a post about this with Delta-V examples : Change the maneuver tool to compute the predicted path in the moving orbital frame

Basically, you can perform maneuvers with roughly the same Delta-V regardless of the TWR (except when the burn duration is critical of course, like landing phases), if you perform the maneuver well enough, which is NOT following the maneuver node.

As was said by @The Aziz, the point of deep space engines is to maximize the Delta-V of your spacecraft, where you don't care about the TWR. There are well suited for lunar and interplanetary transfers, but not low orbit. Indeed nuclear engines may be more adequate, but hydrogen tanks are bulkier and don't use the same resources

March 12

7 hours ago, MirageNL said:

Actually, for large inclination changes (>43^o for LKO) it would be better to raise your Ap, do the inclination burn there and then lower the Ap again.

That's right, I forgot about this method

6 hours ago, Lowi_Sace said:

In the current game vehicles cannot turn while time warping. That is probably why the maneuver is a inertially fixed frame.

That would mean the dev team chose to temporarily fix a bug by adding another bug and never talked about it...

March 12

8 hours ago, Intercept Games said:

20 Can't create a maneuver node within another SOI Working as intended. Evaluating as feedback

Ah yes! The maneuver planning tool that does not allow you to plan maneuver!

This is a terrible design choice

March 11

5 hours ago, MirageNL said:

For a plane change, wouldn't it also be better to maintain an (anti-)normal direction instead of a fixed one? A fixed direction also changes the Ap/Pe and has to be corrected by the pro-/retrograde direction.

For small inclination changes, it does not make a lot of difference I guess. With large angles but short burns (high TWR), the best thing to do is, as you said, to plan a maneuver in fixed direction with both a normal/anti-normal and retrograde direction. With very low TWR, the best method is to perform multiple plane change maneuvers, at both ascending and descending nodes, again in fixed direction. With semi-low TWR (long burn but still achievable in a single burn), I'm not quite sure what is the best method, but I would say it should be in fixed direction

5 hours ago, MirageNL said:

As for the fuel limitation, wouldn't it be possible to just use the remaining dry mass for calculating the continued trajectory? It would need to be clearly marked red of course. In any case, I don't think there need to be any additional maneuver node modes, that would just make it more complicated.

It could be a solution. I prefer the solution with three modes, but if there is a solution to overcome the fuel limitation and the two first modes are implemented, then the third one has little use. So if the devs have good reasons not to implement the last mode, I'm ok with that.

March 11

3 hours ago, magnemoe said:

I also used this prediction to land on Tylo, An pure landing burn would crash, but adding an outward component keeping me up until I killed my velocity just above the landing spot.

With the proposed method, you could set a purely retrograde maneuver node, and at some point the spacecraft would eventually kill its velocity. So that kind of landing would be easier to plan, and with greater fuel efficiency

1 hour ago, Presto200 said:

This would probably improve the accuracy of the maneuver plans also which has been a concern especially with interstellar on the horizon (the devs said in an interview that interstellar will not have a special maneuver node system and it’ll be the same as what’s used currently)

I'm not sure it would make any difference. The predicted path would rely on the same type of computation, just with a different formula for the direction of thrust. I don't know what concerned players describe as an accuracy problem, but if it is purely calculation accuracy (like floating point precision), the problem would not be solved by my proposition.

34 minutes ago, kdaviper said:

You can also achieve a similar result to the ksp1 method by (in addition to moving the node back) pointing radially in as well to get a maneuver tangential to periapsis.

Yes, I talked about that somewhere in the middle of my post. The main issue is that it was way faster, easier, more precise and more intuitive to do so with the instant impulse planning tool in KSP1

March 11

tl;dr: summary at the end of the post

I am aware the problems of the current maneuver planning tool have already been discussed on this forum by multiple players: the prediction stopping when out of fuel, the inability to set the maneuver at the next orbit, the lack of number entries, the inaccuracy of the progress bar... Here I want to bring a mathematical insight to why, even with all these problems dealt with, the current maneuver planning system would still be inadequate.

The current advantages of the maneuver tool are the ability to see the real trajectory followed by the spacecraft during the burn, and to evaluate its end point. It is a huge advantage, especially for long burns. However, the predicted path is computed by assuming the direction of thrust is constant, and set at the beginning of the burn, and that is the heart of the problem.

Take for example the following vehicle, that has 4072m/s of ΔV and a TWR of 0.29, placed on a 100x100km orbit. I want it to transfer to a kerbostationary orbit at 2863km of altitude.

Picture: Test vehicle

With a theoretical instant impulse, the Hohmann transfer is 651m/s for the apoapsis raising (going from the 100x100km orbit to a 100x2863km one), and 424m/s for the circularization at apoapsis (from 100x2863km to 2863x2863km). The return trip costs the same, 424m/s for periapsis lowering and 651m/s for circularization at 100km. These are the ΔV computed by the maneuver tool in KSP1, because it was computed assuming an instant impulse.

Picture: Principle of a Hohmann transfer

Of course in a real situation the maneuver is not instantaneous, and the player has to find a way to perform the maneuver with this limitation. In KSP1, the usual technique was to point the spacecraft in the direction of the maneuver, and start the burn when the time before reaching periapsis is half the duration of the maneuver. So basically the node is approximately in the middle of the real maneuver.

By doing this technique, the ΔV is 659m/s for the apoapsis raising and 424m/s for the circularization at kerbostationary altitude. The return trip costs 424m/s for the departure and 651m/s to circularize at 100km. With different spacecrafts, the ΔV cost varies according to their TWR. For this spacecraft in particular with an initial TWR of 0.29, the cost is very close to the theoretical Hohmann transfer (only 8m/s of loss).

Picture: Direction of thrust with KSP1 method

In KSP2, the new maneuver planning tool computes the predicted path of the spacecraft during the whole duration of the maneuver, assuming that it is pointing in the maneuver direction. This direction is inertially fixed, and computed in the orbital frame at the start of the maneuver. This means it is no longer possible to place the node at the middle of the maneuver. When planning an apoapsis/periapsis raising/lowering, if the player sets a prograde/retrograde maneuver (as was done in KSP1), the spacecraft will be pointing straight in prograde/retrograde direction at the start of the maneuver, and slowly drift away as the orbital frame changes along the trajectory.

By doing this technique, the ΔV is 700m/s for the apoapsis raising and 426m/s for the "circularization", but the orbit is much more elliptic than KSP1's technique (2847x2880km instead of 2863km). And the return trip costs 424m/s for the periapsis lowering and 671m/s for the circularization but again it is impossible to circularize with this kind of maneuver. The resulting orbit is 59x151km. So the ΔV cost is much higher using this naive technique introduced by the new planning tool. This is due to the thrust direction being suboptimal.

In these maneuvers (apoapsis/periapsis raising/lowering), the goal is to gain or lose orbital energy. The optimal way is to thrust in the prograde or retrograde direction, every other direction introduces a loss. The greater the direction difference, the higher the loss. KSP1's technique keeps the thrust direction pretty close to the optimal direction, therefore the ΔV is close to the theory. In the naive KSP2 method, the direction is prograde/retrograde at the beginning, but the difference is much higher at the end of the maneuver, therefore the loss is much greater. In this particular case, the loss is 81m/s, 9 times higher than with KSP1's planning tool.

Picture: Direction of thrust with KSP2 naive method

Picture: Resulting orbit after the periapsis circularization

With KSP2 current tool, it is in fact possible to perform the same maneuver as with the KSP1 method, but the player needs to correct the direction of thrust with a radial-in/radial-out component. So the new method would look like this for a circularization at periapsis: set a maneuver at periapsis with a retrograde component so that the apoapsis is approximately at the good altitude; move the maneuver so that the the periapsis is in the middle of the path; add a radial-in component to the maneuver so the resulting orbit is closer to a circle; tweak all three parameters until the projected orbit is as close to a circle as you want.
It takes only five minutes to do in KSP2 what took two clicks in KSP1. What an upgrade!

Now what I'm proposing is to change the way the planning tool computes the maneuver direction. For these kind of maneuvers, I would like the maneuver to be computed in the orbital frame that moves with the predicted path. Which means, when a maneuver is set with a prograde component, the maneuver marker stays exaclty prograde during the whole duration of the maneuver.

Picture: Direction of thrust always prograde

This is what happens when you burn always prograde/retrograde in my example. The apoapsis raising costs 652m/s of ΔV. It is very close to the theoretical ΔV, but as a side effect it also raised the periapsis by 7km. Therefore less energy needs to be gained at apoapsis, and the circularization costs only 418m/s. The total is less than a Hohmann transfer. For the return trip, the periapsis lowering costs 417m/s of ΔV. For the circularization at periapsis, I start the maneuver at such an estimated time so it ends at the periapsis, and it costs 644m/s. As I don't have an adequate planning tool, the circularization is not perfect, so the resulting orbit is 97x105km, but still way better than with the current planning tool. Again the ΔV is less than the theoretical Hohmann transfer. The total gain is 19m/s, minus some ΔV needed to properly circularize.

The difference is even greater between the KSP2 naive method and the one I propose when the TWR is lower or the burn longer (e.g. for interplanetary departure/arrival).

So with this change, the planning tool would allow the player to negate the losses induced by a suboptimal direction of thrust. However I don't think the current planning tool should be totally discarded, because in some cases maneuvers need to be planned with an inertially fixed direction.
Here are cases I can think of where the maneuver should have a fixed direction:
   - plane change (changing the inclination)
   - fly-by corrections (changing the orbit in another SOI)
   - target corrections (reaching another spacecraft)
It is not anecdotic, so it is better to keep the current tool available to the player. But the default planning mode should be the moving orbital frame, because here are cases where it is essential:
   - orbit changes (periapsis/apoapsis raising/lowering)
   - circularization
   - rendez-vous
   - lunar/interplanetary departure
   - interplanetary arrival (injection burn)
   - targeted landing
   - suicide burns
Theses maneuvers are the heart of KSP2 game loop, there are essential to go anywhere.

Ideally, I would like to have an option on the planning tool to compute the path either:
   1. In the moving orbital frame
   2. In inertially fixed frame
   3. As an instant impulse
The third one can still be useful to plan certain maneuvers that are not possible with the current spacecraft. For example, the player sets a station in high altitude orbit of Kerbin (with no engine), and now he/she wonders how much ΔV it would costs to reach the Mun with a space tug or a resupply module. With instant impulse planning tool, he/she can have that information that is not available in the VAB trip planner.

TL;DR
The current maneuver planning tool computes the future path by assuming the spacecraft points in a fixed direction. This is useful only for some very specific cases. In most cases such as orbital raising/lowering, interplanetary trajectories or landing, it is suboptimal to say the least.
A better way would be to compute the maneuver in the moving orbital frame. It would be easier to plan in terms of QoL, and cheaper in terms of ΔV cost for most maneuvers.

P.S.

This posts echoes @Superfluous J tutorial (Don't just burn prograde!), where he/she shows the prograde maneuver is nowhere near optimal in terms of ΔV for an interplanetary departure. However, I would say the title is misleading: you SHOULD burn prograde and stay prograde, just not in the direction of the maneuver

March 8

6 hours ago, Lowi_Sace said:

In the Kerbolar system you can get away with a KSP1 style maneuver planner, but for those interstellar maneuvers you want one which also takes fuel weight loss and acceleration path into account

It's just that sometimes you want to have an estimate of the Delta-V required for a certain maneuver your ship is not capable of. It's a good thing to take into account weight loss and correct path, but stopping the prediction when out of fuel prevents you from getting that knowledge, which is a shame. I'd rather have a not perfectly accurate prediction (e.g. path computed with constant mass after fuel depletion) and with a warning note on the inaccurate path, than no information at all.

6 hours ago, Lowi_Sace said:

In the Kerbolar system you can get away with a KSP1 style maneuver planner, but for those interstellar maneuvers you want one which also takes fuel weight loss and acceleration path into account

I personally do not see the need for option one, I think that is more something modders can add to the game. The problem with option three is that vessel stay fixed/locked during time warp. This was a while in the bug report, but the DEV team said it takes a while until they fix it (complex issue). When this is fixed we may get option three after all.

Ok, I didn't know devs considered this as a bug. When it will be corrected I hope they'll implement option three.

If we have options two AND three AND path prediction beyond fuel depletion, then yes option one is of seldom use

March 8

On 3/7/2024 at 3:37 PM, The Aziz said:

It takes PAM thrust limiter into account as well.

Ok, I haven't noticed for the thrust limiter, that's good.

On 3/7/2024 at 3:37 PM, The Aziz said:

Once we're able to assign RCS to throttle, it should work, easy.

Though you're beginning to cherrypick here, it's KSP, it cannot possibly predict every stupid design the players come up with, but it doesn't make it any less valid.

Yes yes, these are the minor details that make the prediction (or the player, if you want to say) less accurate. My point is not to say the current tool is worse on these points, just that both KSP1 and KSP2 have inaccuracies. But you are right, I'm dirfting away from my main point, which is the suboptimal direction of thrust of the current tool.

On 3/7/2024 at 3:37 PM, The Aziz said:

There's a button to follow the maneuver marker. Don't just hit prograde because you'll end up nowhere during longer burns, as you're going on an ellipse, not straight line.

Been to Moho lately? I have, and noticed a significant difference that makes the KSP1 "halfway to node at Pe" inferior by a long margin.

Yes I'm aware there is a "maneuver direction" button, I've played KSP my fair share .

However, I strongly disagree with you on this point. If the goal of your maneuver is to raise/lower an apsides (which is also the case for interplanetary departure and encounter), the optimal way is not to burn in the same direction. Apsides raising/lowering is all about gaining or losing orbital energy. The optimal way to do so is to burn prograde or retrograde. Every other direction is a loss of energy (except if you need to also do a plane change of course). If you want to perform an interplanetary departure with a very long burn, you should cut it in multiple burns at periapsis, but every burn should be prograde, never in a straight direction.

I've been to Moho, and burnt retrograde at the encounter to circularize. I did that manually because I was incapable to plan a good circularization with the given tool. I must admit KSP1's tool was also no good in this situation. In both games, I only use the maneuver node to have an estimate of my burn duration.

I'm not sure my point is clear enough, and I don't want to pollute more this post about UI design, so I will write a separate, more detailed post in a short time (https://forum.kerbalspaceprogram.com/topic/224064-change-the-maneuver-tool-to-compute-the-predicted-path-in-the-moving-orbital-frame/)

March 7

2 hours ago, The Aziz said:

How is it better if the burn ends up inaccurate anyway because all you see is an instantaneous change in velocity, physically impossible?

KSP2s planner can't let you plan beyond your current fuel capacity because it has nothing to make the calculations. Your mass, speed, TWR, whatever can't change when you run out of fuel, and so the predicted path can't change either.

Well the current tool has its limitation : what if I take some time to stage? If I start later or earlier? If I don't burn at 100% thrust? If I burn with RCS?

Besides, the direction of thrust computed by the tool is completly wrong for a lot of use cases. For apoapsides rising/decreasing, lunar trajectories, or planet encounters, I do a much better job in terms of Delta-V than the maneuver tool by controlling my vessel to burn prograde or retrograde, something the current tool is not capable of. By doing so, I can achieve almost the same Delta-V an instant impulse tool would compute. So yes, I continue to affirm KSP1 maneuver tool is a better planning tool in terms of Delta-V optimality than KSP2.

2 hours ago, The Aziz said:

With planning tools, already partially and a bit rushedly implemented, you shouldn't need a separate craft to plan stuff.

The trip planner in the VAB only gives the Delta-V necessary (Delta-V computed as instant impulse I guess...). When I launch an interplanetary mission I like to know the orbital elements of the required escape trajectory, because it is inclined in most cases. With a separate spacecraft as a trip planner, I can launch from KSC directly aligned with the escape trajectory because I can see it in map view when I set the satellite as target. Therefore I do not need to perform a plane change combined with the escape burn, and so the whole trip is less Delta-V consuming

March 7

1 hour ago, Superfluous J said:

I agree that I'd like a node like what KSP1 has. However, I'd like it in ADDITION to the node we have now in KSP2, with a separate use case.

I've wanted a true "planning node" for (almost) a decade now. Maybe some day we'll get one.

Yes, I don't think the current KSP2 maneuver tool should be totally discarded.

The ideal maneuver tool I would like is similar to the one present in the KSP1 mod Principia : you can switch between three calculation mods :

Instant impulse. Similar to the vanilla maneuver calculation. Not realistic for long duration burns but good enough for planning trips.
Inertially fixed. It computes a continuous burn with a fixed direction of thrust. Similar to the current KSP2 tool, useful for plane change maneuvers or changing the apsides direction.
Not inertially fixed. The continuous burn is computed in the orbital frame along the predicted path. Useful for apsides rising/decreasing

If only one solution should be kept, I'd rather have the instant impulse of KSP1 than the current KSP2 one, but I agree it is less than ideal.

March 7

On 3/2/2024 at 11:46 AM, Lowi_Sace said:

Might be harder said then done. The maneuver planner takes the path the ship takes during the burn into account and thereby also calculates the effect of the weight the ship loses due to the burning of fuel. That would mean that the fuel will get negative mass after that or stays the same which will not give a precise maneuver path.

That's just another reason why the current maneuver planner system is so bad. Why have a maneuver planner that does not let you plan maneuvers?

In KSP1 I often place a small satellite in Kerbin orbit with the sole purpose to plan interplanetary maneuvers. For instance I set a maneuver to Duna with it, so that I know the departure time, and the direction of the burn (inclination, ascending/descending node...), and it allows me to launch an interplanetary mission from KSC directly on the correct path, as well as planning it with the correct Delta-V. In KSP2 this not possible anymore, because it would require the satellite to have enough fuel for any burn I want to perform, and have the TWR of my future mission...

KSP1 maneuver tool is better than the current KSP2 one. However, KSP2's tool lacks just little things that would make it so much better. It's just a question of design choice

March 1

Loved all your suggestions. Your Trip Planner version 1 is already self explanatory, I don't think the second version is needed

February 16

Situational music seems to be the most reasonable fix haha!

February 16

What happened:

The electricity of my spacecraft decreases while the Infinite Electricity button is switched on, when the ion engines are throttled. The electricity is however not consumed when the button Infinite Fuel is switched on.

Expected behavior:

When Infinite Electricity is switched on, the electricity should be infinite whatever the use case. The current behavior is misleading.

February 16

I haven't seen comments about the trip planner, and I almost never use it. What is the problem with it? Are the dv numbers wrong?

February 16

14 hours ago, gregdeen19 said:

There is no telescope in KSP so launching a Hubble style satellite could act as a way to discover other planets.

You know the planets of our solar system weren't discovered with orbital telescopes, right? An orbital telescope in KSP would be ok (and cool!) for extra solar objects, when interstellar will be brought to the game. But it does not make sense for the known planets of Kerbol, because all the observation and math can be done from the ground.

In reality, interplanetary and lunar probes did indeed help to plan the next missions, but it was about improving the precision of transfers to an extent that is not achievable in KSP.

14 hours ago, gregdeen19 said:

It is a game and making more mission and objectives to unlock new things is kinda the point.

Sure KSP is a game, so it should be fun, but it is a simulation game and should stay coherent to the reality. And I wouldn't want more missions that just slow the game pace by adding barriers.

However, orbital telescopes to discover the usual planets is typically a good idea for a mod. It already exists for KSP 1, it works great with modded solar system!

February 13

This might be just a bug. It does not make sense for a gas giant to have a surface, so it will be removed from the game before a biome is set

But for the sake of the thought experiment, precise landing next to a landmark and then getting back to orbit would be the ultimate challenge!

February 13

9 hours ago, The Aziz said:

The sole fact that you were brave enough to try a Dawn-based probe on Jool...

Well I didn't read the bug reports before playing this mission, so it was an obvious solution to me for a Jool-5 capable probe :rolleyes: . Too bad this propulsion technology is not ready yet in this game. I've been reading the KERB updates, and they talk about acceleration under time warp bugs, but without specifically pointing the Dawn engine

9 hours ago, The Aziz said:

But also

Thank you for the link. From my uninformed point of view, there seem to be multiple unrelated bugs affecting ion engines and time warp. I will read the full thread when I'll have the time, and maybe I'll share my save. It might help the devs and the QA dep.


20	Can't create a maneuver node within another SOI	Working as intended. Evaluating as feedback

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by Darta01