Well, after some fixes, now our config version work for gamepad having only one set. And works steering in both sides. But keyboard due we removed one it not works for that side. If we setup both left and right, keyboard fine but gamepad broken…
Im missing something or there is any bug?
-
EDIT: This mapping worked for us:
for IA_Left no map the gamepad. And for right, add the dead zone with default values.
I didn’t see a problem.
“Combined Axis” mode also effects the enhanced input.
for combined mode you need to use the “vertical” and “horizontal” axis.
in other case you need to use throttle/brake & left/right axis.
with enhanced input some standard input features(like deadzone) are not needed anymore but they can work together so I don’t see much harm at this point. I may remove some of the standard input options in the future.
With enhanced input needs to be configured exactly like that in the IMC or not works fine.
I not use combined axis.
For one side, for keyboard you need to set both, left and right inputs.
For gamepad, you only have to set one of them, right or left, if both steer not moves.
In this case the right one, and use the DeadZone, without deadzone not works as it should, one side returns to center more slow, like double time. I have set 0.2, but seems starts to works fine at 0.04 or similar but there is some missalign when you drop the stick, it not goes exactly to center, so i leave it default 0.2 just in case.
With this exact config i can get all working as expected.
Maybe im missing some config or checkbox for gamepad but tried lots of combinations and this is the unique that works for me. Will be great the red car have the inputs for gamepad too.
If this is wrong, what exactly should be the config for gamepad?
@lazybitgames On cornering / 180º, at low speeds and drifting, gear goes to 1st and engine reach the rev limiter.
In Dirt Rally 2.0 seems there is something that reduces that, even with all assits off.
Setting max Traction Control it reduces hit the limiter almost always when cornering and only hits on straights and jumps.
Guess this is related in how FGear manages the transmission, gear ratios, GearUp/Down ratio and velocity bias but tried various config an nothing.
Always the car goes to low speed it changes to 1st and hits rev limiter.
In FGear:
Dirt Rally 2: Polo | Goes to 1st but no rev limiter
Dirt Rally 2: Subaru can keep 3-4gear with same maneuver
How to achieve this in FGear? or what is the assist or tech behind that? So i may try to replicate.
logically the vehicle should gear down when it slows down, in this cases it almost stops or even going backwards. it might be looking at the wheel speed instead of velocity.
currently fgear uses minumum wheel speed and velocity so you could first try to use the maximum wheel speed in gear change code and velocity bias should be zero. try replacing getMinWheelKMHSpeed with getMaxWheelKMHSpeed in transmission class.
another thing comes to my mind is that they might be avoiding the gear change somehow and partially disengaging the clutch to avoid a stall. this might work but it won’t be trivial to implement.
It looks it has by default some traction assist that sets the best gear and maybe reduces throttle or some RPM target to avoid spin the wheels and get faster forward avoiding hitting the rev limiter?
Btw, Thanks will try all that to see if i can get somewhere.
@lazybitgames I think found what DR2 does, or at least 2 of them:
Projected RPM check:
Good automatic-shift logic doesn’t just shift when current RPM < downshift threshold;
it computes the resulting engine RPM if the car actually shifted into a lower gear given current wheel speed.
If projected RPM would exceed the limiter, the shift is blocked.
Hysteresis / timing & smoothing
To avoid shift-flapping; after a big maneuver the controller waits before allowing large downshifts.
Guess thats why i never see the car hit the rev after downshift like in FGear in auto or the shift hunting under some scenarios.
This probably can fix most of the problems im having hitting the rev constantly while drifting.
hello @lazybitgames How do I replace the “particle emitter” for Niagara Falls? It’s for the smoke effects and the physics of materials.
I never used niagara, I guess it’s also time to update the effects component.
that would be great. I made a child of the effects comp by making the parents functions to protected. And added a Niagara component to a child of the Fgear PM. Works but I’ve gotta redo it with every update. It would be nice if we could get access to some sort of GitHub repo to test your upcoming updates and add them to our projects pending final implementation or update to fab.
I have another approach, my own Physical Material, with niagara for smoke-skids-sparks, sound, etc.. and as a child the FgearWheels for the Friction & Roughness logic, so no need to use FGearEffect component and no need to redo that things in every update.
the effects component is not meant to be used for production, the implementation is rough and not polished. that’s why it’s lower priority. my recommendation is to roll your own solution and just learn from the effects component if needed. cascade is deprecated so I guess I can make a quick conversion there.
for me providing an online repo to users is a different level of support which would force me to change my work style(not mentioning the monthly fees) and I’m not planning to do such a thing for a plugin that doesn’t generate much income.
I also tried sth. today and it kinda worked well, check this out.
the code to make it happen is very simple, find the shift down code in transmission class and replace with this:
float sr = mVehicle->getMaxWheelKMHSpeed(true, false) / (1.0f + mVehicle->getKMHSpeed());
if (sr <= 1.0f) gearDown(true);
So it should look like this right?
else if (speedDown < mDownSpeed && mCurGear > 1)
{
float sr = mVehicle->getMaxWheelKMHSpeed(true, false) / (1.0f + mVehicle->getKMHSpeed());
if (sr <= 1.0f) gearDown(true);
}
Because if i replace the entire block, else if, by your if, it does weird things and cant the car go forward.¿?.
This is my transmission setup:
Video with your edit, i feel it still does the same.
it looks alright except mine is in a different branch so it needs a minor fix, try this:
if (FMath::Abs(sr) <= 1.0f) gearDown(true);
the idea is simple, downshifts are prevented when there is positive slip, if you keep throttling and the vehicle is strong enough then it won’t downshift.
…
still testing this, here is another update:
else if (speedDown < mDownSpeed && mCurGear > 1)
{
//gearDown(true);
wspeed = mVehicle->getMaxWheelKMHSpeed(true, false);
float sr = wspeed / (1.0f + velocity);
if (FMath::Abs(sr) <= 1.0f && FMath::Sign(wspeed) == FMath::Sign(velocity)) gearDown(true);
}
This new one starts to do what i expected with gears, the problem is the car wheels on doing the 180 some get negative speed in one side but in other like 80km/h creating a bad behaviour
On drifting on a track avoids downshifting and hit the revs but at some point while cornering it hit the revs in 3rd on cornering making the car unestable due difference on wheel speeds.
With the previous the car hits too much rev limiter but the downshift seems help to keep the slide angle and stable, but due high Gear some wheels not have enough force, other too much and creates that bad behaviour on steering.
you could try increasing the threshold so that only higher slips can prevent the downshifts.
instead of FMath::Abs(sr) <= 1.0f maybe try sth. like FMath::Abs(sr) <= 1.15f
idk if that would work, another idea is that you could let the downshift if the gear is 3 or more. in that case it will stop downshifting at 2nd gear.
the absurd difference between left and right wheels can only be solved with a more accurate differential and it is one of topics that I have been working on. I think it’s one of biggest challenges of vehicle physics development.
Ive been testing lot of combinations and start to get something after this:
Hitting rev limiter is reduced on track drifting, most of it due keeps on 3rd more time and rev hits on 2nd, not downshift never to 1st(unless driving mistake), this makes less slide but more stable-controlled direction.
Probably with a better gear ratio config and maybe some logic on autoshift when it detects the car is sliding can do it without hit revs.
On 180º goes down max to 2nd but hits rev limiter, all wheels similar speed so feeling is better.
The feeling overall is like the speed and traction not match ¿?, so it sometimes you get more traction that you should and sometimes slide too much, and if this happen sudden you can feel the car unestable during that transition.
That huge diffs on wheel seems to hapens due stall assist, if the older setup just disabling stall assist, wheels more similar, but on 180 goes from 4th to 1st sudden.
In DR2 in this 180º case, the car still feels responsive and slides even in 3-4th gear.
But well, guess better wait to the big update due with lot of changes i will need to calibrate all again with new drivetrain and different behaviour. Still no date aprox?
still in progress, hard to give an eta and I haven’t decided to go for fgear 2.0 or a big update yet.
there are many changes and new features on the physics side and I also want to reimplement some unreal related stuff but then it might be impossible to switch to the new version without losing all your vehicle blueprints. anyway once all physics features are done my first target will be releasing the unity version, it’s way easier and there is less work there. when it comes to unreal it’ll probably require more time and work. but it is always the physics side that is important and the rest is just about time.
stay tuned and in the mean time we can discuss unreal specific changes here.
for instance,
any need for keeping unreal4 support?
do we need a more polished effects component?
do we need static mesh support?
do we need fixed timestep support?
…
let me know, i’ll keep taking notes.
Unreal 4 is still very relevant for mobile development and especially for VR. My Meta Quest projects take a performance hit of about 35 to 40% every time I try to port them to UE5. Not to mention that for physics-based games, Chaos on mobile is much heavier and more problematic/instable than PhysX.
The effects are a great selling point; however, it would be more interesting if they were more modular. For example, being able to disable the tire smoke but enable the sidmark and skid sound, or disable the engine sound (to use Fmod or Wwise). In fact, what first caught my eye about your plugin was exactly the presence of effects and the time that would save me.
Some things I suggested before and I think would make the plugin easier to use:
Implementation of tire presets for different surfaces (arcade-style), with the option for dynamic swapping. I know it’s possible to change the lateral and longitudinal friction of each tire, but the more easy and modular the plugin is, the better for new users. Also, adding presets with physics materials for various surfaces (using that table I sent or some other better source) would help a lot.
A kingpin offset option for open-wheel vehicles (I managed to do this well using a map range on the forward and spacer offsets, but it could be more simplified for new users) and a way to detect wheel collision. (Maybe combining a few line traces with the wheel’s convex collision).
Wishlist:
Integration with other well-established assets and plugins in the market would also be a huge plus. For example, an integration module for controls with the SimpleController plugin, or exposing variables with specific naming and calculations already done to work well with the vast number of vehicle audio systems provided by Skril Studio, etc.
I know that many of the things I’ve suggested can be achieved with the features already available in the current plugin, but they aren’t very intuitive. Making things more accessible could make all the difference in reaching a larger audience and reducing support requests. Game developers might seem lazy sometimes, but in reality, they’re just looking to save some time across the many stages of completing an entire game.
