Difference between revisions of "Talk:CPF"
| (One intermediate revision by one user not shown) | |||
| Line 12: | Line 12: | ||
Out of curiosity, has anyone noticed any differences between the data types 0xEB61E4F7 and 0x0C264712? I've not even seen 0x0C264712 yet in any of the CPF files I've worked with, and if they're both Ints, why would there be a difference? One of the main reasons I'm worried about this is that I'm working on some new code to handle CPF files, (including saving them once editing has been done) and if there's no real difference, I'm going to probably just have it save everything back with the 0xEB61E4F7 data type since it's all I've seen so far, and I can think of no reason not to. --[[User:Jfade|Jfade]] 16:32, 24 January 2007 (CST) | Out of curiosity, has anyone noticed any differences between the data types 0xEB61E4F7 and 0x0C264712? I've not even seen 0x0C264712 yet in any of the CPF files I've worked with, and if they're both Ints, why would there be a difference? One of the main reasons I'm worried about this is that I'm working on some new code to handle CPF files, (including saving them once editing has been done) and if there's no real difference, I'm going to probably just have it save everything back with the 0xEB61E4F7 data type since it's all I've seen so far, and I can think of no reason not to. --[[User:Jfade|Jfade]] 16:32, 24 January 2007 (CST) | ||
| + | |||
| + | == Another CPF type == | ||
| + | |||
| + | I've discovered in some very old packages another CPF type ID - 0x6D783F3C. It's not the usual format, so I'll re-post when I've worked it out. | ||
| + | |||
| + | :Ignore the above - this is an uncompressed XML chunk, so to read you have to backtrack 4 bytes then reading the entire thing as a single XML string and process as normal. | ||
Latest revision as of 16:29, 4 April 2007
Is the type ID CBE7505E or CBE750E0? Albmont 14:33, 31 December 2006 (EST)
- Where are you getting the E0 one from? Delphy 16:18, 1 January 2007 (EST)
- I got it from a recolour done with BodyShop, EP1 version. I guess it was the Property Set, but I could not read the data (the numbers were wrong). Albmont 19:10, 1 January 2007 (EST)
[edit] SimPe
SimPe - apparently - used the sequence E0, 50, E7, CB, 02, 00 to detect the CPF. It's in the file CpfWrapper.cs. Albmont 15:26, 6 January 2007 (EST)
[edit] Differences between the two Ints
Out of curiosity, has anyone noticed any differences between the data types 0xEB61E4F7 and 0x0C264712? I've not even seen 0x0C264712 yet in any of the CPF files I've worked with, and if they're both Ints, why would there be a difference? One of the main reasons I'm worried about this is that I'm working on some new code to handle CPF files, (including saving them once editing has been done) and if there's no real difference, I'm going to probably just have it save everything back with the 0xEB61E4F7 data type since it's all I've seen so far, and I can think of no reason not to. --Jfade 16:32, 24 January 2007 (CST)
[edit] Another CPF type
I've discovered in some very old packages another CPF type ID - 0x6D783F3C. It's not the usual format, so I'll re-post when I've worked it out.
- Ignore the above - this is an uncompressed XML chunk, so to read you have to backtrack 4 bytes then reading the entire thing as a single XML string and process as normal.
