if you notice in the SS, that none of the textures are aligned, that is because I selected all and reset textures in an effort to solve a problem with texture scale that was causing BSP to fail.. It worked but loading the map would still crash the engine. "Bad Surface Extants." it says.

I managed to compile a "working" version of the map by placing a giant brush in the middle of it, effectively blocking view to the other side. It runs fine apparently in Quakespasm no problem but the map was targeted for quakeworld and in QW its a disaster.

QS SS: http://i.imgur.com/22j6yh3.png
QW SS: http://i.imgur.com/4QWcwXM.png

I thought that running a full vis overnight might solve the QW issues but when I woke up it still had 33 hrs to go. Also in QW it takes some time for it to load and you need the -mem 128 command line too.

It was a lot of fun putting this map together but find that working within the the perimeters of QBSP and engine (somewhat restrictive) capabilities to be an unforeseen challenge. I'm still compelled to work on it, but a lot of my focus will be on scaling it back, or salvaging the more clever brushwork (by my standards) for more sensible application.

I loved mapping for Quake back in the day and find that modern editors are so fluid and responsive that it's very easy to become drunk with power. 

Which compilers did you use - does this occur with bjptools_xt or tyrutils_ericw? 

TxQBSP 1.13 I want to experiment more with the existing compilers though. 

Make sure that your faces are all set to 'world' alignment, not 'face'. (P.S. world/face terms used by Worldcraft/JACK/Hammer and may not match terminology for your editor) 

is so similar to a map I was working on over a year ago it's crazy... it took me a second to realise it wasnt the same map. 

This link should work for the fgd https://www.dropbox.com/s/lv4r7tmcspcz2gt/quake4ericwTools.fgd?dl=0 

Big thanks for this. 

how to create transparent glass? 

Introduce manganese dioxide into the manufacturing process. 

... is your friend ... (but I didn;t have link in mind where you could find it)

OK, others, please correct me if I do not remember properly:

1/ Create a brush using a "plain" water texture (i.e using only one color) and name it *<watername>: this wil be your glass

2/ Create a func_wall of the exact same size, and use a skip texture there

3/ Add skip tool in your list of compilation tool, after bsp process (bsp/skip/vis/light). So ultimately the func_wall will have its texture removed but remains solid (you can't pass through it), but the "water" texture remains gicing the glass texture visual.

4/ Load the map, and adjust r_water_alpha value in the console to a value that is below 1.. the closer to 0, the more transparent the glass.

Enjoy ! 

An alternative way is to use a solid color texture (such as grey) and make it a func_wall.

Add an alpha key with value of however transparent you want the glass (So .65 for example). 

... but I am not sure this is supported by all engines... not even sure the other techniques is working with all engines either.. though... 

https://www.quaddicted.com/reviews/mfxsp17.html

This map has an example of glass. It comes with a .map that you can look at to see how it was done. 

Neither technique would work with the original engines as far as I know, but I'm pretty sure that the alpha key has been a thing for a while... someone correct me if I'm wrong of course. 

alpha key doesn't always work as intented. I usually make teleporters' liquid a func_wall with alpha 1, but it often looks transparent anyway (I noticed that in videos/streams) 

Quakespasm supports seperate alpha for water/slime/lava/telefluid set in worldspawn just fyi :) 

What are the potential problems if exceeding the vertexes limit? I'm pretty much right at it now. However, only just noticed that I had exceeded it by roughly 4000 in MCE with no apparent downsides that I'm aware of?! 

Quakespasm supports seperate alpha for water/slime/lava/telefluid set in worldspawn just fyi :)

I must have missed it. 

BSP 29 has a hard limit of 65536 verts, because face edges reference verts with a 16-bit unsigned integer. I doubt any qbsp will let you exceed this and still write out a BSP 29 file because the map rendering would be totally messed up if it did.

Where was the warning / limit coming from? 

http://quakespasm.sourceforge.net/Quakespasm.html#ss6.3

func_wall with alpha 1, but it often looks transparent anyway (I noticed that in videos/streams)
What engine was that with? AFAIK that is a bug, at least with the Fitzquake / protocol 666 interpretation of alpha. the Fitz 0.85 code specifically mentions that "_alpha" "0" means to use r_wateralpha for liquids, but other "_alpha" values besides 0 take precedence over r_wateralpha 

Thanks so much. Bookmarked! 

TxQbsp reports WARNING: Vertexes 33657 exceed normal engine max 32767.

But it seems there are no consequences, maybe only in software Quake. 

vanilla's vertex limit is 65535 apparently.
I didn't check the asm to ensure that it doesn't sign extend, but otherwise the datatypes are already unsigned and thus already 65k. 

What engine was that with?

Quakespasm, don't know the version, I guess the recent one. Gotta check it out myself.
Btw it was with func_illusionary, not func_wall if that matters. Works correctly in latest mark v tho. 

Hi, I've been searching for some info but wasn't able to find anything conclusive. The map I'm working on is almost done, I've made some huge changes and the map is now fully playable in WinQuake, a program I've not used in... let's not say how long.

The only problem is greyflash, I know easily fixable by setting r_surfs and r_edges to say 10000, and the map runs perfect. I wan't to reduce the amount of polys being rendered so the map runs akin to and id map. Essentially max 800 surfs, 2400 edges. I am almost there, 80% of the map is below this limit.

Will doing a full vis help this? Haven't done it yet and it may take at least a day or so. Is there any other way to reduce what is rendered, I've already simplified and added "S turns." Any help is appreciated.

Thanks.