blowfish

Hello! Just popping in to say that I noticed an issue with one of the configs: @PART[*]:HAS[@MODULE[ModuleEngines*],!PROPELLANT[IntakeAir]]:FOR[EngineLight] This will check wither the part has a PROPELLANT node with name = IntakeAir, which will always be false, since the PROPELLANT node is on the ModuleEngines. I think you want @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[!PROPELLANT[IntakeAir]]]:FOR[EngineLight] The nested HAS block will check the ModuleEngines* for that PROPELLANT node

RealFuels v12.0.1 for KSP 1.2.2 is now released! Fix TestFlight integration Fix engine configs in career that aren't unlocked by upgrade nodes Fix harmless but noisy error message when using thrust curves

I'd recommend writing a ModuleManager patch to do whatever you want to do. Editing real .cfg files becomes pretty painful once the mod releases a few new versions and you have to edit it every time.

It is being done due to absence. bac9 didn't seem completely attached to the idea of keeping the same thread when we first discussed it though (I can copy that conversation over PM if you'd like to see it)

@Flashblade and I (and others who are willing to help) have been maintaining B9, with permission from the original authors, for more than a year and a half now. We originally kept the original thread with the intention that we would be able to contact bac9 after each release to update the OP. bac9 has recently gone dark, which has made releasing updates rather difficult. So my question is this. If we create a new thread, would someone from the moderation team be able to update the OP of the original thread so that it links to the new one?

Might want to report that in the RF Stockalike thread.

Yes. No need to indent the brackets though It would look like this: @PART[part1|part2] { .... } Notice the vertical bar | separating the names of parts. This patch will affect part1 and part2

Few things You probably want @TechRequired = start since the part already has TechRequired. Otherwise it will just add another TechRequired value to the node (which one will take priority isn't well defined) You can put as many patches as you want in the same file, e.g. @PART[part1] { ...} @PART[part2] { ... } You can target multiple parts with the same patch. e.g. @PART[part1|part2|part3] { ... } (note that this syntax only works for top level nodes though) Alternately, there might be some identifying feature of all the parts you want to target. Then you can use a HAS block to filter them

Torque and power are physically different things. Torque can be thought of as how much you're pushing the wheel to rotate, which is independent of how much kinetic energy you're actually imparting to the wheel. Torque is the rotational equivalent of force.

Just curious, what was what was your plan for tackling this? After messing with the B9 gear which are set up similarly, I'm fairly confident that ALG can be converted to KSPWheel, but it will involve a fair number of code changes (probably even a few to KSPWheel itself). I would hate to duplicate effort here, even as far as researching goes.

Be careful with your generalizations. I help people with support requests and problems all the time. My only issue is when the information at hand is readily available and the person in question can't be bothered to find it on their own.

Then go study (or at least sleep) and worry about FAR's status when you have the time to. It's not like anything is going to change between now and then. (just to be clear, I'm not singling you out here. There are probably thousands of "status update plz" posts on this forum. Just answering them would encourage more, so the answer has to be no every time, regardless of circumstance)

No, but I can tell you the shortcut of going to ferram4's profile and looking for posts there.

If you read a few posts above yours you might get hints as to the answer. If you read a few pages back, you might actually see a post from the author explaining the current status.

So I spent a day trying to get the wheels working with @Shadowmage's new wheel implementation Initial results have been good. It didn't require any model changes, but did require code changes to both KSPWheel (PR already submitted) and B9PartSwitch. KSPWheel should still be considered an early beta as well, so bundling it with B9 is out of the question. Best I could probably offer if this goes through is that the wheels would show up if you installed KSPWheel separately. This also bodes well for converting Adjustable Landing Gear, especially since no model changes where necessary.

It wouldn't actually help with wobblyness at all. All joints between parts in KSP are actually a single point.

I know the cycle, no need to keep posting the diagram. Except that after being compressed to 15 MPa, the temperature is going to be more like 400K (lower bound based on quick calculation - incoming air is cooled just above boiling point of ~82K then compressed). According to REL, the temperature of the incoming air at sea level is too low for the helium loop to drive the compressor, so heat has to be bled off after the preburner (HX3 in the diagram you posted). The ambient pressure when the vehicle is going mach 5 is going to be much lower then when the vehicle is at sea level. Thrust increases as the ambient pressure falls away. There's definitely somewhat of a loss in headroom, but it's not going to be as much as you say, and definitely not enough that you'd loose thrust before other things start breaking. And I realized I didn't address some of your points from the last post, so here they are: Mach number alone can be somewhat misleading here, as total temperature actually increases with the square of mach number. At mach 5 it's about double what it is at mach 3.5 (in kelvins). The SR-71 managed to go as fast as it did by only compressing the air a little, and is limited by the temperature of the air exiting the compressor. At mach 5, the air is hot enough that it would melt the compressor at the entry point (hence precooling). The SR-72 would use a scramjet, which relies only on ram compression (although the cycle is somewhat different). These are both aircraft intended for use in-atmosphere. They can burn a lot of fuel if need be. The Skylon would need to generate ~6 km/s in rocket delta-v after changing modes, so the cost of low efficiency in air-breathing mode is much higher.

Where does that limit come from? Recall that the SSME's chamber temperature is closer to 3600K, and that's pretty fuel rich. This doc puts the air exiting the compressor at 853K, which isn't anywhere close. That's for the SCIMITAR, true, but there's no reason to believe that the cycle is any different in air-breathing mode. According to the real engines I've seen, the compressor will likely overheat around 1200K or so. I think the main limitation on the compressor is that it's quite hard to cool (whereas the precooler is actively cooled by helium passing through it). At 1200K, you can still add quite a lot of heat by combustion before encountering limits on anything downstream of the compressor.

Notice in the last picture how the control surfaces on the wing are deploying in opposite directions? That causes drag on that side and allows the flight control software (or SAS, to a lesser extent) to fight the natural yaw instability. I think there's a control surface setting for that in FAR but I don't remember what it's called.

The Unity 5 upgrade broke all existing landing gear in KSP. Without access to the original source files (which I don't have) it would be almost impossible to fix them.

That probably means that there are holes in the collider mesh.

Probably because there's a global patch which changes the RCS but the main engine still expects Monopropellant.

To my knowledge, RF Stockalike (which is what is presumably being asked about here) has not been set up to work with SSTU.

Also I PM'ed BahamutoD asking for the source models. We'll see if that goes anywhere.

Okay, maybe try removing the Assembly-CSharp reference and re-adding it. Also, if you open the .csproj file in a text editor, can you find KSPUtil in it anywhere?