Kavaeric

Photon drive real?! Congrats!

Updated to version 1.0.2: Added Japanese [ja] translation, courtesy of Mei Konishi.

Like all of these engines, it's an entirely fictional design. As for the tank, assuming you're talking about one of the screenshots in the OP, I think it's one of the multipurpose fuel tanks from Near Future Exploration?

Congratulations on the release!

Hope you are enjoying them! As for the balance, I imagine that those are for the "hydrolox super-lifters"—namely the Kunlun and the Aso. They're intentionally super-powerful but also incredibly expensive and cost-ineffective. If you are playing on career with CTT they take a lot to get to (near the end of the rocketry tech branch) and are on tech par with some pretty nutty nuclear engines at that point. I may look to adjusting their balance in future but right now I think the fact they're just so hard to reach in career makes them okay right now.

I've not tested it personally, but from what I understand it's what actually gives the resource definitions, not to mention a lot of the other dependencies that this mod shares with the original CryoEngines. Gameplay-wise the original will also feel more well rounded.

Updated to version 1.0.1: Added French [fr-fr] translation, courtesy of Delta Varan. Somehow adding a translation has reduced the filesize by ~3MiB?

English - 中文 - 日本語 - Español - Française - Português - Pусский CryoEngines Extensions is a parts pack mod that adds 11 new Restock- and Near Future-alike methalox and hydrolox engines. Designed to integrate with Nertea’s popular CryoEngines mod, it aims to extend the range of vessel and mission design possibilities. Download (v1.0.2) Download from CKAN (recommended install method). Alternatively, manual download available via SpaceDock. Please ensure you understand all required dependencies and compatibilities prior to installation. My ability to help with bad or incorrect installs is limited. Restockalike Paradise 11 fictional engines lovingly crafted, textured, and balanced to match the look and feel of Restock and Near Future parts while injecting fresh new visual flavour. Multiple size mounts and brand-new “end-cap” sustainer engine mounts are the cherry on top. Methalox Roundup Design a mission from start to finish using methalox as the sole fuel source. New methane-powered sustainer engines balance atmospheric and vacuum performance for your upper stages, while low-profile and cost-effective orbital engines bring methane power to your vacuum landers. Vacuum Fiends The tiny 0.625m-size Yiqi and Hestia vacuum engines bring new cryogenic opportunities to even your smallest craft, while the Shikra and Owl find themselves in a niche previously occupied only by the likes of the Terrier and Poodle. Cryogenic Super-Lifters They’re expensive, run hot, and are barely controllable—but those who can tame these potent hydrolox lifters will find themselves in the company unmatched liquid bipropellant might. Screenshot gallery on Imgur Part spec sheet album on Imgur Language Support CryoEngines Extension includes localisation support with the following languages available: English [en-us] — by Kavaeric 汉语（简）[zh-cn] — by Harker Perin, Kavaeric, Keinga 日本語 [ja] — by Kavaeric, Mei Konishi Español [es-es] — by @Nike1155 Française [fr-fr] — by Delta Varan Português [pt-br] — by @Kari Pусский [ru] — by @Zarbon44 If you think you can help with localisation, feel free to reach out to me in PMs. Some parts names, descriptions, or labels may require additional context to translate properly. Support & Thanks Special thanks to the modding community for helping me through my first modding journey, with a shoutout to @triple cheeseburger for testing, ongoing advice, and supplying some of the wonderful screenshots above—check out her Supplementary Electric Engines mod while you’re at it. Making models, texturing, testing, and balancing takes a lot of time and effort. Send a token of appreciation my way via Ko-Fi if you like what I do! FAQ Will you add a new part or variant that I want? There’s always a possibility I will want to adjust or expand more on this mod, but don’t hold your breath. As of right now I consider this mod feature complete. Does this mod support [X] mod that I have? Will you write a patch for it? Chances are it’s out of the scope of what I want to do with this as a straightforward parts mod that otherwise doesn’t include any new gameplay mechanics. You’ll probably have better luck talking to the owners of that mod instead. I make recreations of real-life spacecraft, is this mod right for me? Although I took visual inspiration from photo references, none of these engines are meant to be analogues, faithful or stylised, of any real-life counterparts. They are fictional creations from yours truly. I don’t like the look/balance/plumes of some of these parts! Not downloading or using this mod is free! Licensing Code and configuration files are distributed under the MIT license. Art assets, including models and textures, are distributed under an All Rights Reserved license. Any bundled mods are distributed under their own licenses. Kristina Ness, art director of Kerbal Space Program 2, has seen my fursona.

Looking good, that's a lot of bugs taken on. I assume that "short-term" means the idea of autostrut is now being reconsidered, or is another solution being pursued? Looking forward to the 22nd!

Struts do exist in real life though! The Delta IV Heavy and Ariane rockets have them, as examples: They're obviously not covered head to toe in trusses, but I'm in agreement with the dev team that there should still be a time and place for struts.

Cross posting this from the IG Discord re: people appreciating Chris/Nertea and his cool dev logs

Congrats on your first release! It was great watching you from worrying about how to texture to banging out two of these in a day

Could be as straightforward as burying an "enable developer mode" option somewhere in the settings or config file of SpaceWarp that evokes a text warning on what it entails; enabling it would allow for loading unbundled assets from a development folder a la KSP1 GameData. Having it require a restart wouldn't be out of the question—I imagine most modders, like with KSP1, will likely have a secondary "workshop" or "test" instance of KSP2 that's separate from their main game to test compatibility and to improve load times. Slapping a watermark in the corner of the screen reading "SpaceWarp developer mode" would mean it'd be very easy to tell anyone who might have it on when they shouldn't (i.e. when seeking support). I imagine there may be other developer features in future that may be opt-in like a dropbox asset feature. re: competing standards and official modding support: I imagine the big reason is that any modding tools and API that IG publishes will be backed with some kind of promise (implied or explicit) that both the modding API will not be altered and that the game is in a somewhat stable situation where randos on the internet like myself can start smashing meshes together and putting them in the game. This isn't to disparage any of the efforts of any of you—it's just a confidence thing, and for a lot of folks I imagine nothing short than the rubber stamp of the game's own developers is sufficient to ease anxiety that efforts put in now will not be wasted in the foreseeable future. Perhaps this can be mitigated if the community modding tools for KSP2 being developed right now were endorsed in some way by the devs, but I imagine they have other more pressing matters to tend to right now.

I did poke a few of them and they kept directing back to the open letter as the answer to "why aren't you modding for KSP2". Suffice to say I think it might be worth going back to it and reading it with a fine tooth comb. If you're asking about how to design the tools it might be better to ask questions like, "what do you like about KSP1 modding?" "what do you wish could be better?" to inform the direction you take your tools. I'm a UX design student so of course I'm going to advocate for user testing and research and feedback; I worry that a lot of the decisions being made for KSP2 modding tools are made off assumptions of what KSP1 modders want.

Hi, so, I figured I'd lend in my two cents on the matter. For background I'm a new modder to KSP1, and I've been learning a LOT about part modding by studying both Nertea's legacy work (and trying to match his style) as well as from prolific folks like Poodmund, Beale, Zorg, etc. I've not formally published any of it yet, but here's the lineup of engines for my first mod, CryoEngines Extensions: I'll also take the time to point out my background, which is to say that I am a modder of an artist background, not of a programming background. This, I think, will be important for this discussion. I only learned how to mod about a month ago. At the time, like now, I harbour no ill will towards the developers (and I banter with them even on the official IG server) nor towards any of the active player KSP2 community, despite (or perhaps because of) its admittedly smaller size. Despite this and the eagerness of folks like ShadowDev and Munix, and even contributing to some UI specs for various KSP2 mods, I ended up deciding to commit my efforts to learning KSP1 modding first instead. The word "commit" is important, I feel, because learning how to make an engine is a large undertaking and a big timesink, and I do not want my efforts to go to waste. At the risk of repeating previous points, the reasons I decided to commit to KSP1 modding are as follows: As an artist, the development pipeline feels much less intrusive for KSP1. Reading this thread and elsewhere I understand what folks like Lux and ShadowDev say regarding the benefits of packaging assets into bundles, for the sake of performance and load times for players—but if I'm honest, during the actual asset development cycle load times of the game are not actually the biggest time sink. Rather, when I'm making my assets I much prefer having to jump through as hoops as possible when I make changes to textures, models, or config settings. As an example, a common occurrence is for me to load a WIP engine into the game and finding out the visual appearance of some of the textures feels off. Since I work in KSP1, though, all I need to do is scribble the edit of the texture in Photoshop, re-export as the DDS, and then slap that into the GameData folder and launch the game again. Again I understand folks' criticisms of the inefficiency of the GameData folder, but what it represents to non-technical modders like myself is a very familiar and intuitive workflow that feels very automatic: just drag and drop the new texture, model, or config into the folder and see if it works. There's also the assurance of how it's all exposed to me and very understandable: I know for a fact that if I don't touch the config file in GameData, none of the stats will change because I've thrown in a new texture. Having to first bundle and package a mod using what is ultimately a black box to me adds a fair amount of friction and is much less reassuring, especially if something goes wrong with the new asset. If you want to get a better sense of the preferences of artist/asset modders like myself, consider how tools like taniwah's Blender exporter are the real game changer, meaning many of us can cut out Unity entirely out of our pipeline: things go straight from the art program we use to model our assets directly into the game with no middleman. The fewer steps between the program I use to make my assets and seeing them in-game, the better. An attempt at an analogy: imagine if every time you wanted to compile your code you wrote in VSCode you had to, for whatever reason, open it in Adobe Dreamweaver first and then export it from there. Sure, it's just "one step", and you're not making a whole thing in DW, but I think you can imagine why it would be so off-putting for asset artists who have a similar relationship with Unity, hence why the new asset creation paradigm in KSP1 is to not use Unity at all. Perhaps an in-between solution is to have a "dropbox" modding folder akin to GameData specifically for asset modders to quickly drop in new edits when developing. An upgrade over the KSP1 system could possibly be an in-game asset editor that allowed me to just import edited textures and new models on the fly, similar to Cities Skylines' editor, cutting out the need to reload the game repeatedly and allowing me to directly view what the asset will look like with the in-game render engine on the fly. In that regard, I don't think anyone would be opposed to being asked to still bundle their mods for publication at the end of development. I am turned off by the competing standards of the modding tools of KSP2. A lot of this can be chalked up to the fact that KSP2 is still early in development and so many of the standards or solutions haven't yet crystallised. Nonetheless, if you are asking us what is stopping us from picking up modding now, this is still worth emphasising. I'll go one step further and actually disagree with what ShadowDev said: I don't want to have to choose between three different methods of accomplishing the same thing, because that means I'm making a commitment to that method/tool. As a beginner I inherently do not have the knowledge or background to confidently choose which avenue would work best for me. Having multiple competing standards itself too becomes a barrier to community as well. Much of the modding effort in KSP1 is still very collaborative, and often spontaneously so: in the last week, Atomic, LinuxGuruGamer, and a few others patched themselves together into a team of like four people to work on a new mod in the span of a few hours and have already produced some concepts and assets. This is only possible because for a given type of asset there is a single unified approach to making it in KSP1, and so everyone merely needs to find which part of the assembly line they need to drop in. It's not the best pipeline, of course, but the fact that it is a single standard and that I can approach anyone and know they can slot into a project gives me a lot of confidence both when making mods and requesting help as a beginner. With many of the biggest mods in KSP1 being highly collaborative efforts (even one-man army Nertea didn't work alone), the fact that KSP2 modding still has not honed in on a singular standard of how to make a basic part config makes me hesitate. I don't actually know what I'd want to, or should, mod for KSP2. This one I don't think has been mentioned but I think it's what a lot of people feel wrt to the fact that KSP2 is still very early in development. I don't actually do modding for its own sake; I got into modding because I identified a gap in the game that I think should be addressed. I'd argue many of the biggest projects in KSP1 stemmed from this motivation of identifying a gap and then building a mod to address it: Nertea's entire suite is about extending the stockalike experience; ReStock was about refurbishing and standardising the appearance of the stock parts; Beale's new WaterDrinker was made following dissatisfaction with the aging Firespitter framework; my own WIP mod was itself spurred from a desire for more Nertea-like parts. With the current development state of KSP2 being so early, the approach of "identify gap, make mod to address gap" doesn't work because there aren't gaps so much as enormous voids where work hasn't even started. This is not to disparage the efforts of the KSP2 dev team and I have confidence they will follow through on the roadmap, but the reality is is that getting us to mod a game so early in development is akin to asking an interior designer to have a go at re-arranging the dining room furniture for a house that has barely completed building its foundations. Plus, with the competing standards and ambiguity of the exact features of the roadmap going forward, there is an inherit gamble in spending effort in something that may be folded into the core experience or otherwise rendered irrelevant. None of us want to accidentally recreate a RemoteTech-CommNet or KIS-Stock Inventory situation; the thought of a lot of monumental (unpaid and often thankless) work going into modding a game only for it to be rendered mostly null in six months does not motivate. I think many of us are indeed just waiting to see a clearer picture of what "stock" KSP2 will look like in order to inform the direction of our modding. I know that's a lot of text and I appreciate y'alls effort in starting early and getting the modding framework for KSP2 correct. That said, I'll leave off with how, while I think they could word it better, I ultimately agree with Lisias: I feel as though much of the effort and design of modding tools for KSP2 have been engineered by and for programmers and coders, with little input or consideration for those who do not come from that background—and there are a lot of us of that background. To repeat their point, the tools feel like they are being made solely to make programming and optimisation of the game easier at the expense of asset developers. While I understand that programming foundations need to be laid out first, the truth is if you're asking us why, right now, we don't take an interest in KSP2 modding, it's because none of the tools nor any of the communication suggest to me a concerted or directed effort in improving the pipeline, flow, tools, and communication for asset artists. I am happy to continue to lend help with UX matters, but something like this needs more than just making sure the UI elements are pretty. It will require concerted and active effort to garner feedback and to ensure tools are being designed around all kinds of modders. (as a disclaimer too: these are all my own thoughts and I do not speak for everyone in the KSP1 modding community, of course)

Hi all, thanks for the feedback. I chatted with @whatsEJstandfor on Discord and while this is jumping ahead, some thoughts on how to integrate strut placement into the static/rigid joints model. We also briefly mentioned other games to take precedent from: PolyBridge is the most famous contemporary example, but folks might remember playing West Point Bridge Designer or Pontifex. It was what suggested to me that much of the performance overhead of larger vehicles in KSP(2) is from the spring joint simulation, and that moving to a more static physics implementation would accomplish much the same thing while being much more performant.

I went and wrote a whole analysis in its own thread about my own personal thoughts on the problem of wobbly rockets, as well as a possible solution. Might echo some of @Lisias's suggestions for bending rigidbodies.

Folks on the Discord said I should type up my thoughts on wobbly joints, so here they are. As a disclaimer I'm merely a design student and not a game developer. I'm especially not a programmer so some of my assumptions about performance may be wildly wrong. I have at least been playing Kerbal Space Program on and off since at least v0.11 or so, so I'd like to say I have a fair amount of experience and remember much of the time before autostrut and mods like KJR. Getting everyone on the same page Before I dive in I want to make sure everyone reading this (dev or player or otherwise) understands the distinction between "wobbly rockets" and "destructible joints", because I think it's a major reason why, when I read conversations on Discord or elsewhere, the debate on wobbly rockets goes around in circles endlessly. For the purposes of this: "Wobbly rockets" refers to how part joints are simulated as springs, i.e. the nature of how joints have a lot of give and elasticity, giving rise to non-structurally sound rockets that bend like a wet noodle. "Wobbly rockets" does not cover the actual strength of joints or the fact that they are breakable. You can have a game with structural failure at part joints without the elastic spring simulation. Or, to summarise ahead, my suggestion is for KSP2 to move away from having flexible joint simulation while still retaining the characteristics and spirit of having wobbly rockets. I'll also take the time to point out that the devs have acknowledged and have committed to improving the joint system such that certain joints are much stiffer, namely how parts inline parts stacked serially should have "little to no flexing", among other things: For whatever reason, a large number of people I've seen discussing this topic believe that the devs aren't interested in changing the joint system as it stands now in EA KSP2/KSP1, and operating off of this misconception. I don't think it's productive and I'm not really interested in discussing this with folks who need to put words in people's mouths to get their point across. I'll also point out any criticisms I have that are shared by the KSP2 dev team. The case against wobbly rockets I'll try my best to avoid stating the obvious while acknowledging issues that others have pointed out in the past. Nonetheless, I've tried to best condense my own reasons why I think wobbly rockets (as in, flexible, elastic joints, not breakable joints; see above if you need a reminder) are detrimental to KSP's gameplay visions as they stand now (again, acknowledging that the final iteration in KSP2 is not going to be how it is right now), based on my experiences of KSP1: Flexible joints are frustrating particularly for new or inexperienced players, as it is an unintuitive and difficult-to-mitigate barrier to launching early rockets. In my time helping new players on various servers and communities, one of the biggest sources of difficulty for getting into orbit for the first time is wobbly rockets, and not in the ways more experienced players playing modded or tweaked versions of the game might expect. I've seen it happen many times where a new player in a Discord call has designed a rocket that seems perfectly capable of flying straight and stable, but the small deflections caused by springy joints can lead to a cascading instability. The most common example in my experience helping new players is when micro-oscillations suddenly compound into an unrecoverable situation: It's a big source of frustration because it's almost impossible to really account for until it's too late: the fluctuations are so small that new players can easily miss them, and once they become obvious it's often too late. Newer players early in Science or Career mode often also have only a limited selection of parts to help control and stabilise. Additionally, inputs via keyboard or even through overcompensating SAS can make the oscillations worse. It becomes a unintuitive source of failure and frustration for new players. Simulated joints runs counter to a game about presenting design and engineering concepts in an accessible ways. One of the odd things about structural stability is how much on "vibes" it goes off of in KSP1: the game will calculate things like TWR in or out of atmosphere or how much dV each stage your rocket has depending on payload and fuel/engine properties, and countless details about mass, fuel consumption, and even impact strength are exposed in the VAB. My assumption was that this was meant to ensure that any failures the players experienced were due to mistakes on their fault and not because the game obscured information it had. Hence, it's always been strange how it was difficult to answer questions like "how heavy can my radial boosters be before these radial decouplers give out and I need to consider adding reinforcing struts?" I realise it's probably not possible now given how joint stresses are simulated on the fly and not an inherit property of each part—nonetheless, maximum loading capacity for critical attachment points like radial decouplers not being listed feels like a very strange departure from what a player is led to expect from in-game parts documentation. Spring joint simulations are very taxing on hardware and is difficult to program. This one I admit is more guesswork based on limited experience of how games are programmed, but from my understanding simulating a lot of joints as flexible soft-body springs is very expensive, at least as described by the devs themselves. From what I know it also often lends itself to cascading problems: some users have reported how the small gap created in between two parts that are bent from each other causes increased drag, compounding situations like the one mentioned previously. I can also imagine it leads to a lot of headaches regarding collision boxes and krakens. To reiterate, I understand that KSP2 devs share many of these concerns and that they are aiming to change this joint model for KSP2; this is merely my attempt at zeroing on the specific problems of the current model. The case...for wobbly rockets? I think it's also worth pointing out to ourselves that there are certain gameplay opportunities to wobbly rockets that we need to keep in mind, even if they are compromised in the current state of KSP1/2. I want to take a nuanced approach to these though and try to drill down what these benefits are, though, since it will inform how a new solution can be designed for KSP2. Wobbly rockets provide feedback to the player as to the viability of their craft design. In addition to watching many new players fumble with the micro-oscillation problem, I've also noticed a lot of players who discovered the importance of structural stability for large craft through the flexible joints. There have been times when I've watched a new player strap two SRBs to their core stage with a single decoupler each and watching them bow inwards due to the amount of thrust they are dealing with. Aside from them finding it funny (which we'll get to in a bit), it does also provide visible (if exaggerated) feedback to their design: you need a heftier joint or more reinforcement. This does get diminished by how the joints can feel so elastic that they seem unbreakable, because it suggests your rocket is made out of indestructible bundles of rubber bands, which may undermine attempts to suggest limitations in the structural strength of joints. Nonetheless, I believe that any new solution should at least retain (and improve) how this system is valuable in the form of feedback. It's fun and funny. This point might be more contentious, but I think in hyperfixating on this specific point from June 16th's upnate the community (and maybe even the devs) failed to find the nuance in the statement. See my above distinction between having wobbly rockets vs having destructible joints: here, I don't think that wobbly rockets and flexible joints themselves are necessarily part of KSP DNA, but rather the experience of trial, error, and comedic mishap. Having played this game for very long and seeing players of different intents and backgrounds play, I don't think I recall much in the way of people finding fun in how rockets act like slinkies, but more with watching their designs fail is spectacular or unexpected ways, with boosters spinning rapidly or what not. I think this sense of finding joy in the sandbox of failure can be preserved without necessarily having flexible joints! Armchair game designer Kavaeric hypothesises a solution This is the point where I go into armchair video game designer mode and try to come up with a concept that satisfies the points, which summarised are: The new solution should be intuitive to understand and not cause unexpected or unforeseeable vehicle failures for new players. The new solution should work with the game's intent of giving players as much (or as little) information as they desire when constructing their rockets. The new solution should be performant and scale well with many parts. The new solution should provide avenues for the player to discover design flaws in their designs, both for players who prefer to scrutinise their craft in the VAB/SPH and for players who like to experiment and watch what happens in flight. The new solution should not run counter to the game's spiritual and aesthetic/comedic tones of failure and mishap on the road to success. Interestingly, my source of inspiration for a possible design solution is from the KSP Early Access cinematic launch trailer. Specifically, this moment where the SRBs of the first rocket come off: Despite the trailer not depicting any of the craft bending like a funfair inflatable guy, I think the vibe of the trailer still feels very kerbal in terms of the ways the craft fail structurally, don't you think? Animation also gives some pointers. I'm a fan of the film The Wind Rises (2013), which has a few moments where aircraft shake themselves apart from the stress. Miyazaki exaggerates the stress, bending, and motion of the aircraft, which could be a source of inspiration on how to depict structural failure of a craft in KSP2. Additionally, my modded KSP1 game includes Ship Effects Continued, which adds to the soundscape of the game by introducing rattling and vibration sound effects when a craft is experiencing significant structural forces, such as during launch or re-entry. I think collecting all these as inspiration, I can start to visualise an updated system for joints for KSP2: Joints are rigid. They do not flex and they are not simulated as flexible parts. Each joint on a part has a value that represents the maximum stress it can take. Generally, smaller parts have lower thresholds, as do radially-attached parts. Attaching a part without using an attachment node (usually the top/bottom node but also the other directions if using a hub connector part) incurs a strength penalty. A joint breaks when the lower stress number of the two parts is exceeded. If a joint is close to breaking, an animation is interpolated in along with sound effects that signal to the player that something is wrong, similar to how the radial decoupler in the trailer rattles violently before detaching. Struts are special parts that boost joint strength to parts they are attached to, increasing the floor of breakage. The system can still allow for autostrut for advanced players who still desire it (e.g., if building vehicles that have parts stacked and clipped into each other for aesthetic purposes) while not making it necessary for players who do not play in such ways. This new system should provide the following benefits: Joint stress does not result in microdeflections or deforming that can cascade into bigger problems, lessening the learning curve for new players by avoiding situations where their rocket breaks apart for no reason. Joint stress is now a very easily quantifiable concept as it is a single part stat that can be exposed to the more engineering-oriented player rather than something that needs to be simulated in the game. Players who are less technically-minded or experienced and rely more on trial and error receive clearer and better feedback in flight on weak structural joints of their rocket, and can better identify and correct them. Audio feedback now adds a new dimension of atmosphere and feedback for players, especially if the the player is in a situation where they don't have a clear view of their entire craft (e.g., in IVA). Rockets will still break up and explode if it is poorly designed or if its structural considerations were under-specced. The system should work both for players who prefer the core Kerbal tone of exaggerated comedic mishaps (we can still watch Fleas fly around like fireworks), while being tweakable enough for modded players to depict these kinds of failures more conservatively. Joint simulation has been simplified making it less expensive to simulate and overall improving performance of the game especially for extremely large craft. Watching a rocket shake itself apart will probably be its own special form of joy. As a bonus, for advanced players, when compared to spring yjoints the proposed static joint system should be simple enough (at least for my amateur non-programmer brain) where new analysis tools in the VAB can be added. This will not only add depth to the game for those looking to endlessly tweak their designs, but also can expand the potential of Kerbal Space Program as a STEM educational game by providing an approximation of static linear truss analysis, a concept very common across all areas of mechanical and aerospace engineering. Below is a simple sketch of how this approximated system can be presented to the player: It is also possible with this model to apply a simplified model of stress/strain, where increased stress does not directly break parts but slowly fills a "strain" stat. More stress fills the stat faster, and when the stat reaches a maximum threshold the joint breaks. Increased strain could then be tied to a random deflection transform to represent the deformation of the joint. In conclusion I think shifting to this static joints system in lieu of the spring joint system currently implemented in both games will be an improvement in terms of a gameplay, aesthetic, and programming/performance overhead perspective. While again I'll give the disclaimer that I am not a game designer nor do I have any specific training, I think that at the very least peeling back the layers on why a feature feels needed or otherwise can lend itself to insight on new avenues for gameplay design solutions. clickbait title: top 5 reasons how wobbly rockets torched my crops and poisoned my water (you will not believe #2)

Ghostii has captured me and is holding me hostage in the basement of the IG studio (otherwise known as the CM offiINFORMATION REDACTED. EVERYTHING IS GOING FINE AND KAVAERIC IS IN GOOD HEALTH. Looking forward to the devlog about heating. Will it be just on the mechanics/system or will there be chitchat about re-entry visual effects too? Folks are wondering about a hotfix as well, and I'm curious about that front too; what challenges would Darrin the team have to overcome? Does the Bug Hunter role and new reporting system improve matters on this front?

Congrats on the release! It's only been like 40 minutes or so but initial reports from the server look like 20-50% framerate uplift across the board depending on your setup, with noticeable gains for those on midrange hardware.

Hm, wouldn't this just be a matter of playing sandbox, then? Unless I'm missing something. It does give me a thought on how perhaps rather than choosing between pre-defined "modes" (sandbox, science, career in KSP1) it instead is presented as which buildings you want active in the KSC when you start a new save as stand-in for which gameplay features you want to enable. Could do something wacky like a playthrough with the entire tech tree unlocked already but still limited on budget.

What the... GHOSTII

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.