Every time I try to compile a map using Necros' CompilingGUI the map fails to compile and it seems as if the compiler can't find the right source file. I'm pretty sure I set up the paths correctly though. 

difficult to tell what's wrong.
check this:
source map: direct path to your map file
working folder: an empty folder where the tool copies your .map file to and does all the compiling.
output folder: either quake/id1/maps or quake/yourmod/maps

make sure all these folders already exist-- the tool only uses the windows copy command, which doesn't not create folders automatically. 

Forgot to say thank you for the response, Spirit. That looks pretty complicated, though. Does anyone know of some more noob-friendly tools? 

it's a bit clunky, but does the job for editing wads. I run it using wine in mac os x. https://www.quaddicted.com/files/tools/wally_155b.exe 

There is a set of command line tools called Qeu listed here:

http://www.tldp.org/HOWTO/html_single/Quake-HOWTO/

ctrl-f for QEU

They are something you have to compile from source with the provided Makefile. If this is not totally strange to you, you could try them. There are two caveats, though.

As provided, the makefile is for DOS systems. To use in on Linux, you have to comment away this line as follows (# is the comment char you need to add):

#all.dos: $(PROGS.DOS)


A worse caveat is that the code apparently only works on 32-bit systems. It has some type definitions that assume 32-bit word size and hence it fails on a 64-bit system because it reads the wrong amount of data when examining a WAD file.

However, this can be worked around by using the -m32 flag to the C compiler and making sure you have the required C libraries for compiling 32-bit code. You have to install a suitable package, like libc6-dev-i386 on an Debian/Ubuntu system. (This is just if you use a 64-bit system. Ignore this step if you have a 32-bit environment.)

For reference, here is a paste of the modified Makefile that worked for me:

http://pastebin.com/PKzbcTvF

And here is just the diff if you prefer that instead:

29c29
< CFLAGS = -O2 -ansi -Wall
---
> CFLAGS = -O2 -ansi -Wall -m32
66c66
< all.dos: $(PROGS.DOS)
---
> #all.dos: $(PROGS.DOS)

Please ask follow-up questions if I didn't explain something clearly or you can't make the programs work for other reasons. Also, I didn't know how much programming experience to assume, so apologies if there was too much unnecessary explanation :)

Based on very little testing, I got these utilities to work on my 64 bit Linux system with these little tweaks. The relevant tools for extracting and constructing wad files are unwad2 and rewad2, which I specifically tested. 

Thank you very much, ericw and Pekka.

Also, I didn't know how much programming experience to assume, so apologies if there was too much unnecessary explanation :)

None at all (I know how to "sudo apt-get install" and that's about it), so no apologies necessary -- I really appreciate the detailed instructions. :) 

So I started looking at the sources of the original id maps, and saw, for the first time ever, that the source for e1m1 includes an invulnerability pentagram on the ledge you get to when you walk through the teleporter in the last secret -- yet I have never seen it in-game. Just checked in DarkPlaces and Quakespasm and looked at online secret guides, but that pentagram never seems to show up anywhere. Recompiled e1m1 from the source and still no pentagram. Getting teleported to that ledge would make a lot more sense if there were an item there to pick up...

Is that an example of an item's disappearing from the map because it is too close to the surrounding brushes? And is that what is meant by an item's "falling out" of the map? (I have heard that phrase many times, but don't really know what it means -- do the items really move downwards into oblivion?) 

Do "developer 1" in the console and then load e1m1 ... it will tell you if something fell out of the world.

It might be skill level filtered, actually... Only shows up in nightmare or whatever. 

 

I'm an idiot. 

I noticed something weird with floating ammo boxes while testing some related things. Below is a minimal map that has a single box room and two func_walls with ammo on top of each. Both func_walls disappear if you step into the other end of the room, and the ammo remains floating in the air.

When compiling the map with tyrutils and playing it on QuakeSpasm 0.85.9 I notice that I can pick up one of the ammo boxes without jumping, but not the other. However, they are both supposed to be at the same height.

Can you explain that? Does the proximity to the wall or the torch have something to do with this?

http://pastebin.com/fXUzXRMu

Compile it, play it, and just run around under the boxes without jumping. What happens?

Another question: What is the canonical way to create an item that falls from above after some event triggers? It's obviously not this, as they just float after killing the func_walls. 

On a func_door that moves sideways, and use another brush to scrap it off. Then it should fall.

Can't remember if it works for ammo though. 

They have always been wonky since their centrepoint is on one corner of the ammo item in the .bsp - so engines have applied various fixes to them down the years.

So you'll see different collisions depending on which engine you use. 

That works with ammo falling off a func_train, so I guess it works just the same with a func_door, where that is more appropriate. Thanks. 

removing entities with killtarget does not correctly register the entity is 'in the air' so the engine still believes it is on solid ground.

you can also try 'crushing' an ammo box. that may cause it to fall through the ground, but i'm not sure. 

Well, func_train is useful for dropping several items in a timed fashion. It just pushes each off its perch in turn :) 

"Internal error: didn't allocate enough planes? (NewPlane)"

What mean? 

Is that from Quake? 

 

Yeah, that popped out of QBSP. I was confused and scared. 

Not even aguirRe's readme has anything on that. 

\o/ What do I win? 

http://i.imgur.com/UoFePIp.jpg 

http://disenchant.net/git/?p=tyrutils&a=commitdiff&h=347020879dc46507681fac3d321a4502f0d72bff

if (map.numplanes == map.maxplanes)
- Error_("Internal error: didn't allocate enough planes? (%s)", __func__);
+ Error("Internal error: didn't allocate enough planes? (%s)", __func__); 

Yeah, I figured it was in the source code somewhere ... I just don't know what it means or how to fix it. :) It had something to do with a brush I had added. I guess it was a perfect storm of floating point planes or whatever and death by map.maxplanes cuts.