Calculate suspension velocity for ac

[wasabinator]

It appears that AC doesn't provide suspension velocity data, so this is a small change to the ac mapper to derive it from the suspension values vs time.

The reason why I went to add this is I found that in AC I couldn't get a good effect to give me a decent impact effect hitting ripple strips. In the cars I tested with, the suspension travel wasn't much different driving on the road vs driving off the track so the suspension's velocity is a good way to catch that.

Corresponding changes that plumb through the suspension velocity will be raised in the monocoque repo.

[Spacefreak18]

I like it.

Is there a way you can leverage simdata->mtick for this ( or create simdata->ntick in a similar manner if needed ).

And if you think it's better than the existing suspension effect, I'm not against replacing the existing effect entirely and just using this for all sims that support it.

And then for your float prev_suspension[4] and struct timespec prev_time you can add them to the base simmap.h struct instead of putting them inside of the acmap struct.

[Spacefreak18]

only other thing I would say is move the calculation inside of acmapper.c to it's own function so we can easily either copy it to the other mappers or move it somewhere universal for all sims ( that need it ). It seems pcars2 (Automobilista2) and RBR provide a suspension velocity calculation althought it is not obvious what the units Automobilista2 is using (m/s maybe).

[wasabinator]

Thanks for the feedback, I will use mtick instead of storing a new time. I actually totally missed that was even there. I'd need to add a prev_mtick or something along those lines to hold that value in simdata, so the code in simapi_datamap(...) would then become.

    simdata->prev_mtick = simdata->mtick;
    simdata->mtick = timeInMilliseconds();

Actually, regarding prev_suspension, I might be able to avoid it if it could be assumed that the existing simdata is used (as the prev value) and then the current game simdata can then be used in the calculations, prior to the mapper then updating the current suspension values in simdata from the game state, if that makes sense. Less data to manage, but also requires care in terms of the order in which it is calculated. Also, I am assuming that data does not get reset in the instance of simdata passed around, which I believe is the case, but again please correct me if I am wrong.

I could indeed then hoist out the actual calculations to a map_suspension_velocity(...) function as it's largely game agnostic. Then on a case by case basis the mappers that don't already get suspension velocity natively. Of course on a case by case bases we could probably add some normalisation to get them all talking the same units, so there could be some form of mapping still required to align them.

As for making this the default used for suspension haptics, I'm a little hesitant to go there, as I am not sure out in the wild who is currently relying on suspension as it is now, so felt it was probably to add it as an additional effect in the absence of that knowledge.

Anyway, just thought I would hash this out before changing, let me know what you think about any of the above and I can rework it.

[Spacefreak18]

Thanks for the feedback, I will use mtick instead of storing a new time. I actually totally missed that was even there. I'd need to add a prev_mtick or something along those lines to hold that value in simdata, so the code in simapi_datamap(...) would then become.

    simdata->prev_mtick = simdata->mtick;
    simdata->mtick = timeInMilliseconds();

Actually, regarding prev_suspension, I might be able to avoid it if it could be assumed that the existing simdata is used (as the prev value) and then the current game simdata can then be used in the calculations, prior to the mapper then updating the current suspension values in simdata from the game state, if that makes sense. Less data to manage, but also requires care in terms of the order in which it is calculated. Also, I am assuming that data does not get reset in the instance of simdata passed around, which I believe is the case, but again please correct me if I am wrong.

yep, I may initialize things in simdata before the game specific mapper, but you are correct, in practice, nothing outside of simapi_datamap should be modifyin the simdata struct that gets passed around.

I could indeed then hoist out the actual calculations to a map_suspension_velocity(...) function as it's largely game agnostic. Then on a case by case basis the mappers that don't already get suspension velocity natively. Of course on a case by case bases we could probably add some normalisation to get them all talking the same units, so there could be some form of mapping still required to align them.

yep, i like that idea, what exactly those normalised units are, idk. I can't tell what AMS2 is doing behind the scenes. I may look at the Crewchief code for clues. But if you want to run with something like m/s, I'm fine with that

As for making this the default used for suspension haptics, I'm a little hesitant to go there, as I am not sure out in the wild who is currently relying on suspension as it is now, so felt it was probably to add it as an additional effect in the absence of that knowledge.

I originally threw together the suspension stuff as part of this ticket and I haven't heard back. I don't really think anyone else is using it, and I don't use it ( you don't want to run too many effects through the same speakers at once ) so if you're using it and like it, I imagine it's better than what I got already.

Anyway, just thought I would hash this out before changing, let me know what you think about any of the above and I can rework it.

[wasabinator]

Sorry for the delay, I got carried away testing my hotlap times in AC instead of the suspension changes!

I've updated the code as discussed, so it can be used elsewhere as needed. Let me know if you spot any issues with it.