Your idea of a good balance between two specific goals. Scawen's idea of a good balance (let alone which or how many goals he's balancing) may vary
This I would love, almost as much as I'd love to stick a set of knobblies onto a FXR and go churn up a field. RB4 field-hooning is great, but MOAR PWR! and all that. Tyre restriction is not a coding issue, just a matter of preference (Scawen's said before it's for realism, IIRC).
That one's not just about priority, it's to avoid duplicated effort. The current cars have been extensively tweaked/tested to make the way they interact with the old tyre physics better (again, IIRC. I think he said he something along the lines of wallpapering over some tyre physics sins with car model hacks, but I can't find the reference). Long story short: there's more than the usual content development goes into putting cars into current-physics-version LFS, the extra time would be wasted effort if he did it before the physics. I don't fancy your chances of swaying him on this particular issue
I'm an edge case, sure, but I see the things you see between starting LFS and choosing 'multiplayer' about once a month (only when a restart of LFS or the computer is needed).
It would need to be in with the server-list, I would think, in order to be visible most often. Perhaps it could be in both places, or functional in one place with a live preview in the other place. Plenty of options to play with if Scawen likes the general idea, anyway
Sorry, I'd forgotten how this bit worked... it's been a while
You get the player flags in the NPL packet when a player joins the track, and in the PFL packet if those flags change while you're already on track. The format is the same in both places.
1601 is 1+64+512+1024, so PIF_SWAPSIDE (1), PIF_HELP_B (64), PIF_AUTOCLUTCH (512) and PIF_MOUSE (1024).
If it's not catching the autoclutch flag from a flags value of 1601, I can only think that you forgot to copy all those defines you listed into your code? (1601 & 512) will be evaluated as true, but (anything & 0) will be false... and an undefined constant will end up being 0.
What I'm doing with the '&' is checking to see if that bit is set. So, 'Flags & 8' will be true if the autogears bit is set for that player, and false otherwise.
If your code above is working, then you can replace the message line with this to check:
If you know how to get at the $Flags variable then it's just the code below, but I'm afraid I'm not familiar with PRISM if you need help getting at it.