ZDoom

No, the fixes only affect resource maintenance. The code to free the models has some serious issues.
Concerning your 'hack', please keep in mind if you in any way abuse undefined behavior I can't guarantee that it will remain functional. Use at your own risk!

Of course. I kept that in mind.

The brightmap "hack" still works.

I'm rather disappointed to hear it being referred to as a hack though. Before spending hours implementing it in a number of things that I was working on, I specifically asked, repeatedly, if it was considered a legitimate feature and therefore safe to use or not. Having been caught out before through not asking about such things I wanted to avoid similar problems again. I didn't receive an answer so, with the feature being very cool and being based on (what seemed like) sound principles (ie the skin is treated as a a texture in the engine and so using texture based features seems like fair game) I took a risk and used it.

So what is the brightmap hack. I do not follow editing techniques so I'm not in the loop.

Graf Zahl: http://forum.zdoom.org/viewtopic.php?f= ... tmap+model

As the thread linked by Nash demonstrates, put your model skin in the textures folder and it can then be given a brightmap (perhaps other things too - like animation?). When applied to a model, the brightmap is respected and so the model gets a brightmapped skin.



The initial post in that thread implies that to get this working the model should also be in the textures folder. This is almost certainly bad practice (putting a non-texture lump into the texture namespace). However, MODELDEF allows the skin and model to have different paths and so the skin can be placed in the the textures folder and the model in a more suitable location. Both then need to be identified correctly in modeldef.



The only restriction that I have noticed is that (in accordance with standard texture behaviour) the skin needs to have a name of no more than 8 characters (plus extension) before it can be given a brightmap.

I would still prefer to see a dedicated solution. (Brightmap property for model skins, presumably.)

If model skins are already effectively handled just like textures then perhaps the "dedicated solution" is to officially allow them to be used in the textures namespace (ie, the situation that currently works). That way, anything applicable that can be done with a texture could also be done with a skin... I think.

Or, perhaps, defining a graphic as a skin in modeldef could implicitly put it in the textures namespace?