blowfish

As a reminder, if KSP hangs at ModuleManager in the loading process (or any other time too), and you're asking for support, you need to provide an output log. There's no way to debug the issue otherwise.

And why is that so different from a jet nozzle? In both cases you've got a subsonic fluid accelerated to sonic through an area constriction (the nozzle throat), and then to supersonic speed through a diverging section. Rockets typically have much more extreme shapes because they operate at higher pressure, but the concept is exactly the same.

ferram4 doesn't update the CKAN metadata. It should update automatically within a day or two.

Well, theoretically at high speeds you could start throttling the compressor to keep it cool - i.e. dumping more of the incoming air's heat into the fuel rather than extracting useful work (sacrificing thrust and some efficiency). But this shouldn't really matter until you're approaching mach 5 already. I should clarify - by nozzle throat I mean the throat of the exit nozzle, not the compressor. Generally you don't want anything else to choke - if something is restricting mass flow more than the nozzle then the nozzle might not choke and thus would fail to produce supersonic thrust. The turbine also limits mass flow in conventional jet engines, but for all supersonic designs the nozzle throat area is variable so that doesn't matter.

Well, it's not the rocket that's overheating, but the compressor. Turbocompressors are limited to about 1000-1200K in practice. Well "max demand" is slightly complicated here, since the maximum mass flow you can put through a given unit area depends on pressure and temperature (see this). In jet mode the chamber pressure is going to vary a lot. The compressor needs to be able to push enough to choke the nozzle throat at all flight conditions.

So I've been talking with NathanKell, who is the primary author of ModuleAnimateEmissive. It turns out that as a result of his involvement with Squad (and general awesomeness), most of the features of ModuleAnimatEmissive have now been integrated into ModuleAnimateHeat. However, the new (correct) way to do engine thermal anims is with FXModuleAnimateThrottle. So in the interim, the fix I posted will actually keep the thermal anims as they are, and in the long run, I'll make sure that the change to FXModuleAnimateThrottle gets integrated into the community fixes. - - - Updated - - - As a friendly warning, it is against the forum rules to post a plugin without a license and source. But given the information I just posted above, could I request that you take it down? ModuleAnimateEmissive is redundant now, and the conflicting fields, which you probably got warnings about when you compiled, might cause unexpected behavior.

Welcome to the forums The output log would be a good place to start. It's usually quite simple to identify the problem from it.

You never cease to amaze

There's no reason to expect that FAR would work immediately with 1.0.5. Be patient

Looks like it's still happening. And it's possible that it's because I forgot a small part of the patch. Try this: @PART[KW*]:HAS[@MODULE[ModuleAnimateEmissive]]:[b]FINAL[/b] { @MODULE[ModuleAnimateEmissive] { @name = ModuleAnimateHeat } }

It's possible I messed something up. But post your output log (as usual) and we can say for sure.

This is really a stopgap workaround rather than a fix. ModuleAnimateEmissive should get a patch within the next couple of days (it's part of SolverEngines which I contribute to). This workaround is really intended for people who can't wait but are willing to put in a bit of effort to keep playing in the mean time.

It does. Like I said above, ModuleAnimateEmissive (a separate plugin which is bundled with KW) will be fixed in due time. If you don't mind opening up a few cfg files there are workarounds in the mean time. Actually, how about this. Anyone who wants a temporary workaround, follow these steps: 1) Install the community fixes if you haven't already. 2) Make sure Module Manager 2.6.13 is installed or upgraded. This is the 1.0.5 version. 3) Place the following code in a new .cfg file somewhere in GameData. If you're not feeling creative, call it AnimateEmissiveTempFix.cfg and place it in GameData/KWRocketry @PART[KW*]:HAS[@MODULE[ModuleAnimateEmissive]]:FINAL { @MODULE[ModuleAnimateEmissive] { @name = ModuleAnimateHeat } } Like I said, the emissives won't work properly, but it should prevent the game from freezing. Let me know how it works

If no logs are generated by this point, then your KSP install is very broken and there's nothing anyone can do to help you. But please check for logs again. You are looking for KSP_Data\output_log.txt (Windows) or ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log (Linux).

My understanding is that this was planned for 1.1. If it didn't show up in the release notes then that's probably the case. If you need multiple modules modifying mass (say that 5 times fast! ) before then, I have a workaround I could show you

What Svm420 said. The relevant file is KSP_Data/output_log.txt. It almost always shows the error even if KSP freezes or crashes. - - - Updated - - - And with Nansuchao's log, I've determined that the error is in ModuleAnimateEmissive. It will be fixed in due time. If you want a workaround in the mean time change it back to ModuleAnimateHeat. The heat anims won't work properly but you won't get the error. And Nansuchao: I also see errors related to Interstellar, RasterPropMonitor, and Pilot Assistant. Doesn't look like they're fatal but something to be aware of if you see any more issues.

Then you would know that 2.6.13 was recompile for KSP 1.0.5. Of course I don't know exactly how much testing sarbian did for this update, but given the scope of the changes in 1.0.5 it's unlikely that anything in MM broke, so a simple recompile should be sufficient for now.

Well, if it is broken, then it would help others to diagnose the problem if you posted your output log.

You might want to read the post above yours

There's cryogenic fuel flowing through many of the pipes and the nozzle. So while the inner surface of many of the parts might be quite hot, the outer surface might be very cold. I'm not sure if icicles would form in a vacuum (though the exhaust is mostly water vapor so it's possible).

Matching intake flow and engine flow in supersonic engines is a nontrivial problem. At subsonic speeds, excess air can just spill around the intake, but at supersonic speeds, there's no way for conditions downstream of the intake to affect what the intake is doing. Flow through the core of the engine is usually limited by choking in the turbine (and the nozzle throat, but that's usually adjustable in supersonic engines). The SABRE doesn't have a turbine to choke, but presumably the nozzle throat is fixed. Theoretically, there's no limit to how much air you can force through a jet engine - you just need to increase the total pressure at the compressor. In practice though, inefficiencies of the intake begin to reduce the total pressure at higher mach numbers, and of course eventually the engine would be unable to handle that amount of pressure and explode (though it'd be rare that this would actually matter in reality). Yeah, I'm not quite sure why that would be. If you figure it out let me know The current RAPIER thrust runs away until it overheats though, which is convenient but doesn't seem right ( plus it ends up using massively more fuel than in vac mode which is definitely not right ).

There is almost certainly a ModuleManager patch, as part of a different mod, which is doing this. If you want to determine which one, please post your output log (see this for how to find that) as well as the name (note: not title!) of the part you are creating.

Well, the cycle is different, but the SABRE should have many of the same characteristics as a conventional jet. Thrust will grow with speed, as ram pressure increases, top speed will be limited by compressor heating (though when this happens will of course be very different because of the precooling). One of the major differences is that the rising intake temperature actually increases the amount of energy available to the helium loop and thus the compressor, so compression ratio (and thus efficiency) will not drop in the same way it would in a normal jet engine. - - - Updated - - - It's pretty easy to add configs, but I don't want to add a bunch of engines to AJE that I don't have time to test. If you like, I can walk you through creating new engine configs. - - - Updated - - - Depends on the engine. The J-58 has stock effects. All of the B9 engines have effects included in B9. Most of the others require HotRockets or RealPlume, though I'm not sure the afterburner thresholds are set properly.

It doesn't look like that chart has been updated post 1.x - a lot of the stock engines have had major changes since then.

Amazing mod, but can I ask what the purpose of this patch is: @PART[procedural*]:FINAL { @MODULE[ProceduralPart] { %diameterLargeStep = 1.25 %diameterSmallStep = 0.1 %lengthSmallStep = 0.1 } @MODULE[ProceduralShapeCylinder] { @diameter *= 1.25 } @MODULE[ProceduralShapeCone] { @topDiameter *= 1.25 @bottomDiameter *= 1.25 } @MODULE[ProceduralShapePill] { @diameter *= 1.25 @fillet *= 1.25 } @MODULE[ProceduralShapeBezierCone] { @topDiameter *= 1.25 @bottomDiameter *= 1.25 } @MODULE[ProceduralSRB] { %thrust1m = 500 } } It causes the diameters to default to a bizarre 1.5625m, and the large diameter increment (1.25m) is not a multiple of the small diameter increment (0.1m). Since 64k doesn't change the sizes of any stock parts, wouldn't it make sense to just leave these at the defaults (default diameter 1.25m, large increment 1.25m, small increment 0.125m)?