blowfish

More or less correct - that patch will run after any patches marked FOR[RealismOverhaul] . But it's worth noting that RO has some patches on different passes, so it's worth looking into exactly what you want to overwrite and when it runs. Also, NEEDS[RealismOverhaul] is unnecessary in this case. AFTER implies it.

I think adding the fuel type is the easy part. Modeling the engine is hard. And like Shadowmage said, it has to fill a gap in the current engine lineup.

It adds to the base cost, same as mass.

It occurs to me that there might be some inconsistency in the part's cost, since KSP assumes that the base cost includes resources and B9PartSwitch assumes that it isn't. It would be hard to say for sure without trying it though. Let me know what you see! It would work for users transitioning from a stock to a switching setup, but would break for moving e.g. from firespitter mesh switch to B9PartSwitch. But maybe that matters less now that all of B9 is actually converted.

Sure, specifying a default is easy, the question is how to decide when to use this and when to try to determine the subtype automatically based on resources. One option would be to always use the default if it is specified, but that would effectively break the feature for anything having a default. Another option would be to only use it if there are no resources currently on the part. Yup. It will detect that the resources are there already and use them rather than creating new ones. You don't even have to match up the amounts, but if you didn't then you might end up with partially filled tanks and it would display the wrong amounts to the user in the part info window.

Yes. I usually search for "error", which unless you have a lot of other issues should find it pretty quickly.

@AccidentalDisassembly I think your best bet is to add the resources on that particular subtype to the part. This may seem like odd behavior, but it turns out that this is actually a "feature" working correctly. Basically if there is no subtype set B9PartSwitch will automatically try to find the correct subtype based on the part's resources. I built this mainly to support converting from other switchers or none to B9PartSwitch without breaking any craft. I will have to think about how to handle this in a way that makes it easier to specify a default subtype.

Is there a situation in which you need to be able to re-close the bay? The shields can cover the openings on initial ascent, then can be discarded in space (but in stock areo everything inside the bay will be shielded anyway) Due to the original artists having left the project no new parts are planned at this time. Sorry!

I don't really understand the propellers, unfortunately. That's really ferram4's or NathanKell's territory. I can do jets though.

The most recent released version does not work with KSP 1.2.2 (indeed, the title of the topic says it's only compatible with KSP 1.1.3). That is most likely the issue.

It definitely shows up in the log.

Re: areoshells - I don't think skinned mesh renderers work for colliders. So if that option were pursued you would have to accept them not colliding with anything.

Confirmed. Unfortunately will be somewhat difficult to fix given that bac9 didn't give us the Unity files to work with. It's probably a matter of just moving the collider that defines the hatch out a little bit, but that's not easy to do if you only have the compiled model. But these parts are relatively simple so I can probably think about importing them into Blender and then re-exporting. The intake version does not appear to have the problem, no quite sure what the difference is.

Efficiency would be less because of the odd nozzle shape, and thrust would not grow with mach number as much because the nozzle area would be fixed. Beyond that, hard to say exactly.

You shouldn't overwrite anything. Just copy B9_Aerospace_HX into GameData along with everything else. Maybe start from scratch at this point as you could have some things in a weird state from overwriting.

Sounds like FAR isn't working, but the MM patches to remove stock aero are. If you're on KSP 1.2.2, there is no released version of FAR that is compatible, so that's likely your problem.

This doesn't really have anything to do with ModuleManager, but I'd recommend looking at Porkjet's Part Overhaul as an example: Yes. I think you would want something like this: +PART[foo]:FOR[MyMod] { @name = foo2 #@PART[bar]/MODULE[FSfuelSwitch] { // Any edits you want to make } } The key here is #, which tells MM to find the node somewhere else and paste it in.

Not sure about propellers (I don't really understand that code), but for jets they should consume fuel at idle. Do they not?

It's because it "depends" on FAR which is not officially updated yet. Truthfully it will run happily without FAR but generally lower engine performance doesn't work well with stock aero. Install FAR manually and I believe it will show up when you refresh CKAN.

Right, my point is that this question is probably better for the TweakScale thread rather than this one.

It's also the case that for most mods, the Tweakscale configs are included in Tweakscale itself and not the individual mods.

Yes, that was functional the last time I checked

@VentZer0 not sure then, but I will mention that flameout actually happens when the flow mutliplier drops below a certain threshold. The flow multiplier is affected by % propellant available as well as all the curves (velCurve and atmCurve in this case). By default, the engine will flame out if this drops below 0.07 (but you can set this by setting flameoutBar on ModuleEngines(FX) ). You're definitely right that stock engines are too powerful in FAR. They're balanced for stock aero. The biggest problem I've seen, and probably why you're hitting mach 2 at sea level, is that thrust grows too much with mach number (machCurve). If you want more realistically behaving engines in general, you could try AJE (linked in my signature). It completely replaces stock atmospheric engines with an actual (though approximate) simulation of their actual behavior. Not perfect, but much better than stock. Creating your own engines has a bit of a learning curve, but I believe there's an AL-31 config included by default.

Well I'm confused now. You have your curve begin to drop at 0.2 but you expect it to cut off at 0.3? Also can I ask what the purpose of this curve is compared to the stock curves? Real jets will have their mass flow scale perfectly linearly with atmospheric pressure*, so the stock curves already give you a bonus in the mid atmosphere compared to real life. * ok, there are secondary effects like bleed air requirements, but that will be pretty small. Also, performance will vary a bit with temperature, which will cause some variation with altitude, but that's not the same as pressure changing.

e-8.4/5.6 = 0.22, which is lower than 0.3, but the image you just posted shows a different curve.