--------
Driftboost formula changed to:
49 + player->kartspeed*2;
(No longer factors weight from previous version)
Collision code now factors character weight for players.
Collision code now only plays the collision sound once, rather than per player.
Weight now factors into drifting's base value. A heavier character will drift more straight with no input and have less control.
Added a cheat check in SetPlayerSkinByNum(), to force speed and weight within the boundaries of 1 and 9.
Nerfed orange turbo to 50 frames, down from 60.
(various large invisible blocks used in the level cause rain to make splashes high above the main level, high enough to make ghostly rain splash sprite artifacts appear sometimes in nearby areas)
I'm convinced there's going to be some stupid side effects from doing this, but it's the quickest way I can fix the polyobj planes not all appearing anyway
Fix R_AddSingleSpriteDef's I_Error messages
Whoops, seems I forgot about this little branch. Basically this fixes how for a character's sprites, a full sprite lump name is displayed instead of just its sprite prefix in the "R_AddSingleSpriteDef: No patches found for [sprite prefix] frame [frame character]" message (unlike when it occurs for non-character sprites), resulting in something like "R_AddSingleSpriteDef: No patches found for PLAYC2C8 frame \^" which does NOT help custom character authors at all as it just confuses them instead. (for the record, the problem would actually with the ^ frame and not the ones displayed after "PLAY")
Oh, and the same problem is also fixed for this similar message: "R_AddSingleSpriteDef: Sprite [sprite prefix] frame [frame character] is missing rotations"
See merge request !95
* NAMEcL refers to a frame which is seen for the entirety of an object's left side.
* NAMEcR refers to a name which is seen for the entirety of an object's right side.
* NAMEcLcR does both sides.
* Having just a NAMEcL requires you to fill in the opposite side either with NAMEcn where n is 1 and 5 to 8 OR fill in with a NAMEcR
* Switches down the centerline of the object instead of at the ANGLE_202h interval for normal sprites.
* Characters were selected for 1) ease of use and 2) not getting in the way of adding support for zdoom's totally bananas 16-way sprite system at a later date if we so choose
Note: polyobj_t's "translucency" is apparently a SIGNED integer, so in theory it's possible to get polyobj flats to use the "spanfunc = splatfunc" line using negative values. If this is not meant to happen, this should probably be fixed asap
Conflicts:
src/f_wipe.c
