Here goes nothin.... 

Well....

I understand that feature-bloat is a bad thing and all, but ATM RMQe is the only Fitz-branch engine with any kind of BSP2 going on. I can only speak for myself here, but I would really love the feature right now. The main reason being that I want to us MHAguireLight to do the light, and it won't work on V29 maps. I just love AguireLight, and now we have lit support with it, I was so made up when we hit that milestone.

Having said that, I'm still keen on using Tyrquake. And I'm really impressed with the QBSP. It seems really stable to me. I'm so used to having trouble compiling huge maps, but this compiler has blown me away. And I haven't tried your light tool for ages either, but I guess the entities are set up differently to Aguires.....?

One quuestion - does it support the -extra4 level of resolution? And the really cheeky question - does it do dynamic (flickering etc) coloured lights? I seem to remember that RMQe + MHAguireLight would actually do that stuff. But I'm not and engine or tools guy, other that using them heh.

Now, where was I.... 

 

Changing the resolution and applying full screen from the menu caused no textures to be drawn, I could only see the shading on the gun. everything else (including the menu) was flat grey.

Launching from command line with the resolution and fullscreen applied worked fine. I cant remember the cvars to apply texture filtering. I prefer the blurry bilinear type texture effect. Lit files not working (were they supposed to be?), no aspect-ratio correction stuff (especially on the weapon).

I decided that what I'm going to do (for now) is use TyrQBSP v0.11 to compile my map, and hopefully I can use MHAguireLight to light it, and run it in RMQe. To me that is going to be the most Fitz-like experience. Baker? 

MHAguireLight. Maybe MH would do it? Que Sera Sera.

Then that can be a standard and FitzQuake MkV will also support it and all will be perfect and centered in the universe again 

TyrQBSPv0.11 + MHAguireLight + RMQe

And I LOVE it! 

Yeah, lots of unfinished stuff in TyrQuake. Resolution changing is only partly done - I really need to finish that off.

I'll get another build of qbsp up with -2psb support. 

Qbsp can now parse Quake 2 map format - you still need your textures in WAD format, but qbsp will automatically strip the leading path from the texture name and ignore the extra surface attributes that are not used by Quake. And by popular demand, we can now output RMQ style BSP2 ("2PSB") format bsp files again with the -2psb command line.

TyrUtils v0.14 changes:

* qbsp: Added Quake 2 map compatibility
* qbsp: Add -2psb option to output in RMQ compatible BSP2 format

Download from the utils page as usual (Win32 / OSX / source). 

@RickyT23: my light util has most things that are provided by the bjp tools - give it a try and see if it does what you need. Check the docs to see which options and keys are available. 

I'll try the light tool too :) 

This is great news that you have added RMQ BSP2 support for Tyrqbsp. However, there is one crucial feature that crashes v14 of tyrqbsp before it even begins, fence textures, or alpha masked textures.

If tyrqbsp finds any texture in the map that starts with the { character, is stops operation and results in an error of:

************ ERROR ************
Internal error: didn't allocate enough entities?

or

************ ERROR ************
Internal error: didn't allocate enough brushes?

depending upon the map. I've done various tests and concluded the result of this error is in fact the cause of having just one texture starting with the { character, which any alpha masked texture must start with to be rendered properly by RMQ etc.

Surely this is an easy fix? 

Doesn't support these yet either.

I haven't investigated any code or anything - what was the reason for using opening brace? This seems to be the cause of most of the problems.

Lame question, seeing as how close I was to the development of the format, but why not use a neutral / unused symbol, like @ or something... 

but only if you enclose the texture name in quotes. 

to be precise: " 

seriously... that curly brace is causing more trouble than it's worth! 

 

 

@Orl: Does this snapshot work for you? If not, can you email me a test map + wad?

Snapshot tyrutils-0.14-1-ge8d1f59: Win32 and Mac OS X. 

Indeed it does Tyrann, works perfect. :) 

Tyrann, if you get bored, might be an idea to generate some hexen2 variants (primarily for bsp2 support) too.
I don't personally make maps, but I'm sure someone would appreciate it... eventually...
(hexen2 burns through clipnodes much faster). 

like Spike said, if it became possible to use BSP2 with Hexen 2, then I could finish this hexen 2 map

http://spawnhost.wordpress.com/2013/04/18/hexen-2-map/

Had to shelf it in frustration months ago because of bsp limit. 

Not sure that any H2 engines support a BSP2 format yet? Might not be too much work to hack it into uHexenII - haven't looked at that project in a long time. Anyone got some pointers to info on the H2 bsp format(s)? 

wow
the stuff on your blog always looks awesome. I really like the look of that Hexen 2 map, especially the wooden stuff. Also seeing more shots of your e1m2-based map is great (I like the idea of adding an outside/location to the original map). 

FTE theoretically does. Both bsp2 and 2psb variants, as well as the h2 tweeks. I don't see any reason why it would fail to work properly, but this particular usage is untested hence my usage of the word 'theoretically'.
The hope is that the other engines will eventually gain support once there are actually maps that use it (that they can test against), as its not too hard to add support to an engine (I really ought to provide a more usable diff in that markv zip).

Basically, max_map_hulls is 8 instead of 4, with 6 hulls used instead of 3.

Here's the hull size list you'd need to generate:
0 0 0, 0 0 0 (render hull, exactly the same as quake)
-16 -16 -24, 16 16 32 (player hull, exactly the same as quake)
-24 -24 -20, 24 24 20 (no longer the shambler hull)
-16 -16 -12, 16 16 16
-8 -8 -8, 8 8 8
-48 -48 -50, 48 48 50
unused
unused

The .map format can be different, the extra fields can be ignored I believe. This doesn't affect the output, but is a tweak you might need for the map parser if you don't already support that. 

That's a lot of hulls! There's the answer as to where all the clipnodes go ;)

No promises, but I'll play around with it and see what I can do.