I gave Box a few pointers. He says it’ll be fixed. If not, I’ll just take the reins and optimize it myself.
Man I feel like I’m saying that a lot these days… 
Taking all those reins…
Maybe you should focus on your movement training and firing range for now. Those are pretty huge portions you’ve got.
Fixed some walls only as of now, and made func_detail of some things.
Tommorow doing the whole friggin thing.
Also fucking ghost page?
This will be fun, I can tell. 
EDIT: VRAD will be the bane of my existence.
Pure evil. A necessary one.
EDIT: Does anyone know the actual VRAD limit for lightmap styles? This is ridiculous… VRAD is throwing me the “too many styles on a face” error in places where I’ve never gotten it before. :brow:
I think it’s something like 4 different light entities that change state.
Was it not 25 or 30 or something?What you using now?
Eitherway happy new year everyone!
Just tested it. VRAD will accept up to 3 named light entities on a face.
Well that’s just awful.
And no, Box… 2^30 is a ludicrous number that will eat up BSP filesize for lunch. There’s no way it was ever that high.
Ah. Yeah, I hate that. One time on a project I tried having light that shut off and then emergency lights turning on, and VRAD was like, “Fuck that noise,” and refused to work my stuff.
Which reminds me, I gotta figure out what my problem with Hammer is.
Well it seems I can safely ignore a number of those errors without issue so that’s cool. I’m not sure why it’s not showing up as ugly lightmap errors in my map, but I’m not complaining either.
Problem solved. Kinda.
Man, you is on a roll.
It is time… TO FULL COMPILE EVERYTHING UP TO THE LADDER SILOS WOOHOO.
This will take VRAD ages… I have a lot of switchable lights.
EDIT: Aaaaaand VRAD just crashed.
Ah well. Time to increase the lightmap scales!
Wonderful! Freakin’ BSP.
I haven’t been keeping up fully with the discussion here, so I’m sorry if I’m totally off the mark, but I figure it won’t hurt.
You seem to be having problems with using named lights, this can be alleviated somewhat by giving lights which change state at the same time identical targetnames. VRAD then treats them all as one single light, preventing the “too many light styles on face” bug. For example, if all the lights in a room turn off and then red emergency lights come on, you could name ALL of the lights which are initially on “lights1”, and then use outputs to turn them off. Likewise you can then name ALL the red emergency lights “lights2” and then use outputs to turn them on. Even if you have 500 red lights and 1000 initial lights, VRAD will not complain, as it “merges” the lightmap pages for them when they have the same name, meaning there’ll only be 2 lightmap “styles” on each face. This also means you need 2 outputs TOTAL for a lighting change rather than 2 for each light, which should optimize the I/O system a bit and is also much easier to deal with in the editor.
Sorry if I’m well off the mark here, or if your problem is a bit different, but if not, hope this helps.
Well fuck, I’m never watching video tutorials again 
I actually never took the time to read that.
Also
"FindPortalSide: Couldn’t find a good match for which brush to assign to a portal near (1025.0 2048.0 111.0)
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:
FindPortalSide: Couldn’t find a good match for which brush to assign to a portal near (1036.0 2048.0 111.0)
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:
FindPortalSide: Couldn’t find a good match for which brush to assign to a portal near (1547.0 2048.0 111.0)
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:
FindPortalSide: Couldn’t find a good match for which brush to assign to a portal near (2048.0 2560.0 111.0)
Leaf 0 contents:
Leaf 1 contents: CONTENTS_SOLID
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:
FindPortalSide: Couldn’t find a good match for which brush to assign to a portal near (1536.0 3072.0 111.0)
Leaf 0 contents:
Leaf 1 contents: CONTENTS_SOLID
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:
FindPortalSide: Couldn’t find a good match for which brush to assign to a portal near (512.0 2048.0 111.0)
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:
FindPortalSide: Couldn’t find a good match for which brush to assign to a portal near (512.0 3072.0 111.0)
Leaf 0 contents:
Leaf 1 contents: CONTENTS_SOLID
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:
FindPortalSide: Couldn’t find a good match for which brush to assign to a portal near (-512.0 2048.0 111.0)
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:
"
When I go to the coordinates, I end up in void :x.
Really? Do you have a lot of programs running in the background? Eating resources? (or a not so good computer)
I tested your basicmovement map: 1min 47 sec (cordon), 3min 22 sec (no cordon)
It’s a leak. Load the pointfile, follow the line until you find the leak, and seal it. If you’re using areaportals, remember that they can leak too. If you can draw any path from one side of an areaportal to the other without crossing another areaportal or world geometry, it’s considered to be a leak by VVIS.