and reading his above comment,

looks like 0x4000 (16384 decimal) is the flag that would be most compatible with FTE. 

Sometime in the next 24 hours I'll grab bush1.mdl and palmleav.mdl (a palm tree) from Kurok, edit the model flag in QME and post a Windows OpenGL .exe Mark V with the implementation. 

I'd better get my modelling trousers on 

Another possible way to specify that the model should be alpha masked is making the skin name start with "{". Hexen2's TEX_HOLEY model flag (16384) seems OK though. Are hexen 2 and quake mdl's the same format, aside from extra flags used by h2?

I was reading the uhexen2 source, it looks like both palette index 0 and 255 are transparent for TEX_HOLEY, at least in uhexen2. But we would just use 255 since that's what is used elsewhere in quake.

Last thing: it might be worth comparing this with a different approach: trying obj2map's new UV/texturing import feature, and then either compile the foliage maps to bsp (disadvantage: lighting would be static) or even try using itendswithtens's new map instance inserter tool to automate pasting prefabs in your map (?). My light tool can even raytrace through the fence textures properly, giving natural shadows under trees. This route is likely more of a pain to set up, but it would have the advantage of working in all the engines that already support "{" textures. 

Quake loads up a hexen2 .mdl fine. Other than that, I don't know how the formats differ.

I'm thinking of making the foliage move in some cases, so bsp wouldn't be great for that.

Also I just don't think bsp feels right for the sort of geometry I have in mind.

Also: plant monsters. 

killer hedges / vines.. looking forward to seeing this! 

Alphamasked MDL texture support has existed in Makaqu for ages, and Super8 inherited it.

I've also implemented it in the x86 ASM version of the MDL drawing code, for fast performance. 

So far, I've deleted the Config, and It still crashes on startup. Is it not compatible with Windows 7? 

Experimental Windows GL Build with alpha texture support for models (with changed source files)

Palette 255 is transparent color, model must have flag 0x4000 set in the .mdl QME 3.1.

A test mod is supplied. Type in console:
"game alphamaskmodeltexture; map start" and watch the lavaball in the HARD hallway which has been replaced with palm leave .mdl.

And looks like this:

Screenshot 

I develop on Windows 7. I don't know why you are having the problem, somewhere around 100 ppl have used Mark V WinQuake.

If you are committed to helping me identify the nature of the problem, I might be able to get it running for you if you are willing to post logs and such. I think in another thread Skiffy said he had a problem like yours.

Let me know. 

@ericw - agreed, heh.

@mk - that's awesome that Makaqu has that feature already. Even more awesome that you have asm for it. 

Wow, that's perfect. Thanks so much for this!

I'm going to be making a lot of assets that showcase this in my mod. Might even be ready for the 20th anniversary expo! 

ok, i'm sold. that looks terrific! 

@necros -- updated the above download raising max static entities from 512 to 8192.

Client-side entities are very small and just keep track a couple of dozen numbers/positions/times and the static limit was just an array of client-side entities and nothing more.

(MH and Spike point out other limiting factors.) 

@necros -- updated the above download raising max static entities from 512 to 8192.

One would hope that at some point you'll drop the array and just Hunk_Alloc each entity_t as each static entity comes in. 

I know how to do it, but until classic-like Quake engines implement "add static entities at any time" for dead monsters and gibs and the like, static entities is basically just a fixed array that happens during connection to the map.

Compounded by: what if a monster died on a lift or temporary floor -- since static entities don't move? And then if you fix that, you break standard Quake physics.

And the entity_t struct stores a ton of lerp data and other things that don't apply to static entities --- which never move. I killed the grunt on the opening bridge in Metal Monstrocity and then shot the bridge release and then was slightly distressed that his body just floated in the air, but in DarkPlaces he'd fall into the pit when the bridge is gone.

Optimization and Quake can be a paradox or at best a rabbit-hole with no known end. Proof that Quake was made by an HP Lovecraft monster and somewhere Cthulu is laughing ... 

wait, what? monsters don't get made static when they die.
monster corpses float in the air only because the fl_onground flag doesn't get cleared so the engine ignores it when doing physics updates. Darkplaces probably just fixes that behaviour. 

actually wait... if a corpse floats in the air when a lift goes down, that's some kind of bug because corpses DO go down with lifts and such. maybe a corner was on the ledge? 

Monsters don't get made static when they die.

I was arguing that in some ways, they should.

If standard QuakeC exposed the ability to make create new static entities at any time like DarkPlaces permits.

Then QuakeC doesn't waste time performing physics or sending network traffic on dead monster bodies.

(Then I mention the problem with this is that if you make dead monster bodies static entities --- they don't experience physics and some places they should). 

attachments could be used on static ents so that corpses could move with the platform.
which would work fine until the platform is killtargetted and then spawned as something else... yay corpses riding your nails!...
might be fun. 

...until classic-like Quake engines implement "add static entities at any time" for dead monsters and gibs and the like, static entities is basically just a fixed array that happens during connection to the map

Hmmm - I'm not sure how this is potentially a blocker.

To be clear, the suggestion to just Hunk_Alloc each static ent as it comes in is nothing to do with being able to makestatic at any time.

It's to do with (1) removing the limit on static entities so you don't get in an arms race with mods, and (2) saving memory while doing so.

Both of which are IMO useful and essential things to have in any engine, irrespective of presence or absence of other features. 

sizeof(entity_t) = 336 bytes on 32-bit (pretty small size). 336 bytes x 8192 statics = 2.7 MB.

You are correct in engine design and philosophy.

But if I rewired it to do as you suggest, Mr. end user won't know even know he saved around 2.7 MB in RAM on all but the most unusual maps.

I mean, I raised the default zone allocation to 8 MB. That's probably 6 MB more than the most rare situation would actually need.

And both Mark V and Quakespasm default to 256 MB -heapsize. Which is about double the memory any map actually requires.

/At least those are my thoughts 

What's the drive to optimize for memory usage in Quake engines these days?

Is it programmer pride, or is there a solid tech reason? 

MH wrote DirectQ and RMQ engine (first BSP2 engine, MH designed BSP2) --- it has some slick memory management. FTE and DarkPlaces do as well, but I've only ever really looked at MH's stuff in relation to the memory management.

(Because MH writes really great code. Time permitting, I try to code in his clean style.)

Almost acquired the entirety of RMQ's dynamic memory management into Mark V in 2014.

I have unusually ambitious backwards compatibility goals because of another engine called ProQuake and realized that if I implemented full dynamic that non-dynamic memory engines (ProQuake, Qrack, Quakespasm, WinQuake, FitzQuake, etc.) wouldn't reliably be able to either connect (coop or over the internet) or playback demos with certainty.

To address that, would have to have a mechanism to set a hard limit. Ends up being a lot of work to be back where you started.

[So both Mark V and Quakespasm use 8192 entities as the limit by default.] 

'Why make maps better than id1?' :>

I think the other reason is the megamap format. Some things just don't work very well, like flickering lights.