This is just crazy, so much advancements to ole Quake! Thank you all for the efforts, really...can't be said enough. 

btw, the key for phong shading has changed since the version you were using, you no longer need to give the texture name. The main improvement of this new version is having an angle cutoff, so it won't smooth around 90 degree corners by default (the cutoff is 89 degrees.)

Another new feature: when using phong shading I suggest setting "_anglesense" "1" in worldspawn, this affects all lights in the map that don't override "_anglesense".
This will make phong shading more visible and generally increase contrast.. it makes the angle that light arrives on a surface matter more than the quake default. 

I'm not sure I will change compilers unless I am really compelled to 

 

Does it apply phong shading to the whole brush? Not sure if this is desirable behaviour.

The thing I want most is a more tolerant or forgiving compiler like txqbsp 

 

whats your problem?? 

my brushwork sucks and I guarantee once my map is properly "sealed" it will leak like an incontinent old man who just drank 30 litres of water. 

 

sounds like an AI chat bot I can get behind. Maybe Microsoft can make it their next project after Tay failed.

"ur avin a giggle m8"
"u wot ill fukin slap u" 

doesnt seem desirable to me to always have an object fully phong shaded. I think there should be a way to choose to either have the model phong shaded or certain textures. 

Dunno, I think with the angle cutoff and the fact that you can break it down into as many func_groups or func_details as you want, the current system seems pretty ok?

I'm just trying to envisage a scenario where that's not enough, and I'm struggling.... 

complex func_groups like this -
https://twitter.com/GavinEdgington/status/714465169649377281

Where I don't want to have to break up into small groups because it will make it a pain to move around and place. 

The angle cutoff is pretty flexible, if you set it to a low value like 30, only pairs of faces with normals up to 30 degrees apart will be smoothed together. So I imagine something in 30-60 would work well on that spaceship, and not add smoothing in unwanted places.

Also it's easy to check what the phong shading is doing, just compile with the light flag -phongdebug.

I could add back the list of textures to restrict phong shading to, if it's really needed, though. 

You guys are fighting the engine's weaknesses instead of playing to its strengths. Some things you're just not going to get control over without fundamental data format changes.

Pick what game you really want to be mapping for first. 

We'll continue working with quake and seeing awesome new tools to use and extend the life of the game. 

Was that a screenshot of something in an existing released map?

(Or what was that a screenshot of?) 

map in development for AD. 

When trying to compile the vanilla GPL start.map:

*** WARNING 10: Reached occupant at (386 1554 132), no filling performed.

This error happens in a lot of places with the vanilla .map files. 

you use the tyrutils qbsp? I guess so, this thread gives me the clue..

I tried to recompile those vanilla maps myself some time ago, several compilers had problems with them.

Whats the cause of those? I don't know, the map were rather tidy in my eyes, all integer coords and such. We all know there aren't any fancy brushes in them. 

try -oldaxis switch? 

-oldaxis didn't help. Time to read the docs... 

try the first released qbsp.exe. Quadicted should have it archived. 

thats an old version, only watervising added to it.

https://www.quaddicted.com/files/tools/wqbsp165.zip 

According to the WQBSP165 docs, it doesn't support -splitspecial, so lit water won't work with it.

The problematic entity is a light torch; I've tried deleting it and creating a new one at the exact same place, and the problem still happens. It's like the tyrutils qbsp compiler is too strict about entity placement.

Light entities should be treated as point entities by the QBSP compiler. I wonder if the tyrutils qbsp is checking whether some default bounding box size is out of map bounds or something.