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. 

Tried v0.14 tonight out of curiosity. At first I thought -forcegoodtree just wasn't working:

txqbsp_xt -forcegoodtree 31815 marksurfaces
tyrqbsp -forcegoodtree 33242 marksurfaces

Then I ran them both without -forcegoodtree:

txqbsp_xt 33205 marksurfaces
tyrqbsp 34644 marksurfaces

There is an almost identical decrease in marksurfaces (1402 vs 1390) between the two versions, but in both cases the marksurfaces with Tyrutils v.14 is almost 5% higher.

Any idea as to why? 

Looking at the full output of both qbsp compilers might give me some clues.