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.