Ramarren

To be more exact, the file GameData/OPM/KarboniteConfigs/MetalOre.cfg contains definitions for MetalOre, which is a resource specific to ExtraplanetaryLaunchpads. If that is not installed for whatever reason KerbNet breaks. Deleting MetalOre.cfg resolves that problem. Presumable the same applies for the whole folder if CRP is not installed. I have also put planet maps under PluginData and adjusted the paths to point to them which resolved the texture load warning, but I think that was mostly harmless - the loader for planet maps is different than the main loader, which can't load grayscale textures. Other than that so far everything seems fine.

Through the scientific process of deleting things at random I have determined that KerbNet in 1.3 is being broken by something in GameData\OPM\KarboniteConfigs , which I presume are out of date with current Community Resource Pack or something.

I found a weird bug, and narrowing it to this mod took a bit of time. For some reason Pilot Assistant is preventing "Launch our first vessel" contract from registering when active. It works fine when paused with Tab, but the contract doesn't trigger otherwise, even if no other control mode is active.

The rebooted version doesn't work for me, I tried it on clean install of KSP 1.0.5 from Steam with no other mods, just the EnvironmentalVisualEnhancements and BoulderCo directories, there are no clouds in the menu and in the Space Center screen the terrain doesn't load at all. KSP.log here: https://gist.github.com/anonymous/f9bbd11bed5f7c0b8acb , something seems wrong with shaders? If it works for other people then I guess I must have messed something up in installation, but what?

I replied there but for completeness: KSP is case sensitive about field names, and FTT cargo pods have 'moduleId' field instead of 'moduleID' field as they should have, which leads to problems as described with symmetry parts.

Application to first tank was fixed 22 days ago, and the version including it should be in the main Firespitter repository. -- Regarding the symmetry issue: actually, the plugin works fine, but KSP is case sensitive about field names, and a bunch of parts with multiple FStextureSwitch2 have a field 'moduleId' instead of 'moduleID' as they should be (note 'd'/'D'). So the texture switch is applied to all texture switches in symmetry parts.

What are you trying to dock to what? I remember reading somewhere that HX docking ports will only dock to themselves, ie. both ports have to be the exact same part.

With the newest Firespitter from GitHub you can use initialResourceAmounts field to define initial resource amounts.

In the log you seem to have two copies of Firespitter.dll : AssemblyLoader: Loading assembly at D:\KSP.9\GameData\Firespitter\Plugins\Firespitter.dll ... AssemblyLoader: Loading assembly at D:\KSP.9\GameData\KerbalJointReinforcement\Firespitter\Plugins\Firespitter.dll This will not work, especially if they are different versions.

My post with a proposed fix for this exact issue is literally right above yours. Come on, it is not even behind a page break or anything. HX parts have the NodeToggle module, which you can tell because you can toggle nodes on them.

I found what made NodeToggle cause ships to fall apart, there was an unhandled exception in OnStart outside the editor which actually made the parts lose all physics. I tried fixing it: https://github.com/Ramarren/Virgin-Kalactic/commit/55045c7649021fdc0d5513cf9df461237c5d8e08 , recompiled dll here: https://github.com/Ramarren/Virgin-Kalactic/blob/55045c7649021fdc0d5513cf9df461237c5d8e08/GameData/Virgin%20Kalactic/VirginGeneric.dll?raw=true . Seems to work after few minutes of testing, but no guarantees.

The ratio is directly copied from Universal Storage Elektron part, just with bigger multiplier. According to that thread Universal Storage uses 1EC=33J. Which unfortunately is indeed completely different than what seems to be used by nuclear reactor mods.

The way KSP handles resources is badly suited to model electricity. The only way to get anything like the actually defined efficiency from the splitters requires two things: 1) electric generator based on USI_Converter, like nuclear reactors from http://forum.kerbalspaceprogram.com/threads/91706-0-25-Freight-Transport-Technologies-v0-2-4-2014-11-01 2) not have the craft loaded at any time when the time acceleration is above x100 or so Any stock EC source or Near Future reactors won't work, because they don't have catchup code to generate surplus electricity to be consumed by the water splitter USI_Converter after the craft is loaded. So it will just convert as much as it can from batteries and then stop. Having the craft loaded at high time acceleration will have a typical KSP EC problem: the generator will produce as much EC as it produces multiplied by the time step, which will overflow the batteries and be lost, and then the converter will try to consume EC multiplied by the time step, which will not be available in batteries (unless you have billions/trillions of ECs of storage). So it will actually work at the fraction of capacity equal to (battery storage)/(consumption rate*time step). There is some magic in USI_Converter to work around that, but it is either broken or I misunderstand it, it doesn't work in any case. If you actually sat there for a day at 1x time speed it would actually split much more than 2l of water (about 50l at 2000 EC/s for six hour Kerbin day).

I am confused. Using numbers straight from the config file, and I am reasonable sure that the rates are per second, which seems to agree with the resource panel display, I get 100931048 units of Oxygen produced in 248*24*3600 seconds for three 2.5 converters, which adds up to more than 142 tons of oxygen. I'm pretty sure that is not the usual amount of storage for oxygen a vessel is expected to have. I know that in my test case I have filled a single large TACLS oxygen container in much less than ten earth days. Am I missing something here? [TABLE] [TR] [TD=align: right] [/TD] [/TR] [/TABLE] More fundamentally, what is the reasoning for limiting the 2.5 converter on oxygen, not hydrogen? For the the Elektron wedge and perhaps the small converter it makes perfect sense, since they are meant to potentially work as part of the life support cycle, and you don't want to be losing breathable oxygen in space, but when processing hundreds kilograms of water per day the only purpose I can think of is producing propulsion hydrogen, in which case you don't want to lose hydrogen, and do want to vent oxygen. Is there some purpose for multiple tons of oxygen I am not aware of?

Oh right, I did miss that in the code. So that is not actually the problem, my problem was just from the Oxygen storage filling up; the valve from Smart Parts doesn't have catchup code.