How to collect track Corner Data

[The Iron Wolf]

This is indeed a good idea. This issue is number one on known issues list for rF2: http://thecrewchief.org/showthread.p...Issues-Backlog

rF2 spotter was able to announce engage pit limiter message, so it should be possible to do using existing model, and sooner or later we'll get to it

[Scoops]

OK so I'll collate the data to keep in hand for the point at which the pit request become visible. If it doesn't then there is nothing lost.

[mr_belowski]

Thanks Scoops

[Scoops]

OK humour me. Why can't we map the same button to call a pit stop to an action in CC? Then hitting the button is listened for by both? To my simple understanding that would remove the need for the sim to provide the information.

[mr_belowski]

i did toy with the idea and might yet implement it but I need to be really careful about what behaviours it triggers and when. If the app holds an internal state 'pitstopHasBeenRequested' and this is toggled on / off each time the pit button is pressed, it's possible for the app's value to get out of sync with the game (a button press isn't processed for some reason), which could be a serious problem.

For a simple thing like "press button X and then the app will warn about pit limiter when approaching the pits on this lap" it could work - the game's internal state would get automatically reset at the start of the next lap.

I'll have a think about it

[Scoops]

I did think about the possible sync issue between game and CC. My only thought to deal with it is to have CC ask 'Do you want to pit or not' if you run passed the pit at speed. But that would need a confirmation button press or a verbal communication. And still a chance for them to remain out of sync.

Anyway I'll get back to the corners. I'll pm the next lot this weekend and add all the pit figures.

[Scoops]

I'm starting to come across more tracks that display the same name in game for different layouts at the same location. So far Paul Ricard, Daytona and Dijon Prenois. Daytona is already mapped as the trioval so will report as such when users are on the road course.
The only solution I can possibly think of is if CC can identify the length of the track to confirm which layout is loaded? Or ask the original author to repackage the tracks with names changed?

It would be a shame to miss out on certain tracks or have CC call incorrect messages.

[The Iron Wolf]

Hi Scoops,
Currently, there's no field in shared memory plugin to expose data allowing to distinguish between such tracks. I am working on a V2 of a plugin, and there's some information that looks promising (char mTrackType[ 32 ]; // track type from GDB). However, I will be busy for the next several months, so won't get to it anytime soon, but will eventually check this field, hopefully that'd be it.

There are ways to fix this, even if data is not available. You are right, cheapest way would be to use mLapDist to use as a secondary value to distinguish between tracks. But I personally would be against doing any of this for a subset of tracks that are poorly authored in my opinion.

Basically, we'll have to live with this for a bit.

[Scoops]

OK no problems. I'll keep a list of circuits where this happens and keep them out for the time being.

[The Iron Wolf]

OK no problems. I'll keep a list of circuits where this happens and keep them out for the time being.

Did a quick check mTrackType - that's not it, and will not be able to use it universally. Best bet for such tracks is to re-author them so that they use different name for each course. This is what majority of tracks does, and they should follow the majority approach.