nli2work

one thing you could try is animating the numerous toes in Max, then animate the larger leg parts in Unity. that could be a workaround solution.

overshoots typically happen when the deltas between two out of 3 keys are large and the keys follow each other close together. Squad's curves are typically 3 to 4 keys, spaced out more or less evenly, with either automatic or flat tangents. that means mostly staircase curves with little or no overshoots. it would be impossible to unintentionally get bad tangets with a two key curve; and almost impossible with a 3 key curve. keys from 0.68/0 to 7/10 to 9 1000 is almost guanranteed to generate extreme overshoots without manually specifying in/out tangents at each key. great case demonstrating the importance of knowing exactly what the curves are doing and what you want them to do.

I have no idea. just too many things to check if you really want to see what went wrong. It'd take much less time to redo everything while making sure scales are reset and animation has no extraneous keyframes.

awesome! I supesct Stock curves are not as bad as this. Most of the curves are only 3 keys, not much chance of getting extreme overshoots like you could with 5 or 6 keys.

new animation clip. I only animated the leg pistons rotating out and extending. didn't animate all the toes.

is AO map mandatory??

propellers require a propellant with mass, in addition to electricCharge. you can set your intakes to checkForOxygen = false for engines to work in non-oxygen atmospheres.

yeah it's something with the animation, but I don't know what. I recreated simplified animation in Unity and it no longer drops down into the launch pad. I would go back to Max, fix the scale on all the parts (they are all over the place) so everything is 1,1,1. recreate the animation, make sure to set the keyframe filter to only key rotation for parts that only rotate; and key position only for parts that only move. do not keyframe any scale at all. export and run through the Unity hoops again, and see what happens in KSP.

I don't know. I guess it's something in the code that saved page states are by prop instead of module. in that case I'd expect the behaviour you see. and in that case it's probably something deeper in the code, I haven't come across any RPM settings related to how page states are saved.

just a guess. I never worked with USI part modules. I'll do some testing tonight too.

try setting USI_BaseAnchor offset to 0 instead of -1. I suspect it's changing the spawn position of your part.

Unity supports many different import formats. But does not support any 3d app's native formats (*.blend; *.max; *.mb; etc). When you "import" a Blend file; Unity is using Blender to export an FBX behind your back. any 3d app that exports OBJ or FBX or DAE or 3DS will do. each pipeline will have their own advantages and disadvantages and quirkiness.

make sure you have RasterPropMonitorComputer Part Module on the pod part and InternalCameraTargetHelper on the internal config no configuration needed for either one. each page block in RPM module has the option "default = yes". that will set a page to load as default when the vessel launched. only one page should be set to default for each RPM module.

what's it look like with the fuel tank attached? is the fuel tank's diameter same as the side of the square? your screen cap shows 1 unit cube being 1.25m in KSP. which is what one expect when not using "rescaleFactor" in the config. the info from link compilation is still correct.

whats your part config.. try adding box collider component to the Foot001~004 objects. no need to change the size or center of the box colliders, they will automatically best fit the foot object. you can set the X and Y to 1.2 if you want the box to include the toes. the large boxes you made in Max can be removed, the left over animation curves can be removed without breaking the animation.

if your config has the line "rescaleFactor = 1" then what you see is correct. if your config does not have that line, and your 1m cube is still 1m in game; then the information from that link needs to be updated.

rendering doesn't do anything for KSP. just learn good 3d modeling technqiues, proper geometry for real-time assets, and UV mapping.

you can place the docking node inside the mesh, the camera will be able to see through the back face. you will have to adjust the docking rod so there are no polygons facing the docking node. you could on the other hand take advantage of the mesh as some kind of reticle.

I don't think the pivots of the feet colliders has to be at the world 0,0,0. I'm assuming it's at the center of the feet collider box at the moment? maybe try setting the center to the bottom of the feet and see if that makes a difference.

ok, yeah I think you have it right. The feet colliders are partially intersecting terrain collider during load, then physics kicks in and pushes the craft in the direction of CoM so the colliders are no longer intersecting.

doesn't seem like it would be a negative impact on performance. all RPM modules share same core computation code so I think 10 MFDs will use about the same resources as 1 MFD. the only times where I've seen performance costs is with TransparentPods where the internals are updated when seen from outside; and when you have many of RPM camera modules rendering to different screens at large resolutions

I'm assuming you don't know any 3D. The easiest 3d software is the one that you have access to largest group of users who can help with your questions directly related to what you are trying to do (making assets for KSP), in that case, it's Blender.

it happens when you extend the legs in VAB then launch? or it happens when you extend the legs after launch and it jumps up as the legs extend across the ground? if it's the 2nd, it's probably the colliders building up tension while trying to slide across the ground.

The multiple screen prop uses 3 separate RPM modules. so it's still 3 separate MFDs technically, even if it's all in a single prop. The three screen don't share buttons between them, meaning the left screen buttons are not linked to any functions on the right screen. etc. it's possible to share buttons across RPM modules/props, but seems like it would get complicated extremely quickly. https://github.com/Mihara/RasterPropMonitor/wiki/Configuring-a-monitor#a-note-on-buttons and if you want more complicated setups, there's context-redirect within page blocks to change the button function based on which page is active.

add checkForOxygen = false to ModuleResourceIntake{} on an intake part.