Neue DromEd-Probleme

Zitat

Original von TypeRED
die ratten brauchen einen flee point auf ihrer höhe, zu dem sie "flitzen" lönnen, keine stufen oder sonstiges sollte dazwischen liegen

Ratten können auch Stufen laufen. Sieht zwar ulkig aus aber es geht (siehe z.B. in Geheimnisvolle Einladung)

Zitat

auch zu beachten gilt, das ratten keine türen benutzen können
kann sein, dass sie selbst bei offenen türen das durchgehen verweigern

Auch das ist ohne Probleme möglich. Es ist lediglich eine kleine Einstellung "Uses Doors" in den Properties notwendig.

Schattengilde:
Hast Du die Ratte vielleicht in einen Käfig eingesperrt, oder sitzt sie in einem Mauseloch? Kurz: ist der Platz an dem sie sitzt zu klein, als dass eine normale Wache an der selben Stelle durchlaufen könnte? In dem Falle sind einige Tricks notwendig, damit die Berechnung der Pathfinding-Database an der Stelle klappt.

Das mit der Wache muß ich erst mal probieren, könnte u.U. aber kritisch werden, da die begehbare Fläche recht schmal ist. Allerdings ist PathfindingDB noch nicht aktualisiert, liegt vielleicht auch daran.

EDIT:
Eine Wache kann problemlos patrouillieren, auch ohne Pathfinding DB zu aktualisieren. Die Ratte will aber auch nach komplettem Durchrechnen lassen nicht. Und sie läßt sich - im Gegensatz zu Ratten in OMs - auch nicht töten, sie ist für Pfeil/Schwert durchlässig.

EDIT2:
Die Sache mit dem redenden und sich bewegenden AI klappt perfekt :D, danke für den Link Sinistreshadow. Aber die Ratte will absolut nicht............

Mal ne Frage zu AIs:
Welche Einstellung muss ich den bei einer Wache vornehmen, damit man sie nur k.o schlagen kann, wenn man den Hinterkopf trifft (also nix mit nach vorne lehnen und draufkloppen )

Liebe Gemeinde, ich hätt da gern mal 'ne Frage:

Und zwar geschieht es bei mir immer öfter, daß DromEd beim Portalize- oder Full Mission Processing-Vorgang nicht abstürzt aber hängenbleibt (Quick Lighting geht). Mir bleibt dann nur, den Windoofs-Prozeß abzubrechen und DromEd neu zu starten.
Und das blöderweise jetzt, wo ich fast fertig bin und nicht mehr einzelne Aereas sondern das Ganze durchtesten will (ich muß eigentlich nur noch Missionsziele und externe Objekte einbinden).

An der Statuszeile unten sieht man ja die (bis dahin) laufende Aktivität, auch monolog.txt zeigt am Dateiende, wo es klemmt:
ObjAnimLightLevel starting out ... 278.1583.1430.779.520.117.771.130.608.258.55.240.1112.[1754].1145.1336.[1696].609.[365].97.1178.310.1050.247.677.[372].1119.820.823.614.553.221.[374].[1719].1347.1125.[1738].1264.493.1207.631.1310.307.734.1159.[1442].250.636.829.44.251.552.1334.835.1267.1820.1132.703.912.[1716].[1505].[1630].710.255.1094.[1633].625.1328.622.304.867.301.1403.621.[387].1304.298.267.1591.1191.[408].838.[1624].844.1479.864.1138.[1512].961.252.514.233.1086.858.286.1101.[362].870.1339.671.1038.[1194].[1722].[1699].1308.1142.30.1126.1122.832.861.950.277.941.110.817.1424.[1521].1162.377.1149.1789.919.

Woran kann das liegen? In den Foren habe ich nix dazu gefunden, auch nicht über Begrenzungen der Lichter-Anzahl. Ich habe schon widerwillig einige Fackeln gegen Hängekerzen ersetzt, die ja nicht animiert sind, aber dann hängt das §$%&*-Ding eben an einer anderen Fackel fest. Und ich habe die Lichter auch so 'installiert', daß sie präzise an den Brushes hängen.

Hast Du Deinen Lichtquellen vernünftige Radien gegeben?

Es ist nämlich dummerweise so, dass Dromed von sich aus erst mal jeder Lichtquelle eine unbegrenzte Leuchtweite gibt. Das heißt für jede Lichtquelle muss Dromed umständlich bis in die letzten Ritzen Deiner Mission die Beleuchtungsstärke berechnen. Und das dauert eben (zum Teil mehrere Stunden oder Tage). Du kannst in den Eigenschaften jeder Lichtquelle deren Ausbreitungsweite durch einen Radius begrenzen. Dann rechnet Dromed nur noch bis zum Erreichen dieses Radius, was das Durchrechnen enorm beschleunigt. Dies hat dann auch den Vorteil, dass man in Dunklen Ecken Deiner Mission auch tatsächlich voll getarnt ist, während es, wenn Du die Radien nicht setzt, immer nur eine teilweise Tarnung gibt, auch wenn Du in absoluter Dunkelheit zu stehen scheinst. Der Sichtbarkeitsstein wird einfach nie richtig dunkel.

Die Kunst ist es nun, die Radien so zu wählen, dass man den Unterschied optisch nicht bemerkt (also keine harten "Lichtkugeln" um eine Lichtquelle entstehen) und dennoch die Radien klein genug sind, um im Dunklen auch im Sinne von Tarnung wirkliche Dunkelheit zu haben.

Hallo, schnelle Rea!

Meine Fackeln haben nur 1/3 Leuchtstärke und flackern, also richtig mittelalterlich-zappenduster. Aber gerade den Radius-Parameter habe ich bisher nicht angetastet, er steht tatsächlich bei allen auf 0 (also infinite), wie es das System standardmäßig bereitstellt.
Welcher Wert wäre realistisch? Man sieht aber doch die Flamme dann trotzdem aus weiterer Entfernung? Ich werde mal ein wenig herumexperimentieren.

Trotzdem ist es für mich unerklärlich, daß DromEd den Prozeß immer bei einem Lichtobjekt abbricht, wie man bei monolog.txt sehen kann. Und daß er bei kleineren Aeras anstandslos und schnell durchportiert, spricht gegen die Annahme ... ich versuche es nachher mal und werde berichten ...

Wie weit der Radius sein muss, hängt ein wenig davon ab, wie hoch die Lichtintensität ist und wie die Umgebung aussieht. Musst Du einfach mal ein wenig rumprobieren, bis es gut aussieht.

Falls es immer an der selben Stelle festhängt, lösch diese Fackel mal und bau eine neue hin. Vielleicht geht's dann ja besser.

Zitat

Original von SinisterShadow
Wie weit der Radius sein muss, hängt ein wenig davon ab, wie hoch die Lichtintensität ist und wie die Umgebung aussieht. Musst Du einfach mal ein wenig rumprobieren, bis es gut aussieht.

Ja vielen Dank, das war's ganz offensichtlich. Es ist übrigens machmal auffällig, wie das Licht 'durch Mauern' zu gehen scheint ...

Zitat

Original von SinisterShadow
Falls es immer an der selben Stelle festhängt, lösch diese Fackel mal und bau eine neue hin. Vielleicht geht's dann ja besser.

Nee nee, das war ein allgemeines Problem, das sich durch die gesamte Missi zog.

Hast Du Object cast lighting verwendet?

Zitat

Original von SinisterShadow
Hast Du Object cast lighting verwendet?

Hoppla, das sagt mir jetzt nichts ... in welchem Zusammenhang?

Es gibt drei Stufen der Beleuchtungsgenauigkeit.

• Quick Lighting Einfachste Beleuchngsberechnung - Wände und Objekte werden komplett ignoriert. (hier scheint das Licht durch Wände hindurch)
• Raycast Lighting - das Licht beachtet hier die Wände (Solid-Brushes) Objekte werden aber weiterhin ignoriert
• Object Cast Lighting - auch statische Objekte werden bei der Beleuchtungsberechnung beachtet (dies ist die genaueste - aber auch langsamste Berechnungsmethode)

Du kannst diese Beleuchtungsstufen im Menü unter Tools auswählen.

Während des Baus einer Mission kannst du Quick Lighting verwenden, vor einem Release solltest Du aber einmal Object Cast Lighting durchrechnen lassen. Komags Menüs machen das automatisch, wenn Du auf Full Mission Processing gehst.

Ach so, nun weiß ich, was Du meinst ... Full Mission Processing läuft bei mir mehrmals an einem Entwicklungs-Tag, um alles zu optimieren.

Aber wie gesagt, jetzt läuft dieser Prozess wieder reibungslos und auch vergleichsweise zügig durch.

Hallo zusammen,

ich nutze Windows Vista 64 Bit. Folgendes Problem hatte ich zuvor nie:

Ablauf:
1. Ich starte Dromed
2. Ich lade die Mission
3. Ich springe in den Game Mode (mit ALT + G)
4. Ich gehe in den Editor zurück (mit ALT + E)
- bisher alles perfekt
5. ich gehe nochmals in den Game Mode - Absturz
--> diese Typische Vista-Medlung (siehe Bild anbei).

Was ist denn nu wieder? *seufz*

(Portalize etc. funktioniert alles in jeder Kombination und ich kann auch ausschließen, dass es was damit zu tun hat)

Vielleicht kennt Ihr das Problem? Danke Euch.

- Warcus

Das passiert bei mir auch seit dem ich ddfix für Dromed verwende. Meines Wissens lässt sich das z.Zt. nicht vermeiden.

Hm ... so langsam habe ich fertig mit meiner Mission ... könnten sich mal 1-2 weitere Alphatester melden. Die Missionsziele müssen aber noch eingebaut werden.

Was ich vorher noch klären muß, sind folgende Dinge:

Was bedeuten die Angaben in der MERGE000.LOG?
Knapp 30 Meldungen wie brush pair 353 127 ... ich kann in den Brushes aber nichts auffälliges erkennen, sie liegen z.T auch weit auseinander und sind jeweils einfach.

WARNING: Memory allocation suspiciously high (67141588 bytes)!
Haben so ziemlich alle FMs in der MONOLOG.TXT, aber weshalb?

Meine Missie ruckelt ein wenig, andere FMs laufen tadellos.
Umfang:
979 Terrain
1878 Object
56 Light
398 Room
Optimierte Version etwa 9,5 MB
show_stats liefert keine besorgniserregenden Angaben über 250, das Verhalten zeigt sich auch bei Sichtpositionen ohne viele Polys.
Alle Brushes sind eingerastet, und zwar zu 85% mit Raster 14, der Rest mit 13 und wenige 12.
Ich habe allerdings viele neue Texturen konvertiert bzw. erstellt ... ist das die Ursache?

Wie im anderen Thread erwähnt, hatte ich den Fackel-Verdoppler-Fehler ... habe jetzt wohl endlich die Dubletten wieder 'raus. Gibt es eine Möglichkeit, sich das sicher anzeigen zu lassen? Per list_obj hatte ich alle Objekte mit hoher Nummer geprüft und z.T. eliminiert, wenn doppelt. Seeeehr hilfreich -äh- mühsam ...

Mal sehen, ob mir noch Unklarheiten einfallen ...

kannst Du mal Deine komplette monolog.txt irgendwo (z.B. bei ) hochladen und den Link hier posten?

Bestehen viele Deiner Objekte aus z.B. Bäumen mit vielen Polygonen, die dazu noch in größeren Mengen gleichzeitig sichtbar sind? Diese Polygone werden in den Stats nicht mitgezählt, haben aber einen großen Einfluss auf die Framerate.

Für das Problem mit den Fackeln, kannst Du eigentlich nur diese im Spiel selbst "händisch" zählen und anschließend mit den von Dromed gezählten vergleichen:

• Einmal durch die FM laufen und die Fackeln auf dem Weg zählen. (Hilfreich ist hier, wenn sie zuvor alle an sind und Du sie mit Wasserpfeilen aus schießen kannst - so weißt Du welche Du schon gezählt hast und welche noch nicht. Gegebenenfalls gib Dir vorher temporär ausreichend viele Wasserpfeile.)
• anschließend vergleiche die gezählten Fackeln mit denen aus der Object-Histogramm bzw. dem List-Objects. Bei einer Differenz wirst Du dann leider alle einzeln löschen müssen, um diejenige zu finden, die noch doppelt vorhanden sind:
• Dazu: Mission neu laden
• hilight_obj_type torches
• hilight_render
• jede der gelben Felder in den 2D-Ansichten von Dromed auswählen und löschen, wenn dabei an der selben Stelle noch eine weitere Fackel verbleibt, hast Du eine doppelte Stelle gefunden, notier Dir dann dessen Obj-Nummer und mach weiter mit Schritt 6
• wenn Du alle doppelten Fackeln auf diese Art gefunden hast, lade Deine Mission neu (hier sind dann wieder alle Fackeln doppelt vorhanden)
• nun gibst Du für jede doppelt gefundene Fackel (Du hast Dir ja all deren Obj-IDs gemerkt) ein find_obj <objektid> ein (ersetze <objektid> durch die jeweils gemerkte Object-ID) und lösch das so markierte Objekt
• speichere Deine Mission ab (am besten neuen Namen/Versionsnummer im Dateinamen verwenden)
• Optimier die Mission und speichere sie nochmals ab.

Was man ggf. auch mal versuchen könnte: die Generate Report Funktion für Objekte zu nutzen, und schauen, ob dort mehrere Fackeln mit jeweils gleichen Koordinaten auftreten.

Ich denke, das mit den Fackeln per se ist das geringste Problem. Ich kann sie ja mit dem Filter Lights alleine darstellen und abchecken, es sind nicht allzuviele.
Schlimmer ist, daß sich auch viele normale Objekte von AI bis Tisch wahllos verdoppelt und verdreifacht hatten ... hatte ja keine Ahnung von dem Bug. Ja und die 'rauszufinden war schwer. Ich kann nicht ausschließen, daß noch welche drin sind.

Habe mal in der Kommandoauswahl geschaut ... Du meinst do_report?
Den habe ich mal probiert ... uff, jetzt habe ich was zu lesen, mal sehen, ob da sachdienliche Hinweise kommen ...

Nee, Bäume und Büsche habe ich nur an 2 Stellen und dort auch dicht beieinander ... es ruckelt kontinuierlich über die ganze Missie.
Extrakt der Mono poste ich mal 'rein, jetzt schau ich erst mal über die DEFAULT.REP ...

Bei mir ist die Reportfunktion als eigener Menüpunkt vorhanden. Mag sein, dass es sich hierbei um einen Eintrag aus Komags Menüs handelt. Du kannst damit auch die Ausgabe des Reports auf das einschränken, was Du haben willst.

Wegen der langsamen Geschwindigkeit: Hast Du vielleicht irgendwo Partikel-Objekte eingesetzt oder vielleicht alle Wachen auf Never-Efficient gestellt? Sind irgendwo noch Objekte, die die Deathstage Eigenschaft besitzen (hilight_by_prop deathstage), obwohl sie sie nicht haben sollten?