updated with itemid specification
updated with itemid specification
Based on a 8 bytes line (0-7)in winhex (or other hex editing prog)
An item from Part.iff th has 64 lines
An item from Part.iff Jp has 67 lines
Last edited by PHOENIXXXX; 10-03-11 at 03:30 PM.
We're talking bytes here, not lines (this isn't Microsoft Word, I mind).
What you probably mean is that a JP part record is 528 bytes long, as opposed to the 512 bytes TH record.
Since an item name in the JP records is 64 bytes long (as opposed to the 40 bytes in TH) and we only have 528 bytes, we're short 8 bytes somewhere in the record when assuming the record has the some properties.
If you open a file with FileXplorer it will give you the size of every item in the file. This can then be used with any normal hexeditor, in my editor if i select a few bytes it shows how many bytes i have selected. tada.Originally Posted by PHOENIXXXX
---------- Post added at 06:33 PM ---------- Previous post was at 06:32 PM ----------
Is JP newer then TH? if so it might be that they removed some unneeded columns which were supposed to be used for something.
Jp with the Kr version are the oldest versions. Pangya Jp was launched like 6 month afet the Kr release.
The use of the fields is different, they have fields for Gacha and other stuff we miss in TH.
Still working on it: but no i don't think so... the main difference like has said Chreadie is for the name which is longer.
Some bytes have also changed places.
I should finish cross checking with other part.iff soon.
Ive noticed that by using my bitmask for item position i get different values for different characters items:
Nuri Shoes is 5 while Hana shoes is 6, anyone have any ideas?
Do a cross check with other characters, maybe you will encounter the same.
i did and i found that most have the same as hana but not all, maybe they are related to the 3d-model?
All long's should be treated as int's.
I have just checked the Kr part.iff.
It has 516 bytes. Seems very close to the TH and US part.iff.
All the 1st 144 bytes and all textures are the same.
Only the Hidemask has moved (?)
Flags (shop and money) could be like those on the jap version.
Last edited by PHOENIXXXX; 13-03-11 at 06:48 PM.
Card.iff is a little bit different than i originally thought, first byte custom to card.iff defines (what i believe to be) what type of card it is.
I will update my application soon to support this.
This is normal. The PosMask value within the IFF is different for each character. Here's a somwhat complete mask for Kooh:
Spoiler:
As you'll notice the Pos marker you extract from the TypeID gives you the bit position (starting from 0) of the primary item type (i.e. Blushies or Feathers). This is important to note when dealing with items that take multiple slots.
I assume that due to the different model structure of each character, we'll have to run 9 different PosMasks.
A more interesting aspect is the Type value one can extract from the Type ID - it seems to be constantly increasing (just like the Serial, where I do expect this behaviour). For Nuri it's 0 for all upper body and lower body parts and many hats (if sorted by TypeID "Halloween (Nuri)", 134223885 will be the last item with type 0) - but suddenly starts fluctuating for newer hats (starting with the "Tomahawk Headset", 134293504 [type: 1] and goes on with the "Gentleman Hairdo", 134348800 [type: 2]). Begs the question whether or not the choice important. Every character has 4 numbers reserved, starting at 0. Some numbers are not being used, though.
It seems generated Type IDs with 0 as Item Type will still work fine - but as with the UCC shirts (where some of the DB values from the Type ID have been nulled) there might be problems later on (currently you can only buy one UCC shirt - so I guess the values are wrong).
Last edited by Tsukasa; 17-03-11 at 03:11 PM.
Nice explanation!
From what ive seen:
Position it a digit between 0 and 20 and type is a digit between 0 and 4.
More research will teach us more!
Reply With Quote
