Um euch mal einen Eindruck zu geben was das dann bedeutet:
Fragestellung: Warum crasht meine "UI Improve" Funktion (in der Beta Version)?
(Der Großteil ist in LUA geschrieben und nutzt quasi nur TPF Bordmittel bis auf 4 Funktionen)
Ab geht die Reise:
- Crash in ConstructionList in Lua
- in conlist.patchModelGroups()
- bei commonapi._native.ModelMetadataExt.set( modelId, "uiCommonAPI", uiCommonAPI)
Hmm, aber die MetadataMap sieht doch noch recht gleich aus im Speicher, also weiter:
- schau mir die Code Zeile an: IdRep_Model* idrep_model = ModelMetadataExt_getIdRepModel(), die aufruft:
IdRep_Model* ModelMetadataExt_getIdRepModel() {
if (CGame_CurrentPtr == nullptr) {
return nullptr;
}
ModelRep* modelRep = CGame_CurrentPtr->gameRes->modelRep;
IdRep_Model* idrep_model = &modelRep->modeldata->rep_Model;
return idrep_model;
};
Also wieder mal die Struktur von CGame analysiert:
Wo wird gameRes gesetzt und ist es noch an der selben stelle?
- Analysiert und ja, ist immer noch an der richtigen Stelle.
Also GameRes analysieren:
- GameRes ModelRep ist auch an der gleichen Stelle.
Aber die Speicherallokation für ModelRep ist nun um 24 Bytes größer 
Hier nun mal ein paar C++ Strukturen dazu:
struct ModelRep
{
ModelData *modeldata;
std::vector<std::string> maybeListFilenames;
std::unordered_map<std::string, void*> unknownmap;
};
struct ModelData {
IdRep_Model rep_Model;
IdRep_Mesh rep_Mesh;
IdRep_Animation rep_Animation;
IdRep_Material rep_Material;
};
struct IdRep_Model {
std::unordered_map<std::string, int> name2id;
std::vector<Model*> m_values;
std::vector<std::string> m_names;
std::deque<int> freeids;
};
Alles anzeigen
und das finale geänderte Speicherlayout:
struct ModelRep
{
void* filesystem;
void* unknown[4];
ModelData *modeldata;
std::vector<std::string> maybeListFilenames;
phmap::flat_hash_map<std::string, void*> unknownmap;
};
struct IdRep_Model {
phmap::flat_hash_map<std::string, int> name2id;
std::vector<Model*> m_values;
std::vector<std::string> m_names;
std::deque<int> freeids;
};
Alles anzeigen
Sprich ich muss die neue Position von ModelData *modeldata finden, und die geänderte Funktionalität von IdRep_Model.
Anstatt std::unordered_map name2id;> haben wir nun eine phmap, diese funktioniert anders und hat auch eine andere Speichergröße.
Das hat mich heute den Nachmittag gekostet.
Hätte ich die Header Dateien (bzw. ne Art SDK) wäre das ne Sache von 3 Minuten bzw. würde gar nicht erst passieren.
So Sitze ich da halt Stunden dran. 
Jetzt fragt Ihr euch, das Feature ist ja unwichtig, schalten wir UI Improve ab.
Ok, aber schauen wir doch mal in FlexStreets:
getOverwriteStripeMaterialsNew von mir macht das:
int materialId = CGame_CurrentPtr->gameRes->modelRep->modeldata->rep_Material.GetMaterialId(&extra->materialName);
Das würde natürlich auch Crashen, wenn CGame_CurrentPtr->gameRes->modelRep->modeldata->rep_Material nicht angesprochen wird, sondern irgendwo falsch abbiegt.
D.h. hier müssen 4 Zeiger und Ihre relative Position richtig sein, sonst gibt es Chaos und die Funktionalität einen Namen zu einer Id aufzulösen.
Ich hoffe ich konnte euch einen kleinen Einblick geben, warum das nicht so einfach ist und nicht mit der LUA Seite von TPF2 zu vergleichen ist.
PS: Auch die Pointer validieren bringt meisten nichts, an der Stelle haben wir ggf. nen validen Pointer, der Zeigt nur ggf. auf ne andere Art von Objekt.
Und das wird im Render Code bzw. beim erstellen von Meshdaten aufgerufen, da gibt es keine LUA Runtime...
Einzigster Trost, ich hab während des Code bastelns nicht an andere Sachen denken müssen, das kommt aber nun um so mehr. 
