@lazybitgames Seems any camber related coeff not updates the curve. Maybe due like Load or Pressure they have a nominal/default param? Any way to fix? so i can check the param behaviour on the curve.
EDIT: Same for the entire combined longitudinal and combined lateral coefs, but no idea if this ones should or not.
there is no reference camber value so camber is always zero in the preview curves.
I added to my todo list and you can easily add a reference camber value:
1-add a new variable called reference camber just like reference load in FGearTire.h
2-give it a default value (0) in the constructor.
3-find each âcalculateâ call in FGearTire.cpp(there should be 4) and pass the reference camber value instead of zero. the input is in radians so you may want to convert it to degrees first.
you canât preview the effect of combined parameters since the preview is only for pure lateral/longitudinal behavior.
@lazybitgames I found a possible bug with ABS.
I have ABS set to 50. If i accel and hold like 20-30% throttle, then i press & hold brake just a bit, between 1-10%, the car increases speed. I can see the LngFF going from 4000 to -4000 when brake presure pass from 4-5% or similar.
With ABS to 0 no problem, in the moment brake is pressed the car speed goes down. In my case starts to notice from ABS 10% to 100%.
Tested with FGearExample, you have to uncheck combined axis. Set ABS to 100. Accel a bit so the car set in a stable speed, like 20-30% throttle, then press and hold a bit the brake and the car will start to accel.
thanks, I saw it happen with like %1-2 brake and it only happened at first gear, anyway iâll look into it.
Great!
In extreme tests with 100% abs, it happens from 1-3 gear, with a range of 1-11% brake, when more throttle seems car speed up more per %brake Âż?. Guess based on car setup like engine inertia and other stuff the problem is more or less evident. For example when cornering and you need to brake just a bit for a small correction on a steady throttle it ruins the smooth driving.
@lazybitgames Im doing some brake debug values and now testing HandBrake found another possible bugs. Due this can be a bit large here the first part:
Situation: Holding Full throttle + HB.
A) Rear BrakeTorque at 6k = Rear wheels locked & car can move due front wheels still spinning.
But,
B) Rear BrakeTorque at 9k = Rear wheels locked & car cant move even if front wheels spinning
I thinks thats wrong.
BrakeTorque force should be applied only on rear wheels to decrease/stop/lock them, but not interfere in vehicle overall force, Or im missing something Âż?
More or less BrakeTorque will make faster/slower decrease, but after wheels are locked, vehicle should behave the same no matter if 6000 or 9999 or whatever.
Another thing about HB is on release, there is a high spike in LngFF & LatFF from one frame to another resulting in a too fast impulse in some scenarios. UP engaged, Down one frame after release.
On engage, you usually want as fast as possible but still some modulation for some maneuvers /smooth transition can be good too.
Rally and Rallycross cars have a lever to pull and modulate.
To fix this, wonder if will be possible a âHandBrake sensivityâ inside StandardInput component, under âBrake Sensivityâ options.
Maybe some slider to tell in ms how much you need to press the button for full effect(BrakeTorque Value 0-100%), same for release for full config, like:
Engage = 20ms, Disengage = 80ms or similar.
iâll check the issues.
handbrake will be a floating point not a boolean anymore.
Ok! And for last,
I had a problem with HandBrake, due holding throttle + HB, rear wheels still rotates.
Tried with HandBrakePower to 99 from Simulation category but nothing.
One workaround was set 14k BrakeTorque on rear, but thats too much having in mind i need front biased and using already 8k front.
To fix that, actually using my own code in FGearWheel to set torqueShare at rear to 0 if HB is pressed which it worked. Now, with 6k BrakeTorque on rear axle and HBpower:4 can stop rear wheels at 250km/h. With HBpower:3 at high speeds needs some time.
I think if i press handbrake the rear wheels should stop at any speed based on previous engage/disengage criteria and HBpower deprecated.
I canât make a rule based system like if handbrake on then lock the wheel etc.
handbrake will only lock if the acting forces are strong enough to stop the wheel.
your workaround sounds harmless so you can go with that.
Ok, youâre right, i missunderstood, thought when handbrake is 100% pulled, always lock the wheels but nope, still can fail.
Then HBpower maybe should be done in another way, due with 6k BrakeTorque and 100(max) HBpower cant lock the rear wheels and it should.
I saw in FGearWheel:
else if (mHandbrakeActive){ deltaV *= mVehicle->getHandbrakePower();}
Maybe that HBpower should multiply BrakeTorque on wheels with HandBrake instead of deltaV?
So if i set HBpower to 4, when i press HB, the 6000 brakeTorque at rear will be 24000, enough to stop the wheels. Then no need for torqueshare=0 or other workarounds.
What you think?
-
EDIT: I want to remove my workaround due may contribute on fast impulses when torque in rear is set default again (i have a lerp to make it smooth but even with that)
Also due my workarund i have to edit too torqueSplitter to exit function when using HB to avoid interferences in torque management.
scaling the brake torque will make the vehicle slow down quicker and you may not want that.
try removing the limits on handbrake power and set it to a big number, if it still fails then it is most likely that the code doesnât reach that line since the netTorque value should be positive. in that case you need a workaround.
Nope, it no matters, even with *9999 HBpower, if throttle & HB pressed, rear wheels never locks.
I just want that on press HB, be sure the rear wheels always lock(no matter speed or what) + Smooth engage(avoid sudden stops) & disengage (avoid spikes=fast impulses).
Fast try and seems it works. Tomorrow will find the correct BrakeTorque to multiply by HBpower.
if ( mHanbrakeInput) {
mVehicle->getAxle(1)->getLeftWheel()->setBrakeTorque(14000);
mVehicle->getAxle(1)->getRightWheel()->setBrakeTorque(14000);
}
else {
mVehicle->getAxle(1)->getLeftWheel()->setBrakeTorque(6000);
mVehicle->getAxle(1)->getRightWheel()->setBrakeTorque(6000);
}
Also after first tests seems with this method no spikes/fast impulses on release Âż? will test more in depth tomorrow.
Doing some tests to lock the wheels and checking code, seems is mWheelTorque who causes difference in car final force after wheels locked.
After debug, mWheelTorque is used later in âcurrentforceâ
float currentForce = FMath::Clamp(mWheelTorque, -absLngFriction, absLngFriction);
And ânetTorqueâ
float absWheelTorque = FMath::Abs(mWheelTorque);
float netTorque = absWheelTorque - absLngFrictionTorque;
float angularAcc = FMath::Sign(mWheelTorque) * netTorque * accCoeff; //signum
float deltaV = angularAcc * dt;
So, my question,
Is that accurate?, more brakeTorque or negative mWheelTorque should affect in overall car force after rear wheels locked?
Not should be the same? if at 6k already locks the rear wheels and car behaves X, why 9k should make the car unmovable?
I donât see a problem with the code but my previous comment might be incomplete.
scaling the brake torque wonât change the deceleration after the wheels are locked but will change how fast the wheels are locked.
also when I convert the handbrake value to floating point and a partial handbrake that doesnât lock the wheels will slow down quicker. for a boolean handbrake I guess it wonât be much of a problem.
This is the test to see clear,
On car still, pressing Throttle + HB:
A) Rear BrakeTorque:6000 = Rear wheels locked, Front wheels spinning, Car moves.
B) Rear BrakeTorque:9000 = Rear wheels locked, Front wheels spinning, Car dont move.
Then, if at 6k rear braketorque, wheels are locked and car moves, at 9k should move too, due only should affect to wheels not the vehicle.
But mWheelTorque value is used also on âcurrentforceâ & ânetTorqueâ, so with bigger values seems it decrease the overall vehicle force/inertia too.
So, i think in one or both not should be used, or in their functions should include a locked wheels exception.
I need to see it happening, in my case I donât see it with the red car in sample project yet.
trying with 10k and 100k rear brake forces and both locks the wheels, front wheels spinning and the vehicle moves slowly forward.
can you give parameters to recreate it in the sample project or the vehicle json file.
Hi, sent you via email the FGearExample with the proper setup and how to reproduce the issue.
Thatâs why I asked you if he had an image so I could understand it well, since when he told me not to interfere with the Ai controller, I was totally confused.
@lazybitgames Some possible physics issues to check at UFGearWheel::updateWheelSpeed:
//take engine inertia into account
float engineInertia = mVehicle->getEngine()->getEngineInertia() * mVehicle->getTransmission()->getTransmissionRatio();
I debugged and âgetTransmissionRatioâ output is: Current Gear Ratio * Final Gear Ratio.
But not squared, as formulas im checking like = âI_reflected = I_motor Ă (Gear Ratio)²â.
Some Source: Calculating effective inertia
Maybe due the missing squared in GearRatio, to compensate you added â/ mRadiusâ Âż?
Also due on reverse getTransmissionRatio() gives negative?
/
Then if that assumptions are correct, it should be something like this?:
float totalRatio = mVehicle->getTransmission()->getTransmissionRatio();
float engineInertia = mVehicle->getEngine()->getEngineInertia() * totalRatio * totalRatio;
engineInertia = engineInertia * mAxle->getTorqueShare();
float engineCoeff = 1.0f / (inertia + engineInertia);
Removed the ABS on final engineInertia due now totalRatio is squared and no needed.
Maybe add ABS on âfloat totalRatio =â. To be clear we only reaching for magnitude.
What you think?