this is quite rough but can give you some ideas:
Itâs working well, but thereâs no lateral resistance, the vehicle remains free and can gain speed while spinning.
I added an âAdd Torqueâ which solved the problem well and gives the feeling of actually being on the sand with a well-contained skid, but I donât know if this is the best solution, what do you think? (Especially in terms of performance, Iâm afraid that all these applications of force will end up compromising the gameâs performance.)
(PhyMat: Fri: .2 / Rou: .5)
there is lateral resistance too but since the lateral movement is slower the resulting resistance is also low. I would use the local velocity vector and scale forward and lateral resistances separately.
all of those addForce, addTorque etc. are summed up and applied at the end of a physics tick, theyâre just vector additions so they wonât have much effect on the performance.
we detected an issue with the enhanced input support, working on a hotfixâŠ
Whats the simplest way to detect if a value is increasing or decreasing?
Inside FGearWheel.cpp, I was trying this:
float actual = 0.0f;
float previous = 0.0f;
float value = mAccel ;
actual = value;
if ( actual > previous) // Accel
{ mOstiax = 11111111.0f;}
else if ( actual < previous) // Decel
{ mOstiax = 44444444.0f;}
else if ( actual == previous) // Constant or none.
{ mOstiax = 66666666.0f;}
previous = value;
Accel and Constant/None ok, but not Decel.
Desired is detect if the car is accel/decel (and how much) or if // Constant or none.
I tried with mLocalVelocity.X and other values that goes up/down with same result.
Any idea?
well if that code is the actual code that youâre using then it is normal that you get weird results since you donât store the previous value at all, it is always zero because it is just a local variable.
Sorry, pasted an old code, this actually works, just setting a lerp on previous, but no idea if there is a better way:
mActual = mVehicle->getEngine()->getThrottle();
if ( mActual > mPrevious) // Accel.
{ mOstiax = 11111111.0f;}
else if ( mActual < mPrevious) // Decel.
{ mOstiax = 44444444.0f;}
else if ( mActual == mPrevious) // Same.
{ mOstiax = 66666666.0f;}
if ( mActual == 0.0f) // None.
{ mOstiax = 00000000.0f;}
mPrevious = FMath::Lerp(mPrevious, mVehicle->getEngine()->getThrottle(), 0.8f);
So, im guessing using the 0.8 can set the amount time to tell the difference, then on each if/else if do a substraction of actual-previous with absolute values.
Btw, if you can add this on the plugin can come very handy.
I would do 2 things differently.
first, acceleration should be based on velocity not throttle, the vehicle can accelerate without throttle. you can use Vehicle.getKMHSpeed for that.
second, it is good to smooth out the stored values since physics data is mostly noisy. in your case you have smoothed the previous value but I would smooth the actual value and compare with the previous. also the way you smooth with âLerpâ is frame dependent, you better use delta time there like Lerp(x, y, z * dt).
Can this be improved in some way to avoid car stop accelerating on change gear and getting like some âstuckâ sometimes. It prevents the fluid drifting:
//keeps vehicle from going faster than engine rpm limit
//this is an artificial force so take clutch power into account here
//mSpeedOverflow is multiplied with clutch power above in applyRpmLimit
if (mSpeedOverflow > 0.0f)
{
currentForce = FMath::Sign(-mLocalVelocity.X) * absLngFriction * mSpeedOverflow;
}
Disabling that, drifting is so fluid and doing 360Âș are much better. Btw, without it, at some times it may accelerates too much, so it has his pros/cons. Wonder if there are some ideas i can test here to do the same but in a different way that not blocks/brake wheels in some way?
it is possible but not trivial, iâll check it when I get the time.
I see an update? but not read any info about this. @lazybitgames
itâs a maintenance update but the plugin update page is problematic and I couldnât upload the update for all versions yet. when itâs complete iâll post the detailsâŠ
v1.8.1 now available
- Enhanced input bugs fixed
- Some replication bugs fixed (read notes)
- Some minor improvements (read notes)
Warning: If you have difficulty running the example project with Unreal5 copy the FGearPlugin folder in Unreal5\Engine\Plugins to FGearExample\Plugins folder.
Notes
- When we had more than 4 enhanced input actions bindings it was possible to loose references to some of these bindings. We changed the way we store action bindings and the issue is gone.
- We used to only have 3 sample input actions for enhanced input in the sample project. Now we added input actions for all input types of the standard input. These files are under FGearAssets/Inputs folder in the sample project.
- Compression of the gear input was failing with negative numbers in replication. This was an issue when you have a sequential gearbox, this is fixed now.
- Instead of replicating the gear input, we now replicate the current gear value. This fixes the gear sync issues with sequential and manual transmissions.
- Current input struct is no longer replicated back to itâs owner. Since the input struct is updated every tick this was not an issue but we skipped an unnecessary transfer.
- There was an issue with server authoritative replication in 5.4. It seems moving a kinematic object no longer generates velocity by default. We had to activate this behavior in 5.4.
- Clutch input was skipped when you have auto-clutch. From now on if you press the clutch it will override any auto-clutch value. This way you can let the system run the clutch and override whenever you want.
- Wheels can generate inherent and extra(additional) drag forces now. The idea is to let a wheel drag in certain cases like a flat tire or when a tire is on rough terrain like mud or sand. The inherent drag is supposed to be the internal drag of a wheel and it is zero by default. The additional drag is supposed to be updated at runtime depending on some conditions. These two parameters will be summed up and used as the coefficient of the wheels drag force. As an example the effects component checks the physical material of the surface that each wheel drives on and sets the additional drag based on the roughness parameter of the physics material. In the sample project you will observe that the vehicle struggles more on the terrain. You can use Wheel.setInherentDrag & Wheel.setAdditionalDrag functions to modify these parameters. This is an experimental feature, use with caution.
Hi,
I am currently using FGear 1.6.2 on a UE 5.3 project. How can I update to the latest version?
Is there a safe way to test the impact?
first you can grab a copy of the 1.6.2 version, typically files are located under âEpic Games\UE_5.3\Engine\Plugins\Marketplace\FGearPluginâ. if things go wrong you can restore it back.
then you just need to update the plugin from the launcher(check the image a couple posts back). there might be some minor issues but overall it should be easy to update. once your project is working, you might want to check your tuning since we had some major changes in v1.7
Hi.
Thanks to you, the update went well.
I originally came to the forum to ask about a problem with the gear not going from R to 1st gear on an uphill, but the update solved the problem.
Replication is also very comfortable now with communication lag down. Thank you very much for keeping up the great updates.
By the way, one question: what should be the engine default Replication setting for FGear actors?
Should Replicate Movement be False?
How i can get the difference values from each wheels axle?
For example i want to get the difference values from rear-front wheels on mLateralSlip.
Inside FGearWheel.cpp im using mFrontW and mRearW to store values.
To detect the axle im using:
float MaxSteerAngle = mAxle->getMaxSteerAngle();
So if MaxSteerAngle > 0.0 are the front wheels, if not, rear.
Then i do: mFrontW = mLateralSlip and mRearW = mLateralSlip on each condition.
But if i try to substract or something between them got the same as original.
So, my question are:
How i can get the difference wheel values between front and rear axle? And between one or other wheel?
we disable movement replication in code so your setting is not important unless you manually re-activate it which you shouldnâtâŠ
define âdifference valuesâ, it doesnât mean much to me.
checking max steer value to determine if the axle is front or not is not a good idea but if all of your vehicles are regular cars with 4 wheels then it would work but even some cars have steering rear axles. you could just get the index of the axle, 0 is front, 1 is rearâŠ
OK, Thanks