and totally out of order,
but how do I take a screenshot in Doom1? 

the correct way would be to play it on a 1993 CRT monitor, and take a photo of the monitor display using a traditional film camera, and then get your photos developed (i dunno where you do this now, i used to take mine to Boots in the 90s) and then post your photo via physical mail to a magazine publishing house that still prints a semi-amateur PC gaming magazine, like the sort you'd see in the 90s, you know the ones with headlines like "Commander Keen Kerbstomps The Konsole Kweens". Finally, get the magazine publishers to send you a copy of the edition containing the print of your photo. Anything less just wouldn't feel proper and retro. 

depends on the engine you're using
i'd recommend gzdoom [prtscr button] 

@-Kinn: As I'm a publisher myself I can take my screenshot with a digital camera, send the picture to my computer, and than ask myself what to do with the blurry picture I got myself. Then I won't offend any magazine publisher, or in this case ID1, who is been that good to deliver the Doom'93 programm for free, on which I run it on a 386 PC.

@-spy: Thanks for the info. I'm aware of the SLADE programm, which give me all possible access to the programm itself.

There are a lot of screenshots published, so it's a bit stupid to ask the question anyway. Me in my ninties adaption was thinking there would really be a F12 button to do so.

Why I want a screenshot? Well, after converting all monsters to Quake1 I thought it a good qc aprehension to do so with the weapons as well.
Blessed the poor of armors, for they will inherate the heavens of weapons. 

I use GZDoom and F12 is the key to take screenshots, but i don't remember if i had to change it or not... anyway, if you are using GZDoom just go to the "customize controls" menu and you can set any key you want to take screenshots 

I tried printscreen, but it results in a pink-blue gamma error. Then used my old 386 with VGS (dos screencapture) but then Doom shut of because of the Terminate and Stay Resident prog.
Will try it out anyway. 

While I'm modding, I still can't lay my hands on this little error.

I can't help it. Everytime I add a new monster, with its specific alterations, the game stays persistent giving this warning.
Sometimes after a few weeks, or pakking the file to a pak file it disappears.

How does it come? Is it something hard coded or just a flawn in the engine? 

make sure you've called precache_sound() before you call sound() with that name...
some engines allow you to call precache_sound outside of spawn functions while others consider that a fatal error. these permissive engines still expect you to precache, its not fatal to fail to do so but you'll still get warning spam.

secondly, remember that many engines (including quakespasm) are lame and favour files from paks over files outside of them.
(hence why qss and qs display slightly different ordering from the path command).
So yeah, don't put your progs.dat into a pak, at least while still developing your mod. 

but I precached new sound in a soldier.qc, made a new sound folder for it, the script runs fine in fteqc and still these warnings apear. The sounds come through well.
Can't think of another place to store them, world.qc?


I run the game in quakespasm_spike_ad. 

Any idea where can one get the gfx/base.wad file that should have come with the example jrbase1.map in the original source code of QuakeEd? I’m working on a MacOS port of the app and would like to run some tests with it. 

I jumped into my archive, installed the original QuakeEd. Read me shows This is qED(tm) Version 2.0.0126 (26 Jan'1998)
I couldn't find the jrbase1.map, probably a later version.
Maybe you could combine it with the original QUAKE101.WAD.

Here is the original sample file that came with Qed2.
Hope it is of any use. 

qedsamp is another one.
This one is slightly larger (2.48Mb).
qedsampq.zip = 1.752Mb 

Thanks for the help! Alas, the files do not seem to be compatible with what the app needs.
Just to clarify, the app I'm porting is the very, very old QuakeEd written in Objective-C for NeXTstep machines.
Somehow, the app expects a WAD file whose first lump is called precisely PALETTE and contains palette data, followed by many miptextures (and *only* miptextures). I'm not sure that qed, or any of the modern map editors, would have (or generate) files following such a strict sequence and format.