quale

Fast screenshots aren't that difficult. You can grab the frame really fast. The trick is to then not hold the game up with compression and writing to disk. A format like PNG is just too slow to compress using libpng's defaults. You could probably speed it up tremendously without really hurting compression by fixing the filter and setting it to Huffman-only mode. Better yet, do it asynchronously. But it isn't TruckersMP's code. Maybe you could convince whoever is responsible for it to speed it up. What makes it difficult to do in TruckersMP is that the developers are patching binary code. It takes a lot of work to accomplish the simplest of things, and then you have to do it all over again for each new version. Each additional hook increases the burden of maintenance. A fast screenshot routine would take quite a few. If you're lucky things haven't changed fundamentally and you 'only' have to find new addresses. If you're less lucky you have to redo the whole thing.

I have taken several hits from players connecting right in front of me. People should really make an effort to connect in NCZs or at least not in the middle of the road. If you get disconnected you can still park up somewhere before restarting the game. For most of ETS2 you can use the web map to be really sure if you aren't in an NCZ. Only a game crash (how rare is that?) makes it more difficult, but that only makes starting SP to move somewhere safe more natural. In all, it happens too often when it should be easy to avoid. I think it should be part of the rules, along with other ways of just appearing somewhere such as loading saves. It's certainly part of my rulebook. If you must do it at all, take the necessary precautions. Disabling collisions for a few seconds should be fine. It shouldn't affect any normal play. It would be difficult to abuse any more than you can now. Abuse would almost certainly decrease overall.

This is still mainly a question of what I'm currently supposed to enter. Does anyone know? I could post a suggestion later based on what I've learned here.

I was wondering about that. Doesn't seem to be hugely important in getting the report dealt with but it would be good to be unambiguous. The form should mention the time zone. JavaScript could be used to let the reporter use their own time zone, which would probably improve overall reliability. Still tell them that you're doing so.

How does this look? At full size, of course. Unfortunately I only just found out this board limits images to 500 KB, and above all, 1200 pixels. That doesn't do it justice. Maybe I should've cropped to retain definition. Oh well. I used some data from ets2map.com because I just wanted to see it. Don't worry: my recorder is difficult to distinguish from someone watching the map casually. I also only recorded 20 continuous minutes for these images, and little more in total. No undue load on the tracker, I'd hope.

If you want a smaller-scale test, it would be best to test particular companies and/or geographical areas. Make it predictable so people can catch on quickly. Like I said, I'm afraid you do need deployment on a mainstream server for the test to mean anything.

This should be pretty easy to do, too. You can just record coordinates directly; no need to match to road segments. I think it's even better because you can see the actual lines people take. Drawing as points is probably satisfactory. You may not even have to correct for speed because roads where people are moving fast are apparently under capacity. Creates a sense of where people bunch up. If I were to implement it I'd draw each point with a slight blur like a normal distribution, with a wider cutoff than you'd normally use and recording intensity at high precision. This way, if there are many points around the same place, the visual thickness increases. For performance you could quantize coordinates to whole pixels at the current map scale or use something cheap like bilinear and then convolve the whole thing with a normal distribution. Should help when there are many points to be drawn, like when zoomed out. All depends on implementation details. The scale that converts intensities to colors should probably be logarithmic-ish. Temporally, you could initially work on 24 hours at once. Many possibilities. All details that can be changed easily once it's working. Is there some interface to track all the trucks? It would be nice to sample at high frequencies to capture curves in less traveled areas better. Let's say there are 2500 trucks, with 8 bytes per truck. That's 20 kB for the entire state. You could fetch this a few times per second without being a huge strain, I think. Delta updates and other compression could improve this somewhat. There only needs to be one consumer taking in so much data.

One reason it would be hard is that once it's technically working (I don't believe the servers currently do much other than forward positions, mind you), traffic is going to be hell. SP is passable because it only simulates a few cars near you. That huge bottleneck you just ran into, like the pileup that tends to ensue when a lane is removed? You can get through in a matter of seconds because until you got near, there were no cars to get stuck there. Even if you did something like this in MP, so cars only spawn in the vicinity of players, if multiple players approach the bottleneck it's all going to add up and reduce the capacity in terms of player trucks significantly. Imagine Europoort if every player brought two dozen cars along. They aren't just going to evaporate. They only despawn when they get out of range (not going to happen when sandwiched between players in a jam) or leave the network using one of those roads inaccessible to players. Engineering something like this so that it actually works is no easy task. For MP you must consider traffic flow throughout the entire European network to prevent continental gridlock.

Although it's nice in theory I wonder how it'd work in practice. Often enough there will be 3+ others on a company lot, most of them not knowing how to reverse. Waiting for all of them isn't what I think of as fun. That's assuming we'll be able to organize an orderly queue without blocking people trying to park or leave. Remember you can't trial this with a limited scope. A server with not too many people in it isn't going to have the same contention for space as there would be in a full server. Self-selection bias would probably make for a more serious and skillful population. If the trial works, of course that's nice, but it isn't representative of widespread deployment. It seems they forgot to add some NCZs. Last time I was at Konstnorr, Helsingborg I don't think there was one. Are there other examples? Perhaps they'll prove useful if they're statistically like the other companies.

I actually turned it off because the extrasensory perception was freaking me out. It's already much more than you should need, but apparently it isn't enough? That would be a 'no' from me. As for the internals of warning blips, as far as I can tell the server doesn't run any game logic. Asking the client for something like damage doesn't seem like a good idea because of cheating potential. Perhaps hard braking could be detected. There might be some conflation with bad lag but that isn't necessarily a bad thing. Additionally, being on track for a likely collision, especially with a great speed difference, could trigger it.