[T1] PPLedit Source

Exhibit A, all that I know about .ppl files:

.ppl File format:
char[4] //PL98
unsigned int numpals //number of palettes in the file
unsigned int ved_int[2] //no idea what these are
unsigned char ved_chr[9 * 4] //36 bytes, no idea what these are
palette palettes[numpals] //palette data
[unknown crap follows palettes]

Exhibit B, the source: http://www.team5150.com/~andrew/project.tribes/ppl/ppledit.zip

This is all I know about .ppl's, now someone else can fix the command screen problem :)

Andrew, your ³ isn't like this ³.

:F

get to work people.

Yea, I got a custom 3 when everybody else had Vet 2. I wanted to get it changed to "x" when 3 rolled over, but I never did :(

did you write this yourself?

in pl98.h in the ppl_pallette definition, changing the aray called colours from 256 to a bigger number would let you have 32 bit colour?

sorry my C/c++ skills are very basic

No, palettes can only be 256 colors.

Some more info for anyone who cares.

The names "506.pal" and "5150.pal" etc come from the palettes when they're indexed inside a PPL.
A PPL file is kind of like a VOL file that just stores palettes.
The last 4 bytes of a palette contain their name, only in hex format, and backwards.

5150 in Hex is 0x0000141E, only Tribes palettes stores their names backwards.
So it'd look like 1E 14 00 00, at the very end of a palette.
It's an easy way to find out where each of the palettes are, inside a particular PPL.
If you want to edit a particular color in say, 1071.pal
You'd open up Windows Calculator, switch to Scientific mode (View > Scientific), make sure it's set to Decimal, then type in 1071 and hit Hexidecimal. Which converts it to 0x0000042F

So if you search for 2F 04 00 00 inside lush.day.ppl, it'll take you to the end of 1071.pal

The way I discovered "palette hacks" originally was when I found -1.pal was the first palette inside lush.day.ppl, and matched the Hex color Green up with 00 FF 00 and 00 (Alpha/Transparency).
It's wierd though, because negative numbers in Binary are backwards, so -1.pal's "name" wasn't -01 00 00 00 or anything, It was FF FF FF FF, and -2.pal is FE FF FF FF.


If you experiment by changing crap like 5150.pal (1E 14 00 00 @ 0x287C) to another name, and just swapping the names of things. You can swap the palettes that particular BMP's use. Although if a BMP can't find the palette it's trying to load, Tribes will crash.

You can do pretty much anything to the palettes apart from change their names, as Tribes PBMP's and Fonts contain 4 bytes of crap that tells it what palette to use.

I can't really remember much more off the top of my head (As I haven't worked on palettes for around 8 months), but if I do I'll post it :

Edit: Also, completely forget about the names "Interface.pal" and "Base.pal" when messing with palettes. They're just names Labrat gave them and will confuse you.

Palettes aren't loaded by Tribes by default either, they're specified in the .mis files when a Mission loads. Which is why 503.pal in lush.day.ppl will be different to 503.pal in ice.day.ppl
Shell.ppl is specified in one of the scripts that's loaded when Tribes is.
So you can pretty much name a PPL file anything, as long as the .mis tells it which one to load.
And you can name a PAL anything (with its Hex name), as long as the BMP is told which palette to use inside the PPL you load.

Holy shit. I have nfi what most of that mean.

Are there any theories on why this happens?

I just know the cmd map uses software mode to render the cmd map display, so all the extra crap is somehow related to software mode. Maybe it's lookup tables for all the transparency/shading stuff..

Sarca, what's the purpose of 800.pal in your updated lush.day.ppl file? If 302.pal is used for terrain textures what's the purpose of 800.pal?

Edit: Nevermind. Forgot about the new sky textures.

Holy shit. I have nfi what most of that meant.