Awesome episode. For me it's up there with Zerstörer and a couple of other ones in some kind of unholy pantheon of episodes. From the brilliant startmap to the boss fight, I think it was just about perfect, with a nice arch from "realistic" to gradually more and more abstract level design. But I loved the last two levels as well. Lots of neat surprises and ideas throughout. It's also one of those rare maps/episodes that I restart as soon as I've finished it. For one thing, I have a bunch of secrets to find. Anyway, many thanks for a brilliant episode. 

Yeahh. I've been changing and rearranging code in Copper for a long time. It grew out of the LunSP2 source, which I started right on top of the LunSP1 source, which is from 2003. That's 15 years of "oh this could be cleaner" revisions and "oh I'd like to have this" additions that probably make truly universal compatibility a pipe dream.

Had I started this project from scratch more recently, there might have been more compatibility with progs_dump, but since I started it almost from scratch a long time ago, most of the parity is with Quoth, which was the only big-mapper-feature-add for a long time.

Compatibility isn't limited to just formerly dead spawnflags and keyvalues, either. Very careful mappers would sometimes offset their ammo pickups based on how the models looked, and not the physical bounds of the pickups, and in Copper they'll appear off-center or even z-fight with each other (the ammo in the dapak maps is frequently screwy). Or map hacks: preserving 100% of them was impossible without leaving 100% of the code unchanged, since any free function was eligible to be a notnull's .use(). Does compatibility mode mean maps as hacked as Ascending and Descending work?

There are also already cases where the gameplay changes themselves might soft-break a map, like if Enforcer or Ogre drops were expected to fuel the LG/RL for the entire level.

Just saying "compatibility mode" implies a guarantee that can't be given. :( It's also on the user to remember to be in the right compatibility mode, and it puts these COMPAT_ calls all over the place ... still, this is an impressive patch. I'll give it a think.


I also did not realize Contract Revoked didn't include a progs.dat. this weakens my opinion that it's only critical to support eXmY.bsp, and that the chips can fall where they may everywhere else.

Guess I'm playing Contract in Copper this evening. 

Wow. I remember playing lunsp1 when it was released, but I hadn't realised it was so long ago!

Considering 15 years of changes, Copper does ... really very well for compatibility. I'm impressed.

Agree 100% that Q1 map-mod compatibility is a bottomless well of absolute despair for all reasons stated.

>>> Or map hacks: preserving 100% of them was impossible without leaving 100% of the code unchanged, since any free function was eligible to be a notnull's .use().

This is so true. I once "harmlessly" refactored barrel_explode and completely broke gmsp3. =(

Nowadays I just assume that maps that use negke-level hacks are a write-off in terms of mod compatibility, exactly because of e.g. info_notnulls calling functions that should be private.

To play new vanilla releases, I use a custom progs.dat which fixes exactly one thing: the Rotfish kill count bug, which I can't cope without. Map hacks have frightened me about compatibility that badly.

>>> Just saying "compatibility mode" implies a guarantee that can't be given. :(

Thanks for pointing this out. Now that you say it ... yeah, I'm inclined to agree. This is a "compatibility mode" to address an *extremely specific* compatibility issue, which is the stale spawnflag/field awfulness. It's not meant to be anything more than that. (My comments at the top of the file make it sound too magical -- gah.)

And yeah, end-user expectations. Right now I have no clue what else to call the module. =( But thanks for the reality check.

BTW, even if my pet idea isn't the way forward: how high a priority is stock engine compatibility? An ent file to patch e3m3 would be ignored by the stock engines.

It's more compatible (if ugly as sin) to include a map-specific hack in the progs. E.g. at the top of func_train:

if (world.model == "maps/e3m3.bsp")
self.wait = 0;

This is so ugly, but it'll work for everyone, even people playing with the WinQuake they downloaded via Steam or whatever. 

That's true. I did advertise that Copper works with any Quake, I guess I can't go back on that now because of one crusher. I gave Copper a try in WinQuake and there was a charming joy to running around in blotchy pixelated 256-color mode again.

Now I have to decide between the abstract badge of honor of being DOSQuake compatible and the abstract badge of honor of not having map-specific hacks in the progs.


A third answer: since all of the problems actually witnessed in the wild seem to stem from func_trains, a Copper-opt-in spawnflag on just func_train is a lot less offensive to my delicate sensibilities. I think I'd only have to update one func_train in all of UDOB (which is going to get an update when Copper does anyway). 

Lunaran, what's your take on the other possibility, of requiring maps for a mod to self-identify as such by setting a worldspawn key?

This seems tantalizing to me because I could unambiguously distinguish between "a map made for my mod" and "a map not made for my mod", and then switch behaviour (e.g. sanitize certain fields) accordingly.

Just brainstorming:

* It would allow a mod to add a new bugfix even if some terrible backwards-compatibility problem with a specific entity is only discovered far down the road, after people have started releasing maps for the mod, when it wouldn't be possible to add an opt-in key to that specific entity anymore.

* A worldspawn key could be set automatically by a .fgd file (I think?), so it's only the mappers using .def files who would have to remember to set the thing (I think?).

But it sounds like you've already considered this option, so is there a downside I'm overlooking? 

*slightly spoilerish*

Replaying the episode, I found the button in udob2 that switches the portal to a ”secret level”, but the level in question is udob7, which of course is part of the episode normally as well. Am I missing something here? 

That's the usual convention of naming secret levels, going back as far as E1M8. 

With a key on worldspawn, we only solve the problem of the player remembering to set the right mode by making the mapper remember instead. It doesn't solve any of the other problems of maintaining two different code paths for everything, which has the potential to be a nightmare of bugs. 

I should have been more clear, I was more thinking about the choice between "key on worldspawn" vs. "key on just func_train" (or whatever affects a given mod) -- both require the mapper to remember something, and both result in two different code paths. Certainly taking advantage of any of these approaches would need to be judicious, and justified in context. Again, I'm thinking generally, and I realise that my own reasons for being interested in these issues aren't really applicable to Copper, so I'll stop rambling about map compatibility and try to get back on-topic.

Having a blast revisiting old vanilla maps with this mod!

* First mod ever to make me think "Oh cool! Another Ring of Shadows!"

* Vores much less tedious to dispatch. There's a sort of a Vore-dance now, where previously there was more of a Vore hide-and-prod.

* Playing the new Nightmare for the first time (UDOB maps), I was constantly on edge about the low health ceiling -- I found myself burning health boxes just to get from e.g. 44 health back up to 50! Been a while since I felt that worried playing Quake.

P.S. on my travels I've come across and squashed some (small, specific, run-of-the mill) bugs -- one is the issue with the "fake" items in e4m2 not showing up, which gila mentioned, and a few other things. Lunaran, I'll aim to send you my findings in an email sometime in the next few days, when I get chance -- don't want to clutter this thread with any more technical stuff than I already have. 

E4M2 fake items: it was the habit Sandy had of using target and killtarget together, so the items thought they were trigger-spawned. Found it, will be fixed in the next version.

When I found out that items with targetnames were problematic (like as the targets of spotlights highlighting them) I should have made it a spawnflag too, to match the monsters, rather than write something silly like SUB_VerifyTriggerable(), but I think I did that in 2010/2011 and never remembered that E4M2 had fake items. :( I was on a 'make everything smart and automatic' kick.

Please, send me the rest of your list! 

gg 

Everyone, here's the newly released Quakecast episode where Dumptruck and I talk to Lunaran:

Quakecast Interview with Lunaran 

maybe I have missed the info somewhere but what are some recommended maps to play with copper quake? I have played the original game and all maps which came with the mod. Need more! 

The creators of the mod recommend the following:

Februus Depth (februus) by czg
Ripe with Decay (sm175_scampie) by scampie
Antediluvian (ant) by metlslime
The Horde of Zendar (zendar1d) by sock
Bad Dark Cistern (dm456sp) by negke

at the bottom of the http://lunaran.com/copper/download.html page (see "Pairings")

But I guess you can take almost anything that is not a mod (or doesn't require another mod and/or mission pack) and use it with Copper. 

Lunaran: email w/ misc bugfixes is sent. If it somehow doesn't get to you, please shout here to let me know. 

thanks for the list
Februus Depth was crazy hard on skill 1 :) 

how can I play the The Horde of Zendar? It has it's own game directory... 

the files in /zendar are just modified health pickups iirc. 

If I'm not mistaken...

Copper has a "pak0.pak" file W/progs.dat
Zendar has a "pak0.pak"+"pak1.pak" NO progs.dat

So... rename the Zendar files:

pak1.pak to pak2.pak
pak0.pak to pak1.pak

Then copy those into your Copper Folder.
PLAY Copper and then "map zendar" in the console!
Or if you use SQL select it from the list.

***ASSUMING you have no OTHER pak files in Copper other then the one that came with it. 

Doing it mfx's way is better if you want to just play the map once and forget it's there, but if you move all the Zendar pak files into /copper you'll be importing zendar's ammo treasure chests, so remember to get rid of it when you're done or they'll be everywhere.


Patch coming soon! 

Playing Zendar in Copper is "better" with ALL of Zendar's content!

But I should have put in what Lunaran stated. 

I ended up making a copy of the copper folder. Renamed the folder to copperzendar and added the pak files from zendar as damage_inc described.
Everything works. And since I want to replay only once, the new dir will be deleted afterwards. 

The Chthon fight was both very classic and very refreshing at the same time. Made me nostalgic for the glorious battles of old.

The levels are very chunky and old school feeling and this has much in common with Machine Games excellent classic Episode 5.

Some of the new mechanics seem cool, at least on paper, but I haven't really noticed or explored them in much depth. 

...is there an intended way to get to to END.bsp other than console command?

I played the whole thing twice and the portal (that I found noclipping) does not seem to open...