Kavaeric

Very interesting, I appreciate the way we can get insight onto the stages of game dev we don't usually get to see (even if some don't/won't appreciate it...) Now I'm curious about how this decision was determined—from my understanding FAR builds an aerodynamic mesh by calculating for the entire craft as a whole. Was it a performance consideration or a gameplay we-want-it-realish-but-not-simulator design consideration? Curious too as well if there may be a way to still advance the drag cube model from taking inspiration from FAR. From what I understand FAR does a whole-craft aerodynamic model; maybe a system that generates drag maps for the entire vessel as a whole on launch would help reduce aerodynamic/occlusion calculation overhead? It would mean that it'd have to be re-calculated if you e.g., decouple or lose a part, though; unsure if the trade off is worth it aside from maybe planes which are almost always in atmosphere and don't really stage like rockets do. Also as pointed out previously, but I have to as well: guy's work has resulted in an entire genre of modding for KSP1 (NFT + ReStock + KA + SSPX + Cryo + OPM + life support mod/Kerbalism) which basically got him hired on the spot and has the nerve to say (You can brag a little, man!)

No problem! Glad I could be of help. I'd recommend for people to simply save or archive the Notion page; though I do make updates every now and again. (and if you know anything about mesh deformations and animations for the .mu plugin let me know)

Hi @ColdJ, I've been learning to use the .mu exporter for Blender as well. I've been taking notes and things of what I learned and been compiling it into a Notion page: https://kavaeric.notion.site/Notes-on-creating-engines-for-KSP-16f8338f483b473486ca9657674d85e2?pvs=4 Feel free to mirror any of the info. I'm still figuring out a bunch of stuff: right now, how mesh deforms/weight painting works, and later how to do animations. Note that most of it is more comprehensive about modelling and texturing, but hopefully there's still some good/new info in there about the exporter.

The man himself. Thanks for the kind words. I imagine the team is more focused on other more pressing issues, yeah. I'd be happy to actually workshop this (this is totally not a thing for my design portfolio I swear); are there any other resources/insights on some of the considerations the UX team have? I believe I've read the UX dev insight but it largely focused on the VAB I think

Need some help with the exporter, and it has to do with making multi-nozzle engines: As I understand it, to create a multi-nozzle engine you'd ideally want to have a separate thrustTransform on the end of each nozzle. Each of them however needs to be named the same thing, since the EnginesModuleFX module doesn't accept more than one. However, Blender prohibits one from actually naming two objects the same thing. See this example where I imported the Bobcat, a twin-nozzle engine, and Blender auto-renames the second to thrustTransform.001: As I understand it there is also no way to stop Blender from appending the discriminator numbers. Would it be possible then for the exporter to auto-rename any thrustTransform.xxx to thrustTransform on export to .mu? As I understand it Unity does let you actually name two game objetcs the same thing (thrustTransform), hence this is a problem specific to the Blender pipeline. Edit: Never mind, turns out Taniwha (or some other contributor) knew what they were doing and accounted for this. The exporter sorts out multiple thrustTransform empties with sequential numbering to be named the same thing. Am writing a bit of documentation on how to make an engine part using just the Blender plugin, so it was good to know that's possible.

Thanks all. I neglected to post this, but better late than never: version of the above proposal on its own

I concur with the increased bug transparency, if only to sate my own curiosity of how the sausage is made. Having seen the new engine stats here, it would be interesting to get further insight into how the new archetypes of vacuum engine (devlog #17) are balanced and find their niche--I imagine it's more than just deep space engines being even more efficient than their orbital counterparts

i don't even have the game installed what is my life

I've noticed that a number of others in the KSP2 Discord have voiced concern over the confusing nature of the patched conics interface, notably Spicat's suggestion. Given some of my other UI suggestions they invited me to try my hand at improving the clarity of the interface. To get a sense of the problem I decided to show the interface to two friends who have played KSP1 before and were of different skill levels, but otherwise had not seen the new interface. The notes are below, but in summary, it was difficult for them to make out what the various symbols mean, and it took them quite a while to cut through the visual noise and understand the symbols and indicators. The intercept icons and SOI change symbols were significant paint points to comprehension. Below is a sketched concept of what the above looks like along with some simple callouts annotating my design decisions. In short, I feel like the current design is overly focused on the meaning of each symbol in isolation, whereas my proposal attempts to systematise the visual language of patched conics more holistically by: Reducing visual complexity by eliminating the ship SOI change icons, which were visually verbose, and reducing visual noise in general by dimming the background. Colour-coding successive orbits to better distinguish between sequential paths, as well as better communicating their order. Unifying the appearance of the SOI change nodes (in the above, match orange to orange and red to red to understand the motion about the Mun). Using a colour- and shape-matching system for approach markers that intrinsically communicates they should ideally be on top of each other, rather than having the player guess at matching letters and orbits. The proposed design should help improve understanding for new players still coming to terms with orbital motion, while ensuring that advanced players are still offered clarity when performing multi-step, complex manoeuvre plans. clickbait title: real design student's reaction to patched conics UI gone wrong (live reaction)

Some modders in the KSP2 modding Discord were interested by the proposal and I decided to clean up the concept a little to be clearer. It's still mostly fragmentary and incomplete but otherwise more detailed than above. The dev team may find this useful too, though I figure there are more pressing matters in the game than this.

I posted this on the Discord to Dakota, but I figure I'd mirror this here in case for some reason it gets lost in the chaos: Send my regards to Nate. Haven't finished reading but as someone who has had to handle PR fires this takes guts honestly, especially given the track record of being attacked. I couldn't do it. The possible change in policy I think worth commending as well; I hope it's a decision you (collectively) don't feel like you need to rescind. Not that I think you'll disappoint; tbh, while I don't play KSP2 yet, it's not like I've been disappointed at all from what I've heard. Happy weekend! Congrats. Looking forward to playing the update...or, well, watching others play the update, I suppose.

+1 this, but ha, you beat me to it. I was just thinking about this thing and was gonna sketch some stuff too

Thank you! And sorry about the thing on the Discord again, I feel really bad about it lol I think I did find someone who made some engines they want to put into the game but is looking for a texture artist (me?) So maybe Parts By Kavaeric will be a thing soon lol

Hm, it'd be less like "mission reports" I feel and a bit more like artist commentary, since my big imposition in this career mode is to also make things look pretty. See stuff like the following

Thank you all for the kind words! Perhaps I should maintain a thread/gallery thing on here

Don't worry, this is not as methodical as you think.

Hello. Not that new here by any stretch in technicality if you look at my profile, but it is the first time in ages, so I felt it right to re-introduce myself. I've been playing KSP for what feels like forever. Currently going through a new career mode thing. I try to challenge myself to make fresh and unique looking craft that are still functional in the career context, usually involving me sketching out my ideas before committing to their construction. My current project is updating my crew vehicle, though the past version (see below) seems to have gone well. I may make a thread sharing my progress in my career mode but I'm not sure if this is the sort of thing people care for. That aside, I currently hang out on the Intercept Games Discord, namely in the KSP2 general chat for reasons unbeknown to humans, usually offering tribute to the CMs of some kind as seen below. I'm also working on a stage designer calculator tool that hopefully some people may find useful. Its biggest limitation is that it only works in Excel, not Google Sheets, so finding a way (or help) to port it to perhaps be a standalone webapp of some sort or even an in-game tool may be helpful. Hoping to meet new people and follow the development of KSP1 mods and KSP2 as well. Cheers!

Also another x-post at the suggestion of a user on the Discord: Browsing for parts in the catalogue could probably be made much more robust and flexible if a filtering system was implemented. Part categories are nice but it can be difficult to remember whether parachutes were in...landing? Or aerodynamics? The existing improvements in clarity over KSP1 are appreciated, such as the size radius class and subheaders, but with the implication of many more parts included in the game versus KSP1 had in stock as time goes on, as well as modders pitching in new parts, a built-in filter system feels like a sensible addition. It should also alleviate the strain for those who jump into sandbox and feel overwhelmed with the number of parts, an existing problem in KSP1 even without DLC and mods—helping them to hide everything that is or isn't of a certain size class or fuel type (especially if multiple fuel types are to be added in the future beyond the basic LF/O/Xenon) would better help them navigate vehicle design as well as the kinds of choices one makes when putting together a rocket (ISP vs thrust, for example). This would also help curtain some other concerns the dev team might have, such as engine archetypes for newcomers. A side suggestion is also to allow for players to configure filters based on existing parts, such as clicking the Terrier engine to find other liquid fuel engines of its size; or even to have a specific button for certain parts like engines that will direct the user to appropriately-sized fuel tanks of the correct resource.

Originally posted on the Discord but someone suggested I x-post it here, so... KSP2 improves on orienting parts by introducing orthographic views and using cylinders instead of spheres to mark attachment points to better read orientation. However, during my many many years of playing KSP and watching others do the same, I've noticed that a common pain point is figuring out which key to press when rotating a part in place mode. It's easy to observe many players fumbling with WASDQE figuring out which key is the right one to press to get a part in the orientation they want. I feel as though some sort of helper or reference element would help curtain this frustration. I was largely inspired by how Nintendo gives clear information in its UI prompts to help orient their players. As VAB/SPH assembly is oriented to an "absolute" direction, it should be (relatively) straightforward to create some floating elements that orient the user similar to the gizmos used when in move or rotate mode. I feel like the challenge of implementing this would be instead ensuring that the UI element is clear without obstructing the view too much; perhaps the element is toggle-able in settings, or the user has to hold down a key (like alt, which coincides with forcing node snapping) to display the helper.

So I was working on a crew vehicle and I wanted to have more drag and heatshield surface, so I wrote a simple patch to add a similar hull part switch (similar to the Mk2 nosecone etc) that adds an option for a heat-resistant version with ablator. It makes it quite a bit more expensive and heavy but it seeeeems to help with re-entry. Unlocks with the "super" hull upgrades at the Aerospace Composites node, in line with the other upgrades .cfg is below: Admittedly still learning how this forum works and I have no idea how to attach things, but I am also willing to share that custom texture I made for it up there.

I've been using it for some time, and it's wonderful. Assuming you had specially-recorded clips of speech in actually Kerbalnese or whatever it's called, would it be possible to have different voices play during different situations? So like during the launch or landing the chattering becomes slightly more frequent and the voices sound a bit more tense, when nothing is really happening it's casual and calm, and when something explodes you can hear them screaming in uncontrollable panic?

oh well damn

I was thinking of a type of spaceship programme/mod/something where you can launch space faring telescopes and take pictures. Of um. Stuff. Beared with the terrible handwriting? Great. Here's the idea: To build a telescope, all you do is pick an aperture part, body lenses part and an instrument module, piece 'em together like an engine and bam! Your telescope. The components will have different specifications which will contribute differently to the overall performance. Larger telescopes will obviously be more powerful than smaller ones. Stacking a bunch of body parts will increase the telescope's power. More powerful versions of the instrument modules multiply the performance, rather than simply add. The telescope in operation will produce a steady stream of Science that it'll beam down towards Kerbin. The amount of science is based on where you're aiming your telescope at and its size and power. Low power telescopes get more science out of taking photos of planets and moons in the Kerbol system, while higher power telescopes gain more science out of, uh, photographing deep space (aim it at something not a planet or moon in the Kerbol system). Free science! Yay! But hold on, there's a catch. It's a telescope. A space telescope. What do space telescopes have? They have sensitive optical parts. You can't just piece together a massive space camera, pop it on top of a thousand Griffon XX thrusters and blast it off at full power. The inner workings of the telescope are highly vunerable. Exposure to forces barely over those experienced during launch will cause the telescope to be damaged, and its performance and thus science output will drop drastically. Exposure to atmospheric drag to the slightest degree can damage the front aperture outer glass shield. Even if you have it out in space doing nothing, eventually it will succumb to the (very very) slow damage of micrometeoroid impacts. Can you fix it, though? Hell yeah you can. All you need is a brave kerbonaut, a good controllable rocket (as if there are any) and the cash on hand for the cure. Just get Mr. Bob "The Builder" Kerman to perform a happy EVA spacewalk repair mission on the damaged component(s) and, assuming you did it right, the telescope will be working perfectly. Anyway, that's my idea. I dunno if anyone came up with it, but here's my take on the idea of space telescopes in KSP!!

You can try out The Universe Sandbox, though I'm not exactly sure its physics are 100% NASA-seal-of-approval correct. You can buy it on Steam or as a standalone http://universesandbox.com/

Venera, because of the photos it sent back from Venus. As in, the surface. Of Venus. And it's every ounce of fear-quaking acid-raining pressure-crushing fear you've heard condensed into a couple photographs. Ho-ly crap that is terrifying.