Is this a known issue?

Loading file C:\Quake\Id1\maps\endeavor.map
Loading unsupported map Valve 220 map format
Malformed map file: expected token of type integer number, or decimal number, but found string at line 1198, column 77
Loaded map file in 0.020000 seconds
Loading entity definition file C:\trenchbroom\Resources\Defs\Quake.fgd

.... aaaand the map doesn't seem to show at all.

So are any Valve220 maps a no-no? 

Is this a known issue?

Loading file C:\Quake\Id1\maps\endeavor.map
Loading unsupported map Valve 220 map format
Malformed map file: expected token of type integer number, or decimal number, but found string at line 1198, column 77
Loaded map file in 0.020000 seconds
Loading entity definition file C:\trenchbroom\Resources\Defs\Quake.fgd

.... aaaand the map doesn't seem to show at all.

So are any Valve220 maps a no-no? 

I haven't tested them extensively. And even if they do load, TrenchBroom can't handle the new texture projection stuff (yet). If you send me the file, I can take a look and fix any problems with the parser, but as I said - you'll have garbled textures all over the place.

Best if you make a bug report and post the map (or the offending portion incl. containing entities) file there: http://github.com/kduske/trenchbroom/issues 

Proper support for 220 maps with freely configurable texture axes are on the todo list for 1.2 or 1.3. 

Well I'll post that .map file anyway (It's that Catatonic Fits of Despair source, but I got the same bug with a bunch of different maps)... 

I submitted an issue about setting the quake path (possibly you already added it as I mentioned it here already... I forgot about that), but in the meantime, is there some way to force set it? I could probably hard code it, but surely there is some config file somewhere I can open in a text editor and set the path? Where is it on Linux? 

And I'll fix the parser for 1.0.5. 

Anyone got multisampling working? Do you have anti-aliased lines etc? My Trenchbroom render window looks a bit ass. I'm using an GeForce 560 with the closed source drivers.

Also, my depth buffer is only set at 24bits, which could be the cause of the lines looking a bit thin and aliased. 

Yes, there is. Go to your home directory and look at the file .TrenchBroom - this is where the preferences are stored on Linux.

Try to set the Quake path to something that the file dialog is fine with so that it is actually stored in the prefs. The edit the file (I think it's an ini file) to reflect the correct path. 

The editor tries to autodetect multisampling, but I'm sure it doesn't work too well on Linux (I was using a virtual machine when I wrote that). If you like, you can look at the file LinuxCapabilities.cpp (or .h) and maybe you can figure out a way to detect and enable multisampling on Linux.

I'll add it to my list of problems with the linux version, in any case. 

I'm aware that the 220 textures are loaded incorrectly in other editors (if the maps load at all), but it would still be nice to be able to load just the brushes. :) 

As I said, if you create a bug report and add some examples, I'll fix it. 

yep, that did the trick. Thanks. 

add the name of the level and things in TrenchBroom?

add a 'message' key into worldspawn to make a title appear for your map. 

I made this:

https://github.com/kduske/TrenchBroom/issues/476

I mean I can't really give any more info than that at this time, because the map doesn't seem to load at all. But once we get past the first hurdle I can help give some structured info on different types of texture angle and how they appear in each editor, if that would help :) 

I'll look into it! 

I really have no idea how to add or find the worldspawn, in worldcraft you just change the level details in a menu but I can't find any menu for it in TB. 

Select a non-entity brush and see its Entity properties. 

Thanks, although that is counter-intuitive. :P 

I plan to add some CSG operations (most importantly CSG merge), but CSG subtract (or "cut" as you call it) is not among those. The reason is that it is very hard to make the subtract operation create "optimal" brushwork. Here, optimal means brushwork that creates a minimal amount of plane cuts when run through QBSP.

AFAIK, the general consensus is to stay away from CSG subtract operations because of this. And that's why I'm not going to add it to TrenchBroom.

If it helps maybe you could experiment with what I did in ToeTag. I remember sorting the cutting planes by size and cutting with the biggest ones first. This did seem to result in the best/least set of cuts possible as it tended to do the large changes first and then the small ones only operated on the small brushes that were near the cutting brush.

Anyway, something to think about. Cutting holes in stuff is a staple feature that I would miss not having, long term. It's really just an extension of the clipping tool. 

Er, not the cutting planes but the cutting polygons, obviously. :) The planes would all be equal size. 

of my first Worldcraft test level a few months ago by liberally using the carve tool. It was a nice looking test map (that may evolve further) but I think discourage carve tools is a good idea. 

I won't get into a huge argument but I disagree. You can make the same mess with the clipping tool. Keeping users away from powerful tools because they might make a mess is a silly argument, IMO.

I'll walk away now. :) 

Well, I thought that noone really used CSG subtract, but if I'm wrong I'm happy to add it. But I think you haven't understood what I meant about cutting the brushes "optimally". I want them to be cut so that they don't get extra vertices in the edges that they share with other brushes that are not affected by the cut. Because that would lead to the adjacent faces of those brushes to be cut up into more polygons, right?

This is easy to avoid in simple situations such as cutting a door frame into a brush, but it seems much harder when you do stuff like cut a brush (or several brushes) with a shape such as a sphere when the sphere. I'll have to think this through, but I'll add it to my todo list for when I work on CSG. 

actually but I think the damage caused by carve can be much greater (imagine carving a cylinder shape out of another cylinder shape, ouch!), I do remember there being a guide for carving brushes properly without making a mess.

These are certainly lessons to learn but I think the carve tool can be a bit of a crutch, there's a lot to be said about making decent pre-fabs to work with that optimise well.