Moin moin

Ich habe momentan aus unerklärlichen Gründen das Problem, dass das Programm "ZHLT Compile GUI X²" meint dass ich zu wenig Speicher hätte.
(Komisch daran ist, dass es vorher auch ging. Ich mein vor dem System reinstall)
"Ok" dachte ich mir, dass könnte ja an den Auslangerungsdateien liegen.
Die hab ich gestern von 3,1 auf 4,1GB erhöht --> keine Wirkung!
Dann hab ich das Programm einfach mal von C: auf D: verlagert weil ich auf D: wesendlich mehr Platz als auf C: habe (D: = 30GB) --> keine Wirkung!
Mir ist aber aufgefallen, dass die Auslangerungsdateien gerade mal bis 2,6GB gehen (der arbeitsspeicher ist voll)
Hätte jemand 'ne Ahnung woran das liegen könnte?
Vorher gabs echt keine Probleme, obwohl die Map vor dem sys-reinstall noch größer war (musste vieles löschen etc. weil ich ein paar Fehler in der Map hatte.. Hier der Link zum Problem, dass ich hatte )

Falls es jemanden hilft, mein System:
AMD Ahtlon XP 2600+@ 2400Mhz (ca. 3500+)
2x 80GB Festspeicher
1GB Arbeitsspeicher (DDR400)
Windows XP Pro / SP2

Map-Editor -> Valve Hammer Editor 3.5 Beta
Compile-GUI -> ZHLT Compile GUI X² (incl. Update 2)
Warnmeldung (Loganalyse): "Memory allocation failure"

mFg
PS: Ich hab davon noch ein screen gemacht falls es hilft > Screenshot

Hmm .. nehm mal die normalen compiler statt das Compile GUI und am besten den VHE 3.4 ... damit müsstes klappen

Das ist ein Compiler-Fehler, kein GUI-Fehler.
Offenbar ist deine Map sehr gross. Funktioniert der Compile bei kleineren Maps?

Richman's Hazardous Course - Status: 100% !!!
www.richmans-maps.ch.vu - wieder online!

Ich tippe auch auf zu komplex. Immerhin meldet dein hlrad eine Visibility Matrix von 134.2 Megs
Ich weiss nun nicht, wie gut du dich mit den Compiler-Parametern auskennst, aber es gäbe da eine Lösung diese Matrix drastisch zu reduzieren (allerdings etwas auf Kosten der Optik)
gib bei hlrad einen veränderten -chop Parameter ein, der Standardwert, auch wenn du nichts einträgst, ist 64.
Wenn du diesen verdoppelst, also -chop 128 reduzierst du diese Vismatrix auf nur 1/4 der Grösse. Probiers vielleicht mal einfach aus, die Schattenberechnung wird dadurch etwas gröber natürlich..

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW

OK, ich hab den Wert jetzt auf 128 gestellt und lasse es jetzt nochmal laufen...

Dazu hätte ich aber noch ein paar Fragen:
In welchen Zusammenhang steigt dieser Wert von 134.2 Megs?
Gibt das z.B. die Gesamtfläche von den "Blöcken" (außen und innen) oder den gesamten ... hm... ich sag mal den gesamten "Luftraum" an (Volumen)?

Ich stell diese Frage weil die Map vorher (mit den anderen Warnungen) gerade mal 90 Megs hatte und jetzt wo die Map (eine Halle) wesendlich leerer ist also ohne den ganzen Kram wie Kisten usw. nun 134.2 Megs hat....
Wäre vielleicht hilfreich wenn ich wüsste wie man das niedrig halten könnte, denn ich möchte eigentlich (ist ne concept map) nicht auf die schöne Optik verzichten...

mFg
PS: vielen Danks schon mal für eure Bemühungen.
PS: Wie ich gerade sehe hat die nur noch 25 Megs ^^

genau weiss ich das auch nicht, aber ich denke mal, die Zahl repräsentiert die Anzahl der "in kleine Happen" aufgeteilten Einzelflächen aus der gesamten sichtbaren Oberfläche der Map. Wenn du diese Happen eben grösser machst, gibt es weniger davon zu verwalten und berechnen..der Compilevorgang geht auch wesentlich schneller. Sieht halt auch nicht mehr ganz so gut aus vermutlich.

/Edit: Zoner meint dazu:

Zitat:

-chop #
Set radiosity patch size for normal textures
Each face in the world has a grid projected onto it, and chopped up into a rather coarse set of sample points. These points are patches, and are what hlrad uses to do the bounced lighting calculations. A higher chop sacrifices quality for both speed and memory consumption of hlrad. A lower chop increases the quality at the expense of speed and memory usage.

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW

ok....
Mit 18 Minuten ging das jetzt echt super schnell. Aber das Licht ... naja ich hoffe das ich das noch hinbekomme. Vielleicht hat ja Jemand noch eine Idee wie man die Megs am besten drücken kann ohne dass die Optik darunter leidet (nichts für ungut WareWolf).

mFg

du kannst nicht alles haben. Hey, das ist die HL (Q1) Engine! Du arbeitest bereits an der Grenze des Möglichen, würd ich mal sagen :)
Hier gibts einige gute Mapper, die ohne Tricks komplexe, gut aussehende Maps zaubern, das ist eben die Kunst ;)
k.A. vielleicht hast du auch irgendwelche Microbrushes fabriziert, poste doch mal ein Overview, dann kann man das besser abschätzen ob das Ganze wirklich zu gross ist oder einfach miserables Design..

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW

Zitat:

du kannst nicht alles haben. Hey, das ist die HL (Q1) Engine! Du arbeitest bereits an der Grenze des Möglichen, würd ich mal sagen :)

Zitat:

Hier gibts einige gute Mapper, die ohne Tricks komplexe, gut aussehende Maps zaubern, das ist eben die Kunst ;)

Zitat:

k.A. vielleicht hast du auch irgendwelche Microbrushes fabriziert, poste doch mal ein Overview, dann kann man das besser abschätzen ob das Ganze wirklich zu gross ist oder einfach miserables Design..

mFg

Mädel, sei doch nicht gleich eingeschnappt.
Mit "Tricks" meinte ich eben diese vorgeschlagenen Sachen wie patches vergrössern etc. das macht man vielleicht, wenn man unbedingt nichts weglassen will, aber i.d.R. hat man dann keine Game-Map zum zocken gebaut, sondern irgend einen realistischen Ort der eben genau so aussehen soll.

Und "miserables Design" wäre z.B. eine riesige Sky-Box um den level, damit auch schön alle Rückseiten der Brushes mitberechnet werden, obwohl der Player diese ja nie sieht.

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW

Mädel Oo? nene ist ja ok.. ich war an dem Tag einfach scheisse drauf, entschuldige ^^

Ich werd einfach mal die außenwände etwas dünner machen. Ich denke mal, dass deswegen die Megs so hoch sind.

Falls das mein Problem lösen sollte will ich mich jetzt schon bei allen für die freundliche Hilfe bedanken. Wenn man euch nicht hätte ;)

mFg

Die Aussenwände der Map?
Die werden bei Compilervorgang sowieso weggelassen, dann spielt es keine Rolle, wie dick die sind.

Richman's Hazardous Course - Status: 100% !!!
www.richmans-maps.ch.vu - wieder online!

hab ich leider auch feststellen müssen -,-
Naja immerhin waren es 0.1 Megs die ich dabei eingespart habe ^^

Ok... damit ich es dann auch mal verstehe: Welche Dinge treiben denn nun die Megs in die höhe? Wird das wirklich nur von der sichtbaren Fläche beeinflusst oder gibt es noch andere Faktoren?

Korrigiert mich, wenn ich mich irre, aber IIRC hat die Anzahl der Faces auch einen starken Einfluss. Wenn die Flächen durch komisch geformte angrenzende Brushes vom Compiler zerclippt werden, macht das das Compilieren lahm (und das Spiel erst recht).
VIS kommt auch besser mit rechtwinkliger Architektur klar. Schräg abzweigende Gänge, große Hallen mit kompliziert geformten Decken (Kuppel o.ä.), Räume mit unebenem Boden, unvorsichtig konstruierte Außengelände und alles was sonst irgendwie "irregulär" ist wird von VIS oft sehr suboptimal verarbeitet. Hier helfen meist klug gesetzte HINT-Brushes aus der Patsche (Gibt's ein gutes Tutorial zu).
Ich könnte mir auch gut vorstellen, dass die Anzahl der Visleafs die Größe der Matrix ins Aschgraue katapultiert. Lässt sich durch func_wall für Details und saubere HINT-Brushes meist in dern Griff kriegen.

What, exactly, is the Internet? Basically it is a global network exchanging digitized data in such a way that any computer, anywhere,
that is equipped with a device called a "modem" can make a noise like a duck choking on a kazoo.
- Dave Barry

zeig doch mal einen hammerr-screenshot, ich denke, dass man dann um einiges mehr sagen kann, wie du einsparst.

Resetting politics:
http://www.onlinepartei.eu