Should I switch FTEQW or are you coming back to Mark V eventually? 

Then he is on a break. It's not his first time off. There's still unfinished business before 2.0 and I am sure he'll get back to it. 

I'm aware of his time off. I was under the impression he worked on Mark V during the winter months. Fingers crossed. 

i've tried the hd textures, they work fine but skies remains the same. how do i enable hd skies? 

you mean skyboxes? 

no standard skies, in the hd pack linked in this thread all textures work except for skies. 

AFAIK MarkV doesn't support replacement of the standard skies. 

How is that true? Fourth line down in the original post states:

"* Full external texture support, DP naming convention"! 

ummm so yeah... I couldn't get it to load my custom sky1.tga(jpg) replacement. Odd that is. 

Skies in Quake are not regular textures. 

I'm having issues with fps on big maps like 1st and 3rd maps of "Unforgiven". FPS drops to 20 and there are delays in mouse work like i press "fire" button - it fires 2 seconds after and keeps firing when i unpressed the button. Tried to run these maps with default config and there is no change in the situation. Meantime DirectQ 1.9.2 runs these maps flawlesly (97-100 fps). Also checked different graphic setup. No result.

Windows XP Pro 32bit
Intel Core 2 Duo 1.86 GHZ
Nvidia GeForce 250 GTS 1024MB
RAM 3 GB 

Utilized Mark V v1.99 DirectX.

Even bigger problems with fps occur at Rubicon Rumbke Pack. Same mouse delays , fps down to 20-30 in some areas. 

External scrolling sky textures are usually comprised of two images, not one:

sky1_trans.tga (transparent overlay)
sky1_solid.tga (opaque underlay)

There are another two possible suffixes in some engines, but I don't remember the name. 

MarkV Direct3D is not the same as DirectQ, and you shouldn't expect the same performance.

To be specific: the reason DirectQ gets good performance is not Direct3D. It's batching, vertex buffers, multitexturing, shaders, etc, and this is all stuff that can be done in OpenGL too, if the engine author is willing to do so.

In the case of MarkV, Baker is not willing to do this. So in order to run in Direct3D, it needs to store out vertex data per frame, then try to mangle unoptimized OpenGL calls into something that works in Direct3D. You shouldn't be surprised if it doesn't always work well.

If you want an engine that has good performance in big maps by using the right kind of code, MarkV is not that engine. Use QuakeSpasm instead. 

Speaking of which, any chance QuakeSpasm will ever support Nehahra? 

Quakespasm is not in active development ATM. So there's that little issue. 

True, but FWIW folks shouldn't read that as "dead project". Updates were still landing in the codebase through the end of 2018. So nothing going at the moment, but Quakespasm development seems to come in spurts.

Dunno if those developers have ever commented on the likelihood of Nehahra support though.