If you are looking for a basic implementation of the mounting system and/or running a blueprint only dev game at the moment then this is where you want to begin.  This will give you a fully functional mounting system with blueprint base classes already setup that you can parent your games various blueprint classes to or vice versa.

In the Demo Project find the folder Plugins/AsadeusStudios and copy the AdsPrototypeTools Plugin folder over to your projects Plugins folder.  Feel free to create subfolders.  This Plugin contains the Basic Interaction System built to use for the Demo.

[IMAGE: Image of the Plugins Directory]

Next go to the Demo Project and find the folder Plugins/Tutorials and copy both the MountingSystemTutorialCore plugin and the MountingSystemTutorial plugin.  Copy both of these plugins into your projects Plugins Folder.  Feel free to create any subfolders you need.  These two plugins form the Full Demo of the PNM System fully implemented in Blueprints.

Go to your projects root folder and right click on the .uproject and select "Generate Visual Studio Project Files"

In the Editor you will need to be sure to have "Show Plugin Content" enabled. 

[IMAGE: Dialog to show plugin content]

Under the plugins folder in the Content Drawer you should now see the "MountingSystemTutorialCore Content" and "MountingSystemTutorial Content" folders which contain all the blueprint base classes you need to leverage.  You can load up the Map found in "MountingSystemTutorial Content/Maps" and test out the mounting system.

Reparenting Blueprints Classes

In the folder "MountingSystemTutorial Content/Blueprints/Pawn" You will find the BP_MST_Character blueprint which represents a Rider.  You can reparent your own BP Characters to this BP for any rider.   This similar approach can be used for the BP_MST_RobotHorse to use as a mount for any blueprint mounts you may want to use.

In the folder "MountingSystemTutorial Content/Blueprints/Player" you will find the BP_MST_PlayerController blueprint which represents the player controller.  You can reparent your blueprint Player Controllers to this  for any player you wish to have the ability to perform mounting.   It is important to note that this PlayerController leverages the Basic Interaciton System and so you will need to modify the Blueprint if you are using your own interaction system.

Reparenting to C++ Classes

If you are using a base C++ class you want to leverage for your Characters or Mounts then you can look in "MountingSystemTutorialCore Content/Blueprints/Pawn" and find BP_MST_CharacterBase.  This is the base class to BP_MST_RiderCharacter which implements the Rider Components and Interface's, and the BP_MST_MountCharacter which implements the Mount Components and Interfaces . 

The BP_MST_CharacterBase simply sets up Input for the Rider and Mount subclasses.   If you have no input scheme yet then you can parent Rider and Mount to this class.  If you have input already established then you can reparent the BP_MST_RiderCharacter and BP_MST_MountCharacter to your own custom C++ versions with input specified for them.

For the Player Controller if you do not have an input system specified you can go to the folder "MountingSystemTutorialCore Content/Bluepritns/Player" and reparent the BP_MST_PlayerControllerBase class to your base C++ PlayerController class.

If you already have a control scheme then you can go to "MountingSystemTutorial Content/Bluepritns/Pawn" and reparent the BP_MST_PlayerController blueprint to your C++ PlayerController instead.

At its core the Pro Networked Mounting System (PNMS) is a Mounting System that can be used as the foundation of your Vehicle or Mounting System.  It should not be seen as a full Vehicle System, instead its focus is on Mounting, Dismounting, and Seat Changing on Actors, Pawns, and Characters that you can consider "Mounts".  How Mounts behave and interact with the world around them is entirely left up to your game's designers.

 The Pro Networked Mounting System (PNMS) was built after working on a few games where mounting an animal or vehicle was a necessary requirement.  During the development of these games significant issues arose in multiplayer that did not exist in single player play throughs.  We hacked in several ways to correct these issues but these fixes where often cumbersome and Hacky.  Ultimately the formula of Actor Attachments, Lag, Animations , and Movement creates a lot of weird behaviors when working in concert with each other.  The PNMS system is the culmination of the knowledge gained in developing games that require solid mounting and dismounting mechanics.  

Being a company focused on creating solid foundational tools for game development we wanted to build a plugin that was of a professional grade system, using the knowledge gained many years of building such systems.

Problems Solved

• Runtime Multiplayer Dynamic Attachments between client and server
• Management of Rider and Mount Associations to the Player or AI Controller
• Synchronizing the Mount, Dismount, and Change Seat operations between clients and Server.
• Fixes lots of issues involved with the Movement Component, Movement Replication, Seat Offset and Orientation.

Easy is a relative term, for a mid skilled programmer or someone knowledgeable with Unreal Engine's blueprints or C++ code, then the answer is yes.  It may however take an hour or two the first time you implement it on your project.  The system acts as a foundation or Framework for creating your Mounting System, not a plug-and-play system you just drop into your game, some configuration is required.

No, you should not have to setup the components and interface for every single mount in your game.  You should establish a base class for your mounts and vehicles.  All your mountable actors should come from a few basic classes regardless of where you got them from (for example multiple marketplace asset packs).  These base classes should be:

• AActor - litterally ever thing placable in the world is an actor
• APawn - Base class for actors that can be Possessed and taken control of
• ACharacter - Pawn Based class with enhanced Movement Component for network prediction
• AWheeledVehicle - Base class for wheeled Vehicles.

No matter where you got your asset from, if you follow the chain of parent blueprints it will lead you back to one of those classes.  Depending on what the base classes are for your assets, you would create or modify a base class or blueprint that implements the interfaces and the components, then reparent your assets to that new base class.  Now the worst you have to do is setup and update the seats and mounting points on the mount according to the vehicles.

The short answer is yes.  The PNMS is primarily a plugin, it does not come with any blueprints or animations that are required to use, it does not make assumptions about the types of the Riders you use other than they should be Pawn types, it does not make assumptions about the types of your Mounts other than they should be an Actor types, and does not make assumptions about the hierarchy and components of either your rider or mount.  So there should not be any project that is incompatible with the PNMS plugin. 

That said there are countless starter kits and and complete projects on the market place an I cannot test them all.  I have yet to find one that I cannot integrate with.  That said, please do not ask me for help integrating with a particular kit, I simply do not have the time or the funds to test them all.  I will gladly answer questions pertaining to the PNMS system, but very often problems from integrations are more due to missing knowledge about the particular kit being used rather than the actual plugin itself.  The biggest offenders tend to deal with how a kit handles interactions and animations such as turn in place, these are unique to not just the kits but to game projects in general and so the plugin cannot account for all scenarios and requires you to learn how that kit works and make the adjustments appropriately.

This is among the last few animation related things I am trying to solve for demonstration purposes.

If you are building your game as a single player experience then yes, you can root motion your mounting, dismounting, and seat changing animations.  However when dealing with a networked game, where a small amount of lag is always present, characters can move while mounting and dismounting, the attachment logic in UE4 can get a bit funky.  For this reason I highly suggest not using root motion for your mounting and dismounting animations.  Instead build the animations from the perspective of the player capsule being already attached to the seat for both mounting and dismounting. 

I am still working to refine this bit and improve fidelity of the system.

Yes, This plugin is compatible with any other plugin or game kit on the marketplace.  I have successfully integrated it with the market place Survival Game Kit (SGK).  You will need to hook in to the SGK interaction system, but it does work.  The SGK is not an Epic product nor is it one I have developed, so I am not responsible for helping integrate the PNMS with it. Further more I do not have an example of the integration nor will I write one on my website as I do not want to add yet another task to my list of things to do every time an update for Unreal Engine comes out OR an update for SGK come out in the chance that the creator changes things.

My goal was to allow you to define any Pawn class to be a rider that can be attached and detached from the a mount or vehicle.  This way using the mounting system did not rely on you specifically using the ACharacter or a special character class imposed by the mounting class to be a base class.

Then I wanted any Actor class to be a mountable object by your rider, but it is important to note that only Pawns can be possessed by controllers in Unreal Engine. So “driving” a non pawn class will require some manual setup on your part.

This is something that the plugin will not address because it has everything to do with how input is handled by the pawn and player controller.  There are a few ways you can handle this from blocking rotation movement input while mounted disabling Rotate Towards Input on the Character Movement Component.

An Example of blocking movement can be found on current C++ and Blueprint Demo Projects

This is an issue with Unreal Engine Character possession logic itself.  The easiest way to deal with this is to have an AI controller take possession of the mount after the rider dismounts the driver seat.  Current versions of the Demos implement this in the example project. 

The attachment system of the PNMS is completely dependent upon the socket orientation.  Also one thing to remember is the Unreal Mannequin is built facing the wrong direction, instead of forward it faces to the left or right by default.  The Third Person Character corrects this by adding a -90 degree rotation around the Z Axis on the Skeletal Mesh Component.  So if you are using the raw mesh to adjust sockets in the Skeletal mesh viewer you'll need to turn them so that the character is looking left or right instead of forward. 

This is usually caused because the demo project has specific collision settings that have changed due to the use of the Migration Tool.

This was one of the central problems with building a networked mounting system in UE4.  Handling the relative offset between the capsule and the skeletal mesh on ACharacter actors can get weird for reasons unknown to myself. 

To ensure Animations, Lag, Movement and Attaching/Detaching does not cause strange offsets in rotation and location the mounting system performs a sort of reset on the character's skeletal mesh when it dismounts and uses two properties on the MountRiderComponent to do so; "RelativeMeshLocation" and "RelativeMeshRotation".  These values are Zero Vectors by default but should reflect the values of the Skeletal Mesh component's Relative Location and Rotation to the Capsule Component.  They can be read and written to in Blueprint so you can make systems that change these default values at runtime if need be.  There currently does exist a method to automatically update these values, but it is prone to accumulation of Error and I will be removing it in the next version of the plugin (2.0).  So Manually setting these is best, but you can also use your Pawn’s Constructor to auto update them on the component in C++ or Blueprint.

This is usually to do with the Roll rotation of the mount not being 0 when you dismounted.  Flying mounts need special consideration especially if you can rotate them around the X Axis (or Roll).  The dismounted character will try to "keep" its rotation as it detaches and so the capsule of your character itself is rotated.  This is different than the previous question about the pawn being rotated 90 degrees as that has to do with the skeletal mesh component.  This is an easy fix. You can create a function that resets your characters/Actors roll after dismounting.  Be sure to include the camera component as well in this reset and use it on the interface function "OnDismountingPawnFinished" on the Characters IMountRider inteface implementation. 

Aside from the Interaction System, this can be caused by a few things.

1. Make sure IAdmUnifiedControllerPawn Interface is implemented on both your character, your controllers and your vehicles
2. Make sure IMountRider Interface is implemented on your Pawn
3. Make sure IRiderController is implemented on your Controller
4. Make sure IMountablePawnInterface is implemented on your Mount.
5. Make sure Possess Character function is implemented
6. If multiplayer game, the RPC for character possession must be setup
7. Make sure you have at least one seat designated as the Driver Seat on the mount
8. Make sure you have "Get Seat ID" Implemented on the Mounting character "IMountRider" interface. For UE 4.25 plugins or newer.
9. Make sure the IMountablePawnInterface function "IsDriverSeat" is implemented on the Mount
10. Make sure the "IMountRider" interface function OnMountingPawnFinished is being called somehow, such as using "AnimNotify_MountingFinished"
11. Check the output log. I have tried to put as many warnings and error notifications as I can to help developers debug the the PNMS.
12. If all the above are fine there is a 95% change that the problem lies in the kit you are using.