thewhitemetroid

Both great ideas for indicators, and sounds like something that would actually add some fantastic immersion and tension to the launch. I would add that we could also add vibration to the navball possibly as an early indicator since excessive vibrations will likely accompany failure events.

I agree it would be unrealistic to expect a video game to perfectly mimic real life but that doesn't mean it shouldn't try in a simulation game. I feel the failure indicator should be "rocket exploded" because that is the real life implication of bad rocket design or an unknown flaw. And at that point you likely didn't lose much since most of these instances are going to be in atmosphere. We can always do the realistic thing and "revert to VAB". The unfortunate thing at the moment is that it's easy for us to blame it on a kraken attack instead of suboptimal rocket design. If I as a learning user can get a noodly rocket into orbit then there is lost potential to motivate me to seriously reconsider my design. Besides, noodly rockets just suck.

The Idea of "Joint rigidity" is silly to me because this is not how it works in real life. the weld seams are stronger than the base metal. If a failure occurs it will happen near the weld or at some other location. So having joint flex occurring where a small and medium sized tank join should not be a thing in this game at all. I get why the devs made "tanks" the way they did in KSP 1, but at this stage they should all be procedural, because as Kerbart stated, this is not how a vessel is constructed. Carbon steel, Stainless, Alloy sheets come in standard sizes with an upper and lower limit, and the number of weld seams are determined by the engineering needs of the project and the size of the sheets, not the size of the "gas tank". I understand pressure vessel design and the design for rockets will use similar considerations, but not entirely since wind shear, drag, and many other considerations must be made. But a cylinder is a cylinder. Speaking of which, I agree with most here, noodley rockets are not realistic. If a real steel cylinder was subjected to the same flex seen in KSP 2 the compressed side would just crumple and subsequently the rocket would start to break apart. As far as what would happen when a rocket is sideways in atmosphere I can't say because I have no experience there but clearly some have managed it, others have not. Lastly, I have never had fun with a "spinning rocket".

It's been a while since I played KSP 1 so I don't remember exactly how it worked and I'm almost tempted to go spool it up to refresh my memory. So far as I can tell there is not sufficient tools in KSP 2 to reproduce that. I do see a tool in the translation mode to change the gizmos location to relative and absolute, but this is not very a useful tool at the moment as it seems it's limited to the node of origin. There is also semblance of a snapping grid in place but again it is not the most useful implementation. The grid does not seem to be absolute, but relative to the individual parts insertion origin into the model space. This is a problem because the user could place a part in infinitely different 3D coordinates. A way to realign the parts to an absolute grid could help with this problem, but I would at this point be concerned about the implications of grabbing a mostly assembled vehicle of even moderate part count, and then tripping the flag to snap the part(s) to the grid and borking the entire assembly. Given the broader scope of this game (assuming of course it will achieve this), a more elegant and efficient way of designing is needed to facilitate building large interstellar vehicles, colonies, etc...IMHO.

Being a pressure vessel designer and having design experience in other disciplines as well, I have a strong appreciation for the inclusion of an orthographic workspace. However after using it I found its implementation left a lot to be desired. Before I layout some observations and suggestions I would like to provide a primer: It's possible that you guys have some kind of tolerance value built into the game that would allow for minor misalignments in vehicle design verses the physics calculations so whatever variance I see in the design of my vehicles may be accounted for by your code. Or maybe you don't have a tolerance, either way there is a problem presented for each. If tolerance is built in the code the user has no way to know what that tolerance is so they can not know how far to bend the rules before it breaks. If on the other hand no tolerance is allowed, then it becomes important to be given some simple proper tools to be precise in the vehicle design. When all the node snaps work perfectly this is not an issue, but all the node snaps don't work perfectly and I suspect that there will always be some issues like for example, when using trusses. The node snaps are very fiddly when trying to build with these parts. I believe that using the ortho environment in an expanded way can alleviate, and even eliminate these issues. I know, I know, KSP 1 has been out for a thousand years and we have deployed our rockets just fine but you put this environment in there so you've forced my hand . Besides all this, I'm a technical designer, I live and die in the world of precision and if I don't know a part is perfectly aligned it drives me nuts! On to the discussion: 1). When in the orthographic environment, part translation and rotation should be locked to the current plane of view. This in my opinion HAS to be implemented or else this environment is wasted. I know you have designers and engineers who know just fine what I am saying, but I just want to be clear that we understand each other so I'm going to qualify what I mean by "plane of view". Let's assume that in the coordinate system Z is up, pointing to the sky, and the XY plane is parallel to the VAB floor. If I were to be looking at the "top" view, then the XY plane becomes my current "plane of view". If then in the top view, part translations and rotations need to be locked in the current plane of view, the XY plane, until the user switches to another ortho view (at which point the parts can be moved within this new plane of view) or when the user returns to the normal perspective environment translation and rotation returns to unlocked. Currently this is not the case. This will only causes frustration for the user because they have no control over the translation and rotation of the part in the plane perpendicular to their view. 2). Provide object running snaps. This is another suggestion I believe has to be implemented for this environment to be useful. Again, your designers and engineers probably know what I mean when I say object running snap and I'm not going to try to explain it in a technical sense, but I think explaining it only in how I think it should be implemented will suffice. the problem that I encounter is that I have no way to reliably line up parts in a way that is repeatable and easy. If you look at the image below I have two fuel tanks connected by a truss(unseen). You'll notice they are not aligned perfectly and unfortunately will stay that way because when placing a part in space the coordinate value is continuously variable. So when I try to use the move gizmo to fine tune (even when pressing SHIFT), the increments are not lined up so the part will always be a little too low or too high. A solution to this could be a snap grid but I'm not fond of that solution. Instead, it would be incredible if each part had an invisible plane associated with the extents of the part such as the top, bottom, sides if flat, as well as planes about the centerlines and object midpoints. Let's say the part on the right has a plane associated with the top extent of the part that is perpendicular to the view. this plane remains invisible until it becomes coplaner with top plane of the part on the left, at which point an indicator appears such as a dotted line showing the alignment. This is an object running snap in it's simplest form. This solution won't cover every possible outcome (I don't expect it to be as sophisticated as a proper CADD program of course) but it will cover the vast majority and provide players an extreme level of confidence and satisfaction when making complex designs. If this were to be implemented along with a snap grid I think it would cover more than enough possibilities. Both should be implemented with a toggle though. Another view to illustrate the problems with alignments. 3). Provide node grabbing in ortho environment. Although not critical like the two examples above, I believe this would be an extra step in the right direction to provide the user with a powerful tool in their design. ONLY while in the ortho view, it would be quite powerful and a sweet Qol feature to be able to selectively grab the nodes instead of just the root of the part. This environment evokes a sense of precision so changing the way the player interacts with the part in a meaningful way will go a long way in improving the experience while also streamlining the build time. Can't tell you how many times I've fiddled with moving a part around the screen juuuuuuust right to get the node I want to snap to. This coupled with #1 would be powerful. 4). Allow user to place move/rotate gizmo. Another non critical but would be a powerful addition. Again, ONLY available in the ortho environment, allow the user to grab the move gizmo at its local zero and snap it (important part is snap, I don't think it wise to allow free coordinate movement of this gizmo) to other nodes or root of the part. If you look at the gizmo in the image above it is stuck on the side of the part. This is pretty useless in my opinion. I would like to be able to rotate this part in the current view about the centerline of the tank by 45° so that the two paint strips on the side of the vessel are in a more ascetically pleasing position. There's now way I'm going to attempt that in the current configuration. The utility of this cannot be understated. 5). Remove environment lighting. Obviously not critical, but would be a better design choice. Point one: this is an ortho view therefore the image is "flat". It does not follow that environment lighting should be seen in a flattened image because real light exist in 3D space (unless you're a flat earther !) point two: personal opinion here but when I get in this space I imagine I'm "going back to the drawing board", something isn't right I need to get out of the shop and sit down in front of the drawing to fine tune this thing in the office. Might be just me but that's what I imagine I'm doing so the environmental light (aka VAB lighting) throws me off. I think this was a great idea and addition to the game but it needs some tools for it to be worthwhile. Otherwise all it's really good for is making sure my boosters line up with my decouplers and such. Lots of potential in this. Hope this was helpful and if you guys already had these ideas in mind but haven't implemented them yet then I say good job. Looking forward to KSP2's final form!

Noted

Try F2 when in flight mode. @RockyTVall of your arguments strongly suggest IG is self sabotaging and that they secretly hate us and want us to suffer. That is an absurd idea. As a team they will naturally want to do everything they can to self preserve. The only way to do that is to put out the best product they can while operating within the constraints placed on them.

My biggest complaint with the new UI is the inconsistency. There is a mismatch of styles going on in the screen and most times even within the same widget. For example, the navball has the dot matrix or pixelated effects around the navball itself and then directly surrounding that, the altimeter, velocity, and compass gauges are all smooth type fonts and line work. Then pasted directly on top of those the altimeter and velocity readouts have smooth font numbers with pixelated lettering and outline. This lack of consistency prevails across all the UI elements. This is a poor design choice IMHO. I also flatly do not like the pixelated aspects of the UI. I would prefer the smoother more vivid line fonts that are used elsewhere. Otherwise just having the freedom to move, scale, or even remove elements of the UI will solve any other problems.

Check in the announcements @B15hop

Hoping some brave modder out there will remove the annoying white menu on the screen when viewing the Kerbal space center.

That must have been an incredible sight. One of my bucket list items is to go to a real launch. It'll happen though when I make it happen.

Awesome, welcome Leroy. I'm a mechanical designer (pressure vessels) but man I dream of rocket design. That just sounds soooo juicy and challenging. Also, you will not regret the flip to PC, mods are the game changer.

Thanks for the update. I can handle a date slip, but feeling around in the dark is painful. It's much preferred and easier to manage my own thoughts and expectations when the team is willing to be more open and share what they hope will happen and when. Rooting for you!

Thanks for the morsel here. Eagerly awaiting the future patches and hoping guys are able to achieve what your vision for this game is 'cause I sure as hell want to play it!

HaHa, yeah just look at the Dallas Cowboys.

Ok, well ill just take it as being remove due to the quote because I haven't received any warnings. Thanks.

Would just like some feedback on why one of my responses in the week one adventures topic was taken down. Not mad but I don't understand where I violated the forum rules.

I'd like to add to these suggestions the ability to tag hex/rgb values with the official color name it represents or one of our choosing if not officially represented by a name. It would be infinitely easier to find what you are looking for instead of trying to remember the color number value of the many possible colors a user might want to save.

YOU choose to buy an invitation to an unfinished product which was clearly stated. Cyberpunk was released as finished, Not comparable.

It would be a good exercise right now to drop all preconceived notions about this situation and take a moment to look at this from the dev point of view. Or better yet lets say Nate Simpson's. Pretend that he has absolute control over when and how the patch is released (he doesn't but pretend). His reputation and career (not pretend) are on the chopping block here. If this goes south on him, his professional career could be in serious jeopardy even ruined by this. It is in his best interest to do what is the absolute best thing for this game which absolutely does not include a "Mwuhahahahahaha...I'll show those stupid gamers, I'm gonna promise them the world but give them a steaming pile of....Mwuhahahahahaha"! Now pull the curtain back and apply that across the entire team. Everyone has skin in this game and their reputations are on the line, T2's included. Why do you think they just went through a round of layoffs, underperformance naturally. There is no doubt in my mind having spent my life in the world of large projects in the engineering industry that from the day of EA till today, there has been people in conference rooms DAILY arguing over this very issue trying to figure out what the best options are. At the end of the day it is just a game.

But please add in settings as option to toggle. I agree this will be helpful, but when I don't need it anymore it will become supremely annoying.

I've got some gasoline here, The Witcher 3 is well established. I play it. I love it. The Next gen Edition Broke the game. The patches "helped" some issues, broke others that were fine before...The next patch "helped" some things and yet still...broke more. I don't play it right now because...it broke. Regarding KSP 2 right now, it's hard and lot's to complain about, but we should just be patient and see what the devs come up with in the coming patches. As long as T2 doesn't flush this project down the toilet I believe they will bring this game up to our expectations. Fingers crossed.

Thanks. Good idea to keep a vanilla campaign save for an unmodded instance of the game. Will do.

The argument of value is moot to begin with. Value from the consumers perspective is subjective. I agree with all sides of the argument here because valid points are made, but no single argument can cover the use case for all individuals. As an example. Moons, you argue that dollar per hour of play cannot be used as a metric because of grindy games and how that can't be fun. I disagree. To you it is not fun or worth your time, to me it is. I like grindy games because I get a sense of accomplishment out of the work I put into it to get the results that I was expecting. Some games do it better than others, thats the risk. I like the dollar/hr metric but it isn't the only one. I have played many games that were short in my opinion but gave me such an intense experience that ill remember forever. Some games have a value of nostalgia, there are too many ways an individual can measure value. It depends on what is important to them. What I do think is worth noting however is that for this particular case, I find the $50 too high for the product I received. I understand its EA, blah, blah, blah, but you cannot know what you are getting until you throw the money on the table and hindsight is 20/20. I don't regret it, don't get me wrong. I'm in, I want to see this succeed, I'm absorbing the risk. However, we can now take a global view with critic reviews, user reviews, low player counts, refund stats, and even long time hard-core players having a critical take on it. It hard to argue that the game has lived up to it's "value". It has left a somewhat bad taste in my mouth, but there is still time for redemption. Its too early to throw in towel, they haven't even launched the first patch. By the way, where is that damn thing, need to drop soon. Anyway I'm going to remain hopeful but the situation is not good at this time.

Confidence was waning before but this just cut the bottom out. I'll reserve my anxiety until after the first patch but dare I say that this first patch is now significantly more important. I hope this thing doesn't fall completely through the floor because I have personally experienced "everything is good, we're good, nothing to worry about" meanwhile the next day the doors are locked. Time to put up.