Jump to content


  • Posts

  • Joined

  • Last visited


249 Excellent


Contact Methods

Profile Information

  • About me

Recent Profile Visitors

2,152 profile views
  1. Updated to version 1.0.2: Added Japanese [ja] translation, courtesy of Mei Konishi.
  2. 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?
  3. 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.
  4. 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.
  5. 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?
  6. 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.
  7. 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!
  8. 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.
  9. Cross posting this from the IG Discord re: people appreciating Chris/Nertea and his cool dev logs
  10. 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
  11. 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.
  12. 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.
  13. 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)
  • Create New...