Prefixes for material identifiers: !!, !, >, 0-9, A\
Prefixes for actor identifiers: &, &£


Actor's identifiers
¯¯¯¯¯¯¯¯¯¯¯¯¯¯
& simply tells the preprocessing function not to merge this actor with the rest of the track mesh. Mostly because said actor will be animated afterward or will be a noncar.
example:
&CAR0001.ACT (names are still changed by the preprocessing, a nummer sufix is added)
&81F0056.ACT (this is a noncar, first two digits tell the noncar txt ref)

&£ is another kind of gameplay object: the powerups. Nothing is needed beside naming it correctly. This is only in C2 has C1 defines powerups inside the text file.
example:
&£680030.ACT (two first digits tell the powerup ref, and then the nummer sufix)

It's possible to animate powerups and noncars with a groove too.



Material identifiers
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
!! and ! are used to make a material nonsolid. However if the material is used on a horizontal mesh, going through it will activate the default sfx volume, water. !! is always used with water/sea/pool materials but I don't know whether there's a difference with ! or not.
example:
!!WATER2.MAT, !!ICEFLO.MAT
!VINES.MAT

> is quite unknown and might only exist in C2. It's the same as above but it won't trigger the default sfx volume when you go through it (when applied on a horizontal mesh I mean).
example:
>CLOUDS2.MAT

0-9 activate a material modifier on materials. If there's no number (CRANE.MAT for example) the default material modifier will be used. 0 (0GRASS2.MAT) triggers the first material modifier after the default one, 1 the second, and so on.
example:
0MUD3.MAT
5SNOPATH.MAT
8GRAVEL.MAT

A\ is probably only effective in C1 (as C2 uses alphachannels anyway). The A letter can be replaced by any letter actually, the \ trigger must be placed as the second character and then followed by two digits telling the percentage of transparency. I know C2 has known materials like R\75GLS.MAT but I doubt it really relies on the percentage defined in the material identifier, it probably just uses a generic texture stored into REG or PIXELMAP (win.pix or glass.win etc idk).
It's a Splat Pack only feature, bringing a Splat Pack track into C1 without SP won't render these textures as transparent.
It seems like the names are based on previously existing material identifiers but with the /## added into them like so: FLAMES.MAT > F/25ES.MAT
example:
W\50OW1.MAT
I\50GLASS.MAT
T\75NSEJ.MAT
R\50GLS.MAT
A\75OOF.MAT
but also !\75LAME.MAT (nonsolid flame, being able to keep the ! or 0-9 is probably why they told the parser to look for the \ in second position)

@Jeff: Are you currently applying texture filtering? I hope there will be an option to turn it off :]
I can try to list the groove and funk keycodes too but it'd be harder to be exhaustive about the groove/funk chunks syntax. There are very few C1 tutorials actually, nothing about C1 track making at all, and it's been more than a year that I started a C1 car making tutorial but it gets harder to explain with all the hex stuff to do so I kinda dropped the idea. There are the notes on my blog too but I guess you already read them.:
http://www.toshiba-3.com/dotclear/index.php?post/FUCK-YEAH-C1-PIX-DATA
http://www.toshiba-3.com/dotclear/index.php?post/Untextured-materials-with-custom-lighting
This however also applies in C1, Actor rendering modes:
http://www.toshiba-3.com/dotclear/index.php?post/Actor-rendering-modes
but I wonder whether C1 supports polygons rendering as C2 does or simply turns everything back into triangles.
Bunch of other C1 basic tutorials there too: http://coffey.polygonized.com/tutorial.html

@Killer11 & D3ads: if we get rid of the oldschool look, it won't be C1 anymore right? ;)

TBH if a fan nextgen Carmageddon was so needed/possible it'd be already in development.
The people behind TTD aren't the same as those behind Carmageddon. The company that owns the rights of the game doesn't care about it anymore and so that guy who started OpenTTD had his hands free. SCi isn't like that at all. Just look at Errol's mod: he barely had the time to create a track and a few things that he got some cease&desist in his mailbox :]
Also I remember a lot of little projects here and there trying to create a nextgen Carmageddon on moddable engines, they never get finished. Probably because a carmageddon-type game isn't that much interesting after all and doesn't attract developpers. YOU really want a nextgen Carmageddon. And a few of us too ofcourse. But not so much out there. Else SCi wouldn't have canned the C4 project or at least someone would have tried to fill that vacuum.
My bet is that nobody will do better than C1 & C2 carmageddon-wise.

Just look at this project correctly: Jeff wants to do an open C1, make it work on modern systems easily, maybe crossplatform, and add some features besides all the original ones. Further I guess it might be intersting to have a proper and modern netcode, but it is not the time yet.
The aim isn't to create a nextgen Carmageddon engine, I'm sure the project should be started totaly differently than Jeff started it, it would require a lot lot more work, even with many other people on the project. All that knowing that there's a near 100% chances that SCi forces the project to stop.

This is "just" an open C1 project. It is enough in my eyes. What's the point of a nextgen Carmageddon that doesn't feel like the real thing, gameplay being the same, when you can have the real Carmageddon working properly. Adding detachables and 3D peds, this is C2 then. Making an open C2 is already way more difficult: deformation engine, lighting system, peds animations, much more features. Let alone turning it into a 2009 nextgen game, that's insane.

This is all just my opinion and I don't want to reply instead of Jeff.
Finishing the openC1 is a good enough project, no need to hassle Jeff about adding nonC1 features. If someone wants to start a nextgen Carmageddon on this project, I guess that person will be able to create a fork when the project goes opensource.

Personaly, I'd like to see this openC1 as what Fitzquake is to the original Quake: an open source port of the game fixing bugs, removing limitations, adding a few conveniences for modders and users, but still being like the original game. Something simple that works.

Alright, I ofcourse agree with your points and all, but I feel like your enthusiasm and my pessimism do the difference in our point of views.

Anyway, the important point in my eyes is: so far Jeff never told he was interested leading this project towards a nextgen Carmageddon engine at any point. Ofcourse such a project wouldn't be done alone and would be started after the initial project is completed. But seeing Jeff only wanted to do an openC1, I don't think what he will have achieved will motivate anybody else to create a fork aiming at a featureful Carma engine because there still will be a huge lot of work, implying things could be started from scratch again for the best.

If I had to be as optimistic as you, I'd say... hell yeah let's complete the project afterward with nextgen features, ala DarkPlaces (I'm not especially looking forward for this, but it'd be an interesting project). With existing libraries I'm sure it'd be "easy" for a coder to implement everything you suggested in your previous messages. But... will there be someone to do that? And will that someone (or team) be able to recreate the right Carmageddon feeling? Won't it be another mirage?

Now that I think about it, so far there's no large scale project from the Carmageddon community that got completed...

BTW why do you think there's so much people looking forward for a nextgen Carmageddon? Everytime I read/see people remembering Carmageddon, it looks like a good part of nostalgia but no one really seems to be willing to play such an oldschool arcade game again. Even on nowadays handelds, people would be complaining about how repetitive it is. I think such games can't exist anymore. We are just still there because we enjoy modding the game and see our creations in such a gameplay?!

It's 64x48x8\pixelmap\hirestch.pix!
Working on the hud? :]