for those using the custom collider component, make sure you’re getting the overlap event from this component not the root mesh.
2 Likes
I’m encountering a strange issue with exiting vehicles and unpossessing them in my game, which runs on a dedicated server. The game is similar to GTA, where the player can walk up to a car, enter it, and then exit to continue on foot.
The problem is that when I exit a vehicle, the car sometimes starts moving around randomly. This can be quite severe—I’ve attached a GIF showing the exit code in action. The car might move left, right, forward, or backward without any input. The issue seems to be worse on road-based splines, but it can happen anywhere, even on static meshes. It doesn’t occur every time, but when it does, the severity varies. Sometimes it’s minor, while other times the car keeps moving for up to 10 seconds, even though it was at a complete stop when I exited.
Exit Code (Blueprint)
I think if you wanna get support - at least simplify the blueprint and make sure it is reproducible otherwise, there are lots of your own code/bp that could be buggy - we dont debug your code 
So issues you’re having is not from Fgear. However I think these suggestions might help.
First, If you’re using a pawn with a primitive component, make sure collisions are disabled between that component and the Fgear parent mesh or any mesh in the Fgear hierarchy.
Secondly, you can stop the engine from running after you exit the vehicle and apply the handbrakes.
Is the “BikeHelper” on FGearArcadeAssits working correctly?
Cant get a smooth pitch correction. Checked the code and found:
“//we need inertiaY but UE5 gives incorrect results so we take the largest”
Maybe this was corrected by EPIC and now this fix makes the behaviour wrong?
I tried all setups, damper from0.1 to 10 max, and Anti-Rolling spring from 0,00001 to 9999999… but always after reach the max pitch angles triggers correctly but at same speed, which is too fast.
Can you double check?
EDIT: Changed GetAbsMax() by GetAbsMin() like the roll damper, and now is more slow and getting something ¿?.
EDIT2: In my case seems the problem is pitchCoeff/DamperSmooth . On _BP min is 0.1, max 10. But to get smooth as wanted i had to do this in .CPP:
pitchDamperTorque = inertiaY * pa * (pitchCoeff*0.01f);
pitchCoeff*0.01 And i get a slow correction. I set pitch angle to 20, when it triggers, so at near 70-80 already stopped. A very subttle correction/limitation that makes still playable and jump with ramps fun without feel that “fake forces”.
bikehelper is meant to be an example for you to improve upon and that’s what you’re doing I guess 
pitch damper is not actually a damper but a stopper impulse so it may not behave as you would expect.
Yep, i already got somehting, what i cant achieve is stop at X avoiding the car turn opposite again.
i mean, if the car is rolling up or down, i want the force start stopping and at some moment car gets stucked at X angle, instead of turning back which is weird.
Is how Dirt4 does, but always get some minimal force back.
Edit: Im using this as multiplier:
FMath::Abs(FGearUtility::getWorldAngularVelocity(mBody).Y)
So when less car speed rotation less force needs to be applied until 0 force is applied when is 0. But still, some remaining torque makes car turn reverse again, a very little but it does.
I wouldd like to make request for the consideration of updating the smoke/particle effects from cascade to niagara. (or support both) (im working in editor/blueprints) hope it makes sense.
1 Like
I have a question about the Fgear physics material compared to the Unreal default:
In the documentation, it says that the “roughness” value is not being used yet,
is that still the case? FGear seems to use the FGear>friction value, being the rest of values under “Fgear physical material” used in the FGeareffects component.
So, my question is, makes sense to support the default unreal physical material (suporting “Friction Value” from the default unreal physics material for the vehicle physics) to increase compatibility with other systems/plugins?
The rest of the parameters of the FGear physical material seem to be for the FGear Effects component (wich i unerstand is very basic intentionally), at this point in my project seems to make sense to drop the Effects component, and using the default physics material makes sense is there are no aditonal actual physics values used in the FGear material.
roughness wasn’t used until the very last update. with v1.8.1 roughness is used as a slow down factor, if the roughness is large the wheel on that material will experience a drag force which slows the vehicle down.
1 Like
Decals not Casting onto vehicle.
WHELP!
Check if the primitive component has “receives decals”
Legend, Thanks.
Now if anyone could help with the smoke. That tire smoke wouldn’t go through car lol.
Thanks! that info will come handy.
I found a possibly bad behaviour. Tested in the last FGearExample too.
On “Engine” if you set “Engine Inertia” high, the car accel more slow, thats ok as description says. But if you steer the car left/right the car accel more fast ¿? in theory it should be same or less. In my example i set inertia to 9, the car accels like 1-2kmh per second, if i start to steer left-right fast thats goes like 10 or more per second. ¿?
I was feeling something wrong, so i tried to check values trying to set some extreme numbers to make the bad behaviour more evident and catched this. On fast steering left-right the car accel more fast ¿?.
noted.
my first guess is that this is due to the feedback rpm calculation in AFGearVehicle::getFeedbackWheelRPM, we take the fastest axle rpm to drive the engine.
Tested and i guess you’re right, did a quick change to see what happens:
if (finalRpm < FMath::Abs(crpm))
by
if (finalRpm > FMath::Abs(crpm))
The problem is fixed, but the car in idle, without any input, goes backwards, and if steer left/right goes more fast in reverse, so the problem seems is there as you mentioned.
Are the calculations correct?
I checked the cars and they use mostly the engine curve with max 9k torque. Some have the limit changed to 6k or similar and match with the calculations, but for the LimitRPM with 9k , calculation says max is 7985.
So, are calculations correct and i should set the limit RPM to max 8k? or 9k, 12k… will be fine?
the calculation is simple, check UFGearEngine::calculateMaxPower.
limit rpm is not the rpm at which the engine generates max power, it’s the rpm at which the limiter is triggered, in real life this is to protect the engine. also the transmission most likely won’t wait until limit rpm to gear up. so if your limit is 9k and max power rpm is 8k you are good.
on the other hand the real power output is not the same as the curve right now, we subtract the friction torque to get the final torque value. so if you increase friction torque you will the see the same max power value but in reality the power is reduced.
2 Likes
Im using “mVehicle->getSteerDeltaAngle(true)”, for a counter steer condition, but having some problems.
At some point, if you turn fast or spin, the sign goes to opposite, from -90 to 90,etc… even if the car is constantly turning to the same side always.
This breaks the condition and its applied in wrong scenarios.
Is there any way to fix that?