Let's talk about broadcasting (programmer's thread)

Hello, I'm working on something to create a report after a session and therefore I'm recording the udp byte stream to disk to analyze it afterwards. For the moment I'm looking at the broadcasting messages and I have a question about the Accident type, as the message property I receive "#vs. #-1472538688". Can anyone elaborate on this? What does this # -1472538688 mean?

 

is it possible to stay in one camera? to focus on the cars arriving at the end of the race for instance? Or staying on the camera at variante 1 in monza starts?

 

Hi Minolin,
I'm just trying to get my head around the broadcasting interface for and have a couple of questions:-

• I guess the client connection is only valid for a particular race (no new messages get sent once you change races). I can't see any way to detect that the session is finished so I can automatically try to open a new connection for the next session. I guess I could do this with shared memory, but I also want to see if I could run my app from another PC and automatically monitor new sessions. Is there a way of doing this?
• Is there a way of differentiating between the 2018/2019 tracks? As far as I can see the TrackName and TrackId do not differentiate. This looks to be the same for the results files and shared memory, and I can only see the server results files differentiating

Thanks,
Doug

 

You can use Free cam with F7. Then arrows to move the camera.

 

This problem is not fixed Tested in 1.3.7

- InboundBroadcastigEvent
broadcastType= 4(Accident)
broadcastMessage= #vs. #-1271002704
timeMs= 248916 (00:04:08.916)
carID= 1072

 

btw: How to get Player Realtime Position ?
Shared memory - SPageFileGraphic.position
UDP - RealtimeCarUpdate.Position (for Player car)

Booth are not in realtime

 

And another problem. Drivers swap ...
UDP - CarInfo.CurrentDriverIndex is not in realtime too ?

 

For anyone interested, I've been working on a springboot app that pretty much mimics the broadcasting client but with one addition: auto focus on cars. So that I can race and stream a "auto-directed" stream with another pc.
https://bitbucket.org/RobbyTimmermans/acc-director

 

will keep an eye on this @Robby Timmermans looks like great work..

 

How install?

 

Are there any issues with putting the Kunos code for this on our own GitHub repo and are there any copyright considerations to using the Test client code in our own clients we develop?

I assume not but just want to check before I do anything.

Or even better, can Kunos put the latest broadcasting code on their GitHub and we can fork it from there?

 

I have started creating a broadcasting SDK in Go (see https://github.com/toonknapen/accbroadcastingsdk, although I'm not sure there are many Go developers here ).

While testing, I found out that the splits are not available for the current lap. At every new lap they do become available for the last lap (and thus they are available). Is it possible that the splits will be exported for the current lap in one of the coming releases?

I'm asking because I'm connecting my race strategy tool to ACC. I have connected it already to timing systems at a number of different tracks (in the real world) and the timing systems at the track all provide the split-time immediately. So it would be great to also have this information available for races in ACC and as such allow real-time planning of the race-strategy.

 

In doing updates to my own version of Broadcasting client I noticed a few things that we need in the broadcasting API to make things better:

• Realtime (or near realtime) updates for position changes and gaps (not sure what the interval is at the moment in the client but I know it isn't realtime in the timing HUD in the game itself)
• Updating split times in realtime as they occur rather than at the end of each lap (as requested by Toon in the post above)
• Weather forecast information in the InboundMessageTypes : REALTIME_UPDATE section of the network protocol API.
• Track Condition information in the InboundMessageTypes : REALTIME_UPDATE section of the network protocol API.
• Positions Gained/Lost from starting position if it is a race, added to the InboundMessageTypes : REALTIME_CAR_UPDATE section of the network protocol API.
• Current Tyre Type added to the InboundMessageTypes : REALTIME_CAR_UPDATE section of the network protocol API.
• Tyre Laps (number of laps the current tyres have done) added to the InboundMessageTypes : REALTIME_CAR_UPDATE section of the network protocol API.
• A way for Incidents to be reliably detected and reported on by the client.

Kunos, can you please consider exposing these to the broadcasting network protocol in a future update. They are great pieces of information for broadcasters to have on hand while commentating to make more professional quality streams.

Thanks for your consideration.

 

To add to above we also need:

• Wind Details
• Pit Window Information
• Option to stay on a certain trackside camera

Thanks again. I hope this hasn't been abandoned as @Minolin hasn't posted here since November and no changes to code since last July? Maybe in 1.4?

 

FYI, A few issues I have noticed with the current code....

• carInfo.TeamName doesn't get populated (always blank).
• update.TimeOfDay doesn't get populated (always seems to be 00:00).
• Accidents get populated with a value like #vs. #-1271002704 as described by others above.
• In SessionInfoViewModel.cs line 45 "var remaining = update.SessionEndTime - update.SessionTime;" only needs to be "var remaining = update.SessionEndTime;" as SessionEndTime already contains the amount of time left in the session. I have fixed this in my code but Kunos may want to change it for others while they are making other changes.
• Sector 3 times are not populated correctly. S3 is always a duplicate of the S2 time.
• Drivers not removed from entry list when leaving a race resulting in duplicate positions listed.

Some of these I am trying to fix myself (or have), but others may be that the correct data isn't coming from the game. Has anyone else got past these issues?

Thanks.

 

The S3 issue is just an incorrect binding name for S3 in LiveTimingCarView.xaml. There are two textblocks with {Binding CurrentLap/LastLap/BestLap.Split2String} instead of {Binding CurrentLap/LastLap/BestLap.Split3String} for the last (S3) one.

 

would be great if you could put the corrections on github. Since the current SDK has no copyright notice, default copyright rules apply and thus the writer of the code should agree before doing that.

I'm writing a Go version of the SDK and also trying to include inline comments (which then can be extracted using 'godoc') describing how to interpret the different fields such that it might also serve even non-Go developers (https://github.com/toonknapen/accbroadcastingsdk/blob/master/network/buffer.go#L118)

Btw, I can capture the teamname, I guess that is an error in the C# SDK then as it is available in the UDP interface?

 

I'm happy to put the fixes up on GitHub. Just waiting for @Minolin or someone else at Kunos to approve.

Optimally I'd like them to put it up on the Kunos GitHub and then I will fork it from there and make the changes. Then we can all develop it together!

 

Another request for the Broadcast Network API....

• Can we please have an OutboundMessageType for clicking DRIVE on the target PC (so we don't have to do this in the ACC window each time)

Thanks.