Hallo zusammen

Ich habe mal das "Remote Compile Center" ausprobiert. Geht wunderbar bis auf die Texturen, alle texturen zeigt es mir nur so Violett-schwarz an. Woran liegt das? Auf der Webseite heisst es dass alle Texturen die ich benötige vorhanden sind.

Wenn jemand Rechtschreibefehler findet kann sie an die Tageszeitung schicken!!

Diese Violett-Schwarz karrierte Textur bedeutet aber, dass in der Map eine Textur eingebaut wurde, die in den WAD Dateien nicht vorhanden ist.

Rambo Engineer @ Drippy's 2fort - finest TFC 1.5 || Bild Upload || The world's most advanced open source database

Ich habe aber nur Texturen verwendet die in halflife.wad und liquids.wad sind und diese sind beide Auf dem Server

Wenn jemand Rechtschreibefehler findet kann sie an die Tageszeitung schicken!!

dann heißen deine Texturen entweder anders oder befinden sich nicht im richtigen Verzeichnis

http://choerbaert.org
Ein Gespenst geht um im Netz - das Gespenst des Open Source
csndr

genau wie die zhlt.wad ... bei meiner map, die ich da grad kompilieren hab lassen, stehts im log, er findet weder hint noch skip ... hoffe, die kompilierer haben die infos, die in den hint/skip brushes drinstecken, trotzdem gefressen.

wenn nicht, darf das teil halt nochmal kompilieren (rad inzwischen ~76 stunden *g*)

Dann bist du das also der die Maschienen Blockiert. Ich habe in der Zwischnzeil 2 Maps auf "Neptune" Kompiliert. Aber sag mal wieso ist der schon fast 100 stunden am RAD???

Wenn jemand Rechtschreibefehler findet kann sie an die Tageszeitung schicken!!

HLRAD is SLOW/stuck on makescales
HLRAD requires large amounts of memory to run efficiently for all but the most trivial of maps.

The vismatrix hlrad needs to run takes exponentially more RAM as the vismatrix grows. The formula is 'number of patches' squared, then divided by 16. This number is how many bytes it will consume. The maximum is 65535 patches, so the maximum vismatrix is 256Mb of RAM.

Furthermore, the amount of memory the vismatrix uses is not all the memory hlrad needs to run. Depending on the visibility of the map, the 'scales' cache consumes large amounts of memory at once as well. For most maps, this amount of memory is close to 1/2 the size of the vismatrix. This generally equates to a maximum of 128Mb, or a system total of 384Mb to run the worst case (65535 patches) map.

The makescales phase has a tendency to run fast right up until it runs out of physical memory and has to start relying on the swapfile. This is frequently noticeable as makescales running quickly (say 20 minutes) up until the 90% mark, then taking several hours to finish the last 10%. This is always caused by running out of physical memory, and the last 10% work requiring heavy use of the swapfile. If more architecture is added to the map, one can see that it will start taking exponentially longer to compile, until the RAM is upgraded.

Besides simply adding large quantities of RAM to the computer, the fix for this problem is identical to fixing a MAX_PATCHES error. Applying those fixes will reduce the number of patches, and cause HLRAD to need less memory, often speeding up the compile dramatically. If all has been done, there is also the option of using -bounce 0 with HLRAD, and using just direct lighting for test compiles of the map. Ideally one would then using a non-zero -bounce for the final compile.