blowfish

Not sure about the Windows 10 version, but in Windows 7 at least Notepad only recognizes Windows-style newlines which not all cfg files seem to have. Something like Notepad++ might be better.

This one is on their end. Tell them this: if they try to find intake modules by name, they're not going to find AJE intakes properly. They need to use FindModulesImplementing<ModuleResourceIntake> or similar.

Known issue, it's a bug with stock tweakables.

Post your output log as usual. Only way to tell what's going on.

I'm sure someone could figure out how to make that work in stock aero, but there's no way to pull just that functionality out of FAR, sorry.

And with all that, you somehow think your issues are B9's fault?

Why wouldn't it?

Very excited for this I guess the Ct10 and KS-68 are the easy cases because you can just delete the outer ring. The relevant bits might have to have their AO rebaked (or just removed) though - I recall there being a bit of empty space in the texture, so if it's not too much trouble those particular pieces of texture could be duplicated to the empty space. For the Ct65 I think you could just move the struts to the inner ring. The rest are less certain I guess - keep the pistons if possible, but I guess it's still worth asking whether the ring should be removed or just shrunken. BTW, I don't think it's necessary to make the attachment base as small as possible. If they're the same size as the nozzle, or only slightly bigger, that's probably fine as far as clustering is concerned EDIT: Ninja'd ... I guess you're going with removing the rings then?

Indeed. Practically speaking, a precooled engine would need cryogenic fuel in order to be effective at high speeds.

Multiple MODEL nodes allow you to combine models in a single part.

Do you have FAR installed? If so, you shouldn't delete those patches. If not, do you have a phantom FerramAerospaceReserxh folder sitting in GameData? If neither of those help, post your output log as usual.

Not a known issue, so you installed something wrong. Try a clean install.

Okay, more notes. Sorry to spam your thread, but I spent on the order of months trying to wrestle meaning out of this stuff for jet engines, so I'd like to think that I know at least a bit of it (and if I don't, I'd certainly like to know what you do and I don't ). You shouldn't need to specify nominal exit pressure - exit conditions should be determinate from chamber conditions and expansion (area) ratio. It's not analytically solvable, but ferram4 gave us an implementation of Brent's method to use for nonlinear zero finding in SolverEngines (in SolverMathUtil.cs). You can use equation 9 here to solve for exit mach based on expansion ratio (this should only has to be done once - probably in InitializeOverallEngineData), and based on that you can find the nominal exit pressure and velocity. This might also simplify your thrust calculations too, since (in the absence of flow separation), thrust is just mdot * v_exit + (p_exit - p_ambient) * A_exit. Not sure if this would work well with your flow separation calculations though. There's no need to use 0.10001 for the pressure ratio at jet separation. One of (x >= 0.1) and (x < 0.1) will always return true. Where does the number 0.1 come from anyway? After all the rest of the details are worked out, I will show you a way to automatically fit some of the engine parameters based on available data for thrust and Isp, using an API I build into SolverEngines (at its core, this uses the same nonlinear solver I mentioned above). You should be able to fit chamber temperature and throat area (which are often not known for engines) based on thrust and Isp

Interesting, couple of questions: Shouldn't max fuel flow be determinate from chamber thermodynamics and throat area? (since the throat must be choked). See the second equation on this page. The CalculateGamma available in SolverEngines is only currently good for mixtures of air and some hydrocarbon fuel. I've been meaning to implement something better for a while but haven't gotten around on it yet. I had a system worked out where Cp was read from a float for a particular gas component and other thermodynamic parameters were determined from molecular mass. But then RealHeat came along, with dissociation modeled, and wasn't sure whether to try and model dissociation as well, since dissociation matters a lot at the temperatures reached in engines, however it makes the combustion reactions in AJE a lot more difficult to model.

ModuleRCSFX is a dependency, for the VTOL RCS thruster. Not sure about RPM.

Right. It doesn't specify what variant that's for, but I suppose it's close enough. I haven't had a lot of time to work on AJE lately but I'll add it when I get a chance.

If you use a mesh switch module rather than ModuleJettison that won't happen.

Most flying wing designs use differential airbrakes on the wings for yaw stabilization. That's supported with FAR control surfaces now.

I'm sure. IPartMassModifier has no effect on physics. You could possibly devise a system where multiple modules would carefully add their mass to part.mass then keep track of changes in that mass, but it would be messy and prone to error.

KSP deals with resource mass correctly, so it doesn't need to be added Currently, you can have multiple modules affecting mass (but that mass won't count toward physics), OR you can affect physics (but only one module can do it). The goal here is to allow both.

Post your output log - only way to see the full stack trace.

The current options for modifying a part's mass aren't very good. You can implement IPartMassModifier, but that mass doesn't affect physics at all. You can modify the part's mass, but if you have more than one module trying to do that, you're going to run into trouble. Therefore I am proposing a new system for part mass modification: A single module will handle all mass modifications and update part.mass Other modules that wish to modify a part's mass will implement an interface similar to IPartMassModifier The part's mass will be automatically updated on part update events, but modules may request a manual update if necessary I've got the basic implementation details worked out in code below. Still a lot of work to be done, but most of the major stuff is there public interface IPartMassModifier2 { float GetModuleMass(float baseMass); } public class PartMassModifierModule : PartModule, IPartMassModifier { public float BaseMass { get; private set; } public float ModuleMass { get; private set; } public float Mass { get { return BaseMass + ModuleMass; } } public override void OnStart(PartModule.StartState state) { base.OnStart(state); BaseMass = part.GetPrefab().mass; if (state == PartModule.StartState.Editor) GameEvents.onEditorPartEvent.Add(OnEditorPartUpdate); else GameEvents.onVesselUpdate.Add(OnVesselUpdate); } private void OnDestroy() { GameEvents.onEditorPartEvent.Remove(OnEditorPartUpdate); GameEvents.onVesselUpdate.Remove(OnVesselUpdate); } [KSPEvent] public void UpdateMass() { ModuleMass = 0f; foreach (PartModule m in part.Modules) { if (m is IPartMassModifier2) ModuleMass += (m as IPartMassModifier2).GetModuleMass(BaseMass); } part.mass = Mass; } private void OnEditorPartUpdate(ConstructionEventType eventType, Part part) { if (object.ReferenceEquals(part, this.part)) UpdateMass(); } private void OnVesselUpdate(Vessel vessel) { if (object.ReferenceEquals(vessel, this.part.vessel)) UpdateMass(); } public float GetModuleMass(float baseMass) { if (baseMass == BaseMass) return ModuleMass; else if (baseMass == part.mass) return 0f; else { Debug.LogWarning("Warning: unrecognized mass detected"); return 0f; } } } So to all the plugin developers out there, I ask: does this seem like a reasonable system? Would you use it? Is there anything you feel is missing?

The issue is tracked on Github. The fix is easy, just delete the ModuleJettison with jettisonName = TankButt in the config file.

You're going to have a hard time either way because engines and tanks weight a lot more in KSP than they do in real life - real launch vehicles only manage 1-2% payload fractions (to low orbit!). You might want to check out this mod though.

The options are NO_FLOW (only resources on same part), ALL_VESSEL (anything on the vessel), STAGE_PRIORITY_FLOW (anything in the same stage), STACK_PRIORITY_SEARCH (anything stack connected in the same stage), and NULL (can't do anything).