Ok now that I can see the original E2M1 at the end of the map it feels a lot better. :) Maybe the problem is my expectations of what a remake is? I assumed a remake is taking the original game and updating it visually, this mod is doing a lot more than this, in places it feels like a TC.

I think the layout got better at the end than the beginning and certainly got harder as I went on (good thing) especially liking the turrets (would have been nice to bring them out of the ground and then activate them)

Once I realize what you are doing with the MOD it feels a lot better and I can accept the changes and see it as a different version of Q1.

You (the team) certainly have my respect for taking on such a challenge as a remake of Q1 because everyone has their expectations of what that is going to be. Probably the hardest thing to get right is meeting everyone's idea what is important to Q1 and not.

mh, I switched graphic cards and the fps slow downs did not happen anymore. Everything was much better and I started to enjoy the map more.

I tried E3M1RQ and that was crazy dark for me and I died a lot! :P 

The name is something that's been complained about a lot. A remake for me is re-making something... to what level that's done depends on who's doing it.

A visual only remake seems the uh, quickest option. We chose everything, which is why it's taking so long :)

We get a lot of flak, but a lot of positive stuff as well.

The episode 3 maps are mine - it seems my working conditions (light) have badly influenced how bright the levels are. We're working on things behind the scenes to fix this up.

Not least lighting levels properly :P 

might be useful to make a console command that will display the player's current light level every frame like r_speeds.
this would actually make it scientific instead of just subjective: 'the area around this important door is only light level 30-40 which is too dark' as opposed to 'i can't see the door'.
i pretty much gave up on trying to light maps with any specificity because everyone's monitors are different. i just fall back on the brightness slider when people mention it. :( 

even zombie gibs are not exactly dead. So what can be done with zombie gibs to make them reflect that fact?

If a zombie misses, the thrown piece of flesh could chase the player. 

Enough zombie Gibs near each other could reform into a zombie, like the T-1000 

Zombie hands could chock the player, like in Blood 

http://www.youtube.com/watch?v=xAOKEIJ74R0&feature=player_embedded 

http://www.youtube.com/watch?v=wnlzqS1DzU8 

 

I had a slightly sick idea for zombies that go through a lifecycle, like insects or caterpillars into butterflies. Blow one up and it reforms into something else. It would definitely add replayability to areas of the map you've been in before, but I suspect it would only be effective if the player gets to see it reform (which would probably require a cutscene furst time). It might also piss off people aiming to get 100% kills.

@Necros - that's a pretty good idea; mind if I steal it? ;) 

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.