InfernoSD

Agreed, it's pretty low odds. The player would need to have foreknowledge of a supply run and make a conscious effort to travel and time warp there. In my opinion, it would only make sense while managing a colony. I think it would be worth it for the purpose of making colonies look alive. The colony view could have a little calendar in the corner of the screen to let you know when the next launch or landing was scheduled, so the player could easily warp to see it for theirself. I don't see that they have said that anywhere. But the tediousness of making ten repeat mining missions is no worse than the tediousness of making ten repeat interplanetary shipping missions. I think it will be a necessity, especially if some resources can only be collected from specific planets. Presumably when a supply run completes you'll get a report like "-400 Liquid Fuel, +1000 Ore". I imagine a small fuel refinery will be one of the first things you build in every colony. What if it's not a round trip, though? Then I imagine your starting colony will have "-800 Metals" and your destination colony will have "+800 Metals". It's likely that I will make a lot of one-way trips to move resources around, and if Metals are a resource, that may require some management as well.

Just that I would be disappointed if I flew a mission one way and the game algorithmically decided to fly it another way. I will admit that I don't have much familiarity with TWP or mechjeb, and so it's possible that the task of autopiloting between planets as laid out above is easier than I give credit for. So let's go with that assumption, that KSP2 will have a functional autopilot than can complete the entire task of take-off, orbit, hohmann transfer, and precision landing. This still leaves us with an immense number of questions to be answered. What if my mission doesn't begin by entering orbit, but instead continues thrusting away from Kerbin? Can the autopilot differentiate between these different types of missions. Will it know the correct time to take off? Opposite that, what if my mission ends by going directly to landing, instead of orbiting first? Does the autopilot have a way of recognizing this different type of outcome? Can the algorithm always reach that precise landing spot, even if it's on the far side of the planet? What if I use aerobraking to land? Some landings will inevitably be more difficult than others. To compensate for heat, or to control where I land, I may need a different angle of attack from one flight to the next. Will the autopilot figure this out on its own? If I make multiple passes through the atmosphere to slow down, will the autopilot do the same? What if I use any other form of transfer that isn't a hohmann transfer? Can the autopilot perform a simple high energy transfer? Would it recognize that this is not necessarily dependent on being in a transfer window? If my mission used 10 separate burns just to transfer out of Kerbin, does the autopilot then plan a route with 10 manuevers? Can it plan that many steps? Is the autopilot capable of plotting a course if I use a third body somewhere in my route? If I decide to burn 500 dV in Kerbin's SOI and 500 dV in Mun's SOI, will the autopilot do the same? What happens with some of these immensely more complicated trips like you get when you travel to Jool's moons? Say the autopilot recognizes that I passed by the Mun on my way to Duna. Will it assume from that that that route must also pass by the Mun, even though it was just incidental? How will it know the difference? What if I'm using an ion engine that requires solar power for thrust? Will the autopilot know to look ahead and check whether the vessel will be in shadow? What if my mission activates different engines at different times, as opposed to a conventional staged approach? Will the autopilot know to do a 180 and fire up the front rockets during one part of the journey? What if the mission incorporates driving with wheels? What if it incorporates flight? I'm only scratching the surface here. Not that these are questions for you to answer, but that they would need to be solved by Intercept. To me it seems like an impossible thing to code or even to design, but maybe I'm small-minded. All of these questions have bearing on fuel effiency, meaning that if the autopilot could not replicate the player's actions, it may result in a failed mission. I don't want to belabor this any further, so I'll make this my last post on the subject.

So it sounds like your desire is for the game itself to plan its own supply route? This enters strange territory for me. Might as well trim the fat and allow the player to assign any supply route without having to fly it himself first, because the automated route will not resemble his initial journey anyway.

Why, though? As a player I would be very irritated by this. The automation system should be designed to automate what the player does, not the other way around. The only way this system interests me at all is if optimization matters. If you take away my ability to slingshot, it's no longer fun. I know we joke about "more rockets" on this forum, but if the solution to building up a network of colonies in space is simply to send the most rockets as quickly and numerously as possible, then there's no challenge or thought involved, which is not aligned to the spirit of the game. Sure sure sure, but my point was that transfer conditions will never be perfectly the same again. Therefore there has to be elaborate algorithms to compensate for those changing conditions. Even if you fly in a straight line from Kerbin to Duna, their locations and rotations and the gravitational effects of different bodies will be different every time, and the route has to be altered for those changes. I think what I'm failing to communicate is that computers are not humans. As humans we notice these differences and adjust for it very easily. For a computer, it would take a very elaborate spiderweb of code to do the same things that we do. As I said above, I think it would be easier to code something that plans its own route than to replicate a preexisting route. Well, yes actually, because I like efficiency, but I realize I would not necessarily be in the majority in that opinion. But there's also no shortage of examples where a supply run would benefit from gravity assist without being a rare occurrence. If we take the Minmus to Duna example, you would want to use the Mun first to bring pe closer to Kerbin, then get the full oberth effect from Kerbin. (I may be wrong, but I believe that is the obvious efficient route to take.) This type of route is not a rare occurrence at all, in the sense that you're speaking of. It could be repeated every transfer window or more often. The trouble is in telling a computer how to replicate that route. Been thinking about this too, although I was considering landing pads rather than docking. I think the only way this would work as desired would be for the player to dedicate a specific docking port or landing pad expressly for the purpose of supply routes. Because you wouldn't want the player to be launching a rocket from the same landing pad that a supply rocket is coming down on. But this could still result in some weirdness if the player manages to block that space anyway. Presumably the supply vehicle dissolves into resources so it doesn't block the next trip. --- Here's a fun question. Interstellar supply runs, yes or no?

This is the key issue. A mission launching from Kerbin's surface and landing on Duna's surface could be repeated once every two years. The same arrangement simply does not occur more often than that. What if we launch from the surface of Minmus instead? Or what if we slingshot around another body, as we often do for more fuel-efficient missions? Then the period until that same arrangement occurs may be effectively infinite. This is ignoring that planets rotate, and that they have oval orbits, and that they have moons which tend to get in the way, all of which introduce additional problems for the game to solve. And this is without even getting in to the many creative flight plans players will use, like aerobraking out of an interplanetary transfer. So I don't see that any version of KSP could ever "solve for" all of the various differences that may arise during an automated flight. What it could do is fake it, but even to fake it would require an immense amount of problem solving. It would ultimately be easier to build an AI that charts its own course to a destination rather than trying to replicate a previous course. And at that point the whole thing is fake, so what is the point? Is it even desirable to allow the player to interact with an automated flight, and if not, why permit them to see it at all? My current expectation is that automated flights will be abstracted. Maybe put a graphic in the tracking station that displays the progress of current automated missions, where the progress bar uses iconography for Kerbin, the rocket, and the destination. If anything, allow the player to watch them take off and land, which is where keyframes would come in handy.

I was going to ask the same question. I enjoy watching time-lapse videos and time warping through long kerbal journeys, and it would bother me if the backdrop was entirely stationary while moving interstellar distances. Imagine superman flying through the sky for miles, catching up to a jet, but he never catches up to the clouds in front of him or escapes the clouds behind him. It would look very wrong. So I hope for some parallax effect on the skybox. There are some technical challenges to it, but it's not an unsolvable problem. Even if only half the stars in the sky appear to move, that might be enough to convince me. This would bother me slightly. How disappointing would it be to see a star and think, "hey, I can see it getting closer, it's not that much further away!" And then you go through the trouble of flying an interstellar mission only to phase right through it. But maybe the game will present information in such a way that these thoughts never occur to the player, so it would be a non-issue. So on the one hand I wonder if it wouldn't be better to fake the parallax effect so that stars can only shift by a certain amount before reaching a hard limit, so that the skybox effectively freezes once you've travelled outside the intended play area. That way the player is not misled. On the other hand it might be nice to fly out past all the stars, to the deep dark.

Sackboy has already made appearances in many places. Sony is happy to lend out his likeness, especially but not exclusively to other Playstation exclusives. This list is missing THPS so it may be missing other games as well. https://littlebigplanet.fandom.com/wiki/Sackboy_in_Other_Media The proportions of that space suit are a good fit for kerbals in my opinion. That said, it lacks any obvious recognition as being related to LBP or Sackboy. Nor is Media Molecule as connected to the franchise as they once were, so it would be strange to put their logo on the costume in 2022. I apologize for even suggesting this, but it would actually make more sense (to a corporation like Sony) for there to be a Sackboy suit, zipper and all. Instead of a visor flipping up or down, the head would unzip like a hoodie to uncover a more ordinary kerbal helmet underneath. I know some KSP players would hate it for being too goofy, but that is the nature of videogame crossovers.

I've considered this too. It would be entirely reasonable for early rockets to cost millions, interplanetary vessels and colonies to cost billions, and interstellar projects to cost trillions. Or some similar progression. I think this would be very easy to design and satisfying for the player to progress through. The trouble is that it's only satisfying once. Because as soon as you've made it into the second tier, anything from the first tier is cheap to the point of triviality. Players could burn virtual piles of money on the launchpad at no real cost. It eliminates that desired feeling of challenge or stake. This seems likely. I'm imagining giant fuel tanks and money silos on the periphery of KSC. Spend tech points to upgrade them or build more. These resource containers refill themselves automatically over time, somehow. Likewise for colonies, except you either have to deliver the resources or use ISRU. Automatic income is not something that appeals to me, but I expect it to happen anyway. Game series always lean towards casualization, never the reverse.

Yes. In theory this enables any system which relies on fuel, electricity, or other resources to work properly over any span of time and at any distance. If we assume that KSP2 also correctly simulates solar power, this would mean that any satellite, station, vessel, or rover that depends on solar power will lose that power during nights. So for example you could have a relay satellite that runs out of battery and goes dark for part of every orbit. It also means that mining vessels will function how they should, only draining electricity that exists. One might suppose the same could apply to other forms of sporadic power. If wind power exists, it might fluctuate up and down over time and affect your operations accordingly. Not sure about geothermal or other forms. Interestingly, it could also be thought to apply to atmospheric flight, if KSP2 also made atmospheric flight work properly over any span of time and at any distance. This would allow you to make an in-atmosphere satellite by burning fuel at an extremely low rate. Interstellar burns for sure, but the possibilities are endless. I'm curious what "Resource Flow Graph" means. Is it a visual graph for the player to see, or does it have some other definition?

It's going to be a mobile game. Set in the Kerbal-verse.

Try pressing Y to bring up a control wheel, hold right on the left stick to select the fast forward icon, and press A to choose it. That activates the time warp controls. Pressing RT will increase time warp and LT will decrease time warp. Alternatively you can press in the left stick to bring up the cursor, then click on the time warp interface in the upper left as you would on PC. That is with the Radial control scheme. There may be some differences with the other control schemes.

I think the research lab in KSP1 is one of the worst ideas put in to that game. Any situation in which you progress simply by holding down the time warp button is not fun or interesting. For that reason I hope first-time discoveries are the only research you can do, but I suspect we will get a mix of both again. Maybe one way to handle unlocks would be to require several discoveries on a specific planet. For example, taking ground samples in three separate biomes could unlock a new fuel type for manufacture there. It would be a good way to encourage the use of rovers and complex missions in general. If you haven't unlocked something yet, members of KSC could give you hints in that direction. In any case, I would be in favor of putting small dumb minigames in for each unique research part or activity.

It's so blue. I want to see a close-up on the surface of this.

Rockets? Giant planet-sized solid fuel boosters? Let's fly this sucker around! Well that's okay too, I guess.

Here's how I eyeball it every time. This won't get you the perfect ideal transfer, but it will be very close. In the Tracking Station, fast forward until Duna is exactly "in front of" Kerbin. If you imagine a line coming out of Kerbin's prograde direction, you want that line to intersect with Duna. Or in other words, if you visualize a line between the two planets, you want that line to touch the very edge of the circle that forms Kerbin's orbit. Perform your burn then. _____ / \ Kerbin-( Sun ) |\_____/ | Duna-v

I wouldn't even desire this. I like starting fresh. But it would be neat if you could find your own derelict craft from KSP1 floating in orbits and on surfaces. They wouldn't even have to be functional or interactive in any way. They could just be wreckage, half-buried in the soil, and if any bugs happened in the conversion it would look like intentional damage. That could be more fun than KSP1's anomalies, I think.

I've asked myself this question a few times. My gut has always said that in order to avoid the issue of "regaining velocity", I want to get periapsis as close to the ground as possible, then do a suicide burn near periapsis. A two burn method. By staying in orbit, I'm not "gaining velocity" until I begin the suicide burn. In practice this has been very hard to pull off. Usually my rocket has puny engines and I am already starting from a low orbit. In some missions it takes upwards of three minutes full burn to get from low orbit to 0 m/s. In those cases, touching down without wasting too much fuel and without crashing into a mountain can take me several attempts, like in the video. Still, two burns has been the most efficient method for me in cases where I reverted to check the numbers. It's just much harder to succeed at compared to approaching the surface from perpendicular to it.

KerbNet allows you to see the surface of the planet below you, including biomes and I think altitude. You can set waypoints from the KerbNet interface. Most probe cores have KerbNet functionality. If you already have a satellite orbiting a planet somewhere, I would suggest switching to it and trying out KerbNet just to see how it works. It's found in the probe core's Part Action Window. Good luck on Eve!

I think "altitude on surface" is referring to the location that the contract requires your active vessel to be. Meaning it requires you to be parked on the surface at the time of a specific action. What is the action it's asking you to do? Or what does the rest of the contract say?

Don't forget switching vessels also works for EVA kerbals. The one set of controls I find particularly useful is the RCS thruster controls. They work like this: Circle - toggles SAS L1+Circle - toggles RCS thrusters R1+Up/Down - burns in an upward or downward direction, per your current control point's orientation, and only while RCS is turned on R1+Left/Right - burns leftward and rightward R1+R2/L2 - burns forward and backward Once you have these controls mastered, they're pretty easy to use at any time mid-flight. I use them for example to make quick adjustments when I'm going interplanetary. I haven't activated docking mode in a couple years since I have no need of it anymore. It's also good to know L1+Triangle which brings up the SAS target wheel. Use this to quickly target Prograde when taking off, or target Retrograde when coming in for a landing. I somehow only recently figured out that Left on d-pad is a whole other wheel of shortcuts. I use that to toggle Lights.

Well, if all else fails, try switching to the Radial control preset. In the Radial preset you click Square on a part to open its Part Action Window or click Square anywhere in open space to close windows.

You probably manually save your craft before clicking the launch button, like I do. Give it ten seconds or so to finish saving before clicking launch and this bug won't occur. It has been around for a couple years, so I don't expect it to ever be fixed.

The dV indicator is a nice tool but not really reliable. It gives me improper readings when I have multiple fuel types, engines pointed in different directions, engines toggled on or off, and all kinds of other reasons. Staging order also has a big effect on it. You might be able to get the dV reading back by moving certain engines or other parts around in the staging interface.

Do you think KSP2 will attempt to solve these issues and make the solar system properly stable? You know, adjusting orbits so that every system is self-stabilizing. Or would doing that just ruin the fun of a system like Jool?

No picture, no video? There's a variety of forces working against you on take off, so here's a variety of solutions: Add fins to the bottom of the rocket. These will help it fly in a straight line, like an arrow. Add an aerodynamic nose cone to the top of the rocket. Or use a fairing to cover the top of your rocket, which may have many drag-inducing parts. Move weight toward the top of the rocket, if your design allows it. Even adjusting fuel priority so that lower fuel tanks drain before upper tanks may be a good idea. Ensure that your center of thrust aligns with your center of mass. If you're having any wobbling issues, use struts or autostruts to stabilize. It's easy to make the mistake of designing a rocket where the top is both very lightweight and very draggy, which is the exact opposite of what you want for take off.