Dakitess

I've never played science except when it was brought to KSP1 back in the day. So just once and things might have evolved then, but the common feeling of our French community is... a rather not interesting game mode and what I see about it is really not inviting to try it again. Anyway, about parts, indeed there is clearly no point to have separated in multiple modules, if they have barely no impact in price (no more price in KSP2, furthermore). They are compact enough that you would just slap them on any craft "just in case", and use it accordingly or forget about it. As you guys said, right click, make science, repeatedly, it's not interesting, better assemble them all in one main science part or whatever. In the same time, you totally lose the RolePlay aspect of it. One big part to rule them all ? Meh. I don't know, Science seems to be flawed at the root because of how it's done, relative to parts and to the context, the objectives, the incentive. It lacks depth, coherence, some way to reward the player that "think" about it, about a specific mission to register specific data that leads to discoveries. It still does not fix the Science Part Number question haha.

The reentry effect really looks like some 2D relative textures, you know, just like the cross plans textures trees back in the day that would rotate relative to your position to always show the best foliage section. It does not feel very 3D, very dynamic, nothing like a heated flux, a moving fluid. It is not ugly, but I feel it could be way better and I hope it will be in upgrades, better start with something than nothing and we have wait too long already ^^ I also hope that we will get proper trails rather than very local heat graphics. And I hope that the ablator will imply some specific look relative to its degradation : the effect on the heat shield is quite nice actually ! But ablator mean there is chemical / mechanical transformation, not bare brute force reentry so I'd like to see specific effect on the trail.

Already addressed : you don't necessarily know which diameter you just used. I know that sounds very very minor, it is, except when theses labels are not easily readable, depending on viewing disability or generally speaking a UI not perfectly suited for anyone. Again, that slight highlight would just... slightly highlight a direct compatibility and that's it, it won't put you into jail of you use another part. It won't break any kind of accessibility of generic ergonomics. It's just a very minor non invasive UI addition that might help more than one player, quasi guaranteed. Just open your game and think about it in action. And feel free to disagree if it truly sounds silly / counterproductive. No need to repeat that it's by no mean a priority, since we already all agree about that, this is not the question. Would it add to the ease of use ? Be neutral / without added value ? Degrade the situation ? Be honest, I get it about your feeling that it would lead players to not think about part choices by themselves, that's valid to some extent, even if I don't agree and don't find any situation that suits this scenario, as someone who use KSP as an expert Stock designer and in the same time doing many workshops in school, high school, for people that never used the game before and need a 4h introduction to be autonomous with it : part choice is a nightmare, a real, tough, one. KSP2 is way better, but we are repeating ourselves again, it does not mean it's perfect yet and that it cannot be improved, with this suggestion for instance. Yes, it has label and proper classification now, but new players don't even know there is multiple diameters, they don't know what the label refers to, they can't read it at all on a vide projector during a demonstration in class, they can't follow the logic. Yeah students are sometimes a bit brain-lazy Just... an highlight to help it out during the first hours that are crucial to help no leaving the game by frustration. We know it happens a lot with KSP, everything that can help in that sense might be good to consider. And again, as an experimented player, I would deeeeefinitely use it, no doubt about it, and I'll manage to ignore it to use another part, promises :p

Haaaa I see ! Yep, good idea indeed, quite like the hovering on the stage tree will highlight the actual part in the craft

No, it looks like you're not reading me and you're injecting your idea of the suggestion inside mine. I repeated multiple times that all that matters, the whole core of the suggestion is ONLY the ability to highlight parts according to their diameters, based on the one that had just been added before. That's it. The contextual help for beginners is another thing that I find interesting and which is still completely not what you've described, but in any case, the very basis that is more worth debating about is the diameter thing. So there is NO "put one of these specific parts here". The whole parts library remains the same, exactly the same, there is nothing being filtering out, there is no new classification, there is no drastic selection : the same catalog. With only some light and non invasive highlight that shows, among the IRW, which one is the good diameter one. Among the various nose cone, which one is the good diameter one. You still have to look for them in the different tabs. You still have to scroll down if they are... well... down. That's it, I insist. I won't elaborate any further about it with you except if you have new elements, I respect your opinion but I got it and we are drawing circle right now. Regarding the reverse idea, i'm not sure I understand the circumstance it would be benefitable : most of the time, I guess, you're building a rocket, a satellite, a rover, and because you used "That Part", you'll chose next "This Part" to go with it, like, the choice of a next part mainly comes from what you have in mind and what you've assembled so far. I am not sure that you will look for a part in the library, to select it and see where it could fit, do you ? If it's a stackable part, like a tank, you are actually looking for a tank with the correct diameter, you're not selecting one tank to see where it would fit. Same for engines I guess, and for all the others parts, except the one that are not stacked vertically with the green nodes and which would not give any result regarding possible placement, since it's free ?

I would love some Information Delay in KSP, with an intelligent and interesting implementation, gameplay wise. And as a difficulty togglable option haha. But I don't really know what it could look like... The need to prepare all the actions before, with some automation, delays, triggers ?... Nah, except for hardcore kOS / kRPC players, it's not gonna please to much. Yeah I don't know how it could be translated in the game while being interesting to play for the mass. Maybe some kind of very easy graphical coding, with given events and actions. Like, you actually set the maneuver to get an encounter with Duna, and you realise it with barely no delay at all since you're around Kerbin. Then you'll have to make an MCC to get a proper plane alignment and refine your encounter to have something like 15km aerocapture altitude : we all know that the realization of the maneuver will have some imperfection and result in 50km Pe altitude. How should it be obtained ? With real life delay, like, having to trigger full Thrust 2'30" before the node and shutting it down 2'30" before the estimate end of manoeuver, while the DV Gauge would be still 30% full because, well, delay, you need to send the signal before the action ? If it's some kind of automation then there is no need for delay implementation in that case : you program "this" manoeuver, you send the action to the probe to do it, and to do it perfectly : how then to add some imprecision ? A random small percentage with a gaussian distribution and better probes has better precision ? Why not ^^ But then come the aerocapture and landing : there is nothing absolute here, this is a sequence of action that you're not supposed to be able to view and pilot in real time. And it has some relative triggers : radar altitude, air speed, attitude, etc. So yeah, maybe a PopUp windows that tells you you're entering the SOI, and invite you to set up the aerocapture / landing sequence with given bricks : events, triggers, actions. It would be fun actually, it still preserve the F5/F9, and it's actually just like you would set your PE at 15km, warp, and state that it's too high for aerocapture or you need to put the craft at another attitude to maximize the drag, you would F9 and get it again. Same here, but you would have some dedicted interface to plan the whole thing and adjust it if necessary. But no way to adjust the flight in real time by itself. I'd love to see something like this, it would be a cool novelty even if I don't think it will make it to the game stock. Maybe a mod ? At least, crewed mission would operate the same as today and could be the main reason to do so so, because so far, there is no much incentive to use Kerbals.

So you really prefer separated and dedicated tutorial rather than contextual help ? You really prefer to have a tutorial that teach you how to assemble "that" specific rocket and which you can do and redo, rather than having some highlight to guide your choices about simple diameters compatibility, while being totally free to do otherwise ? Open non-rethoric question, you may ! But I clearly don't. Actually this is what I dislike in tutorial : they are very specific. They are an "how-to" that won't resist much to any change. Just like most of the first KSP1 tutorial by the community, which were good enough to reproduce exactly the steps but lead to so many people don't understanding AT ALL where that orbital drift came and why they kept being pushed away from their target even if each time they would properly cancel their relative speed and push toward the station. I don't see how this slight highlight will make them dependent of anything, how it's spoonfeeding, it's quite an hyperbolic exaggeration here. It will just help them to identify the part which fits the diameter, that's it. Same goes for expert players. Then you're free to use the one just below, which is bigger, because... because you're free to do it. It substract nothing to the judgment, the decision, really nothing, or you still did not get what I'm speaking about. Anyway, thanks for you feedback about it, I can get that it's not necessary by any mean, even less a priority, but I keep thinking that it would a cool, convenient and subtle QoL improvement for about any players

The tutorial definitely won't enter in that details so far, or it will be for a specific "your first rocket" and that's it. Afterward, no help for the beginners to figure out what would / should go in this place, what is the correct size at a glance, etc. This is the main default of Tutorial : they show, you follow, you feel you got it but finally, you did not. You can start it over, but you'll only repeat the intended path, while what you're looking for is some contextual help when you're assembling YOUR rocket. Anyway, this is more about Diameter Compatibility immediate identification rather than a contextual help, which would be a nice bonus to me. I get that you don't feel this necessary : it's not "necessary". But just because things are better than before or even good, does not mean they can't be improved further I also get that you don't understand what it could look like, a very easy to ignore highlight, but that's partly my fault since I did not provide any pics so far. Of course that part clipping will lead to more interesting design. Of course that using a wide diameter below a small one can form a support for interesting shapes and "out of the box" aesthetic. Thanks, I have something like 7000h in the VAB and SPH and I play only Stock because I love to reinvent based on a given common part base. This is not the subject : I, as an experienced / expert player, still want some streamline identification for parts. Simply the good battery/tank/IRW/whatever diameters based on what I just used. Yes, KSP2 does it way better already. But it can be even better. Especially for beginners. Suggestions are not a place to only drop first priority fix and bug hunting. But also ideas and suggestions. And if it happens to be a good enough idea that are not taxing too much time and fits the actual ongoing development, well, at least it's registered !

It's not a "Now put a parachute". At all. It's more a "among the parachute, this one is the good diameter one". That's it. Veeeeeery easy to ignore. It's juuuuust an addition to the existing "size" indicator : it has colors, it's clearly written "XL" but you don't necesseraly paid attention to what diameter you choose right before, and then it's not help seing "XL" or "L", you'll end up trying and then knowing which one it is. A matter a second you say ? Yes ! Indeed ! But why not improving that second ? Size indicators are also a QoL improvement which is about a second of two figuring out the part you wanna use. It's not something crazy uh ? Just very convenient and practical, coz I swear, the KSP1 logic is / was terrible and the KSP2 one is way more better but still not perfect. So nothing like a priority, more like an idea, a suggestion. Oh, and regarding Beginner, you definitely want to take them by the hand if we are dealing with the SandBox point of view where all parts are available. Definitely. Don't make me believe that you introduce KSP to someone and let it cook a frustrating absurdity while scrolling in the part library not having a clew of what to do. So yep, this UI addition would be a good way to guide a beginner identifying what parts make sense at what moment and the player will learn the "why" and "how" if the game don't insist about it. But again this is a bonus way to see the UI, It would be fairly good as a start to only get that slight highlight of the correct diameters parts without including any part nature.

Mmh because it would only be a slight highlight that you Can very easily ignore or even deactivate ? For beginner for instance, if would be a very nice feature, to me.

So yeah, I think I already spoke about that when KSP2 released, but not in a dedicated thread. I won't have any image example to illustrate this, I'm on the train with very limited bandwidth, and I'll forget to write it down again if I wait more. The suggestion is to benefit from the UI Part library of KSP2 which already is fairly better than KSP1, since it properly shows diameters. This Week-End I participate to a 30h KSP1 Hackathon, no pause, no sleep, it was damn good ! And damn fustrating to aaaaaaalways look for that damn specific very logic tank. The size-mass-price-whatever filter are no help, they don't work as intended. Anyway, in KSP2, what would be a huge step forward in ergonomics for both beginners and experts player, is a UI assistant that would just highlight parts in the library accordingly to what you just used as the previous part. As I said, no pics, sorry, I'll try to add them later, but stay with me, it's really easy and straight forward. You choose the nice 3 crew pod which as a top M diameter and a bottom XL diameter (don't remember exactly haha). Then the game automatically highlight the relevant parts in the library : parts that can be stacked with the good diameters, including adapters of course. Tanks, batteries, engines, parachutes, etc. You can get it "simple" as is, or go a step further : if that's a pod, then you'll want below some "mandatory" (i.e. very logic) Fuel tank OR Decoupler OR HeatShield. If it's a tank you just added, below any other part, then only the bottom part is free, so it will highlight part according to the diameter and the nature : decouplers, engine, other tanks, adapters, and so on. You can feel that the first step that ignore the nature of part and just highlight according to the accessible stack diameter is sufficient, since pretty much anything is possible in KSP, it's not that benefitable to process that above a pod, you won't often use a tank. Except that, well, skycrane, and so on, so let stick to the "easy" main option ^^ It feels quite "simple" to implement (no dev here, haha) and very worthy ergonomically speaking. It would streamline well better the design, helping the user to identify the good diameters, especially when adding simple tanks, decouplers, heat shield, etc. Of course, the other diameter remain totally here, visible, clickable, usable, it's just a highlight diameter compatibility and that's it Of course it would totally ignore the parts that don't stack vertically, but whatever, you would not need / want recommandation about thermometers, legs, etc, would you ? Your opinion about it ?

You missed the point completely : they DO are quite bad at cherrypicking, which is actually a good thing for transparency, indeed. It's quite a shame sometimes / often because it gives the feeling that they don't care at all, and is was very specifically the case something like 2 to 5 months before the release : almost all the media were clunky. Video were laggy as hell, picture were showing defects and artifacts that would have been very easy to avoid. I'm not speaking about "hidding", at all, i'm speaking about caring what they share. We don't need to see that craft parts are almost always mis-aligned because of a Kraken-like distortion e-v-e-r-y time. It was do deceiving and worrying to see. We don't need to see that the ground texture is horribly stretched right at the place they consider it good to take a screenshot while it was better elsewhere. And the list of examples elongates, really, it does, the last months before release were HORRIBLE communication wise, with all the worst choices possible (not only media...) and an actual feeling of amateurism or no paying any attention at all. It even lead the community to be extra careful and picky at the release, to me. There is a wide spectrum between Total Transparency and don't giving a [snip] about what you share. Anyway, this apply to before-release era, no more. Now it's better, communication is more relevant, less amateur, and is getting more and more transparent. So, yeah, my words here were to say that since we know that they're not the best for that exercise to cherrypick their location, framing, craft, etc, we can consider theses screenshot as an eventual good reflect of the whole terrain. Which is "nice". It's some part of humour and sarcasm, and some part of truth. That's it. -------- Regarding the NavBall debate, would you guys like the Juno-way ? Or some kind of on-screen centered transparent HUD-ish information ? I feel like the NavBall is very efficient so far, i've not played much with Juno but it was not a revelation ergonomically speaking. It's nice to see alternatives though.

Do you really act like this on a daily basis ? Any message I see from you is very defiant, your opinion is the only one valuable and if someone express his own which is not exactly the same as you, you'll clearly say so with definitive affirmation, most of the time non legit because there is no nuance, no place to discuss about it. If that guy say that he wants better clamps, let it be ? You can question it, otherwise there is not discussion but all your questions are formulated to imply that this is repurposed bovine waste. Edit : "repurposed bovine waste." I dont EVEN know what I was remotely writing here oO What the heck xD i'll even let it this way haha.

Mmh things are getting better, stock graphics might reach an honest level in a year or so. Won't be the KSP2 some of us actually were awaiting for, but it's improving. Since the team is not really good at cherry picking and showing the best part of their game (...), we can assume theses are not some very situational improvement but rather a general upgrade and it does not seem to be completely ruined by artifacts and all. Don't get me wrong, textures are still stretched, ground is still totally flat triangles with some scatters on it, there is not kind of physics tessellation, ni micro-topology. These are required for interesting rover session.

But... Do you really don't pan the cam in KSP1 so that you can see the bottom of your craft while also seeing all the information exactly where it's best to find them ? Do we agree that this way, in a manner of... half a second, you actually get the very specific point of attention, which is the landing contact, at 2-4 centimeters to the very most crucial information which is the speed relative to surface, at the top of the NavBall ? With also the eventual residual drift thanks to the retrograde being pushed away and not strictly vertical, etc. To me it's the exact ideal position. We just need that little manual pan, which is very rapid, very adjustable, and not required for 90% crafts by default. Because on my side I totally agree that there is something to do about the Stock KSP1 HUD, the centered navball can be a bit annoying and should be optimized in a way or another. No question about that. But I also find the bottom-left position worst in any aspect, and the landing scenario is definitely not an issue that make the center position prohibitive. Maybe it was all about the console that can't do that so, for them, the centered NavBall is too annoying ? I might have missed that. Could be understandable, though I don't really see how console player are better suited with their pad rather than keyboard + mouse just like on a regular PC.

Haha, there we go ! I'll link this post that contains a whole comprehensive survey about it : Have a read about it, really, especially because it's the "state of the art" before KSP2 actually released, so before the huge mess, only in a positive and speculative way, what the french community statistically was waiting for the most ! A quick overview of the main result : I'll stick to my opinion back in the day, and which is quite adequate to the above data. Among anything else : graphics. Graphics. GRAPHICS. Environment, scenery, something to look at, an incentive to actually take off, land, drive, explore, fail, move around, rebuild a rover because of the rocky challenging terrain, getting back to Drone exploration because more convenient, and finally finding the little pearl, the perfect spot that you're proud about, to share screenshot and coordinate : a stiff canyon with sharp and detailed texture, micro-mid-macro topology, collidable little rocks, etc. A river. A mountain, a valley. A waterfall. A cave. Anything but by the 2020+ standards, something worth exploring. Incentive. I don't have any in KSP1 except using mod but still not perfect and very dated technical foundation. I don't want anything much more than Graphics. Actually it's the only real thing I was waiting for and when I saw the trailer, dang may I say I was hyped like almost never before. A NEW technically up to date KSP, this is all what we were missing !!! With that, anything would be possible : performance, scenery, the rest would come as bonus content, added features, mods compatibility. But a good technical foundation and true graphics upgrade to set KSP2 in the 2020 decade. The previous data and the linked methodology show how much it was a common request, a real expectation. And I repeat, it's not a reaction past KSP2 released, it's back in 2019 ! Well... We all know how it turned out ^^ It's getting better, but there is still a looooong way to get proper 2020+ visuals. Edit : oh ! And Discrete Procedural ! The thing I like the most about KSP is... Being able to build whatever based on a given list of canonic parts. It's an incredible challenge, and the reason why I spent 7000+ hours in VAB / SPH, fine tuning design, trying to innovate, looking for efficiency, overcoming what has been done, etc, everything only with the stock parts, not a single part mods. I LOVE it, I really enjoy this challenge, and this is why I don't like Procedural. Even for wings which can be debatable, I'm not used to it so far, and I'm not sure to like it. But Discrete Procedural is way to cumulate only the good aspect of procedural while keeping the discrete Lego gameplay. It's probable that most of you get what it is, but I'll write anyway for the others : FL-T100 Fuel Tank Small 150 (104.1) 0.5625 0.0625 2 000 6 50 45 55 FL-T200 Fuel Tank Small 275 (183.2) 1.125 0.125 2 000 6 50 90 110 FL-T400 Fuel Tank Small 500 (316.4) 2.25 0.25 2 000 6 50 180 220 FL-T800 Fuel Tank Small 800 (432.8) 4.5 0.5 2 000 6 50 360 440 You have this for "Small diameter" tanks, right ? Well... What about a single one, adjustable in lenght, with a minimum increment according the smallest actual tank heigh ? You add it to your craft and you slide it in WYSIWYG fashion or by numerical input if's too hard and there you go : one part, less performance hit, less wobble, but the whole spirit of the original lego gameplay. Nothing removed, like, at all, but only advantages. I must say that I don't understand why it's still not the case for KSP2. This is really part of the thing that should have been identified as good innovation to the way we build, while lowering computing demand and fixing most of the wobble issue. I know that the original KSP1 team and the new one never got attracted by procedural yet they did for wings, but here there no procedural cons, only pros.

Uh, like, "geographic coherence" (pardon my English though, it sounds very wrong xD) and the fact that axis are misaligned, forcing the user to correct the boresight (?) since it's diagonally positioned ? Having crucial information not directly close to the center cone of vision but rather on the side, forcing the user to switch from the craft to the data, at crucial moments ? Did you read it, or ?... Please do, if you want to debate. Totally open for that, as ergonomics can be very subjective, just like this thread shows. So... Did you read as well ? The camera feed example is indeed a way to show that centered information, respecting axis, is way better since you don't need a reference to get it right and you don't have to adjust for a misalignment between where / how the information is disposed, and what it actually shows. By the way, theses video flux being off-centered on the entertainment screen on the side is... Not a good thing by any mean, just a compromise, there is no added value, just the obligation to not obstruct the main HUD data already well busy. Which is not the case for KSP and the situation we're discussing about. Do you actually like to look 25-40° on the side + 25-40° vertically while doing a maneuver ? Because where I work, this is only an acceptable compromise when we can't do otherwise. My two cents were just a way to get some inputs from an Ergonomics point of view, not totally adequate to the actual situation : this is by no mean any kind of authority argument, just something like... My 2 cents. You can discuss it, you can totally disagree because a 3rd view game is nothing like a 1st subjective view in a vehicle. That's not the point, more about some common principles and a specific subject regarding NavBall position and rather why I would prefer the center view and why my basic knowledge about it would support it, that's it. Video game HUD / IU ergonomics has its own field, but it's quite famously derived from IRL UI

Wow, i've never seen as many pages on a dedicated topic Impressive ! I've read something like 75%, it's interesting. I'll add my 2 cent as a former (it's very (very) recent haha) ergonomist, with a little UI / UX experience in a specific domain I won't elaborate here : you really want "geographic" coherence as much as you can. If I have buttons on both side of my wheels, they need to control accordingly the main pilot HUD and the secondary entertainment screen. If I use proximal cameras, like 5 around the vehicle, they need to be presented in a small grid accordingly to their overall position around the vehicle. On this example, some people can have hard time figuring out that the "top" one on the screen is the "facing" one, because the representation is equal to a top-down view, while you see the screen from a personal perspective view. This is already a compromise, but it's mainly okay because there auto-references : you can set the silhouette of the vehicle in transparent below the camera feeds so that the user will passively understand what is where, what video is showing which axes, etc. Here, setting the NavBall on the side is not ideal and we know by KSP1 that a center position is doable, while maybe nor perfect either since it can mask a small part of your craft during the crucial step of landing vertically. Fortunately, the panning was perfect for that specific reason and solve in half a second. Having the NavBall on the side misalign the axes. The NavBall Up is no longer the Craft Up. You need to transpose diagonally, without auto-references since the NavBall is... Well, a sphere. Let's agree on a point : there is nothing impossible or prohibitive here, you can get use to it, and you even will. But it's not ideal, and quite easily less optimal ergonomically speaking than a centered one, even when considering the drawback and advantages of both situation (masking / alignments). I'd rather have it centered and movable than the opposite, while the actual design is totally made up for corner. Knowing that, a centered NavBall could have been properly designed to minimize the occultation while providing the essential information. Transparency, contrasts, shape, additional easy to read information, etc. Juno has innovate on that aspect, won't say if it's better or not, but there is solution. And really, I need to get the altitude, the speed and the NavBall orientation aligned with my craft, on the center of my screen.

Well RolePlay is a thing as well, to me. I'm totally fine with HUGE massive shield that would be required to protect an interstellar ship against the very high speed and micro-meteor encountered during the trip. Even it would not protect from anything in game because not implemented. I would actually find a bit deceiving to not get them. Obviously, it would be 10x better to get gameplay integration, like some kind of... Of heat, actually, a gauge that would represent the damage endured by the front facing parts, something very simple that would be an equation with apparent cross section, speed, distance traveled

Hum, no, no. Stop with this argument. There is PLENTY way to get proper scenery, while not doing them handcrafted. Obviously, thanks captain. Examples were given. There is probably many others. You'll say that KSP is a way smaller team, that it's not using the good engine to do so, etc : yes, and that's part of my point. It won't get get good enough even with time. It might get correct-ish, and enhanced by mods. But not something that would set it apart from KSP1, from the old decade scenery, which is, to me at least, very VERY a shame. That's it. And yeah, trailer, not actual gameplay, blabla, the debate has been treated a thousand time, it's fine if you don't see any promise in it, no expectation, no engagement, if you can show whatever you want as long as you mention the magic phrase for the whole show, etc. Not my opinion, by any means. You show me a BIG focus on terrain and scenery ? I don't expect it to be the way it looks in the trailer, but I expect it to be a major thing in the game. You show me a BIG focus on the per-part physic destruction ? I expect something related in the game, which is not. Etc. This is not a gimmick, a transition, a camera work, a cut-scene, a context, that would be legit to give a nice continuity to the video, a global enhancement, etc. No, it was a specific "LOOK AT IT ! SCENERY ! TERRAIN ! TOPOLOGY, look, look ! The wheels bumps dinamycally on a rough terrain ! Look, mountains, valleys, sharp canyon, you'll set in a proper scenery which rich details, at high-medium-low scale ! Look ! The 'Splosions, the destruction, so detailed, gonna be amazing, you'll love it !! It's MILES BETTER than KSP1 and we show it to you, proudly !" Nah ? You just see a nice 3d render fan-made video ? Cool.

My guess is that we won't ever have anything close. We won't get any proper scenery that are really worth the proud message "dang look at what I find, the perfect spot to settle, it's at this coordinates guys, and here are some crazy screenshots !". This is exactly why the trailer gave me the thrills, the feeling : ok now we will have a beautiful aesthetic KSP, this is what is the most exciting and what was the most lacking in KSP1. But we rather have a very shy update, and even it if will surely improve, maybe get 3 times as beautiful as it's right now, the tone is clearly that it will remain mostly boring and technically out dated graphics. No really impressive and sharp canyon with appropriate textures and not stretched ones, no real river with good looking flowing water, no epic massive mountains (appropriate texture and no strteched one bla bla), no micro-topology, no proper dense scatters, and this is the very basic, then we could think of fancy places, very specific one, but instead will actually just get theses very specific places with lazy integration in the environment, texture / ligtning / shading not matching, like a very abrupt and arficial cave, a vary rough and dumb lava crater, a weird bones field in the water with weird looking artifacts, etc. And not AA yet. It will improve. No doubt. It's necessary, and it's a good thing. It might even got to something correct with enough time. But it won't set appart from KSP1, just a tad better, no real scenery, nothing that will set KSP2 in the actual decade. Let's hope it will bring enough nowadays technologies so that modders will have fun trying to make it truely worthy.

Yeah, theses POI are really the best lever to offer a "simple" yet comprehensive story line to the Kerbal Universe. Even without a whole narration, no cutscenes, etc, you can do a whole lot with proper selection and good integration. Actually, it could pretty much be the kind of mechanism we got in Outer Wilds ! Did not played it but one of the very best video about it is surely the one from TheGreatReview, a french Youtuber : no or not much story lines, no specific orders, just incentive to discover, and to reassemble the puzzle. But since in KSP it's going to be a very very (very) "poor" content, just dropping assets after creating and writing the lore, at least it needs to be very well done. Something like 30-40 POI, 90% in the original star system and the rest in other ones, for instance. I've actually done that myself in KSP, using a save to share a "world" where there is some crafts, some flags as message holder, some decal to hold other messages in RP way. The story has a big "Foundation" feeling (well, i'm not Asimov by any means xD), while it was totally not planned since I read it 15 years ago and did not recall of it at all until I saw the TV Show. Anyway, yeah, it's possible to write a whole story in KSP, a whole universe, background, lore, call it the way you want, that set the story, the characters, etc, without the need of anything else than KSP as it's nowadays. But it needs to be good enough to offer proper incentives to the mass, not only the more passionate about Kerbals.

The last update and the upcoming one are fixing some of the weird aesthetic of KSP2 but there is still a lot of work to address the whole inconsistency when it comes to visual. I won't consider KSP2 any beautiful as long as the lightning is so messed up, as long as the paints are so "greasy", so bizarrely shiny, as long as the horizon / mountains / reliefs are so doomed by overcontrasty / over speculared, as long as we have the Back-in-2000s aliasing, etc etc etc. The list is quite long. This game looked like garbage (yeah yeah, I dare to say, I really really find it technically completely dated and aesthetically completely broken). This update helps a lot with the overall lighting feeling, it's nice, but I hope it will improve a lot more.

Did you really enjoy the Easter Egg in KSP1 ? I really found them ultra lazy, random assets being drop down with barely no adequation to the environment, no lore, etc. Regarding the "POI" shown in KSP2, so far, it's the very same, it's cruelly lacking proper design and integration with the environment, the textures, the lightning, the whole aesthetic design seem completely off with the rest of KSP. Even the last one shown is really not convincing by any mean to my eyes. Yeah, best word is "laziness" when it comes to these POI... And it actually kinda prevent the dev to build actual scenery everywhere rather than very localize and weird thingies. We can expect some integration to the Exploration mode though, some lore, some story line... Otherwise, damn, I would not get it, and I'll allow myself to strongly doubt, based on the past.

I love soooooo much the original trailer and the global sound design of the actual game.