yeah it is. the quakespasm sdl port. i'll try it with glquakebjp when i get home 

metlslime join this in to do list ;)and don't forget .jpg screenshot suport 

so it's not fitzquake. same problem on the aforementioned :/ 

What happens if you move the zombie slightly, or if you delete and reinsert (c/p) the brushes beneath him? 

Is the origin of the zombie directly above a single brush? Or is it above the edge between two brushes? Might be that it's randomly choosing one of the two brushes. 

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