Jump to content

nli2work

Members
  • Posts

    2,836
  • Joined

  • Last visited

Everything posted by nli2work

  1. I tend to keep things as simple as possible, straight FK whenever I can. you can rig as much as you like in Maya, just bake the animation when export to FBX.
  2. what lo-fi said; http://i.imgur.com/vzNnRqo.jpg
  3. 1. animate before export to KSP. whether you animate before Unity, or with Unity, doesn't matter. 2. yes, as long as ctrlSrf_obj is aligned with +X-right, +Y-forward in SPH; that's all you need to do. 3. simple animate of opening will be enough. animateGeneric will reverse animate clip automatically when you close the doors.
  4. prefab smoke emitters go in -Y direction (not +Z like thrust), so you need a separate transform for smoke trails. it's odd ball... but dem's the breaks.
  5. transformName = in PREFAB_PARTICLE{} or MODEL_MULTI_PARTICLE{} is where a particle FX is placed when the engine is running thrustVectorTransformName = in ModuleEngine{} or ModuleEngineFX{} is where force is applied when engine is running. a collider directly behind (up to 10m I think) the transform will "block" the exhaust and 0 force will be applied. they can use the same transform, or different transforms. all transforms with the same name will have the same particle FX. location of thrust is the average position of transforms given to thrustVectorTransformName =
  6. if you want more than 2 options; you might be able to do it with without MultiModeEngine (that only switches between mode A and B, and can't have both at the same time). then set action groups in game to toggle different sets. you may be able to set different transforms to the same ModuleEngine though I don't know what syntax it would require, I can't say for sure if it'll work, never tried having multiple engine modules on a part without ModuleMultiMode
  7. you would have to have groups of thrust transform with different names, then set each engine mode to use different set of thrust transforms. center one might be thrustTransformCenter; outside ones might be thrustTransformOuter (all share the same name)
  8. mind sending me the broken project files? I'm curious... I recalling dealing with something like this a while back, but didn't pay much attention at the time. can't recall what I did to fix it problem.
  9. any clear resolution? anything strange turn up in the animation clip? removing the unrelated object from export tree fix the issue? I see "getName()" and I'm thinking it may have something to do with an object's name, a space in the name maybe... I'm collecting various errors for a troubleshooting guide. this would make a good entry, breaks pipeline and uncommon.
  10. something wrong with the animation clip most likely. check for stray animation curves on objects/properties that shouldn't have them (anything you don't intend to animate should not have keyframe or animation curve). little gray diamond indicates animation curve, so check the objects that has those. or some intended animation curve maybe corrupted, for the lack of a better word... you may need to recreate the animation clip.
  11. open up the console and watch the messages as you export a model. when adding animation, make sure you are using "Animation" component, not "Animator" component. the screenshot doesn't show anything extraordinary.
  12. generate normal/AO/Spec/Displacement map in your browser! appears quite flexible. http://cpetry.github.io/NormalMap-Online/ nVidia's stand alone normal map baker http://www.nvidia.com/object/melody_home.html
  13. for baking (sometimes called projecting) you need a 3d app, Max; Maya; Modo; Blender; etc. You need a game mesh with UV set, plus a high poly detail mesh (uv is unimportant). baking has the advantage of letting you quickly generate base maps for diffuse, specular, ambient occlusion, etc, at the same time as you generate your normal map. it can speed up your texture process quite a bit. for converting, you need some image editor like PS or GIMP and appropriate plugin like nDo, or http://cpetry.github.io/NormalMap-Online/, or nVidia's PS tools. a lot of options. advantage is speed in iteration. you can see changes in the normal map output very quickly by updating your source image.
  14. I'm Back still adjusting jet lag and processing photos from the trip. will ease back into KSP as time allows. haven't touched 0.9 yet. I expect RF to work for the most part, as long as plugins are updated. Firespitter DLL is updated to 0.9 I think, @ snjo.github.io; FSCoolant resource is only necessary if you use electric engines from FS or KAX, make sure the resource is properly defined for KSP in GameData/Firespitter/Resources/ TRReflections MM patch is the lowest hanging fruit and I'll probably do that first. larger airbreathing engines seems to be a niche that needs to be filled with the new MKIII space plane parts.
  15. add this to the cockpit part config INTERNAL { name = IVAView //name of the compiled internal space } you can check the part configs of cockpits that has IVA you want and copy it to the cockpit without IVA.
  16. use the "Create from Grayscale" option and use the new slider to adjust amount of bump. It's difficult to paint a normal map by hand without knowing how tangent space normal maps work. best option is use Unity to generate one, 3rd party plugin, or directly from 3d app.
  17. you guessed right, what you see is normal. if you want super clean edges between color blocks in your design, best way is split UV patches by color blocks; though that has comes with it's own limitations. Even then, you will still see stair-casing in game depending on your game/videocard FSAA settings PS. DPI doesn't mean anything unless you are printing. 1 pixel is 1 dot, whether it's 72dpi or 7200 dpi.
  18. I noticed dropped props don't stick around when switching away then back to the kerbal. is that normal?
  19. right click on the external camers and set them to different ID # with the +/- buttons.
  20. LOL. yeah there was talks about that. I suspect not much activity will happen till after new years.
  21. on a different note. anyone intrested in 3d prints of some of the RF parts? something like this http://shpws.me/zYrQ. some assembly will be necessary of course. Space Tug pack DEV 0.4 download in OP
  22. I think this could work like the pro-props thread. OP lists part topics, and entries, on a rolling basis.
  23. fun one before 3 week break. Space suit helmet from Planetes series. requires KAS. Cheers! download link here http://forum.kerbalspaceprogram.com/threads/99013-Pro-Props-Wearable-items-for-your-kerbals?p=1596438&viewfull=1#post1596438
  24. a fun one before break. Feel free to include it in future packs! space helmet from Planetes series © Sunrise. http://www./download/ezwwch5yy49qq2s/planetesHelmet.zip
×
×
  • Create New...