JadeOfMaar

@Gordon Fecyk I believe it was you who asked about localization sometime ago? JNSQ now supports localization (even the loading tips) so have at it if you're still inclined. We got German and Italian already, though.

@FreeThinker If the multiple modules you're targeting are siblings or otherwise a family (have a major commonality in spelling) you can use ? as placeholder for "X character here." And you can use that in combination with * for "any characters, any number of characters here". This example will work assuming you have parts with any of these four modules scattered across them: @PART:HAS[@MODULE[Module???Feature*]] { @MODULE[ModuleABCFeatureGenerator] { // operations } @MODULE[ModuleENBFeatureResourceConverter] { // operations } @MODULE[ModuleGNCFeatureTransmission] { // operations } @MODULE[ModulePQSFeatureResource] { // operations } }

@Roland1999 KSP is quite accurate with its aero model most of the time so the behavior you get in-game can often be trusted when carried over to a real craft. The SRBs may help just a bit in very loosely producing a composite lift surface along with the core lifter and drag back the CoL by some amount but not far enough to matter. The problem of cylinders is that they are round and not a shape with flat sides and enough area on any side (like a triangle or cube). That means they will have no ability to change the air deflection vector, and have no ability in themselves to prevent rolling, no ability to otherwise add to aero stability. By very loosely I refer to the fact that stock aero does not model fluid dynamics in any way. One part producing lift and deflecting the air stream will not block the part behind it from participating in the same. You'll need to install FAR and test your design in it for an even more accurate behavior. If you build a Venture Star with Mk3 tanks and use no wing pieces then ideally you should end up with a huge lift surface but if you turn on aero overlays and force the craft to yaw just enough, you'll see just as many of the cyan effect lines along the yaw axis as you would the pitch axis. If you bank to the left, then the right side of the craft will produce just as much lift force towards the left side as if it was pitching and won't "block the air flow" from every part behind it and towards the left side. All its parts will produce that sidways aero force and that's not realistic at all.

Solid boosters IRL can have very high gimbal ranges. This a bandage at best but not a true remedy. This does not actually fix the aero problem of the CoL being at the head of the craft. This just makes it more troubling and more sensitive to steer the craft. This is fighting instability (due to aero) with instability (high thrust with high gimbal). Would you give an already incredibly unstable craft even more ability to be unstable? ... Only if you really know what you're doing (and if your autopilot can handle it).

Yes, they are. If you have built planes, the same rules apply when you create a winged orbiter and its launch vehicle. The center of lift needs to always be behind (or below, depending on how you look at it) the center of mass. Due to where the shuttle is positioned on its launcher, the launcher doesn't need wings, but the problems due to the shuttle being side mounted (center of mass and center of thrust will move a lot) will quickly make it hard to adopt and very difficult and undesirable to engineer anything else like it. If you build anything like an arrow, you must respect the principle of the arrow's design. Pointy end forward, feathers at the back. Due to this principle and the very real problem of dry mass and dead mass, no real space agency will build a winged orbiter and a launcher with sufficient wing surface anytime soon, and when you attempt this in KSP you will be shocked by how much wing you'll need to keep the whole craft aerodynamically stable. Winged orbiters, in general, primarily use their wings to take advantage of the atmosphere during and after descent, not during ascent. When they glide and take that advantage they can exercise much more control over where and how they land, especially at low speeds, unlike capsules. Their touchdowns can be much more gentle due to landing horizontally, granting them much less need for chutes.

Perhaps you're using CKAN? Maybe HX is not marked as compatible with current KSP (as it hasn't needed actual updates in a long time). You'll have to enable your CKAN to sow mods for older versions of KSP. I'm a manual install kind of guy so I can't guide you to that switch.

This is a very nice little thing to have. But as HebaruSan above is asking: Why doesn't your zip file have a folder structure? This is very much needed in order for CKAN to know how to organize it in an install, and so players who install manually have an idea where the files go. This is vital to the operation of a mod or anything that's downloaded and run. Try to always remember and to always meet this requirement when you do a release.

Angel and I would completely agree with this statement. Angel doesn't provide tech support that far back. Upgrade your game. Those problems were fixed between KSP 1.4 and 1.5. There are reasons that should not be shared openly. The best answer to his problems was to create a resource system under his own control and with only a small set of resources which are immediately important to the workings of his mods. His mods default to Classic Stock but most of them still have a facility to change to use CRP. The exceptions to this are his Kerbal Flying Saucers, anything else futuristic, and any new mods he has "coming soon(tm)."

I created a very practical /sensible system for refilling Ablator on trans-atmospheric vessels that don't dump their heatshields. It revolves around an upgrade-able furnace installed in one of the unused decks of the stock science lab, and a pseudo "(EVA) work" resource consumed by converters installed into parts that hold non-transferables like Ablator or CRP radioactives. It requires the presence of a high level engineer and the lab connected to the ship in question in order to be effective. This will be a new Extras (optional) patch in Rational Resources.

Due to the highly disposable nature of solid rockets I always thought it was silly that players wanted a means to recover, recycle and refill them. So I'd like some insight (particularly from a KSPI user) how KSPI makes it worthwhile to do this. I know some of them mine Alumina to make AluminumFuel for SRBs. At the same time, I find it curious and possibly worthwhile to refill/re-paste heatshields so I created a system for that. The stock science lab is equipped with a converter titled "Blacksmith" with upgrade-able performance powered by B9 Part Switch. It simulates a molten metal forge and a piping system installed in one of the unused decks (the lab has 3 floors and can seat 6 kerbals, but only 1 floor and 2 kerbals are used by Squad). This converter uses Core Heat to spool up but will not overheat like you expect. It also requires an engineer trait (not converter skill) for full throughput. Since Ablator is not transferable, heatshields that hold it will get a converter that accepts Ore and the new RR Work resource produced by the Blacksmith. This simulates the kerbals going to the shields with hoses and sprays (or other applicable equipment) capable of withstanding the molten material from the furnace. This system will be released as an Extra and will not be active by default. Beyond refilling heatshields I imagine this being useful to those who have a working method (including MM patches) for reusing solid rockets or who want to use the lab like this to produce other non-transferable resources... EnrichedUranium for USI reactors, for example.

That same person also said (or agreed) on-stream that Monday doesn't exist so he trolled you. (He has a top quality funny bone. Lol)

A lot of modders got upset when the variant system arrived and it didn't provide fuel switching. Why on Earth did Squad not deliver this? is a burning question. I anticipate there would be a great headache for Squad to add that in later on and potentially revise the variant config structure, which will (on one hand) bring relief to mod makers, but on the other hand, also upset them: "Oh nowwww you fix this." Meanwhile the fuel and mesh switch mods keep on growing or are already fully matured. If stock variant fuel switching does arrive, it will be a few years late and waiting on it will be foolish. If Squad does it then there would be a huge gain to it. Several redundant stock parts can be deleted and that will potentially save on performance or at least, it will save on trouble navigating part selection. Until then, us modders roll our own solution and we carry on. Snark's SimpleFuelSwitch is minimal and the most stockalike solution so I urge @fulgur to use it. Don't wait on Squad for something so basic, so powerful, already available in a tiny mod. And remember, KSP is made to be modded. KSP is a blank canvas, and mods are your art tools. Squad will not deliver everything that's asked of them for that reason. As for me, what I've done with B9 Part Switch is more than enough, and zer0kerbal's offering trims this down to just the stock stuff.

An update is finally coming. Highlights: Ore tank options added for Alumina, Carbon, Mopedantte, Phosphorus. Phosphorus is essential to human life but can't do much in-game so it will be good for farming funds. It is not in the CRP so it's defined separately. Splitter converters for Alumina and Mopedantte will produce a small array of other resources. Facility for refilling heatshield ablator in-flight. Will require a science lab staffed with engineers to produce a "work" resource which will be consumed with some Ore, by converters added to heatshields (this latter converter simulates EVA work being used and is needed because Ablator cannot transfer). This is something I've entertained for some time, however, I can't make sense of the idea of refillable SRBs (as far as stock mechanics allow). Kerbalism compatibility for all the added ISRU chains. Fuel input switching on fuel cells. KSPI resources should no longer be getting replaced. Karbonite and Karborundum are bound to be purged as they are abstract handwavium and therefore, not rational resources. Feedback is open.

The joint strength of surface attached parts tends to be very low. For craft like a Skylon analogue, you'll easily meet the problem of your engines breaking off due to their weight (or their thrust) overpowering the joint strength of the wing structure between the engine and the center fuselage. The wing joints are further overpowered either by high drag due to AoA in low atmosphere adding stress onto them, or overpowered by the runaway thrust of a RAPIER cluster in mid-to-low altitudes. This kind of thing won't appear in the flight log. There are two ways to help with your structural integrity problem: Make your nacelles radially attached to the center, use Shift+Offset to offset them as far as you need, then strut them to the wings. MOAR STRUTS.

@Beetlecat @theonegalen Interesting issue here. I have applied (hopefully high) purchase costs to KK's labs in JNSQ and in Damon's KSC Extended. Concerning Bureaucracy, I may have more reason to increase them. I don't play career so my prices may all be rather low.

Karbonite+ includes drills and one (maybe two) particle scoops for Karborundum. Mods that provide Ka+ typically come in the form of planet packs as it is the planets and stars that provide it in-game. You must explore with the Ka+ detector to find planets that contain it or find the altitude in low orbit of the star(s). Once you have these locations you must deploy mining infrastructure and build up Ka+ depots and then you can conveniently fly Coyote freighters. Two of the stock planets and a certain altitude in Low Sun Orbit possess Ka+. The planet packs that I know of, which also provide Ka+ include: Galileo's Planet Pack Grannus Expansion Pack The World Beyond Outer Planets Mod (I think)

@damonvv You don't have to wait to see if Squad revamps the solar panels. (That might never happen so it's dumb to wait on that... For all we know... Squad might redo all the plane parts and THEN the misc stuff like solar panels, structural panels and the RTG.) I advised that your Dragon solar panels be blue so that they'd be easily recognized by folks who weren't expecting solar panels. But mods do exist that have solar panels in colors other than blue, like any ISS parts mod with the famous yellow or orange. The fanbase seems to really want black panels now so the only question is "When do you feel like it?" I do believe it would be super easy to do and there's no obligation not to provide it.

@caipi Thanks for noticing that error. It has been dealt with and will appear in the next release.

Yeah. I quickly noticed. I just asked someone about the possibilities of exploiting ModuleColorChanger{} which is used by the stock heatshields. I got a positive-but not-quite-sure answer, and an offer to write a shader if you can implement it into KSP.

@Jacke I've thought of FAR, yes. Something like that would be the best option and would spare the troubles of "Corrosion Scale" which I'm outlining below to LGG. @linuxgurugamer I've been thinking hard on this for the last few hours and I just did some scribbling in spreadsheets. In my pursuit to answer your question I came up with another new question: How do I make corrosion scale well (with respect to surface area without making things more complicated)? So I decided to derive from the bulkhead size and named this new factor simply "Corrosion Scale." This is so that while a Kerbodyne tank will obviously have a lot more material to corrode than a Mk1 tank, the two should still corrode at nearly the same speed since the Kerbodyne tank has a lot more surface area. This method is still flawed as a double-length Mk1 tank will, by this rule, last twice as long as either of two single-length Mk1 tanks because it's still a Mk1 tank. I think these baseline values (assuming a planet with atmo acidity of 1 and at least 1 atm of pressure) would be fine. The formulas here are: HP = (Mass * Tolerance * Resilience * 0.1). Lifespan = HP / Corrosion Scale. Measured in 6 hour days. Having those 5 factors seems nice actually. Someone on Discord additionally suggested having corrosion scale with the velocity vector while moving through atmo...but you already have it covered by scaling it with part temperature. Shock heating will lead to increased corrosion on its own. That's fabulous.

Sadly I know that detecting the outermost parts would be tough to do and would be hard on the CPU. It's no problem at all. I expect this to demand a great investment of time and energy. And I wouldn't want to force you and burden you (in particular) with how much you do for the community already. Just inviting you to see my idea is enough.

Crap. Div/Zero. Thanks for noticing! I updated the zip at the download link.

I've been carrying this idea for a few months now and I figured it would be quite neat to have. Its customization and versatility would be at least on par with the Kopernicus feature: HazardousBody, which replaces HazardousOcean and does not require the hazardous body to possess an ocean or atmosphere. Its overall purpose is to add that missing aspect of challenge, of risk and reward to exotic planets in your favorite planet mod(s). The idea first came to me while watching beaucoupzero's video of a KSPI shuttle entering into Deemo, the yellow acid moon in @AndrewDraws Extrasolar mod and sadly not taking damage from the atmosphere. (Video link starts at 10:00, you don't have to scrub it or watch the whole thing.) HazardousBody can be applied and restricted by altitude regions, points with effect radius (making only the insides or immediate areas of volcanoes deadly in-game), latitude regions, possibly even complex toroidal regions. It can even accept a grayscale map texture (which needs investigation). It's an incredibly powerful feature just for manipulating heat. But there is more to a deadly planet that exposed lava. So, what I'm envisioning is a cousin to HazardousBody. With how complex it can get and its deep involvement with parts, I doubt I can hope for it to be fully realized as a feature of Kopernicus, but as its own part failure mod or a sub-feature of another part failure mod, or a certain habitation mod. Suitable existing mods that come to mind are Kerbalism, Kerbal Health, BARIS and Oh! Scrap, owned by @Sir Mortimer @garwel @Angel-125 @severedsolo. Also paging @linuxgurugamer because why not? How I imagine it will work in-game is: Parts carry an HP gauge and a resilience factor (equivalent to this is the DEF or SP DEF stat in monster/magic battle games). Resilience is how reactive or non-reactive the part is to the acid around it, and HP scales with mass by default but can be influenced by one or two factors such as heat tolerance or part category. Depending on the resilience value given to a part, it is implied to largely consist of weaksauce Aluminum sheets...or consist of a very buff, complex Carbon lattice. Some parts, despite having a powerful outer hull composition, may still have exposed innards that aren't and can't be as well protected such as intakes or shrouded solar panels. There will be facilities to refurbish parts and restore HP (very much like any maintenance process within a failure mod), but not all parts can qualify such as early-game crewed parts, delicate science instruments or certain classes of engine. Kerbals would be most vulnerable to corrosion. Just as with EVA fuel, when a kerbal leaves the ship they may take from a limited, onboard supply of dispensable anti-corrosion coating, and when they board or disembark, the part possessing the hatch should have especially high resilience or should take corrosion damage. Planets will have two or three corrosion factors, simply measures of how powerful its acid (or alkali) is. One for ground, for the ocean, and for the atmosphere. Why separate factors? It's possible for a planet to have a corrosive atmosphere and a neutral ocean, or a neutral atmosphere and corrosive ocean. The ground factor will apply to anything immediately touching the ground (such as landing legs or EVA kerbals). The ground could be saturated by acid rain. The ocean...pretty straightforward. And to the atmosphere (basic, scaling in intensity with atmosphere pressure). Additionally, this ideally should also accept a float curve for atmospheric intensity and would enable such things as the boundary in Venus' atmosphere above which it's still completely safe to fly but below which are the acid cloud deck and sudden acid rain. Ideally, the corrosion should only affect the outermost parts of a ship and work its way inward, giving substance to the concept of applying armor to your ship. Advanced features: Certain modules will break and become unavailable if the part bearing this module has sufficiently corroded (taken a certain fraction HP loss). This can easily help simulate breached cabins and greenhouse environments. If a part has an ablator module then whatever resource is used by this would be consumed and would mitigate the corrosion damage. Parts can be destroyed (critical failure) after taking a certain fraction of damage before losing all of their HP, such as a fragile tank full of highly reactive resource like CryoTanks and LH2 or Oxidizer. Kerbals and certain parts can have upgrade-able resilience factor or HP. Life support mods (Snacks, Kerbal Health, Kebalism) will respond to excess HP loss on the kerbal and apply their appropriate negative status (stress!, poisoned, panic, fainted) to the kerbal. This, if it was realized as a mod could add much more immersion, when applicable, to an interplanetary or interstellar experience in KSP. Activate this alongside part pressure limits, and hostile worlds like Venus in RSS, and Deemo in Extrasolar will get that much more interesting and immersive.

Whenever @Angel-125 is ready.

@NermNermNerm Except for TAC life support, I think I generally buff the Mk2 version of a converter by up to 25% over what I find in a 1.25m form, as long as the volume of the thing makes sense to me. I understand your decision against bio-waste. I tried a life support mod which had one job: produce sustenance from a steady EC input alone and hold a small amount within the converter. There were no tanks outside of the converters. Since food production comes in two very distinct forms, I'm confused now how to treat them in my mod. I provide only 3 parts for holding converters. And it's not easy for me to choose which 3 features of your mod to put into them. If you experiment with B9PS as I do, you will be aware of B9's ability to alter the I/O lists in a given converter (but a quicksave and quickload need to happen after the switch). I've entertained the idea of using this on your modules but I wont be sure if your plugin will agree with it. I guess hydroponics is more appropriate for Airline Kuisine. Until now I didn't know that each one was appropriate for a certain situation and so I couldn't decide. I haven't gotten an answer #3 from your explanation (due to the number of industrial converter chains not directly tied to food), though your explanation is sufficient for understanding PKS better. I'd like to mention that (pardon me if you know already): I'm very aware of the tiered food resources and that they're availed through B9PS; As subtypes, and with recent feature additions to B9PS, you can make each tier/each subtype require a tech node unlock, and progressively make them all available which is that much better and more fitting for PKS.