Obj ID XYZ is our of range...

In die Konsole:

resize_obj_id_space mit entsprechenden Werten eingeben.

Vorher solltest du vielleicht noch diese hier anwenden:

find_lost_objs
purge_missing_objs

Also meiner dark.cfg konnte ich folgende Wert entnehmen:

obj_min -8192
obj_max 2400
max_refs 14000

EDIT

Oder meintest du wie man ungenutzte Brush-ID's in Objekt-ID's umwandeln kann?

Das ist Computerkonvention. Wenn man eine Zahl auf dem System darstellt, enthält sie auch ein Vorzeichen. Bei 8192 hat man somit die doppelte Anzahl möglicher Objekte. Wenn Du mal in die Hierarchie schaust, stellst Du fest, daß z.B. Sounds immer negatives Vorzeichen haben.

Negative Objekt ID's beziehen sich immer auf den Archetyp, sprich die Objektklassen. Du kannst also in DromEd über 8000 Objektklassen definieren...

EDIT

zappenduster:
Das stimmt leider nicht. Negative ID's repräsentieren immer Archetypen/Objektklassen. Nachzulesen in diversen Papers zu der DarkEngine von Doug Church und auch später von Alex Duran. Wenn du genau hinschaust, wirst du feststellen, dass auch Tische etc. in der Objekthierarchie eine negative ID haben.

Die Anzahl der verwendete Objekte kannst du ganz einfach in DromEd auslesen:

Tools->Object Histogram....ganz unten in der Liste steht die Anzahl

Bist Du sicher, dass Du auch alle Custom Objekte, Sounds, Meshes und Texturen wieder in die entsprechenden Ordner zurückgelegt hast? Diese Fehlermeldung kommt nämlich auch, wenn Dromed eine große Menge von Ressourcen nicht mehr finden kann. Dann landen diese unter Missing als neuer Archetyp.

Ich hatte ja im Grunde genommen nichts anderes behauptet. Ich wollte nur schildern, weshalb man negative Zahlen verwendet.

Allerdings haben bei mir nicht nur Objektklassen negative Zahlen, sondern auch Sound-Objekte (oder sind das auch Klassen?) Z.B. gar9908 = -3023 ...

Alles was du in der Objekthierarchie findest, sind eigenständige Klassen, die jedoch bestimmte Properties von einer Basisklasse erben. Diese Vererbung hangelt sich rekursiv bis zu Basisklasse Object(-1) hoch.
Die Objektklasse Sound(-391) erbt alle Properties von Object(-1). Die Klasse gar9908(-3023) erbt wiederum von Sound usw. usw.

Die Objekt-Hierarchie ist schlichte OOP, man kann also nur Klassen instanzieren, aber keine Objekte.

Und nur aus diesem Grund haben Klassen eine negative ID, damit sie intern vom Objektsystem parallel neben den Objekten verwaltet werden können. Das hat in dem Fall also nichts mit dem darstellbaren Zahlenbereich zu tun, es dient lediglich der Spiellogik. Eine Festlegung wie "alle konkreten Instanzen müssen eine ID > 0 haben" macht die Unterscheidung einfacher und übersichtlicher, da man so auf den ersten Blick sieht, was eine Klasse und was eine konkrete Instanz einer Klasse ist.

Das mit der Vererberei diverser Klassen ist mir schon klar - nutzt man ja gerne, wenn man ein neues Objekt in eine Kathegorie einfügen will. Ich weiß nur nicht, was ein konkreter Sound noch weitervererben könnte. Das ist doch eigentlich das Ende der Kette?

Und man hätte die Unterscheidung natürlich auch so treffen können, indem man einfach diverse Zahlenbereiche fest reserviert. Das mit den negativen Zahlen schreit doch irgendwie nach optimaler Bit-Ausnutzung. Immerhin ist das Spiel ja schon recht betagt, man hat zumindest früher versucht, viel Speicher zu sparen.

Aber offenbar hast Du die Unterlagen recht genau studiert, das ist schon von Vorteil ... wie biste da 'rangekommen?

Genau genommen braucht man nur einmal in die Objekthierarchie hineinzuschauen und ein oder zwei neue Archetypen und Objekte zu erzeugen und man kann sich das auch selbst zusammen reimen.

Zitat

Original von zappenduster
Ich weiß nur nicht, was ein konkreter Sound noch weitervererben könnte. Das ist doch eigentlich das Ende der Kette?

An sich hast du Recht, es macht keinen Sinn einen Sound noch weiter zu spezialisieren. Aber damit man das gleiche System für alles nutzen kann, wurde das eben auch für Sounds so gemacht.

Zitat

Original von zappenduster
Und man hätte die Unterscheidung natürlich auch so treffen können, indem man einfach diverse Zahlenbereiche fest reserviert. Das mit den negativen Zahlen schreit doch irgendwie nach optimaler Bit-Ausnutzung. Immerhin ist das Spiel ja schon recht betagt, man hat zumindest früher versucht, viel Speicher zu sparen.

An sich schon, aber aus meiner Sicht ist der Weg "Klassen < 0, Instanzen > 0" wesentlich übersichtlicher. Wenn man einen anderen Bereich gewählt hätte, z.b. 3128 als Grenze, dann hat man doch weniger Überblick. So wie es bei der DarkEngine ist, sieht der Designer sobald er eine negative Zahl sieht sofort, dass er gerade den Archetyp bearbeitet. Das schützt im Zweifel davor den Archetyp zu überschreiben, obwohl man nur eine Instanz ändern wollte. Wenn man dann erst überlegen muss, ob 3200 jetzt schon eine Instanz, oder doch noch ein Archetpy ist wird das wesentlich unübersichtlicher. Eine negative Zahl springt einem da eher ins Auge wie man so schön sagt

Zitat

Original von zappenduster
Aber offenbar hast Du die Unterlagen recht genau studiert, das ist schon von Vorteil ... wie biste da 'rangekommen?

Das Paper von Doug Church gibts hier:
http://chrishecker.com/images/6/6f/ObjSys.ppt

Das von Alex Duran hab ich eben nicht kostenlos verfügbar gefunden. Da bin ich über Citeseer.com und die Uni rangekommen, an der ich studiere. Aber vielleicht findest du das auch im Netz als freie Version.

Es hat noch einen weiteren Vorteil, wenn man Archetypen und konkrete Objekte auf diese Art anordnet:

Man kann beide Zahlenbereiche beliebig vergrößern (zumindest theoretisch).

Na ob ich mich allzusehr in die Materie hineinvertiefen kann, sei mal dahingestellt. Es dürfte recht komplex sein. Wenn ich mir etwa die Vielzahl der Metaproperties oder Eigenschaften anschaue, die man zumindest theoretisch einem AI verpassen kann, kann man nur erahnen, wie komplex der Quellcode sein muß.
Nicht umsonst gibt es doch jetzt mindestens eine Uni, die einen Studiengang Spieledesign anbietet ...

Zitat

Original von zappenduster
Nicht umsonst gibt es doch jetzt mindestens eine Uni, die einen Studiengang Spieledesign anbietet ...

Naja, nicht dringend. Das was man dazu brauch, lernt man auch alles als Informatiker, egal ob an der Uni oder FH. Für das Objekt-System der DarkEngine braucht man neben relationalen Datenbanken besonders Hashfunktionen und Bäume/Baumtraversen und allerlei Cache-Techniken.
Ich wage fast zu behaupten, dass man unter "Game Design" weniger die eher theoretischen Seiten der Informatik versteht

Hmm... ich glaube nicht, dass das hier noch von nicht Informatikern verstanden wird. Wir haben uns ohnehin recht weit vom Topic entfernt.

Ok, zurück zum Thema:

Wenn das, was Sinister vorgeschlagen hat nicht funktioniert bzw. nicht der Auslöser ist, dann könnte vielleicht nur noch diese Idee helfen, dass man ungenutzte Brush ID's in Objekt ID's konvertiert.
Das habe ich erst vor kurzem in der Editor's Guild gelesen, aber ich finde es nicht mehr.

Wenn von euch jemand weiß wie das geht, oder wo es steht, dann könntet ihr das ja mal hier posten.

Also wenn ihr die mögliche Anzahl der Objekt-Arten ausgegangen ist (was ich nach unserem Telefonat gestern eigentlich nicht vermute) kann sie immer noch irgendeine bestehende Objektarte verwenden und ihr ein anderes Shape verpassen.
Also wenn es ein Einzelstück ist (Beispiel Weinfaß) verfahre ich so, ohne eine eigene 'Klasse' anzulegen.
Bei Objekt-Importen, die mehrfach eingebaut werden wie etwa Fackeln, lege ich eine eigene Klasse mit -# an.

Hat sie dir gesagt, was nach dem Fehler passiert? Falls da dieser Yes/No/Cancel Dialog erscheint, kann ihr geholfen werden. Sie soll dann mal auf "Cancel" drücken und schauen, was in der 1. Zeile des Monologs steht.

Der Hex Wert hinter DromEd caused an Access Violation in module DromEd.exe at interessiert.
Kennen wir den Hex Wert, hilft das hier weiter.
Damit wissen wir dann, in welchem Modul der Fehler verursacht wird (AI, Sound etc.).
Und dann hilft meistens nur noch probieren, sprich der Reihe nach die Objekte des entsprechenden Systems löschen bis man das erwischt, was den Fehler verursacht.