|
die 10000 warnmeldungen sollten dir eigentlich zu denken geben und beim nächsten mal erst mal den log durch den analyszer schicken:
Compile Log Analyzer - Auswertung
Gefunden: Insgesamt 7 Fehler, davon 4 unterschiedliche(r).
LEAK
Gefunden in:
Zeile 32, Zeile 33
Problem:
Ein LEAK (Leck) ist im Prinzip ein Loch im Level. Wenn man sich vorstellt, man würde seine Map mit Wasser füllen und irgendwo könnte etwas austreten, dann hat man ein LEAK. Die gleiche Meldung erhält man übrigens, wenn sich ein Point-Entity (z.B. light oder info_player_start etc.) außerhalb des umschlossenen Raumes der Map befindet.
Lösung:
Leck finden und schließen, bzw. das den Fehler verursachende Entity in den Innenraum der Map verschieben oder löschen. Bei Problemen, das Leck zu finden, gibt's die "Pointfile-Methode": Dazu muß neben dem mapname.bsp auch das mapname.pts-file (wird während des Kompile-Prozesses erzeugt) im Maps-Ordner von HalfLife sein. Man startet dann HL mit der Befehlszeile hl.exe -dev -console +map mapname.bsp ...und gibt in der Konsole (^-Taste) "pointfile" ein (ohne die Anführungszeichen). Wenn man nun innerhalb oder außerhalb der Map sucht (Konsolenbefehl: noclip 1), findet man eine schwarz-weiß gestrichelte Linie. Diese Linie führt irgendwann aus dem die Map umgebenden "Nichts" durch das Leck in den Innenraum der Map --> Leck gefunden. Falls die Strichellinie zu kurz sein sollte, startet man HL mit folgender Befehlszeile: hl.exe -dev -console -particles 10000 +map mapname.bsp Dadurch wird die Strichellinie länger. Der Maximalwert für "particles" liegt zwischen 15000 und 16000, man kann aber ohne Probleme 20000 angeben, dann wird automatisch das Maximum verwendet. "Pointfile" funktioniert nur im Software-Modus! Weitere Anmerkung: Die Koordinaten die hinter Entity capture_point @ (x, y,z) stehen, sind NICHT die Koordinaten des LEAK! Sie geben nur die Position des Entities an, von dem aus das Leck entdeckt wurde (die Kompiler lokalisieren Lecks von Entities aus).
===
new portal was clipped away
Gefunden in:
Zeile 110, Zeile 175, Zeile 240
Problem:
qbsp.exe hat hier Probleme bei der korrekten Erstellung eines LEAFs, was meist an zu komplizierten Brush-Formen liegt. Solange die Map aber in HL problemlos läuft und die r_speeds (die ja durch die LEAFs entscheidend beeinflusst werden) im grünen Bereich bleiben, kann man diese Warnung meist übergehen.
Lösung:
Bei den angegebenen Koordinaten nach komplexen Formen suchen und diese entweder vereinfachen, oder (wenn möglich) zu func_walls machen.
===
couldn't read
Gefunden in:
Zeile 314
Problem:
Dies ist KEIN Error von VIS. Es bedeutet, daß entweder in QCSG oder QBSP2 ein Problem aufgetreten ist und BSP deshalb das mapname.prt ("portal-file") nicht schreiben konnte, welches von VIS benötigt wird, um die Sichtbarkeitsberechnung korrekt durchführen zu können. Folge dieser Warnung ist, daß die Map nicht optimiert wird, die r_speeds werden vielhöher als nötig. Außerdem wid qrad -wenn überhaupt- nur "notdürftig" ausgeführt.
Lösung:
Vorherige Errors lokalisieren und ausbessern oder ggf. die Pfade in den Worldcraft Einstellungen überprüfe
===
No vising performed.
Gefunden in:
Zeile 315
Problem:
Es wurde kein vising durchgeführt. Beim Vising wird berechnet, wann der Spieler welche Sachen sieht. Diese Meldung ist kein eigentlicher Fehler, sondern signalisiert nur, dass aufgrund eines vorhergehenden Fehlers diese Sichtbarkeitsberechnung nicht durchgeführt werden konnte.
Lösung:
Behebe alle vorhergehenden Fehler
--
|
.
