[WIP] Race Engineer (Spotter) plugin for rFactor 2

cosimo

cosimo

Registered
Hi everyone,

I have started working on a "race engineer" AKA spotter plugin for rFactor 2.
The goal for this project is (for me) to just have fun and do try some C++ programming while staying in a field I like (simracing).

I have looked at the rFactor 1 spotter plugin and it's a massive amount of work, probably far too much for me, compared to the little time I have to dedicate to this.

I do want to try anyway to have at least a subset of those functions, probably only configurable with a text file somewhere. So, a really minimal start and then we'll see where this goes, no promises :)

I started tonight to prepare the compiler environment, get the example plugin from ISI, documentation and study the rf1 spotter, for which unfortunately no code is available. I am now at a basic proof of concept stage:
  • I've got the plugin code to compile and run correctly in build 494
  • I added a simple alert on average brake temperature > 600°C
  • I verified from the log files that this condition is correctly triggered

Next up on my list are:
  • Including the fmod library in the project
  • Get to play a sample wav/ogg/mp3 file whenever the brake temp goes over 600°C
  • Try to not crash or slow down rF2 when playing external samples, basically use the fmod async APIs

An important thing I will need to figure out is how to have the "RaceEngineer" react differently to different cars or tracks. For example, 600°C is just an arbitrary number. Ideally this number should change according to the car. An F1 car is different from a Clio when it comes to brake temp threshold. How do I know that? Can I query the rF2 engine for the current active car or a sensible brake threshold for the current car?
 
The ISI rF2 spotter still doesn't work, so your project will be fixing what ISI refuses to. Good luck, I hope you figure it out!
 
cosimo said:
I started working on a "race engineer" AKA spotter plugin for rFactor 2.
The goal for this project is (for me) to just have fun and do try some C++ programming while staying in a field I like (simracing).
...
Next up on my list are:
  • Including the fmod library in the project
  • Get to play a sample wav/ogg/mp3 file whenever the brake temp goes over 600°C
  • Try to not crash or slow down rF2 when playing external samples, basically use the fmod async APIs
Click to expand...

These are now done! I integrated fmod, and I got to a first proof of concept version of the plugin.
I'm uploading a video to YouTube right now. Not much really, just a voice that says "Your brakes are too hot, go easy, cool them down" :-)
There is a very basic debouncing now, so the guy won't continue repeating the same thing over and over. Will just do that once every x (30?) seconds at most.

Here you go:



cosimo said:
An important thing I will need to figure out is how to have the "RaceEngineer" react differently to different cars or tracks. For example, 600°C is just an arbitrary number. Ideally this number should change according to the car. An F1 car is different from a Clio when it comes to brake temp threshold. How do I know that? Can I query the rF2 engine for the current active car or a sensible brake threshold for the current car?
Click to expand...

If anyone has any idea here...

Next step: collect a list of checks/alerts I want to implement.
 
PRL MerlinC said:
Have you been able to run the debugger as well? I always get an error message when RFactor starts and my debugger is running.
Click to expand...

Not sure as I haven't used the debugger yet.

PRL MerlinC said:
P.S.: Did you think about sharing the workload by distributing the source code and tasks to a software communitiy like sourceforge?
Click to expand...

Yes, I plan to publish it on my Github account. There's such a massive shortage of open source in this field :-)
Right now the code is a bit embarrassing, but we'll see.
 
congrats to the first implementation of ``brake temps announcement`` !! thats cool

the spotter for rf1 has a list of mp3 files in /gamedata/sounds/pits which can be used as a reference. there are 6 to 8 files for each situation very little different speakings. they can be used randomly.

for overheating there are 2 or 3 zones which can provoke different reactions. I think repetition may be done on lap basis (exception Nordschleife may be ... )
 
Today I added a radio DSP effect so that the spotter sounds more like a real radio. Kind of cool playing with the fmod library.
Now I'm trying to add some static noise effect too :)
Would be cool to get the source code for the rf1 spotter though... I guess it would be a lot less work to do from scratch.
 
Slow progress, but progress nevertheless :)

In case someone wants to help, here is what you can do.

First of all. How important is for you to talk to this plugin? Would it be still useful if it just reacted to condition of the road, or race, or tires, brakes, etc?
I don't really want to get into the speech recognition mess from within rF2. GauchoRS wrote a GlovePIE script to take care of that. Probably that's a viable solution.

So, how can you help.

As you know, the first thing I did was to implement a check for brakes temperature. If the brakes are too hot, the plugin tells you now already (see video above).
One problem with that is that I had to program a fixed threshold. For example, when the average brakes temp goes over 1000°F.
So this 1000°F will be the same if you drive an F1 car or a Clio. This is not right.

I figured a way to know from inside the plugin which car is being used, and now I also know that peeking into the car .MAS files, it's possible to extract the HDV and TBC files to get data about brakes and tires optimal temperature for example.
I would like to get to the point where the brakes/tires parameters are loaded dynamically depending on the active car.
To do that, I would ship the plugin with an INI file or some configuration file like this:

// Clio_PC.ini
[Brakes]
OptimalTempRange = (350, 680)
OverheatTemp = 1000

[Tires]
OptimalTempRange = (85, 100)

// FISIR_2012.ini
...

Another problem is that this data is not always accessible, because some MAS files are not accessible (f.ex., MR01_car)
Anyway, this spotter plugin is a huge task :-)

Another thing you could help me with would be to choose the next "thing" the spotter should do, after the brakes check.
I thought I would do something like checking if it starts to rain or track is wet, or maybe announce the race position at the end of a lap.
I'd like to go with simple things.

What would you like to see?

Then of course you would get to test the plugin :-)
I plan on packing up a first alpha version as soon as it's somewhat useful.

Thanks for reading!
 
Is it possible to record every recording 5 or 10 different times? And then have the spotter plugin randomly choose which audio file to use? This way he can say the same thing but in a slightly different tone (just like how in real life you would never sound EXACTLY the same if you were asked to repeat something) and for some you can even change the wording a bit.
 
Spinelli said:
Is it possible to record every recording 5 or 10 different times? And then have the spotter plugin randomly choose which audio file to use? This way he can say the same thing but in a slightly different tone (just like how in real life you would never sound EXACTLY the same if you were asked to repeat something) and for some you can even change the wording a bit.
Click to expand...

Yes, that is definitely possible and already supported by the ISI built-in spotter and by the RF1 custom 3rd party spotter.
However, that is not a priority for me at this point, so initially I plan to limit myself to the messages that either of the two (RF1 and RF2 ISI spotter) implemented.

That is actually not a very bad situation.
The other day I managed to unpack the RF2 Commentary MAS file, and I found all the spotter sounds ISI have recorded and there are 112 (!), so you won't have different sounds for each situation (f.ex. brakes overheating) but still you have plenty of possible messages coming at you.

OTOH, the Rf1 custom spotter instead has lots of alternative messages recorded for each single situation, and those could also be used.
We'll see... :-)
 
cosimo said:
Yes, that is definitely possible and already supported by the ISI built-in spotter and by the RF1 custom 3rd party spotter.
However, that is not a priority for me at this point, so initially I plan to limit myself to the messages that either of the two (RF1 and RF2 ISI spotter) implemented.

That is actually not a very bad situation.
The other day I managed to unpack the RF2 Commentary MAS file, and I found all the spotter sounds ISI have recorded and there are 112 (!), so you won't have different sounds for each situation (f.ex. brakes overheating) but still you have plenty of possible messages coming at you.

OTOH, the Rf1 custom spotter instead has lots of alternative messages recorded for each single situation, and those could also be used.
We'll see... :-)
Click to expand...

Awesome!
 
I have looked in detail at how the internal ISI spotter works, studying the Commentary MAS file and the accompanying INI file.
What ISI has done there is very promising!

I have no idea why the built-in spotter at this point doesn't say much (just lap time for me, but there's some surprises there, I'll post soon about it).
The potential to build a kick-ass spotter is all there!

Now that I sort of finished working on the Delta Best plugin, I'll start experimenting by poking the commentary system and see what I get out of it.
 
yes, there are many comments in the file of the ISI spotter, but the voice is terrific (like r2d2 robot) and way to low in volume.
 
I managed to interface with the ISI built-in spotter from my plugin!

This is the very first proof of concept, but it means I can remove all custom sound code and (maybe) most sound files because I can leverage the built-in commentary files.
That's really cool.
 
You must log in or register to reply here.
Back
Top