pg17

Maybe you encountered a bug (repeatedly), because I had several instances of relay workings for me. For example I had one 130Gm satellite in high orbit around Kerbin, another one in high orbit around Jool and it's moon, and I could control my craft in low Jool orbit with only the probe core integrated 200Mm range without any issues. While in other instances I lost connection with KSC because I didn't have the range to hit any "relay" (as I understood, every antenna is supposed to act as a relay in ksp2... but I don't know if it's only for the "real" ones or if the integrated ones are also concerned). Also double check the following thing (I, for one, made the mistake) : Make sure your two crafts/relays have the appropriate range to send and receive. A craft with a 200Mm range can't be controlled with a 130Gm antenna unless it is not farther than 200Mm from it (in the game you can't send instructions to your craft if the craft can't "reply back"). Side note for information: the occultation system isn't implemented yet (we are many who really hope it will come).

I concur! I don't know if this should be this solution (or something like having multiple color coded stacks with only one active, like those multiple shortcut bars in RPGs) but we need something to address the underlying issue. At the point I am in the game this is among the most frustrating things for me. I would take any form of improvement! I often build rockets delivering multiple vessels at once (for example a station, a lander, a communication satellite, a science return vessels, ...). Assembling it all together always result in an awfully long and messy stage "stack". It would also be helpful if those stage groups could be "locked" even outside of VAB too, so that when docking, the groups of each vessels are preserved. Maybe the groups could also be linked to the main shortcuts on the left (braking, solar panels, lights, ...) in a way as to trigger only the corresponding elements in the active / main groups.

The cleaner font really improves things! I can't wait! On the other side, as others have said, it really emphasize the need to get rid of the pixelated art direction. I understand it might have sounded like a good idea, I understand it was someone's baby and they were proud of it (and in a way, it was consistent and really well done), it's just that it doesn't work regarding readability and effectiveness to communicate information to the player in a game like KSP. On the opposite, and I know some will disagree and I respect that, seeing the skeuomorphism of KSP1 really makes me like the more contrasted and identifiable color scheme for some elements (like rcs & sas activation, altitude vs speed on the navball, ...).

That is exactly the kind of cases that calls for more procedural parts. It would need to be balanced with a max length set around the point where it is considered too long to not have a noticeable or expected bent (at that point you have to really assemble two truss together and compute the joint). That being said, I second the idea of having some sort of sub assemblies with approximated simulation in specific steps. Especially payloads like satellites or rovers secured in a closed cargo bay during takeoff. I think they could be approximated as a single block with proper mass & CoM without losing too much. But it's hard to say without knowing exactly what happens and what kind of computations are done under the hood. For really complex systems like physic simulation, I tend to trust (hope?) that the dev team already thought of such simple optimizations. So, it is either that they had a good reason not to implement them, or it is already in development / planned.

Just a quick thought (in addition to the suggested alerts) : it could be nice to have a timeline in the UI, with a dynamic or logarithmic scale, where you could see maneuver nodes and specific events (you could hover a label to get the type of event, craft concerned, time remaining and a "fast forward to" button). Also, I don't know how multiplayer will work exactly, but it could also be used to see where (or in fact "when") each player is currently at.

I agree, multi-goal missions (with known objectives from the start) seems better than multi-step ones (where you discover the next steps along the way).

I roughly agree with all your suggestions except for this part : I agree with something like a 10 to 20 rolling quicksaves, but starting back at 1 every time you start the game is not fine. I don't always make a proper save before leaving the game (and I'm probably not the only one). They can use the save datetime to know which one is older and should be overridden. As for point 8, I agree, but in my case I mostly had the reverse issue. I launch an apollo style mission (or a station with empty modules for futur use), fail, revert back to vab to make a few tweaks, launch and I realize halfway into the mission that I have stowaways in my lander and won't be able to bring back everyone in the return capsule.

I'm a simple man, when I see a sensible request for more procedural parts, I press the like button.

Currently, and despite the optimization improvements, it would probably end up killing most of our computers, or at the very least be an interesting powerpoint slideshow. That being said, if it could work, that would be awesome! From my recent experiences with docking, it looks like the 2.2km range also apply to the keyboard shortcut that allows to switch between vessels "on the fly".

The way I see it, it would be non blocking (meaning you could do the same things you can currently do, it wouldn't magically prevent you from landing anywhere for exemple), it's just that instead of getting most of the advance knowledge from the wiki (some of the knowledge I talk about isn't currently visible in the game, though that could change), you would get the option to learn it through the game with science experiments, and it would need to be balance in a way as to not prevent players (especially new comers) from experimenting things by the "trial and error" method while allowing advanced players to better "plan ahead" and optimize their missions even more. That being said, I wouldn't mind at all this being a difficulty option. It would have the additional benefit of allowing the player to optout of discovering everything again in an ulterior playthrough. And even if you don't activate the option in your first playthrough, chances are you won't visit, check and remember data for every system and every planets or moons so you would still have knowledge to "discover" in a new playthrough should you decide to activate it then.

On one hand, I think devs ressources should be spent on more important things, but on the other hand, I agree this could be fun! So maybe it's a good idea for a full fledged mod (that would add proper controls, ux and ability to create courses).

This doesn't seems like an easy things to do before takeoff (in a way that doesn't result in a plane design totally imbalanced). It would be interesting to try, but I suspect that wouldn't change anything in the way the game considers things once the two crafts been attached.

In game graphs and charts that gets completed through experiments would be awesome. I wasn't sure about suggesting it, because adding a whole data visualization system seemed like a lot of work on top of what I already suggested, but I would love it ^^ Thank you very much I didn't knew about that one, thanks for pointing me in the right direction (for now... because I agree with you, I still think this should be in the base game).

You're right! Interstellar levels of time warping are a bit concerning in that regard.

In my case, what I'm expecting is rovers to be reliable and useful. Let's take Opportunity as an example: it was planned to drive 600 meters away from the lander, and ended driving 45.16 km in roughly 14 years (this is overall time mission so if you took into consideration driving time only, it would be less but still very slow). In reality, it can be scientifically interesting to drive just 600 meters away from your lander, in KSP not so much... unless you are very close to a biome boundary. So you need to drive farther away. And so, for the same reason nobody wants to play in 1x speed for interplanetary transfers, I would like (in an ideal world) to be able to drive my "slow" rovers in 4x speed or more, in a reliable and stable way (meaning I should have issues only if I made a badly designed rover or if I tried to drive like Sébastien Loeb ). In short, I would either like to be able to drive a slow rover reasonably "fast" through time warp or to have "things to do" with my sluggish and frail rover in a reasonable distance from my lander (thus justifying I built it and brought it there in the first place). Of course, low gravity bodies will always be hazardous to drive on (as they should!), but they should be hazardous because of the environment, not because of some incomprehensible wheel behavior, bugged parts, invisible bumps and pothole, timewarp changes or quick reload. That being said, I'm not saying this is an easy thing to fix by any means.

I'm sure there is room for improvement, but, to a certain point, I doubt you can really avoid that behavior. I imagine this not a graphic performance issue but a game logic calculation issue, the faster you go, the more calculation (orbital position, velocity, checking potential impacts, electricity, commnet range, ...) needs to be crammed into a frame (or a bunch of them for less critical computations). At the higher speeds some minor things can probably be "turned off" and retro-actively computed once you go back to more manageable speeds but not that much considering some elements need to be shown and notified to the player during warp.

I probably haven't been particularly lucky with rovers so far (as you can see in this bug report ) and I had bad experiences driving rovers on the Mun (even on the quite flat mares) and Ike (so lower gravity than Kerbin and Duna), but I haven't tried on Duna. I'll agree that on Kerbin, asides from when bugs like above, issues with seats and EVA phantom forces arose, the driving handling felt better than in KSP1 overall.

Oh, I feel you! In my opinion, rovers are a bit of a pain every steps of the way (building, delivering and driving). In KSP1, driving a rover over something like 80km on Duna ended up so frustrating that it played the biggest role in the reasons I stopped playing the game for years... Right now (and despite some improvements over KSP1), unless I want to toy with them, I tend to avoid rovers. Especially for missions & science where I would rather send several landers or "hoppers" than a single rover. I agree it needs to improve, because, down the road(...map), rovers will become more and more important gameplay wise : With colonies, they might become very important to move around site (especially if you consider how huge colonies can be). With resources taken into account, the avoidance strategies will become a lot less viable (like sending multiple landers). With multiplayer, people are bound to race each other around KSC very early on... and you can be sure it will escalate quickly . To avoid any misunderstanding: I don't think racing should be a gameplay focus for the devs. I think racing will be a consequence because good rovers are even more important for a good multiplayer experience (where you'll probably want to avoid reloading a lot more than in single player). Also... Rovers are fun! Or at least they should be! Not just in theory but in practicality too!

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: Intel Core i5-8600K | GPU: Nvidia RTX 3070 | RAM: 64 Go Sent a satellite probe in low Kerbol orbit, a bunch of parts were destroyed by heat, but the probe core didn't suffer any damage and survived until it "crashed" into the star : Happened to me a couple of weeks ago, so I was only able to find this screenshot taken a bit before the "impact". Probe being like : Sorry, couldn't help, this was too good of an occasion... Included Attachments: .ipsImage { width: 900px !important; }

Not the solution that I personally would prefer, but I agree that it would be a good and reasonable improvement of the current feature that would need less work that reworking the system the way I suggest. More generally I wish there was some way to lock or color code vehicle stages so they dont get merged together when you fix a payload to a rocket (so that the vehicle B stages would act as 1 "non-triggerable" stage of vehicle A). Also so they don't get "mixed" in the part viewer. Not really, because for one, as you say, there is no hierarchy, but most importantly, while I can have one "heavy launchers" directory with 10 files inside, having one "heavy launchers" workspace with 10 vehicles inside could put the game on it's knees and force me to work on a craft at 3 fps (I'm not exaggerating, that is what I got with complex heavy rocket still nowhere close to the VAB size limit). But maybe I missed something ? I'm asking genuinely, no irony there, because you seems to be comfortable with (and attached to) the current system while to me it is very frustrating, so I might be missing something. Do you think you could maybe post one or more screenshots of some of your uses cases so I can see when and where it works well ? Easy, if it contains many vehicles, either copy all of them and let me decide which one I remove and which one I keep after pasting them, or copy only the one that was "active" when the file was saved.

I get the idea for the new system. The point of having several vehicles loaded in the VAB is useful when assembling a rocket with it's payloads, but considering how it performs with big and complex crafts (lot of pieces), it doesn't feel really usable to me as a mean to have a library / collection of craft in a single file (and if you consider the potential bugs in symmetry, undo/redo, staging groups, control groups, deltaV calculation, etc... it's a recipe for disaster on an entire spacecraft collection). Also the need to go through the "save as" process each and every time and having to name both the workspace AND the ship really feels cumbersome. What I would like to see is : Keep the multi-root / multi vehicle in the VAB & save file as it is useful in many cases (assembling payloads, testing vehicle variants, testing scenarios, etc...) Only have one name for the save (which would be the default vehicle name no matter which sub-assembly you choose to launch) Add the ability to have named folders A dropdown with the existing folders / paths would replace the current "workspace" input in the "save as" popup for rapid folder selection Bonus: have a list of icons to choose from (rocket, rover, payload, lander, deep space, satellite, station, local SOI, interplanetary, ...) When merging two files A & B with A being the one loaded, either : make the merge into a new file instead of merging into B so you don't risk overwriting anything (I lost a few blueprints because of that) or add a copy button directly on the file thumbnail that gives you the corresponding json (of B in this case) in the clipboard ready to be pasted into your currently loaded VAB (A in this case) without having to open B then reopen A Add a "save active vehicle as" button that would save the currently active root into a separate file (without leaving the current VAB / file). I've seriously come to a point where, for vehicles I consider "finished", I maintain a list of ".txt" files containing the json (that you get with ctrl+c) in one of my desktop's folders because it feels easier and safer to open them and copy/paste them than using the in-game system.

I share your feeling! I really hope the colony update will improve the need to have manned missions, but I somehow doubt it will resolves the "Kerbals being interchangeable" issue...

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: Intel Core i5-8600K | GPU: Nvidia RTX 3070 | RAM: 64 Go So I think this is related to the following bug, but it only talk about rockets, so I'm not sure if it's the exact same bug or a very similar one: Before the bug happened I was trying to make a rover when I realized that the order you build things with structural parts plays a big role in how sturdy your rover frame is : Red dot is the root node, then construction order follow the red lines. As you can see while driving parts were either going apart or into each other. Then I decided I would make a sturdier frame, so I did this : Then as you can see in the attached video, out of 6 try : 4 resulted in immediate physic instability and violent vehicle disassembly, 1 needed a bit of help before getting attention of the mighty kraken, 1 was ignored by the kraken despite my efforts (I must conclude he is not omniscient after all). sturdy-rover-instable.mp4 sturdy-rover-instable.json

While I don't miss the procedural missions as much as I thought I would, I will say that those missions added to the money constraints was the only incentive I had to try to create "industrial lines" of spacecraft that would be the most DeltaV efficient and cost effective for specific kind of roles. Like having a rocket blueprint for LKO / small payloads, one for HKO / Mun / Minmus, a rescue vehicle, and so on. I currently build new rocket almost each and every time, and without really caring about efficiency too much. Though I agree with the devs, that the old system was too grindy. I never got past Duna because one man cannot do so many Duna SOI rescue missions without going a little mad! That and driving a rover on Duna for too long killed my motivation back then. But yeah, maybe once we have colonies and resources, some procedural secondary missions could be nice, if they don't feel like a grind but more like a bonus or an alternative way to get resources (or Kerbals? or Kerbal experience if introduced back into KSP2?).

*disclaimer*: this is going to be a very long post concerning the science gameplay, my experience of it and the things that I think would make it even better. I might cover subjects already talked about in other topics, but everything being somewhat tied together, I feel the need to draw the big picture of what science could become. Before the main piece, let me say that "For Science!" was really what I was waiting for (in terms of features, progression, challenge and fixes / improvements) before going back to the game after early access release. The team did a amazing job and made KSP fun again for me despite the remaining issues and all the work still needed. So much so, that I've officially beaten my KSP1 playtime and gone way further into the game! A - Science should be more educative I feel there is a missed opportunity here. A big part of KSP is learning interesting stuff and getting a grasp of how things really work (in a delicate balance between a realistic enough simulation so that you get the concepts but fun enough that it doesn't feel like a real rocket scientist job nor qualify you for it ). For context, in KSP1, I personally hated the mystery goo because it felt to me like the "unrealistic" / "sci-fi" experiment. So, while I get the idea that having a science part for each kind of sensors (thermometer, barometer, anemometer, ...) might be too much, I would really like to have some "real" (in the game world context) data show up. So yeah... you can tell me the "Science Junior" is a bundled weather station that does several type of experiments at once and give me a fun and yet interesting text reports attached to the overall experiment, but please: Give me real sensors and instruments (seismograph, spectrograph, radars, lidars, ...) and give me the numbers / data that goes with them because I would love to learn the range of temperature on the Mun, how big the earthquakes are on Pols on the Richter Scale, or how hard the wind blows on Eve... or Jool! Make me learn what kind of other interesting experiments and data real world scientists are after! B - Science could be more immersive I think it would be more immersive, more interesting and more challenging if science was better tied to gameplay in addition to being a currency. Let's say at the beginning of the game we have only sparse and imprecise data on the planets and moons (less than we have now in the tracking station) : First we could launch and run the first experiments in Kerbin low orbit and we would learn the Kerbin inclination (about that... it would be nice to able to see the inclination of planets in the map with a line going through the planet, the equator line, and our current angle relative to one of them), then do the same in high Kerbin orbit and learn if a Geostationary orbit is possible and what the Altitude and Speed needed are, and those informations would be permanently added to the map (or to "The Science Diary", see below). A bit latter down the line and I want to go to Eve. Now, I could go blind, or I could send a probe with the proper experiments to learn what the temperature and pressure are to select the most appropriate parts for my next mission, and to see if my Kerbals would survive the trip. Time to go to Jool? Maybe running that radioactivity experiment would be wise before sending that big ship (if we had environmental hazards for sensitive electronic or needed to shield Kerbals from high levels or radiations *wink wink*). Wanna go on Eeloo? Oh, did we forgot to tell you? We only have a rough estimate of it's gravity, it's in the range [0.05-0.2], maybe you should send a probe with an accelerometer to measure it before trying to land Kerbals on it! This kind of mechanics would have the added bonus to bring the opportunity for more missions both to guide the player in what experiments serve what purpose and also in its overall exploration of space. C - I need the "Keri Diary of Science"! Ok, all those experiments are greats! But there is a lot of different types, lots of biomes and lot of bodies (the astrophysical kind, not the Kerbal kind... although... ). I'm tier 3 and I'm starting to get lost on what I did and what I didn't do. Doing a mission in KSP takes time, and there is a lot you can do, so doing a mission to realize half way through it that you've already done that experiment in that very place is a real bummer (and one reason to get bored out of the game). So, what we need is a journal to track our progress, plan our missions and re-read those reports we forgot to read because we where so happy and eager to clic on that "send" button! It could be a panel that can be deployed in the tracking station when checking a body characteristics. It would contain a section for each kind of "place" (high orbit, low orbit, atmosphere, surface, undewater), an entry for each kind of biomes, and sub-entries for each type of experiments. Some of them would be grayed out or invisible so we don't get any spoiler beyond the obvious ones (high and low orbit would always be presents, atmosphere would be visible for the obvious one like Duna or Eve, experiments would not be visible until you've unlocked the corresponding parts, biomes would not be visible until you have encountered / entered them once). They could also contain a picture (so you know how to visually identify the biome once you've unlocked it). And of course, once the experiment has been collected back to KSC, it would display the report/results. It would also have the added benefit to motivate the completionists into even more missions and game time \o/ (though I suspect the hardcore ones are already tracking all that by hand ). And it would do so, even if the science points where not useful anymore to their progression because everything is unlocked. It would be also nice to have the ability to map the biomes like what the "Orbital Survey" mod do (and maybe map other things like "illumination" to find those places in semi-permanent shadow or light for our future colonies, now that we have axis tilt!). Also, surface waypoints/markers please! *pleading* D - Various things in unspecific order: I think the "robotic arm sample" and the "Kerbal sample" shouldn't have the same value to have an incentive to send Kerbals (think a vial of dust vs a bag full of rocks). Overall I haven't really felt the need to send any Kerbal in space over robotic missions (aside from when a mission asked me too and between tier 3 and 4 with the 1st version of orbital lab) . I'm sure some will make the argument that it is realistic, but I feel like sending Kerbals in dangerous situation is part of the fun, and the approach "robotic" first as pathfinders and "manned" next as more thorough exploration feels better. Now, I suspect this might be addressed with colonies and then later with resources. In the same spirit, I think there shouldn't always be a robotic version of the experiments (like the diving bell), or there should be a big tradeoff (like with the robotic version of the orbital lab) either in resources (electricity, number of science points, ...) or weight or volume (maybe the automated version should sometimes be bigger). Also, the robotic arm needs to be smarter (or configurable) in the way it can deploys to do the sampling so we can give him vertical orientation for example. The orbital science lab should at the very least have a separate "deploy" option, so it can stay deployed and resume experiment immediately when triggered. Ideally, I think the orbital science lab (especially the habited one) should be able to buffer more than one experiment at a time and automatically resume progress when switching biomes. Otherwise I don't see how you could ever do the Kerbin's "beach biome" for example. I get the idea to unlock science parts progressively (incentive to make more missions instead of only one big "mother of all experiments") and to scale science points given by experiments according to difficulty/reachability. But the tier of first unlock should also play a role in the points given. Having 16 points for the radioactivity experiment on Kerbin when at that point in the tree any unlock is in the 1.5k range feels utterly useless. At least something in the 80-160 range would make you feel like it would help you gather the points your are missing for the next unlock. Kerbol (the star, not the sytem) needs some love guys! I was really disappointed to have my cheap (can't get too close without radiators *wink wink*) "Parker Solar Probe" not being able to gather any science, even in low orbit, with the "Science Junior". Also, I'll say it there: with it's static surface and lack of solar filaments, Kerbol is visually... underwhelming, compared to what many other games can achieve regarding stars. Having the atmospheric science part makes me hope for either Inflatables Parts (for balloons and airships) and Rotors/Propellers (like "Ingenuity" on Mars). I like the automatic transfert / cloning of science experiments & samples, but I personally fix the limit at "while I can imagine the manned capsule having inside storage, those probe core sure does feel like they have internal memory for reports but doesn't feel like they have a container for the physical samples". Thus I would advocate for "Sample Container" Part that would be needed unless you have a capsule / cockpit. Also, regarding transfert. I know it happens through port docking, but let's say I'm flying a tiny drone in Duna atmosphere to gather the atmospheric samples, then flying it back near my return rocket with Bob waiting there. I could "eject" the probe core and have it being "parachuted" down near Bob (instead of having to dock a mini airplane onto a lander which is... much harder). I didn't see any option that would allow Bob to retrieve the experiments from the probe on the ground. Did I miss something ? E - Prospective: Science complexity & balance Ok... this is probably going to be the more controversial subject, and probably something that should only come in the distant future or in a mod (if ever). And don't forget that many of the arguments (around balancing some aspects of the game) that I will make here, might be addressed through colonies and resource gathering further down the line. I think it would be interesting to add complexity that could be tied to specific Parts / Experiments in the mid to late game in terms of experiment timeframes and coverages. In term of timeframe we could have: Short term experiments like what we have right now, Surveys like monitoring temperatures over a full day / night cycle or a full orbital revolution. It would bring specific challenges like being able to power something up for a full Mun day/night cycle or having to keep a permanent CommNet connection with Eeloo for nearly 20 years (assuming survey reports are too big to be stored in the vehicle and need to be streamed back continuously). In term of coverage we could have: Single "on the spot" sample like what we have right now Multiple outspread samples with minimal distance between them like putting 3 seismograph running at the same time in the same biome with a minimal separation distance of say 100km to do some kind of triangulation or having to collect 10 samples in a concentric circle around your first one in order to have reliable data and validate the experiment. It would incite players to be creative with rovers or efficient lander designs you can send in batches, etc... Full (or close to it) surface mapping of bodies or areas (ex: 80% of a specific biome) like a lidar survey that would require players to have a satellite in polar orbit or a specific orbit like the equatorial ridge of Dres. Of course you could match timeframes and coverages for even more challenges! That's all folks! If you read this, thank you very much for taking the time, you are one brave soul ! TL:DR : Science is great but could be even better! More educative / instructive, better tied to gameplay and engineering challenges, with proper tracking and planning, and finally maybe a bit more challenging.