Hi FGear Dev! Question: When I Un-possess a vehicle with the Non-Server Authoritative mode, then the vehicle is teleported to 0,0,0 and I can’t seem to do anything about it.
Do you know of a solution here or am I forces to use server authoritative to prevent it?
I’m on UE 5.5 and your latest version of FGear
Update: I can get it to not teleport if I possess the vehicle with a temp AI controller then moment after I possess my character pawn
thanks for the feedback, I have confirmed the issue and it’ll be fixed in the next update.
in the mean time you can use that workaround, it seems harmless.
Been quiet in here lately. Anyone tried to compile the plugin for 5.6? Got a couple of warnings about deprecated stuff and one error. Hopefully official support is coming soon. Also looking forward to the next product from the devs will be.
@lazybitgames any ETA on 5.6 support?
this month or next month at the latest…
an update on this issue.
with client authoritative mode the local player has the authority over the vehicle transform but when you unpossess the vehicle there is no way to tell others about your transform so the server must take over just like AI controlled vehicles. in short your workaround seems like a valid solution, i’ll only prevent the teleport to zero origin just in case the developer fails to handle the case.
v1.8.3 is now available
Notes
Warning: If you have difficulty running the example project with Unreal5 copy the FGearPlugin folder in Unreal5\Engine\Plugins to FGearExample\Plugins folder.
@lazybitgames
Thanks for the update, but I noticed a few issues:
(I’m using manual transmission with automatic clutch)
I think it should work according to the speed, gear and slope (you can check if the vehicle’s rotation in Y is positive or negative to know if the car is going up or down), for example:
If I’m in first gear on a hill, I stop accelerating and the car reaches a certain negative speed, the system should be activated simulating the gear holding the car, but if I put it in neutral or in a gear in a favorable direction (Reverse on the uphill and any other gear on the downhill) the system should turn off and allow the vehicle to move. If the vehicle’s rotation is close to zero, the system should not be activated.
The “Allow Wheel Rotation Against Engine” seemed to work perfectly, why was it replaced?
I’ve retried to change gears with a manual and it released the brake with a gear change(tried both forward & reverse). I think auto clutch has a problem, can you try those with a manual clutch.
I also didn’t encounter any stuck cases, if you consistently see those behavior please send your json files and describe how to recreate it.
“Allow Wheel Rotation Against Engine” was conflicting with another feature which caused a bug and it’s also not a realistic feature.
debug gizmos show the correct position, I was mistaken earlier, there is no problem with that. again if you think there is a problem please elaborate.
My problem with the debug wireframe is the following:
My rig has two bones for each wheel, one for the physical wheel and the other for the geometry. (I did it this way so I could animate the suspension and kingpin correctly)
When I apply the offsets (forward and spacer), the collision of the physical wheel goes to the correct place, but the debug wireframe does not follow it, but it works with the Rim offset.
My question is why the wireframe is not following the wheel collision, does the fact that the bone has no geometry influence anything?
I tested Hill-holder assist with the manual clutch and the problem persists. I am attaching the Json file.
JampFGearVehicle.json (8.1 KB)
this is how it works in general:
bone position = forward offset + spacer offset + vertical offset + suspension travel
wireframe position = bone position + rim offset
bone position represents the visual of the wheel, wireframe position is the physical wheel(there is no physical wheel but it’s the origin of the ray/volume queries). the difference between rim and spacer offset is that rim offset only moves physical wheel but spacer moves both.
will check your json for the hillholder case.
yet again I don’t see a problem with hill-holder but it’s clear there is a bug with auto-clutch(the rear gear case).
you’re not directly using the standard input, I guess there is a problem with how you apply inputs.
My input is customized to fit the SimpleController plugin, unfortunately the Hill-holder assist is breaking my game, would it be very difficult for me to re-implement the “Allow Wheel Rotation Against Engine”? (actually only the part of the code that denies this function, working as standard)
In my case I would need to move only the physical wheel, and have feedback from the wireframe if my calculation for adjusting the wheel rotation in relation to the kingpin as a pivot is correct, would there be a chance for you to implement a forward offset that works like the rim offset?
reimplementing “Allow Wheel Rotation Against Engine” is quite easy if you’re building from source, you just need to add 2 lines to the wheel class, if you’re up to it drop a mail.
the origin of the wheel bone can be shifted on Y axis so I have added the rimoffset feature to quickly fix mismatches between physical wheel and the wheel mesh. it’s unlikely that the other axis’ will be shifted so the other offsets are not required and at the end of the day you can do that shift yourself in the anim bp.
Comparing FGearWheel.cpp from 1.8.3 with 1.8.2, I saw that these lines below were removed, should I just copy them back?
820 bool allowReverse = mVehicle->getAllowReverse();
831 //if overflow is not the same sign as limit, then set tire speed to 0
832 else if (!allowReverse) mRealSpeed = FMath::Lerp(mRealSpeed, 0.0f, clutch);
844 else if (!allowReverse) mSpeedOverflow = 1.0f;
Since I’m going to have to recompile the code, is there any simple change I can make so that the wireframe follows the forward and spacer offsets?
for allowReverse just get rid of the conditions like:
else /*if (!allowReverse)*/ mRealSpeed = FMath::Lerp(mRealSpeed, 0.0f, clutch);
...
else /*if (!allowReverse)*/ mSpeedOverflow = 1.0f;
since you want the behavior where it’s false.
wireframe code is a bit more involved, i’ll take a look and paste here when I get the time.
Thank you, everything is working properly again!
You mentioned that using “Allow Wheel Rotation Against Engine” causes a conflict with another feature that causes a bug, what is the feature and the bug? That way I can avoid using it.
I’m trying to make a replay system using a vehicle proxy, I can record things like the vehicle’s position, wheel rotations, suspension height, etc., but how could I record the moment the dust FX is played on the wheels? Is there a variable that is provided by the wheels (and exposed in BP) that when it exceeds a certain value means that the particle has been emitted?
here is the post that mentions that bug: FGear Vehicle Physics (v1.4) - #1683 by Davit_Masia
I didn’t look for the cause since I wanted to remove the option.
and about replay system, you can take a look at the provided replay system in fgear, basically we do not save any FX data but expect a similar FX to be generated based on inputs and the transform. if you want to roll your own system you can take a look at the UFGearEffects::effectUpdate function where we compile some wheel slip data to trigger the effects.
and for the offsets you could try the below code (didn’t test it)
I don’t think it’s a bug, it’s normal for a vehicle with an automatic transmission in D to move forward slowly even without pressing the accelerator. I tested it here on a clean project and the car doesn’t move when in N or with the clutch pressed.
I think you should keep both systems, the “Hill-holder assist” for arcade vehicles with automatic transmission and the “Allow Wheel Rotation Against Engine” for vehicles with manual transmissions. (In “Hill-holder assist”, it might be better to remove the “On Brake State Changed” when the vehicle is on a flat surface, it’s strange to see the brake light turn on without pressing the brake.)
Thanks for the code!
It worked! I finally managed to make the physical wheel follow exactly the rotation arc of the visible wheel in relation to the kingpin (for an offroad game with rock crawling it is very important that the wheel has perfect contact even with the smallest rocks).
About the replay, I wanted to do something super light, using a vehicle proxy without physics or anything, then I should be able to record and reproduce everything related to the vehicle and the wheels, I can also record things like the brake light and backfire through the events, the only thing missing would be the moments where the dust fx was activated. Would it be too much work to expose a boolean variable indicating whether the fx is active or not? (I believe it would also be useful to reproduce the skidding sound)
Hello!
It seems that the keyboard controls have some kind of problem, when i use the directional keys to turn the car around sometimes there is latency or seems like there is a force fiighting the input direction. For some reason is more common/pronouonced turning left. Gamepad controls doesnt seem to be affected.
Tested with same results in UE 5.4 and UE 5.6
