check the angles on the lights again ;) 

origin is directly above the edge of the little wizmet brush

tried moving the zombies slightly. bizarrely, moving the east-facing one (the bright one) 2 units back into the wall fixed it; it now lights the same as the ones in shot 3. at the other end however, moving it 2 units into the wall makes no difference and moving it 2 units out makes it fullbright. no joy re-adding the brushes either.. 

The code says 12 units into the wall for a horizontal/verical wall. On a 1:1 diagonal wall, this should be reduced to 8 units.

Assuming that doesn't help, I have no idea... 

I haven't looked at the lighting code for a while, so this is just a theory. With the zombies set back into the wall, might it be possible that surfaces on the other (back) side of the wall are contributing to the lighting? 

yeah, i wanted to ask: is the map sealed or is there some geometry behind the wall with the zombie?
i think i remember a case where it happened in an unsealed map, and when it was sealed and the outside faces culled, the problem went away. 

i wanted to ask: is the map sealed or is there some geometry behind the wall with the zombie?
i think i remember a case where it happened in an unsealed map, and when it was sealed and the outside faces culled, the problem went away

well, it was unsealed and that wall backed out into the void.

so i tried doing a full compile of the whole map, which is sealed in its entirety, so i could test your theory.

i then went to the area and noclipped up to inspect... and only THEN remembered that in my fed up frustration the other night i ended up ditching the zombie altogether and replacing him with a hanging flag ;/

= dunce ;/ 

i hope you don't mind, but i had a good chuckle at your expense. that sort of thing happens to me all too often. ^_^ 

I'm on the end of my map and I'm trying to get it realvised.

After the -th version I keep this error of some brushes that keep disapearing in some views. I tried everything to get it right, force to grid, reshaping but the error remains.

As I look at the mapstructure the brushes are changed from MapStructure to info_notnull.
I haven't given them these option, it just occured.

Could it be the root of this malviewing? 

needs Hammer ;) 

I thought it was mapping help..,
let's have another editor. 

I use the BSP editor, and I have to be careful and always use the Esc Key on my keyboard to de-select brushes before selecting brushes for an entity. If not, some selected brushes (not in my view) could get an entity applied that I didn't want.

I don't think you want to force to grid all your brushes after you draw them or clip them. First select the grid you want, like 1, 2, 4, 8, 16, units etc, and draw your brushes to that brush(grid) resolution, or clip to that unit resolution.

Brush entities that disappear while viewing at different angles may be due to being built partially out of your level. Large multiple brush entities that span a level could do the same. Giant sized multiple brush entities can be made though, that don't disappear. 

work with grid 1 for what?

force to grid? :\

This is the kind of tools "not to be used" 

than a 16x16 grid. It happens sometimes, but usually I keep the grid that size or bigger. And yes - as I am dragging out my new brushes they are snapping to the grid.
Also selecting another brush in WC will always de-select any other brushes unless you are holding the shift or control key.
Also WC has the ability to send any brush entities back to being normal brushes. Just select the entity and click on a button "to world". 

Yup, I usually use grid 16 and higher, but for clipping I sometimes go down to 1 and 2 units when making something over 50 faces.

Forcing to grid, not sure how that works, but if a grid is changed is the brush going to adjust to the new grid when selected? That might explain things.

And, my previous editor also de-selected as a new brush was selected. BSP is opposite and hard to get used to, but I'm managing. That's the main reason, I think, that people hate changing editors. Unlearn'id what they learned! 

I have this cave with sidebrushes of triangular shapes to make a terrain shape.
Some brushes fit well, others don't.
The ones that won't fit I force to grid on 1 unit grid. As the center of the brush is placed back to integers the outside can change.

The only way to avoid hom's of the sidebrushes was to change them all into func_wall.
Problem solved, signon calling to minimize the func_entities. 

what light and vis command you guys use?

mine:

e:\Quake I\quark\QTools\Vis.exe -level 4 -priority 0

e:\Quake I\quark\QTools\Light.exe -extra4 -gate 1 -addmin -range 0.45 -dist 0.8 

what light and vis command you guys use?

mine:

e:\Quake I\quark\QTools\Vis.exe -level 4 -priority 0

e:\Quake I\quark\QTools\Light.exe -extra4 -gate 1 -addmin -range 0.45 -dist 0.8 

Gotta try those commands out some time, I still just use -level 4 and -extra. I'm new to Agguire's tools. Been using something like "delay" "2" and "wait" "1" on lights, and stuff looks alot better.

Madfox, if you make all your brushes with the grid at 16, and move edges and points around to make terrain, everything should match-up at the 16 unit grid. No need to move something 1 unit. Also, if every brush is made and clipped on the grid ( grid from 1 to 128 units and larger), all brushes should be integer.

I played lots of your levels and can see brush points less than 1 unit, though. So, it's just something you need to setup properly in your editor. Trinca will write you a tutorial! 

..is the default behaviour just so you know. wait 0.5 makes the light cover twice the radius without increasing the brightness level, wait 2 halves it, and so on. so if you have a high light value with a high wait, it will create a small bright spot, whilst low brightness & low wait will dimly light a wide area.

although i confess i only use -soft out of those compile options, and -extra4 on the final compile. need to look into them a little more... 

roblot whould be a cool stuff... me making a tutorial... my English rockzzz :\

will be a peace of crap :p 

I use grid 1 quite often for details - building complicated door shapes to exactly match the texture, making buttons that exactly line up with the cutout in the texture. That sort of stuff.

I regularly use grid 2 when making ladders or handrails.

No problems, rarely get any error messages.

Radiant's Translate tool makes sure it all stays on grid. 

Didn't know that "wait" "1", I just copy other peoples stuff alot. Trinca you really should send out editor setup info or something. I think it would help. Some people speak other languages, so reading english makes mapping twice as hard. If I had to learn another language, like British or something, I'd never know what I was doing. 

vis -level4
light -dist 0.7 -range 0.7 -light 15 -extra -soft
ingame light wait 0.3

terrain maps.
I know it sounds weird, but I tried to make a triangular brush that fits exact on the 16 grid.
Normal triangel brushes always go off grid. So I placed the boundary on the 16 point grid and keep hashling the corners untill they fit on the gridpoint.
After forcing this brush to grid I used copies of it to make a large flat surface. Then I raised all the triangles and made them sloping.
By doing so, the centre of the brush gets offgrid again what results in these coarsed lines.
Then it tends to the compiler to show what's the outcome. Sometimes they match fine, sometimes it needs new forcing to grid.

I know this sound rather strange, but I was curious when I saw the original triangular brushes, with their angles of grid.
With good use of light it can be minimized.
That's in Quark6.5 alpha. 

Maybe try this.
1. First set grid. Brushes placed should snap to this grid setting when adjusted.
2. Place all the square or rectangle brushes you need. Oh yea, turn off texture lock!
3. Make the triangles you need out of the squares and rectangles, or slope the square and rectangle brushes as needed.

If the editor does this wrong, then it's giving you a hard time. The BSP editor does much more complex copy, paste, merge, and rotate of multiple brushes really well. 

Oh yea, turn off texture lock!

Has MadFox ever turned on texture lock?