SorensonPA

And that's the problem, for some reason IFS is completely skipping over anything related to fissionable fuels - no options for uraninites, actinides, enriched uranium, UF4, Thorium, Uranium Nitrade and and so on. I did a KSPIE playthrough about a year ago and I THINK they required their own specialized tank (inline, IIRC) but it doesn't seem like it's being generated so I have to find out what mechanism KSPIE/IFS creates it and find out what's going wrong. EDIT: After nosing around in the part and patch files for a bit it looks like it's less a matter of a nuclear fuel tank part failing to load as there simply not being one at all - not a single container file in Utility (which has the hex cans and the airbag) has any listed options for them in the IFS modules and the closest ones to that function are a few in Fueltank that seem to have been dummied out with their unlock techs set to Hidden and only one fuel type. I'll see if shoehorning options for all those radioactive materials info the cargo hex module's config will work as a bypass.

What's KSPIE's behind-the-scenes process for setting up tanks for things like uraninites and radioactive fuel? I've got hex tanks for gasses, liquids and varying forms of cargo but haven't found ANYTHING for the aforementioned: stock ore tanks end at Regolith and cargo hex modules end at Spudomene, so I'm stuck using those huge PV receivers that double as solar panels for energy and it's bottlenecking my offworld construction efforts.

Given how much modding has driven the popularity of KSP, methinks a means of easing comparability issues between different mods is a fair suggestion to make. Because of the way different mods can approach the same issue, sometimes you wind up with redundancies and incompatibilities: mods that introduce things like nuclear reactors might have the same resource concept - enriched uranium, for example - but use unique versions of enriched uranium that only work with their specific mod counterparts. Another example are mods that introduce the concept of life support - like TAC LS and Civilian Populations - which approach the same issue with dramatically different resources and processes and as such require quite a bit of jiggery-buggery to get them working together. In light of these sorts of clashes, then, it might be worthwhile to set standards for many of the more common resources that pop up in mods such to ease these sorts of conflicts - and should Squad decide they want to integrate those kinds of functions into later updates, they'll then already have some of the fundamentals already mapped out. Off the top of my head, I can think of: Basic Elements: Hydrogen, Deuterium, Tritium Helium-3, Helium-4 Carbon, Nitrogen, Oxygen Neon, Argon, Krypton Thorium-232 Uranium-233 and 235 and 238 Plutonium-239 Antimatter Exotic Matter Biological resources: Ice Food, Clean Water, Clean Air Solid Waste, Liquid Waste, Dirty Air Heck, you could probably just use a "1 unit = 1 kilogram" quick and easy pattern for all of these and have it work well enough once modders finished adjusting consumption and conversion rates. Just ensuring that universal bedrock so everybody's playing on a level field.

Hey there, I noticed that the Mercury biome map is slightly off: the same light-cyan color wound up getting used for the North and South Pole alike so the former would show up as the latter. Nothin' a quick bucket fill or 10 to white in Paint can't fix, but something to take care of supply-side nevertheless. EDIT: And now I'm noticing according to SCANsat that the vast, vast, vast majority of the surface is getting pegged as Lunar Seas and Major Craters, with Far Side Basin and the like getting crammed into miniscule ridges despite the biome map file painting a different picture. Hmm. EDIT: Aha, and there's a period missing for the green value of Venus' Volcanic Rise biome, no wonder I couldn't find it.

Has anyone using CKAN noticed anything unusual after installing some recent updates of other mods? I took a bit of a hiatus from ~August 8th until yesterday when I did an update and farted around with anomalies on Earth, and I just noticed that my moon base is suddenly hovering several kilometers above Iapetus of Saturn. EDIT: And trolling through /gamedata by date, looks like it's something in Kopernicus which got updated yesterday, since the only other recent stuff is KW Rocketry Community Fixes, Kerbal Foundries, RPM, Dmagic Orbital Science, Planetary Bases, KIS and Texture Replacer. So yeah, get ready to do some save editing.

You been playing a bunch of X-COM recently, haven't you?

No bite, just a NullRef exception: [LOG 21:00:23.821] [ModuleManager] Exception while processing node : /Kingularity_Values/@PART[*]:HAS[@MODULE[ModuleEngines*]]:Final System.NullReferenceException: Object reference not set to an instance of an object at ModuleManager.MMPatchLoader.WildcardMatchValues (.ConfigNode node, System.String type, System.String value) [0x00000] in <filename unknown>:0 at ModuleManager.MMPatchLoader.CheckConstraints (.ConfigNode node, System.String constraints) [0x00000] in <filename unknown>:0 at ModuleManager.MMPatchLoader+<CheckConstraints>c__AnonStorey3.<>m__0 (System.String c) [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[System.String].TrueForAll (System.Predicate`1 match) [0x00000] in <filename unknown>:0 at ModuleManager.MMPatchLoader.CheckConstraints (.ConfigNode node, System.String constraints) [0x00000] in <filename unknown>:0 at ModuleManager.MMPatchLoader.ModifyNode (.ConfigNode original, .ConfigNode mod) [0x00000] in <filename unknown>:0 at ModuleManager.MMPatchLoader.ModifyNode (.ConfigNode original, .ConfigNode mod) [0x00000] in <filename unknown>:0 at ModuleManager.MMPatchLoader+<ApplyPatch>c__Iterator1.MoveNext () [0x00000] in <filename unknown>:0 It's probably something stupid on my end, here's the config I'm running this on: @PART[*]:HAS[@MODULE[ModuleEngines*]]:Final { @MODULE[ModuleEngines*] { @atmosphereCurve:HAS[#key,0[*]] { %newKey = #$key,0[1, ]$ @newKey *= 1.3 @key,0 = #0 $newKey$ } @atmosphereCurve:HAS[#key,1[*]] { %newKey = #$key,1[1, ]$ @newKey *= 1.3 @key,1 = #1 $newKey$ } } } I'm wondering if it might be a tabbing error from copypasting the code or something, seems Notepad++ doesn't compensate for pasted tabs. EDIT: I might just be making an ass of myself by making some mistake only invisible to the programming-illiterate, but I think I might have gotten it: @PART[*]:HAS[@MODULE[ModuleEngines*]]:Final { @MODULE[ModuleEngines*] { @atmosphereCurve:HAS[#key[0?*]] { %newKey = #$key,0[1, ]$ @newKey *= 1.3 @key,0 = #0 $newKey$ } @atmosphereCurve:HAS[#key[1?*]] { %newKey = #$key,1[1, ]$ @newKey *= 1.3 @key,1 = #1 $newKey$ } } } Unmodded ion's 130-5460, modded T-1 aerospike is 603.2-603.2, basic jet engine is 12480, OPT dark drive is 3900. I do get the feeling that this approach is only hitting stuff that reads as key,x = 0 x and key,x = 1 x - there's some air-breathing rocket engine with a funky atmosphereCurve setup with the ASL value unchanged while the vac rating was modified. EDIT: Yeah, looks like that's it, here's the part's curve: atmosphereCurve { key = 0 340 key = 0.1 850 } Although it certainly begs the question of why he'd use a setup like that when atmCurve would do the same and better. EDIT: I've also noticed this doesn't do anything for mode-based engines, but that's just a matter of fiddling with the specified affected modules in some fashion.

I ran the configuration as copied from FlexGunship's latest post where he confirmed your approach worked: @PART[*]:HAS[@MODULE[ModuleEngines*]] { @MODULE[ModuleEngines*] { @heatProduction *= 0.33 @atmosphereCurve { key0 = #$key,0[1, ]$ @key0 *= 1.3 @key,0 = #0 $key0$ key1 = #$key,1[1, ]$ @key1 *= 1.3 @key,1 = #1 $key1$ } } } That config worked fine on any engine with 2 or more key entries (ion engine with 100-4200 reads as 130-5460, modded T-1 aerospike with base isp of 464-464 is now 603.2-603.2) but anything that had just 1 key value got a squared increase - the aforementioned OPT dark drive has a single entry of 3000, but comes out at 5070 and the stock basic jet engine has 9600 but comes out to 16224 after patching. I'm trying to run your latest bit now, though I'm guessing I'm hosing up the formatting somehow since it won't even take root.

What luck! I've been doing an ad-hoc MM-based science progression deal of sorts and the isp scaling is the one bit I was having trouble with, so many thanks. One thing I did notice, however, is that if a part has only one isp value (stock jet engines and OPT dark drives and Mk 2 scramjets, for example) any additional key,# entries will keep piling on it so it winds up getting modded to the square of the multiplier value, so this would need something with the ability to detect that there're no more key,# entries to mod and stop instead of looping back.

First pass is completed: all LFO/Mono engines given TWRs based on approximate real-life analogues, Mk. 2 and 3 fuselages updated, just realized the Mk. 1 Intake/Fuselage is not. Contemplating a company-pairing approach for finding analogues: Aerojet for Jeb's, Kosberg/Glushko for Rockomax, Aerojet-Rocketdyne for Kerbodyne, though I suspect this could hinder as much as help.

What's this mod about? NathanKell's Real Fuels mod is absolutely essential for satisfactory use of the much-beloved Real Solar Systems mod, and goes to great lengths to create as accurate a portrayal as possible of the numerous propellant and propellant tank types developed over the course of aerospace research. This accuracy, one of Real Fuels' greatest strengths, is also one of its greatest weaknesses: due to the considerable amount of scripting involved in Real Fuels and mods dependent upon it, many other mods which have a tentative overlap in their area of interest - TweakScale, for example - are rendered inert or suffer from serious malfunction. What would this mod do? The goal of Kerbal Fuels is to modify stock fuel and engine assets in such a way as to replicate many of the characteristics of Real Fuels that make it essential for Real Solar System, but maintain enough of the stock character and functionality that it maintains (a reasonable chance of) comparability with as many mods as possible and require only a minimum of effort to bring others into alignment. There are three distinct factors that define Real Fuels and make it necessary for any kind of Real Solar System playthrough: realistic fuel types, realistic fuel tanks and realistic engines. The resource and plugin data that forms much of the backbone of these factors is what can lead to conflicts, but a reasonable facsimile of those basic characteristics can be applied to get something of an approximation of that functionality: Give resources like Liquid Fuel and Oxidizer appropriate densities and volumes, thus allowing for rockets of realistic scales Give fuel tanks realistic volumes and tank mass as a percentage of fuel mass, thus giving a realistic approximation of total tank weight Give engines proper mass values based upon their thrust and isp levels to give a realistic approximation of performance, while refraining from adjusting other values to maintain stock "character" What would this mod NOT do? While Real Fuels and its dependent mods deserve praise for their dedication to create as authentic a space program management experience as possible, the lengths to which they go to create this authenticity can leave many mods in a lurch as far as cohabitation goes. With this in mind, while Kerbal Fuels seeks to replicate Real Fuels' core characteristics, it stops short of more exhaustive measures of doing so in order to avoid burning certain bridges. As such, Kerbal Fuels will not: Add new resources and fuel types, and the necessary scripting to make them accessible and functional: new resources would require a heavy dose of engine modification, which is part of the root of Real Fuels' conflicts with other mods Add new fuel tank types and characteristics, and the necessary scripting to make them accessible and functional, which is likewise part of the root of mod conflicts Modify engine characteristics other than mass, save rare situations like the Twin Boar booster which includes fuel tank functionality, as some of these characteristic changes would hinge upon having new resources and fuel tank types, already ruled out (increasing vacuum isp to ~420 which would only be possible with a LH2/LOX fuel, LV-Ns and other special cases aside) Provide highly-scrutenous levels of accuracy and real-life replication. The goal of Kerbal Fuels is to create an approximation while still keeping certain stock characteristics and to do so with a minimum of risk of mod conflict, so while obviously the LV-N wouldn't be running purely on the KSP analogue of RP-1 it's a relatively minor liberty/abstraction that has to be tolerated since setting the proper fuel source would create bigger problems that're anathema to the core purpose of the mod. So where's the mod? Kerbal Fuels can be downloaded from Kerbal Stuff and will hopefully be available through CKAN shortly. Procedural Parts and Module Manager are required for Kerbal Fuels to function. Given this is currently a test-of-concept stage, Kerbal Fuels modifies only stock LFO and MonoPropellant engines, though should this prove a feasible idea other popular engine pack mods will be incorporated. So how does it work? Surprisingly well. Between Procedural Parts and TweakScale, Kerbal Fuels can create basic replications of early space flights and their launch vehicles with approximately similar end results, such as a ~140-ton rocket capable of delivering a ~4-ton crew capsule to orbit with sufficient fuel to de-orbit and land. Given the lack of proper LH2/LOX engines and their ~420 isp, though, lunar missions and beyond are likely to prove challenging, although the LV-N might be able to compensate for such. So what do you want? Feedback, naturally. Suggestions on data sources, part analogues, empty and full mass-to-volume and fuel-volume-to-tank-volume ratios. Much of this initial setup was hobbled together from Real Fuels itself, though the methodology is not as perfect as desired, and getting access to some original sources and figures and insight from people who know a hell of a lot more about real rocketry would make things much better. Changelog: 0.1: Initial fully-compiled version. Raw .cfg dump, Fuel Tanks: @PART[adapterMk3-Mk2] { @Mass = 0.29 @RESOURCE[LiquidFuel] { @amount = 4500 @maxAmount = 4500 } @RESOURCE[Oxidizer] { @amount = 5500 @maxAmount = 5500 } } @PART[adapterMk3-Size2] { @Mass = 0.362 @RESOURCE[LiquidFuel] { @amount = 5625 @maxAmount = 5625 } @RESOURCE[Oxidizer] { @amount = 6875 @maxAmount = 6875 } } @PART[adapterMk3-Size2Slant] { @Mass = 0.362 @RESOURCE[LiquidFuel] { @amount = 5625 @maxAmount = 5625 } @RESOURCE[Oxidizer] { @amount = 6875 @maxAmount = 6875 } } @PART[adapterSize2-Mk2] { @Mass = 0.116 @RESOURCE[LiquidFuel] { @amount = 1800 @maxAmount = 1800 } @RESOURCE[Oxidizer] { @amount = 2200 @maxAmount = 2200 } } @PART[adapterSize2-Size1] { @Mass = 0.116 @RESOURCE[LiquidFuel] { @amount = 1800 @maxAmount = 1800 } @RESOURCE[Oxidizer] { @amount = 2200 @maxAmount = 2200 } } @PART[adapterSize2-Size1Slant] { @Mass = 0.116 @RESOURCE[LiquidFuel] { @amount = 1800 @maxAmount = 1800 } @RESOURCE[Oxidizer] { @amount = 2200 @maxAmount = 2200 } } @PART[adapterSize3-Mk3] { @Mass = 0.29 @RESOURCE[LiquidFuel] { @amount = 4500 @maxAmount = 4500 } @RESOURCE[Oxidizer] { @amount = 5500 @maxAmount = 5500 } } @PART[miniFuelTank] { @Mass = 0.003 @RESOURCE[LiquidFuel] { @amount = 90 @maxAmount = 90 } @RESOURCE[Oxidizer] { @amount = 110 @maxAmount = 110 } } @PART[mk2_1m_AdapterLong] { @Mass = 0.116 @RESOURCE[LiquidFuel] { @amount = 1800 @maxAmount = 1800 } @RESOURCE[Oxidizer] { @amount = 2200 @maxAmount = 2200 } } @PART[mk2_1m_Bicoupler] { @Mass = 0.058 @RESOURCE[LiquidFuel] { @amount = 900 @maxAmount = 900 } @RESOURCE[Oxidizer] { @amount = 1100 @maxAmount = 1100 } } @PART[mk2Fuselage] { @Mass = 0.116 @RESOURCE[LiquidFuel] { @amount = 4000 @maxAmount = 4000 } } @PART[mk2FuselageLongLFO] { @Mass = 0.116 @RESOURCE[LiquidFuel] { @amount = 1800 @maxAmount = 1800 } @RESOURCE[Oxidizer] { @amount = 2200 @maxAmount = 2200 } } @PART[mk2FuselageShortLiquid] { @Mass = 0.058 @RESOURCE[LiquidFuel] { @amount = 2000 @maxAmount = 2000 } } @PART[mk2FuselageShortLFO] { @Mass = 0.058 @RESOURCE[LiquidFuel] { @amount = 900 @maxAmount = 900 } @RESOURCE[Oxidizer] { @amount = 1100 @maxAmount = 1100 } } @PART[mk2FuselageShortMono] { @Mass = 0.043 @RESOURCE[MonoPropellant] { @amount = 1600 @maxAmount = 1600 } } @PART[mk2SpacePlaneAdapter] { @Mass = 0.058 @RESOURCE[LiquidFuel] { @amount = 900 @maxAmount = 900 } @RESOURCE[Oxidizer] { @amount = 1100 @maxAmount = 1100 } } @PART[mk3FuselageLF_25] { @Mass = 0.363 @RESOURCE[LiquidFuel] { @amount = 12500 @maxAmount = 12500 } } @PART[mk3FuselageLF_50] { @Mass = 0.726 @RESOURCE[LiquidFuel] { @amount = 25000 @maxAmount = 25000 } } @PART[mk3FuselageLF_100] { @Mass = 1.452 @RESOURCE[LiquidFuel] { @amount = 50000 @maxAmount = 50000 } } @PART[mk3FuselageLFO_25] { @Mass = 0.363 @RESOURCE[LiquidFuel] { @amount = 5625 @maxAmount = 5625 } @RESOURCE[Oxidizer] { @amount = 6875 @maxAmount = 6875 } } @PART[mk3FuselageLFO_50] { @Mass = 0.726 @RESOURCE[LiquidFuel] { @amount = 11250 @maxAmount = 11250 } @RESOURCE[Oxidizer] { @amount = 13750 @maxAmount = 13750 } } @PART[mk3FuselageLFO_100] { @Mass = 1.452 @RESOURCE[LiquidFuel] { @amount = 22500 @maxAmount = 22500 } @RESOURCE[Oxidizer] { @amount = 27500 @maxAmount = 27500 } } @PART[mk3FuselageMONO] { @Mass = 0.169 @RESOURCE[MonoPropellant] { @amount = 6250 @maxAmount = 6250 } } @PART[proceduralTankLiquid] { @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[Mixed] { @dryDensity = 0.029 @RESOURCE[LiquidFuel] { @unitsPerT = 15516 } @RESOURCE[Oxidizer] { @unitsPerT = 18964 } } @TANK_TYPE_OPTION[LiquidFuel] { @dryDensity = 0.029 @RESOURCE[LiquidFuel] { @unitsPerT = 34480 } } @TANK_TYPE_OPTION[Oxidizer] { @dryDensity = 0.029 @RESOURCE[Oxidizer] { @unitsPerT = 34480 } } } } @PART[proceduralTankOre] { @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[Ore] { @RESOURCE[Ore] { @unitsPerT = 866.434 } } } } @PART[proceduralTankRCS] //Based on tank mass ratios for hypergolic fuels like Aerozine50+NTO: Monoprop density is more akin to straight Hydrazine, but Hydrazine tank mass ratios (restricted to Service Module types) are much higher and would kill its usage for actual hypergolic engines. { @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[RCS] { @dryDensity = 0.027 @RESOURCE[MonoPropellant] { @unitsPerT = 36275.257 } } } } @PART[proceduralTankXenon] // { @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[XenonGas] { @dryDensity = 0.0908 @RESOURCE[XenonGas] { @unitsPerT = 110132.158 } } } } @PART[radialRCSTank] { @Mass = 0.002 @RESOURCE[MonoPropellant] { @amount = 76 @maxAmount = 76 } } @PART[rcsTankRadialLong] { @Mass = 0.006 @RESOURCE[MonoPropellant] { @amount = 240 @maxAmount = 240 } } @PART[toroidalFuelTank] { @Mass = 0.008 @RESOURCE[LiquidFuel] { @amount = 135 @maxAmount = 135 } @RESOURCE[Oxidizer] { @amount = 165 @maxAmount = 165 } } @PART[xenonTankRadial] { @Mass = 0.003 @RESOURCE[MonoPropellant] { @amount = 400 @maxAmount = 400 } } Resources: @RESOURCE_DEFINITION[LiquidFuel] //RP-1 analogue { @density = 0.000859 @unitCost *= 0.18 } @RESOURCE_DEFINITION[Oxidizer] //Standard Liquid Oxygen, stock multiplier 3.9177277179236043095004897159647 { @density = 0.001141 @unitCost *= 0.036 } @RESOURCE_DEFINITION[MonoPropellant] //Based on density of Hydrazine { @density = 0.001021 @unitCost *= 0.24 } //Xenon density/price isn't being changed (yet) due to the relationship between Xenon and EC for providing thrust, as changing density could drastically increase or decrease the EC requirement and its feasibility along with it. Based on RL density KSP Xenon units are ~0.03225806451612903225806451612903 of a liter //@RESOURCE_DEFINITION[XenonGas] //{ //@density = 0.0031 //@unitCost *= 4 //} @RESOURCE_DEFINITION[IntakeAir] { @density = 0.001 @unitCost *= 0.2 } Engines: @PART[liquidEngine] //LV-T30 Reliant, based on Aerojet A-7 TWR of 64.2112462006079. { @mass = 0.340 } @PART[liquidEngine2] //LV-T45 Swivel, based on Bell 8081 TWR of 55.8230769230769 { @mass = 0.368 } @PART[engineLargeSkipper] //Skipper, based on Aerojet LR-91-5 TWR of 90.71 { @mass = 0.717 } @PART[liquidEngine1-2] //Mainsail, based on Aerojet LR-87-3 TWR of 89.204410011919 { @mass = 1.682 } @PART[liquidEngine2-2] //Poodle, based on J-2 TWR of 73.1801112656467 * 1.2028571428571428571428571428571 = 88.025219550963601999999999999997to compensate for lower vac isp (421/350) { @mass = 0.284 } @PART[liquidEngine3] //Terrier, based on Rocketdyne RS-72 TWR of 40.922454165373989865413878178138 { @mass = 0.147 } @PART[liquidEngineMini] //Spark, based on Notional Liberty-2 TWR of 44.34 { @mass = 0.040 } @PART[microEngine] //LV-1 Ant, based on Marquardt R-40A TWR of 38.43 { @mass = 0.005 } @PART[nuclearEngine] //LV-N, based on US Dept. of Energy Nerva NTR 1971 total launcher TWR of 2.5991651424389902159071088144992 (Nerva NTR 1991, which has an actual engine-specific mass of ~8,500 kg, has a pure engine TWR of 3.9983210409546081429513701505067, but since Kerbal Fuels doesn't account for increased cryo tank mass for storing actual LH2 the lower ratio is used to simulate) { @mass = 2.106 } @PART[omsEngine] //Puff, based on AJ10-118k TWR of 45.143439638852482889180136886559 as data on the AJ10-190 used in the STS OMS was unavailable { @mass = 0.043 } @PART[radialEngineMini] //LV-1R Spider, based on Marquardt R-40A TWR of 38.43 { @mass = 0.0052 } @PART[radialLiquidEngine1-2] //Thud, based on Rocketdyne RS-78 TWR of 40.922454165373989865413878178138 { @mass = 0.293 } @PART[Size2LFB] //Twin Boar, based on SpaceX Merlin 1-C TWR of ~96 { @mass = 3.425 @RESOURCE[LiquidFuel] { @amount = 14400 @maxAmount = 14400 } @RESOURCE[Oxidizer] { @amount = 17600 @maxAmount = 17600 } } @PART[Size3AdvancedEngine] //Rhino, based on Merlin 1-D Vacuum TWR of ~150 { @mass = 1.334 } @PART[Size3EngineCluster] //Mammoth, based on F-1 Cluster TWR of 94.0680252651651 { @mass = 4.252 } @PART[smallRadialEngine] //Twitch, based on Rocketdyne ATE TWR of 35.1506204084502 { @mass = 0.045 } @PART[toroidalAerospike] //Aerospike, based on proposed US Air Force Institute of Technology DEAN TWR of ~106.5 { @mass = 0.106 } Kerbal Fuels is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) license.

Click the launch center icon in the upper-right corner, then click a magnifying glass next to a center to move the camera to it and the center name itself to designate it. On-globe site icons don't show up and one or two are underground, but most of them seem to be more or less functional (Australia, Cape Canaveral, that equatorial ESA site mostly run by the French, Vostok, Yukon seem OK from my usage).

I'm not sure if this is supposed to be the case or if something's gone awry with patching, but several engines seem to be either missing part or all of their texture, if such a thing's even possible: the NK-33, NK-43 and the entire RD- series all look like their textures aren't loading properly and their primary bodies are just a flat white, though some do have coloring for things like tank connection rings and certain hoses. Afraid I can't provide a picture at this time since I'm running openGL which doesn't seem to like PrtScrn grabs in the slightest and KSP keeps crashing when I try to set up a good shot of an engine totem. EDIT: And of course I realize right as I get a reply that (A) the parts in question aren't modmanager'd KWR parts like I thought they were, and ( the dude apparently didn't do an actual texture for them.

And such was said of the Skyrim modding community, I'm sure, and yet here we are bearing witness to people charging $5 for incomplete fishing mods less than a day out of the gate.

I'm sure many users have already heard the news, but to recap: Valve just unveiled a Paid Workshop function for Steam whereby people who upload content to workshops can now charge actual realworld money for them. Currently it's in play for the Skyrim workshop, but there's no reason to believe other publishers and developers won't be quick to jump on the bandwagon. It's also having as big a backlash as one might expect of such and has stirred up a massive debate about both the feasibility and, for lack of a better term, ethics of the idea. Considering there's been plenty of discussion about whether or not KSP could someday get its own Steam workshop, I think this merits a question put towards Squad with a request for a very clear answer: in the event that Kerbal Space Program does gain Steam workshop functionality, and that as of such time publishers and developers have the option of allowing users to charge for access to their workshop items, would you allow such monetization of the Kerbal Space Program workshop? Yes or No? If you answer "Yes" to the previous question, then please answer the following question: what percent, out of 100% total, would you delegate to the user as their cut of the item's sale? For reference, Bethesda is giving workshop uploaders 25% of all workshop item sales.

I'm not so sure this passed through the update completely unscathed. Decided to blow a few days grabbing low and high-orbit gravity scans and whatnot, and after farting around in low orbit for an hour things worked well enough. Went to high orbit, sped through about 30 hours - and got hit with a massive 115-report sciencesplosion the second I dropped out of timewarp, including a whole crapload of reports you can only get from being landed on the surface, many of which were also things I'd already cleared out. Went back to KSC, was coming in for landing - and got hit with *another* one right on my final approach. Don't think I can get anything useful from the log, unfortunately, since 99% of it's For Science firing off about no science or experiments being available.

Oh wow, the part subtype switching is absolutely fantastic: no more having to wade through a sea of varient configs each for a different resource. I did notice, though, that while there're setups for LF, LFO and Monoprop it doesn't cover XenonGas and ElectricCharge. Quite a few mods make Xenon-fueled drives more appealing and it'd suck to shut them out, and being able to store power without slapping a bunch of ugly batteries on the exterior would be nice.

Hmm. Is science supposed to be locked into the part once it gets hoovered up from experiments? Like others I snagged this since I figured it'd make doing science sweeps much easier - but after doing so, I found out I couldn't retrieve it from the part via right-click, and my research vehicle is a separate one from my return vehicle. EDIT: OK, after whipping up a ModuleManager config to insert the collection script into cockpits, it seems you can nab those on EVA even if not from the science parts themselves. Maybe a better way to go about this would be to just insert the manual collection script into cockpits and then only have new parts for automatic collection, which some folks might not even want?

Oh man, I discovered a bug in the most neat-ass way. Was sending a blimp-based whor-er, science lab to Duna and had the return stage mounted under it, and decided to snag an EVA report on the way down - except I had both passengers in the lab module and nobody in the lander can on the return vehicle and forgot about it. Lo and behold, after mashing the EVA button a few times someone finally came out - of the lander, while two other folks were in the lab. The first occupant of the science lab got cloned and punted out the lander can's hatch, and now it's Bob, Andrew and Anti-Andrew figuring out what to do.

Not really knowledgeable about all this community development stuff, so I'll just drop this off here and the Procedural parts thread: a config file for procedural Karbonite tanks that gets preeeeeeetty darn close to mod-stock mass and volume values. Only thing it's lacking is one of those [Need] triggers that hides it if you don't have a certain mod/part installed since I couldn't nail down a functional one for all get. PART { // --- general parameters --- name = proceduralTankKarbonite module = Part author = AncientGammoner, NathanKell, Swamp Ig, OtherBarry // --- asset parameters --- MODEL { model = ProceduralParts/Parts/cylinderTank scale = 1,1,1 } scale = 1 rescaleFactor = 1 // --- node definitions --- node_stack_top=0,0.5,0,0,1,0,1 node_stack_bottom=0,-0.5,0,0,-1,0,1 node_attach=0,0,0.5,0,0,-1,1 // --- editor parameters --- cost = 4000 TechRequired = heavyRocketry entryCost = 4000 category = Propulsion subcategory = 0 title = Procedural Karbonite Tank manufacturer = Kerbchem Industries description = Made from viscoelastic nanopolymers (which were discovered by accident... growing in the back of the office mini-fridge) this fuel tank can be stretched to accommodate Karbonite in a range of sizes and shapes. Hardens to a rigid structure before launch! // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 1.2 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 1 crashTolerance = 12 breakingForce = 500 breakingTorque = 500 maxTemp = 3200 MODULE { name = ProceduralPart textureSet = OrangeSides TECHLIMIT { name = start diameterMin = 1.0 diameterMax = 1.5 lengthMin = 1.0 lengthMax = 2.0 volumeMin = 1.5 volumeMax = 3.0 } TECHLIMIT { name = heavyRocketry diameterMax = 3.0 volumeMax = 35.0 lengthMax = 7.5 } TECHLIMIT { // Make everything unlimited for metaMaterials name = metaMaterials diameterMin = 0.01 diameterMax = Infinity lengthMin = 0.01 lengthMax = Infinity volumeMin = 0.01 volumeMax = Infinity } } MODULE { name = ProceduralShapeCylinder displayName = Cylinder techRequired = start length = 1.00 diameter = 1.25 } MODULE { name = ProceduralShapeCone displayName = Cone techRequired = generalConstruction length = 1.0 topDiameter = 0.625 bottomDiameter = 1.25 } MODULE { name = ProceduralShapePill displayName = Fillet Cylinder techRequired = advConstruction length = 1.0 diameter = 1.25 fillet = 0.25 } MODULE { name = ProceduralShapeBezierCone displayName = Smooth Cone techRequired = advConstruction length = 1.0 topDiameter = 0.625 bottomDiameter = 1.25 } MODULE { name = TankContentSwitcher useVolume = true TANK_TYPE_OPTION { name = Karbonite // This is the dry mass of the tank per kL of volume. dryDensity = 0.108 RESOURCE { name = Karbonite unitsPerKL = 173 forceEmpty = true } } } }

Where did you have to sign in to download? Opening the link just opens up the file dump, click on a file tile, boom, download prompt.

I've been trying to get SCANSat to work with TweakScale, and since search isn't being helpful as to whether it's something in SCANSat itself or me hosing something up file-side figured I may as well ask here. Added the function to ScaleExponents: TWEAKSCALEEXPONENTS { name = SCANsat max_alt = 3; best_alt = 3; power = 3; } and duped and formatted a part configuration file: @PART[SCANSat_Scanner] // SCAN RADAR Altimetry Sensor { MODULE { name = TweakScale type = surface } } @PART[SCANSat_Scanner2] // SCAN SAR Altimetry Sensor { MODULE { name = TweakScale type = surface } } @PART[SCANSat_Scanner24] // SCAN Multispectral Sensor { MODULE { name = TweakScale type = surface } } @PART[SCANSat_Scanner32] // SCAN Been There Done That® { MODULE { name = TweakScale type = surface } } but no dice. EDIT: Of all the stupid crap to get caught on, it's letter case. :facepalm: Well, thanks for spotting that.

Howdy. I've been on a part purge kick recently thanks to discovering Procedural Parts which lets me dump all the crappy and bloated stock and mod-packed fuel tanks and whatnot, but since PP doesn't have a config file for Interstellar stuff I decided to whip one up. I'm guessing there's got to be at least a few other folks who run PP+Interstellar, so this might be useful for anyone who's wanted modular in-line tanks for resources: PART:NEEDS[Launchpad] { // --- general parameters --- name = proceduralTankInterstellar module = Part author = AncientGammoner, NathanKell, Swamp Ig, OtherBarry // --- asset parameters --- MODEL { model = ProceduralParts/Parts/cylinderTank scale = 1,1,1 } scale = 1 rescaleFactor = 1 // --- node definitions --- node_stack_top=0,0.5,0,0,1,0,1 node_stack_bottom=0,-0.5,0,0,-1,0,1 node_attach=0,0,0.5,0,0,-1,1 // --- editor parameters --- cost = 4000 TechRequired = nuclearPropulsion entryCost = 4000 category = Propulsion subcategory = 0 title = Procedural Interstellar Tank manufacturer = Kerbchem Industries description = Made from viscoelastic nanopolymers (which were discovered by accident... growing in the back of the office mini-fridge) this fuel tank can be stretched to accommodate rocket construction materials in a range of sizes and shapes. Hardens to a rigid structure before launch! // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0.2 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 3 crashTolerance = 6 breakingForce = 300 breakingTorque = 300 maxTemp = 2900 MODULE { name = ProceduralPart TECHLIMIT { name = survivability diameterMin = 0.1 diameterMax = 1.5 lengthMin = 0.1 lengthMax = 0.5 volumeMin = 0.1 volumeMax = 1.0 } TECHLIMIT { name = advRocketry diameterMax = 3.0 volumeMax = 15.0 lengthMax = 5.0 } TECHLIMIT { // Make everything unlimited for metaMaterials name = metaMaterials diameterMin = 0.01 diameterMax = Infinity lengthMin = 0.01 lengthMax = Infinity volumeMin = 0.01 volumeMax = Infinity } } MODULE { name = ProceduralShapeCylinder displayName = Cylinder techRequired = start length = 1.0 diameter = 1.25 } MODULE { name = ProceduralShapeCone displayName = Cone techRequired = generalConstruction length = 1.0 topDiameter = 0.625 bottomDiameter = 1.25 } MODULE { name = ProceduralShapePill displayName = Fillet Cylinder techRequired = advConstruction length = 1.0 diameter = 1.25 fillet = 0.25 } MODULE { name = ProceduralShapeBezierCone displayName = Smooth Cone techRequired = advConstruction length = 1.0 topDiameter = 0.625 bottomDiameter = 1.25 } MODULE { name = TankContentSwitcher useVolume = true TANK_TYPE_OPTION { name = Deuterium // This is the dry mass of the tank per kL of volume. dryDensity = 0.15 RESOURCE { name = Deuterium unitsPerKL = 200 } } TANK_TYPE_OPTION { name = Tritium // This is the dry mass of the tank per kL of volume. dryDensity = 0.15 RESOURCE { name = Tritium unitsPerKL = 200 forceEmpty = true } } TANK_TYPE_OPTION { name = Deuterium-Tritium // This is the dry mass of the tank per kL of volume. dryDensity = 0.15 RESOURCE { name = Deuterium unitsPerKL = 100 } RESOURCE { name = Tritium unitsPerKL = 100 forceEmpty = true } } TANK_TYPE_OPTION { name = Helium-3 // This is the dry mass of the tank per kL of volume. dryDensity = 0.15 RESOURCE { name = Helium-3 unitsPerKL = 200 forceEmpty = true } } TANK_TYPE_OPTION { name = Lithium // This is the dry mass of the tank per kL of volume. dryDensity = 0.15 RESOURCE { name = Lithium unitsPerKL = 1000 } } TANK_TYPE_OPTION { name = Thorium Tetrafluoride // This is the dry mass of the tank per kL of volume. dryDensity = 0.15 RESOURCE { name = ThF4 unitsPerKL = 800 } } TANK_TYPE_OPTION { name = Uranium Tetrafluoride // This is the dry mass of the tank per kL of volume. dryDensity = 0.15 RESOURCE { name = UF4 unitsPerKL = 800 } } TANK_TYPE_OPTION { name = Uranium Nitride // This is the dry mass of the tank per kL of volume. dryDensity = 0.15 RESOURCE { name = UraniumNitride unitsPerKL = 10 } } } } It's a bit shaky and relies on a lot of eyeballed guesstimations (I'm guessing the radial tanks are .625x3m, rounding to 1,000 liters for simplicity) and doesn't yet have some of the other stuff like argon, ammonia, methane/methalox and water, but I figure this might be of interest for anyone who prefers in-line tanks instead of radial or wants to ship a crapton of stuff without a billion parts.

I had a feeling a rounding issue or something of that type was the case given the diminishing returns aspect you see in a lot of the higher-end experiments. I'd tweaked sciencedefs.cfg to equalize basevalue and sciencecap (repetition's necessary in reality, but doesn't make for the best of gameplay) but had already done several beforehand which probably led to some hidden far-flung value that kept hootin' and hollerin'. Idiotproofing is just as much a part of development as bughunting, I suppose. What about looking at the potential return of a given experiment type and setting the "not maxed" filter such that it acts more as a "99% researched" or "<0.1 science" filter? That should knock out most stuff by the third or so repetition of the experiment but would also leave a bit of wiggle room for high-payout stuff like experiments on Eeloo or Moho. EDIT: <90% still gives repeated reports, but <50 got it to settle down although that leaves a huuuuuge hole of science that'll be ignored after the first pass with some stuff.

Debug dump: [Log]: ScienceAlert, Dumping all science found in 24 containers aboard XSP-4 Gravity Scanner [Log]: ScienceAlert, gravityScan@MinmusInSpaceLowSlopes - Gravity Scan from space just above Minmus's Slopes [Log]: ScienceAlert, gravityScan@MinmusInSpaceLowMidlands - Gravity Scan from space just above Minmus's Midlands [Log]: ScienceAlert, gravityScan@MinmusInSpaceLowMidlands - Gravity Scan from space just above Minmus's Midlands [Log]: ScienceAlert, gravityScan@MinmusInSpaceLowHighlands - Gravity Scan from space just above Minmus's Highlands [Log]: ScienceAlert, gravityScan@MinmusInSpaceLowSlopes - Gravity Scan from space just above Minmus's Slopes [Log]: ScienceAlert, gravityScan@MinmusInSpaceLowHighlands - Gravity Scan from space just above Minmus's Highlands [Log]: ScienceAlert, gravityScan@MinmusInSpaceLowMidlands - Gravity Scan from space just above Minmus's Midlands [Log]: ScienceAlert, gravityScan@MinmusInSpaceLowSlopes - Gravity Scan from space just above Minmus's Slopes [Log]: ScienceAlert, gravityScan@MinmusInSpaceLowMidlands - Gravity Scan from space just above Minmus's Midlands [Log]: ScienceAlert, gravityScan@MinmusInSpaceLowSlopes - Gravity Scan from space just above Minmus's Slopes [Log]: ScienceAlert, End science dump. [Warning]: ScienceAlert, Current eva situation: evaReport@MinmusInSpaceLowSlopes, science 32 [Log]: ScienceAlert, There are 2 total transmitters - 1 real, 1 magic [Log]: ScienceAlert, MagicDataTransmitter probeCoreOcto_4294370598 has 0 queued transmissions Settings.cfg dump: GeneralSettings { SaveFlightSessionManeuverNodes = True FlaskAnimationEnabled = True SoundOnNewResearch = True StarFlaskFrameRate = 24 EvaAtmosPressureThreshold = 0.00035 EvaAtmosVelocityThreshold = 30 DebugMode = True } ExperimentSettings { asteroidSample { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = Unresearched IsDefault = True } SCANsatAltimetryLoRes { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = Unresearched IsDefault = False } SCANsatAltimetryHiRes { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = Unresearched IsDefault = False } SCANsatBiomeAnomaly { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = Unresearched IsDefault = False } crewReport { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = True AssumeOnboard = False Filter = NotMaxed IsDefault = True } evaReport { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = True AssumeOnboard = False Filter = NotMaxed IsDefault = True } mysteryGoo { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = NotMaxed IsDefault = True } surfaceSample { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = Unresearched IsDefault = True } mobileMaterialsLab { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = NotMaxed IsDefault = True } temperatureScan { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = NotMaxed IsDefault = True } barometerScan { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = NotMaxed IsDefault = True } seismicScan { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = NotMaxed IsDefault = True } gravityScan { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = True AssumeOnboard = False Filter = NotMaxed IsDefault = True } atmosphereAnalysis { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = NotMaxed IsDefault = True } magnetosphericExperiment { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = NotMaxed IsDefault = False } gasChromotographyMassSpectrometryExperiment { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = NotMaxed IsDefault = False } FNSeismicProbeExperiment { Enabled = True SoundOnDiscovery = True AnimationOnDiscovery = True StopWarpOnDiscovery = False AssumeOnboard = False Filter = Unresearched IsDefault = False } } AudioSettings { bubbles { Enabled = True MinDelay = 2 } click1 { Enabled = True MinDelay = 0 } click2 { Enabled = True MinDelay = 0 } } Quicksave (though it's a mutated hodgepodge of mods, so I'm not sure if there's anything to be gleaned from this): https://www.dropbox.com/s/5gjxb92gn4skbwv/quicksave.7z Quicksave from a new game with only ScienceAlert and Mechjeb, same problem and same approximate conditions: https://www.dropbox.com/s/iae89souo1r3wcw/quicksave2.7z