nli2work

This is the one mod that is true to the spirit of KSP.

like spanner mentioned. definitely check your rig setting first. should be Legacy. For transform rotation any current Unity version is alright. make sure you are using "Animation" component; not "Animator" component. Unity will set the correct component based on the rig setting. click "Reimport" after you've changed the rig setting just to be safe. this line determines what the action is named in Action Groups; probably why it's not visible because it's commented out in the Animation Module. actionGUIName = Toggle Direction do you have other Animation Modules on the same part? AnimateHeat/AnimateThrottle/AnimateGeneric don't play nice together for whatever reason, safest to use only one of them on a part, especially if bits on the part is affected by multiple animation clips. Test each animation clip to make sure they work alone, then add other animation modules and see what breaks.

which type animation is this? The Engine heat emissive? Engine throttle response animation? some generic animation? landing gear? animated lights? are multiple animations trying to move the same transform? unselectable part could be missing collision mesh; parts with no collision mesh will be unselectable once placed in the Editor. need a little more info on what you are trying to do.

for simple rotations in only 1 axis; Unity is fine. for complex rotations, blender might be easier to work with as Unity's curve display are not intuitive to work with. You might need an animation plugin like Firespitter or BahamutoD's if you are trying to get AnimateHeat and/or AnimateThrottle and/or AnimateGeneric all on one part.

you can't. short of making your own.

damn dude, looks FANTASTIC!

as long as sandbox mode stays. The game would need better tech and larger scope for the kind of resource play (restriction) you are suggesting. No way I would spend all that extra effort just so I can get to Jool with 1968 tech. If KSP had expanded tech like KSPI; and multiple solar systems, I might consider it.

Prerelease v0.3.x compability patch for the Karbonite Ed Retro-Future engines in case anyone needs it. http://www./download/bvz93hu0ucf5lf2/KaPre0.3.1Patch.zip

nope not forgotten, plugging away at the internal props and figuring out all the JSI internal goodies. sorry it's taking a long time. but good news is all 3 pods will get updated. not just one.

thanks for the heads up! I think it's because ScoopedAir is deprecated and new Karbonite engines use IntakeAtm ala KSPI. Will update it once Karbonite new version released. try this patch in the mean time http://www./download/bvz93hu0ucf5lf2/KaPre0.3.1Patch.zip

4x4 Engines!

Ah okay. I fiddled with the scale and got some movement. I think now it's just a matter of figuring out the right range and axis for the orientation. and actually modeling the prop... which would take a while.

yes; those are in the plans. just have to get around to doing them. I have several engine/blades in mind, a heavier landing gear perhaps. and some other parts as well. Update; links in OP Retro-Future v1.2 New Parts steerable tail gear fwd and rwd wing mounting pylons for 1.25m engines; arrow indicating direction toward airflow. warning sound for engine overheating Changes Technodes fixed for JeyTew and Trianka engines Nose gear can now steer Heat production and maximum temperature adjusted for all engines Main landing gear suspension strength increased

I see what you mean, the main purpose of the intake is to make the engines useble with FAR/NEAR; I didn't anticiplate it would lead to the issue you are experiencing, thanks for making me aware of it. I think the new update will fix the asymmetrical flameout problem. here I got 2x LF engines from Karbonite Pre 0.3.0, and I've closed the intake on the left engine. Both are running fine. no asymmetrical flameout. Following previous image, I close the right engine intake. symmetrical flameout results now that there is no open intake on the craft.

Sweet, I'm getting another update together, this compatibility fix and a few small things, will put it up soon. I've been testing with Karbonite LF engines as well as mine; explicitly defining IntakeAir as resource seemed to resolve the issue. No NREs or other game breaking problems with FNPlugin.AtmosphericIntake. Thanks for help testing!

pretty awesome, to say the least!

Looks like KSPI compatibility issue is resolved? I'm not getting any issues major or minor, with the Karbonite engines, nor with mine. No NREs related to FNPlugin.AtmosphericIntake in output_log.txt. An extra line of green bar in the right click window is small price to pay. Hurray! One thing with the LF Propfan, the FSengineSound module audio paths need updated to the new part folder names.

IntakeAtm is just IntakeAir with ModuleResourceIntake's checkForOxygen = false; so any gas will do for the engine. It's problematic if ModuleResourceIntake will only add to the resource if there is Oxygen. versus a simple check to allow engines to draw from resource if there is Oxygen. I haven't confirmed, but I believe if checkForOxygen is set to false; the engine will take any atmosphere, instead of only Laythe and Kerbin; same way IntakeAtm works. Not trying to sound contrairian; just asking naive questions based on my meager understanding of the source code and config files.

great models!

how many pics of anime girls will it take to change your mind?

speaking of resources... is there a reasonable way to consolidate Squad's IntakeAir; KSPI's IntakeAtm; and Karbonite's ScoopedAir in code? they are all essentially the same thing, just filtering for different stuff that's part of the planet's atmosphere.

Asymmetrical flameouts happen in upper atmosphere where air intake rate begins to fall below consumption rate. When vessel is not perfectly aligned to velocity vector, side intakes get differing amounts of IntakeAir. Total IntakeAir pool is not enough to feed all the engines adequetly. Engine gets priority to IntakeAir from closest Intake (itself), and that leads to asymmetrical flame outs and flat spins. it would be a problem if the thrust is asymmetrical even if the engines are placed with symmetry on. I hope this is not the case.

KSPI has it's own intake module AtmosphericIntake, that's probably automatically added. I'm testing with WaveFunction's experimental and the info window shows IntakeAtm and IntakeAir as one would expect. Looking at the FNPlugin.AtmosphericIntake source code, NRE during FixedUpdate() would mean IntakeAtm is not defined on the part or vessel. I'm guessing IntakeAtm is defined else where, based on the IntakeAir resource on the part. so undefined IntakeAir -> undefined IntakeAtm in FixedUpdate() -> NRE spam every frame. But I'll take a double display of IntakeAtm if it means no NREs+crash or other game breaking problems.

Officially I'll keep it without bottom stack node. like other stock turbojets. Nothing prevents you from editing your config to add stack node however. just remember to change the attachment rules to allowStack. this is normal to multiple air breathing engines, just part of the challenge in flying multi-engine aircraft. the blades are deceiving, they are Ultra High Bypass turbofans, or Unducted Turbofans. not the same as Turboprops. You can think of the one with visible blades as the other radial turbofan without the ducting. While the stack jet engine is a Turbojet. fluff aside; in terms of performance in game, KAE75Q and KAE-150R have similar thrust; KAE-150R has higher ISP and slightly heavier; while KAE-150S has worst ISP out of the 3, but much higher thrust.

nothing testy. all stock configs. just added stock Resource IntakeAir to engines, seemed like they were the source of KSPI incompatibility. It's similar to the 0 electric resource on stock engines. Resource is defined at 0; stock code adds tiny amount to the part when launched, enough not to trigger NaN error; but not enough to run the engine. Won't hurt anything, even if it doesn't solve the problem. I thnk the gist of it is KSPI has new IntakeAtm resource, which is added to parts that has IntakeAir resource. All parts that consume IntakeAir are set to consume IntakeAtm as well. Problem came up when I added ModuleResourceIntake to make the engines FAR compatible, parts with intake have 0 drag in FAR. Without Intake module, the blades radius makes FAR think there's a huge flat disc trying to go really fast, and FAR says "hell no". I didn't define IntakeAir resource since I don't want the engine to go without using separate Air Intakes. KSPI sees the engines consume IntakeAir, and set them to consume IntakeAtm as well. of course, no IntakeAir resource defined means no IntakeAtm defined, which leads to NRE spam and/or NaN errors, which in turn makes KSP go crazy.