Hallo eratmal,

ich hab nen Leak, wo kein Leak ist. Klingt komisch, is aber aber so...

Ich glaube, dafür gibts wahrscheinlich keine Lösung. Aber ich kann euch erzählen, wie dieser "Leak" zustande kommt. Dürft gerne ruhig selber ausprobieren. Wer doch ne Lösung weiss, immer her damit...

Also, ich neige dazu Worldbrushes gerne mal "ausserhalb der Map" auszulagern. Blöche, Konstruktionen ect. pp. Natürlich nicht so weit ausserhalb, wo es keine Gitter mehr gibt - is klar. Kann ja sein, das man bestimmte Blöcke oder Konstruktionen nochmal benötigt und kann dann natürlich praktisch mit Copy&Paste reinbasteln.

Bei nen Final-Compile macht man natürlich auch alles (ausserhalb der Map) wech. Auch soweit kein Problem. Bisher hat sowas auch keine Probeme verursacht.

Nun sitze ich über einen etwas längeren Zeitraum an einer Map. Immer wieder auch fein Zwischengespeichert. Ich Nummeriere bei Mapwntsicklungen die zwischengespeicherten Maps. Die aktuellste Version ist natürlich die mit der "höchsten Zahl" (Beispiel: mapname_blabla_nx22a ist aktueller als mapname_blabla_nx10d). Grob gesagt, bin ich grad bei nx30a (daher etwa 30 Tage dran gearbeitet -so immer ca. 2 Stunden / je nach Lust und Laune-). Das heisst, ich habe bestimmt (!niedriggeschätzt!) schon 60 mal Zwischengespeichert (wenn man von einem Zwischenspeichern pro Stunde ausgeht).

Das Compilen funktionierte auch immer soweit Einwandfrei (Ich machs per Batch-Datei). Doch nu ist die Map ja nen bissl größer geworden und da dachte ich mir, um Compilezeit zu sparen: Ach, weisste was - lösch doch einfach das "Ausgelagerte" und spare Compilezeit.

Gedacht getan. Und schupps: Leak!!!

Häääää???

Mit "Ausgelagerten Blöcken und Konstruktionen" = alles Ok!
Ohne/Gelöschte "Ausgelagerte Blöcke u. Konstruktionen" = Leak????

Egal ob mit ZHLT oder SHLT.

Mit ein bisschen Rum-Experimentieren habe ich festgestellt, das die "älteren Maps", wenn man das Ausgelagerte löscht, der Compile keine Probleme verursacht. Maps jüngeren Datums verursachen die Probs.

Gut, habe ich mal alles Schritt für Schritt gelöscht und getestet, ob der Compile läuft. Am Ende ist sage und schreibe ein einziger Block übrig geblieben. Sobald man diesen "letzten Block" löscht, dann gibt nen Leak. *staun*

Ok, habe ich mir gedacht, offensichtlich scheint sich ja "irgendetwas" beim Speichern (immer im RMF-Format) oder beim Speichern (für den Compile ins MAP-Format) geändert zu haben. Aber nix da, Aufbau und Struktur sind im Vergleich zu den "älteren Maps" soweit gleich. Keine Auffälligkeiten entdeckt.

Ok, dachte ich mir und schnappe ich mir mal die MAP-Datei und werde den "Block" Hardcoded löschen. Die Zeilen für diesen Block gefunden und wech damit.

Tja, leider ohne Erfolg, egal ob per Hammer oder per Editor den Blöck gelöscht, gibts nen Leak.

Komisch oder? ich habe dafür echt keine Erklärung bzw. is mir nen Rätsel.

Naja, ich hab den Block jetzt mit NULL-Textur belegt und habe daraus eine Lehre gezogen: Zukünftig werde ich "ausgelagerte Blöcke / Konstruktionen in einer "Extra-RMF-Datei ablegen" und ggf. dann hin und her switchen, wenn ich mal was brauch.

Vielleicht kennt jemand dieses Problem (meine Suche hat leider nichts derartiges gebracht) schon und hat zufällig ne Lösung Parat?

Euer Phoenics

Vielleicht mit irgendetwas anderem gegroupt ohne es zu merken? Dann wird das andere evtl so mit gelöscht wenn du den Block löscht. Wäre so meine erste spontane Idee.

keine referal links bei thewall.de --dp

sagt alt-p was?

Nur die, welche sich für ganz stark und extra erwachsen halten trinken Kaffee ohne Milch. Das sind meist auch die Leute, welche rassistisch und homophob sind. Da Rassismus von Minderwertigkeitsgefühlen und Homophobie von latenter Homosexualität stammt, trinken also nur ängstliche Schwule Kaffee ohne Milch. Das wurde wissenschaftlich durch Galileo auf Pro7 bewiesen.

@Skeleton: Naja, daran habe ich auch gedacht. Es gab zwar "gegroupte Konstruktionen", aber die haben keinen Fehler ausgelöst. Habe dehalb sicherheitshalber auch die ganze Map durchgeschaut, ob es vielleicht mit etwas innerhalb der Map gegroupt ist. Isses aber nicht.

Wäre auch nur zu schön gewesen und wahr zu sein, denn dann wäre es kein Problem, die Teile zu löschen und das "mitgegroupten Teil" innerhalb der Maps zu ersetzen.

@Skuldoon: Daran habe ich noch garnicht gedacht. Aber alles in Butter. Nix Invalid oder sonstiges. Auch nix zu Fixen.

Ach ja, ich habe mir vorhin gedacht: Was solls, nehm ich den Block und bastel den innerhalb der Map rein - sollte ja nich so wild sein... Pustekuchen... sobald ich den Block inenrhalb der Map habe, gibts Leak. Verschiebe und verforme ich den Block ausserhalb der Map, meckert nix.

Komisch oder?

Ach ja, ich denke, der Fehler ist reproduzierbar. Einfach zig-mal irgendeine Map unter verschiedenen Namen genügend speichern. Dann irgenwann mal nach den 100.sten Speichern Blöcke "ausserhalb der Map" löschen und ins MAP-Format speichern. Dann darf sich jeder einem "unlogischem Leak" erfreuen... ;)

Euer Phoenics

Ist deine map irgendwie unmoralisch gebaut? Zb extrem detailiert, oder RIESIGE Räume?

Spielen: Prison, Ispatel 4: Classic, Heart of evil
Anschauen: Spirit of Half-Life: Legion

The Trap ist mit abstand die fantastischste Mod die ich seit langem gespielt habe!

Eine Unmoralische Map... ;)

Nö, eigentlich nicht. Es gibt zwar ein "recht grosses Gebilde" (832w 808l 640w). Aber dann hätte es schon vorher ne Fehlermeldung ausgespuckt. Aber dann logischerweise nicht als Leak. - Ich verstehe allerdings da auch nicht wirklich einen möglichen Zusammenhang.

Naja, Shit-Happens. Bleibt der blöde Block halt da wo er is - und gut is...

Nachtrag: Es ist bestimmt nen komisches Gefühl irgendwann einmal auf einem Server durch die eigene Map zu laufen und zu wissen: Es gibt Sie... Irgendwo da draussen gibt es etwas... Naja, Fehler machen ja auch Kreativ. Ich denke, ich bastle einfach "da draussen" an der Stelle etwas nettes. Wer den "Raum" dann irgendwann findet, der kriegt nen Lolli (oder nen Eis!) von mir: Versprochen! :)))

Euer Phoenics

hast du dir mal das pointfile ageschaut wo das leak sein soll?

Na, selbstverständlich. Ich bin ja zuvor erst wirklich von einem Leak ausgegangen, ohne zu wissen, das der gelöschte Block "ausserhalb" dafür Verantwortlich war.

Zuerst dachte ich, das ich tatsächlich ein Leak hätte - ein sog. Microleak. Nachdem ich den Wirrwar an Linien verfolgt habe und alles mögliche geprüft und sogar doppelt-und-dreifach dicht gemacht habe und am Ende sogar alles per Block-Methode (voller Sky-Block rund um die Map) und dann immernoch ne Leak ausspuckte habe ich irgendwann gemerkt, das ich kein Leak habe und das es an den "ausgelagerten Blöcken" lag. Genauergesagt war und ist dafür ein (siehe oben) ein einzelner Bock ausserhalb der Map verantwortlich gewesen.

Mit Block = Compile ok.
Block gelöscht = Leak-Meldung.

Das kuriose ist ja ebend, das dieser o.g. Block eigentlich gar kein Einfluss beim Compile bzgl. Leak-Meldungen haben dürfte. Warum dieser Block ne Leak-Meldung verursacht ist für mich nicht Nachvollziehbar bzw. is mir nen Rätsel.

Wer Interesse hat und sich selbst Vergewissern will, dem kann ich gerne die Map einmal "mit Block" und einmal "ohne Block" schicken.

Euer Phoenics

yo! Schick mir mal an the-middleman@gmx.de

Spielen: Prison, Ispatel 4: Classic, Heart of evil
Anschauen: Spirit of Half-Life: Legion

The Trap ist mit abstand die fantastischste Mod die ich seit langem gespielt habe!

Jup. Gerne.

E-Mail is raus (Name: map_mit_block_compile_ok und map_ohne_block_compile_leak - einmal als RMF- und einmal als MAP-Datei).

In der Top-Ansicht siehst Du den Block etwa auf Position 2200, 3000.

Entfernst Du diesen Block, gibt nen Leak. 8)

Ach ja, ich hab mir gleich die Mühe gemacht, ne kleine Wad dazu zulegen damit im Hammer nicht alles "Schwarz-Weiss" bzw. nackig aussieht. Und angemerkt, Map is noch im Alpha-Satdium - daher noch nicht so viel drin.

Viel Spass damit. Vielleicht fällt dir ja was dabei auf bzw. ein.

Euer Phoenics

schicks mir mal acuh ich knobel gerne:P
email per pm

Liegt vielleicht innerhalb des Blocks ein Entity, das nach dem Löschen dem Void exponiert ist?

Hast du evtl. leere Entities (würde bei Alt-P angezeigt) oder leere Brushes?
Um diese zu finden, müsstest du erst den Mittelpunkt des Grids (0,0,0) frei von normalen Brushes und Objekten machen. Wähle diese einzeln aus, ohne den Markierungsrahmen zu verwenden, und lass sie ausblenden (oder löschen, Backups vorausgesetzt).
Dann ziehst du einen Markierungsrahmen um den Mittelpunkt. Sollte nun ein Objekt ausgewählt sein, das nicht reale Dimensionen hat (du siehts in der Statusleiste von Hammer Angaben mit -1999999999 o.ä.) lösch es, und versuchs nochmal.

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

Du hast doch unmoralisch gemappt. Siehe auch Vatikan mapping guide Seite 1042.

Das Problem ist der große leere Luftraum in deiner map. Füge einfach ein paar sky brushes in diesen ein. Sie beeinflussen weder das gameplay noch die Optik der map und das Problem ist gelöst.

Spielen: Prison, Ispatel 4: Classic, Heart of evil
Anschauen: Spirit of Half-Life: Legion

The Trap ist mit abstand die fantastischste Mod die ich seit langem gespielt habe!

@middleman: Jup, um die Übersicht (im Hammer) zu behalten, habe ich eher ein "grossen Sky" benutzt. Eigentlich meine Übliche Vorgehensweise. Am Ende, wenn es um den Final-Compile geht, entferne ich die grosse Skybox und passe Sie auch dementsprechend bzw. mache Sie deutlich, deutlich, deutlich kleiner (um ebend die og. "unnötigen, leeren Lufträume" zu vermeiden.

Ich werds aber gleich mal ausprobieren den Sky zu verkleinern, ob das die Ursache für den Leak is und sich der Block dann auch entfernen lässt.

PS: Der "Vatikan Mapping Guide" ist mir leider nicht bekannt. Es gibt ja mehrere Guide's bzgl. Mapping.

@Richman: Nope, im Block kein Entity. Aber ich probiers auch mal aus.

@bloodsch: Mail is Unterwegs.

Euer Phoenics

Hab es schon ausprobiert. Die map lasst sich wunderbar compilen, wenn du den sky raum verkleinerst.

Compiler mögen einfach keine überdimensionalen leeren Räume und produzieren dann ein leak. Umso erstaunlicher dass dein nullbrush am anderen Ende der map diesen Fehler behebt o_O Eigentlich ist es das schlauste ihn da zu lassen. Scheint eine Elegante Lösung des Problems zu sein.

Spielen: Prison, Ispatel 4: Classic, Heart of evil
Anschauen: Spirit of Half-Life: Legion

The Trap ist mit abstand die fantastischste Mod die ich seit langem gespielt habe!

Hm. Du denkst, es ist umgekehrt. Der aussherhalb der Map existierende "Block behebt den Leak" bzw. hat einen Leak (aufgrund zu grossem Raum) verhindert?

Wenn das stimmt - das müsste man dann mal genauer Prüfen... dann... dann wären Out-Door-Maps zukünftig eigentlich kein Problem mehr... das wäre cool...

PS: Bin grad noch am Probieren und Compile gerade mit/ohne Block und deutlich verkleinerten Sky... bin gespannt...

Euer Phoenics

Mir schwebt da grad in Gedanken eine Adaption der Battlefield2 Map "Wake Island" vor (wenn Speeds ect. pp. mitmachen *bigsmile*)...

Wenn Du nichts dagegen hast und diese Map irgendwann einmal fettich is, dann würde ich dich, the-middleman, gerne in die Credits aufnehmen - mit Besten Dank für die Hilfe!

So, meine Compiles sind fertig. Habe den Sky verkleinert, Entitys nach "innen" versetzt und sogar HINT-Brushes gesetzt (einmal mit und einmal ohne Aussen-Block). Allerdings kann ich dein Ergebnis momentan noch nicht ganz bestätigen. Auch bei "kleineren Sky" erhalte ich Leak-Meldung, wenn der Block weg ist.

Kannst Du mir mal zu Vergleich deine RMF- und MAP-Datei schicken (E-Mail-Adresse hast Du ja)? Vielleicht habe ich auch einfach nur die HIN-Brushes blöd gesetzt... ich werd Morgen mal weiterschauen...

Euer Phoenics

es hat nichts mit alle dem zu tun
einfach die blöcke außerhalb löschen und mit pointfile nach dem leak suchen...

aber zuersteinmal ein paar anmerkungen zu deinem mapping stil:
man baut keine blöcke aus 1unit
baue wände aus 16/32units die man acuh klar erkennen kann im editor dann gestaltet sich die fehlersuche nciht so schwer
1unit brushes mit schrägen zusammen sind etwas was man absolut vermeiden sollte
schräge sachen sind sowieso nicht die stärke der cs engine deswegen sollte man dort speziell erst recht keine 1uint brushes verwenden
es ist btw acuh sinnlos die außerareale der map mit null textur zu bekleistern udn diese auf 4096 hochzuskalen, lass einfach die normale textur dann erkennt man auch was im editor, um die visibility kümmert sich schon der compiler

nun zur map im speziellen
ich habe alle sachen außerhalb gelöscht(zwei brushes)
mittels pointfile vom player_start verfolgen und irgeendwann stößt man durch diesen brush(trapezförmige 1unit decke die auu angeschrägten seitenwänden steht!!!!!111)
das wurde auch isntant mit einem leak bestraft vom compiler
habe mal ein bild gemacht
http://www.pic-upload.de/view-9332510/Neu-Bitmap.jpg.html
einfache lösung:
trapezdecke zu einem quader geformt und die seitenwände ebenfalls schrägung weggenommen
tada
hier nochmal die .map wers net glaubt
http://www.file-upload.net/download-3306937/map_mit_block_compile_ok.map.html
mfg pwl

Jup. Ich kanns bestätigen.

Das is ja ne Katastrophe, die ich speziell an dieser Stelle gebastelt hab.

Aber ich möchte zu meiner Entlastung nur nochmal erwähnen, das das ganze ja noch nicht einmal im "Alpha-Stadium" war.

Jup. Ich scale Aussenseiten mit 4096-Null-Textur. Ich habe irgendwann mal festgestellt, das dies ein paar Speeds einspart (glaub, das warn Zufall). Ist minimal, aber es klappt (erstaunlicherweise). Daher habs ich mir angewöhnt.

Gut 1 Unit Blöcke sind natürlich nich so doll. *voll-zustimm* Besonders bei "Konstruktionen" und für Blöcke, die an Aussenbereiche grenzen werde ich mich diesbezüglich umstellen.

Das erklärt auch, warum das "Verkleinern" des Sky-Raums nicht alleine das gewünschte Resultat erbracht hat.

Dennoch wirft es die Frage bzw. das Ergebnis von the-middleman auf, wieso der Block dann ein Leak verhindert hat. Ist doch seltsam...

Ach PS an bloodsch: Nö, bin dir nicht böse. Bin dir Dankbar für deine Hilfe.

Euer Phoenics

Nur, um nochmal damit ("uralte Legende") aufzuräumen:

Beim Outdoor-Mapping ist die HL-Engine sehr schwach, weil sie nicht darauf ausgelegt ist. Da helfen auch keine Tricks, um größere Areale hinzupfuschen, die Sichtbarkeitsberechnungen beim Compilevorgang sorgen dafür, dass die Map ingame später unspielbar wird. Hängt mit der Binary Space Partition zusammen, und mit dem, was die Visibility daraus noch so macht. Engines wie z.B. die UT-Engine sind für sowas ausgelegt, die benutzen da andere Verfahren.
Wenn man jetzt doch mal Aussenareale dabei hat, dann gibt es 2 Ansätze, um Speeds zu sparen: NULL auf nicht sichtbaren Flächen und Hochskalieren von Texturen. Um das sinnvoll einsetzen zu können, sollte man aber wissen, wofür sich was davon überhaupt lohnt.

(a) NULL-Textur für nicht sichtbare Flächen.
Alle Flächen, die direkt aufeinander liegen oder ins Void zeigen, werden vom Compiler sowieso entfernt. Die BSP enthält keine Blöcke mehr, sondern nur noch Flächen und die Einteilung des begehbaren Raums (daher braucht man btw auch die Skybox). Die einzigen unsichtbaren Flächen, die es jetzt also noch gibt, sind solche, die z.B. immer garantiert über dem Player liegen und nach oben zeigen, wie bspw. Oberseiten von Deckenträgern, die der Spieler unter normalen Bedingungen nicht sehen kann. Dort kann man die NULL-Textur nutzen, um Speeds zu sparen. Genauso auf Rückseiten von gebrushten Objekten ausserhalb des vom Spieler begehbaren Bereichs, z.B. Felsen o.ä.
Die NULL-Textur zu skalieren macht gar keinen Sinn, da allein ihre Existenz auf einer Fläche diese komplett aus der Map entfernt.

(b) Hochskalieren von Texturen.
Die Einteilung von Flächen in Teilstücke wird von CSG so vorgenommen, dass alle 224 Texel ein Schnitt auf der Fläche erfolgt. Das richtet sich nicht nach weltlichen Einheiten, sondern hängt also mit der Skalierung der Textur zusammen. Das ist übrigens auch der Grund, warum man niemals große Texturen nutzen sollte, um kleine Details auszustatten, z.B. auf ein offenes Rohrende. Das steigert die Speeds -- sieht man auch mit gl_wireframe. Jetzt gibt es ggf. Aussenareale, die der Spieler nicht begehen kann, und die er nur aus der Entfernung sieht, die allerdings keine NULL-Textur vertragen, weil sie eben sichtbar sind. Und vielleicht auch, weil sie nebensächlich Bullets blocken sollen, afair tut NULL das nämlich auch nicht. Dort lohnt sich ein Hochskalieren, um die 224er-Schnitte weiter auseinander zu ziehen und so weniger Teilflächen zu erzeugen, was die Speeds in kritischen Bereichen etwas senken kann.

Dazu auch die beiden rSpeeds-Artikel aus der Tutorials-Sektion hier bei TheWall.de. Bitte werft nicht die ganzen Konzepte und Begründungen durcheinander, das führt nur wieder zu weiteren Fehlern und zu mehr Leuten, die nicht wissen wie sie mit der Engine umgehen können. :)

Weiterhin sind filigrane Brushes sowieso zusätzlich noch ein Problem, weil sie immer deine Leafes beeinflussen; genauso wie alle Schrägen etc. An der Stelle sollte man zu brush-based Entities greifen, um die Compilezeit unten zu halten und Leaf-Portal-Saw-Into-Leaf-Fehler zu umgehen.

Viel Spaß weiterhin, ich will Ergebnisse sehen ;)

Schlachtfestchen TF2 Community
Schlachtfestchen.de - Drink 'n' Fight: sfchen.de:27015
Jeden Donnerstag ist Custom-Map-Abend!

Dem stimme ich uneingeränkt zu.

Ergebnisse kommen, wenns irgendwann einmal fertig is... ;)

Euer Phoenics