Willkommen ~Gast!
Registrieren || Einloggen || Hilfe/FAQ || Staff
Probleme mit der Registrierung im Forum? Melde dich unter registerEin Bild.
Autor Beitrag
000
09.02.2001, 12:37
pokefox



Hi Leute.

Kann es sein, das die WC Kompiler ne genauere Fehleranalyse machen ??

Ich kompiliere über SHLCT, und benutzte Hauptsächlich die ZHLT´s. Da mir das Fast compiling bei rad zu lange gedauert hat ( bei making scales, so ca. 1.5 h,danach von mir abgebrochen), hab ich die gleiche map,(auch über SHLCT), mit den Q compilern, kompiliert, und da tauchten dann Fehler auf ( z.B. "MakeNodePortal:new portal was clipped away from node@"), die eindeutig auf einen zu komplizierte brush hinweist. Ebenfalls erscheint der Fehler:
" Max Map Miptex", (erklärung spare ich mir).

Ich weiß zwar das diese Fehler für die ZHLT´s unrelewand sind, trotzdem frage ich mich, ob diese Fehler das compiling nicht doch beeinflußen.
Sprich zuviel Arbeitsaufwand für die rad bei making scales(bei erstgenanntem Fehler).
Also, sollte ich den(oder besser die) brushe/s entfernen, der/die den Fehler verursachen ???

Und schlägt der MMM Fehler sich ebenfalls negativ auf die Performence aus ???

Soll ich den kompilier Vorgang abrechen wenn er wieder bei making scales hängt ???(beim Fast kompilieren)(Ich weiß das etwas mehr Arbeitsspeicher helfen würde*g*)

Warum bekomme ich kein "WARNING" über ZHLT.

????:-(

--

zum Seitenanfang zum Seitenende Profil || Suche
001
09.02.2001, 15:03
ExecutorToon



Ich hab bei "meinem" MMM Fehler 5MB texturmemory eingestellt, danach ist der Compile-Vorgang richtig schnell gegangen!

--

zum Seitenanfang zum Seitenende Profil || Suche
002
09.02.2001, 15:23
pokefox



Ok, aber da der Fehler über ZHLT nicht auftaucht, dencke ich mal das meine MM´s noch im grünen bereich liegen, also unterhalb der 4MB Grenze.

Deswegen, dencke ich, sollte eine Erhöhung der texmemory überflüßig sein.

Aber THX.

pokefox

--

zum Seitenanfang zum Seitenende Profil || Suche
003
10.02.2001, 01:52
BSE_crid



.....ich glaube, daß die zhlt's so optimiert sind, daß sie an Stellen, an denen die (relativ "angestaubten) Originalkompiler 'ne Fehlermeldung ausgeben, besser klarkommen und deshalb keinen Fehler anzeigen. Ich glaube nicht, daß die Performance darunter leidet. Zumindest nicht bei einer "MakeNodePortal..."-Meldung.

--

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

zum Seitenanfang zum Seitenende Profil || Suche
004
10.02.2001, 11:17
pokefox



Schön, nur...

jetzt hab ich mal die o.g. map über Nacht laufen lassen (ca. 8 h), und er blieb ca. 7,5 h bei make scales (immer bei 50 % ) hängen.

Das DOS-Fenster konnte ich zwar normal schließen, aber ich wüßte jetzt gern,
ob sich rad aufgehängt hat, oder es noch nicht fertig war. Ne Fehlermeldung kam nämlich nicht., und der cursor blinckte noch. Das komische daran ist,
bis 50 % laüft alles normal, aber dann....
Bis dahin blinckt meine Orangene LED auch nur manchmal auf, aber bei 50 % leuchtet sie praktisch ständig und die Festplatte ist ebenfalls sehr aktiv. Ich hab zwar nur nen 128er Riegel, aber vorher hatte ich auch keine großen kompilierungsschwierigkeiten.
Ich vermute mal, daß das an meinem zusätzlichem neuen Raum liegt, denn vorher konnte ich die map eigentlich konstant compilieren, ebenfalls wenn ich ihn jetzt entfernen würde(was ich auch schon getan habe). Aber ich möchte nicht auf diesen Raum verzichten(2. Bombenplatz). Ich werd den vorhandenen Raum jetzt durch einen Neu designten ersätzen, wüßte aber schon gern was ich für ein Prob habe.

Bitte um eure Meinung.

pokefox

--

zum Seitenanfang zum Seitenende Profil || Suche
005
13.02.2001, 00:34
BSE_crid



....klingt eindeutig nach zu wenig RAM......sobald Daten auf die Festplatte geswappt werden müssen, können vor allem vis und rad 100 oder mehrfach länger dauern ---> RAM aufrüsten, oder viiel Geduld haben.....

--

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

zum Seitenanfang zum Seitenende Profil || Suche