blowfish

MM doesn't create a cache if it detects errors - that's expected behavior. The exact cause of the error is in KSP's log.

Yes @PART[someEnginePart]:FOR[myMod] { @MODULE[ModuleEngines*] { @PROPELLANT[LiquidFuel] { @name = SomeOtherFuel } @PROPELLANT[Oxidizer] { @name = SomeOtherOxidizer } } }

Wouldn't that qualify as breaking the laws of physics? Power should always scale as r-2

It's not ModuleManager. ModuleManager only touches configs that have been loaded by KSP.

isEnabled is true in the editor. It's mostly just used for completely disabling certain modules, e.g. MultiModeEngine disables the inactive engine module. Both OnUpdate and OnFixedUpdate will only fire if isEnabled is true, but OnFixedUpdate has another check of part.state == PartStates.ACTIVE.

FAR has a ModuleManager patch that applies the basic FAR modules to all parts. I'd be very skeptical if these weren't applying to yours unless you messed something up. Aero surfaces are different, you need explicit patches for each of those because you have to specify the shape of the wing. It sounds like you have a lot of questions that aren't necessarily FAR related. I would hate to clutter an already crowded thread. I can maybe help you with some stuff if you make a new thread.

...I have no idea what you're trying to do or how you're trying to do it. Could you please be somewhat more specific and provide context in your posts?

I think a major reason it's not coming off the ground is those control surfaces on the main wings are angled up, killing your lift. You probably want to remove pitch input on those surfaces, and maybe enable them as flaps even (which would angle them down) That being said, it does take more wing to fly in FAR than in stock. Don't expect a craft that behaves well in one to behave well in the other.

Right, because PartModule actually uses the Awake() method. Fortunately it provides an OnAwake() method which you can override (and is just called by Awake() ) I think this is true for OnFixedUpdate but OnUpdate is called regardless.

KSP.log or output_log.txt. Information on how to find those is in the first link in my signature "how to get support" If you're having a lot of problems though, I'd recommend a clean install. Even if you think you've updated everything, it's easy for a couple of things to fall through the cracks.

@Victorsaurus KJR works fine on 1.1.3, hard to say what's wrong on your end without logs.

I've debugged plenty of broken patches in the past. As with any log messages, the results are difficult to capture in-game, but can be read easily after the fact by looking at the log (KSP.log or output_log.txt). I'm really not sure what you're so angry about.

Okay, let's back up a step. Most shapes, including cylinders, cones, and cubes, will generate lift at positive angle of attack. The bottom surface will deflect air downward, and the airstream will tend to stick to the top surface as well forcing the air down and by extension the object up. With the exception of wings (which are treated differently), FAR models body lift for all parts. The Mk2 parts have a lifting module in stock, but FAR removes it and calculates body lift 100% based on the shape.

@Verran Lifting bodies are unstable, that is a well-established fact.

@Delipunch Welcome to the forums ... that's quite a strong opinion you seem to have, do you have some specific examples to back it up? The specifics of the errors are written to the debug log (which is shown in the debug screen, but things get lost in there pretty quickly. Is there a particular patch you're having trouble debugging?

I've answered a number of questions related to this in recent times, so I figured I'd explain in detail the entire life cycle of a PartModule. Birth When parsing a part from the game database, KSP looks for MODULE nodes to parse as part modules. It looks for a name = XXX value in the MODULE node and tries to find a class that derives from PartModule with that name. If it finds one, it will attach an instance to the part's GameObject (part modules are Unity components and can only exist attached to game objects). The newly created module will then be added to the part's module list. Load(ConfigNode) will be called on the module with that node. This loads any fields with the [KSPField] attribute automatically, and calls OnLoad(ConfigNode) with the same node to allow parsing of any custom data. KSP stores the part (and its modules) as what's called a prefab - any time the part actually needs to exist in the game, this prefab is copied. Instantiation in the Editor When adding a part the the editor, KSP will instantiate (copy) the part prefab. In order to do this, Unity serializes the entire part and then deserializes it as a new instance (see here for more information on serialization in Unity). This is often a source of grief with part modules because custom data frequently does not get serialized (brief note on this below, I will dive into more depth on this issue in a future post) Once all the editor setup is done, the part's Start method will call the module's OnStart method, then Unity will call the module's Start method. Life in the Editor OnUpdate will be called by the part and Update by Unity every visual frame. OnFixedUpdate and FixedUpdate the same every physics frame (even though there's no physics in the editor). Editor Copy The user may copy an existing part in the editor or change the symmetry mode. Either way, KSP makes a copy of the existing part. Instead of copying the prefab as before, KSP will instantiate the existing part instance. The same serialization rules apply. Editor Save When the craft is saved in the editor, Save is called on each part module to save its state. Save writes any KSPField with isPersistent = true to the saved node, saves data about events and action groups, and calles OnSave, which can be used to save any custom data Editor Death When the part is removed in the editor (or a new craft is loaded) the part and all its modules are destroyed completely. No data that wasn't already saved will survive. Creation in Flight This behaves very similar to creation in the editor. The part prefab is instantiated (again, by serializing and deserializing), Load is called with any saved data (which again calls OnLoad to do any custom loading), OnStart is called by the part, then Start by Unity once everything is set up. There's one odd case of this, and that is when dealing with the root part of a vessel already in flight. KSP does instantiate the part prefab (and by extension its modules), but then copies its fields to a new part with new modules. I'm not sure why this is done and it usually doesn't matter, but still something that can cause occasional issues. Life in Flight OnUpdate will be called by the part and Update by Unity every visual frame. FixedUpdate will be called every physics frame, and OnFixedUpdate will be called every physics frame once the part has been activated (i.e. staged). Flight Save Basically the same as in the editor, Save is called on each part module, which writes any KSPField with isPersistent = true to the saved node, saves data about events and action groups, and calles OnSave, which can be used to save any custom data Editor Death When the flight scene is exited, the craft goes out of physics range, or the part explodes, the part is destroyed completely, along with all of its modules. I've probably missed some stuff here, so feel free to ask questions etc.

The ones who understand the propeller configs are @NathanKell and @ferram4, I'm not sure if they plan to work on adding engines at any point AJE has configs that remove the Tweakscale module from any engines. Or at least they should.

It's not really possible to have a part move other parts. At least not easily. That's what Infernal Robotics is for (but it's still not perfect - for instance, this is incompatible with KJR). Actually there is a stock module but it's pretty hacky and probably incomplete. My recommendation would be: don't bother.

@Fengist not sure about your issue, but you could simplify that code quite a bit. part.Modules.OfType<ModuleEngines> will give you both ModuleEngines and ModuleEnginesFX, since ModuleEnginesFX derives from ModuleEngines. Also probably easier to check whether FirstOrDefault gave you anything rather than looking at the count as well. Also, part has a method for doing this: myEngine = part.FindModuleImplementing<ModuleEngines>(); if (myEngine == null) return;

Okay, well I see that something is causing FAR to spam exceptions. The next step would be figuring out what mod is causing FAR to do that (Tweakscale might be a good first try). This doesn't seem to happen for anyone else, so it has to be one of the mods you have installed (or a bad install). Here's what I would recommend, if you want to get to the bottom of this as quickly as possible: Start with a clean install with only FAR. Slowly add mods back in until you see the problem again, in which case you know which mod caused it, or you don't, in which case it was an install error. By the way, unrelated to your problem but you only need one copy of ModuleManager (the latest version). Others will disable themselves if they see another one.

Forgive me for still being skeptical, but RPM is a dependency for B9, so if there was a conflict others would probably have noticed it by now. At any rate, I tried on my test install (B9 + Dependencies + a couple of other things) and found no issue either with stock cockpits or with B9 cockpits. So something else has to be going on. Can you replicate the issue with only B9+Dependencies installed?

I can't see any reason why B9 would be causing it, and it's always worked fine for me. You got the wrong log, but looking at the one JohnWittle posted in the other thread, I do see some exceptions related to RasterPropMonitor. If you can't reproduce the issue with no B9 but with RasterPropMonitor, then confirm that adding B9 brings the issue back, I'll take a closer look.

I think the step you're missing is the mixture density, which allows you to convert from mass flow rate to unit flow rate. The mixture density would be the weighted sum of all the propellant densities (mixture ratio) = SUM (propellant density * propellant ratio) / SUM(propellant ratio) If you divide the mass flow rate by the mixture ratio, you will get the unit flow rate, then you can multiply by the (normalized) propellant ratio to get the flow rate in units per second for each propellant

Try posting your logs again, along with ModuleManager.ConfigCache. I will see if I can identify anything new. It's definitely easier without noise from outdated mods.

I'm not 100% sure about this, but I think MM would count x as existing regardless. The reason is that all the FOR clauses are processed before everything else (to figure out which ones actually exist) You can't modify the EVA kerbal part through ModuleManager (because it is created programmatically by KSP). There are ways to do this with code though. I believe @anxcon figured out how to do this, maybe you can have a chat if you're interested in doing it this way.