Warning: If you have difficulty running the example project with Unreal5 copy the FGearPlugin folder in Unreal5\Engine\Plugins to FGearExample\Plugins folder.
Notes
Engine stalling is only meant for manual transmission/clutch mode. You need to set a stall rpm and stall time, when the engine is forced to go below that rpm for enough time then the engine is forced to stop. A negative stall time value will prevent stalling.
Removed a problematic clutch axis from the example project which kept the clutch pressed with a controller.
Fixed the case where engine doesnât rev-up when started in neutral gear.
Pause button added to replay sample so itâs possible to pause the replay now. Also it is possible to access the variables of this class from blueprints.
Forced symmetry on all sample tire models eliminating left/right steering balance issues.
Great, the stall system is working perfectly. Thank you!
Possible Bugs:
When starting the game with the car in neutral, none of the brakes work (hand/pedal), only after engaging a gear do the brakes work.
After passing from a surface with high roughness (FGPhy) to a surface with standard Unreal physics:
Using semi-automatic or manual gear, the engine stops revving when engaging any higher gear.
Using automatic gear: it no longer shift to up gears.
Suggestions:
Some functions that are only triggered by the plugin could become events, such as Stall and Sleep, for example, when the vehicle stalls, the dev can use the event to turn off the dashboard lights or trigger some sound, etc.
When you are on a low-friction, high-roughness surface, such as in a mud pit, it is very easy to turn the vehicle practically on its own axis without any effort. I believe it would be more interesting if the vehicle had more resistance to turning.
Question:
I donât have access to an automatic car. I would like to know how this type of vehicle behaves when it cannot climb a steep hill? Considering that the player will keep his foot on the accelerator without using the brakes: Does the vehicle stall? Does the vehicle go down? Does the engine rev?
In the case of the plugin with automatic transmission activated, the vehicle remains stationary and the engine does not rev. Is this correct? (With stall assist on, the tires skids and the engine rev. Personally, I find this method more interesting, but even with this assist on, the previous behavior still happens sometimes.)
In the case of the manual vehicle, it loses power until it stalls and is held by the gear (it is now possible to replicate this behavior with the new pluginâs stall option).
I canât reproduce the bugs you mentioned, if you can recreate them in the example project please send me a video via mail.
there is a sleep & wake event but for the engine start/stop you need to poll the engine.isRunning state.
I also tried a low friction high roughness surface and I couldnât observe what you describe.
about stalling, the vehicle can stall when auto-clutch is off but as I have mentioned stalling is meant for manual transmission, it might work with other settings but the behavior is untested/undefined.
Itâs easy to reproduce, just duplicate one of the terrain demonstration areas (ice/nature) and apply a new material representing the mud with FGear Physical Material (Friction 0.1 / Roughness 3.0) and remove the PhysMaterial in the GreyGrid Material Instance. You will notice that after leaving the area the vehicle will be âweakerâ, unable to reach enough revs to advance the gears. (I can send you the modified example if you prefer). I belive it must be something simple, like because the default physics material doesnât have the same values ââas the Fgear physics material, the plugin ends up keeping the old values ââin the calculations.
Also when crossing the mud area, you may notice that it is possible to turn the vehicle easily at the same speed as if going forward.
I also couldnât reproduce the brakes problem in the Fgear example project, it must be something related to my project, I need to investigate further.
The event for the stall would be something simple, like the âOn Brake State Changedâ that is already present in the plugin but without the need to inform about the status change.
alright, I see that now, yes itâs a quite simple bug that can be fixed with a single line.
for anyone that works with the source code go to UFGearEffects::physicsSurfaceUpdate function and update like below:
for (int i = 0; i < mWheels.Num(); i++)
{
UFGearWheel* w = mWheels[i];
w->setFrictionFactor(1.0f);
w->setAdditionalDrag(0.0f); //add this line to fix
...
}
and about turning the vehicle easily, the roughness effect only adds a drag force along the wheelâs forward direction, iâll try applying it along the horizontal axis of the wheelâŚ
Im doing some revision to the car suspensions, and want to confirm if âSuspension constraintâ component is the best solution compared with that hard contact scale? Can both work together without problems or if using the constraint component let hard contact scale to 0?
I donât recommend suspension constraint component and it might be removed in the future. the reason is itâs behavior is not tunable and it can bounce the vehicle.
hard contact can also be bouncy but you can reduce itâs scale for better response with acceptable short penetrations.
I see, im saying that because in the v1.4 was added and this was mentioned in the log:
â-Suspension constraint adds a joint to each wheel and updates their limits at each tick.
This works much better then âHard Contactâ option so this is the recommended solution now.â
Ok then, so now recommended is âHard Contact Scaleâ tunned based on the car setup to avoid the bouncy behaviour but still enough to avoid reach the limit as much as possible.
So far I had only tested convex collision on small surfaces and terrain, but when testing on steeper obstacles, I noticed that convex collision doesnât work, the wheel goes into the object. I need the wheel to have a precise collision with the rocks while the player climbs a hill for example, itâs a more technical offroad game, the sphere collision works well, but it exceeds too much to the sides making it useless in my situation, the line trace option with multiple line traces (9 x 3 sides) works well most of the time but I believe it must be heavy for mobile devices to handle that amount of line traces. Am I doing something wrong, is there a way to make convex collision work with steeper surfaces?
itâs not about precision but about the nature of shape casting.
we have discussed the issues of open wheels before and currently fgear can not handle those cases.
multi line casting handles this up to some extent but itâs not perfect, sphere and convex casting will directly fail. it might be possible to achieve similar results with sphere or convex but you would have to cast multiple times(no such feature available right now).
I think hybrid or pure rigid body wheels are more suitable for off-road sims and we donât have that right now.
Thanks, Iâll try to use only line traces, most of the time with 3 or 5, I think itâs enough to not pass through fences and other vertical obstacles, when in more technical areas I change to 9x3 (or as many as the device supports), and I also wonât use rocks with an inclination greater than 75 degrees.
I think a combination of convex and line trace would be interesting, just a few horizontal and diagonal line traces would be enough to prevent the wheel from passing through vertical obstacles (like in the video). In any case, it would be heavy for mobile devices, right? But it would be interesting for those who develop for PC.
Always wanted to create some sort of racing game but fell short of a vehicle adjustment screen such as this, if you dont mine me asking, how were you able to create the ui/menu screen that allows for vehicle adjustments.
Thats not mine, is from Dirt Rally 2. My game still not have any game UI. Btw, if i remember well, on marketplace there are some âmenuâ plugins/bps and other stuff that should make it easy, check them before do your own system.
@lazybitgames is it possible to allow further customization of the trace channel type? Now you can only set the custom channel but you cannot customize what the individual responses are.
@lazybitgames Differential Lock/Open are correct? i think they are switched.
In theory open means each wheels goes freely but:
if (mDifferentialType == FGearDifferentialType::DF_OPEN){
mLeftTorque = mRightTorque = getOpenDiffTorque(); }
And locked should be they goes at same speed but it does the opposite. Âż?
Then for L-S-D there are two ways to manage this, with Differential Strenght or by Lock %.
I guess if change the conditions open/lock, on L-S-D i should change the order for open/lock so Diffstr gets working as it should, or leave as it and change diffstre by locking%.
open diff transmits the same amount of torque to both wheels but one of the wheels can steal the power if itâs on slippery surface. locking diff(l-s-d) transmits more torque to the wheel that has more grip. this is correct in code so I donât think theyâre inversed but none of these enforce any speed on the wheels which is a limitation of fgearâs differential implementation. the only speed enforcement is done with the locked diff. if you check UFGearAxle::postWheelupdate, you can see that the wheel with the most grip enforces the rotation speed.
in short the differentials are not broken but theyâre not perfect either. the reimplementation of the drivetrain is a topic of a future fgear 2.0 versionâŚ
to mimic a differential preload you could add/subtract a certain amount of torque to the differential output in UFGearAxle::getLockedDiffTorque.
I have no plans to do major simulation changes in the fgear 1.x branch, I just donât have enough time right now. when I get the time my plan is to work on a possible 2.0 rewrite but that is unlikely to happen in the short term.
