Discussion

I can't send a message to anyone on the SW Battlefront2 forum. The option to send a message simply no longer appears on people's profiles.

KS hairdo's hdt has 100 physics enabled hairstyles, which is a lot. But not enough to be unique among hundreds of modded npcs. Only 1/8th of ks hairdos has been converted, and nothing from apachii hairstyles. The only other options 6-8 from valkyrie and a bunch of random asian rpg hairstyles scatted across the internet. After 7 years i believe there should be more. I tried myself, multiple times and failed misserably at it.

Thank you for the suggestion. I'll definitely try that. I already kind of played around with the idea because I set another armor for an important character to "unplayable", I just wasn't fully sure that it also extends to the trade inventory. Is there a way to dynamically flag items as "unplayable" at runtime or do I need to do this for each item individually?

For reference, here is a short description of the reflection data format. It consists of a set of chunks that begin with the chunk type (4 bytes, BETH, STRT, TYPE, CLAS, OBJT, DIFF, LIST, MAPC, USER or USRD) followed by the data size as a 32-bit integer, then the chunk data. The first three chunks are always BETH, STRT and TYPE, in this order: BETH: Header, the size is always 8 bytes, and the data consists of two 32-bit integers, a version number that is currently always 4, and the total number of chunks in the stream (this includes the BETH itself). STRT: String table, it is a set of C style NUL terminated strings concatenated to a single data block. In the rest of the stream, type and variable names are 32-bit signed integer offsets into the string table. There is also a set of pre-defined types that can be referenced with negative string table offsets (see below). TYPE: It contains a single 32-bit integer that is the number of CLAS chunks to follow. These are followed by class definitions (CLAS), the same number as specified in TYPE. The format of CLAS data is: Class name as string table offset Unknown 32-bit integer, usually 0. Flags as 16-bit integer, if bit 2 (0x0004) is set, then a USER or USRD chunk will be used to store the structure data. Other flags are unknown. Number of field definitions to follow (16-bit integer). The definition of a single field consists of the name and type (both as 32-bit string table offsets), then the data offset and size as 16-bit integers. The latter two refer to how the structure data is stored in memory in the game (with alignment etc. taken into account), and are not required for decoding. The class definitions are followed by the actual data. Each object is stored as an OBJT or DIFF chunk, which begin with the data type (as string table offset). The difference between OBJT and DIFF is that the former just contains all data fields as defined in the CLAS, while the latter uses a "differential" format that allows for encoding only a subset of the fields. In DIFF, each field is stored as a 16-bit signed field number (0 = first) followed by the data. A negative field number denotes the end of the structure. The differential format is not used within simple built-in types (like integers and floats) that are not structures, but it is inherited by sub-structures that are stored in separate LIST, MAPC, USER or USRD chunks. Regular structures can be nested within OBJT and DIFF, however, certain data types require additional chunks, which are stored separately after the parent object. These special types include: LIST: A list of objects, begins with the element type (string table offset) and the number of elements (32-bit integer), followed by the element data. MAPC: A map of objects, similar to LIST, but it contains key, value pairs, and it begins with the key and value types (two string table offsets) and the number of pairs. USER, USRD: Used for sub-structures with the "user" (0x0004) flag set, USER if the parent is OBJT, and USRD if it is DIFF. These allow for type conversions. If no actual conversion is performed, then the format is similar to OBJT and DIFF, except the structure type is stored twice at the beginning of the chunk, and there is an additional unknown 32-bit integer at the end. Otherwise, each field of the structure is stored as the actual type to read (it is always a built-in type in the data I have tested so far) and the field data. Note that in the latter case there seems to be no difference between USER and USRD. Finally, here is the table of built-in types: 0xFFFFFF01 (-255): Null, no data. 0xFFFFFF02 (-254): String, a 16-bit length value followed by the C style string data (including a terminating NUL character). 0xFFFFFF03 (-253): List, requires a separate LIST chunk. 0xFFFFFF04 (-252): Map, requires a separate MAPC chunk. 0xFFFFFF05 (-251): Pointer/reference to anything, stored as a pair of type and data (the type is a string table offset). 0xFFFFFF08 (-248): 8-bit signed integer. 0xFFFFFF09 (-247): 8-bit unsigned integer. 0xFFFFFF0A (-246): 16-bit signed integer. 0xFFFFFF0B (-245): 16-bit unsigned integer. 0xFFFFFF0C (-244): 32-bit signed integer. 0xFFFFFF0D (-243): 32-bit unsigned integer. 0xFFFFFF0E (-242): 64-bit signed integer. 0xFFFFFF0F (-241): 64-bit unsigned integer. 0xFFFFFF10 (-240): Boolean (0 or 1 as an 8-bit integer). 0xFFFFFF11 (-239): 32-bit float. 0xFFFFFF12 (-238): 64-bit float. The above is only a description of the general reflection data. However, the material database can be dumped in a human readable format with mat_info -dump_db, which could be of help understanding the structures it uses. The 32-bit hashes in resource IDs use CRC32.

If the items are created by you then you could set their 'unplayable' flag - then they won't even appear in their inventory no matter how it is opened.