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.

One problem as far as mass producing liquid hydrogen, especially with realistic settings: according to my tests and reading of the USI_Converter code, the catchup code fires once on the first physic step after the craft is loaded per converter. This means that when the converter is updated it splits water until oxygen storage fills, since the valve doesn't get a processing step to catch up even if it did have catchup code, which it doesn't, it generates this much Hydrogen, or at least as much as fits in immediate storage and vents the rest, and that is all. Then the compressor fires in one go and produces only as much Liquid Hydrogen as there was Hydrogen present at that point. Or the other way depending on how the parts get ordered. Either way, to produce 16 tons of Liquid Hydrogen "off screen" in one go you need 16 tons of Hydrogen storage and 128 tons of Oxygen storage, which is not practical. And you can't do it on screen even if you didn't want to do anything else during that time, because as time step goes the EC ticks get too large for any sane battery setups. My suggestion is to declare that the large part is dedicated for Liquid Hydrogen production and make it generate (mass appropriate) Liquid Hydrogen directly, and automatically vent Oxygen and stop when LH is full. Who would need that much Oxygen anyway? Maybe also add a decompression mode for the Hydrogen container, to make the conversion two way?

I used numbers from the CommunityResourcePack. Note that the "density" parameters is actually mass per unit of resource in tons, not mass per unit of volume, because KSP doesn't care about resource volumes. I think Universal Storage defines Hydrogen the same way.

Those numbers were in line with Universal Storage, there were fuel cell numbers inverted plus I think ten percent energy loss. The thing is that you need orders of magnitude more hydrogen for nuclear propulsion than for the fuel cell, which means that you would need hundreds of Elektron parts to make enough in reasonable time. If the new electrolyser is not at least hundred times more powerful than Elektron then it still wouldn't be very useful for producing liquid hydrogen for propulsion purposes. Which is where the thousands of ECs per second come from. I have logged an issue on USI Github about that, it seems there was supposed to be a modifier for electricity, where no matter how long the delta is always counted as at most one second, but there is a Math.Max instead of Math.Min. So you still need enough capacity to hold as much as is produced by all reactors for a full physics step, so it breaks at high warps. It is possible something else was wrong when I tested it with the vessel not loaded. Unfortunately, I don't know enough about how KSP processes event to know how the catchup code is exactly, or enough about building mods to test it myself. I still think that fully mass conserving ratio is the only proper one (~4450:1). Magic resources are all very well, but increasing mass of the vessel by pumping stuff around just seem weird.

After some testing this is not going to work, because KSP can't handle parts consuming multiple thousands of EC under high warps without having really unreasonable amounts of batteries, and it doesn't seem to work with the vessel unfocused either. Even with both generators (FFT generators) and consumers being USI_Converters. Actually looking at the source, there might be a straight up bug in USI_Converter.cs... I will log a github issue.

I just looked it up on Wikipedia ( http://en.wikipedia.org/wiki/Electrolysis_of_water#Efficiency ). 237kJ per mole (for water ~18grams) is a thermodynamic lower bound, any real system would use more. I have typically seen 1EC=1kJ, but that seems to be a very rough approximation. It more or less works out between solar panels and lights and so on. The problem with electrolysis is you cannot simply use the standard KSP "witchcraft" solution (see description for stock ion engines, which consume way less power than they should), because of the Universal Storage Fuel Cell. If you produce oxygen and hydrogen using less energy than the fuel cell produces from the same oxygen and hydrogen you can get infinite power from nowhere. If you ignore what the "real" energy cost is and use that as a bound, for the fuel cell you get 1.78e8 EC units per ton of hydrogen. So you would need 2.85e9 for 16 tons. (Unless I miscounted something) Near Future and Freight Transport Technologies nuclear reactors have output in the several thousand range, with the Starlifter reactor giving 10000 EC per second. So with a single one you could generate 16 tons of hydrogen in eighty hours, which seems actually reasonable. Edit: something seems wrong after all, maybe this time I lost a bunch of orders of magnitude... Yes, actual numbers seem to be: 2.75e9 per ton, 4.4e10 for 16 tons, 1222 hours (50 earth days) at 10000EC/s which is not that terrible still.

Unfortunately I'm pretty sure Newnard moved the decimal point the wrong way when calculating the mass per unit for Hydrogen, so with that the compressor will be magically getting a kilogram of LiquidHydrogen from every five grams of Hydrogen, which is probably going to strain even the most flexible suspension of disbelief. The actual problem is not really mass ratios, but rates and electric consumption. Water electrolysis is quite power consuming, and splitting enough water (144000 units, 144 tons) to get 40000 units of liquid hydrogen (16 tons) will realistically require power in the range of terajoules (it takes more than 237kJ per 18 grams to split water).

I calculated the mass ratios with CRP numbers and that is what I got. Where did the 851 number came from, because I am seeing about 4449? water hydrogen liquidhydrogen oxygen density (tons per unit from CRP) 0.0010000000 0.0000000899 0.0004000000 0.0000014100 units per ton 1000.0000000000 11123470.5228031000 2500.0000000000 709219.8581560280 kg per unit 1.0000000000 0.0000899000 0.4000000000 0.0014100000 ratio in water 1.0000000000 0.1111111111 0.1111111111 0.8888888889 kg per 1 water unit 1.0000000000 0.1111111111 0.1111111111 0.8888888889 units per 1 water unit 1 1235.9411692004 0.2777777778 630.4176516942 electrolyzer 0.0000176697 0.0219907427 0.0109953713 normalized 1.0000000000 1244.5453346690 622.2726645048 compressor 851.0000000000 1.0000000000 normalized 1235.9411692004 1.4523397993 should be? 4449.3882091213 1

The plugin creates a "presets.cfg" file which KSP tries to load on next startup and fails, getting stuck on loading screen. You might want to use a different file extension.

I tried Kerbin anomaly contract again in 0.8.5(.1) and it still doesn't work. The log shows, if I understand it correctly, that the anomaly is 47 million meters away, which is about how far away Minmus is, but the contract clearly says "Kerbin's surface".

I have been trying anomaly research contracts, which are a really neat idea, but I have trouble completing them. On Kerbin the atmosphere means than any space experiments need to be done at least 70 km up and I didn't get the on screen message at all, which from looking at the code should appear no matter the horizontal distance for the proper experiment below hundred kilometers. The anomaly detector experiment registered correctly when flying low over the thing, though. Another problem, although not a fatal one, for a Minmus anomaly the message did appear and said the data was recorded, but didn't count for contract completion apparently because I was too high. If this is an actual condition the contract terms and the message should reflect that.