I was thinking ... Of course you've considered this, but I'm wondering why you would have rejected the idea. What about a custom .TB file format or something? Why use the MAP file format for all I/O? It seems like that's where the loss is happening. If you stored the map in your own format and just spit out a fresh MAP file for each compilation you would eliminate this problem.

Like what Worldcraft did... 

.TB being a binary format, I mean. Something lossless regarding floats. 

Good idea imo 

and I don't want a binary format for better compatibility with other editors, also being able to edit the files in a text editor is a bonus. 

Was very 'strong' in that regard... but the headaches created by the proprietary format weren't minor.

Although having full control over it would avoid things like texture conversion problems of course. Most of which were caused by Valve not releasing the source.

I suppose it all depends on if you want to create and then support an additional map format SleepWalkR.

Just musing aimlessly when I should be 'working' :) 

"but the headaches created by the proprietary format weren't minor. "

You mean the RMF format? What were those, I'm not aware of what happened.

I think it allows for a few things ... floating point stuff aside, it allows for editor proprietary stuff like groups or prefabs/instances pretty easily.

I did the same thing in ToeTag in that I used the MAP file for everything. This meant that anything non-Quake had to get stuck into special comment lines that I parsed later. Was a little hacky and if I did it over again, I'd probably just make my own format.

As long as you can read/write MAP files also it shouldn't be an issue. 

It was often a blocker for working in teams - often getting someone to pull out their own teeth than install a secondary editor was easier. Getting someone to convert a map before sending it the same.

The other issues were all caused by committee design, things like texture alignment and WAD conversion.

Really, human obstinacy was the only real problem.

And if you support map as well as have a 'clean' format which still plays nice with other editors after export then it should be a non-issue in a technical sense. 

Maybe we need AlembicQuakeCollada 

Oh yeah, everyone loves a good standards fight, right? Right? Guys? 

Writing a float to text and reading it back doesn't need to be lossy.

From wikipedia,
if an IEEE 754 single precision is converted to a decimal string with at least 9 significant decimal and then converted back to single, then the final number must match the original

So just use "%.9g" in C and you're good. (I guess it's stream.precision(9); in C++)

I made a little test program a while ago that just loops through all 32-bit values, copies the bits into a float, does a round trip to string with "%.9g" and confirmed that is lossless for all 32-bit float values. 

Cause TB2 is double prec. 

17 digits (wiki) 

Can anyone recommend a programme for editing Quake textures and particularly texture wads, which runs on Linux?

Initially what I would like to do is just to extract one texture from a particular wad (let's call it "wad A") and add it to a different wad ("B"), since it is the only texture from wad A I plan to use, and wad A is enormous -- so it's really clogging the texture browser in TrenchBroom, and makes it a pain to search for textures in wad B*. I seem to recall reading that it's possible to do that, but I cannot seem to find that information again. (Can someone confirm -- is it possible to extract single textures and/or splice/merge different wads?)

---
*I guess that's what TrenchBroom's "group" feature is for, but when I click "group" in the texture browser, it just seems to make a bunch of textures unavailable. Maybe I'm doing something wrong there. 

QuakeForge has a commandline wad tool. 

No idea how to make it output mips and create wads though, sorry. 

after an -onlyents compile with an already lit map, your switchable light gets lost. Light again for viewing pleasure.

I think thats why mfxsp17 sucks so much;) 

i think you can run light -onlyents to fix it 

you can with aguirre's tool for sure. 

Old habit.. 

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. :)