Dakitess

I guess the equilibrium with be natural : very high ISP, whatever Thrust (as long as it's still coherent), but very very massive and dedicated fuel (or not). Just like you won't stick a NERV onto a small craft, where an LV909 will perform better since it's more light than the Nerv is efficient. Math about it are quite easy and interesting So yeah an interstellar craft using interstellar HUGE engines would not suit any use for local platenary system. But I don't see the dev forbidding their use, and they better not to, it is KSP, let us play the way we want and we will DEFINITELY see some emergent gameplay about it, some RolePlay using this gigantic parts, etc. This is no doubt that a 2 giant engine, nozzle to nozzle, will shape a magnificent sphere-ish to hold some RolePlay habitat that would shield the crew from any radiation, etc ^^ As a side subject and as already said in other relative subjects, I really really really really (really (really)) hope that they will balance the Interstellar accordingly to the actual physic. Yes, have fun with speculative technologies, high ISP, etc, this is part of KSP. But don't mess with physics : a given quantity of fuel with a given drymass and a given payload will achieve a specific DeltaV, not a capacity to reach another place by magic, without entrance relative velocity to kill at destination. I really hope we won't be able to stick thousand on tons of payload on top of a giant interstellar contraption : even a tremendous quantity of fuel with a incredibly efficient engine, won't achieve a 10% of c if the payload is big or even medium. So yeah something like basic Tsiolkovsky equation and not another system like whatever the payload as long as you assemble "this engine" with "that quantity of fuel" and you're good to go. Real physic, real transfer time (with Warp, hu ? ^^) that have real impact on crew. I want to feel the need to shorten the transfer time, and for that, to bring even more fuel, to feel the tragedy of the Tsiolkovsky equation which imply that I would have to triple the fuel already absurdly enormous. Or... I will reduce the payload by a tiny bit, reduce the dry mass of that many tanks, etc Something really challenging, it's end game, after all ! Best intuitive solution would be to enlarge the whole star system to a multi-star one, just like we go from planetary view to star view, at another scale. So that we actually really eject from our system, travel in between and reach another one wich a perfectly fine and logical speed entrance to cancel at the arrival. But I don't know if they will do that this way, I guess, it might trick it and it would be fine as long as it's coherent. We don't need to actually travel from a star system to another one.

That would change soooo much things for a game like KSP. In the good sense, obviously. I dream about that for a KSP3, be it in 15 years. Normally, in 15 years, StarEngine being the nowadays tech, it should be doable by the KSP3 team xD

Same, I would let that to the mods.

I really see it as an other kind of fuel, really... And it feels to me that people who don't want to bother with that are in almost defending Infinite Fuel since, damn, I don't want to bother with constraints. It's an hyperbole, an exaggeration, I guess, but we are not really far from this, are we ? Why maintaining the fuel constraints and not add something that is very similar and RolePlay / GamePlay relevant, which is the LS, just another resource, but not lacking interest since it's mainly depending on time rather than DeltaV ? I really feel like having an alert "20% crew resource left - estimated at 1.2 years" is really cool as it might imply a trade off because of your tight initial margin : you have enough DV to "cut" the transfer trajectory with a high-energy fuel costly back to home, that might save your crew from starving. Or you calculate it well and you're fine, doing the initially planned hohmann transfer, which might be 95% of the time since you can take some margin and I don't expect LS to be very "sizing", very impactful compared to a fueled crewed interplanetary mission. Just... Just a ton or two of drymass that you'll consume along the way. Yeah I don't really understand the reject of LS arguments. But it's fine, I just state that base on what have been written, I (I (I insist)) don't get how it can be a bad thing for KSP2. I would actually add more relief to it, more constraints, while not making any kind of microgestion but rather some RolePlay relevant addition : crew sanity, especially, depending on available pressurized space for the total crew, and the mission duration. See in my previous message for "details". Edit : and if it is made optional via a difficulty toggle, then it's pretty much like Communication, which is fine in KSP1, isn't it ?

This. The throttle. I don't know if you're trying to make fun of us, but how did you elaborate such a rant and such resistance to explanation when you... Just failed to zero your thrust ?... Seriously. I'll even guess that you made out this video knowing that you'll need to use that thrust error to mimic the issue you were describing, since at 0'38" you indeed have a "drift" that suddenly disappear by an action of yours : to cancel properly the throttle rather than having that tiny 0.5% of gas. C'mon... Edit : OR this is totally honest, you're using a HOTAS or something else to control your thrust, and your dead-zone is really not wide enough and you got plenty false cut-off. I might even bet on that ^^

Wow this looks like a very little gem to discover !

Alleluia, finally a good docking tutorial ! I lost mine on an ancient tutorial, and was too lazy to rewrite it from scratch, knowing that there were probably people actually writing tuto how I do it myself AND with the same method ! This is so unusual to see the "active-retrograde-redirection" rather than the "kill velocity, accelerate toward the target, kill again, and forward again", which lead so many beginners to endless orbital drifting... So, yeah, it's not in french but it's easy enough to understand so that I can redirect people in need here

Aside of the physic explanation, this is why you basically never want to cancel your relative speed. This is the EXACT reason why people following step by step tutorial don't understand why they are drifting around their target, warping, cancelling speed, going forward at 2m/s and 2km distance, warping, drifting, and so on : you're never travelling in straight line, you can only consider it when traveling at a good speed to distance ratio, otherwise the orbital drift will be even more important than the forward speed you gave to your craft... I don't understand how / why people keep canceling speed rather than doing the retrograde-active-redirection, when you pull / push it toward the target indicator, keeping all your momentum, only reducing it partially when approaching. It's easy, very practical, very relevant, way more efficient RCS / Elec wise, etc. Don't cancel your speed at 3km to give it back 20s after. And you do it, fine, it works, but only if you push toward the target a sufficient speed regarding your distance. 2km ? 10m/s is fine, this is plenty time to react. Any less will make you drift...

Thanks for that performance crash test, so much effort x) It seems to be a very nice multi modules station ! MANY parts looks completely off-placed, like some Kraken disassembling : is it a "stable" appearance ? Like, can you observe all the part being mis-aligned ? Are this mis-alignment getting worse and worse ? I'm not talking about the module being no properly docked, or noodle effect, but a tank being slightly / vastly not aligned with the direct closer one while it should be perfectly stacked like in the VAB. How many parts ? I might have missed it, sorry.

Yeah but... The tutorial could totally introduce the players to this UI feature, isn't it ? Like, "you can use this aid to know what part comes directly compatible to the previous part diameter used, but feel free to do otherwise, Craft Design is all about freedom and creativity !"

Ha yeah, physics, I would even trade some graphics for proper destructions, including ground impact craters :p

Seems in the range of KSP1 for "legit record" which is nice. I guess the allowance to be nose down and plunging and the no-requirement to recover successfully the craft can help reaching 1900+m/s but I did not try it so far. Thing is, in KSP1, you could go WAY faster in low atmosphere and thermal was the limit to play with. Is it still the case here ? Would your craft go past 2000m/s at horizontal flight and sea level with 1, 2 or 3 rapiers, @Periple ?

Do you really feel it as "you can only pick these for that" ? If its behavior would be to "grey out" other options, I would agree, but a slight highlight ? A light contouring ? And again it would be plenty obvious that it's just an help regarding diameter, nothing else. You would scroll and explore tabs as usual, but when diameter is relevant, such as for a decoupler, a battery, a heat shield, you would have that slight highlight / whatever emphasis to immediately know it will fit the previous diameter, and that's it. The easy-to-ignore actually feels important as it mitigate a lot your points. It's just... an aid. That you're totally free to ignore, non invasive (because designed and integrated accordingly, of course). And it could totally be togglable as an option. I don't understand how it would send a wrong, non-creative message to players, and I'm speaking as a huge legit-clipping player that use a lot of non-conventional parts at non-conventional places ^^ I don't know, I have the feeling that we've seen this multiple time in game (or maybe software ?) but I might be wrong, I'm trying to find back where / in which context.

Like, when you're building quite quickly with muscular memories, you always know that you've used the X200-32 Medium Diameter, and now that you've moved toward the battery section without really paying attention, you're 100% confident that you'll remember that you're looking for Medium Diameter, that you'll be able to read it (and other will), etc ? Cool. I'd rather have so very easy-to-ignore highlight of the good battery diameter. I'm 10/10 and 12/10 in visual acuity, so totally fine, and my memory is OK-ish if I pay attention, but I would actually use that feature a lot rather than mistaking AGAIN with that damn decoupler which is not the good diameter because I swear I though I used the MD and not the big one. Again, at least KSP2 now shows well more conveniently the diameters, but it's not hat easy to read depending on screen resolution, visual acuity, etc. I really struggle to see the point here. I'm fine debating about suggestions, but there is a little tone of bad faith and weird irrelevant resistance, I may be wrong though, I respect others opinions. Just respect mine, especially when I try to be constructive about it.

It's getting better, but nope.

Haaaaa fair enough... Damn. Or, it would be the Real Solar System with the actual real specs that are legit for orbital speed, system stability and so on, while the original one would particularly weird, with ultra high density etc. It still possible for the game, not so much in reality.

Yeah, yeah, I know, simple Game Oriented suggestion It needs to be refined !

Why not a new metal alloy on another star system, allowing for wider structure diameter to research progressively, so that launcher can be heavier, specifically because... You guessed it, the actual star system is at least 2.5 in scale, or even 5x ? So that it shift the referential, and gives the game a new breath ? This is what I've been waiting for since Multi-system has been announced. Be it stock or by mod, I WANT to actually enter the Real Solar System, at real scale, while having a whole continuity with the stock scale base system. No new physic, no new constraints, just the real scale, the real planets, and the opportunity to settle and develop a new techtree, or just a part of it, relevant to the new stellar system, to adapt to the much more demanding DeltaV. Metal alloy, new chemical mix to get double the ISP with the base parts, both, something else, whatever : when we get in a new system, I really feel that it's "you've finished KSP2, congrats, but actually, wait a minute... Yeah, you're not done". You know that feeling of "congrats - credits - oh, by the way, you can continue playing and you still have as much to do as you already done so far, enjoy !"

I don't second that. Constraints and "restrictions" are definitely a way to explore, improve, to get away with a specific objective. Say, for instance, the rover's design : without the "constraints" of a realistic detailed terrain, there is NO points, not even RolePlay, to build it so that it can withstand physical micro topology and rough terrain, because you won't ever be able to test it, to feel it, to get a visual and performance feedback so that you improve your design accordingly. Not the best example though as it's too much different, yeah. I do agree that restrictions and constraints should not be considered as a must, in game. But it's still relevant sometimes, to elevate the gameplay. Regarding LS, I feel that having a metric, an assessment of what is or is not a sustainable crewed module, RolePlay will be the only way to care about it, and it won't be enough for some / most players. I do go the RolePlay route when it comes to LS : I don't use mod, I just adjust the whole living space and some drymass according to the mission duration and the crew required. But I would prefer to get some way to assess that it's OK-ish / not enough / plenty enough with a common base that would be told by the game. The effective impact of this is still to be determined : bonuses ? maluses ? hard punishment / impossibility to run the mission ? I'm not into a micro gestion, I don't even care about Kerbals Roles such as pilot, engineer, scientist. I just would like some very general and overviewed handle of Life Support to add some relief to crewed mission. There is clearly no separation today between crewed or probed mission, nothing that set them apart, except for mass which is way under-evaluated when it comes to crew. Maybe some very general "gauges", maybe even 2 only would be enough : Crew resources and Crew sanity (excuse my english, might not be the good word) : - Crew resources : just another "tank" that contains the whole 02, C02 recycling, food, water, etc etc etc. In one single box, one single box, that is consumed based on crew number and mission duration. You start with 500, and it decreased by 1 for each day, each member, that's it. - Crew sanity : a second gauge that would represent the pysche of the whole crew, that might depends on plural interesting factors the real main one would be the living space. Totally fine to only get a capsule for 3 guys to reach orbit and dock, 2 days, etc. Not fine when it's for a 2 years duration to Duna. That would be a gauge that "consume" space or something like this, it's full at start and decrease by 1 for each day, each member. Not perfect though, less logic than the previous one but you can get it as a gauge that is actually green from 100 to 5% and at the end it shows that you might have planned for more space. It would be nice that this sanity can be reset my simply landing and EVA on a surface, or just at 50% max except if you can enter in a ground basis that has the whole living space to reset for another 2 years Of course it would need some way to pre-calculate the required amount in the VAB/SPH ! And then the player would set it accordingly, give it a little margin to be safe OR not respect it and get... well, this is the part to be discussed : maluses ? nothing ?

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.