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 

That's his whole playthrough with commentary, summed up in one picture. 

Thanks for pointing out, here's the correct link for my playthrough: Full playthrough with rambling and commentary 

Lunaran: the term "clever way" would probably be too generous. This is an ugly problem, and there doesn't seem to be a silver bullet.

My goal has ended up being to create a single QC file, compat.qc, which could (in theory) be added to any existing mod, and which provides the tools to implement an extremely light "compatibility mode" as painlessly as possible.

Because my target is "any existing mod", I can't assume that the mod's mapping interface can be changed, so an opt-in worldspawn key is a no-go.

I should stress that I do not assume this module is something you will necessarily want to add to Copper. I have simply used Copper as a test case while implementing it. I'm presenting it as something of possible interest.

How it works:

ENABLING / DISABLING "COMPATIBILITY MODE"

By default, compat.qc will automagically enable the compatibility mode for the stock id1 maps, but not for any other maps. This default behaviour can also be overridden via console commands, allowing a player to play non-stock vanilla maps (which aren't auto-detected) in compatibility mode if they really want to.

It turns out that it's really easy to detect whether one of the stock id1 maps is being played. They all have known file names, so compat.qc checks "world.model" once, on map start, and enables compatibility mode if the file name is one of the stock maps. It's common for mods to provide a "start.bsp" that shadows the stock one (and UDOB does this with "end.bsp" too), but that can be distinguished by checking some other field as well (e.g. "world.message").

This alone makes it feasible to address compatibility with the stock maps, which seems like a big win.

But we've also 20+ years of custom vanilla maps that a player might want to play with whatever mod we're talking about. They can't all be auto-detected.

As a better-than-nothing workaround, compat.qc comes with a config file, compat.cfg, which a mod can load from its quake.rc file. This defines console commands allowing the player to override the default behaviour:

compat_auto: restores the default behaviour.

compat_always: always enables compatibility mode on map start, allowing custom vanilla maps to be played. (This will break maps that are actually made for the mod, and the command warns the player about that, loudly.)

compat_never: always disables compatibility mode on map start. Not really useful for the player, just here for debugging.

Given my self-imposed restriction of "should work with any mod", I think this is the best that can be done, though I'd love to hear of anything better.

MAKING "COMPATIBILITY MODE" DO THINGS

compat.qc manages the compatibility mode, but by default, the mode doesn't actually do anything. To make it do things, functions are provided that can be called to sanitize fields (and spawnflags) only if compatibility mode is in effect.

So to fix the func_train problem that affects e3m3 (and e4m4, apparently), only a single line needs to be added near the top of the func_train spawn function:

COMPAT_SanitizeFloat(wait, "wait");

That's it. If compatibility mode is in effect, the "wait" field will be cleared, and a developer message logged. If compatibility mode is not in effect, this is a no-op.

Screenshot:

http://www.quaketastic.com/files/iw_copper_patch_20190702.png

There are equivalent COMPAT_SanitizeVector and COMPAT_SanitizeString functions, and also COMPAT_SanitizeSpawnflag (some entities have rogue spawnflags set).

A mod using this doesn't need to foul up its code with "if/else" wickedness.

THE CODE

Lunaran: as I said above, I do not assume this is something you would definitely want to add to Copper. But if you're curious, a patch implementing this is here:

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

Changes to existing files are marked with "// iw" comments.

The following things are sanitized when in compatibility mode:

- func_train: "wait" field (affects e3m3, e4m4)

- path_corner: "speed" field (affects "Contract Revoked" maps)

- All non-boss monsters: all new fields and spawnflags (just to demonstrate how easy this becomes)

- In general: the "COOPONLY" and "NOTCOOP" spawnflags (ditto)

In principle, one could go through every spawn function of every stock entity and sanitize every new field and spawnflag that the mod adds, to pre-emptively fix any as-yet-undiscovered problems. I started doing that, but then I realised how many extensions you've added to the stock entities, so I stopped. =)