<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the category: Engine.</i>
I have now checked in the map data type processing script (<tt>Scripts/makedmt.py</tt>) and the map data types "meta header" file (<tt>Include/mapdata.hs</tt>). I have also updated p_dmu.c with the necessary changes. However, P_Copy(p) and P_Swap(p) will not work with the currently available data. We need to do some extra thinking here.
The way the P_Copy/Swap previously worked, using the propertyTypes array, is flawed. It makes the incorrect assumption that every property has the same type in each map data object. This is not the case when it comes to, e.g., flags. We will most likely need a way to determine the DDVT type of a property, given we know the DMU type (e.g., DMU_LINE, DMU_POLYOBJ) <b>and</b> the property (e.g., DMU_FLAGS). We will need to modify makedmt.py and mapdata.hs so that the internal members are mapped to properties. I was thinking something like:
...and so on.
HOWEVER. Because properties are not really 1-to-1 mappable to internal data members, we should carefully consider how P_Copy/Swap should be implemented, and how mapdata.hs should be defined. Some properties affect multiple internal data types, or are interpretations of the internal data. These can only be handled as special cases in P_Copy/Swap, or otherwise we have very complicated logic on our hands (need to define member aggregates, translations, whatnot... Not a sensible use of our time?). It seems to me that a simple mapping like in the above example is good enough for something like 80% of the properties. The rest should most likely be handled as special cases in the code, and not have any information declared about them in mapdata.hs.