Looks great!

Closing speed could be more efficient use when its unit would be more precise.
With meter/second, we wont know more than :

closing = 1 for >0 - 1.49 m/s (how will it report closing speed if under 0.5m/s ? null ? idk)
closing = 2 for 1.5 - 2.49 m/s
closing = 3 for 2.5 - 3.49 m/s

etc... till 255 m/s, but do i rly need to know car X rammed Y at 255m/s ?

To me a "fast/slow" boolean would be as efficient.
As i consider anything above 2.5 m/s a too hard contact, and as i can have more clues about the intent of faulty car with throttle/brake info, i believe it would open more possibilities of using the closing speed value if it was labelled in a more precise unit like decimeters or centimeters /second, even if it has to be clipped for higher speeds.

At the moment, if less than 0.5 m/s closing speed, the packet is not sent.

I think high closing speeds are important to know if you think about what wreckers do. But I agree : 255 is not needed.

How about if it would be "closing speed times 2" so values of that byte from 1 to 250 would indicate closing speeds from 0.5 to 125 m/s?

Online testing with Victor we thought that speeds below 2 m/s would probably be ignored, because they were such light touches.

EDIT : One reason for having it a bit coarse was that it naturally provided a cut off point (0.5 m/s) so cars that were just rubbing a bit down the straight wouldn't send several collision packets. To get more accuracy we could possibly use another byte... but I still think a cutoff point is needed because of the possible bandwidth problem, maybe the same old 0.5 m/s....?

Best tested on KY1 I think, with bump drafting.

0.5 m/s sounds low enough to consider it a racing incident if something bad is going to be the result of the contact between the cars.

Most crashes on the licensed environment occur due to not having enough respect for each others speed and braking points. The trigger currently lies on the creation of a yellow flag but often the wrong car gets penalized as well pretty badly. Due to having a not so big active racer pool, multiclass systems are there which doesn't necessarily have to be negative but speed differences and braking points even become a bigger issue. (Some think that having single class will fix a lot of problems automatically, but I do not agree on that, looking at demo XFG/XRG races for example).

Crashes also often occur because of total disrespect of the yellow flag but that is sadly a completely different problem.

---
Wreckers are more a typical demo thing, a classic will be the; 'reverse on track, drive wrong way below 10 m/s (~ ?) to avoid being spectated and take out leader. Such behavior will be easy to detect with this system but the current ongoing race will still be ruined.

Biggest problem on the demo environment is the voteban system which is nice but too basic, not the wreckers. Demo racers are quite good in having an early detection of potential wreckers but vote banning someone off the server on time seems to be difficult. Or worse, a little group starts vote banning of people just to hijack the server. But EQ Worry can comment more about that, running six successful demo servers.

.

Quote from Scawen :

I don't really want to do that, in case CCI bits are added to CompCar some time in the future.

But to understand why it is important, I'd like to know how someone would use clutch and handbrake information in a collision analysis.

I guess they could be put into one byte, if the lateral and longitudinal accelerations were also put into a single byte, though that would be a bit of a squeeze.

Or of course I could extend those structures by 4 bytes each, leaving a bit of space for the future. Maybe that is the best idea, just in case...

I think that one big point of recive packets with trottle, brake, clutch, handbrake, steerring,... is that a programmer can do easy a online telemetry program for monitorize a team partner with telemetry like in F1, GT,...
I'm trying to do one and i haven't a lot of info from the packets, maybe looking on the memory of my computer i can extract more data, but i don't know how to "memory hack" or use memory adresses in C# code

For me the new packet and structure looks great, but I really cannot say now if they prove to be usable for reliable crasher detection. Unfortunately, lags are always influencing many things. I guess we all know situations when you brake on time, but the car in front of you is obviously pushed and slides away though you never touched it. But you lagged a bit, the server saw you braking 0.5 s later than you really did, and processed the inexistent collision. Now it will send a collision packet with lots of precise data, that are not so precise in fact. And cascading effect is also possible, cars hitting each other as a result of the first small lag.

So, I think it is great to have the car collision packet with some data available. But only practice (months of testing/development) will show what data are actually usable and reliable for whatever crash-detection routines someone develops. Having some spare bytes both in the collision packet and the car structure looks like very good idea to me. Also, I consider the impact speed resolution of 1 m/s as sufficient. Car speed is updated only 2 or 3 times per second on server, so again, it will never be precise and highly reliable factor.

I hope the object collision packet will make it into InSim. That would be nice to have for clean laps detection. Also nice would be to have the InSim version raised to 5 (or whatever), so that InSim libraries can easily detect they can use the collision packets and longer messages etc. And I very very much hope a kind of /stopvote command, canceling the running kick/ban vote, will make it into patch Z30. It is the thing I miss most. And maybe that Ctrl+Shift pressed bit in OutGauge. Sorry for repeating myself and BIG thanks for all this development!

Quote from EQ Worry :

For me the new packet and structure looks great, but I really cannot say now if they prove to be usable for reliable crasher detection. Unfortunately, lags are always influencing many things. I guess we all know situations when you brake on time, but the car in front of you is obviously pushed and slides away though you never touched it. But you lagged a bit, the server saw you braking 0.5 s later than you really did, and processed the inexistent collision. Now it will send a collision packet with lots of precise data, that are not so precise in fact. And cascading effect is also possible, cars hitting each other as a result of the first small lag.

I think it is a little better than you imagine. The impact detection is not done on the host, but on the guests. If you crash with a local player (AI) then of course... no problem, the data is accurate, packet is sent to the host. If you crash with a remote player, that info packet is also sent to the host. Plus, the remote player sends a packet to the host. These two packets must be in reasonable agreement, and if so, then they are combined (with some straight copying and some averaging) then output to InSim (on guests and host).

So, most of the data in the packets is in fact quite accurate, having been calculated on the guests. And a crash due to lag that only appears on one computer will not be reported.

Quote from EQ Worry :

I hope the object collision packet will make it into InSim. That would be nice to have for clean laps detection. Also nice would be to have the InSim version raised to 5 (or whatever), so that InSim libraries can easily detect they can use the collision packets and longer messages etc. And I very very much hope a kind of /stopvote command, canceling the running kick/ban vote, will make it into patch Z30. It is the thing I miss most. Sorry for repeating myself and BIG thanks for all this development!

I have implemented a /cv command for admins or hosts to quickly cancel any running vote. It applies to game votes (end / start / qualify) and system votes (kick / ban). I used a single short command for all types of vote so admins can use it without thinking too hard.

About the InSim version, I could increase it but I have only one concern. But maybe my concern is unfounded... I sometimes imagine that InSim programs will decide not to operate if the version number in increased. So the version number increase would indicate incompatibility. But maybe no-one used the version number in this way, and if so then it is fine to increase the number.

Object collisions I definitely want to do. It's possible that they won't be in the first test patch, as I am trying to release one without delay. But there are always more than one test patch and some things will be added after the first one.

Quote from Scawen :

At the moment, if less than 0.5 m/s closing speed, the packet is not sent.

I think high closing speeds are important to know if you think about what wreckers do. But I agree : 255 is not needed.

How about if it would be "closing speed times 2" so values of that byte from 1 to 250 would indicate closing speeds from 0.5 to 125 m/s?

Online testing with Victor we thought that speeds below 2 m/s would probably be ignored, because they were such light touches.

EDIT : One reason for having it a bit coarse was that it naturally provided a cut off point (0.5 m/s) so cars that were just rubbing a bit down the straight wouldn't send several collision packets. To get more accuracy we could possibly use another byte... but I still think a cutoff point is needed because of the possible bandwidth problem, maybe the same old 0.5 m/s....?

Nothing would be sent under 0.5m/s sounds weird to me.
An option to limit number of contact packets would be restrict events with some timer so 2 cars wouldnt trigger more than for example 1 event per second. However maybe this approach isnot so easy to implement, compared to a speed cutoff.
From my own insim programing experience, it seems the AXO packet has a nice cutoff system, never flooding the bandwidth, but still reports even the lightest contact. Idk how it works, but it looks efficient.

Sometimes, the cause of an accident can be a driver blocking the way on straights or at braking by changing lane when someone attempts overtake can result in blocking car being pushed by the other one even if the follower keeps his lane (kinda fish tail). I would like those contacts to be reported, but it seems to me most of them are under 2m/s and maybe even under the 0.5m/s cutoff threshold.

I am aware that small refinements are often those which eat much time. and I didnt test online so i wont discuss more over your inputs,
The "closing speed times 2" will still be better precision, and that contact packet still will be a major boost for racing spirit, am confident.

You could increase the insim version to 4.1 and state, that the minor version may change if non-breaking changes are introduced

Quote from GeForz :

You could increase the insim version to 4.1 and state, that the minor version may change if non-breaking changes are introduced

Insim version is a integer.

Quote from Scawen :

I think it is a little better than you imagine ... two packets must be in reasonable agreement ... I have implemented a /cv command for admins or hosts ... About the InSim version, I could increase it.

Fantastic about the 2 collision packets sent by clients and combined! Indeed, that is much better than I imagined. Very nice.

Also BIG thanks for the /cv command! I can't wait to test it. My only concern is that e.g. ban vote can run together with restart vote, and /cv will cancel both. Quite often there are situations, when only one type of vote needs to be canceled (either ban vote or restart vote) and the other should run. Sometimes I need to cancel restart vote but kick/ban is allowed. Other times kick/ban needs to be canceled, but restart voting should continue.

Concerning InSim version, maybe that Zero byte (4th) in IS_VER could be used for sub-version as eg. InSimSubVer? It was always 0 up until now. It could be 1 for Z30, making this InSim version 4.1, an update of 4.0. But it is a "header" byte, so I'm not sure if that's possible.

Again, thanks for all these explanations. The only thing that seems to be a problem to me now is the universal /cv command, which, if I understand it correctly, affects two different and not really related types of voting.

Quote from fat-oil :

Nothing would be sent under 0.5m/s sounds weird to me.

Maybe the collision packet could still be sent, simply with 0 as the severity (speed)?

I think I am right to say you can cancel a game vote (restart / end / qualify) with TINY_VTC.

That's what the documentation says, with one error : it says in the enum that it is "info". But the documentation (and apparently the code) say you can cancel a vote with TINY_VTC. So i've changed that "info" to "both ways".

So that means you only need another special command to stop a kick or ban vote. I think /cv is very good for typing, because an admin may want to stop a vote very quickly, without trying to remember one command or another.


EDIT : I've just added /ck to cancel kick. So /cv cancels any vote and /ck cancels a kick (or ban) vote.

is it possible to get the current throttle, current gear and brakes at MCI / NLP ?

Yes, indeed, it is possible to cancel restart/end/qualify vote through InSim, though not immediately (after 1st vote), but only when the vote is really called by the server (more than half the people voted). But that's OK, no problem there. All that's needed, in my view, is the possibility to cancel kick/ban votes, and only those votes. If /ck does that and only that, I'm absolutely happy.

Quote from skywatcher122 :

is it possible to get the current throttle, current gear and brakes at MCI / NLP ?

Would be insane to tackle the yellow flag ignorance problem but I'm afraid it's too much for now

Having the gear available in MCI would be nice, as there are some cheats giving XFG/XRG a 6th gear. But again, it is best to release the patch as soon as possible and maybe add such suggestions later, if reasonably possible. Just my view though.

Quote from skywatcher122 :

is it possible to get the current throttle, current gear and brakes at MCI / NLP ?

Would be a really easy way to detect players using more gears than the car actually has as well

Quote from EQ Worry :

But again, it is best to release the patch as soon as possible

Hmm personally I'm BBQ'ing tonight with a fellow admin. So wouldn't be much of a problem if it's being delayed a bit more haha...

OK, thats a bit selfish

Quote from fat-oil :

...

I've decided to use another 4 bits.

Now implemented like this :

word SpClose; // high 4 bits : reserved / low 12 bits : closing speed (10 = 1 m/s)

And they will be sent if the closing speed is above 0.25 m/s - we'll see how that goes.

So just to summarise / clarify, that makes it
and (for example)
would give us the closing speed as float in m/s.

Correct?

Yes, that's right.

float closing_speed = (pack->SpClose & 0x0fff) * 0.1f;

You really must do that &0x0fff before multiplying by 0.1f so it's safe if I add some more bits in the future.

I've also increased INSIM_VERSION to 5.

Well, this looks ultimate. Bravo

It would be nice if the button interface had a hot key mechanism, so you could bind an on screen button to a keyboard button. It would allow for things like a menu system to be used without having to stop playing (mainly for mousers like myself), al la Counter-Stirke.

Source: InGame Menu for Server Plugins, VGUI Docs, and Alliedmodders: Menu API* (If you read nothing else, read the one in bold).

I don't think Scawen is taking requests, you could post that in the improvements forum.

Quote from Mango Juice :

I don't think Scawen is taking requests, you could post that in the improvements forum.

If you look back in the thread, it seems that he is as long as it's not to hard. I'll suggest it, and he will decide if it get's into the next version or not.