vgui/black brush in doors?

Fyfey

L2: Junior Member
Jan 24, 2008
54
4
I was looking at the decompiled Granary and saw that valve have put what seem to be just world brushes textured with 'vgui/black' in their doorways (as you would with an areaportal). I was wondering if anyone knew what this does or why they've done it. Seems really odd.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
Its most probably a decompiling error, or something much above me ;)
 

Earl

L6: Sharp Member
Dec 21, 2007
284
38
Maybe it's tied to the areaportal in actuality? I.E. its what fades in to close the portal?
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
You'll find this has been used along with tools/toolsblack in doorways, windows and alley ends in "actual" provided vmf's for hl2 also. Take a look at "town" (ravenholme section) for an example. They use it because it doesn't relfect light (such as a torch) So instead of having to have a large purposefully dark room behind a door or window they can just stick that texture there to make it look 3dimensional without the cost of actually having an empty 3d room there.

But those are unused doorways and windows, normally located at a distance too far to observe in detail from a stranded ingame characters perspective. If you mean actual doorways then i wasted my time and Youme probably has it spot on as a decompiling bug.
 
Last edited:

Fyfey

L2: Junior Member
Jan 24, 2008
54
4
Yeah, they are used in actual doorways. I reckon they are just areaportals messed up then. Do people actually link areaportals to their doors in maps (to open and close)? Or is this not common practice?
 

Brandished

L5: Dapper Member
Jan 19, 2008
234
311
Yeah, they are used in actual doorways. I reckon they are just areaportals messed up then. Do people actually link areaportals to their doors in maps (to open and close)? Or is this not common practice?

No, the vgui/black texture is actually used for the func_areaportals in Granary, this is not a vmex bug issue (I thought the same thing at first). I checked through the bsp with a text editor and the "toolsareaportal" texture isn't used anywhere on the map, while vgui/black is.

Valve linked the area portals in the doorways around the 2nd control points for the red and blue teams to the doors the area portals surround. They also used func_occluder brush entities in the doorways as well.

I've been experimenting with cp_granary's vmf in an attempt to make the map into a reverse style ctf type and fixed a bunch of bugs that vmex produced (re-tied the func_areaportal's and func_occluder's to the corresponding brushes, fixed some of the overlays that were mis-aligned, etc).

I've uploaded the edited vmf here for those interested (original cp_granary with some bug fixes, not the reverse ctf vmf):
http://www.mediafire.com/?wwhejhxddjj
cp_granary_d1.zip (704.31 KB)

(the vmf was taken from a decompile of the most rescent update of cp_granary, it's not the one listed in the Valve maps thread)


There's still quite a few bugs remaining, though:

-None of the func_details are grouped (haven't gotten around to this yet)
-There are info_player_start's all over the map
-The water in the 3d skybox shows up pink/purple
-Some of the the areas in the map are not lighting up properly
-The skybox kicks out this error during compile: "Error: Skybox vtf files for skybox/sky_granary_01 weren't compiled with the same size texture and/or same flags! Can't load skybox file skybox/sky_granary_01 to build the default cubemap!" (this is probably related to the lighting 3d skybox errors)
-There's an area portal bugs that show up during compile; "FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (-3072.0 -3319.0 99.7) Leaf 0 contents: CONTENTS_SOLID
Leaf 1 contents: viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID
Candidate brush IDs: Brush 1178:"


PS: I've mentioned this in another thread, but compressing vmf's/bsp's (zipping/rar'ing) saves a ton of bandwidth on the uploader's and downloader's part (a vmf/bsp file can quickly and easily be compressed to less then 1/10 it's original filesize with no loss in quality).
**cough** original VALVe maps sticky **cough** :p
 
Last edited: