He doesn't want to interact with you. U mad? 

deqer, this is the treatment you'll be getting for such an attitude from the regulars of this board.
relax, go use radiant or whatever for your quake 2 boxmaps and stop polluting interwebs with your posts. 

Yes it does appear to be the case that your requests are being ignored. Hmm, yes we should probably investigate this peculiar turn of events...I'm sure there must be some reason for this, if only I can remember-

-oh wait, it's because you're a cunt. 

Ricky, I understand your issue was about importing Hammer maps (or rather, Valve 220 maps) into TrenchBroom, which causes TB to choke.

Elevory, your issue seems to happen when doing it the other way round: Importing a TB map into Hammer. TB doesn't support the Valve 220 map format yet. Full support for it is planned for the 1.2 release, though:

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

But I'm afraid it will take a while! 

Include stripping out the extra data or actually recognizing / reading it?

If I remember rightly Necros (?) was working on a stripper script that would remove the extra data attached to each face string.

Recognizing it would be the first step supporting the advanced texture projection. 

Fixing the parser to strip the extra data is scheduled for the next maintenance release. Actually recognizing and reading the data as well as in-editor support for changing the projection axes and saving .220 map files is what's planned for 1.2. 

I fully appreciate the difficulty in reverse engineering it and maintaining the original .map format, which is definitely a strength. 

Ok then :) 

Like seriously. Mad seriously. 

The Valve 220 format is properly documented and I know how it works. The Mac version already had support for it, but that feature got lost in the C++ rewrite.

You will be able to set the format in the map properties dialog. So if the map is standard Quake, TB will save standard Quake. If it is 220, then it will save 220 (and give you the additional tools to adjust the texture projection per face). 

be able to open a normal map file and then re-save it into 220 at a later date to fix up the textures? 

And that's awesome.

Thanks for the continued dedication to this project, it's well appreciated. 

 

Quest and Quake 3. 

What's Going On Here

He's the turd that won't flush. 

Conversion of standard Quake to Valve 220 map is trivial (it will not affect the textures), but the other way round is tricky. I'm not quite sure how well TB will support that. 

"What's Going On Here?"

What's going on? SleepwalkR is being a bitch, just like all programmers.

I'm not surprised. Programmers are bitches, and many people have known that for years.

Maybe I should post videos of the things that trenchbroom lacks, and promote those videos as a "beware" message to all mappers out there. Would that help?

"Oh Fuck Of Deqer "
Thanks Ricky. I know, the truth hurts, doesn't it. 

deqer

U mad? 

I think the most sane choice would be to discard the additional texture information.

As much as I like how it works, it does have its limitations - often when slicing a brush it'll corrupt the projection leaving the actual BSP unplayable on certain engines (that being a linux issue AFAIK, but I could be wrong).

Trying to replicate the projection sounds like a minefield, and one it'd only be possible to partially cross before you lost your legs. Then arms, etc. 

Willem, nope. Like I said, I'm not surprised. I'm just pointing out the facts.

Even when people are nice, they still get ignored by programmers.

Heck, even the Project Manager in the company I work for complains about the same thing. Says the same thing too, lol, "programmers are such bitches."

So, if SleepwalkR feels he's better off being a bitch, then so be it. "Not to sound harsh or anything", right SleepwalkR? heh.

I'm sure he uses that quote a lot, "Not to sound harsh but ... ", but doesn't realize that it's complete bullshit when you actually read his entire post that follows that quote. lol 

Not quite sure what you mean now. Are you talking about converting 220 to standard Quake? There would only be approximate solutions in that case, but I could at least try to keep the texture's center pixel in a face intact. This is how texture lock works right now. 

To both, but yeah, in the previous I was talking about 220 -> .map.

Keeping it locked as you mention sounds the best solution. 

I think the most sane choice would be to discard the additional texture information.

As much as I like how it works, it does have its limitations - often when slicing a brush it'll corrupt the projection leaving the actual BSP unplayable on certain engines (that being a linux issue AFAIK, but I could be wrong).

Trying to replicate the projection sounds like a minefield, and one it'd only be possible to partially cross before you lost your legs. Then arms, etc.

I think that the texture projection stuff is powerful enough that it's worth trying to get it working. especially if you could directly control it in the editor, to, for example, make tri-souped terrain faces all use the same projection. 

That's the plan, yeah. All modern compilers can handle the 220 format anyway and to Quake it's all the same AFAIK because QBSP generates the texture coordinates for the engine. 

I just meant the scope of the conversion features - once you're working in 220 you probably won't want to change back anyway unless exporting to another editor.