App Offical release of Crew chief version 4 - auto updating and shiny

I've just uploaded 2.4 with the changes to support 'hot lap' mode, revised sounds for worsening (increasing) laptimes and cut track warnings, check the gap increasing / decreasing clip is still valid before playing it, along with some other fixes (list in the first post as always).

I've really not tested this enough (even less than usual...). I'll probably not get a chance to look at it properly till tomorrow but it's pretty low-risk stuff. As always, holler if it's busted

 

Gah, 2.4.0 has the wrong sound pack bundled with it. I'm uploading 2.4.1 now which has the correct sound pack. There are about 20 missing sound files in the 2.4.0_with_sound_pack zip file. Stupid error on my part

I also fixed a minor bug in the gap message validator (it wasn't checking if the race had finished before playing a gap message) and made sure it doesn't play "0.0" second gaps in hot lap mode (it'll just say "less than a tenth" if you're off the pace by less than 0.05 seconds). So we're now at 2.4.1. Sorry for balls up folks

 

Thanks for doing and maintaining this app, mr_belowski. I used and tested it in the past three days for its spotter feature, which is the one thing that got me here. It is a big step in the right direction, but while the callouts sometimes come, sometimes they come not. I checked the UI and saw the time entry slots for minimum and maximum speed of approaching cars, and played around with them, but I am not sure I really understood correctly what they do and how it affects the ingame action of the virtual spotter. Could you elaborate a bit on what to do there to get the spotter calling out more reliably, like in iR and Nascar2003? Currently, some cars sometimes slip by or stay beside, without being called out. What values would you recommend to be used for making the spotting more reliable, mentioning every car entering the detection zone?

As a "want-have" for the future", I would wish, if I may, for some more diversity in calls. Just a suggestion.

 

The spotter is unreliable I'm afraid. I've worked hard to make it as solid as I can get it, but unfortunately the data in the shared memory block require lots of checks and work-arounds to make the spotter work at all. It's always going to be a bit flaky with the current data which can be quite noisy. There's no "detection zone", all I have are the player's car speed and the time gap in front and behind.

The parameters can be tuned to make it a little better, but don't expect all the calls to be correct.

I suggest using a smaller value for "update_interval" - maybe 50 or so. I use 100 for the spotter_overlap_delay and spotter_clear_delay parameters. The spotter_car_length parameter is used to work out whether the player's speed & time delta would result in an overlap. I've chosen 3.6 metres here but this is a guess - it works better for some classes than others. The spotter_gap_for_clear parameter adds a small amount to the car length before the spotter can call clear (i.e. we use a smaller car length for 'overlaps' and a longer car length for 'clear' - this makes it less likely to call 'clear' when you're still overlapping).

There might be some combination of settings that give more reliable results, but at the moment it's never going to work 100%.

When you ask for more diversity, is that in general or in the spotter calls specifically? If it's for the spotter calls, what did you have in mind?

 

The car speed params are to stop annoying spotter calls for when you pass a stationary car (very high closing speed) and if your own speed is slow, the spotter accuracy is very poor, hence the min speed for spotter variable. Both these speeds are in metres per second

 

Thanks for the replies! Regarding "diversity", I just meant to have some more speech files, stuff like that. But I think priority is on different things, so ignore it.

 

I don't know (and can't know) which side the car is on - the information isn't there. I've had another rummage through the raw data RaceRoom gives me, and it looks like the TimeDelta values (which I use to calculate if the cars are overlapping) are getting (briefly) set to 0 or -1 when an opponent car crosses the start line (and maybe the sector lines). This confuses the spotter (obviously) so I've added an additional check for this - might improve things a bit.

I've also added more 'hold' and 'clear' messages, but as I don't know what side the car is on there aren't many alternative ways to say "hold your line"

I've been testing 2.5 tonight with the spotter changes and have found a couple of other issues (including a nasty crash bug). I've also added tyre wear monitoring making the number of individual voice files somewhere around 830 (!). I'll release this tomorrow

 

I just made a MP race with the DTM 2013.
A really messy race, much lag and probably a handful of wreckers.. .

Got caught up in the turn one mayhem..
I was also able, not to avoiding other crashed cars skidding along the track over the race.. .
So I'm not sure if "you got some bodywork damage" was spamming, or if I sustained a bit of damage here and there.

But 4 minutes before the race was over I thought I do some gearbox testing, so I stopped using the clutch on the downshifts for half a lap.
And that one is for sure spamming.
The transmision light came on and I got the "be careful with those downshifts".
I started to use the clutch again, but those downshift messages along with bodywork damage kept coming every 20 seconds or so, and sometimes when downshifting..

Would it be possible to have the crew chief take a break with those calls unless there is new / more damage done?
I know I didn't hurt the gearbox more after the first message, and I never got any real noticing gearbox damage.

 

Very weird, its supposed to only play each message once per session (unless you ask it 'how's my engine' or whatever).

Don't suppose you still have the log messages?

Can't see what would cause this - anyone else noticed the damage reports keep being repeated?

 

Looking through the code, I'm struggling to understand why the damage event would ever spam messages. I suspect this might be a symptom of some issues in the queue handling, which I'd already started looking at. This will take a little time.

In the mean time I'm going to release 2.5 with the known bugs fixed and the additions. I've also move the damage monitor code around a bit so if I'm right about the cause, the underlying issue won't make it spam messages.

If anyone sees any weird behaviour like this, a copy of the console log would be helpful.

I'll do this later on today and restructure the queue code a bit over the weekend

 

Just uploaded 2.5.0, Heppsan, if you see the damage messages spamming again can you post the console output? Ta

 

Don't think I will have time testing it this weekend.
But let you know when I have.

 

Big thanks for an excellent app!

 

Very very much thanks for this great feature. Just tested it and works brilliant. Perhaps Sector3 can include this in their next realeases?

 

We be testing this sometime over this weekend. Thanks for the constant updates.

 

I've finished sorting out the queue code and some annoyances with the spotter, and I also found a bug in the damage monitor (ta for the heads up heppsan) which caused it to play multiple damage messages when it shouldn't (there was indeed a code bug, I missed it first time round).

I need to test these changes a bit more, then I'll release a new version - probably tonight or tomorrow.

In the mean time, all bug reports and suggestions are welcome

 

Righty, 2.5.1 is up with these tweaks to the queuing. Basically the old code was holding a lock on the message queue while its contents were being played. This meant that other events had to wait till the queue had been played before adding their messages. So if you cross the line and the app queues 3 or 4 messages that could take 10 seconds to play - during that time if, say, you went out side of track limits the track limit warning wouldn't be added to the queue until those 10 second were up.

Not a massive issue because the queue is played in order anyway, but having the event triggers blocking for potentially long periods would cause some issues.

The interrupt handling is smarter too now. When a long stack of queued messages is interrupted for, say, a spotter call, the app handles this better with less delay and no more of the weird beeps for channel opening and closing when it really shouldn't.

The upshot of all this is that it should sound a bit more natural and just generally work better.

The spotter code had to be tweaked a bit too - it's no more accurate in its detection (the R3E data is noisy sometimes), but it's a bit more robust in its handling of the radio channel open / closing events.

The damage code bug was all down to my assumption that the damage happens instantly in a single event. But actually if you ruin your engine, this is something that happens over, say, half a second or so. During that time my app would queue the "minor engine damage" event, then shortly after it'd queue the "severe engine damage" event, then it would play the "knackered engine" event. A few seconds later those minor and severe damage events would play, even though they're no longer valid. This is now fixed

 

Reporting:

At the end of the race I get: "you won, fantastic job",
and then: "your left front is showing some tyre wear, you should keep an eye on them".

Cheers.

 

I had this one too last night

 

Will have a look