nli2work

Yeah, it's something I've been trying to sort out for along time. still not successful. collider box will be correct as long as you make the wing larger than default size, but when not when it's smaller than default size. I'll ask DYJ when I get back.

yar... I been editing #4 to correct the MM patch. I was missing a bracket initially. I think this should actually work @PART[*]:HAS[@MODULE[ModuleDockingNode]]:FINAL //applied after everything else { [INDENT]@MODULE[ModuleDockingNode] { [INDENT]%acquireForce = 0.1 //adds acquireForce if not specified; changes to 0.1 if is specified; stock value is 2 if not specified in part CFG. %acquireTorque = 0.1 //same as above[/INDENT] }[/INDENT] } I'm still not very good with the voodoo that is MM.

you can look at the code with Unity's Monodevelop IDE. the stock modules are not well documented, and not all the settings are visible by looking at the configs. This is one way to dig a little further than the config files. here's the ModuleDockingNode. some of them you see in the part config, some not. generally a public variable in a part module can be manipulated through the part's config settings. But the rub is not all of them are used in the module, if you know C# well you can look deeper and see which ones are and which ones aren't. The other setting you can try adjusting is captureMaxRvel. I'd experiment with just one docking port on the launch pad, use ALT-F12 to turn off gravity. if you find a setting that works, you can use MM to apply it to all docking ports. *Edit: I figured using *= would edit the default values; should have realized MM only deals with what's written in the config files.

I don't quite understand the problem. you are talking about the transparent pods? which cockpit are you referring to?

ahahah. wait till you see this other thing! don't worry about the beams. I'll lower the opacity a bit more. little too much at the moment. What would really be seks is true IK with upTargetNodes.

try changing the % to @; Final may have to be all Caps. not sure on that one. TweakableEverything is good too. *Yep, it was the %, and FINAL. change those and the errors should be gone.

this should do the trick; needs ModuleManager copy/paste this into a text file and change extension to *.cfg; place in GameData, it should set all parts with ModuleDockingNode to 10% of specified acquireForce and Torque @PART[*]:HAS[@MODULE[ModuleDockingNode]]:FINAL { [INDENT]@MODULE[ModuleDockingNode] { [INDENT]%acquireForce = 0.1 %acquireTorque = 0.1[/INDENT] }[/INDENT] } delete the cfg from GameData to unapply or if it doesn't work.

this might give you some ideas http://forum.kerbalspaceprogram.com/threads/98684-IDEA-REQUEST-Diverting-Jet-Thrust

Yes that's the basics. # of shaders; size of the textures; smoothing groups; UV layouts; all affect the rendering costs per frame, strictly speaking. biggest bottle neck is texture size and # of textures. geometry is practically free. I subdivided those different setups to 9~12k triangles each, and they sit around 0.2ms per frame, no different than if they are 12~48 triangles

@Hodo, there should be one in there. very simple part, should load without any problems @DarkProphet, hm... hard to say. The only time the tanks setups change is if ModularFuelTanks is installed, in which case FS fuel switch is removed, and replaced with MFT's fuel module. The mesh switch will only change the color coding on the tanks. post the output_log.txt from KSP_Data; maybe there's something in there to tell what the problem is.

sure beams in vacuum aren't realistic. but it looks nice. engines has proper FX now, also reverse thrust for towing. Best part is Lo-fi's wizardry that shifts the engines around the center allowing you to shift CoT on the fly. also MM extensions for various mods... mostly visuals and customization options. some will get extra functionality later. TRReflections Regolith SCANsat TheWriteStuff ModularFuelTanks

also courtesy of frizzank Free student versions of Max; Maya w/ 3yr license free PS CS2 http://forum.kerbalspaceprogram.com/threads/102635-Free-Software-Max-Maya-Photoshop-CS2

very nice parts and textures! just like stock.

I just looked at some pics of Philotical's NCI mod. some of the objects are very large. Looks KSP doesn't have problems handling something like an orbital construction dock for building ships kms in size. NCI appears to manipulate physics range so that maybe part of the reason it has objects much larger than 2.5km.

very cool!

I don't know what the size limit is, if any. Philotical says he's made objects up to 17km. though I had trouble getting a 1500m, very light part to do anything other than float in space.

EPL builds subassemblies that you save in the Editor with "Rocket Parts" resource, which is converted from metal, which is converted from Ore you dig up from the surface somewhere. I figure down in the code it's more less the same, just different names. whether you require the "Rocket Parts" resource being launched from a planet's surface, where the other conversions are done on the surface; or launching "Ore" from the surface and do the conversions in space isn't terribly different. I mean it's different game play wise; but for code, it's the same either way. At least that's what I figured from looking at the part modules and source. haven't actually played with the mod yet.

really? I tested a part that's 1500m and the shadwos were all messed up and none of the controls respond. and what is NCI?

wouldn't this be very similar to EPL? And yes I've been thinking about the same thing. ships larger than 100m assembled with modules that are built in orbit. though I figured I would simply rely on the EPL mechanics for everything, plus a one-shot docking module for assembling the ship chunks. KSP seems to handle mid size ships up to 400m alright. not sure what the upper bound is, less than 1500m I'm pretty sure.

CS2 link is truncated. 404.

I suggest taking some time to get familiar with Blender making some simple KSP parts like fuel tanks and probe cores. the link above have all the information you need.

Huh, didn't guess that from the config file. Good to know!

Thanks! That's extremely helpful. Does ModuleAnimationGroup apply to Analyzer/Scanner? Doesn't appear to from what I saw yesterday on github. It makes sense not to as analyzer/scanners are basically automatic; but would nice if there is ON/OFF for analyzer/scanners. like KSPI's analyzers.

you need one for every texture (Normal; Diffuse; Emissive) referenced by MODEL{}, file name has to be exact match. those that aren't shared can stay in the part folder and not reference them in MODEL{}. KSP loads everything (used or not) in GameData; and MODEL{} texture replacement happens during part compile phase. if a texture isn't being replaced using MODEL{}, KSP will look for it in the same folder as the MU. I haven't had any problems doing things that way, but a few has run into issues where MODEL{} doesn't replace textures correctly preventing parts from compiling correctly. another option is export everything with dummy texture to begin with. and your MODEL{} would look something like this MODEL{ model = model path texture = dummyDIF, Diffuse texture path texture = dummyNRM, Normal texture path texture = dummyEMI, Emissive texture path //Only necessary if other than 0,0,0 and 1,1,1 postion = x,y,z rotation = x,y,z scale = x,y,z }

you need a dummy texture in the part folders for MODEL{}. I export the proper MBM textures with the 1st part; move the MBMs to the centralized folder for the pack; export the part again but with different texture format like PNG, resize those PNGs to 1x1; one color PNG is 1KB. now export the rest of the parts into their part folders, texture format doesn't matter at this point. copy the 1x1 dummies to all the subsequent parts that share the same texture; and delete the full size textures in those part folders. for future part updates, export one of the parts with format you use for actual textures, move those into the centralized location and replace the old textures, and that updates textures for all the parts that share the texture. other part updates (new mesh or UV) just export to a different format than what you use for the dummy textures, and delete the new exported textures, keeping the dummies in the part folders.