... 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? 

Awesome sound, too bad it doesn't get played in END.BSP anyway :(

Who made it and how by the way? 

ah, I shouldn't have zeroconvert'd door.wait. Another rush typo.

Thanks, iw! 

Nice work. 

maybe mankrip needs this. bump 

In E4M2 there's those 3 teleports that take you to MH, YA or Silver Key. They are also marked with those items. But with Copper, these items aren't there:

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

In ID1 it's fine. 

Awesome sound, too bad it doesn't get played in END.BSP anyway :(

Who made it and how by the way? 

Lunaran: glad I could be of help. I'm having good nostalgic fun playing through old maps with this mod.

I'm currently working on a QuakeC-based workaround for the "stale entity keys" issue. I've bumped into the same thing in the past, and I'd like to hammer out a decent general-purpose solution to it. I'll share the code when it's finished, will probably get the chance to do that within a day or two. 

What do you have in mind? I'd love to know if there's a more clever way around it than an opt-in "please do it the special new way" selector on worldspawn or something. 

This was a blast and I'm very happy to see it's been well received! Here's my Full playthrough with rambling and commentary. 

that's just a JPEG