Maybe it disconnects first. 

Thanks, 0.99 vs2008 version works. The winquake version wouldn't start. (Win7 Pro x64 i7-4770 integrated graphics) 

If I have an autoexec.cfg then the sky is drawn over the world. Anyone else having this issue?

https://www.dropbox.com/s/kxkl7j9mrlj22rh/bug.jpg?dl=0

I thought it was a setting in the file but it seems that any entry will cause the problem. 

I tried to get around this by having a file called 1.cfg (the only setting being r_shadows 1), I typed exec 1.cfg and I get the same sky drawing error. 

I just went back and re-read the thread and realised there's a bug with shadows in the latest build...

What a weird coincidence that this was the only setting I decided to keep. Losing my marbles. 

The Nehahra Fog doesn't work in Mark V. I remember Directq used to have a problem with this. 

Nehahra is an interesting thing, especially the fog. Here is what I did ...

1) DPNehahra is the official engine for Nehahra.
2) Because dpnehahra is the official engine, I view how dpnehahra displays a map as correct and only way it should be displayed.

Load up the map in question in dpnehahra:

A) If dpnehahra shows fog on the map, I have a bug.
B) If dpnehahra does NOT show fog, I am complying to the official presentation.

JoeQuake and derivatives present the maps in a different way than DPNehahra.

But JoeQuake didn't exist when Nehahra was released and I view any differences in map presentation between JoeQuake and DPNehahra to be JoeQuake presenting the maps wrong.

Case in point, there is a DP Nehahra expansion map with a skybox and non-standard fog keys.

1) If I load up the map in DPNehahra, I see the sky but no fog.
2) If I load up the map in JoeQuake, I see fog but no sky.

I had to pick which way to do it, I picked the DPNehahra way. 

the fog is a lesser issue 

But DPnehehra has the fog in Neh2m5, but Mark V does not 

Since you are playing Nehahra, if you happen to know where any of the smoke emitters are, let me know. I spent a lot of time trying to get the sprite 32 support perfect and such, but the maps are so large and I couldn't find a smoke emitter. 

Does Mark V support external fullbright maps for brushes, like Darkplaces do? What do I have to do? I already have some xxx.tga and xxx_glow.tga in my ID1/textures directory. Mark V reads the texture, but the _glow thing doesn't seem to work. How do I fullbright a brush surface?

Also, is there support for alpha translucency? How do I do it? 

Fitzquake supports glow textures, so i would assume it also works in Mark V, but maybe there's something that changed. 

Here is a hideous screenshot demonstrating _glow textures against a test folder:

http://quakeone.com/proquake/media/sfloor4_2_glow.png

It uses the following 2 textures that happen to be .pcx format

http://quakeone.com/proquake/media/sfloor4_2.pcx

http://quakeone.com/proquake/media/sfloor4_2_glow.pcx 

Alpha translucency is not a texture feature in any Quake engine except DarkPlaces because it is a recipe for cheating (FTE ... ezQuake ... any NQ engine etc do not support them.). Somewhere earlier in this thread there is a discussion involving Spike, Sock and myself and others on that topic.

In fact, if you having trouble with textures I would recommend removing the alpha channels.

I think the alpha channels are ignored in FitzQuake (not a common topic, so from memory I can't recall.)

If you want things like glass in a map, you have to set the entity alpha of the brush (for instance alpha 0.5.

Both Mark V and Quakespasm support alpha masked (a pure mask like a fence where each pixel is either fully transparent or fully opaque -- there is no translucency) and the texture in the map must begin with a { and Quake color #255 is the mask color.) 

The current Mark V beta, unlike Quakespasm, only supports alpha masked { fence-like textures on entities. Quakespasm supports them on the world model, but this shows void (areas outside the map) but Rubicon Rumble needed that because of a visibility issue that has since been resolved (i.e. masked textures really should not be on anything except entities). 

Looks like we're double-posting here and at QuakeOne. My bad :( Hope it's all useful.

Anyway, I just downloaded the two textures you posted to ID1/textures folder. Here is another hideous screenshot for you:
http://i3.photobucket.com/albums/y80/amurad/Games/scrn_zps1e3wcnqi.jpg

It's your texture pointer showing Mark V is loading sfloor4_2.pcx, but not sfloor4_2_glow.pcx.

Are you sure we're running the same version? Mine is 05:49:41 Jul 13 2014 

And here is the fence-like alpha blended working like a charm (on the background, sfloor4_2 fullbright not working):

http://i3.photobucket.com/albums/y80/amurad/Games/scrn2_zps9l2ffkid.jpg 

The screenshot above is a world brush, not an entity. So your engine alpha blends world geometry as well.

It's showing void where the brush touches the floor, wich makes perfect sense: the world brush subdivided the floor and the surface it hides was removed by the bsp compiler. Thing is, you can see thru this world brush, so you can see the hole the removed surface left.

I just tied the brush to a func_wall entity and recompiled the map. No void showing anymore. I'm gonna use it! 

I'm using the October 10 beta build which is known to have issues with drawing the sky on Nvidia cards due to a stencil operation and may have a couple of other things like that (which is why it was marked as a beta). The download is buried in the thread.

Words: It is unfortunate that work alpha gets used for everything but I do want to point out that no blending is occurring for "fence textures". Blending means it is combining 2 colors, fence textures are an alpha mask and isn't blending. 

sorry if I've it's been mentioned and I haven't noticed - is there any support (or planned support ;) )for Alpha masks on external textures?

Thanks for all your work on this so far, it's awesome. 

I don't remember if there is external texture support for the masked textures.

I would guess "no", but I can't remember because normally this is something I would do.

I think a roadblock was external textures for masked textures and the possibility of the masked texture having a fullbright component.

That is a complicated scenario to draw for external textures because fullbright is an additive blend but should only affect the masked area.

Which is quite a headache to devise the drawing for when almost no one even uses external textures, let alone masked textures. 

for alpha masked fence textures and fullbrights, you could process it at load time:

for the main texture, keep track of which pixels are < 0.666 alpha. On the glow map, set those pixels to pure black. This way the glowmap won't be visible on any screen pixels where the main texture is masked out.

I'm not sure if this will still cause tiny bleed overs where the glow slightly overhangs the hard edge of the mask, but it could be tweaked, maybe by raising the alpha threshold or something.

But at least this doesn't affect render code at all. 

In that screenshot I posted above, that transparent wall with yellow balls is a brush with an external TGA type 2 with an alpha channel, where white makes a pixel visible and anything else makes it invisible. So I would say yes, Mark V seem to support external alpha masked textures.

Tried the three EXE of the October beta. The WinQuake version wouldn't show external stuff anyway. The other two don't even have the r_texprefix_fence cvar :o

Please Baker, don't rip the transparency off the engine, I need it! Didn't follow the discussion, but a security solution can't be to cripple the engine. 

r_texprefix_fence cvar is gone because since Quakespasm adopted fence textures ported from Mark V with exclusively the prefix "{", it is no longer an option to pick a prefix. This is consistent with Half-Life and The Remake Quake engine and FTEQW. [Yeah, the WinQuake build doesn't seem to work]. 

@metslime. No doubt that work and I likely devised something like it.

I think the situation that was aggravating is the possibility of the regular texture and the glow texture replacement not being the same size and factoring in possible rescaling in the (rare) absence of power of 2 textures.

With normal _glow textures, this isn't a factor since there isn't a dependent relationship between the regular texture and the _glow one.