Unfortunately same thing after migrating. 0 warnings / errors after compilation.
Strange. Just to be sure I’ll take some c++ template, like FPS and try to migrate M113 there together with a plugin.
Is your project a c++ project? Which version of the engine are you using? Which version of VS are you using?
Alright, so started blank C++ project and I also have these errors after adding variable.
Could you try to add your plugin with FPS Template but C++ ?
If you will not have a problem, it seems like I adding something wrong.
If you will have a problem, it seems like it’s not working with C++.
- Added new C++ FPS template project closed editor
- Copied content of this repository https://github.com//MMT_Plugin into [project folder]/Plugins/MMT/ folder
- Opened new project and MMT_Content
- In MMT_Content selected M113 blueprint and migrated it into test project
- Opened test project, added new BP of Pawn and added variable of M113 reference
- Closed project and opened it again, everything works
- Added a character c++ class and re-build solution from VS, everything works
Make sure you’ve installed plugin into proper folder, you can check if it is installed properly in Settings->Plugins, it should be at the end of the list:
Did all that steps and again stopped on :
6) Closed project and opened it again, everything works
Plugins folder :
Migrated content :
Adding variable of M113 :
✘Closing and opening project again :
Plugin is installed :
- Using Visual Studio 2015
- Using 4.11.2 version of Unreal Engine
No Idea then, judging from a screenshot, MMTPawn class is not accessible (or something like that) after you restart editor. As indicated by “None” parent of M113, with most likely “None” parent of A_Tracked_Vehicle too.
Maybe some issue with file access rights, not sure.
Maybe this is off topic… but I have a question for everyone using ever progressing blueprints and code that someone else is working on.
What is your method of using for example the MMToolkit for your own subject and moving to a new update without having to redo things you did with it.
I like to pickup where I left… but since this is an ever progressing project… I hate having to keep redoing an implementation.
So let’s say I continue with the tiger (which will be a long running project), what is the best way to keep updating something like MMT without having to redo anything.
How do you all do it?
Not at all to be honest. It kind of goes without saying that if someone provides a plug-in for the community, then it is done backwards compatible.
For example take a look at UE4 versioning. Every update introduces bugs and breaks things because Epic likes new features at the expense of quality control. (which is fine, it is just one strategy among many)
That’s why most people stay with their one development version until the end and never update once their project has become a large project that would ask for a full beta test after an update, because you never know what booby traps Epic planted this time for you.
That being said, I am also aware that it is not going to change because upping the Quality Department would probably exceed Epic’s finances as a SME.
See it like this.
Let’s say I am working on a project to create a tank simulator (fictional story).
I’m in charge of the assets and implementing it into an existing framework.
That framework is being worked on by a programmer (in this case that is MMT).
So you start with what you have… programmer works on adding new functionality and fixing things.
I do a first drivable implementation of the assets in the blueprint.
That frame work keeps improving… just like the assets keep changing.
more or less a basic gamedeveloper scenario.
But I do get your point in sticking with what you have and picking when to update parts or not. Usually when I’m working on a project that started in a certain version… I stay with it until it’s done.
I really never upgrade when a newer version comes out unless there is something in there I really need.
I could add something like versions in addition to branches related to UE4 updates.
I don’t think you have to redo your tank for each new version. With BP content you can use migrate function to merge versions or even use BP merge tool ( haven’t tried it myself yet).
With compnent based approach you would only need to merge components that are used in your projects. In some cases that won’t be enough, but that would be a minimum.
For example you could duplicate T-26 for your base setup, keep copy of T-26 as a backup and change models and logic in a duplicate. Later when you want to update, just migrate new version of T-26 into your project. This will bring over all dependencies and components, updating components which are used in your custom BP ( copy of T-26). On top of that you could see all changes done in T-26 Pawn blueprint itself, as sometime it’s not only content of component changes but interfaces/function calls. Those you would need to update manually. The only problem with this approach as far as I see is default values of variables in BP components - if default value is changed in the source of component, it switches custom value to default in each instance of component. Which is a nasty thing, for example you set moment of inertia for the engine to 2000, if I change default value to 200 and merge, you might not spot such change and vehicle will behave differently.
Another alternative is to merge only Plugin. This will simplify process but you would have to wait for necessary components to be ported to c++.
Overall the closer you are to the latest version the less issue you are going to have with updates, except if you are using experimental components such as modular drive train.
Not sure if it is applicable here, but we initialize all variables in blueprints as we do in Code. Just one large macro or function in your BP that fires once when you press the play button and all variables are set in it. Then, after it has run, the rest of the blueprint is executed.
Pretty much what you do with every code based program as well. Then you do not need to rely on the default values actually working properly in BP.
That would work. I can test another option too - making a child of necessary component and setting defaults there.
One thing I forgot to ask a while ago.
Do you plan on adding torsion bar suspension?
Basicly the M113 now uses a simple spring… but like a lot on tracked vehicles … it has a torsion bar suspension.
Or is there already a way to do a torsion bar suspension that I am not aware of 
(I see most vehicles on my list all have torsion bar suspension)
The easiest way to do is using angular motor on physics constraint. It’s not the most elegant solution as torsion bars don’t have a linear response as angular motor will have but its good enough for prototype. Later you could add torsion bar component and just remov angular drive.
Sounds good… but that’s way over my head. 
I will for now stick with the simple suspension.
yesterday was playing with your Modular Drive train… Brings back memories ! Great Job! This is exactly what it was like driving the Tiger in T34 vs Tiger … and this is definitely something I would like to add when you are in the driver seat.
When switching to the commander seat I want it to just be more of a commanding the vehicle mode where it switches to automatic mode and the wasd keys turn into a move forward command etc… just like in Steel beasts.
As the commander you want to focus on the surroundings… and when you tell the driver to go forward… you just want him to continue going forward without having to keep reminding him to go forward.
basically that is the most annoying thing in ArmA right now… when you tell the ai driver to go forward… the driver will also decide to evade obstacles and start steering left and right… you’re in a freaking tank! Stop Steering! When I tell you to go forward… GO FORWARD! 
It’s actually pretty simple, T-26 uses angular motors on levers of suspension (arched parts to which bogies with wheels are connected).
Regarding drive train, I’ve uploaded new version with a locked differential last week. Added sound for shifting gear too. Still need to clean up code and add open differential and add rolling friction for tracks.
Commander mode can be added on top of such system. Need to decide on some sort of component and interface which will handle input from keyboard/mouse/gamepad and an automatic mode on top of it. Right now input code is handled in pawn, which is not good for modularity.
The linear response of joint motors can be exchanged for other responses by changing the strength of the linear/angular motor during runtime. Like for linear motors, to turn them into proper springs/shocks, you would feed the spring equation into the position strength pin of the ‘set parameters’ node. The spring equation is simply F=k*x, with x being the amount of stretch or compression (if I remember correctly). The distance from a reference point (e.g. wheel to chassis) gives you stretch/compression. That’s how we did it, or at least it was something like this as I remember, for the shocks of the carrier in our little nonsense game. Still not a 100% vehicle simulation, but a good start.
Yes, you can dynamically alter stiffness to get the desired effect.
There are couple of thing that I’m not too happy about in regards to angular and linear drives of physics constraints as a basis for suspension spring (they are totally cool for attaching things together!).
-
Symmetry of damping - most of the real life dampeners have asymmetric response to suspension compressing or extending, this is very important for proper behavior of the cars, not too important for modern tanks. Asymmetric damping allows wheels to react very fast to obstacles protruding from road surface - this compresses suspension, at the same time reaction to ditches in the road is much slower (suspension expanding) and wheel can “fly over” the hole in the ground. Aesthetically this works rather well for tanks too.
-
Physically accurate application of force - yeap, not happy about this
Let me explain what I mean. Aerosled is a very good example where accuracy can lead to undesirable behavior. Chassis of the machine is 1100 kg, each of four ski is 50 kg. At rest, four suspension springs will push on chassis to keep it up, but the same force is pushing on ski too. Unfortunate part with solid body physics is that as there is no loss of energy by means of heat or deformation. This leads to a relatively light body being pressed by relatively large force against the ground. In case of aerosled it leads to one of the skii piercing the ground on one frame and being pushed out on the next frame, the end result is annoying shaking of the vehicle. What I do to solve it is rather simple - a spring which can push on chassis and ski with a different force. If I want to place Aerosled on the back of another vehicle and have it’s suspension properly react to weight of the aerosled, I can pass as much force to vehicle as I want. And again, it doesn’t have to be physically correct especially if it creates more pleasing and stable result. -
On this point I might be wrong, but I have impression that springs and dampeners of physics constraint operate on a relative scale. I want to iterate over the code of my custom springs to make sure that they have a consistent scaling. What I mean by that is stiffness of the spring should depend only on engineering properties of it - material, manufacturing, design but not on it’s length. This is very helpful in long term when you have to deal with many vehicles and allows to find proper values by simple calculations instead of tweaking it 30 times until you get good results. Another benefit from proper scaling is that you don’t have to iterate over the stiffness of the spring every time you adjust it’s length.
This is not a rant or a critique to how physics constraints work. They are made to be used for variety of different use cases and more accurate simulation just needs a bit of custom touch to it.
Good points!
-
Asymmetry of constraint stiffness/strength can be included by considering the direction of movement of the constrained component relative to its relaxed constrained reference point, i.e. compression and stretching have different signs and this sign input can be used to branch two different equations for asymmetric strength/stiffness into the ‘set parameters’ node.
-
Yes, I absolutely agree on the problem of mass differences in the current implementation of the PhysX Code base. Are you saying you tweaked the PhysX constraints in a way that they apply different forces in each direction? Or do you mean a double spring composed of two out-of-the-box PhysX constraints.
-
Well, there seems to be something like this going on. The actual spring force also scales with the attached masses. For example our nonsense robot: Body is always the same weight, but you can choose different leg/arm/feet/hand parts with different weight each. Now here it comes: Lighter legs are wobblier, while heavy legs are stronger because the constraints (hip/knee/ankle) react different when different masses are constrained together. We never cared too much about it because it actually makes a nice gameplay feature, but it shows clearly that something is on relative scales under the hood. If constrains were on an absolute scale, i.e. for example same strength for all mass combinations that are constrained, that would make it easier to control.