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.