MULTIPLAYER Broadcasting & Company

U cant... afaik its not possible to change content of the games on consoles

 

Is there something new about broadcasting? Events organisators have a big problems to broadcast without eny information from game. Replay tool, etc...

 

Nobody cares about us... But you can write your own application if you want, as its absolutely normal, that all players/admins are programmers too..

 

@Minolin
Can you shed some light on how you calculate the live gaps and the sector gaps, ingame?

I see that in the testclient that you provided you base it on the distance between cars on track(which I assume you get from a combination of splinePosition and track length), and their current speed. But this seems very unreliable and changes A LOT.

Cheers

 

Whilst he doesn't answer you, what would you describe as an unreliable result value you're getting?

Cause I believe, even IRL those live gaps are results of a math between position on track (from GPS, in real life) and the current speed of chasing car. The only trick you have to do is when the front car had already crossed the line and the on behind hasn't, but isn't that complicated. On normal circumstances tho, is pretty straightforward. If Monza spline's has 5793 meters and you have car A at splinePosition 0.5 and car B at 0.3 and running at 200 Km/h at that moment it would be:

Code:

Gap = [ (TrackLengh * SplinePositionA) - (TrackLengh * SplinePositionB) ] / (CarSpeedB * 3.6)
Gap = 1.6s

That should be reliable, since it will be updated every socket interval.

Sector/Lap gaps are "easier" tho. At least in real life they were/are done via RFID transponders on fixed positions throughout the track. Then is just a matter of CarA tooked 30sec to travel the Sector 1, and CarB took 29,5sec. Simple subtraction.

 

@Fabio Pittol I don't think you can use a car speed for the gap. Just imagine someone going 270kmh on the straight of Monza and another car a little bit in front already at braking point for T1, at the moment at 270kmh also...
Now the car in front brakes hard, going down to 70kmh, the other one still at 270kmh... You gap calculation would vary an huge amount, even if they take T1 in equal time.

I think the only reliable way of calculating the gap is taking the position of the car behind and then look how long ago was it when the car in front was at that longitudinal point on the track, lateral difference maybe could be taken into account (ideal line) but even if not this should be way more accurate than the other calculation.
I'm happy if you prove me wrong or have another idea.

 

But, at least from my perspective and I'm just throwing ideas here as well, not claiming anything, the calculation at the end works similarly with what you're suggesting. At every 250ms (UpdateInterval) you are defining a target point in space (where the Car A was) and how much time at the speed you're traveling you would take to get there. So, by using the SplinePosition we are already setting a "longitudinal point on the track". As all these values will be updated every 250ms, the speeds and distances will also vary, giving an "usual" gap difference. The elasticity of the gap due to speed difference already happens, even in real life, or on any racing game HUD. You're gap will deceivingly drop whilst your opponent takes the 1st chicane at Monza and you're on the straight. But it will "even out" when you get there and it's your turn to go slower.

At least this is how I see it working. Be it for real racing or in any racing game, including ACC. Is should be "precise enough". But it all depends of what you guys are expecting of precision. For instance, you can see that the Lap Delta information for your car is never 100% precise, cause, as you mentioned, there's also lateral distance taking away from it.

 

Well this is exactly why I'm asking how they do it ingame, cause it is *WAY* more reliable than a simple "position on track combined speed"-calculation.

My original post:
"I see that in the testclient that you provided you base it on the distance between cars on track(which I assume you get from a combination of splinePosition and track length), and their current speed. But this seems very unreliable and changes A LOT."

The way I was thinking was using a rolling avg. laptime and use that instead of speed, basically.

That rolling avg. will obviously need to do number of things. Like keeping the last 5 laps stored, and exclude any lap that exceeds something like 110% threshold of the quickest lap within that list of those 5 laps, to keep the avg. lap time somewhat in line with reality.

 

In general I just have sooooo many questions about how the game actually works with the broadcasting API, because the test-client really does not do a good job of explaining what the game does internally, and what data to expect both receiving and having to send back.

I've had to fix several issues that logged errors in ACC logs, that the test-client does NOT handle well.

 

And exactly this is what I don't like about this calculation.
The displayed gap is shortening a lot in brake zones and enlarging in acceleration zones, this is not reality.
Let's say Car A is in front and B is behind 1s.
When A brakes down to 70kmh for T1 and Car B still at 270kmh,the displayed gap will reduce to maybe 0.3s when in reality the distance gap has decreased but not the time gap. Car B is now entering the brake zone and will brake as well, causing the time gap to remain stable.

That's why I suggested to look at the time Car A was at same point on track as Car B is now and display the difference in time as gap.
If car B is faster then that gap will decrease, but it will not decrease only because the first car is entering a brake zone.

 

Yeah, you have a point there, Andy. It makes sense.

I guess it comes down on how much precision and calculations you wanna do. With your idea, we would be splitting the track into micro sectors (which IIRC ACC already does internally). That's easy, you can just use the SplinePosition to check the car's current laptime at each segment you want (every 0.1 of the full 1.0, to simplify). But you'll have to do a bit more, and log that information for every single car. Since I'm not that experiencing with coding, I dunno how process demanding it can end up being depending on the usage, but it might work fine. One caveat that comes to mind tho, is that, if the car is traveling at great -variable - speed and you're only receiving its data via a fixed rate, you won't always be able to get the value of the exact same SplinePosition.

 

I completely understand what you mean. I'm not a programmer (I'm a designer) so my knowledge on that area is very limited. Application programming, be it C#, C++ etc. is very confusing for me. Thankfully very early in this thread (or the Programmer's one), somebody posted a draft conversion to NodeJS. Since I get Javascript much better, I was able at least to have it getting and sending data that way. And it helped me understand a little better what's going on.

Since the devs seemed busy with other stuff for a while now, judging from their last interactions around here, if you want, you can post some of your questions here (or DM me), I'd be happy to help IF I can.

EDIT: Just noticed I missed one of your posts.
Yeah, what you and Andy are saying makes sense. I might be a thing that was simplified on the TestClient for, well, Test reasons. It might be simplified cause after all, most broadcasting, even real life ones, don't get high refresh rate. But yeah, I recall one of the devs explaining to me almost a year ago how the game handles track cuts and penalties, and it was something about slicing the track into micro sectors and measure the timing between them. It might be the way to go for you and Andy. Little bit more coding involved tho.

 

The coding is not really the issue - I could defenitely implement micro-sectors based on the spline-position.
I'll be getting updates from the game every 250ms anyway, so should not be an issue...

This is defenitely an option, but have to test it with a full grid of 50-60 cars, tracking like 10-20 microsectors for each car. But honestly in the grand scheme of things, it's not *that* much data.

 

Would you happen to be working on a broadcasting client that will be publicly available? I haven't been able to find a single one that is actually still actively being developed. Thanks in advance!

 

Not a broadcasting client.

I'm working on a livetiming application. However for now this is something I'm developing for private/team use. *MAYBE* at some point down the line will I make the code public. The way I've build it requires you to host a webserver + site, atleast locally, for it to send data to. It's not a turn-key solution like the one The Sim Grid is offering.

 

Hi all, has anyone an idea how to get the Team Name out of the broadcasting API? I am only getting an empty string out of the teamname item. Is this a Bug or does any one has it running to read out the Team Name?