ich hab leafs aber wie kann ich sie finden ?

(und , gehen deswegen die r_speeds hoch?)
ntering D:\Half-Life\cstrike\maps\de_pum9.map
CreateBrush:
10..20..30..40..50..60..70..80..90.. (15.66 seconds)
SetModelCenters:
50.. (0.00 seconds)
CSGBrush:
10..20..30..40..50..60..70..80..90.. (5.10 seconds)
Using WAD File: \half-life\cstrike\decals.wad
Using WAD File: \half-life\cstrike\mad_spain.wad
Using WAD File: \half-life\cstrike\mad_spain_addon.wad
Using WAD File: \half-life\valve\halflife.wad
Using WAD File: \half-life\cstrike\pum.wad
Texture usage is at 2.09 mb (of 4.00 mb MAX)
21.04 seconds elapsed

----- END hlcsg -----

** Executing...
** Command: D:\Worldcraft\hlbsp.exe
** Parameters: "D:\Half-Life\cstrike\maps\de_pum9"

hlbsp v2.5.3 rel (May 2 2001)
Based on Valve's version, modified with permission.
Submit detailed bug reports to (zoner@gearboxsoftware.com)
----- BEGIN hlbsp -----
Command line: D:\Worldcraft\hlbsp.exe D:\Half-Life\cstrike\maps\de_pum9

-= Current hlbsp Settings =-
Name | Setting | Default
-------------------|-----------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
priority [ Normal ] [ Normal ]

noclip [ off ] [ off ]
nofill [ off ] [ off ]
notjunc [ off ] [ off ]
subdivide size [ 240 ] [ 240 ] (Min 64) (Max 240)
max node size [ 1024 ] [ 1024 ] (Min 64) (Max 4096)

BSP generation successful, writing portal file 'D:\Half-Life\cstrike\maps\de_pum9.prt'
11.65 seconds elapsed

----- END hlbsp -----

** Executing...
** Command: D:\Worldcraft\hlvis.exe
** Parameters: -fast "D:\Half-Life\cstrike\maps\de_pum9"

g_fastvis = true
hlvis v2.5.3 rel (May 2 2001)
Based on Valve's version, modified with permission.
Submit detailed bug reports to (zoner@gearboxsoftware.com)
----- BEGIN hlvis -----
Command line: D:\Worldcraft\hlvis.exe -fast D:\Half-Life\cstrike\maps\de_pum9

-= Current hlvis Settings =-
Name | Setting | Default
-------------------|-----------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
priority [ Normal ] [ Normal ]

fast vis [ on ] [ off ]
full vis [ off ] [ off ]

1376 portalleafs
4422 numportals
BasePortalVis:
10..20..30..40..50..60..70..80..90.. (40.97 seconds)
Warning: Leaf portals saw into leaf
Problem at portal between leaves 448 and 456:
(-55.270 384.000 -222.750)
(-55.016 384.000 -222.750)
(-55.016 384.430 -222.752)
(-55.162 395.718 -222.796)

Warning: Leaf portals saw into leaf
Problem at portal between leaves 453 and 456:
(-55.264 448.000 -222.826)
(-179.000 448.000 -186.000)
(-177.933 384.000 -185.095)
(-55.270 384.000 -221.248)
(-55.162 395.719 -221.248)

Warning: Leaf portals saw into leaf
Problem at portal between leaves 454 and 457:
(-263.000 448.000 -161.000)
(-576.000 448.000 -67.845)
(-576.000 384.000 -67.771)
(-262.105 384.000 -160.287)

Warning: Leaf portals saw into leaf
Problem at portal between leaves 456 and 453:
(-55.162 395.719 -221.248)
(-55.270 384.000 -221.248)
(-177.933 384.000 -185.095)
(-179.000 448.000 -186.000)
(-55.264 448.000 -222.826)

Warning: Leaf portals saw into leaf
Problem at portal between leaves 458 and 448:
(-162.080 448.000 -255.000)
(-55.844 448.000 -222.627)
(-65.074 1160.000 -221.248)
(-162.080 1160.000 -255.000)

Warning: Leaf portals saw into leaf
Problem at portal between leaves 459 and 448:
(-57.067 448.000 -221.248)
(-162.080 448.000 -255.000)
(-162.080 384.000 -255.000)
(-55.014 384.000 -222.751)

Warning: Leaf portals saw into leaf
Problem at portal between leaves 464 and 462:
(-189.944 336.000 -226.056)
(-189.258 336.000 -221.248)
(-189.252 324.000 -221.248)
(-189.954 324.000 -226.046)

Warning: Leaf portals saw into leaf
Problem at portal between leaves 465 and 464:
(-192.000 336.000 -223.227)
(-189.944 336.000 -226.056)
(-189.954 324.000 -226.046)
(-192.000 324.000 -223.266)

Warning: Leaf portals saw into leaf
Problem at portal between leaves 542 and 539:
(-192.000 324.000 -222.791)
(-192.000 192.000 -223.294)
(-161.000 192.000 -255.000)
(-161.000 324.000 -255.000)

average leafs visible: 844
g_visdatasize:230485 compressed from 236672
45.20 seconds elapsed

----- END hlvis -----

** Executing...
** Command: D:\Worldcraft\hlrad.exe
** Parameters: "D:\Half-Life\cstrike\maps\de_pum9"

hlrad v2.5.3 rel (May 2 2001)
Based on Valve's version, modified with permission.
Submit detailed bug reports to (zoner@gearboxsoftware.com)
----- BEGIN hlrad -----
Command line: D:\Worldcraft\hlrad.exe D:\Half-Life\cstrike\maps\de_pum9

-= Current hlrad Settings =-
Name | Setting | Default
--------------------|---------------------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
priority [ Normal ] [ Normal ]

vismatrix algorithm [ Original ] [ Original ]
oversampling (-extra)[ off ] [ off ]
bounces [ 1 ] [ 1 ]
ambient light [ 0.000 0.000 0.000 ] [ 0.000 0.000 0.000 ]
maximum light [ 256.000 ] [ 256.000 ]
circus mode [ off ] [ off ]

smoothing threshold [ 50.000 ] [ 50.000 ]
direct threshold [ 25.000 ] [ 25.000 ]
direct light scale [ 2.000 ] [ 2.000 ]
coring threshold [ 1.000 ] [ 1.000 ]
patch interpolation [ on ] [ on ]

texscale [ on ] [ on ]
patch subdividing [ on ] [ on ]
chop value [ 64.000 ] [ 64.000 ]
texchop value [ 32.000 ] [ 32.000 ]

global fade [ 1.000 ] [ 1.000 ]
global falloff [ 2 ] [ 2 ]
global light scale [ 1.000 ] [ 1.000 ]
global gamma amount [ 0.500 ] [ 0.500 ]
global sky diffusion [ 1.000 ] [ 1.000 ]

opaque entities [ on ] [ on ]
sky lighting fix [ on ] [ on ]
incremental [ off ] [ off ]
dump [ off ] [ off ]

[Reading texlights from 'D:\WORLDCRAFT\lights.rad']
[1 texlights parsed from 'D:\WORLDCRAFT\lights.rad']

7585 faces
Create Patches : 59548 base patches
0 opaque faces
816415 square feet [117563872.00 square inches]
1 direct lights

BuildFacelights:
10..20..30..40..50..60..70..80..90.. (181.20 seconds)
visibility matrix : 211.4 megs
BuildVisLeafs:
10..20..30..40..50..60..70..80..90.. (1254.56 seconds)
MakeScales:
10..20..30..40..50..60..70..80..90.. (1148.76 seconds)
SwapTransfers:
10..20..30..40..50..60..70..80..90.. (370.69 seconds)
Transfer Lists : 66994232 transfers
Indices : 24841028 bytes
Data : 267976928 bytes
Bounce 1 GatherLight:
10..20..30..40..50..60..70..80..90.. (222.94 seconds)
FinalLightFace:
10..20..30..40..50..60..70..80..90.. (50.47 seconds)
3277.13 seconds elapsed [54m 37s]

----- END hlrad -----

Also das muss doch schmerzen.

1. Ist das ein kompilierfehler, also? Wo kommt das hin?!
2. Steht das im Kompilierfehler-Artikel drinne! http://www-public.tu-bs.de:8080/~y0009981/compile/comperr_08-01.htm
3. Du musst die leafs dazu nicht suchen

Lies dir mal alle Artikel da oben nacheinander durch...

shielding people from their own stupidity is an evolutionary step backwards anyway.

/* God is dead!............Nietzsche */
/* Nietzsche is dead!......God */
/* Nietzsche is God!.......The Dead */

EDIT weil Schwachsinn =)

"Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer is at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed ervey lteter by it slef but the wrod as a wlohe."

Das Problem hab ich auch öfter, besonders wenn ich Felsen mache. Hat aber meißt keine spürbaren Auswirkungen auf das Spiel, also ignorier ich sowas in der Regel.

Wenn hier jemand ne Map erstellen kann, die KEINE leafs hat ist er gut.
Leafs sind ein grundlegender Bestandteil jeder Map.

Denk nach, lies dir die Artikel durch und frag dann, wie du ein Leak... moment, es gibt tolle Anleitungen "how to find a leak"

so.

-> forensuche

voice - Ruhe in Frieden

Nochmal ganz klar:

1. Leaves sind keine Leaks: Leaks = Fehler, Leaves = müssen sein
2. "Leaf portals saw into leaf" heißt, daß der Blick von einem Vis-Leaf nicht nur in andere geht, sondern auch wieder in sich selber zurück. Muß man nicht verstehen, sollte aber nur eigentlich nicht passieren.
3. Wenn's doch passiert ist es nicht unbedingt ein Bug und kann in der Regel (wenn's nicht zuviele sind) ignoriert werden.
4. Bei Dir sind's ein paar arg viele, das könnte Deine Vis-Berechnung versauen, also:
5. Erstmal einen normalen Vis-Compile und nicht auf "fast" stellen, manchmal isses dann schon weg.
6. Wenn nicht hast Du höchstwahrscheinlich einen zu komplizierten oder invaliden Brush der die Leaves scheisse zerteilt. Suchen und plattmachen - aber nur wenn die Map sich nicht spielen lässt, da Deine ja mit Rad compiled ist eigentlich alles tutti.

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

Haha, das kommt davon wenn man nich weiss wie man mappen muss. Is alles ziemlich gut erklaert im Leaf artikel, ich probiers mal in Kurzform:
Jeder Raum brauch seine eigenen brushe als Waende. Also sollten sich zwei Reaume nie zb die Brushe des Eingang "Tunnels" teilen. Weil dann erstens ein Leaf in dem Raum vor dem Eingang, im Eingang selbst und im Raum erstellt wird. Das heisst das das Eingangsleaf, das gleichzeitig im Raum UND im Eingang UND im Raum davor existiert von sich selbst gesehen werden kann und das resultiert zu dieser Fehlermeldung.

Hoffe das da einer durchblicken kann.

Ps: "Ich hab LEAFs, aber wie kann ich sie finden?" *rofl Jede Map hat Leafs, steht alles im Artikel.

Na zum Glück weißt Du ja, wie man mappen muß :) Aua aua, da hat sich der Herr Bandit aber gerade schön selbst ins Knie geschossen, das ist absoluter Unsinn was Du da erzählst. Wenn bei Deinem Beispiel wirklich ein LPSIL-Error auftauchen sollte, müsste jede je gemappte Karte davon mindestens 500 Stück haben. Der Error tritt nur dann auf, wenn sozusagen ein von einem Leaf ausgesandter "Richtstrahl" irgendwann wieder in dasselbe Leaf eintritt und das ist theoretisch unmöglich, praktisch passiert es aber bei sehr komplexer Bauweise eben doch. Aber bestimmt nicht bei zwei Räumen und einem Verbindungsgang *rofl*

Aber immer erstmal schön einen auf dicke Hose machen und über andere lachen :)

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

Das beweist das du net geschnallt hast was ich versucht hab zu beschreiben. Das mit dem richtstrahl haengt nur davon ab wie konvex ein Objekt/Leaf ist. Und da kovexe flaechen von HalfLife net dargestellt werden ist dazu theoretisch (wie du schon richtig gesagt hast) unmoeglich, kommt aber irgendwie doch vor, was? Das WAS da vorkommt ist das was ich versucht hab zu beschreiben anhand eines Ganges. Stell dir mal folgendes vor:
Du Hast einen Raum B, einen Gang C der in den Raum (B) hineinragt, diese "hineinragende Flaeche" nennen wir mal A. Wenn Vis die Unterteilung der Map in Portale durchführt, wird der Gang manchmal nicht zwischen A und B aufgespalten. Stell dir nun vor, daß du an Punkt A stehst:

Du befindest dich eindeutig an Punkt A des Gang-LEAFs (richtiger des Gang-Leafs-Portal), aber gleichzeitig im LEAF von Raum C. Vis wird trotzdem noch überprüfen, ob von A aus C sichtbar ist bzw. C von A aus, weil A trotzdem immer noch zu B gehört, und gleichzeitig zu C. Obwohl die LEAFs von C und A sich überschneiden, sieht Vis den Bereich A immer nochals zu einem anderen LEAF(B) zugehörig an. Infolgedessen denkt Vis, daß das LEAF in sich selbst sehen kann (C kann in A sehen und umgekehrt), was den Fehler verursacht. Was hier getan werden muß, ist eine Trennung von A und B, damit, wenn Vis oder die anderen Compiler-Programme die Map zerlegen, A und B eindeutig voneinandergetrennt werden. Wenn dann die LEAFs festgelegt werden, können A und C verschmolzen werden, OHNE daß A weiterhin auch als Teil von B angesehen wird.

Hoffe das du daraus schlau wirst, is im Grunde der LEAF Artikel von JoelCaesar und Crid, und ich wollte natuerlich net unhoeflich zu Highlander sein. Sorry falls das so rueber kam. Ich fand es nur klar das man die Leafs, bzw die Reaume oder konvexien (meint Gebirge und so) voneinander rein LEAF maessig trennt. das is bei mir n natuerlicher vorgang wenn ich die Speeds optimier. Nochmal sorry und thx and crid und Joel

ps Falls du mir eklaerst wie man n Bild schickt kann ich das auch noch machen ... tja ich weiss halt NICH wie man das macht. Und jetzt kannst du von mir aus lachen.

Bei dem beispeil würde es schon reichen einen hintbrush in den verbindungsgang C zu setzen, dadurch würden die überschneidenden stücke der leafs des raum B abgeschnitten.

War in Europe - the first WW2 modification for HL http://www.warineuropemod.com

Ich verstehe schon, was Du da erklärst, aber im Grunde rezitierst Du nur den Leaf-Artikel von Crid, der diesen von Joel Caesar ins Deutsche übersetzt hat und dieser sagt selber: "Auch kann es sein, daß nicht alle technischen Details in diesem Artikel hundertprozentig korrekt sind, aber so verstehe *ich* dieses Problem."

Im Prinzip ist die theoretische Erklärung ja richtig, aber in den im Artikel geschilderten Situationen tritt dieser Fehler eigentlich nie auf. Ich habe nun inzwischen annähernd 100 Maps gebaut und compiled und meine praktische Erfahrung zeigt, daß so ein Fehler in geschlossenen Räumen äußerst unwahrscheinlich ist (ich hatte ihn dort auf jeden Fall noch nie). Zur Veranschaulichung nochmal Deine Version als Grafik:

Hier ragt der Gang C in den Raum B rein. Deiner Theorie zufolge entstehen dabei nur 2 Leaves, die sich dann auch noch überschneiden. Die Schnittmenge sieht man oben in blau und Du nennst diesen Bereich A. Würde dieser Bereich entstehen, wäre das ein klassischer LPSIL-Error, aber VIS würde diese Bereiche niemals so aufteilen. Selbst wenn der Gang nur 1 Unit in den Raum reinragt, legt VIS in der Regel (ich habe es jedenfalls noch nie anders erlebt) ein eigenes Leaf dafür an oder ignoriert diese 1 Unit. Und in den Bildern aus Caesars Artikel passiert das 100%ig, da die Gänge dort 16-32 Units tief im Raum stecken.

Ich will Dir mal eine Stelle zeigen, wo ich den Error gekriegt habe:

Ich hatte vor dem Compile einfach verschwitzt, diesen Haken zu einer func_wall zu machen so daß er komplett in die Leaf-Unterteilung mit einbezogen wurde. Die zahlreichen schrägstehenden Brushes zerhacken den Vis-Bereich wie Sau und führen mit 99%iger Wahrscheinlichkeit zu einem LPSIL-Error (ich hatte ein gutes Dutzend davon an dieser Stelle).

Also meiner Erfahrung nach (ich sag auch vorsichtshalber nicht, daß das unbedingt stimmen muß) tritt dieser Fehler bei zu komplexer Bauweise auf, die in die Vis-Berechnung einbezogen wird. Mein Lösungsvorschlag für so einen Fehler ist es, nach kleinen und komplexen Strukturen zu suchen, die man nicht zu func_walls gemacht hat. Außerdem sollte man gecarvte/geclippte Brushes daraufhin untersuchen, ob hinterher auch wirklich alle Eckpunkte auf dem Grid liegen. Ein Brush muß nicht unbedingt invalid sein um einen LPSIL-Error zu erzeugen, manchmal reicht es schon wenn ein Eckpunkt nicht sauber auf dem Grid liegt.

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

puhhh... @Term deine Threads sind immer noch die aufschlussreichsten ;)

hab grad viele meiner strukturen zu func_walls gemacht und siehe da...die fehler wurden weniger
danke