1. ALL engines should handle external bsp collision. Unless you rotated it.

2. You can't fix this unless you can find a way to change the size of the entity's bbox to be smaller. :( 

bleh. '2' is referring to the disappearing bmodel.
This is due to the bmodel's bbox being linked to too many visiblility 'areas'. the problem is that the engine has a limited number of links to visible areas and when that list fills up, it just starts removing other links and replacing them. 

Ah, hopefully won't be a problem with a full vis then? :/ 

I noticed that dropout in the beta but didn't think anything of it specifically because lots of the bmodels in my map did that and yes it got better after fullvis. 

In my experience, it tends to get worse with a full vis, but you won't know for sure until it's done. 

As well as the problem with it's size (which would affect any brush model type) try this:

gl_flashblend 0
Fire a rocket at it.

Ugly, isn't it? 

Does Mark V support luma on skin textures? 

Model replacement textures use the DarkPlaces external texture naming convention (so replacement textures for models go in the progs folder).

You can call them _glow or _luma (_glow is what Quake 3 uses.) 

After trial and error I got _luma to work. The thing is the _luma texture need to be sized to the original model skin NOT the replacement texture. So dropping in a replacement skin pack doesn't work out. 

I can't remember all the details, but it was really hard to add external texture support for .mdl for FitzQuake while sticking by the strengths of FitzQuake.

I can't remember what texture set I used to test the feature, but I wanted to keep with FitzQuake way of doing things which in this particular case involved some contortions.

FitzQuake, unlike other engines, doesn't stretch skins to accommodate OpenGL baseline compatibility and instead pads it. This made adding external texture support for .mdl difficult while still retaining the feature (which is good and avoid stretching). As far as I know, the replacement texture and the luma/glow texture being the same size should always work, but you seem to be saying it doesn't.

I'm not sure when I'll be back to doing a revision #8 of the engine, but clearly this will be checked out , rectified and documented in the readme. 

Checking for and using GL_ARB_texture_non_power_of_two as an optional path instead of using skin padding.

Also - and this is available in GL1.1 as well so it may appeal to you more - instead of recalculating the skin texcoords based on the padded size, just scale the texture matrix instead. You can keep the original skin texcoords and have different sized skins this way. 

Extension would be extremely useful in FitzQuake, ultimately. Because the padding stuff --- and that code was ingenious --- but it really increases the overhead.

Something fun about non_power_of_two --> the texture you download is the one you uploaded ;-) so in theory, one might even be able to super-optimize the Fitz texture manager to not even need to store raw pixels source location (* I am aware of the exceptions here and there).

re: Texture matrix scaling, may I trouble you for a really simple example (which I would normally do at I3D except it is rather broken)?

I've never done anything with the texture matrix, but a simple example and I'm sure I could take it from there with ease ... 

Something like this should work:

void GL_PadAliasSkin (aliashdr_t *hdr, gltexture_t *tex)
{
glMatrixMode (GL_TEXTURE);
glLoadIdentity ();
glScalef ((float) hdr->skinwidth / (float) tex->width, (float) hdr->skinheight / (float) tex->height, 1.0f);
glMatrixMode (GL_MODELVIEW);
}


void GL_UnpadAliasSkin (void)
{
glMatrixMode (GL_TEXTURE);
glLoadIdentity ();
glMatrixMode (GL_MODELVIEW);
} 

MH adds Baker XP +1 for the Nth time, where N is getting to be a sizable number ... 

You can also translate and rotate, or even do wacky crap like load perspective onto it. Very handy stuff, and a far more elegant solution to many problems than trying to brute-force it in C code. 

Would it be possible to have a map key to set light level on static entities? 

I remember asking when working on statics in my last map
and I thought it was not possible.
So the only way out was resetting the gammalevel of their skinfiles. 

It should be possible but would need a protocol change as statics are sent from the server to the client during connection time. You'd also need to define how it works with coloured light and whether or not they should be affected by dynamic lights too. 

I'm trying to use the -basedir command-line option and something is off. (This is on Windows 7.)

If the path doesn't have any spaces in it, all is fine. Let's say the folder containing id1 is named "foobar" at the root of the C drive:

fitzquake_mark_5.exe -basedir C:\foobar

That works. But if the folder name is "foo bar" I'm out of luck. This doesn't work:

fitzquake_mark_5.exe -basedir "C:\foo bar"

Using the "shortname" (barf) of the path-with-spaces does work:

fitzquake_mark_5.exe -basedir C:\FOOBAR~1


This isn't an emergency at all and I'm likely just making some stupid mistake, but FYI. (I ran across this while trying to write up some info on how to use different Quake engines.)

FWIW, QuakeSpasm does handle the path with spaces OK. 

@Baker, Is there any plans for another update soon? 

I got your private message. I'll respond in thread @ I3D. 

 

I am not sure what you mean by ARG, but this is me trying to contact Baker. I am planning to tie up loose ends on the development of my MOD and I want to modify the MarkV engine so I can distribute it in my final zip file. I tried emails, private messages and finally this place, hence the weird reply.

Baker is a very tricky person to contact! :) 

A roundabout way.

Or, possibly, if we chased up the link to I3d we'd find some hidden ITS release... :)