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* 

Well how 'bout them apples, yeah it really is doing the adjustment ... missed it last time I checked. 

Hey Baker, not sure if you gonna work on it more, but...

Would it be possible to have support for foreign keyboard layouts?

Could you make the console fade-in faster? (maybe make it relative to vertical res)

Have the End key jump to the bottom of console log? (rather than having to hold page down for 30 secs) 

is a command, "conspeed" I think it is. 

I've run out of time to do anything except light touch-ups to correct bugs and I had to cut international keyboard support from my to-do list (along with many other things, sadly).

I wanted to get one final update out and actually moved that forward rather than late summer.

My time is up, and they'll send zombies and nazis --- and maybe even nazi zombies --- after me if I don't focus on my real world objectives. Go figure. 

Regardless, thanks for the great update :) 

Is there another way of minimizing it then? 

Yes the windows key is disabled when Mark V runs.

Fullscreen, you definitely want it disabled. Windowed mode, harder to say.

For windowed mode, I made the decision like this:

1) Mappers are really smart, know how to install engines, know how to use more than one.

2) Casual players are afraid of that stuff. And are way less likely to be pressing the Windows key for functionality when running the game because they probably are just "playing the game".

So I decided to err on the side of a casual player who just wants the game to work.

An uber intelligent mapper such as yourself could use Quakespasm or DirectQ or such if you are developing a map or mod and need that.

[Although, I'm betting Quakespasm likely disables that as well ... but I know Fitz 0.85 doesn't ...] 

 

Quakespasm also supports this.

Mark V's video code rewrite makes ALT-ENTER a very fast operation. 

There is something weird going on with the latest release
Fitz: 0.92 exe: 02:43:35 May 24 2013
(using version command)

After a while the enemies cannot take any more damage from the player. It is like their bounding box has moved/changed. If I quicksave and quickload the problem goes away and then gradually comes back. I have only encountered this problem with my latest map. 

I did some more investigating and it is not the bounding boxes, I can see them with the r_showbbox command. It is a time based event where enemies no longer take/receive damage. After a while I can just walk through them. I can't produce a save file to show what is happening because quick save/load fixes the problem (temporarily) 

Can you capture it in a demo? 

are they still damageable (blood particles vs grey puffs)?

can you get the edict # and check what the fields look like? (maybe make a tiny hack mod where the axe does an eprint of whatever it hits)