Crater

Targeting is possible, but the approach vectors are off - like perpendicular or even inverted. I set up a Minmus orbital station using one as the hub over the weekend.... I hadn't realized just how much I now rely on Navyfish's docking alignment indicator until it was out of commission and I had to eyeball docking again. I pity anyone who relies on MechJeb docking with the FLAT

The only other body with oxygen in the atmosphere is Laythe, which also has toxic components so you cannot breathe it straight - there is a filter part that allows you to extract breathable oxygen from it and replenish your tanks though. As for doing what you want with mods provided you don't distribute them, you are quite correct that in general that isn't a problem. What is a problem is when people alter a mod, e.g. by moving files, and then report the breakage in the forums, or ask for help getting things working when they actually would work if they hadn't fiddled. So yes, you can do anything you like, but if you do so, expect to be pretty much on your own getting it working. Regarding duplicates of Module Manager and Toolbar dlls - that's exactly my point about leaving files where they are put by the developers. Modulemanager_x_y_x.dll should ALWAYS be in GameData, and nowhere else, and Toolbar.dll should ALWAYS be in GameData\000_Toolbar and nowhere else. Off hand, I only know of one instance where a mod has included toolbar anywhere else, and that was fixed within a couple of days, and was back in January. I'm never seen anyone put ModuleManager.dll in their own folder since the days that Sarbian took over development of it, and integrated all the features into a single copy. If you are seeing copies in other places, then either the dev of those mods is distributing them wrong, or you're installing them wrong. In the former case, please let us know which mods it is, so we can get the devs to put them in the correct place and avoid causing crashes and breakages for people.

If you know what your tansit time is supposed to be, you could try for an "Intercept at time X" transfer, but you'll really need to be accurate on where in your orbit you place the burn, or you could find it to be extremely delta-v intensive. Other than that, you could try plotting the burns well in advance, storing them using something like Kerbal Alarm Clock, or PreciseNode for each craft, then running the burns manually one orbit early, or one orbit late, and then tweaking the course with a mid course correction.

Do NOT rename folders when you install mods, it is almost guaranteed to break stuff. The reason is that the asset database that KSP builds uses the exact path name to the file as the key by which it will find things later when they are called for. You move things and stuff that uses them can no longer find them. The reason that some devs use their name for the top level folder is that if they are releasing multiple mods that share assets, or DLLs, or whatever, then it is pretty important that they only have one copy of the file, so the only real sensible solution is to keep all their stuff together.

Somewhere around 1.6 TWR seems to be the sweet spot with FAR and a good aerodynamic shape. If you throw more thrust at it, you'll certainly get there a lot faster, but you will definitely end up with a less efficient launch. I can confirm the numbers you're seeing in the thread though. I usually budget about 3900dV to get to 100km orbit these days, and it's often less than that.

Make sure that the config file with that in is alphabetically last, so stick it in a folder called "GameData/ZZZZ_Final_Mods". All of the configs are parsed in find-them order, then all the :Final ones, in the same order.

Yup, just drop the .dll in the GameData folder. You can place config files for it anywhere under there. Not as such, but take a look at http://forum.kerbalspaceprogram.com/threads/70986-0-23-Cargo-Transfer-Bags-and-Tanks%28for-TAC-life-support%29-0-6 for a possibly better option Don't forget that most of the engines in game also generate power while they are running, so it is totally possible to do successful manned orbital flights with TACLS from the start. It just means that you have to put some focus into battery and solar panel research before you can head for the Mun. Definitely doable, though. Though I agree that it was challenging at times.

Hatch door? Oh, err... yeah, we'll, err... definitely have one of those! *scribbles frantically on the design plans*

The difference is that without MM, what you get is exactly one day of supplied per kerbal in only the command pods. No more, no less. This is dynamically added at load-time by the lifesupport DLL. ModuleManager allows you to trivially and safely adjust this default. You can add more supplies to some pods, or remove them from others, meaning that you would need separate tanks, or add LS storage onto other parts as well, or.... well anything you would want, generally. The beauty of ModuleManager is that it allows a mod (or a user) to adjust and edit another mod's (or stock's) cfg files in a way that DOES NOT require them to be edited on disk. This means that you can undo the change by removing the MM config that comes with the editing mod, and that if several mods want to change the same original cfg file, they an all safely do so, and that if you update the original mod, you can drop the new cfg file into place and the required edits are reapplied next time you load the game. It is a very small, very lightweight addon that uses almost no memory, takes a tiny amount of time to load, and massively simplifies many many tasks.

While I was double-checking my work for the modified HotRockets config I just posted in that thread, I noticed a minor boo-boo in the drec config file, too. For your attempted workaround for HotRockets in your latest version, you double up the ModuleEngines with a ModuleEnginesFX definition for the heatProduction adjustment..... but you missed the FX variant for the skipper Though, the alphabet being what it is, it'll probably work anyway, since your heatProduction mod will go first, before the HR one changes the module name.

1) I've edited the HotRockets config file in line with this post, but I'm not in a position to test it. If anyone is interested, replacing the file at GameData\MP_Nazari\MP_Nazari.cfg with the one from https://dl.dropboxusercontent.com/u/2652591/MP_Nazari.cfg should work fine with and without DREC. 2) HotRockets BUG report - while doing the above, I discovered a bug in the shipping MP_Nazari.cfg - the engine data for the BACC SRB has been used for both stock SRBs I've cleaned that up in the d/l above.

So... we're looking at a rectangular-ish metal box with tail-fins... Am I the only one who is now humming Greased Lightnin'? Can't wait to crashfly this baby!

Loving the concept of the Kanned Kerbal...err H.A.R.P., but those downward angled wings would mean it would likely be a nightmare to fly. It would make it very roll-unstable, with a nasty tendency to add a helping of rotisserie to the pressure-cooker.

Are you testing on the lauchpad? TACLS doesn't kick in until you take off.

Right..... The first one is because a few versions ago, the name of the DLL was changed. Sadly, the only way to "remove" the old-named dll when most people just unpack over the top of their existing install is to replace it with a zero-sized file. This causes the error that you are seeing, which is just KSP warning you that it was unable to load the (old) dll file, which is the required behaviour, since it is empty. The second one is caused partly by some deprecated parts. They part definitions still exist, to allow old craft that used them to be loaded and the parts replaced, but the models and textures have been removed from the release to avoid needlessly wasting system resources. And partly by someone misunderstanding the texture= line in a MODEL{} block. They are using it to list the textures used, while it is only necessary to use it to replace the textures specified in a model with different ones. The errors can be ignored, since the game defaults to using the acutally correct textures in both these cases. It is quite safe to delete Gamedata\Kethane\Plugins\MMI_Kethane.dll Gamedata\Kethane\Parts\kethane_radialDrill\ Gamedata\Kethane\Parts\kethane_tank1mLarge\ which will reduce the warning count a little if you wish. I'm pretty sure that the current release of Kethane only works with the current release of KSP, which is 0.23.0.395 - I'm afraid you'll need to update KSP and try again.

Sumghai is unwrapping these parts so that there is only a single 4k texture for the entire pack. The texture islands are shared across all the parts that look like that. In X0.04 the only per-part textures are tiny ones that are just the logo for the module. All the rest is common.

Awesome. I already had the FAR changes - I'd done that one myself, but hadn't had a reference handy for the direction on the DREC shields. I'm now looking forward to many crashes and oopses tonight (sorry Jeb) while I get some shiny spaceplanes built.

Thanks! Much appreciated

It's not just you - they're defined as being wings... which make flying them in FAR surprisingly interesting. Sorry to be a pain, but the link you posted for the MM configs for DRE (and stuff) leads to an apparently empty directory in your dropbox. Any chance you could check it out, I'd love to have the configs and I'm never sure how the directional stuff works for DRE.

It looks like it allows you to select parts that are obscured by other parts in front of them, e.g. you could pick up a part that was inside a closed cargo bay, or pick up a fuselage tank that it completely plastered in batteries without having to find that single-pixel gap between them where you can see the tank itself, or you can pick up a small object that has gotten itself lost inside the collider for, say, a ladder. At least, that's what I think it is for

Quite a lot of module developers have multiple mods that they install into a single sub-folder of GameData. e.g. bobcat, rbray, ASET, ThunderAerospace, SDHI (seems to be planning to go that way), TriggerTech. Requiring a file called gamedata/somethinggoeshere/versioninfo would fail in those cases, since there are multiple mods installed below that level, and each will be versioned independently. Alternatively, allow any file beneath GameData called arbitrartymodname.version - walk the tree looking for *.version, and parse the name and preferred install folder (if you need it) from within it.

It is exactly that reason - several versions ago, the DLL was renamed. The only way to stop people who don't read the installation instructions from having two conflicting DLL versions installed (i.e. most of us if we are honest) is to replace the old-named one with a non-file, in this case a .dll with zero length. The "error" quoted is totally harmless and can be completely ignored. The simple fix for it is to delete the offending file.

How it works is as follows 1) stock part configs are loaded, so if a part pre-exists with TAC-LS support, it will have it 2) Module Manager configs are patched in - so any part with specifically defined values can be set 3) ALL parts with crew capacity that do not already have the LifeSupportModule automatically have the LS module and exactly one day of supplies added. This means that, for one day of consumables, everything will just happen by magic, and you cannot forget to provide a mod part with air to breathe. BUT, it also means that you can e.g. build an MM config that puts more supplies onto a pod (such as NASA's planned Orion pod which will have consumables for about 6 days for 6 people - 36 person days of stuff), or, for that matter, you could just add the LifeSupportModule, but not consumables, using MM, which would mean that the code would not do the automatic add, and you'd have a very dangerous pod to spend any time in O.o

Unfortunately, the way TAC Lifesupport works is that the same single tank stores both the consumabe and the waste product, so, for example, and O2 tank with start with 100/100 Oxygen, and also 0/100 CarbonDioxide, and as you use up the O2, that drains and the CO2 produced fills it. So after 30 unit used, you'd have, say, 70/100 O2 and 30/100 CO2. The clash here is that one tank can only have one pump level, so when your resupply ship arrives to fill the station with O2 and collect the CO2, there is no way that you can set a fuel pump level that does both, as it will either pump consumable AND waste into the station, or consumable AND waste into the return vessel, you cannot split them. So the only way to do it is manually, which is exactly what this wonderful mod was created to avoid.

Thank you