dreadicon

All the new stuff looks awesome! But presently, I think I would settle for an update to 0.25 xD

Regarding RealFuels, KSPI, and realism, another point to keep in mind is that KSPI has a fusion reactor, an antimatter reactor, and a warp drive. KSPI is what is known as "Hard SciFi". It's very firmly inspired by real science, but many of the things it does are just past the realm of tested science and into the realm of hypothesis and near-fiction. Nothing wrong with that; in fact I quite like it! I love to see what's just over the horizon technologically, what would happen if hypothesis became tested practice. It's also fine to take some liberties like improving the tested stats to make it game-viable without game-breaking. But when it comes to these liberties, we will all, always, have to agree to disagree when we see things differently. If talking hard science, it must be kept as hard science. In KSP, fusing too many parts together is arguably tantamount to cheating in some people's eyes. It's why I don't use mods that add space shuttles in 4 parts; what's the point? It's all designed to fit together in one way, for one purpose, with highly limitted options. As an engineer, I see that as, if not cheating, a pointless mod for myself. No offense to those who would rather focus on flying missions, but my joy is in seeing the craft I built work beautifully, and if it's all just a prefab 'magic box' part, then how is it my creation? I never followed directions for lego sets as a kid, because if I did then it wouldnt have been my creation! So that is my KSP. If yours is different, that's fine. More than fine, it's great! You probably fly more missions and go more places than I do, typically holed up in the VAB/SPH for hours on end perfecting every aspect. We all enjoy the game in different ways. Rejoice that most of your wants and needs for KSP have been taken care of for you by the amazing community, no matter what kind of a player you are! Now, before we get too far off topic here, let me just say that I love RealFuels. For me it is the golden standard for resources and realism. I am working on some code to try and implement fuel-filled wings for Procedural Dynamics specifically for Real Fuels tanks. Not easy though; his code is kinda like spaghetti xD very hard to make a standalone addon that doesn't trample it, lol.

Hey Northstar, I made a pull request to Kell like 4 days ago which was accepted next day. He just hasn't released it yet; it's all in the main RF repo as we speak. Regarding Vista and Hybrid, I was wondering about those. They were already removed from the repo, but I wasn't aware they needed to not make it back in. I worked up configs for them anyhow which were accepted into the RF repo along with the general config. It did seem off, but then, so does all the NTR and ElectricPropellant config changes. So I figured they were just weird edge cases. I'll see about dealing with those sooner or later if no one picks them up. Regarding Raptor's configs, I quite honestly find engine configs tedious and irritating. No good way to automate them, or make them elegantly with current tools. Part of why I have the procedural engines on my Kerbal Mod Building Bucket-list. I'll see about the engine configs, as I said, when I get around to it. Not like I am getting paid for any of this My most recent obsession has been space planes, and by proxy, the Procedural Wings mod, which I am trying to build an addon for with solar panel-covered wings and wings which carry fuel. Finally, i'll be frank as to why I haven't made configs for the KSPI ISRU to have full water functionality: It's a big magic 'I-can-do-everything' box (maybe scientifically accurate magic box, but none the less, a magic box). KSP is about design and engineering to me, so when a mod adds a simple cylinder which does 10 jobs (many of which are relatively unrelated), I consider it a poorly implemented part. Yet another idea on my WAY too long list is to fork the code from Karbonite and make a realistic ISRU alternative. But again, really long list...... Configs beyond RealFuels I always considered extra, and I'm not sure how much faith I have in Raptor's pack going forward anyhow; it's been lagging behind RF, and other mods even more so. It still doesn't have Methane configs for tons of parts which it logically could/should, and Raptor expressed little to no interest in electric RCS configs or in integrating the Near Future configs into the pack. Speaking of, I should really write up a config for RF for those.... I have played maybe 6 hours of KSP this whole week, and havent even had time to upgrade to 0.25 yet on my personal build of the game! So, I intend to enjoy myself this weekend, and maybe squeeze in some time writing code/configs and updating my personal copy of KSP xD

Ah, that is an excellent point; not sure why I thought it was appropriate to post here... In regards to the IRL engine though, actually, the engine only ran for 6 minutes, and I was referring to the X-51, not the J58. Yes, it's a prototype, but like I said, I love the near-future possibilities so I can not just play with what's out there now, but to play with what we have a solid chance of using in the next decade or two. The prototype was accelerated over mach 4 by a rocket, after which the X-51's SCRAM Jet engine took over. "the X-51 completed a flight of over six minutes and reached speeds of over Mach 5 for 210 seconds on 1 May 2013 for the longest duration hypersonic flight." I still wish we had SCRAM Jet engines, but ah well.

Any chance we could get support/configs for the cool engines that come with Karbonite? Specifically the Propfan it has. The thing just looks awesome, and the actual aerodynamics behind it are pretty cool too. On a side note, and maybe it's because I have been delaying 0.25 update on my main game for reasons, but I have been finding mach 4+ for extended periods to be nigh impossible due to parts on my craft exploding/overheating. Even in the last layer of the atmosphere (less than 0.001 fractional sea level by FAR's count). By extended periods, I mean 15-20 minutes (typically around 10 minutes or less mission time). It's not even the engines; it's the wings (procedural), parachutes (realchute), and other random parts. They reach 1400+ degrees, catch fire, and burn up. Am I doing something wrong? Side note: I know that irl, this is avoidable, because the X-51 was able to achieve mach 5.1 for 3 minutes, and likely had been at mach 4+ for at least 7-10 minutes. On top of that, it was in much denser atmosphere. I know it takes special materials and engineering, and might not be practical right this moment, but engineering is making steady headway. I like KSP not just for what we already can do, but what we COULD do, if technologies that are in the prototype phase now made it to reality. Finally, thanks so much for AJE! It's one of my must-have mods!

These parts look amazing! Well done! I love the new cockpit, the cargo bay (double-door sets actually fill a niche that is missing in mods like b9!), as well as the adapters and such too! Once you get closer to completion, I would be willing to work up MM configs to make your parts compatable with Real Fuels, if you like. One final aestetic thought on the cockpit; usually a nose-type section A brief question; do you plan to make adapters for some of the larger b9 Aerospace parts? It's fine if not, just curious Finally, would you consider making a long version of the j fuselage? I make long crafts typically, and too many segments can make for wobbly frames NP if not interested though, I understand.

Is there any way to use something like :FINAL but have it run before any other :FINAL configs? Basically I want it to run after all other mods have been processed, but before any other :FINAL configs so that users/tweakers can override them. Any way to do that? My only thought is to create a folder 'zzz' and put a 'zzz.cfg' file in it with a dummy MM opperation that does nothing, but includes a :FOR[zzz] to trigger dependency, then have all items I want to run after other mods but before :FINAL use :FOR[zzz] Is that the only way to do this? (Or will not even that work?)

I suppose that's true. Ultimately though, I'll deal with it if I feel like doing so at some point. I still want some hard science that says Electrolysis can opperate under contaminatied and possably corrosive conditions before I allow it to use wastewater. And not just 'it makes sense'; but rather actual scientific research. Raptor's in charge of the stockalike configs for engines. Raptor has some specific sets of config values he uses (he's got spreadsheets and what have you). If you are interested in realism, there's always the Realism Overhaul configs ;P My configs should be done minus the fuel tank parts and traditional style engine parts that KSPI provides. Which while I plan to configure them sooner or later, really aren't necessary, as I've configured RealFuel tank configs to allow water, which was the only resource it was missing. If you have an interest in getting the engine configs pushed through, I recommend you talk to Raptor. I'm done adding new stuff for the moment.

I've got a theoretically working KSPI config on my dev thread (see my sig, the section for the configs near the bottom of the first post in my dev thread for now). Soon as I get someone to test it more thoroughly, I'll make a pull request to the repo with just the KSPI configs if Kell would like. Oh, they don't cover the fuel tank parts from KSPI (they only add proper tank types to the already covered tanks like Default, ServiceModule, etc.), as I was going to set up a dynamic module configuration for them which takes, like, math and thinking, and I'm kinda shot from developing the existing configs for the moment Will get to them soon though! Another thought, I have a set of universal configs as a catch-all for tanks that RealFuels misses. It should make all stock-configured tanks innately compatible with RealFuels, though the personalized touch of manual configs will likely still be better. Again check my dev thread for those. I plan to add a catch-all for engines too, but that's a bit more tricky to make 'passable', and will likely never be nearly as good as hand configs. But at least it will work xD Thanks for what is probably my favorite mod, and congrats on the new release! I can't wait for RealHeat!

Just wanted to thank Sarbian yet again! I also threw together some Language Configs for Notepad++ syntax highlighting for Module Manager. It's available here, or on my dev page in my sig. Hope it's useful! I welcome any feedback on it! To use it, just go to Language (top bar in Notepad++), then "Define Your own Language...", then choose import. Select the file, and it's imported! To use it, select Language -> ModuleManager (same menu as "Define your own Language..."). You may have to restart NP++ before it shows up, but otherwise it should work fine!

I've got a functional (I think) set of configs for RealFuels, KSPI, and TACLS. See my dev thread in my sig, or here for more details. It's near the bottom. I will probably split each config out into separate file sooner or later (RF-KSPI, RF-TACLS, TACLS-KSPI, etc). For now they are in the same file as the same search can be leveraged for multiple modifications, and I am pretty heavy on the wildcards, so I wanted to be considerate to load times (I'm assuming wildcards make for a measurable hit to load time). I'm planning on some things like more accurate Ammonia conversion, and better TACLS support, but no need to pull that in.

the difference is about 11% density. It's on my to-do list, but a low priority. I could see this. But it doesn't inherently purify the water as the resulting gasses could react with the liquid producing other gasses, not to mention accidental/natural shift to the gas state of the other contaminants. And what if the ocean has corrosive properties to the electrolysis equipment? The way I see it, the ISRU module form KSPI already has a water filter built in. The TACLS filter is just a stand-alone filter. I mean, the ISRU already has a mining unit for uranium, aluminium, ice, etc, and nuclear reprocessing, electrolysis, sabatier, and several other reactions. It wouldn't make much sense to lack a filter. Oh yeah, TACLS has those. I always forget about them as I use Universal Storage. I'll just copy over the US configs when I get a chance. I dont do this right now because of overlap. I use wildcard searches, which take longer to perform, so when the same change is needed for multiple mods, I just make the changes in the same search, but with conditions for the mods in question. Also, people prefer less clutter, and when a mod isn't present, the other MM patches for mods that aren't present do nothing. I'll break it up if it gets too big though. I broke off the RF config because it's pretty heavy-handed, and some people might not want it. Unlike the other configs which only do good things far as I can see. And they are organized in the file itself, so easy to edit. Regarding the change I made to tanks, I am doing exactly what regex suggested already; I modify the TANK_DEFINITION configs and add a new TANK module to each that has Kerosine (because if it can hold Kerosine, it can hold water in pretty much the same way). I use a wildcard search so that every tank definition that has kerosene gets the change, with only a few lines of code. Finally, don't worry about the multiple configs issue; MM has config application ordering, so I can always just set my configs to take place after the RF ones. Let me know if you come across anything else!

Updated: I added the small MM config projects I have been working on lately in order to make RealFuels more universally compatible. Also some Notepad++ configs for syntax highlighting. Feedback appreciated on both!

Hey, thanks for taking the time to look over my thoughts/feedback and reply to them (a couple pages back). All perfectly reasonable points Interesting about the oxygen tanks; I had suspected it may be something similar to that. Does that mean the tank can't be refilled if they only output oxygen gas? Or does it have a reconstitution unit to turn the oxygen gas into it's liquid cryogenic form? Perhaps I should make a config for a converter unit that fills oxygen gas tanks and vice verse... I love the concept of the adapters also being the housing, especially if you made them into fairings mechanically to where the sides would extend as far up as the core hubs go and additionally cause the parts to not even be counted for purposes of aerodynamics. But that's again probably a little over-ambitious and/or difficult, lol. Love the progress, you guys are awesome!

*lurks* Wish I was a better programmer; I just can't quite understand how the PQSMod is/isnt working in the code despite my hours of poking and investigation into the source code. Really, it's so hard to look at the mod and know that the amazing PF crossover functionality is just out of reach. Hope Teknoman's school woes lighten in the future!

Just wanted to drop by and offer some thoughts; First, I have a complete (but untested) KSPI-RealFuels config. Just don't want to post it without testing first. It should set everything to RF standards, and change everything in the configs that RealFuels doesnt handle itself. Second, I wanted to support Tweakscale; with 60+ mods, my parts menu is VERY cluttered as-is with LSPI-Lite and over 50 parts disabled or removed. Also, a general note on Tweakscale and mass scaling: I thought realistic tank scaling was non-linear at one point myself. Turns out, this isnt the case. All tanks for space craft are actually pressure vessels, even when the contents are just at STP. Space is a vacuum, thus unless the fuel is at like 1/100th STP, it's going to scale more or less linearly because the tank's pressure increases with it's size. Strictly linearly in the case of highly pressurized gasses like Xenon and Argon whose tanks can't be built larger than a fixed size practically. The only real factors in tank weight that may not be linear are things like outer shells and structural elements. The tanks themselves are mostly linear, and at a certain point, all tanks become linear because we do not have the material structural integrity to build larger tanks, and instead tanks must simply be duplicated for more volume. @Fractal_UK Have you considered collaborating with NathanKell's efforts for AJE/RealHeat? AJE handles jet engines brilliantly, matching realism better than I thought possible myself. While RealHeat is in it's infancy, it could be the answer to your efforts to manage thermal energy realistically, as it wont use KSP's "pump" system, but instead uses a custom system based on physical properties. I think you and Kell have a lot of similar goals; the only difference is your mod pushes into the theoretical. But your emphasis on realism is the same none the less. In fact, I would highly suggest utilizing mods like RealFuels, AJE, and so forth so you no longer have to implement so many things in KSPI. The best part about realism is that IRL, there's ultimately only one way things work. There's only one STP desnity of LiquidOxygen. The various reactors and materials have piles and piles of data. 100 degrees kelvin is always 100 degrees kelvin. The only things that the topic can contain that lead to disagreement are: 1) how deep the realism goes 2) which data set is used (typically resulting in something like a 1-10% variance) 3) semantics The data set used typically just doesn't matter, long as the data was acquired with decent control and scientific rigor. Semantics are just that: semantics. In English I call the rose 'Red'. In Japanese I call it 'Akaii'. In Greek I might call it 'Kokino'. Because computers demand we all speak the same language, we have to pick one word for everything that is the same. If we mean H2O at STP, then there should be only one term for it, and everything that uses H2O at STP refers to the same definition. I've standardized everything to RealFuels currently in my configs, mostly because the mod has more realistic chemicals which are based on scientific data than any other mod. Far as I am concerned it's the realism standard currently. The only other notation I would support would be scientific standards of some kind. Also, many other mods around the forums offer their models under open licenses; You could use them as a base or final models. I highly doubt many users would mind...

Just wanted to drop in and say THANK YOU FOREVER to sarbian! You have fixed my wishes for MM configs forever with the new matching syntax! I'm so glad my post was helpful! I wanted to also drop in a MM script I worked up here that is only possible thanks to this latest feature addition: @PART [*]:HAS[@RESOURCE[Oxidizer],@RESOURCE[LiquidFuel],!MODULE[ModuleFuelTanks]]:FINAL{ MODULE[ModuleFuelTanks] { volume = #$../RESOURCE[Oxidizer]/amount$ @volume += #$../RESOURCE[LiquidFuel]/amount$ @volume *= 5 type = Default } !RESOURCE[Oxidizer] {} !RESOURCE[LiquidFuel] {} } @PART [*]:HAS[!RESOURCE[Oxidizer],@RESOURCE[LiquidFuel],!MODULE[ModuleFuelTanks]]:FINAL { MODULE[ModuleFuelTanks] { volume = #$../RESOURCE[LiquidFuel]/amount$ @volume *= 5 type = Jet } !RESOURCE[LiquidFuel] {} } This is a nice catch-all for any parts not covered by RealFuels. More tailored configs would always be better of course, but this makes it technically compatible with any stock-alike fuel tanks, no matter what the mod. (The 'FINAL' is just so that all other mods can add their Real Fuels configs first). Similar configs might be possible for engines as well! I can't thank you enough for this; it made my day (week, even). I will be working some up for other similar applications soon

Someone once pointed out that if you are using career mode/science mode, Mechjeb functionality only becomes available at points where you likely have already performed the maneuvers reliably yourself a few (or more than a few) times. It also gives a reason to buy the silly probe nodes, which otherwise are pointless besides form factor. Realistic? yes. Easier? Also yes. But for me, it comes down to designing the nodes and tedium reduction. Without Mechjeb, I could do all the same orbital transfers, rendezvous, and orbital insertions it does; I know how to do the math, how to find dV, Isp, TWR, etc. But I have a job, and a wife, and friends, and plenty of other cool mechanics, math, and physics to learn rather than doing the calculations for these by hand after the first 4 or 5 times. IMHO, Mechjeb is like a calculator; an excellent tool in which there is no shame in using it, provided you know how to do what it does yourself. Moreover, it still doesnt work so well with FAR; especially airplanes/spaceplanes

As always, amazing work! I love Universal Storage, and generally use it whenever practical. The tweakscale is a seriously awesome addition, and will mean even more opportunity to use it! Also, thank you very much for the Methane option. I was rolling my own MM files in the mean time, but this is great having them in the official mod! The new model reworks are cool too! I did have more than a couple requests/ideas..... -How about a comms wedge for Remote Tech? I'm guessing one could just use the stock folding antenna and slap it in the empty bay in blender or such, but despite my know-how of C# and MM, I fall squarely on my face when it comes to 3D programs any more advanced than Sketchup >_> Either way, just an idea -Would it be possible to make the parts slightly lighter without the exterior covering, but increase their drag? (FAR and stock both have the ability to manually increase the drag of parts from configs iirc; was just curious if this would be non-trivial) -There's still no battery module, which seems odd. I know fuel cell/electrolysis is more efficient in terms of electric charge per-ton, but fuel cells are capped in how fast they can convert the energy. Having a pool for spikes in usage would be very convenient. -Have you considered making a service module part? It would contain RCS thusters and an RCS tank (and possibly other parts). What would be even cooler is a variant that uses bipropellant, is the same weight, and contains no tanks, but has higher thrust and isp. -Is there a reason Oxygen and Oxidiser are separated? Specifically when it comes to something like RealFuels LiquidOxygen resource. Is rocket grade LOx not suitable for human(kerbal) consumption for some reason? I just ask because the oxygen tanks use LOx for density of the tank, but essentially contain GOx. I'm just curious why these are separated is all. -Would it be possible to use the water filter while in an aqueous ocean (such as Laythe's) to refill the water tanks? -Have you considered making a Bosch reaction wedge to reclaim the hydrogen from the methane made by the Sabatier reaction? -Would you consider making core parts that are 2 or 3 nodes tall? It'd be a minor reduction in part count, but every little bit can help! EDIT: just realised this is less necessary with the addition of tweakscale, but with addons, I could definitely still see a good use for it! (Like the DMagic Orbital Science wedges, KAS wedges, etc; I can easily need over 16 separate nodes!) -How about a Solar Panel Array wedge? -And finally, a really cool feature would be IVAs for the octo/hex cores, with a display for each part attached to the nodes. You could use the technique FusTek Karmony uses for IVAs, where the kerbals are 'seated' in invisible seats, and clicking on the hatch to either side could move them to the next habitable module it's connected to. What's more, you could potentially manage them as if you were using the external ship view, and/or add options like collecting experiments, but from IVA! Bit of an undertaking, just thought I'd throw it out there though. Sorry if I've bombarded you with stuff; I totally understand if none of them appeal to you or you just don't have time! I always appreciate anything and everything you make! Keep up the good work!

wait, WHAT!? OK, ditching last 15 minutes of work to investigate NAO. I know I proposed a format/implementation syntax a month or two ago, and he sounded cautiously interested, but I didnt think he'd actually do it! w00t!

General Update; Thanks for your comments and thoughts thorfinn and Kolago! Discussion/feedback helps keep me engaged in these projects. So, I've been playing with Kopernicus, and hit a wall with PQSMod handling. No one knows what the formatting for PQS should be, or even if the functionality exists in the scripting yet (disturbingly, not even Bryce). Soon as I get an answer there, I'll hopefully be able to continue working on helping with Kopernicus PF script handling. Concerning Combustion Composer, I have been doing some informal research, but it's a pretty big task, and I still doubt I would be able to do it all myself. Most of all, I have no idea how I would generate the mesh dynamically the way Procedural Dynamics, Procedural Fairings, or Procedural Parts do. I may know a lot about C#, but how KSP handles display of models, and how to alter those in real time is black magic to me. I'll figure it out eventually, i'm sure, but all I can do for now is compile data on how rockets work and how to derive values and traits. A note on the matter of Rocket vs Jet engines; I am doing Rocket engines first as the principals are more straight forward, the concepts simpler, and the common use greater. Moreover, I want to get rid of all this part bloat, and engines are the last bit to contend with for Procedural Parts. That said, I do really like AJE, and will at some point extend it to include Jet Engines (if I ever can make it at all...) Regarding Round Robin Rasters, I really should pick up my work on those again... I got a reply from the creator of Science Alert, and i'm free to base my work off his, which means a science display is 80% done already thanks to Rasterprop and Science Alert... Will probably wait for both to update to 0.25 first though. Figures Fraught with Fragility has been vexing me; I have some ideas on how to implement it code wise, but the penalties seem....off. Any good ideas would be spectacularly difficult to implement so far (degraded performance, complex injuries, erratic behavior, etc). If anyone can think of good, simple numerical ways to handle penalties, i'm all ears! Finally, I know it's not exactly on the list, but I have a set of MM configs which help some mods play nice, or add more options. (FusTek Karmony + MKS/OKS, RealFuels engine configs for Methane RCS, RealFuels configs for miscellaneous mods, and so forth). I might post those some time here, soon as I can update all of the relevant mods to KSP 0.25. These aren't in lieu of the mods in the poll; they are just little bits I do to make KSP mods play together the way I like, and I've been maintaining them for myself as convenient for a while now. May as well share Speaking of 0.25, it's a shame x64 remains sketch at best. Was really hoping they'd be able to plumb it up relatively quickly. Or add an API for kerbals. Or for TechTree. Or anything pre-existing that still lacks proper API, for that matter. Ah well, at least we got a lot of other QoL updates.

As mentioned in my PM, I may be willing to write up the configs, but I would want good, solid numbers on conversion rates, compression rates, and so forth. I can say that LiquidFuel maps much more accurately to RP-1 (a refined form of Kerosene) than to H2. Overall, RealFuels tanks are 5x the size, and fuels are 1/5th the density when compared to stock. NathanielKell's numbers for density have checked out against Wikipedia and the few more credible sources I've checked, so i'd be going with his numbers and conversion rates whenever there's a discrepancy. For these resources, the conversion is quite simple; Oxidizer & LiquidFuel are multiplied by 5 and summed for the total tank space. It'd be close enough. Ammonia can be converted in terms of space to LqdAmmonia/Ammonia * tank size. Do the same for Methane, and that's it! Honestly, if MM was just a liiiiittle more powerful, I could write a like 30 line config file to handle the whole thing, but alas, MM can't assign one part value to another dynamically.... The problem comes with things like the MW resource, which maps inaccurately to Electric Charge depending on the mod used, and finding where all these values are located, and what they are. I've got time & will to write up the files, but not to hunt down all the values from the parts files and compile them into a readable format. Either way, we'll see how it goes, but no guarantees unless I've got the numbers.

There will eventually be either a conversion script that will convert your configs to Kopernicus, or it will automatically detect them and perform the conversion itself. Obviously the latter would be more convenient, but right now I think the team is mostly focused on making things work period first. As of now, no. Kopernicus is currently unable to read Planet Factory configs of any kind. I am working on a script, but am hung up on details of PQS implementation. I need to know if Kopernicus configs support dynamic PQS or are close to supporting dynamic PQS, and what format is wanted for PQS in kopernicus.

Agreed; I mostly come across the disappearing wings because I build giant space planes (3.75m body, triple-SABRE engine craft. Launches at least 16t into orbit in a 20m x 4m x 2.5m cargo bay). They typically have 4-8 drop tanks, and can achieve circular orbits of about 300km, depending on payload weight. Shame about the trailing edges; oh well.

Thanks again for the awesome mod! Not sure how I would make large scale space planes without it! Funny enough, the disappearing wings bug is what has been bothering me lately. Also the inability to adjust the trailing edge to not taper (tapering means it doesn't line up with control surfaces). Both just aesthetics far as I can tell, but yeah xD. Will be happy with any added features, bugfixes or improvements though!