GPL 1967 v3 Dev blog

[MonteCristo]

Bottom post of the previous page:

@MonteCristo Potentially. I'm thinking something like - "If code rolls a 7-7-7 (since damage is a random number generation system), do Power x 0.95". That would simulate say, loss of a cylinder. It wouldn't come up on the race report though. Random failures should already be a part of the game but probability is so low you mostly won't experience them.

I suppose the next question then is how you inform the driver.

If you're driving in real life, you can hear a change in engine note, or hear (or maybe feel in a small car?) a knock. But aside from power dropping 5%, and lap times going down all of a sudden for no reason, it would be hard to tell that you're meant to be nursing a problem.

Obviously the car can trail smoke, so maybe that's one way of notifying them. But not sure what else there is.

[PTRACER]

@MonteCristo Potentially. I'm thinking something like - "If code rolls a 7-7-7 (since damage is a random number generation system), do Power x 0.95". That would simulate say, loss of a cylinder. It wouldn't come up on the race report though. Random failures should already be a part of the game but probability is so low you mostly won't experience them.

I suppose the next question then is how you inform the driver.

If you're driving in real life, you can hear a change in engine note, or hear (or maybe feel in a small car?) a knock. But aside from power dropping 5%, and lap times going down all of a sudden for no reason, it would be hard to tell that you're meant to be nursing a problem.

Obviously the car can trail smoke, so maybe that's one way of notifying them. But not sure what else there is.

Maybe that's ok though? If it happens on a straight the car will unexpectedly slow down. And the driver should notice the car being lazy under acceleration.

I don't have time this weekend but I will see if I can implement something sometime.

[Michkov]

I like the idea of random failures. As long as they are not implemented like in GP2. There you'd get assigned a random failure at the start of the race and no matter what you do it will happen. Something I'd love to see is gearbox failures, I havn't seen that in any sims so far.

[MonteCristo]

Well as a sim driver you'd certainly know if you're missing a gear!

[PTRACER]

I had more time this weekend than I expected so i looked into the damage code as a provisional step to adding more damage types. What I saw was a bit disappointing.

Basically for overrev damage, the game does a calculation to check whether you are overrevving and by how much. Then it disregards that calculation and then just applies a fixed damage amount to the engine if overrev = yes.

So I had a play around and managed to implement an increasing amount of damage based on how far over the limiter you've gone. For something like the BRM, 1500rpm over = instant death, but you could hold 500rpm over for a decent amount of time without too much damage (though it will catch up with you eventually). This is a vital change if I am to implement the Disable Rev Counter code.

[leon_90]

I'm having fun with the x86GP2 version of Grand Prix 2 and man, those mechanical failures are such a fun twist! You start a race with no idea if you're going to crash, if someone's going to take you out, or if your car is going to break down on you. It's refreshing and makes for unique races every time you jump in.

The gamepad implementation is also state of the art. Better than most sims out there. For me, only AC and ACC are on the same level, if not better. You can set speed sensitivity, steering sensitivity with compression to change the curve, dead zones and most importantly there is an option for the steering wheel not to follow the raw input but to turn based on the actual possible range set by your speed sensitivity value! That's something that was previously only available in AC and ACC! It makes for such smooth steering, with no jerkiness. The triggers can also be customised. The only thing missing so far is the option to split the triggers (and rumble, but that's because GP2 has no FFB).
If possible, I would suggest to copy/paste the code written by the author of x86GP2 (with his permission of course) into GPL

[PTRACER]

Had anyone ever noticed that, when stationary, the rear wheels of GPL cars still spin slightly? (Especially when parked on a hill in 1st gear)

From what I can see this is happening for a couple of reasons I don't fully understand but kind of get:

1. Something called numerical drift around extremely low values near zero. This is where everything should be 0.00000 but actually the sum of ALL physics calculations turns out to be 0.00001 or more and then it can't stay there and the numbers start increasing by themselves until they hit some kind of stop like rolling resistance.

2. The absence of static friction in any of the code (a force that must be overcome before an object can start moving).

The devs settled with applying the brakes automatically if the vehicle's speed fell below 0.35kph, which provides some resistance to initial movement, but for heavier cars the brake is not strong enough.

So, I wanted to find another solution.

Firstly, I disabled auto-brake to see what happens. Not only does the car roll forward when facing down a hill (with the wheels initially spinning backwards and not forwards), but if you park the car at a 90 degree angle, it will slide down the hill laterally as well. Very frustrating.

Early attempts had me artificially locking the car to 0kph if the speed fell below 0.1kph but then the car stopped being able to move at all. Increasing the base grip did nothing and actually made the issue worse somehow. And increasing the strength of the auto brake means that if you come to a stop on a steep hill, it acts like a handbrake and the car can't roll down it.

To cut a long story short, I made some progress last night. I found the part of code that handles resistance based on surface type and I added additional resistance to it when the car is at a fraction above 0kph. For the longitudinal direction, this has made the problem vastly less noticeable. It doesn't fix the numerical drift but at least forces those numbers closer to zero. Now I just have to fix the code for lateral movement (which is a lot harder to understand) and then this major bug is pretty much sorted.

If anyone has any alternative suggestions I am all ears.