Discussion

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.

looking for someone to basically do what Hijimare did with their Dryad Male Outfit mod, but with mizora's dress and hair shoulder cloak thing (images included for clarity) for half-elf body type 2 🥺🥺🥺 i can probably pay (i do not know anything about modding payrates woops) and it'd be a surprise for my darling so im very interested in it being done. lmk if you'd consider it!!!!

i am not sure wat i am doing wrong i have downloaded  several mods and those that need the bat command in my ini seem to be working fine just as some of the esm files like the craftadhesivevacuumtape or comspike, but the USU.esm selection Gravbooster and Biggerships just wont load correctly ! in all casses of the ESM files i used the same setting *name.esm so why do those few not laod correctly?

hi, i'm trying to figure out how i can find the amount of active .esp's i have.... i'm trying to find it, but well i have issues finding the milk when its right in front of me 😛