Ah, forgot what I wrote above, wrong thread.

That being said, amazing episode. It felt almost like an official release, similar to DOPA. The mod blends in quite nicely. Always hated when you lost armor in spite of having the Pentagram active, among other small things. Feels like a late but welcome polish. 

Really satisfying episode, I've got a bit of an urge just to play it again.

Map remixes are my kryptonite BTW so good job with that.

Favorite changes in the mod so far: ring of shadows, nailguns changes, multi-key-carrying, drowning mechanic. Also nice: gibbing downed zombies, and spawns getting amnesia.

I agree that the backpack pickup sound is less appropriate when used for a lot of monster-dropped items as opposed to the occasional special pickup.

Not completely sure about all the other monster changes yet, but they seem ok-to-good at first glance. 

Awesomest gameplay of the decade! Tons of fun, infighting, ambushes, the works.

Great, well thought out secrets (Btw, in one of the maps it's impossible to get 100%, am I right?)

Somewhat harder than the original, Ogre and Vore attacks get me more than they use to.

Great work, guys. Thank you, you are great! 

1) It is not impossible to get 100% secrets in any map. I wouldn't do that to you. You missed a gold key :)

2) Rocket or grenade jumps are not required anywhere, for either critical progression or secrets. There's always a way. I don't ever really do anything to prevent them, though, so speedrunners shouldn't feel excluded. (except maaaybe by udob5.) 

My demos from maps 4,5,6 and secret map. Skill 2.
This was crazy stuff. Amazing maps and copper quake.

http://www.quaketastic.com/files/demos/copper_ankh_maps_4_5_6_7.7z 

So in udob3, what's the intended way of getting the barred GK by the wooden ledge with the SK? Far as I can tell the iron bars are opened by a button below, but by the time you get off the elevator the bridges start retracting and the bars are shut. I needed two rocket jumps to get up there in time. 

 

Would it be possible to adjust the player's mug to have the completely healthy face at 50 health in nightmare difficulty, or would it require engine side changes?

Unfortunately no. The choice of hud graphic is hard coded engine-side, based on player health/100. Not without CSQC, which I don't want to require for something so minor. But it bothers me too.



The extremely delayed crushers on E3M3 are a result of Copper. Both crushers are func_trains with a stale 'wait' key. That didn't do anything in id1, but I gave trains a custom pause time at each pathcorner and made 'wait' the keyvalue for it in keeping with all other func_ behaviors. I didn't notice the E3M3 crushers now wait for 13 seconds in both positions.

I was running through Quake with Copper not often, but regularly, but I didn't do one last final run-through like I should have and this slipped through.

I'm debating the best solution. Keyvalue inconsistency between func_train and other func_*s isn't desirable, nor is leaving the bug as is. Perhaps including .ent files to take care of these specific problem cases in the original maps? 

.ent seems the easiest way to fix it. 

" You missed a gold key :) "
Good. As if I needed an excuse to replay this! 

not impossible to find when you are looking for them,
some new ways to hide them,
nicely located,
visually attractive 

Ain't no way to get that blasted barred gk without rocket jumping. Nope. Too slow to use the megahealth plinth, WAY too slow to use the elevator, teleport can maybe save on 1 rocket jump. 

I loved this mod and your take on Nightmare takes the challenge to a new level. The start map stands out as well, the way this level has been revisited in a decayed fashion really stirs nostalgia.

#39 answered a question I had, but does anything special happen when you kill all foes? I only have one secret left to find so I'm wondering if that's it. 

I found the way, now RJ required, just need to be quick 

no RJ required 

I never understood why the Pentagram doesn't protect your armor, and losing health AND armor underwater when drowning felt unfair already during my very first playthrough. This mod fixes these annoyances and many more. Play the original episodes with this and you will have a hard time going back. Romero would approve, I am sure! 

... for a thoroughly enjoyable episode of traditional Quake goodness.

Some of my all-time favourite releases are episodes of more-or-less id1-sized maps with carefully-constructed gameplay: things like bbelief, contract, and terra. This pack is right up there with them in terms of quality. For me, it's these sorts of releases that most closely capture the feeling of playing the original game.

In addition to the various good things that have already been mentioned above, something I really appreciated about these maps was that secret-hunting was fun and satisfying. The relatively "modest" scale of the maps (by modern standards) meant that the maps could get away with having some fairly devious and tricky (and therefore, satisfying) secrets without it becoming impractical for the player to find them.

This is a case where I think id1-sized maps like these have an inherent advantage over modern XXL maps. In a really big modern map, I might reach the exit with e.g. 27 of 30 secrets, then go back and explore and get to 29 of 30, and then feel discouraged because the prospect of finding that final secret in such a gargantuan environment is like finding a needle in a haystack, and not much fun at all.

In UDOB, I was able to find all of the secrets without getting bored and without resorting to cheats. I liked that. My favourite secret was the one in udob3 that others have mentioned, where you have to get to the gold key before the bars close: finally working that one out was very satisfying.

I also like that the individual maps appear to have sufficient supplies to each be playable from a shotgun start, and that a shotgun start on Nightmare seems tough but not completely unbalanced. This is great for replay value.

I'm looking forward to playing through the id1 maps with Copper, and will add my thoughts about the gameplay changes in the mod when I've had more of a chance to digest them. 

... a bug report, and a humble patch submission to make Copper detect, and automatically correct, this sort of bug.

I found that I was unable to get 100% kills in udob2 on Normal skill: I was stuck at 53 of 54. I did some investigating, and it appears that the culprit is the monster_fish at "-928 -88 -224". This fish is configured to be present on Normal and Hard, has the SPAWN_TRIGGERED spawnflag, and has the targetname "fishyfishy". However, the trigger_relay that targets "fishyfishy" is only configured to be present on Hard, so on Normal the poor fish cannot be triggered, and remains stuck in the cosmic interstice.

I should preface the rest of this post by explaining that I am a cleptomaniac player who always wants to finish every map with 100% kills and 100% secrets. I am not sure whether this is normal, or even whether it is healthy.

In any case, it's my experience that this sort of bug -- where a triggered-spawn monster cannot be triggered, either because it has an unmatched targetname (possibly limited to a specific skill setting), or no targetname at all -- is historically very common in maps for any mod that implements triggered-spawn monsters. It's just so easy for this sort of thing to slip through.

Because I am the sort of player I am, I have long since taken to fixing kill-count bugs in maps and mods for my own playing pleasure. In general, I've found that it's best to make a mod detect and automatically correct map bugs whenever possible. In the case of a mod like Copper, where other mappers are encouraged to make maps for the mod, this seems even more desirable.

It would be really great if Copper could do the following for triggered-spawn monsters:

* On map start, check whether the monster has a targetname and whether the targetname is matched by the target (or target2, target3, or target4) field of another entity.

* If the targetname is matched, finish setting up the entity, and update the total_monsters count.

* If the targetname is unmatched, then the monster cannot be triggered, so print a warning message (for the mapper's benefit), and remove the entity without adding it to the total_monsters count.

I have created a patch that implements this behaviour, which I've uploaded here:

http://www.quaketastic.com/files/iw_copper_patch_20190627.zip

The only changes are as follows:

* monsters.qc: modified monster_spawnsetup

* monsters.qc: added monster_spawnsetup_go

* utility.qc: added dprint7

The comments for the functions should hopefully explain why I've done things the way I have.

Lunaran, please do absolutely whatever you like with this submission, including ignoring it if it's presumptuous. 

 

Thanks dude, with your clue I finally figured it out. I'd call this one a bit counterintuitive. 

I found that I was unable to get 100% kills in udob2 on Normal skill: I was stuck at 53 of 54

dammit dammit. Every now and then I'd make a bug like that for myself, where a spawned monster was unspawnable on a certain skill level. Your patch is pretty much just what I would have done (ie detect it and make it a loud error) had I recognized the systemic need for it before release. Thank you for the patch!

I'll put that in. It's now on the short but growing list of stuff to fix:
- better backpack sounds but for real this time
--- old ammo noise for dropped packs, new one for placed packs
- coop starts
--- add to start.bsp
--- degrade to sp start when missing
--- teleport any touching players a little distance away instead of telefragging
- fix cthon <-> ch'thon
- address ch'thon snipe-on-teleport
- e3m3 crushers are slow (stale train wait key)
--- needs e3m3.ent
- error when a monster isn't triggered by anything that exists on this skill (iw's fix) 

There's also a minor issue on the underwater map where one of the door textures glitches due to occupying the same space as an adjacent rock texture after the door opens. Didn't think it was significant enough to mention before since I didn't think there would be any patches, so I don't remember which door it was. 

ch'thon

"Chthon" is fine. 

Playing currently the original Quake ID1 stuff on Nightmare with Copper (clean install, no UDOB). Only thing I added is pak1.pak with backpack sound that I copied from lock1.wav from ID1.

In E3M7 there's a certain button player has to push and it also should make a portion of the floor to slide open and platform with some Zombies to rise. The floor opens, but the platform doesn't go up, there's an "elevator" sound though for a brief moment.

Here's a link to the pic of the described part:

http://gila.deathmask.net/copper/e3m7_zombie_platform.png

It's no big deal, unless player falls down, then there's no normal way out.

Also in one of previous levels something was off with Fiend spawn, it got kinda stuck in running animation, where as I remember it always jumped immediately at the player. I think it's at the same part with a crossroad bridge, with two crushers (I think they were reported above to be slow) on the sides.

Here comes totaly useless subject, but how about also item pickup messages consistency? The original messages are "You *got* the nails", but some of the new ones are "You *get* ...". Also in UDOB it was "spikes" from backpacks, not nails for some reason. I like the "You are healed by XX", why also not do the same for ammo, especially considering that in Copper some ammo types have different pickup amount. 

I believe I've found the bug that's affecting func_doors in various id1 maps. This is the cause of gila's problem in e3m7 and Ankh's problem in e3m2, and seems very likely to also be the cause of the problem in e2m6, though I can't reproduce that one on-demand to test it.

The issue is in the func_door spawn function. The original code had the following lines:


if (!self.wait)
self.wait = 3;


In Copper, this has been changed to:


self.wait = zeroconvertdefault(self.wait, 3);


This results in a "wait" value of -1 being converted to zero, a value of zero being converted to 3, and any other value remaining the same. This is different to the original behaviour, which just converted a value of zero to 3 and left any other value the same.

The problem here is that a "wait" value of -1 has special significance to the func_door code, and should not be changed. (More pedantically, any negative "wait" value has significance, but -1 is the value that the id1 maps use by convention.) In particular, the door_blocked function interprets a negative "wait" to mean "this door should not reset to its previous position if it is blocked".

So the result of the change is that doors with a "wait" of -1 will reset to their previous position when blocked, even though they aren't supposed to do that.

Restoring the original behaviour fixes e3m7 and e3m2. The platform with the zombies in e3m7 always gets blocked temporarily on its way up, which is what caused the bug to manifest. The silver key platform in e3m2 can get temporarily blocked if its hits the ogre in the room below as it's descending. The ogre is walking about, which is why this doesn't always happen.

The Romero lift in e2m6 is also a giant func_door with a "wait" of -1, so I expect the same bug causes that to go back up, though I couldn't reproduce this on-demand (it only happened once while I was testing, for no apparent reason). The mystery for me would be why it would get blocked, because it shouldn't be possible for anything to obstruct it. However, there occasionally seems to be engine weirdness in general with things blocking when they shouldn't?