Exploboxes won't trigger or killtarget entities when they explode because on death they run the barrel_explode function, which just goes kablooey and deletes itself and is missing the SUB_UseTargets function that allows an entity to trigger and killtarget things. However, with the dark majyyks of map hacks, it's possible to rig up a setup to do what NewFlesh wants, with only one extra entity and thankfully no usual fussing with any info_notnulls.

Normally, you could just manually set the explosive box to killtarget something by sticking SUB_UseTargets someplace in its key/value fields, but just about every field is already taken- th_die is already filled with barrel_explode. th_pain works, but only activates if the barrel isn't blown up in one shot, and then you have the wall already missing and the barrel still clearly not blown up. If your name is Preach and you're a member of Mensa, maybe you could juryrig something with SUB_CalcMoveDone, but it's five in the morning and none of us have time for that crap. The one big field that we want that a boom-box doesn't use by default is use, but how do you use a barrel o' boom? Make a trigger_once around it with a reasonable amount of health (both sizes of explodebox have 20 health, for reference) and make it just big enough to overlap the funbox. Have the trigger_once target both the explodebox and a relay that killtargets the wall- this is necessary because in id1 progs, you can't have one relay both target and killtarget things at once. Then add a use | barrel_explode key/value pair to the explodebox- this will make it go boom like normal when called upon by the trigger_once. In short:

classname | barrel_explode
origin | (wherever the box is placed)
targetname | splodebox <- add this line, change name if desired
use | barrel_explode <- add this line

classname | trigger_once
target | splodebox <- make it match the targetname above
health | 20 <- this is the default explodebox health

classname | trigger_relay
origin | (doesn't matter)
targetname | splodebox <- share a targetname with the actual explosive box so both are hit by the trigger_once
killtarget | splodewall <- use whatever name fits your normal entity naming schemes

classname | func_wall
targetname | splodewall <- this is the wall you want to be 'destroyed,' so link it appropriately

Double check to make sure everything's wired up right and it should work just fine. Note that this really works with anything you want instead of an actual misc_explobox, but by using an actual box (even if the box itself isn't actually shot by the player) you don't have to worry about spoofing a model or including extra textures or anything. Or, you could just add a tiny invisible button like Shambler suggested... if you're a weenie. 

The bit that says
classname | barrel_explode
should actually be
classname | misc_explobox or misc_explobox2
depending on which size box you want to use. I slacked off in proofreading and now I'm the weenie. 

Use the shootable button method. 

I hope you stub your toe on your dumb button. 

Then it will trigger the relay and remove the func wall. Unlike your essay of code, god knows what all that does, maybe someone else can read it and summarise for me. 

Here's a file passed the BBS -
Exploding Walls v1.0 from The QuakeLab
6 okt 1996.
It is a nice example of exploding walls.

exploding walls

Have Fun With It! 

Thank you kindly for the suggestions, folks! I'll sink my teeth into it ASAP and I'll be sure to upload a version for testing when it shapes up a little more. 

Why not a trigger once under a false floor (beneath the explosion) with health set instead of all that? 

No real reason other than autism, I guess. Or that trigger_onces don't take damage from explobox explosions. There's a thousand ways to accomplish the same thing, I just went with the trigger setup out of lack of knowledge for what triggers and buttons would do when in floors, behind geometry, inside the button, etc. 

trigger_onces don't take damage from explobox explosions

duh me 

A trigger_once inside the explodobox will suffice 

Trigger_once doesn't take damage from the explodobox. Keep up, man. 

Quick test shows it working here 

You got a copy of the .map you can upload? I tried it multiple ways and no matter what, the trigger wasn't hurt and required being shot by the player separately, even when it's buried inside the box itself and should be at ground zero of the explosion. 

I had same results as Spud. As he and others posted, explodbox did no damage to the trigger. 

https://www.dropbox.com/s/bn8jj6asslpvq7u/explodo.zip?dl=0 

Strange, I'm using what should by all means be the exact same setup and it doesn't work. I thought maybe it was related to entity order but my test has the explobox listed before the trigger_once, just like you do. 

You can compile the map I uploaded and it works? 

The only id Tech-based game I've ever mapped for is Prey. I like its way to manage movers from its scripting system, where triggers call a scripted function that specifies which movers will have to move, in which direction, how long the movement must take, how many degrees they must rotate...

With the recent news of 3DRealms releasing a Darkplaces-based FPS soon, I started using GTKRadiant to map for Darkplaces. While the process of building the architecture for a level is quite similar to Preditor (because Preditor was based on GTKRadiant), there is no func_mover to select. So how do I add moving brushes in Darkplaces levels? 

Yeah, compiled it using ericw's tools and it worked just fine, player_start health buffer and all. 

This will be specific to the Wrath gamecode, not the DP engine code. For now, just mackle up placeholder movers using the vanilla Quake progs, using func_door, func_train or whatever, and then when 3DR release a dev kit for their game you'll have to convert your placeholder movers over to whatever system they are using. 

Oh. Then, I imagine there's no guarantee it's even gonna be possible to use something similar to Prey's movers, because 3DRealms had made a big deal about making everything with QuakeC, for authenticity's sake.
Which leads me to ask another question: is it possible to use QuakeC to move around models (e.g. .md3 models) instead?