Quake 1 editing certainly needs lots of forward planning in that regard. Which is why the blocking out method is recommended. I usually make my prefabs inbetween blocking and detailing so that I'm happy with those types of things before I have to redo every single detail in the map.
There's definitely some really great features that I would love, one of them is making a standard prefab and then being able to stretch it out (like a railing) and the engine just makes it extend out properly without any skewing or deformation. I would love the hell out of that. 

well, i'd rather use awesome modelling tools to create even vaster quakey areas. :)

TB2 is getting there, but I still prefer making stuff in 3dsMax. Even if the damn scripting language blows up every other version. Friggen autodesk.

For me it's always been modelling tool for anything rocky or terrain-like, but I've never found a modelling workflow for low-poly architectural stuff that comes close to matching the speed and accuracy of (quake editor of choice). Maybe I just suck at modelling. 

https://www.youtube.com/watch?v=iBgxdZ7x5go 

"How does Quake look in 2013?"

Like shit, apparently. 

Yeah that updated look does not lend itself well to quakes low poly everything. 

Jesus, my eyes ... that's horrific. 

I thought this discussion was too 2001 and passe for you, cocksniffer. 

I think modular can also be done with brushes. It just tends to look less interesting than unique spaces, unless perhaps someone did it really well.

I remember that Vondur map that was all arches, that seemed very modular but it also had the downsides of modular.

Community repo of brush modules? 

THAT could be very interesting. If Trenchbroom or whichever app could hook into a central repository of Quake brush prefabs ... properly textured so you can just drop them in without worrying about it. Slipgates, arches, windows, etc.

All the generic crap you rebuild all the time.

There WAS a website way-back-when that did something like that. Had prefabs you could download. Slipgate Central? Can't remember... 

this one?

https://www.quaddicted.com/webarchive/prefab.planetquake.gamespy.com/index.shtml 

that's a brilliant idea! 

I could literally knock out a shit load of prefabs. I love making little doo-dads with bsp. 

Scampie - I think that's it, yeah! 

I always maintained a .map that was just a big archive of commonly used brush structures and other bits and bobs.

When I mapped, I just kept 2 instances of radiant open, with my proper .map in one and my prefabs .map in the other, and just copied/pasted as required. 

I see the discussion is about a community resource of prefabs, not just editor "support" for prefabs, my bad. 

Just import .map's... 

Because the idea of a prefab is that if you change the source prefab, all copies of it update automatically.

If you mean have the editor reference external MAP files then, yeah, that's an implementation that could work. Valve does that with Hammer. L4D was built on referencing external MAP files.

That also has the advantage of being able to work on an axis aligned piece of geometry in the source MAP file but when you reference it in your level, you can rotate it to lay at a 30 degree angle or whatever.

So it's easy to work on AND interesting to look at in the final level. 

Can't wait for UE4 quake map import plugin. 

If you mean have the editor reference external MAP files then, yeah, that's an implementation that could work.

Infinity Ward had been doing that since at least CoD 3 and possibly earlier. You've described exactly the implementation I'd love to have, but it does require editor support.

The non-90-degree rotations scare me though :) 

Man, that would be a sweet feature for Trenchbroom.

Just think of having:
{"classname" "func_detail"
"_map" "crazy_arch.map"
"angles" "0 30 0"
}
with a preview of the referenced map, and a command to open the other map file in a new window.

qbsp would need to support it, but I'd think it would be a trivial preprocessing step (load the referenced maps, translate/rotate/scale (?) them as needed, add the brushes to the original map file in memory, continue normal processing) 

TB2 has builtin support for layers and groups. Both layers and groups can contain groups, entities, and brushes, and both concepts are mapped to the map file format using func_groups with special properties. By default, func_groups can only contain brushes and not other entities, but TB2 works around this by adding a reference property to entities. So a group would look like this in the map file:

{
"classname" "func_group"
"_tb_type" "_tb_group"
"_tb_name" "asdf"
"_tb_id" "2"
// some brushes
}

And an entity belonging to that group would look like this:

{
"classname" "light"
"_tb_group" "2"
}

At some point in the future, TB2 will also support instancing by adding two new concepts: A master group and slave groups. Slave groups will additionally contain a transformation matrix that is applied to the objects from the master group. Editing any slave group will modify the master group and therefore change all other slave groups.

These will be written to the map files as func_groups again, so that no special compiler support is necessary. On map load, all objects that belong to a slave group will be discarded and replaced with the objects from the master group. The consequence is that TB2 map files can be edited in other editors and compiled by all compilers without modification. Of course, if you use other editors to edit a TB2 map file, it might result in groups getting out of whack (missing ids, or modified slave groups). This can be detected at load time, though, so it won't be too much of a problem.

A similar system could be used to support external .map prefabs. I would include these external prefabs when saving the map, and when loading it back again, the included stuff will be discarded and replaced by the actual stuff from the referenced map file. 

My concern is how you deal with target/targetname/killtarget/mod-defined-target-fields, so that you can include fancy doors or whatever. 

"targetname" "ArchDoor_I$"

The instance gets "_I$" replaced with some unique identifier unique to each instance (TB2 would generate these behind the scenes and assign them)? Something like that would work.

If you don't want the auto generated name just leave off the "_I$" at the end. 

I hadn't thought about that yet. I suppose I have to do some replacing or auto generating of keys for this. I'll add that to my issue ticket. 

You didn't even have to change qbsp. That preprocessing would be done in a very simple tool, placed before qbsp in the toolchain. Then you could use any qbsp you like.