About that maybe-server-api

If you are referring to me, I raised the issue of the collisions as the side topic was about a safety rating, and considering that collisions are at the very core of what a safety rating is about, I felt it was worth raising, perhaps it wasn't.

My apologies if it caused offense.

Thanks,

Ben.

 

That would be a really really bad design decision... Hasn't the go language be designed with parallelity in thought?!? In such a language, why would one create such an obvious limitation?

 

For me I think is both @Minolin. Basically the server plugin part would be some generated json/xml data feed that could be streamed or send as a file to a remote server from where can be retrieved. This data can be used in different forms, so there would be an app that exploits it, totally independent of the server plugin.

As all mentioned the server plugin can be used to register user stats which can be used later to generate any kind of driving ratings. This would open the door to a vastly iRacing kind of leagues or communities, with its own unique rules of ratings and sanctions.

 

I may be able to help with that

 

Might be better the other way around: detect a deliberate disconnect with light or no damage, and deduct a bit. Could even do that on a lap completion rate, where quitting early is penalized more.

 

That seems quite negative though and I can see people being upset if they get accidentally disconnected for some reason. I personally think that a more positive approach to a safety rating is better, reward good driving, clean fast laps and finishing races but don't penalise people who get cut off from the server, or who spin out etc.

I still worry about detection methods. In previous games I've been rear ended by an opponent and I've been the one who got penalised. Or what if you get rear ended, then in return you rear end the car in front, who gets the penalty?

I do like the idea of a rating system, but I worry about its implementation.

 

Good luck even trying to come up with a penalty system that can determine who is at fault; half the time human stewards can't do that.

 

I must have missed the bit about there only being one plugin at a time.

Just emphasizes that there should be minimal requirements from the AC server plugin side of things to get the system running - probably just have it send the AC log over at the end of each race, and get driver ratings over plain http request containing the driver's steam id (with optional parameters to get car/server specific info).

 

Is Nim Cross still doing that over at iRacing?

 

Without an common agreement that apply for all, such an Rating system would not make much sense.
Are the parameters for iRating (or other) accepted in common by all the Drivers, leagues and other servers?

If yes, then it could be adapted, because it has proceeded the acceptance test already.

If not, then I have some doubts if its possible to make a rating system that all single parties will accept. Well the leagues or server admins could just enforce it, but I can see the heavy and endure sh!tstorm already out there by the drivers that are not happy with it. As it always is when such systems are coming into play.

 

Well, you will never have everyone happy and trying to is a recipe for disaster. An interesting approach would be to have a rating system that can be parametrized, based on the different events the system can register. Like how 2 wheels or 4 wheels off track are considered. How a light or medium contact (if that can be differentiated) should be handled, how many "safety rate points" you get if you complete the whole race with no incidents, on same lap, etc. etc.

 

Which is why I said deliberate disconnect.

The point of impact and speed from all cars involved and track location should be able to give some idea with collisions, though you will likely have to have a category of "indetermined" or "race incident" for anything where you can't decide who might be at fault.

 

I think a portable interface (between multiple languages) would be a better approach. Still I hope that KS will allow multiple plugins.

 

Just my two penneth on 'who's at fault' coding. If you don't apply incidents to both parties equally you open up a whole can of worms for exploits.

Unfair and unsafe manouvers such as brake checking and swerving by a lead car with no consequence? No thanks!

 

Maybe it would be possible to create a "redirector" plugin which doesn't change the UDP semantics at all, so for plugins it would be the same connecting to AC server or connecting to the redirector. Without knowing the API it is difficult to see if this would be possible or not. I would like this much more than a .NET approach (linux might be an issue for that as well).

 

Yeah I was thinking that the plugins could just behave like a proxy - the first one gets the 'real' ports, the next one just gets the ports of the proxy but the interface is identical both ways (although if the plugin wants to do something, it'll change that state on the way back to the server)