riocrokite

great stuff man Did some quick testing and here are some thoughts: (edit: tested version = 0.9.0.2) test vehicle setup; I tried to mimic stock pre 1.1 wheel behaviour that had much higher friction values so most tests are done with max friction values (added benefit is that I can observe wheel reactions to different settings / driving conditions more accurately) 1) would be nice to have higher limit of long/lat friction than 3, I have a feeling that I cannot get to the point of wheels friction of pre 1.1. So even with value of 3 wheels are prone to skidding especially at low speed. from my experience high friction limit is good for low g bodies so you can control your vessel more effectively especially when climbing hills. (i don't find 'flippability' a problem since imho I expect from real world physics and also when steering carefully or driving straight you're fine). 2) pre 1.1 unity had something like wheel weight value which was great for me since it prevented wheel spinning naturally (i used to bump it to high value which worked automatically like traction control), but I guess new physx got rid of this value and I have to tweak traction control values now for no-spin wheels 3) I can't get into the sweet spot of high damp ratio and high ride height (or high loading ratio) since all those values seems to increase fSpring values and when fSpring gets above 30 (in this case) it starts to freak out (weird range of values) and it ends up in a bouncy wheel effect (bouncing vehicle into air etc). Personally I prefer big damping value and medium to high ride height / loading ratio since it evens out high speed driving on uneven terrain and recovering from landing after bigger or lower jumps. Big loading ratio is also nice for heavier industrial rovers so the springs aren't compressed to the max and can do some hops damping work. 4) another nice to have would be to have selectable wheel groups - something like in pre 1.1 KF code, so you could tweak values for all wheels in the same group in editor or in flight. It would make testing much faster especially for vessels with more wheels 5) haven't tested if but did disabling wheel collider disables steering as well (i.e. when wheels are stowed), would be good to have for possible deployable wheels so they don't turn when they are not deployed 6) tr-2l wheels that i tested seems to be excessively sensitive to angle change on terrain. I.e. when driving out or onto runway (small slope) even with slow speed they bounce of terrain or get stuck and explode. changing wheel collider to capsule or sphere doesn't change anything. You can replicate that just making circles on the runway driving into runway side slopes. 7) I feel it would be good to have a steering limit written as a curve that depends on speed somewhere in the future 8) sometimes changing colliders from ray to sphere causes the wheel to go up (to look right again I had to use offset 0.5) and then it stops behaving normally (can't turn properly and then becomes bouncy and itchy) example setup when this happens to front wheels: 9a) something is weird with flipping the vehicle with ray or capsule colliders. I simply cannot flip the vehicle naturally turning hard with max friction. What I mean is that the vehicle comes to about 30 degree flip and then the flip just stops there unnaturally. The effect is similar to games when your roll is artificially reduced so you can't flip it (I think WoT used to have this before physics overhaul). vehicle Pic: 9b) the same vessel that is much lighter (without fuel in tanks) behaves weirdly as well - rolls to about 45 and then is blocked by some imaginary roll force then. It can be overcomed by turning even harder so there's something like natural flip to 45 degrees - block at that range - flipping further if more roll force is given. Maybe it's because the wheels apply force to the body? I don't know. 10) decreasing loading rating to a small value does something weird to steering of front wheels - they understear heavily no matter what speed or whether they exceed friction level or not. edit2: tried similar tests with most recent dev version and results are similar. So yah again great work fighitng that long with the broken physX of unity 5, one has to be amazed (not) how much they fubared wheels physics that worked great in unity 4 :/

I think it has more to do with tearing and micro-stuttering that is visible whenever game goes below 60 fps in my case. This might become quite annoying even if average fps is over 30 or 40. btw the worst example I had was micro-stops every 2 seconds with large comms network and many mods installed in 1.0.5 I think.

yah. the added benefit of isp written as a curve (flat one in this example) is that you can specify isp of an engine depending on atmospheric pressure.

I would start with this part: the second number is an engine isp.

very nice work man, one additional useful thing is that I can now launch rockets without fuel loss using big engines that need to spool up. I just need place a big tank of fuel nearby

One more thing, the off-road vehicle collider for unity 5 by NWH coding got released under name 'universal wheel controller': https://www.assetstore.unity3d.com/en/#!/content/74512 https://forum.unity3d.com/threads/released-wheel-controller-3d-realistic-three-dimensional-alternative-to-wheelcollider.441618/ I guess you guys lo-fi and Shadowmage might be interested in this stuff

Nice @Shadowmage I guess the biggest hurdle is getting things to work properly and being efficient so I wouldn't mind separate partmodule or whatever additional cfg and part setup for controlling colliders

yah, I've tried to recompile it some time ago but couldn't resolve all the errors, sorry

No idea, imho colliders are currently quite optimized. what comes to my mind is adapters and cockpits since they usually have 2 mesh colliders so you can merge them at the cost of being less accurate. Some time ago I tested whether it would be beneficial performance wise to replace tanks mesh colliders with i.e. a box+capsule and it wasn't (not to mention mesh - collider inaccuracies).

Shadowmage, dunno if this helps however I might have had similar problem when making concepts of a big antenna lately, anyway what might help is: - attach empty objects (I do it in blender) to vertices on the tube then parent them to the tube. Now you can use 'look at' those empty objects constraint for your beams where appropriate. It helped me with deployable dish animation - beams have constant crossection and I only change their length to account for deployment animation, example below red circles are the empty objects parented to the dish (which is heavily scaled in x/y and a bit in z scale as well): yah I guess the end caps would be fixed and be a part of the center / outer tube and all 8 beams could be grouped into 2 objects, each with 4 X and 4 Y beams scaling outwards from the center. last thing that might help with animation: https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Animation/Dynamic_Parent this tool was handy for me some time ago if you're using blender, you can parent / unparent objects dynamically for only a part of animation so you're much more flexible with compound animations etc

@Shadowmage you might consider adding darkened stripes - something like in the picture below: one practical explanation would be to see rate of rotation on a ship from a distance (similar to black stripes on rocket tanks):

dunno if that helps but here's a simple concept I made some time ago, 2x 1.25m modules on a 150m tether - very long radius allows for low rotation speed. I guess the diameter would be too much for ksp and you would need to animate lifts on tethers to accomodate for transport of kerbals between modules and the center. animation with speed increased by 2.5x :

We know that physx update along with unity 5 has broken wheels. So what about pulling relevant wheel code from physx that worked (2.8?) and then compiling it as a plugin or part of the plugin for current ksp? One can register at nvidia and then apply to get access to proper private github repositories to check code of current physx (3.3). Or just google "physx 2.8 github" and one just finds libraries with physx 3.3 and 2.8. I guess it would be quite complicated since physx = c++ language and then vehicle physics was part of the core physx sdk in 2.8 so referencing and libraries are interconnected and it was some sort of pulled as an extension in the current version. Then there might be licensing issues as well. Other option would be to just download vehicle code from current version of 3.3 and just 'fix / upgrade it' to suit mods needs. My logic might be totally flawed here though or it might be too time consuming so ingore if it's a cul-de-sac idea

just an update that i'm still working on this stuff albeit a bit slow: animation test of jaw crusher https://gfycat.com/SoreSourIchidna#?direction=reverse

yah, here's a link to the demo of the current version of off-road vehicles (old one), I guess it uses more or less standard unity wheel colliders with all its weirdness: http://46.101.247.190/

another day, another find - unity 5 custom wheel demo: http://wheelcontroller.tk/ development thread: https://forum.unity3d.com/threads/wip-wheelcontroller-realistic-three-dimensional-replacement-for-wheelcollider-demo-available.425443/ I guess this will released shortly as an updated off-road vehicle physics pack - https://www.assetstore.unity3d.com/en/#!/content/39946 dev movies:

Dunno if that helps but a quick google search yielded two videos showing tanks with tracks made with unity 5. Maybe something specific in ksp makes tracks behaviour not normal :/ https://www.youtube.com/watch?v=1rwPGMPq5dY https://www.assetstore.unity3d.com/en/#!/content/50485

it's great to hear about mod progress @lo-fi ! FYI steeringCurve mechanics on stock wheels is broken since unity 5 implementation. I've tried looking up relevant code but I couldn't get it to work. So if there's any chance to implement it in your mod it would be awesome:) http://bugs.kerbalspaceprogram.com/issues/12987

very nice, probably outside the scope of this development but it would be cool if AM factory was constructable similar to other KSC buildings

cheers; updated the mod with new size-0 ballute

Thanks for the report, will add bulkhead profiles. As for breakingToraque/force yeah they are a bit low I guess it will do no harm to increase those values a bit. As for wobbliness as far as I know this behaviour is directly linked to part's mass so there's not much I can do without increasing part's mass directly.

cheers, it's corrected now.

updated version to KSP 1.2

thank you, btw checked the mod quickly against ksp 1.2 and it seems to work ok

yah, after quick check it seems that the modulStructuralNode is bundling adidtional meshes ( that cannot be turned off easily ) with switchable nodes. Probably would end up making quite a bit of empty objects for each part to accomodate switchable nodes. For now I'll just try to recomplile JSI (it's soo awesome ;)) edit: I might actually be forced to use stock system since it's too difficult for me to recompile jsi for 1.2