This library currently combines the concept of property tags (treated as property "headers" in this library) with property values, while UE defines and handles these concepts separately. To more closely represent the binary file format, we should consider refactoring the code to better differentiate between tagged and untagged properties.
For example, when an ArrayProperty contains a StructProperty, the serialized property will not have a tag, but the StructProperty type used by this library to represent it contains a guid field relating to the absent property tag:
impl From<VectorF> for StructProperty {
#[inline]
fn from(vector: VectorF) -> Self {
Self::new(Guid([0u8; 16]), StructPropertyValue::VectorF(vector))
}
}
Additionally, this library only supports array_index for NameProperty, although raw arrays could be valid in other locations and types. Some ideas that could help to improve this situation are:
- Store tags separately from values. Examples of header values that are stored in Property types:
array_index in NameProperty
type_name in StructPropertyValue::CustomStruct
- Use
EPropertyTagFlags to DRY out the various impl_* macros.
- Expand the
impl_* macros to support StructProperty.
- Update the code and documentation to consistently refer to property "headers" as tags. This will reduce any possibility of future confusion between the file header and the property header.
This library currently combines the concept of property tags (treated as property "headers" in this library) with property values, while UE defines and handles these concepts separately. To more closely represent the binary file format, we should consider refactoring the code to better differentiate between tagged and untagged properties.
For example, when an
ArrayPropertycontains aStructProperty, the serialized property will not have a tag, but theStructPropertytype used by this library to represent it contains aguidfield relating to the absent property tag:Additionally, this library only supports
array_indexforNameProperty, although raw arrays could be valid in other locations and types. Some ideas that could help to improve this situation are:array_indexinNamePropertytype_nameinStructPropertyValue::CustomStructEPropertyTagFlagsto DRY out the variousimpl_*macros.impl_*macros to supportStructProperty.