Bluebottle

You might be using Linux, according to your sig. Have you checked the permissions on the UbioWelding directory/folder? If you unpacked the mod as the root user, your user won't have the ability to write anything in there.

Probably something that needs to be said more often: thanks so much for updating and maintaining all your mods. They're of the highest quality and I probably wouldn't still be playing KSP without them.

I ported a patch to add ZBO to Ven's CryoX tanks (from Stock Revamp) so that I could use them for high-temp situations such as aerobraking. It's a few pages back, is now out of date since the latest rebalance, and it was only for Interstellar Fuel Switch anyway. But there's nothing stopping you from doing something similar with Nertea's Cryotanks patch for MFT.

That's the idea. The dedicated tanks have slightly higher dry masses to simulate the equipment and insulation needed for zero-boil-off. The stock tanks lack that, so they're lighter. edit: oops. I don't know how MFT is supposed to work with ZBO.

OK. I'll try to wrestle the Unity Editor into working on Linux.

@taniwha I've been trying to use your plugin for some simple mesh modifications to some parts. Thank you for it. The import works fine, but I can never export. I get a shader error regarding MuMaterialProperties. This happens even when immediately exporting after importing. I have tested several different parts from different mods and get the same error. As you can see in my screenshot, the materials tab shows a correct setup (right?), and the materials are displayed in Blender (I read the thread ). I'm using Blender 2.69 on Ubuntu 14.04, if that's any help, and your 12/12/2015 plugin revision from Github.

Hehe, maybe! Thanks, at least I know it's probably something specific to my install. I also have issues with instant, massive structural failures/krakens when switching back to a vessel that is clawed to an asteroid. Haven't nailed down yet whether it's just good ol' claw krakens or PersistentRotation.

It's working, thanks. Great Mk2 parts too.

That's pretty much what I expected. I've never had any improvements come from deleting those MM cache/physics/techtree files though, or PartDatabase.cfg/Physics.cfg. The file that's disabling your EL parts will be a .cfg MM patch file somewhere under GameData, which is why a full-text search (grep) can help. But MM patches don't have to list the part name to alter a part: they can have search criteria based on the modules that a part uses, they can match on the name of a mod, and so on. Look here. You might even have another mod or patch that disables all other parts using ModuleResourceScanner with the MetalOre resource, for example. Why, I don't know, but it wouldn't surprise me that much. What you could do, although it's ham-fisted, is make a clean save of your game, quit, move any half of your mods out of GameData to somewhere temporary (leaving EL behind, of course), and restart KSP. Start a new sandbox game and check if all the EL parts are there or not. If not, swap out the other half of your mods from GameData, rinse/repeat, and continue until you narrow it down to which mod is causing trouble. Either that or you continue doing text searches. edit: actually, belay that. Search through your KSP.log for the OMD and Magnetometer because MM logs all its patching. Failing that, use the part database in the alt-F12 debug menu. I find it slow and difficult to find anything in, but YMMV.

OK, thanks. I searched through all my save files, and none had an odd map_width. Many instances of 636 and 1008. Although I can't reproduce it with SCANsat v14.8, the save that was causing the problems had a unique map_width of 616, i.e. across about 80 saves, that 616 was the only value that didn't occur in another save.

You're welcome. When you say "reinstall", do you mean that you first deleted all of the old files that grep told you about? The problem is most likely to be an outdated MM file that is lying around. Are you using CKAN? It takes a very conservative approach (i.e. don't delete user data) and won't delete files that aren't in its database. But that can leave 'cruft' behind. Also, the "MM files that contained them" you deleted were things like ModuleManager.ConfigCache, correct? Which .cfg files?

That's OK, I thought you might be new to it. 'grep' is a command that searches through files for the text you give it. "-r" makes it look through all subdirectories, i.e. recursive. The next parameter is the text to search for, and the last one is where you want it to search, so if you're in GameData, that would be "*" The EL parts you're looking for are, conveniently, called "OMD" and "Magnetometer". No prefixes or anything. So, in a terminal, without the quotes: "cd insert-path-of-your-GameData-directory-here" (you can press Tab to autocomplete) "grep -r OMD *" "grep -r Magnetometer *" Grep will tell you the path of the files it finds, and print the matching lines. There's likely some graphical utility in your desktop environment that could do the same job, but grep is always useful.

Try doing a recursive grep through your GameData directory to look for part names. Very useful for finding old and forgotten MM patches. For example, when I was searching for everything that touched the MRS quad-nuke engine, I ran this in a terminal, inside GameData: grep -r NB2mNuclearEngine * It's much faster and less frustrating than using the game's debug menus. Something you could use would be this example, to find every MM patch that alters the EL orbital dock: grep -r ExOrbitalDock *

I've been trying to replicate it again, but no luck so far. Where is the map size stored? If it's in the SFS file, I could pull it out of there. I think the sizes always reset, though, so probably not stored at all. Crudely cropping the screenshot shows that the map window's drawable area (not including the black border or the titlebar) was 1194 x 626. Complete window area (including borders and the titlebar) was 1198 x 643. No odd numbers for the width.

Thanks for the the rebalance (this and Cryo*), and especially for the updated NTR patches. I'd been maintaining my own set until now.

This is a great mod, and I agree with the asteroid rotation feature, but I've hit a problem with it. I docked a 500 ton ship, and a 200 ton torque probe, with a 280 ton class-D asteroid. 2000dV after grabbing the asteroid, too . I slowed the rotation to a dead stop. But the asteroid is acting like it has its own torque generator, and it keeps spinning up my ships, even with either SAS or MJ's kill-rotation activated. Effectively, the asteroid is operating as a perpetual motion machine, providing endless torque. It's practically impossible to redirect the asteroid without constant, extreme RCS usage, burning through 1000 monoprop in one minute. I even have to use Throttle-Controlled-Avionics because engine gimbals aren't enough when under acceleration and require inverted input for a pusher. So, is there any way to give asteroids an initial spin, but not continue applying that force after the first instantiation? Linux KSP 64-bit v1.0.5 (many, many mods), PersistentRotation v1.0.2 via CKAN.

Oh, and congratulations on joining the staff... now you (presumably) get paid for your hobby!

It happens with the biome map and the hi-res map, at least. I don't know how to show the low-res RADAR map after the hi-res one has been gathered. The map starts building and then dies just over halfway up. but... resizing the map works , although I had to resize the map window on another satellite oribiting Mun, and then rely on that size setting being remembered. Is there some poison-pill map size?

Hi, I'm getting a disabled/bugged Scansat window with one of my satellites. When I switch to my Minmus SAR sat, and view the large map with ground tracks, I get this IndexOutOfRangeException, repeating every 20-30 milliseconds: I can view the Minmus high-res altimetry map without problems from the space center. The exception only appears when I view it from the relevant satellite with ground tracks. The altimetry map is about 94% done, and everything was operating correctly until today. After the exceptions start streaming in, the Scansat map window goes blank, with only a non-clickable radio button, the numeral "7" and the ground track icon visible in the top left of the window. The exceptions stop if I close the map window, and start if I try to view it again. The small map and other Scansat windows seem unaffected. Screenshot: I currently have 193 mods installed. No big changes recently except for removing SVE as part of trying to diagnose a random CTD/memory leak I'm getting. Re-installed SVE and the problem still happens, though. Again, everything was OK until today. Linux 64-bit KSP v1.0.5, Scansat v14.7 via CKAN

Just an FYI in case anybody looks here: my overheating/exploding base problem with FlightIntegrator was actually caused by FAR, and has been fixed in the latest version (0.15.5.5 as of this moment). Any vessel with a ModuleCoreHeat was loading with temperatures of thousands of degrees and usually immolating itself. Not any more. @Geschosskopf: I've had that with the drills. For me it happens with any drill, not just the Gold Digger. Clicking the "modify drill" button again sometimes brings the dialog box up properly.

Completely understandable. I'll lurk on the dev thread instead of clogging up the release one. Hmmm, I know. I once built an 860m-long Minmus base extension down to some flats which were better as landing pads, but anything that was undocked from it (or the extension itself) instantly teleported to the other side of Minmus, lat/long/altitude 0. Probably bad to undock when the new vessel's CoM is outside the 200m physics force simulation range - kind of a hard limit. As for the NTR viability, I was hoping to save on the tonnage and parts associated with the reactors, thereby increasing the TWR. This will require some... more inventive solutions now.

Thanks. My ultimate aim is to recreate something like the Pegasus from the BBC's "Space Odyssey" mini series in 2004. That was about 1.2km long, fueled with LH2, powered by NTR engines. There are two spots on that station for reactors to be installed later, once it reaches Kerbin orbit. I will probably add a Whirlijig. As for scaling, and I know this is likely 'too much', but could it be possible to scale the cooling EC demand down, as fuel mass and/or volume rises? Surface area increases at a much lower rate than volume (http://www.tiem.utk.edu/~gross/bioed/bealsmodules/area_volume.html), so the relative losses at larger volumes should be far below the current, linear relationship of 0.1 EC per 1000 LH2. There would have to be two metrics, I suppose: an absolute cooling EC demand that tapers down as the absolute volume increases, and a relative, per-vessel EC rate that compares the current LH2 remaining to the MaxAmount. A full tank means the volume:surface-area ratio is at its most favorable, and the bigger that tank is (in absolute terms), the better. This is because, per unit of LH2, a full Centi-2 should require much more cooling than a full Mondo, simply due to the volume:surface-area ratio. Just pie-in-the-sky stuff that would require large and unpleasant changes, I guess, but it could be a way to help NTR viability on large vessels.

Thanks for your considered answer here. LOX can hardly be considered a "storable" - usually it would be gone in a couple of weeks - but I understand that altering a stock resource would be wrong. This isn't Realism Overhaul. Then again, LH2 is now the only propellant with RO-like properties, i.e. boiloff. Those NTR "attractive properties"; would that mean lowering the mass of all NTR engines, increasing thrust, etc? Stock ones, or the Nova from Ven's revamp, are, as things stand, completely non-viable. Hydrolox engines are also non-viable though. I cannot currently design any craft, or any stage, where hydrolox makes more sense than LFO. Nertea talked about un-nerfing the cryo engines and I hope that happens. LFO stages are lighter, higher TWR, lower part count, and higher dV right now, even without ZBO EC penalties. More on that below. This petite darling, my "Olympus" station... Yes, 18 spherical tanks wrapped around Speedy's hex truss in the LH2 section for 20,760,000 LH2, and another 4 million in the hydrolox section with the tweakscaled Mondo tanks. Each section is only 1 welded part (I love that Ubio plugin) which works well after some part file editing. Everything except LFO will be dry for the Minmus-Kerbin transfer, and then I'll have to make some similarly large tankers to service it. That's where I'm running into problems with the feasibility of LH2/NTR and hydrolox. Fuel:dry mass ratios are certainly much more meaningful for analysis of performance. However, when arguing that LH2 tanks ought to be lighter, based on comparisons to specific real-world rocket stages or lack of need for internal bracing (as Bluebottle was doing), I believe it's useful to step back and remember that empty LH2 tanks are actually the lightest objects in the game for their size. Yes, they are. And the mass and volume ratios you've implemented are remarkably realistic (very close to the Delta IV CBC). A Centi-2 + Centi-3 tweakscaled (I know, I know) to 5m give me something very close to a D-IV CBC tank (http://spaceflight101.com/spacerockets/delta-iv-heavy/), so the 2x fudge isn't actually unrealistic in that case. The engine TWRs, though, have relegated cryo engines to being niche parts - suitable only for a 2nd/3rd stage lifter - which is somewhat realistic, but therefore unbalanced versus the now-magical-by-comparison LFO. What I'm saying is: nobody's going to use them, at least nobody who uses KER or Mechjeb for dV calculations, or anybody cares about part count and doesn't weld (so, so many tanks on interplanetary vessels). That makes me sad because I love the idea/concept of the cryo engines. Oh dear, that makes me feel bad for venting it right into Bill's face!

Thanks. Yeah, I usually have the transparent pods switched off, or perhaps on "auto". RPM is so terrific that I can hardly imagine removing it entirely, but it would be great to have it enabled on a ship-by-ship basis. For example, enabled on the little single-crew Minmus science hopper, but disabled on the massive grand-tour ship.

The dry mass argument doesn't quite stack up, given that Centaur was incredibly light, and RP1 tanks require(d) significant internal bracing (in lift stages). Centaur's structural strength came from the pressurization of the contents. Also, did you take into account the cryogenic nature of the LO in an LFO tank? It seems only LH2 is being penalized for insulation weight/dry mass disadvantages, and LO gets away with it. Maybe this is why Kerbal Atomics was introduced: all other NTR engines running with Cryotanks are at a permanent disadvantage now, and it's very, very tough to make an NTR/LH2 ship that has better dV than LFO for the same mass. When you need upwards of 2000Ec/s for ZBO, those reactors get heavy! And again, LO has no penalty at all. With absolutely no snark (I know how difficult the IFS configuration is), has the outcome matched your intentions?