This may be purely theoretical: are there any bsp tools that don't set TEX_SPECIAL?

The only one I know of is the -splitspecial flag from TreeQBSP (which is in tyrutils, as well as Bengt's TreeQBSP). TxQBSP (as well as id qbsp) always set TEX_SPECIAL for texture names starting with * or sky in map.c:FindTexinfo.

I guess if someone happened to compile a map with TreeQBSP/tyrutils and used "-splitspecial", and then used whatever light tool was used for death32c.bsp, we could have false positives again, but it seems pretty unlikely. 

The SQLauncher is AWESOME.

I've been renaming all my map titles in the Quake folder to the actual name of the maps, and I can just use SQLauncher to play them. It takes a bit more time renaming everything, but it's much neater. And you will actually the map title.

Quake Injector is a bit buggy, I just prefer to download maps from Quaddicted one at a time so I know what I'm getting. 

The SQLauncher is AWESOME.

I've been renaming all my map titles in the Quake folder to the actual name of the maps, and I can just use SQLauncher to play them. It takes a bit more time renaming everything, but it's much neater. And you will actually the map title.

Quake Injector is a bit buggy, I just prefer to download maps from Quaddicted one at a time so I know what I'm getting. 

mh: should unlit water surfaces receive dynamic lights?

In the software renderer, that's impossible; surface caches needs surface subdivision.

ericw: I guess if someone happened to compile a map with TreeQBSP/tyrutils and used "-splitspecial", and then used whatever light tool was used for death32c.bsp, we could have false positives again

It wouldn't be a false positive. It would be a true positive, because the lack of the TEX_SPECIAL flag would make the light compiler treat liquid surfaces identically to regular surfaces. The only problem would be the lack of backlights, which can be solved by recompiling the lighting alone, without modifying the BSP data. 

Specifically: should unlit water surfaces receive dynamic lights?
I'd say it's up to each engine. I'd personally leave unlit water without dynamic lights.

I've pretty much decided that translucent objects of all kinds (water, glass, etc) don't get lit - they're translucent so light goes through them rather than reflects off them. So instead they're drawn fullbright but with translucency.
I'm with Pritchard, IMHO semi-transparent glass and lit water should still get lightmapped. Fitzquake 0.85 does lightmaps on func_'s with the alpha key < 1, though I'm not sure how many maps make use of lightmapping on glass, Fifth & I exploited it in ad_tfuma.bsp for example: http://i.imgur.com/rhO6awC.jpg

The logic, I guess, is that you can see shadows on dirty, scratched up windows.

It wouldn't be a false positive. It would be a true positive, because the lack of the TEX_SPECIAL flag would make the light compiler treat liquid surfaces identically to regular surfaces.
Ah right.. in that case, even the vanilla id light.exe would generate lightmaps for the water/sky. I guess a better question is, how many released maps (e.g. in quaddicted, or idgames) used TreeQBSP's -splitspecial option, and thus have lightmaps for their liquids? This would be a time when it's handy to have a mirror of quaddicted and run a script across all of the maps.

I'm guessing the answer is "0". 

translucent water *has* to get lightmapped. In fact, the translucency is going to be essential to sell the lightmapping as convincing, otherwise water is going to look like pea soup. 

If you can see the surface, then it reflects light. A certain amount of light passes through it, but not all of it.

Besides, like I said earlier, translucent objects (or any objects, really) glowing in the dark doesn't make any sense in a lot of cases. 

Wondering if this is even possible from an engine perspective? One of my answers in sock's recent survey post:

5. Are you put off by certain monster (horde) setups?

No. I don't love excessive in-fighting though. It's frustrating and I wish modern source ports could have a "slider" for in-fighting. Perhaps: "never>rarely>normal"  

That would get very buggy very fast. Play a map like ad_tfuma, it opens with a bunch of infighting. If that was disabled it wouldn't be the same. 

Infighting doesn't come from the engine anyway, it comes from the QC. It would be totally inappropriate to put any kind of control over it into the engine. 

I was asking if it was feasible.

re: ad-tfuma Not sure if it would keep you from playing the map though? Also not really necessary in AD as mappers can add a key to suppress infighting. So it would really just be for vanilla Quake. As I asked: Wondering if this is even possible from an engine perspective?

mh - why would it be "inappropriate" to add this feature to an engine? 

is planned and set up using triggers.

I'm not sure why you would want to alter this behaviour as this is my vision for the map. 

the logic of the game is in QuakeC
the monsters are in QuakeC
the infighting rules are in QuakeC

the only thing that the engine can do is put the slider in the menu 

I mentioned above this would be for vanilla Quake not AD and it's just an inquiry. Not trying to destroy your art. ;)

@topher yeah I get that's how it works. It was more of an academic question. Wondering if you could modify QC behavior through the engine. Apparently not. 

my guess is that it's possible but it will be hacky, bug prone and harder than modifying and recompiling a new progs.dat 

Wondering if you could modify QC behavior through the engine. Apparently not.

Well the engine can change the QC, but that's not really the point. The logic that deals with infighting is all in the QC, so all you could really do in the engine is do something like a truly disgusting hack such as preventing self.enemy from changing on an entity if certain conditions are met. However, you could only reliably guarantee it working for id1 (the assumptions you make in the engine to make it work for id1 wouldn't necessarily be valid under any other mod), and any other mod being run under it could break in all sorts of subtle ways. 

mh - why would it be "inappropriate" to add this feature to an engine?

First read Kinn's answer just above - that covers the technical reasons why.

Then read Fifth's answer because it covers the gameplay/modder perspective.

I know you said that you were asking about vanilla Quake, not AD, but it's still relevant. Infighting is a designed behaviour of vanilla Quake - it's even mentioned in the Quake manual:
Q: Did I really see two monsters fighting each other?
A: Probably. Some monsters hate one another almost as much as they hate you. You can use this to your advantage (exercise left up to the reader).

Infighting is game logic and the correct place to modify game logic is in the QC code. The engine should not try to inject modifications to QC code. I'm actually shocked and appalled that this even has to be explained. If you want to modify the QC code, the correct thing to do is... modify the QC code. Make a mod with reduced infighting and play that instead. 

If you really want such a feature then make your own progs or throw money/sexual favours at someone to do it. 

I'd do it if you threw money at me ;)

I actually previously modified this behavior in FvF. I think my monsters only have a 50% chance of getting mad at each other if they hit each other by accident. If they get hit intentionally by another monster, then they immediately retaliate (they just check to see if the owner of the attack is a monster, and they sometimes ignore the attack if it was not intentional -- if the owner of the attack has you set as its enemy, then it was intentional and you return the favor). This cuts down on the monster infighting, so they can focus more on killing the FvF players >:D But it's still fun to try and get the monsters to fight with each other instead of them all turning their attention on you!


Buy yeah, this is not something the engine should really be tinkering with.

Except MAYBE as a secret hidden setting which is defaulted off; like a new, harder difficulty mode or something. But I think there are plenty of other issues Mark V can be addressing before adding something like that.... 

I could be mistaken but I think the infighting behaviour is slightly different in AD and they don't instantly change target unless you do a certain amount of damage. 

could someone sent a config with basic graphics to to improve the fps (dx9_mark_v.exe)?

My notebook isn't very good, onboard video and etc.
what's the command for save a config? 

My email: hmdbrandao@gmail.com

How can i put the Time (with high size) on the center of the screen?

Tks everyone! 

We need more women in Func_. 

The only major default thing that might help FPS is to disable mirrors (which really should be disabled by default):

r_mirroralpha 1


To always show the clock, set:

scr_clock 1

(Baker, the help info for scr_clock is incorrect. It says 0 = deathmatch only, and -1 = never. That info is reversed).

I think the only thing you can do to make the clock bigger is to make your HUD bigger, like:

scr_scaleauto 0
scr_sbarscale 2 

Onboard video is actually capable of running fast without needing to compromise on quality. The problem isn't onboard video, the problem is how the engine is coded.

One of FitzQuake's claims is "if you can run glquake, you can probably run Fitzquake". Unfortunately that means that it tends to brute-force certain things on the CPU where a more elegant, faster approach often exists.

MarkV has inherited that tendency, so hence it suffers from the same problems.

No amount of "go faster" config options can fix that; it needs a complete rewrite.

It's a fallacy to think that the older API is faster with low-end hardware. Low-end hardware these days supports shaders and VBOs; really old low-end hardware still supports shaders and VBOs. Shaders and VBOs allow a faster renderer.

I recommend that you run QuakeSpasm and run it with all extensions enabled; odds are that it will run substantially faster than DX9 MarkV, even on Intel hardware.