You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of having an implicit "if the child is exported it is not going to be exported in the parent, as discussed offline, we just explicitly define how the parent export works as a combination of its children.
For CompoundValues this would be fully automated. For CustomCompoundValues this would be more bespoke, in that we could not automatically validate that the parent or child were being exported properly without parsing the c++ code, but it would setup the structure needed for the custom c++ code to write parent or child values, which is something.
A 3D Box with 3 dimentions (custom input output delimiters)
# something to know how to import compound values that are not comma delimitedxml_parent_import_patterns: ["{width}x{height}x{depth}","{width},{height},{depth}"]xml_parent_export: "{width}x{height}x{depth}"xml_children_export: []
Even though this is really complicated and we might want to relegate it to a custom class, if we wanted to support this there would still need to be something that could define the input/output for compound custom classes
Lets ignore that for now and just require that the xml_parent_export to only contain tokens of the children separated by a single comma.
Validation
With this we can do some rudimentary validation that all of the children are being serialized properly to xml, while making it obvious how the serialization occurs from the documentation. Instead of the "not immediately obvious but clear once you know" solution of removing any specific children exports from the parent export.
The text was updated successfully, but these errors were encountered:
Idea for CompoundValue and CustomCompoundValue
Instead of having an implicit "if the child is exported it is not going to be exported in the parent, as discussed offline, we just explicitly define how the parent export works as a combination of its children.
For CompoundValues this would be fully automated. For CustomCompoundValues this would be more bespoke, in that we could not automatically validate that the parent or child were being exported properly without parsing the c++ code, but it would setup the structure needed for the custom c++ code to write parent or child values, which is something.
Color
Position
Position with QPos for 4 dimensional gaming
Euler Rotation
Future Possibilities
A 3D Box with 3 dimentions (custom input output delimiters)
A Datetime (partial compound values)
Even though this is really complicated and we might want to relegate it to a custom class, if we wanted to support this there would still need to be something that could define the input/output for compound custom classes
Lets ignore that for now and just require that the
xml_parent_export
to only contain tokens of the children separated by a single comma.Validation
With this we can do some rudimentary validation that all of the children are being serialized properly to xml, while making it obvious how the serialization occurs from the documentation. Instead of the "not immediately obvious but clear once you know" solution of removing any specific children exports from the parent export.
The text was updated successfully, but these errors were encountered: