Crater

That will be because MMI_Kethane.dll in the 0.8.3 release is 0 bytes long.... However, it looks like it has been renamed to kethane.dll, which is a new file in this version, and that Majiir has included the zero byte one to effectively remove the old version, since most people just install over the top so it wouldn't get deleted. If this assumption is correct, then the error can be ignored, since the game is failing to load a dummy file that has no actual content, and will then get on with running normally.

You'll need a pod, probe body or docking port for which the forward direction is in line with your landing engine thrust vector. Then simply use "control from here" to make it active before final descent, and MJ will then assume that your engine vector is inline with it (which it should be). The ship you're referring to is called the Eagle, and someone even ported it to KSP a few versions ago http://forum.kerbalspaceprogram.com/threads/8549-Space-1999-Eagle-**Version-1-2-16-hatch-Kerbonaut-Ready!**

no idea if it will work or not, but the syntax to do what you seem to be attempting would be @PART[parachuteSingle] { @attachRules = 1,0,1,1,0 node_stack_top = 0.0, 1.53, 0.0, 0.0, 1.0, 0.0, 0 } @PART[parachuteLarge] { @attachRules = 1,0,1,1,0 node_stack_top = 0.0, 5.0, 0.0, 0.0, 1.0, 0.0, 1 } The PART needs to be in caps, the name for the small chute is not the same as the folder name, the attachRules should replace the existing line, and the node_stack_top is new, both of them are properties of the main part node, so no need for a MODULE statement or any further braces. Good Luck

Not sure if it is smiled on to post full configs or not, but all you need to change, from the initial supplied config is... TechRequired = flightControl changes to TechRequired = start and then for each of the lines like MechJebModuleBlahBlahBlah { unlockTechs = flightControl } change the bit at the end to say MechJebModuleBlahBlahBlah { unlockTechs = start } Then, if you haven't unlocked it already, you will need to go into the R&D building, click on the start node (the leftmost one) and then click on the AR202 that should show in the little list on the right. It should then be available to you to build with, and run with all its modules.

That just makes it more work to remove a mod, since it is no longer totally contained in its own folder, and does nothing to resolve the issue of installing a mod that comes with an old version of ModuleManager.dll that overwrites the one already in GameData\ModuleManager. Many users are put off by having to track down dependencies that they see as "should be bundled", so mod authors who depend on MM for their functionality will want to (and rightly so) bundle the MM version that is current at the time they created their mod.

Yes, the rest of the functions are unlocked in unmanned flight (I think), and yes, any parts already in use when you unlock that will get a free upgrade to the newer functionality.

I'm a little concerned about needing to have a copy of the ModuleManager.dll in every sub-tree that has ModuleManager config files in it. My reasoning is that I have seen several mods which do not use ModuleManager themselves, but provide ModuleManager config files to ease inter-operation with other mods. For example, Kethane does not use ModuleManager, but ships with a ModuleManager config file to integrate the Kethane resource into ModularFuels. This will silently fail under the new scheme unless the user either adds a copy of ModuleManager.dll into the Kethane folder, or moves the Kethane resource definition file (which has the @TANK def) out to somewhere that has ModuleManager.dll already. I think that ModularFuels compatability is likely to be the biggest one, here, but there could well be others. However, I completely understand the concern regarding addons dropping older versions into the GameData root, and messing up the entire install. As an alternative, how about simply including the dll version number in the filename? So you could have GameData\ModuleManager_1.4.dll If you then up-version to GameData\ModuleManager_1.5.dll it will never overwrite the old one, and will be easy to see what versions are installed. You would then still be able to process the entire tree from a single instance of your DLL, and users could be told to simply delete all but the newest version number from GameData? Anyhow, thanks for working on this, I don't quite know what I would do without it I'll be testing the new one out tonight (carefully, and installed in 3 places, as needed), and I'll give feedback if I find any problems.

Essentially, yes. Any line starting with an @ is saying to match against something.... the square brackets contain the value from the "name = " line so it knows what it is looking for. So you could, say, give a REAL kick to one of your decouplers by @PART[radialDecoupler] { @MODULE[ModuleAnchoredDecoupler] { @ejectionForce = 25000 } } which would match to the PART named radialDecoupler, and then within that part, to the MODULE named ModuleAnchoredDecoupler, and within that module, find the line that defined ejectionForce and replace it as shown. (don't try this at home, I have no idea what 100x the ejection force would do to your rocket!). If you read the thread for MM, there are loads of examples of what you can do with it.

Sorry, I should have explained, for those who don't already use it... ModuleManager ( http://forum.kerbalspaceprogram.com/threads/31342-0-20-ModuleManager-1-3-for-all-your-stock-modding-needs ) is an addin whose sole function is to allow you to apply change-files to parts from stock, or from other mods, in a way that means that you don't need to edit the original files, which means you can safely install new versions of mods, and that id two mods need to change the same file, they can both easily do so, and both sets of changes get incorporated and used, at runtime. So to use what i posted, you will need to download the DLL from the link above, the recommendation is to put the dll directly into your GameData folder, and then create a text file called something like KAS_Tech_tree.cfg (any name you like, as long as it ends .cfg) and paste what I posted into it. Personally, I have a folder in GameData where I put all my ModuleManager files, but you can actually put it anywhere you like underneath GameData. Then when you load KSP, the dll will go through the changes-file, match the parts my name, and add the config data specified to them. You can use it to add/change/reconfigure/remove modules, resources, or pretty much anything in the config files.

Uhhh, Majiir has requested that people use ModuleManager configs to share additions to the tech tree, rather than distributing complete config files, or the complete parts folder as you have (which I think also violates the licence for the addon, though I'm not sure [Majiir, the licence link on the front page isn't working]). Anyway, here is a ModuleManager config that will add all the KAS parts into the tech tree, for those who want to use them in career mode. This one puts the containers in start, struts and pylons in generalConstruction, where you get EAS-4 struts, and pipes, winches and all their accoutrements into specializedContruction, where you get docking ports. Feel free to move things around as you wish, but this way at least you don't get back-door access to functionality that shouldn't be unlocked yet. @PART[KAS_Container1] { TechRequired = start entryCost = 0 } @PART[KAS_Container2] { TechRequired = start entryCost = 0 } @PART[KAS_ContainerBay1] { TechRequired = start entryCost = 0 } @PART[KAS_CPort1] { TechRequired = specializedConstruction entryCost = 0 } @PART[KAS_CPort2] { TechRequired = specializedConstruction entryCost = 0 } @PART[KAS_Hook_Anchor] { TechRequired = specializedConstruction entryCost = 0 } @PART[KAS_Hook_GrapplingHook] { TechRequired = specializedConstruction entryCost = 0 } @PART[KAS_Hook_Magnet] { TechRequired = specializedConstruction entryCost = 0 } @PART[KAS_HookSupport] { TechRequired = specializedConstruction entryCost = 0 } @PART[KAS_Pipe1] { TechRequired = specializedConstruction entryCost = 0 } @PART[KAS_Pylon1] { TechRequired = generalConstruction entryCost = 0 } @PART[KAS_Strut1] { TechRequired = generalConstruction entryCost = 0 } @PART[KAS_Winch1] { TechRequired = specializedConstruction entryCost = 0 } @PART[KAS_Winch2] { TechRequired = specializedConstruction entryCost = 0 } @PART[KAS_Winch3] { TechRequired = specializedConstruction entryCost = 0 } @PART[KAS_Winch4] { TechRequired = specializedConstruction entryCost = 0 }

The game, like most people, use the term "battery" loosely to refer to power storage, rather than referring to cells that make up batteries that are clustered together in strings, which are then paralleled up to provide the total required capacity at the aggregate voltage. It's way more complexity than is modeled in game, so it is simpler just to think of a fuzzy lump of charge-storage device, and call it a "battery", and the batteries in the game are, as I said, fairly close to real, and you were initially asking for higher capacity in lower masses, which is OP and not based on current scientific research. Also, if I clustered 6 of the 40kVA units I would have 240kVA, but if I only had one set of control gear, I'd have a 40kVA unit with an hour of autonomy. It is a 240V system, and can supply up to around 150Amps, but if I tried to draw a thousand amps, apart from tripping and shutting down, it would catch fire. In fact, I could add another 80 strings of batteries to the 8 strings currently in the UPS (which would take it to around its maximum supported configuration), taking the total storage to eleven times its current amount, but it would still only be a 40kVA unit, just with 2 hours of autonomy instead of 10 minutes. What you're looking for in-game would probably acutally also require very high power throughput and therefore the cell to control system ratio would probably still be about the same. Even so, the volume ratio is about 60% batteries : 40% control, the mass ratio is about 75% batteries to 25% control, so even looking at just the cells, the volumes in game are on the small side, and the masses aren't a million miles off.

Just to be clear here, in this context ModuleManager is a DLL written by Ialdaboth and maintained by Sarbian which allows you to use a simple configuration file to modify the part definitions of anything in your game without having to hand-edit the parts, so the tweaks can safely persist across installations of updates to the mods that you are tweaking. It also means that several mods can make changed that they wish to, to stock parts for example, without there being any clashes or over-writes to the parts. It is NOT an application that manages what mods you have installed, which I believe is what you are referring to.

Unfortunately, batteries are big and heavy. I just did the maths on the 40kVA UPS we have in the server room here... It has about 10 minutes of autonomy at full load, which means that, ignoring the power factor and stuff like that to keep the maths simple, it can store about 40kW x (10min x 60) seconds = 24MJ of power. It weighs in at just under 0.7 tonnes, and takes up about 4m3 of space. For comparison, 6 of the z-4k batteries will hold 24,000 charge (~=24MJ), weigh 1.2T and take up less than half that much space. So, considering that the sample here is fragile batteries, that you can't safely tip over, let alone subject to acceleration stresses, I'd say that the slight increase in mass for stability and containment is reasonable, and that, if anything, KSP batteries are a little on the small side. Essentially, this is the reason that large scale power protection involves a few minutes of battery to allow for a generator to cut in, rather than trying to provide emergency power just off the batteries. There's nothing to stop anyone doing a config edit to store thousands of MJ in something the size of a AAA, but anything more power-dense than the batteries in-game at the moment would definitely be based on wishful thinking rather than science. There are some promising looking possibilities in the nano-tech field, but, as anyone with a smart-phone or a laptop will tell you, real batteries just aren't very good, right now.

It's not exactly a loop issue, more of a when do you convert question issue. For example... * if you up-convert all of your EC to MJ, then someone on the ship turns on a light (or tries to use reaction wheels, or life support), it won't come on. * if you down-convert all of your MJ to fill your EC storage, then most generator modules will see that EC is full, and stop generating. * if you happily convert both ways all the time, then yes, it is a loop, as both converters will be running, and, well, who knows whether you'd have an EC or MJ at the precise instant that you requested it, regardless of how much of the other you may have to hand. So what you need is something that can intelligently make sure that there is both stored capacity and spare capacity on both sides of the conversion equation. So, you could, for example, make sure that all storage containers for both types of resource were at an equal percentage full, so you could have 27.1% capacity on your MJ, and 27.1% on your EC, and if someone used a load of EC, you'd down-convert until the percentages matched again, and vice versa. However, I don't know of any generator (converter) modules out there at the moment that could be made to work that way. They are generally of the "stop only when I have no input or the output tank is full" variety.

This is the expected behaviour - it only pings when it enters a new hex. This is a real pain, especially on rough surfaced bodies, such as the smaller moons, since it can be very hard to tell what hex you are in on the surface from the current orbital grid map, and I can't find any way of reporting on the Kethane content of the current cell. I actually managed a base on Bop where there was Kethane and (EL) Ore in adjacent cells, and I straddled the border with my two drilling systems, but it was a PIG of a job to find the right place, had to keep driving, drilling, driving, drilling, until I hit the magic green goop. It would help if the current scan amount could be seen via the right-click menu.... hmmmm, off to github to put in a feature request When in doubt, just run fuel lines both ways.Having fuel pipes both ways is rarely a wise plan, sadly. It creates a closed loop, and the current stack traversal code for fuel routing (which determines what tanks to drain in what order) really doesn't cope well with loops. If there is any symmetry involved then you are very likely to get asymmetric draining, and a rapidly imbalanced ship, often followed by an unscheduled lithobraking event.

Oh, they're working on it, but most of that work involves waiting for Unity to release a 64-bit Unity engine on Windows that is stable enough to use for KSP. I think that they are already using it on the linux build, but, apparently it just isn't quite there yet on Windows.... but it will happen.

Load the game, exit immediately from the front menu, then go look through the KSP.log file for where it is loading those assets - search it on the filenames (without the extension) and on the part names - it may give you a clue as to what is happening.

Trying to word this as feedback, rather than a whine. The changes to recycling are definitely more realistic, but, for me, they move it from a useful way to tidy up the base (and kick Kessler into touch), to being a function that I will probably never use. Most of the recycling I've done has been to clean up so that I could make bases without excessive effort, rather than out of a need for RocketParts. Now.... well I'll give it a try, but I suspect that the fun per unit effort coefficient is going to be too low now. (Definitely updating, btw - the work you are doing to this mod is awesome, thank you!) Just personal opinion, not asking you to change it back, but feedback is important in any mod.

It is, essentially, the fact that Unity seems to expand all images into an uncompressed representation in-memory while it is running, coupled with the fact that there is a very high res image for each body in the system. There is another thread that is discussing this ( http://forum.kerbalspaceprogram.com/showthread.php/47150-ISA-MapSat-Legacy-discussion ), and essentially, the primary way to do it would be to store the terrain data out-of-band, and build the textures on the fly for display on screen - this would be a huge change in how the addin works.

You just need to edit it out in the part files, and in the config file that is in plugindata (under the mod in gamedata). All the resources that are used are listed in there, so you can set them to anything you like, just make sure that the resources in the part configs match. But.... you can keep your children, I value my sanity

Do you mean interstellar, or interplanetary. If the former, then, well, there sort of isn't actually anywhere in game to go. If the latter, then, I have a TAC-supported mission on Ike that has been on the surface for nearly 200 days now, and will be heading home soon, they are just waiting for a transfer window back, so it totally doesn't cause a problem with mission duration.

It has been discussed many times, from just after 0.20 was released onwards. You need to add a PART { ... }wrapper around every part in its config file You should move the parts into a subfolder in GameData You will need a copy of cleverbobcat.dll , ideally in a Plugins folder in the same sub from GameData as your part files. Note though, that you may already have a copy of this if you have installed the HOME kit. You should check for that, and avoid having two versions. For the command pods, you will need to remove the old SAS configurations (Ki, Kp, Kd, torque, modules), and add the new ones (see a stock command pod for examples, needs sas, reaction wheels, electriccharge). These are the same basic instructions as for migrating any part-pack from pre-0.20.x to current format. I'm happily using DEMV2, DEMV4, DEMV5, Nautilus, JoolV after doing the above (though I also needed to track down a VanguardTechnologies DLL for some of the animations).

Take a look at the basic version of the Modular Fuels mod - http://forum.kerbalspaceprogram.com/showthread.php/31706-0-20-Modular-Fuel-System-1-3-realistic-fuels-reconfigurable-fuel-tanks-and-engines - that's more or less exactly what the basic one does. It is only the advanced version that adds all the real-world fuel types and engines in (as I understand it).

The secret to this is in the density of the resource, which you can find in KSP\GameData\OrbitalConstruction Redux\Resources\RocketParts.cfg (and also in KSP\GameData\Extraplanetary Launchpads\Resources\ExtraSpaceCenters.cfg if you have EL installed) The section RESOURCE_DEFINITION { name = RocketParts density = 0.0025 // parts are very fluffy. 0.5t/m^3 flowMode = ALL_VESSEL transfer = PUMP } defines RocketParts, and sets their density to 0.0025 tonnes per volume unit (apparently 2 litres), so each unit of RocketPart resource weight 0.0025t, or 2.5kg, so yeah, you need 400+ parts per ton of ship you are building.

I think there's a bug in the resource type for one of your tank sets. In the LF/Ox mixed tanks, you have (correctly) "LiquidFuel" and "Oxidizer". But the separated out resources the tanks store "LiquidFuel" (still correct), and "Oxygen", which is great if you have life support and want enough air for a decade for your station, but it won't keep a rocket flying. Is the separate Ox tank actually meant to be Oxidizer rather than Oxygen?