blowfish

Okay, so there's definitely a problem, but FAR doesn't usually do that so there must be something telling it to voxelize constantly (not sure what it is though).

Seems to be working fine for most people. Try reinstalling it and if that doesn't work post an output log in the Kerbal Flight Data thread.

Vessels aren't re-voxelized constantly, only after staging events and every so often during animations. If you're getting a slowdown, it's probably not FAR.

The real situation is certainly more complicated than I proposed. The biggest limitation for the current system is what we only have an approximation of the mass flow rather rather than actual compressor maps. The documentation I've seen suggests that actuation of the adjustable nozzle is mach dependent (mostly based on documentation of the J58 and Olympus 593), but there may be other conditions where actuation happens. This is complicated by the fact that (AFAIK) some engines actuate the converging and diverging parts separately, whereas others don't. The nozzle flaps may be passive in some cases too, so that their position is set by balancing ambient pressure with exit pressure (if possible). So do you have a proposal for how this should work? The two things that need to be determined are the exit velocity and exit pressure.

No one has answered because there's not a definite answer. There are known bugs but it's difficult to say if they're game-breaking.

Yes, because things haven't been updated to work with 1.0.x yet. It's on the to-do list. - - - Updated - - - Does TweakScale know how to deal with FSFuelSwitch? It's one of those things that requires more than a simple exponent.

You usually don't need those struts to begin with if you use KJR.

It is, but you need both the main download from the OP and Crzyrndm's patch which updates the plugin (among other things).

It does seem odd that KSP gives you access to the basic jet before the liquid fuel fuselage, doesn't it...

JiKahn: you're going to have to provide a full output_log.txt if you want anyone to even look at exceptions.

Ah yeah. Well, you can still put tier 0 fins on. Maybe turn on FAR's stability assistants too - they do seem to help a bit.

Maybe put some tier 0 fins on the upper stage and put the mystery goo inside a service compartment.

There are a few things that need collider updates to work properly with voxelization. Also the VTOL fan wing has no FAR wing module (though that was never designed to work on parts with other features so it won't deal with things like added mass properly).

You're correct, it will not. There were a substantial number of API changes that took place in 1.0, meaning that some very significant changes had to take place with respect to how plugins like FAR interact with the game. So for now you'll either just have to live with with older versions of FAR (0.14.x) or accept a smaller list of mods (or learn to mod and update them yourself ).

I've thought about the question of subsonic engines and nozzles a bit and I'm proposing the following solution: First, how it currently works: The exit velocity is calculated assuming an isentropic expansion to ambient pressure. The exit pressure is ambient unless the flow chokes. My solution would have two nozzle types: convergent and adjustable. A convergent nozzle would have its exit velocity capped at the speed of sound. Exit pressure would be ambient unless the flow chokes (same as current). Adjustable nozzles would operate the same as convergent nozzles at subsonic speeds. At supersonic speeds, the exit velocity would no longer be capped and the exit pressure would always be ambient (since the divergent part of the nozzle expands the flow beyond sonic conditions). If this solution is agreeable to everyone, I'll implement it. It doesn't account for all of the effects involved but it seems like it would satisfy the complaints that have been levied against the current system, and it's a pretty easy change.

And credit to V8jester and M4ck for their contributions to the compatibility port. If any one else is interested in contributing to the compatibility port, you can find it at https://bitbucket.org/blowfishpro/b9-aerospace. It is far from done of course. I've created a compatibility checklist in the repository, copied below for convenience. If you're interested in helping with the compatibility push, either send me the changed files of submit a pull request on bitbucket (preferred, but I understand that not everyone knows how to use Git). I know for a fact that I won't have huge amounts of time in the coming weeks to work on this, but I'll make updates as time allows. ------------------------------------- B9 1.0.2 Compatibility Checklist May not be complete Already Done Stack node adjustments by V8jester and M4ck Most textures converted to DDS CrossFeedEnabler, Firespitter, JSI, KM_Gimbal, SmokeScreen updates To do Recompile KineTechAnimation and Virgin Kalactic which have not been updated Convert remaining textures to DDS (missed by DDS4KSP) Re-entry thermals Jet engine configs velCurve defines thrust vs mach atmCurve defines thrust vs density tempMachLimit and machHeatMultiplier set mach limits on engine operation [*]Cargo bays need new module for 1.0 aero [*]All wings need adjustment for 1.0 aero (FAR should still be fine) [*]Unknown if bizarre drag behavior still applies to intakes in stock aero [*]bulkhead profiles [*]See if ResGen is still necessary for compressed air thrusters

Keep in mind that even with the attach nodes fixed, there is still a lot that won't behave properly in 1.0.2. This includes heating, cargo bays, and air-breathing engines.

Ignore the CoL indicator and do static analysis (you probably want to turn it upside down though to assure that the bottom is pointing into the airstream though).

The payload bay needs the new module for stock aero. The engines need a velCurve (thrust vs mach) and an atmCurve (thrust vs density). Some parameters probably need to be adjusted for the new reentry heating system. I think that's it...

I thought the alignment guide wasn't supposed to exist anymore...

I loaded the included .craft file. That still works.

The module in question is KModuleAnimateIntakeAir, which is part of KineTechAnimation. If a module can't be found KSP usually just warns in the output log and continues. Perhaps you have an old version of KineTechAnimation sitting around in your GameData folder somewhere which is making it think that the module is there but failing when it actually tries to create one? That plugin hasn't been updated in a while.

I didn't try to fly it - I just loaded in the VAB to look at area ruling, though this did require changing the CRP resource names (LiquidHydrogen->LqdHydrogen and the same with oxygen). Not sure what the error you're getting is.

Not bad for a craft of this size, though perhaps a little room for improvement. I'm surprised REL didn't extend the central fuselage narrowing back a bit to match the end of the engine nacelle, though perhaps FAR doesn't account for the effects of engine inlets and exhaust on area ruling. Anyway, I've learned information that may solve many of the FAR issues. FAR relies on the wing being oriented along a certain axis. I think the plane of the wing has to be perpendicular to the y axis, but don't quote me on that (it's however the stock wings are oriented). Of course, this would require rotating the attach nodes a bit. Pitch stability (or the lack thereof) will still be an issue but I suppose one thing at a time...

The DCoM is still there, just the field in the GUI that told you the offset in meters is gone.