the gibs from zombies could just bounce around like tarbabies, leaving behind blood tracers. maybe they cold die out naturally after a while. 

I sort of think when you've gibbed a zombie it should cease to be a threat. The gibs could stay there making squishy noises and the head could continue to groan for atmosphere.

Alternatively if you go with the idea of all the gibs reforming in to something they could turn in to one of those blob things.

Or other monsters could pick up zombie gibs as health packs! 

Make the player able to carry a zombie head and give him an achievement if he gets it to the helicopter.

More serious suggestion: Let the player collect gibs for some reward (per level and per game), be it just a number or something "real". I liked the coins in ne_ruins. It would be a tacked-on game feature the player can choose to participate in or not with not big impact on the game world (unless you present it as such). 

Already eats gibs and heads btw - once they've got enough stock they cack out a zombie.

Spirit - that reminds me of a pack I did in Quake2, which had the player placing 3 commander heads on a tomb in the hub for a reward... 

In e2m2rq, I died when the lava began to rise. After reload, it appeared as if I was still in the lava visually. I wasn't taking damage, but my vision was warping as if under water and everything had a yellow tint. 

Moving liquid brushes use a stuffcmd of v_cshift to set the colour shift, but this persists until another such stuffcmd clears it. The same applies to stuffing fog, and any other such cvar.

You can see another effect of the same bug if you go to the green fog area in e3m3rq, save your game, exit Quake, then start again and reload.

Anything else using stuffcmd will suffer from similar.

It's something we're aware of but haven't yet found a robust solution for. Ideally some kind of "area flags" would be best, but that's going to really disrupt the file formats. 

just use non-saved vars for that.

ie:
nosave .float isCShiftReset

along with an
if (!self.isCShiftReset)
resetCShift(self);

in a player think. 

There are a number of different ways of tackling it when you die/respawn. We could also stuff default values on respawn, or track changes made via stuffcmd engine-side.

The big problem is across the save/exit Quake/restart Quake/load boundary. The is visible too in other maps such as ne_tower, where r_wateralpha is stuffed after you shoot out the wooden boards at the start. Go halfway up the tower, save, exit, restart, load and go back down - water is now opaque again.

Right now I don't see a clean way of resolving this without format modifications.

Nahahra has a RestoreGame QC function which is used to re-stuff specific values that may be used in a map. That's quite a nasty way of doing it IMO (I'd prefer to see them as worldspawn entries) and it still doesn't deal with the case where values can dynamically change as you progress through a map.

Extending the save game system seems to be the only way (possibly by adding a state file so as to leave .sav files intact and usable in other engines) but I'm wary of the idea in case I've missed anything. 

Please read ....

http://forums.inside3d.com/viewtopic.php?f=2&t=4601

Please! This save game crap must die.

Save games are for when you exit Quake and restart. Not for dying and respawning. Better concept in thread. 

My idea would only work for coop :( 

Somebody over at Q3World posted a link to a high resolution texture pack.

http://raynescorner.weebly.com/textures.html

Maybe of help to your project as your are using stuff that size (1024x1024). Most of the texture are generic materials which could be useful for rock, concrete and brick etc. 

I get the above warning whenever I try to run the demo. I have never seen this before. Anyone know what it is, and how to fix it? 

What's your gfx card?

Also, there are two "Multitexture Not Supported" errors in the engine - "multitexture not supported (GetProcAddress failed)" and "multitexture not supported (extension not found)" - which of them do you get? 

Posted to the internal forum, thanks. 

I get this error too when I tried to run the engine alone (i.e. it's running OK when "-game rmqwinter11" has been added to its command line).

I deleted the config.cfg in id1 folder, and then it runs OK too. 

There's something incompatible in your config. It'll default to that config if there isn't one in the mod folder - you can place an empty one there (or one without whatever the offending line is) to avoid losing or moving your id1 config.

As to the cause - dunno. 

http://youtu.be/0rqP7sqoSbg
Best bug ever. Make it official. 

I've no idea how a config setting could affect the ability to detect a GL extension. The only thing that would make any sense might be if you've specified a bad video mode for which OpenGL acceleration is unavailable (like maybe a 16-bit mode on some funky hardware that may hypothetically not accelerate 16-bit modes, although I've never seen that happen). 

Hahah - thats the magic system run amok. They're duplicating themselves and dimension dooring to your position. Skill 3?

If you build a test level with a vore in it try setting caster_level to 5+ and playing on NM.

They'll call in lightning from an empty sky, summon hordes and forcewall you.

Facewall is basically 'everything in this big circle gets gibbed' 

Yesterday I got the same vore duplication effect on e4m2. It was surprising - first I thought it just teleported near to me but it was sending copies after me. A bug I hope :) 

The code is unfinished, so buggy as well. 

The application has failed to start because d3dx9_43.dll was not found. Re-installing the application may fix this problem.

I got the above warning when I tried to run the engine with 'rmqwinter11' added. I don't use a custom .cfg. I'm not sure what kind of graphics card I have, my computer IQ is pretty low. 

DirectQ currently can't run this - you'll need to wait on the next version which will support it.

For that error you just need to update your DirectX to the latest version. (Having D3D10 or 11 isn't enough - D3D9 is completely separate and needs it's own update. Updating D3D9 won't affect your install of 10 or 11 if you have them.) 

I have:

NVIDIA GeForce2 MX/MX 400

This computer is almost ten years old, so it's probably not cutting edge technology. 

Never gonna work.

DirectQ absolutely requires vertex and pixel shader support at D3D9 or better level. That means a GeForce FX or better. Even an Intel 915 chip will run it, but the shader support is required.

DirectQ is not going to be a good engine for RMQ for at least 6 months though - the devil is in the dynamic lights - it runs incredibly jerky and sluggish when they start going (and RMQ is full of them).