Gestern Abend hat es noch funktioniert. Hab also *.map gesichert, kompiliert, Leakfehlermeldung bekommen, *.map geöffnet, gesehen, dass von meiner outdoor area ein invalides brush gelöscht wurde, hab das gefixt, als *.map gesichert, wieder mit batch-file kompiliert, noch ein anderes Leak, will *.map öffnen und tadaa: "For you information 1701999988 solids were not loaded due to errors in the file." - Ich klicke auf Ok und VHE stürtzt ab und Windows will eine Fehlerberichtserstattung machen.

Dann habe ich panisch eine halbe Stunde lang versucht den Fehler in der Map zu finden, ohne Erfolg. Hab dann mal versucht, einige ältere *.map-Dateien zu öffnen, aber die geben mir exakt die selbe Fehlermeldung mit exakt dem selben Zahlenwert und stürzen genau so ab wie die eigentliche Map, mit der ich das Problem zu erst hatte. Komisch, weil meine "älteren" *map-Dateien sind SEHR alt und somit sicherlich von VHE, wenn nicht WC, gespeichert worden, bevor ich dieses Problem hatte.

VHE scheint die *map-Dateien noch richtig zu speichern, sieht jedenfalls alles ganz vernünftig aus, wenn ich die im Texteditor öffne, nur öffnen kann er sie jetzt plötzlich irgendwie nicht mehr.

Bis jetzt habe ich VHE einmal neu installiert, und die beiden Konfigurationsdateien CmdSeq.wc und GameCfg.wc mal umbenannt. Das Problem bleibt das gleiche. Das einzige was ich mir vorstellen kann, was jetzt noch korrupt seien könnte, wären Einträge in der Registrierung, aber da kenn ich mich nicht aus. Ich weis nur, dass man da viel falsch machen kann. ^^

Hoffe es gibt hier wen, der eine ungefähre Peilung davon hat, was mit meinem VHE los ist.
Danke im Vorraus!!

666 BPM

.rmf ist des Hammers natives Dateiformat.
*edit
Warum speicherst du dann als *.map?
Der Hammer mag halt rmf's und es ist ja kein Beinbruch das zweimal zu speichern.

P.S. ich hab deinen Beitrag nicht durchgelesen, hab nur dauernd ".map" gesehen und dachte "Ah"
Ach außerdem hast du bei mir mit deiner "2-Monate-alten-Thread"-Ausgraberei schon so einen Eindruck erweckt :D

Website

Danke für die Antwort, aber die *.rmf hilft mir hier leider nicht, da der Compiler die *.map benutzt,
welche sich von der *.rmf unterscheidet, wenn der ein oder andere Brush fehlerhaft ist.

Man sollte im Userprofil wirklich Mappingerfahrung angeben können.
Geht echt auf den Senkel als Noob eingeschätzt zu werden, wenn man
seid fast 9 Jahren dabei ist. ^^

Egal. Ich kann als vorrübergehende Lösung alles etwas sorgfältiger nachbauen,
aber es wäre mir wirklich lieber wenn ich den Bug loswerden könnte. Es ist ja
auch zu befürchten, dass noch andere Funktionen plötzlich nicht mehr richtig
funktionieren.

666 BPM

Du mappst also seit du 8 Jahre alt bist... Interessant... aber mit Erfahrung hat das nix zu tun (vorallem nicht wenn man deine releasete SvenCoop-Map von vor einem Jahr ansieht).

Krifitze hat Recht: Nutz das native Dateiformat .rmf fürs Speichern.
Fürs Kompilieren hat WC/VHE ne .map-Exportfunktion. Es gibt nen Grund (!= Jux und Tollerei), dass man sich damals dazu entschlossen hat Maps nicht im .map-Format für die weitere Verarbeitung durch WC zu speichern.

Nur weil du denkst, du weißt, was ein Bug ist, heißt es nicht, dass du es weißt.
Außerdem kann niemand dir sagen, was evtl. falsch läuft, ohne die Rahmenbedingungen zu kennen, die du hier nicht genannt hast.

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Zitat:

Du mappst also seit du 8 Jahre alt bist... Interessant...

Zitat:

aber mit Erfahrung hat das nix zu tun

Zitat:

(vorallem nicht wenn man deine releasete SvenCoop-Map von vor einem Jahr ansieht).

Zitat:

Krifitze hat Recht: Nutz das native Dateiformat .rmf fürs Speichern.
Fürs Kompilieren hat WC/VHE ne .map-Exportfunktion. Es gibt nen Grund (!= Jux und Tollerei), dass man sich damals dazu entschlossen hat Maps nicht im .map-Format für die weitere Verarbeitung durch WC zu speichern.

Zitat:

Nur weil du denkst, du weißt, was ein Bug ist, heißt es nicht, dass du es weißt.
Außerdem kann niemand dir sagen, was evtl. falsch läuft, ohne die Rahmenbedingungen zu kennen, die du hier nicht genannt hast.

So, Suppe versalzen! -> Im nächsten Forum nachfragen! :D

666 BPM

Mach mir mal einer die Tür auf ich glaub es wird Tag...

Zitat:

In der *.rmf geht das nämlich nicht, da der Bug erst nach dem Export in der *.map sichtbar ist.

Zitat:

Es geht hier nicht um einen Fehler in der Map, sondern in VHE. Ich habe auch lang und breit erklärt, woran zu erkennen ist, dass es an VHE liegt.

Zitat:

(<- Second Chance!!)

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

So, Problem gelöst. Falls es irgendwann mal jemand haben sollte, hier die Erklärung und Lösung:

Schon vor Monaten hat es sich bei mir zur guten Gewohnheit entwickelt, vor dem Kompilieren immer unnötige WAD-Files per Text Editor aus der *.map-Datei zu löschen. Dann war ich aber mal zu faul für 30 Sekunden Testkompilierung das wieder zu machen. Da wieder ein Leak drin war, hab ich direkt versucht die *.map zu öffnen, ohne vorher WAD files rauszuschmeissen. Das Problem ist also, dass Hammer keine *.map Dateien öffnen kann, in denen mehr als 8 WAD files angegeben sind. Dass ich mehr als 8 WAD-Files drinne hatte ist schon lange her, allerdings habe ich erst jetzt wieder zur Nachforschung jene *.map öffnen müssen, um nachzusehen wo hier der Fehler ist. Die Compiler haben damit jedenfalls kein Problem, sonst wäre ich viel früher damit konfrontiert worden. Ich bin darauf in dem Moment einfach nicht gekommen, dass das Fehlen dieser kleinen Nachüberarbeitung dazu geführt haben soll. Der Bug ist also in Hammer, lässt sich aber mit etwas Sorgfalt bei der WAD-Auswahl umgehen.

666 BPM

Zitat:

Silencer Einundneunzig postete
Schon vor Monaten hat es sich bei mir zur guten Gewohnheit entwickelt, vor dem Kompilieren immer unnötige WAD-Files per Text Editor aus der *.map-Datei zu löschen.

Zitat:

Der Bug ist also in Hammer, lässt sich aber mit etwas Sorgfalt bei der WAD-Auswahl umgehen.

edit: Nach kurzer Überprüfung hat Valve da wohl nen kleinen Buffer Overflow im VHE (man müsste meinen sie wüssten es nach etlichen Fixes im HLSDK besser). Sobald der wad-String die Länge von 765 Zeichen überschreitet, geht der VHE krachen. Malicious Code Injection, anyone?
edit2: Sobald die Zeilenlänge 511 überschreitet, ist bereits vom Standardprozedere abweichendes Verhalten festzustellen (Es werden keine Solids mehr geladen).

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-