I think this is a good list for tutorial(from easy stuff to hard…) and if true, I’m personally is more interesting in a tank(track vehicle) tutorial))), but of course any tutorial is good
Also i have a suggestion-- for example if there a wheels control system, can it have output transform pin(with wheel position/rotation/scale for using these parameters in animation BP for creating realistic suspension) from wheel control node?
Sure! Hovercrafts air cushion skirt is animated like that. For each bone of skeletal mesh there is an “air pressure thruster” component. Each of such components calculates where bone should be and location is send to animation blueprint.
Btw : How did you move the M113 over to MMT?
Did you re-setup the whole thing? Or did you import the Blueprint from the N-Wheeled project and did some minor tweaking?
Just in case I do something stupid, or re-doing things I don’t need to re-do 
Thx, super… but can this truster nodes be using for creating 4 wheeled vehicles(cars)?, and how about using skeletal mesh for main tank body? i see is easy way to have a invisible physics box slot (it collide with world, have some weight )looking close to real tank body and inside this box we put physics disable(maybe enable on some parts) skeletal tank mesh body(with animation BP that drive wheels and suspension from truster nodes) , i thing this method use Epic in standard vehicle class(they separate visual body and physics body), but standard vehicles physics is very bad… but for setup its very easy!!!
Well, those thrusters are very specific to Hovercraft, that’s why they are not placed with the rest of the reusable components in the folder.
Swapping static mesh to skeletal mesh always can be done. It’s a matter of how things are wired but there isn’t much difference in setting bone position or component position. The major difference is reusability of the assets. Anyway let’s wait for component based release of the tanks and see from there.
Btw, OldRaven’s tutorials on how to setup tank are valid in MMT, I don’t think there is any major difference in how to use it.
I’ve migrated them as assets into MMT. In principal you could try to migrate tank that you already have the only issue is that it will try to bring assets which are already there like A_TrackedVehicle BP and meshes. Give it a try after making backup copy 
EDIT: Second thought on how to deal with all this in feature. Instead of being locked into MMT_Content as a basis for your project. You can migrate just specific components/BPs which you want to use as a basis. Copy/paste C++ portion of the plugin and you are good to go. Anytime components or BP is updated, you just migrate it’s fresh version into your own project and overwrite existing content. Eventually the most common components will be moved into C++. It’s not only better performance wise but update of functionality of component becomes transparent to you. Kind of how A_TrackedVehicle worked but on a smaller scale - on a scale of specific component. Non C++ components made in BP have to be migrated.
Update
Fresh update of plugin and content example.
0lento contributed an improved version of the function that can return valid transform of components during physics sub-stepping. I’ve added some small features to it and replaced old implementation. Thank you, 0lento!
Fresh executable: https://www.dropbox.com/s/55dazkm8q4s0axn/MMT_Content.zip?dl=0
So this is how BP looked before if we needed to retrieve a socket transform during sub-stepping:
this is how it looks now:
SpringAndDampener components are suppose to be re-usable and this is what I had to do to retrieve transform of attachment points with optional attachment to the socket:
and now I need to do just this:
The best part is that new implementation removes necessity to think about what your components are. For example you couldn’t get a proper sub-step transform for scene component if you didn’t deliberately made a BP to gather all transforms in chain to the next physics simulating parent, now all this is handled in C++.
This is all pretty rad! I’m currently extremely miffed with the physx constraints so it’s nice to see there’s options out there!
Update
Enjoy!
New additions:
Hovercraft is now using simple friction component to simulate friction of the skirt. The amount of friction depends on the mode of the engine: the higher hovercraft hovers the less friction is there. Some tweaking is still required but basic behaviour is there. Another addition is air drag. Addition of air-drag placed a limit on vehicle top speed and removes part of the skidding inertia at high velocity.
Fresh version is uploaded to github and compiled version is here: Dropbox - File Deleted - Simplify your life
I briefly looked at your BP drag equation and there was few things that seemed off to me. First the speed in the equation should be m/s, not km/h (although in unreal we have cm’s). Other issue is that you don’t square the velocity, instead there’s normalization (?). To get that u^2 so that you can use it for drag counter force, you can do -Velocity * Abs(Velocity).
edit-> I realized what I wrote initially didn’t make any sense (you can’t abs vector), but what I explained on the next paragraph will work 
I do this separately for each local velocity component (surface area usually differs based on the direction). If you do that, then local X velocity will be (-LocalVelocity.X * Abs(LocalVelocity.X) and so on, you then just need to transform that into world space in the end.
Btw, you can use terminal velocity to verify that your aero drag equation works right. You can calculate it manually but I’ve used just built in calculators, they all seem to give same results for me, for example www.calctool.org/CALC/eng/aerospace/terminal. I’ve tested this myself by placing the simulated object at 10km height on level, set initial velocity near the calculated terminal velocity value, put a print of the velocity on tick (to see if the value tries to reach the exact terminal velocity, tries to slow down or tries to get faster) and just started the simulation.
I’ve copy pasted it from my old code and I do recall some sort of unit conversion done there. Have to check why it was done, converting to km/h indeed sounds strange.
As to square of velocity, I think it’s just plugged twice into equation, so V^2 = V * V. Or do you mean something else?
Thank you for the link, I’ll validate the calculations.
Update
Added links to OldRaven’s tank tutorials from Tracked Vehicles project to the first post.
Math of air drag was indeed wrong. Thank you, 0lento for spotting it!
For gameplay purposes it’s very easy to make hovercraft slide much less and get behaviour similar to handling of hovercraft in Battlezone. But challenge here was to get this thing moving and steerable with a single physics based control!
Fresh executable: https://www.dropbox.com/s/55dazkm8q4s0axn/MMT_Content.zip?dl=0
My apologies to whoever used GitHub repository of MMT_Content - for at least a week source code on github was broken. Not sure why, but git plugin for UE4 didn’t handled re-directors properly and I’ve missed that they were not committed properly to repository. Fortunately my local repository is working fine and now I’ve properly merged everything with master branch. I’ve tested both cloning from master branch and downloading as archive, both work properly. Enjoy!
Update
Tracked vehicles now fully support physics sub-stepping. Suspension and handling don’t freak out anymore if FPS changes:
Dust particles are now working again, previously I forgot to add physics materials to Project Settings->Physics->Physics Surface settings.
Steering is still problematic at the end of the 1-st gear and higher. Engine simply doesn’t not produce enough torque to overcome inertia of the track. To steer, you have to press on brakes first, to slow down tracks and only then you can do a sharp turn.
It’s possible that I’m missing some vital physical connection between rotation of the axle and engine and in real life axle wouldn’t be able to accumulate so much velocity. Either I need to fix this aspect or simply change steering. As far as I know M113 is using breaking steering, not a differential steering that I’m using right now. Breaking steering will allow sharp turns and I’ll figure out later how proper differential steering is suppose to work.
Master branch on Github repository is updated and this is the link to latest executable: https://www.dropbox.com/s/55dazkm8q4s0axn/MMT_Content.zip?dl=0
Forgive my ignorance, is this being developed as a plug-in or as a full engine extension? I’m just curious as to how to integrate this in a project that may change as UE4 produces newer versions?
Looks awesome either way, keep it up!
Nice, curious about the difference with sub stepping enabled for tracked vehicles.
I’m a bit busy with another project… but will continue moving my stuff over to MMT soon.
Thanx for adding the video links again 
, I will update a video if necessary in the future.
Thank you!
It’s developed as a plugin, so it can be copy/pasted into any project to provide essential functions for custom physics calculations. C++ code of the plugin is always included, to be able to compile it for different platforms and any version of the engine.
As a note, there are two parts:
Regarding integration in general. I’ll be upgrading both plugin and content examples when 4.11 is released, 4.10 version will go into a separate branch. Same will happen to 4.11 when 4.12 is released. But nothing prevents you from using plugin and content examples with the latest version of UE4, it’s just certain things might not work as expected. If something works differently in latest version it can be always patched up.
Long term plan is to move the most re-usable components into C++, like PID controller for example. Some components will stay implemented only in BP, so it’s easier to make a copy of them and customize for a specific machine. For example, air pressure thruster component is very specific to hovercrafts and hardly can be used on anything else. Something like a propeller engine, can be used on many different machines, so it makes sense to move it to C++ and leave BP code as reference.
The reason why I’m saying this ^ is because I’m not sure how someone can integrate with BP project. With plugin it’s easy, you just copy/paste a fresh version into your project and its done. In some cases you might need to re-compile BPs.
With BP projects you need to migrate assets and while engine will pickup all dependencies himself, I’m not sure how something like hovercraft can be used as a basis. For example with Tracked Vehicles, there is a base BP class A_TrackedVehicles, which contains minimal amount of visual elements but contains almost all code. One can create a child of it and provide it with their own models and settings of variables. Later when you want to update to latest version of A_TrackedVehicles, you simply migrate it into your project and re-compile child blueprint. With hovercraft this is not the case - making a child of it will inherit all visual and logical components which can’t be removed, only their settings can be altered. Most of the logic is inside of the components and those can be updated by migrating fresh version. The “glue” code is in the pawn itself, could be migrated if you don’t change it in your custom machine, otherwise can be copy/pasted if you know what exactly was changed. Tool for comparing BPs can help here but all this sounds like a lot of work to stay up-to-date.
Ideally, we would have components such as engine, wheels, gear-box and etc. You add them to the pawn or actor and other components would automatically find them and work with them using interface calls. Practically speaking, I think this can be achieved only partially. To have a better control over what is going on you need to write glue code. For example to make sure that component’s physics update is done in desired order or to track if some components like a wheel where blown off by explosion/collision. For this glue code to be easily portable, machines have to be build in a more abstract way and it makes sense to do it only if you are planning to have multiple designs of the same type of vehicles in your game.
Maybe someone can have a better idea how this can be approached. Approach of building everything in C++ and be able to change only data portion in BP, like its done in VehicleComponent, doesn’t sound too appealing. But building everything out of “smart” components might tax performance more than necessary. Some hybrid approach is needed.
It became smoother. On my main machine, when I run it from the editor I can see that sometimes fps goes under 60 fps. Most likely it’s because of the hovercraft being there in the scene (hovercraft is not really optimized and doesn’t have sleep functionality). In Tracked Vehicles project, there is a pile of physical wheels, which are taxing performance too. The importance of sub-stepping will become more obvious with cars. Tanks suspension is distributed along many components, this provides smoother and more stable behavior by itself. Even if some suspension length rapidly changes, it’s own force is not enough to push vehicle too much. With cars, as you have just 4 wheels, in most cases, glitches in physics will be more visible.
Btw, we can get it even smoother, I’ll try to set physics sub-stepping to 120 updates per second. Just need to check how much it will effect performance.
Very cool stuff @
I like the rodeo tank!
Thank you!
I need to check how suspension of tank transfers force to the ground too. That vehicle is about 3 tons, it should have pressed hovercraft to the ground much harder.