exe. doesnt start at all for me. just getting the usual "starting quake" window, then it just flushes out, no warning nothing.
:(
running xp sp3 on intel Chip ati video 

@mfx Hmmm. Does a previous version work ok? And flushes out = it exits or crash? I added multisample support that abuses that window, but seems your graphics card no like. I'll see what I can do to resolve that.

@necros --- no external .vis means that instead of vispatching your stock Quake maps for transparent water, you just use .vis you toss in the maps folder. I'm on a low bandwidth connection at the moment, in a few days when I'm back I'll upload something and show you what I mean.

@fifth -- You lost me. I can make a BSP with a texture named "{alphatexture" and it works. Why do you need external files? Am I missing something here? Or is something not working right about the engine and external textures? 

Shoot the wall several times in the same place.

Or use lightning gun. 

I didn't initially get that but Fribbles made a fish. 

Yeah the curly brace standard is actually one of the dumbest decisions I can think of. I'm saying the standard should be changed to a key tied to an entity brush instead.

(FYI, the curly brace conflicts with the .map standard formatting...)

Like I said, it really pissed off SleepwalkR and I can fully understand why (open up a .map file in notepad and realise why this was a terrible decision) 

previous ver. works fine.
this one it just doesnt Do anything than
just showing the starting window, no crash msg or sth. just disappearing from ram. 

no external .vis means that instead of vispatching your stock Quake maps for transparent water, you just use .vis you toss in the maps folder.

oh ok, i see what you mean about that. :)
changelog has some interesting things in it, thanks for doing this, baker. 

Why a brush entity key? Well we have this support with alpha, why not just set the key to something like "alphamask"?

I can relate to what your dislike of the curly braces.

I'm a decent Quake engine coder, but I know my place and I'm the wrong person to code anything that could be interpreted as a standard.

I named the experimental fog for Sock to look with an unlikeable name "beta_fogex" so it couldn't accidentally be interpreted as a standard, and likewise some of the experimental things I did with texture prefixes are console variables.

I'm not the right guy to make those kind of decisions. If I have any credibility with the 10-year engine devs (self-deprecating humor), it is that they know I'd wouldn't think of that doing anything like that.

Shorter version: Maybe ask people like metlslime, tyrann, preach and necros and such?

I'm just not the right guy. Seriously. 

Extract to quake/id1/maps folder

http://quake-1.com/docs/utils/visfiles_go_in_quake_id1_maps.zip

Then the original Quake maps are vispatched (unless you set "external_vis 0") to work with r_wateralpha.

It isn't that I think r_wateralpha is that great of a feature, but more that the vispatch process is extraordinarily painful since the original utilities will not work on Win64 even with DOSBox so someone looking to try that out can do it. 

If the mapper specifies external textures and they have an alpha mask defined (tga/png format) then load and use it. This does not require fancy name changes or lots of effort by mappers just an external texture directory with alpha textures.

QW and Q1DM players would be very upset because someone (a cheater) would use replacement textures with alpha to make walls "see through" that shouldn't be. 

people do that for a 17 year old game? 

@nitin
Yes.

@fifth
{ prefix is compatibility with halflife, but also distingushes between alpha-blended alphas, and alpha-tested alphas. Which is especially useful if you have both active on an entity at once.
In the case of internal textures, palette 255 is a valid palette. While unlikely, its possible that this particular palette index could be used on other textures not intended to be transparent upon the same brush entity. Additionally the image loader will likely need to replace this palette index with an average of its still-visible neighbours in order to avoid colour leakage (yay! HALOS!), which is not something that can easily be done without walking through the ent file and checking each model in a really slow and hacky way on a per-surface basis (with multiple copies of the texture - things get even more fun if the qbsp reused the surface in two separate inline models). Which is why a flag on the entity is a stupid way to do it.

That's why we use a { prefix for alpha tested surfaces. 

but it's incompatible with the .map format because curly braces are clearly already used for a different purpose (which appears to be containing sets of information together). This makes certain map editors (namely Trench) take a huge shit when the open curly braces aren't closed properly. :P

I'll leave it up to you coder types to sort out this mess, but I wouldn't mind having alpha mask textures for some of my upcoming maps (I have some nice ideas for them that I haven't seen yet). 

but it's annoying, and I wonder why you guys haven't chosen another character that doesn't have a semantics in the context of map files. 

In console

] r_texprefix_fence
"r_texprefix_fence" is "{"

] r_texprefix_fence "!"

Name mask textures !myfence

] r_texprefix_fence "fence_"

Name mask textures fence_1

You will be able to map with TrenchBroom and view the maps you make in Mark V with alpha masked (fence-ish) textures.

And maybe somehow this problem will come to a conclusion by time you have polished map. 

then fix Trench to parse by tokens like qbsp does, or to write texture names in quotes so that it doesn't trip over its own output.

If I read the code right, it looks like a texture name with a comma in it will break it too, with an infinite loop, but its written in c++ and the code flows all over the place, so I've no certainty over that. 

@Baker, I downloaded the new beta and I like noclip, notriggers :) good for testing. I LOVE the command auto-complete, my god about time! It even does map names within gamedir folders :)

I had to rewrite a large chain-reaction of things to implement proper auto-completion of everything.

It wasn't fun at all, but I was getting really tired of not having autocomplete and asked myself "Ok ... you engine code right? Are you going to kill this once and for all or just keep being aggravated".

I thought since this was the last Mark V, the choice was "regrets" or "no regrets" and I didn't want to look back on it with regret.

I had a play with the new fog and it feels back to front to me. I want original fog up close and then fade to specific colour at distance.

I tested the "alternate fog" on Masque of Red Death to see how surfaces look at a very far distances and they don't fade out to full gray with the settings I suggested.

The OpenGL 1.x fog options are pretty thin. There is linear fog, and whatever GL_EXP and GL_EXP2 do (which clearly involve exponents probably using distance).

I don't know if much better fog could be done in OpenGL 1.x using glFog (I somehow doubt it) and I think it would require someone with a particle effects shader mindset --- which is something I don't have.

[I haven't forgotten about mfx. Not sure when I'll have the chance to put out beta 2). 

Heh - I'm definitely no engine coder, I'm totally glad you're even considering supporting it! I really like this engine a lot BTW. Massive props :) 

The silver key door in e1m2 was non-solid for some reason. I had the SK but didn't need it to open the door as I just passed through. The released fiend was also able to pass through the closed door.

When using the engine to play DMSP2 I've notived that some enemy become somewhat impervious to fire. One grunt took almost 120 nails to drop. 

Will help me track down bug, I have a few suspects in mind. 

Here's demo of me making no impression...

http://www.quaketastic.com/upload/files/demos/dis_atlantis.dz

That one's on atlantis.bsp, but it's also happened on naughty2.bsp and the Travail DM maps as well. Sometimes there's no effect; sometimes one in ten or so shots hit. 

I think I need to double check changes I made when adding external .vis support. I'm able to reproduce the issue reliable. Thanks for the bug report. 

This is probably a dumb question but: what does "Automatic wide-screen FOV correction" in the readme file mean?

I thought this might be something like QuakeSpasm or Fodquake's FOV adjustment. Despite the discussion in the thread above. :-) But nope it doesn't seem to be doing that (in revision 9).

So is that readme line just talking about protecting the weapon viewmodel from FOV changes, then? Or is it something else? 

1) Adjusting the field of view calculations to be equivalent of a 4:3 aspect ratio.

The Mark V vs. Quakespasm FOV correction is the same calculation [although I don't know that the Quakespasm guys know this ;) ]

2) The viewmodel FOV "fix" is entirely separate from the above, but what it does is backs out the FOV calculation when rendering the weapon (viewmodel) so that the weapon does not get distorted if using, say, fov 110.

Note: I expect beta2 to be out later this week correcting the distrans discovery (grrr) and hopefully the issue preventing it running with mfx's video card. 

...I have a bug named after me *blushes*