Well, to think being "pretty sure" is not enough.
From my software debugging experience in know we must exactly know what's happening if we want to really eliminate the problem.
The wall_impact.efx is made of 3 parts (example: blaster)
- sound (sounds/weapons/blaster/hit_Wall.mp3)
- decal (gfx/damage/burnmap4)
- FxRunner (effects/blaster/sparks.efx)
Now sparks.efx itself contains:
- 2 lines (gfx/misc/spark and gfx/misc/spark4)
- Tail (gfx/misc/spark)
- again FxRunner (volumetric/black_smoke and volumetric/smoke)
And i'm talking about only the wall_hit related to the blaster...
As you see the EFX contains much more than a sound... mainly various GFX effects. But I guess i'm not telling you any new stuff, eh
Did you remove step by step any of these to see what really causes the crash?
If you think its the sound, then try playing it alone inside MP engine.
Perhaps it might crash if the MP3 format is not supported.
BUt usually JA tells it instead of crashing.
You can't just exclude the BSP because it doesnt work with original JA BSPs... thats wrong logic i think.
SP-BSP most probably don't work in MP exactly because they have been mapped using different settings.
The compile process itself should be the same. But check Radiant... why are there two settings, one for SP and one for MP? There are many different entities... and most certainly the source code is also different, e.g. regarding surfaces tags etc.
MP is meant for fast fun gaming,
while SP is meant for better quality and atmosphere.
If it means we have to remove half of the shaders and effects to make SP maps run in MP, then its again a sad drawback