jinks

No worries, I'll play with it when it's ready. Shouldn't be too hard I hope. We'll have to see. Oh, there's more. At them moment it's relatively easy to game the system. I'll shoot you a pull request when git is up. EDIT: I might be getting ahead of myself, but what do you think about these as Toolbar icons?

Yeah, the texture files are quite heavy. They're made with a really old copy of KSP, probably before .pngs were even an option. Like I said, I didn't make them, I just updated the .cfgs. I'll give a converted version a try. This one's just 2.4MB, but I have no idea if it'll actually save memory. Nonetheless pngs are probably easier to work with if someone want to reduce the textures. Get it from GitHub or Curse.

Howdy! A few requests: Could you put up the source on your github repo? I'm not gonna yell at you about the forum rules requiring it. But from the LICENSE.md I assume you intend to release under GPL3 and I'd really like to play around with the code a bit (e.g. option Toobar integration). I think you need to set a few more resources to "unlimited" for the marketplace. Right now one can easily plonk a few dozen Helium Cryostats on the pad, empty them out and buy tons of antimatter and/or HE-3. (Yes, I know it's configurable, but I'm a strong believer in sane defaults. )

Isn't that how it was before? To be honest, I believe the version suggested by Fraz86 (no implicit passability / every passable node configured explicitly) looks the most correct / intuitive. It requires a bit more work up front, but adding CLS configs for mods is quite simple in itself.

ARGH! A simple typo! I checked the structure of the .cfg a dozen times, but I never bothered to actually read the words. Thank you!

Just replicated this with only KSPI on a clean install (I even left out ModuleManager, since it dosen't do anything with the core). Pictures from the VAB: I have no idea where to look any more. Is nobody else seeing this with WaveFunctionP's version?

Sorry you two, I left out one crucial bit of information it seems: I get NaN/0.0 for ECs (which is not ORS managed btw.) directly in the VAB for every Core I place, apparently it never even gets the correct value from the part. (Correct me if I'm wrong, but I assume that since the part is correct in the Debug Menu this is not a MM issue, right?) Will do more debugging as soon as find time.

I seem to have a problem with the Computer Core. No matter what I do, the Electric Charge is set to NaN/0.0. I checked the part.cfg, the config as seen in the Debug Menu (both say 1000/1000) and all the logs, there's no indication why the settings aren't accepted. I'm using WaveFunctionP's experimental version. Any ideas?

Just to clarify: The Top post links to a Modulemanager-2.1.0.dll, sarbian's latest post links to Modulemanager-2.0.10.dll. Are those the same files?

Can you give a bit more detail on this? I don't really understand what the issue is and if/how this affects me as a user. Why would not reordering modules (I assume you mean MODULE{} sections on parts) break my save? I have mostly MM configs which add MODULE sections, maybe a few @MODULE which modify specific lines. What should I expect to break and how will it manifest itself?

With 2.1.0 I get a NRE right after MM has identified all loaded DLLs: [LOG 02:51:28.825] [ModuleManager] compiling list of loaded mods... Mod DLLs found: Assembly-CSharp v1.0.0.0 ModuleManager v2.1.0.0 aaa_Toolbar v1.0.0.0 ActionGroupManager v0.0.0.0 <...snip...> Non-DLL mods added: [LOG 02:51:28.973] [ModuleManager] Exception while checking needs : LLL-Extra/Parts/fuelLowerstage/part/fuelLowerstage System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (.ConfigNode node) [0x00000] in <filename unknown>:0 at ConfigNode.CopyToRecursive (.ConfigNode node) [0x00000] in <filename unknown>:0 at ConfigNode.CopyTo (.ConfigNode node) [0x00000] in <filename unknown>:0 at ModuleManager.ConfigManager.CheckNeeds (.ConfigNode subMod) [0x00000] in <filename unknown>:0 at ModuleManager.ConfigManager.CheckNeeds (System.Collections.Generic.List`1 excludePaths) [0x00000] in <filename unknown>:0 [LOG 02:51:29.075] [ModuleManager] :FIRST (default) pass The part is the "Cellular fuel tank" from LLL_Full's extra pack. The cause seems to be in this section: PART { name = fuelLowerstage module = Part author = Lack //MODEL { model = Squad/Parts/Structural/structuralIBeam3/model position = 0,0.00,-0 scale = 1,0.8,1 rotation = 0,0,0 } MODEL <...snip...> As you can see, Lack has "disabled" one MODEL section by commenting out the header, so I assume MM can't handle a body without a header any more. Is this considered a bug or "WONTFIX, tell Lack to fix his damn parts"?

Probably not, there have been no changes to that part of the code.

Define official. The original author hasn't been seen since January, so agises and I made some modifications to keep this thing alive and released them. When/if Jarcikon comes back we'll see what happens, otherwise I'll probably just continue keeping my fork in (mostly) working order. Targetron opening itself upon vessel load has been like that for quite a while. Maybe I'll look into it at some point but no promises, I'm just the janitor. The filter list persists fine for me, though.

What the heck are BOMPs? Bolt-On Mission Probes are unmanned command modules or probe cores. They have been created by Ted in a time when the currently available probe cores didn't yet exist. Since then they have kind of fallen by the wayside. Ted is certainly occupied with his job as QA Lead at Squad and when stock probe cores were added, BOMPs weren't needed so sorely any more. When partconfigs got updated, KSP gained features and the landscape changed, BOMPs stopped working. Updating the config files to make them compatible with 0.23.5 wasn't such a big deal, but I didn't want to keep them all to myself. So I contacted Ted to ask him if I could redistribute them, and he informed me that they were originally released under CC-BY-NC-SA 4.0. That was great news and I can now present to you all a revived and 0.23.5+ compatible set of BOMPs. The stats are pretty much in line with the stock probe cores. Why would I use a BOMP instead of a standard probe core? You remember them from when they were the only option and are a bit nostalgic. You think they are prettier than the standard probe cores. (Hint: They are!) You need a 3.75m stack probe core. You just feel like it. Where can I get my very own set of BOMPs? Download the latest release over at GitHub: BOMPs-0.90.0.zip Curse: BOMPs KerbalStuff: BOMPs What does a BOMP look like? From left to right: BOMP-XL (3.75m), BOMP-L (2.5m), BOMP-Mini (1.25m), BOMP-Nano (0.625m). Enjoy!

Hiya folks! agises has given the code a thorough workover and so I get to release an all-new shiny Targetron 1.4.1 He has cleaned up the GUI code a lot and fixed a few bugs in the process. Switching ships via right-click context menu now works again and we get the old skin back without it interfering with other mods. So, a big Thank you! to you, agises, and everyone else enjoy the new version. Download: Targetron 1.4.1. Source (github) Changelog: 2014-04-24 (1.4.1) agises * fix gui skin issue * code cleanup A question for all of you: I'm now a little torn between the two GUI options. I'm not sure what I like better visually, so voice your opinion.

I actually like KSPI mostly the way it is. Will you still maintain your experimental tree with community-fixes and interim improvements? I kinda rely on you to integrate Fractal's releases into a sane git-tree. (Mostly because of the line-endings. Fractal pushes CRLF and on Linux I cannot autoconvert.)

YAY! More fixes Would you consider pulling this change into your repo: https://github.com/willglynn/KSPInterstellar/commit/c2885426618a505f4a4d1f3ecd17cffd154bfbec? It's a minor performance fix, but every bit helps.

Well, the code is actually pretty specific (see FNGenerator.OnFixedUpdate()): if (!chargedParticleMode) { [...] double thermal_power_currently_needed = electrical_power_currently_needed / totalEff; double thermaldt = Math.Max(Math.Min(maxThermalPower, thermal_power_currently_needed) * TimeWarp.fixedDeltaTime, 0.0); input_power = consumeFNResource(thermaldt, FNResourceManager.FNRESOURCE_THERMALPOWER); if (input_power < thermaldt) { input_power += consumeFNResource(thermaldt-input_power, FNResourceManager.FNRESOURCE_CHARGED_PARTICLES); } double wastedt = input_power * totalEff; [...] The question is: Is this intended behaviour or a remnant from before DC generators were around?

There's at least the KSPI Science Lab and the upcoming Modular Kolonization System which also take stupidity into account. I'm thinking about actually removing the ModuleManager config for workshops so I can use the stupid ones to pilot the braniacs around. That's a good idea, right? Dumbest guy sits at the controls, what could possibly go wrong?

Ok, that's where I went wrong then. I assumed that KTEC generators would completely ignore ChargedParticles the same way DC generators don't use ThermalPower. (Now that I know what to look for, it wasn't too hard to find the relevant place in the code ) Is this intended behaviour? My understanding was that the KTEC is a heat-exchanger, what would it do with ChargedParticles?

I seem to have some problems with the 0.4 version. No IVAs. They worked fine in 0.3, now they're not loading at all. If I leave a part via Crew Hatch, the game crashes and I get a bunch of NaN errors in the log. Note: I did not copy over the outdated FireSpitter.dll from the zip since I'm using FireSpitter in the most recent version. Maybe there is a conflict.

OK, I did a bit more generator testing, this time with the official 0.11 release. The problem only occurs with 2 generators (DC and KTEC) connected to the same reactor. It seems that the DC generator somehow "saps" thermal power from the KTEC. My test setup is a 2.5m Sethlans 2 fission reactor with one type of generator on each end. I get max power of 895 MW_e from the DC generator and 716 MW_e from the KTEC. Each generator separately actually supplies that power to the transmitter at 100%. If I turn on both generators at the same time, the DC one remains at peak output, but the KTEC drops to about 129 MW_e and I end up with a deficit in my supply to the transmitter. (In his particular setup I have to tweak down the transmitter to ~60% to not lose any power.) Since I could now confirm it in the official version: Fractal? Any idea?

Yeah, like I said, I just plopped in the fist config I found, needs tweaking. My goal for the part is to make it "not hard" without being outright cheaty. (All while keeping the part-count down and not requiring a ton of greenhouses to supply a medium-sized base. As an example eLpads wants 15 Kerbals for its workshop to be at peak efficiency and putting up 4 greenhouses is already quite a drain on parts considering what else you need for a eL base.)

The latter numbers concern just food, since that's the only thing the greenhouse is supposed to supply and you can get the other resources replenished already by other means. (I literally just stacked food containers until I got 5t and then divided the days of supply by 365 and that result by 4 (Kerbals)).

For anyone wanting to go the "other way around" (converting LqdWater to Water via water purifier) I posted a MM config over here. I prefer it myself because it's less invasive, but it comes with it's own caveats (the LqdWater routing).