nli2work

actually looks like the ship has been made already. http://forum.kerbalspaceprogram.com/threads/91706

the low hanging fruit

looks pretty stock alike... the brown, gray, and yellow/black. it's shipping RCS fuel.

I've increased the suspension on all landing gears in 1.6.2; are they still too mushy? Yes I know, the initial direction is odd to say the least. partly because it's a hacky way of doing side deploy gears and still use landing gear module (unless you want to use action group to deploy them and have no suspension); but only way I can think of without a plugin. In game one gear is pointed forward, the other is backward. I may be able to improve it some fiddling with the attach node directions.

it'd be surface attach. you can stick it anywhere. mount it on the underside of the rover, drive over a docking port jr. extend yours and dock. tough part is getting the distance correct... might be able to use FS module to get some flexibility

the Gear should work fine. I tested it briefly before in 0.25 and everything appeared functional.

if you want the spinny blades sure, FS Propeller spinner will let you spin the blades based on speed, which is nice. a simple tube would work just as well. make sure you have an extra transform for ModuleResourceIntake.

actually that'd be a nice part to have... I'll add it to my to do list. extending 0.625 docking port surface attach.

Bahamuto's Lightning cockpit, requires B9

KAX: http://forum.kerbalspaceprogram.com/threads/76668 RF has 5 or 6 different gears. 1 or 2 in the pipeline.

you can try an engine module with very low thrust (0.0001) and high alternator output; set it's velocity curve to run from speed X to Y (non zero, so it doesn't work when not moving); and set it to consume very small electric charge and some intake air (0.01 EC vs 10 IntakeAir). and you have a wind turbine

MODEL{} is updated node system. it should be used in place of the old mesh = and texture = lines

the jets sound the way they do because they were too loud for the mics, sampled maybe 100ft behind a J79 at a turbine shop in Canada. Some of it sampled from a camera mounted on top of the engine body, mixed in with the rest. They were the best ones I can find. Otherwise it'd be some sound fx clips that are too soft and distant. I don't know anything about old time ramjets, feel free to adjust the configs to your liking. I'll flip the model so it looks like the pics I find online, small end forward, and change the thrust curves a bit. I'll add a 2nd thrustTransform so you can flip it and use it as pulsejet if you want. There's no good way to do these in KSP using only velocity curves and I don't want to spend too much time noodling with them. Got a whole back log of IVAs I need to do haha

really? they don't seem any better than B9's F119, both around IIRC 120kN in FAR. I had to up their thrust a bit since FAR 14.2 after wing mass/area was added. my planes were 1.5 to 2x heavier and I barely get 1 TWR with 2 engines. Upper end of velocity curve maybe a wee bit high.. mach 4.4 ish. Maybe I should bring it back down a notch. I have no clue how any of my parts behave without FAR.

yes, textures generally the most memory expensive asset; always best to share across different parts if possible. use this in the part config instead of mesh = blahblah.mu MODEL{ model = GameData/your/part/path/part (no mu extension) texture = texture1, GameData/your/textures/location/texture1 repeat texture lines as necessary. scale = x,y,z rotation = x,y,z position = x,y,z }

x64 is the problem. get ActiveTextureManagement and drop to x86.

it's to keep memory footprint low. All textures are loaded by KSP, which means any alternate textures take up memory even if you are not using them on a part. much cheaper memory wise to use FSmeshSwitch as far as templates, it's easier to think of the textures as atlased than trying to overlay UV patches on them. Upper left you have the basic panel section, lower left is one of the end caps; top right is 2nd type of endcap, a sort of internal crew hatch; lower right is 2nd type of panel that doesn't change color between the two color schemes. So you can make a part and sample the different texture sections by cutting up the UV accordingly. That said, it should be easy to create masks for use with Kerbpaint. The white top/black bottom was my attempt at stock-alike, pretty lousy; it's either too bright or too dark. Going all stock-alike texture wise is unlikely. I like the "tin can dragged a few miles on the road look" as you might have guessed, and that's not at all close to Squad's aesthetics. Some point in the future I might dirty/chip up the textures even more than they are now.

internalRPM.cfg refers to the internal MU file. that should be in the same folder. you can change it to use MODEL{}; in that case you can move it somewhere else as long as you give it correct paths. but given I don't know the original assets and what Squad changed, the only way to be sure the internal loads correctly is to place the INTERNAL config in the same folder as MU and textures. Mk2CockpitsRPM.cfg can be anywhere in GameData/

this mod is making me thinking I should get an analogue controller instead of using keyboard to fly.

depending on the normal map generator you might need to Invert the Green channel.

trans sonic vapor cone thanks to SmokeScreen

the scuffs can be simulated with directional motion blur on a high contrast noise map; or the crosshatch artistic filter. the smudge brush can do it as well if you hold down shift and click on two points, PS will run a stroke between the two points, set the fade distance (in pixels) on the brush to make the stroke taper/fade off.

that can be arranged. easy one to set up.

whats the output_log? RPM will display this error if there is an incorrect configuration setting in the prop config, like a missing variable. But the source of the problem can be far removed from RPM.

copy those two configs to the folder locations 1. GameData/Squad/SPP/Mk2CockpitStandardInternal/internalRPM.cfg 2. GameData/Squad/SPP/Mk2CockpitsRPM.cfg