You should totally make a catalogue of screenshots documenting how settings change the looks. That would be so super useful. 

i've been thinking of doing something like that. i'm just a lazy bum. :( 

necros

Yeah, you definitely can! I set it up as per these instructions ...

http://ouns.nexuizninjaz.com/dev:programming_introduction#working_with_the_code

I think that's the right link, it's not loading at the moment for whatever reason. But basically it's using the Code:Blocks IDE and installing a QuakeC plugin. I still compile from outside the environment but it gives you stuff like syntax highlighting, searching through the entire project, intellisense, etc. 

thanks for pointing me to that! i had no idea! :D 

been out of the loop for a while. Does anyone know any ways of tricking Vis into thinking an area is not visible even when it normally would be? For reasons that are fairly fiddly to explain, it doesn't matter if it causes a whopping great HOM. 

Only two things I can think of are:
* Using the version of vis that lets you set a maximum visibility range - afraid I can't remember which one this is but if you're interested I'm sure someone can supply it.

* Using skip brushes to obscure it, but then that does actually create a physical block as well as a vis block.

In theory the quake bsp format should support this kind of weird vis behaviour but I don't know of any examples in practice. 

i would use a real directional sun in addition to the global illumination -- the latter is just for filling in light that would be coming from the rest of the sky. if you have a lack of shadows it's the lack of a real sun :) 

It would help if you described better exactly what it's for. I would say there's little you can do to trick VIS. Skip works if you don't mind a HOM (or grey/red void view for those who use gl_clear), but this sounds like a very hacky solution, unless you're maybe thinking about using it in a hint brush sort of way, masked with a func_illusionary or something like that.

Has anyone every experimented with that maximum visibility range thing? Does it even work? 

Tried to use it, its inconsistent at best, random at worst. Cant use it like q3map2. Afair hvis has it. 

necros: that link to the multithreading vis doesn't work...

negke - hard to describe. I just wondered if i could sticky-tape up some bullshit I did caused by years of working with engines where you have to do all the geometry culling manually. It's no biggie - I can easily rework my layout to play nicer with Quake. 

Cheers for the info. max vis distance sounds interesting but i can't really think of it being useful in my map. 

try this one: http://www.quaketastic.com/upload/files/tools/windows/wvis_20100117.7z

sorry, i didn't check when i posted it. 

nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

That one has a bug, http://www.quaddicted.com/files/tools/wvis_20100119.7z is the right one. 

negke was bugging me about how I keep buggy and outdated files to which I replied that I do and that someone should write a nice guide on http://www.quaddicted.com/tools/map_compilers instead 

i knew the date was wrong (17 instead of 19) but i figured it wasn't anything important. :x 

http://www.quaketastic.com/upload/files/tools/windows/level_editors/wvis_final.zip 

that should probably be moved into /upload/files/tools/windows/misc/ instead of /upload/files/tools/windows/level_editors

that's actually why i posted the wrong one earlier, i wasn't looking in level_editors, just misc. 

i am making a quake 1 map and when i test it using the darkplaces engine, i do not see any problems. i loaded it up in quakespasm engine to test compatibility with other engines and i get this hall of mirrors effect when i walk past a certain point in the map.

i tried to find out if the map has leaked by typing pointfile in the console but it says no pts file could be found. i checked qbsp.log, light.log and vis.log and the files do not mention any leaks. when i fire a rocket at the HOM, it ricochets and eventually the trail of particles appear at the opposite side of the map.

here are two pictures of the bug i am seeing:
http://i.imgur.com/S4oS4h.jpg
http://i.imgur.com/ChU2Dh.jpg
http://imgur.com/a/E1xv0

any tips on how to get rid of this bug? it does not occur when using darkplaces engine to test the map.

i am using the compile tools found at this page:
http://user.tninet.se/~xir870k/
i am using the wvis_final.zip WVis 2.31 version of Vis.exe 

Does your map exceed 4096 units from the origin in any direction? That would explain it, this is a limitation of most quake protocols, exceptions include the darkplaces protocol and the RMQ protocol. 

That's the 4096 effect. Move the whole map until it's inside the 4096/4096, -4096/-4096 square. 

it seems that this is correct, looking in the editor, the HOM is appearing at the 4096 line on the x-axis in the editor. i had started at the origin at started building north from there. moving the entire map down to fit in this 4096 limit has fixed the bug. thank you for helping! 

from necros: the problem is that you only have 16 floats that you can carry across to other maps, 10 of which are already in use. if you wanted to do anything more complex than fire a few triggers off, you're out of luck.
the best you could hope to achieve is to use bit fields on the 6 (7 if you get rid of one parm that's not really needed) to get 6 * 24 = 144 on/off states. and that's incredibly limited.

I've been thinking about this - you could free up some more parms by combining them in a way that doesn't feel too hacky. For example...

QuakeC's floats are 32-bit right? Does that mean you get 7 sig. digits? If so, you can reduce the # of parms needed to store all the info, e.g. Parm4 could store counts for both shells and nails; you need 3 digits for each - e.g. if you had 52 shells and 143 nails, then you could extract this info from the number 143052 (to get the # nails, just divide by 1000 and round down - getting the shell count is also trivial). The other info for cells, rockets, health, armorvalue and whatnot could also be compressed to make full use of the available digits.

Also am i right in thinking parm9 can be ditched? (armor type can be stored in parm1 - items) and so could parm8 - the player's currently held weapon could just use the seventh digit in one of the ammo count parms.

By my estimates this could free up 5 of the currently used parms...

Maybe this is a bit silly i dunno. 

yeah, you get 7 digits. i guess you could even store a third 3 digit number in the decimals?
floor the number, and subtract it from the original, then multiply by 1000.

that's really clever, storing multiple ammunition counts into one parm! :)

and yeah, you can totally get rid of the armor type. (that's what i meant about the parm that's not needed)

you could even get a few more flags by moving temporary items out of the .items flag during parm saving/reading because they end up being zeroed anyway. things like keys and powerups. 

actually you can go full retard with it and only use 2 digits each to store health, shells, rockets and cells, because you can set 00 to mean 100 for both health and shells. (Health is never saved as zero, and shell count is never saved below 25) Also, you can do some silly cheese with flags to discriminate between 99 and 100 for rockets and cells too, I'm sure :}

I'm overthinking this aren't I? :}