Also ich wuerde das Problem wahrscheinlich so angehen ..

Ich denke, dass es das beste waere, alle Objekte die ganze Zeit im Speicher zu haben. Bei den heutigen Systemen spielt das auch keine allzugrosse Rolle. Sollte es dabei viel Redundanz geben (z.B. bei Schaltern) koennte man gruppenbasierte Metaobjekte erzeugen und Einzelobjekte simulieren. Wird ein Objekt nicht mehr benötigt, wird es einfach als Speicher freigegeben. Wird ein Objekt noch fuer spaeter benoetigt, wird es im Speicher gehalten.

Was die Sache mit den Scripts angeht, so ist dies eventuell auch recht einfach. Jedes Objekt bekommt eine Eigenschaft, auf welcher Map (oder welchen Maps) es verankert ist. Ist es auf keiner Map verankert, so gibt es dafuer eine spezielle ID. Zudem gibt es eine Messagequeue zum Senden von Botschaften an alle eingetragenen Funktionen. Beim ersten Initialisieren eines Objektes hat das Objekt nun die Moeglichkeit 2 Call-Back-Funktionen als Handler in den Queues einzutragen. So ist es bei den meisten Objekten sinnvoll, dass in die All-Object-Queue ein Handler fuer ein Enter_Map_Event und ein Leave_Map_Event eingetragen wird. Diese Handler pruefen dann die aktuelle Map_ID und registrieren bzw. entfernen weitere Messagehandler in der Queue. Somit brauchen die Scripte nur genau dann Rechenleistung, wenn man sich auf einer Map befindet, auf der sie die Messages ueberhaupt abfragen muessen. Dass dennoch fuer fast jedes Objekt eine CallBack Funktion durchlaufen wird, wenn die Map verlassen oder betreten wird, sollte verschmerzbar sein, da hierbei ohnehin externe Resourcen geladen werden muessen. Die Geschwindigkeit der Messagequeue kann zudem optimiert werden, wenn die Message nicht in den Handlern auf den korrekten Typ ueberprueft wird, was der Fall waere, wuerde die Queue aus Funktionspointern bestehen, sondern wenn stattdessen Structs aus Funktionspointer und einer Liste/einem Array akzeptierter Messages gespeichert wuerden. So lassen sich unnoetige Funktionsspruenge vermeiden. Nicht die IFs, sondern die Calls fressen Resourcen, da damit der Instructioncache des Prozessors unbrauchbar wird.

Was dein anderes Problem angeht, hab ich keine Ahnung, was du genau machen willst. Laut deiner Beschreibung iist doch ein Array von Funktionspointern auf verschiedene Funktionen ganz genau das, was du haben willst. Wieso nutzt dir das nichts ? Oder willst du etwa zur Laufzeit neue Funktionen schreiben und dann deinem Array hinzufuegen ? Dann musst du wohl oder uebel auf dynamisches Linken zurueckgreifen und mit Dlls bzw .so arbeiten. Gib uns am besten mal ein konkretes Beispiel, wofuer du das brauchst. Sicherlich gibt es fuer dich eine elegantere Loesung, z.B. Arrays von Funktionspointern oder Templates ...