Jso

Can't really troubleshoot a setup with that many mods installed. Try a clean install with just BDB, the latest Procedural Fairings and Firespitter, and the PF configs. The Firespitter core included in that download is for 1.1.3 I think. Perhaps I should update that. I haven't had an opportunity to play with procedural fairings with 1.3 so I have no clue if those configs still work.

Since there is a wide variety of other parts that carry fuel it wasn't added to reduce clutter in the menus. If you've got a life support mod those resources will show up in the cargo containers, but you can set them up to carry anything you want. Under the Bluedog_DB\Compatability folder the supply.cfg for the individual life support mods sets up the cargo containers. This bit of MM will add LFO and MonoProp. Just stick it in your own cfg somewhere in GameData (I make a folder called zzzMyMods for personal configs).

Merged. Thanks!

Final 1.2 re-release (to fix the spacedock version number snafu). KSP 1.3 release Changelog

We're good. They work fine on a clean install. @Dark_Dragon26 latest versions are fine for part mods (those without DLL's). For plugin mods you'll want versions updated for 1.3 or you'll likely have headaches. The update plan is wait for @CobaltWolf to finish cleaning up the graphics files, do a final 1.2.2 release, then update the plugin and do a 1.3 release. And I need to try to get the slider for the boiloff settings working again.

I would love this for supply containers. Unload Food/Water/Oxygen, then switch it to Waste. Have you put any thought in to what the UI might look like? I can't see the current control widget fitting into a multi step "Are you sure?" process. Perhaps some event hooks could be added? I could see wanting to do something additional on a tank change, like enable/disable other modules.

CryoEngines is not a dependency, we use our own boiloff code. There's an updated 1.3 BDB.dll on GitHub in the Extras folder for testing. The boiloff slider in settings is still screwed up so I'll see what I can do about that. You can play without B9 for fuel switching but there are a few parts that use it for mesh switching and lack the NEEDS[B9PartSwitch] clause so they throw errors. B9PartSwitch is updated. You also need ModuleManager 2.8.0.

The plugins (B9, DMagic, and ours) need to be updated before this will load on 1.3. Then we can see what might be broke in the configs and models. Hopefully nothing.

Unless the parts have something unique about them like a name prefix (PART[MunarInd*]) or an author or manufacturer that you can pickup in a HAS[#author[linuxgurugamer]], you can't.

Maybe but it's a mess. It has two NEEDS, a FOR and a BEFORE. I'm pretty sure FOR, BEFORE and AFTER are mutually exclusive. Edit: If you're expecting @PART[*]:FOR[MunarIndustries]... to only process part in that mod, that' not how it works. Try NEEDS[FTT]. RoverDude uses FOR[FTT] in one of the files. NEEDS[UmbraSpaceIndustries\FTT] won't work because module manager only identifies first level subdirectories of GameData for a NEEDS clause. Not the subdirectories of those. If you have a mod installed in a subdirectory like that, and it has neither a .dll or a FOR clause anywhere there's no way to confirm it's presence with MM. You can ask the mod author to add a do-nothing MM patch with a FOR[ModName] clause in that case.

Let the ckan people know. They might be able to fix the sorting. It must be pulling that from Spacedock, the "v" prefix is on ckan Github . I suppose we could release a patch.

I can't think of a reason something like that would only fail on BDB parts. I assume KER still has the partless option, you shouldn't need anything but a checkbox for that. This is my standard MechJeb-For-All patch. Never had an issue. @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:NEEDS[MechJeb2]:Final { MODULE { name = MechJebCore } }

KSP issue. 1.2.2 broke percentage sliders. They know about it.

NM, glitch gone. You'd think I'd know how to update my own mod by now. There's some stock-alike real fuels configs in extras on github.

Little glitch

CGMonitor Paste a direct link to the image in your message. Yours was http://i.imgur.com/VWUIayh.jpg. Imgur will give you one with a little hunting.

Updated to 0.2 with an experiment, ModuleJmTweakableTransmitter. This is a drop in replacement for ModuleDataTransmitter that allows adjusting the data rate and transmitter power. Since real probes reduce the rate of transmission as they get farther away rather than lose data to signal quality I thought I'd give this a try. Adjusting the power works like it really would, 4x the power gives twice the range rating, 1/4 power gives half the range. This could be useful to reduce EC usage with strong connections. I'm not sure what makes the most sense with data rate, so I went with simply dividing the range by the data rate percentage. 50% data rate gives twice the range, 5% gives 20x the range. The catch here is while the data is moving slower, the EC usage per second is the same, so your EC cost per Mit goes up. You can easily drain a battery transmitting the temperature on Minmus. Only works while the vessel is loaded. Can not be used to extend the range of a remote relay. MM to try it: @PART[longAntenna] { @MODULE[ModuleDataTransmitter] { @name = ModuleJmTweakableTransmitter } }

It's PART, not part. This is the basic idea, but will give errors when values in the base module are not set and left to default like DeployFxModules and antennaCombinableExponent. I'm not sure of an elegant way to handle that. SelectableDataTransmitter inherits from ModuleDataTransmitter so it should be safe (famous last words) to just rename it and leave everything in place. PART, not part. I think there's a setting for requiring connections for probe control. You're missing opening and closing braces.

Get Tweakscale. Fairing bases would be a natural place for general purpose IUs.

You want to increase ModuleAblator's pyrolysisLossFactor by maybe 25-50%. This is how SMURFF handles heatshields.

Yeah, I stumbled into that as I was finishing this up. I couldn't find any stock parts that use it though and haven't had a chance to stick it on something and see if it works. Doing this through that interface would be a simpler but would be an all or nothing approach.

Not recently. It was doubled back in December to bring it in line with the other upper stage engines.

I really don't have a problem with a Communotron-16 being able to relay home. As far as I'm concerned if you can make the connection and have the hardware installed to relay it's a go. My motivation here is to provide more choices in antenna selection. There's the obvious gain of being able to relay with any antenna. But also with the relay ability decoupled from the antenna, we're potentially able to de-relay the relay antennas and lower the mass (and cost) accordingly, making them useful for general purposes. With an antenna in the RA-100 class that's worth a half a ton of weight removed from a probe that has no need to provide relay services. The range limitation (which was admittedly an afterthought) is to maintain balance and there may be a better way of going about it. I'm still pondering some sort of bandwidth limit but I have my doubts that will work. The idea is the mass (and cost) removed from the relay antennas goes into the transponder parts. A small 50kg unit that could enable an HG-5 sized relay would not work on an RA-100. You'd need a half ton of equipment for that.

I use 3x with Sigma Dimensions for rescaling + Custom Barn Kit for adjusting the DSN. Should work with your preferred planet pack if you have one. I don't edit the Sigma config files directly since they get overwritten every time you update. The config below I keep in GameData\zzzMyMods\rescale.cfg (I use zzzMyMods so my Finals are actually done last). It's got some presets for 3, 3.2 and 6.4x atmospheres and will handle scaling the CommNet stuff. I frequently flip between different scales when testing. Just edit the first line. For 3x orbital velocity at 200km is 3986. GEO is 5408.3 km. You need about 5000-5500 dv for launch depending on the design.

CommSat Transponder The purpose of this module is to allow any antenna or combination of antennas on a vessel to act as a relay. This is an early work in progress and subject to change. How it works Place a part containing a ModuleJmCommTransponder on your craft. The transponder will scan the antennas on the vessel and adopt the stronger of the strongest single active antenna, or combined power of combinable active antennas, and present itself to CommNet as a relay antenna. Each transponder has a maximum power. Multiple transponders may be added to a vessel increase the maximum possible relaying power. The transponders have no transmission capability on their own - the power will never exceed that of your antennas. Bandwidth as a limiting factor would seem to make more sense, but that does not appear to come into play on an unloaded vessel that is acting as a relay. TODO It appears to work but needs harsher testing. I'm still waiting for the gottcha. Parts - a test part using the small radial battery's model is included. Balance concerns. Non relay antennas are much lighter and cheaper than relay antennas with the same range. A vessel using a Communotron-88 as relay should cost and weigh about the same as one using an RA-100. Adding the module to a part MODULE { name = ModuleJmCommTransponder maxAntennaPower = 15000000 } Download Github Source code Github License This mod is distributed under the LGPL v3.0