Any way to attach a lightstyle to a shadow from a bmodel? 

I think that might actually be possible. It would be a bit of work to code, possibly not too bad though. 

cool, it's just a nice-to-have. maybe you have some floor you want casting shadows, but later needs to break or something... 

There's a fix for mixed face contents I'd like to have that was added to git on 31/07, but the latest build is from 13/07 (according to readme).
Will there be a new build soon-ish or will I have to do it myself? (= pain) 

available from here: http://quakespasm.ericwa.com/job/tyrutils-ericw/ 

 

Yeah, those nightly builds should be fine to use.

In other news I found a serious bug in the surface lights code that was causing it to spam multiple copies (sometimes 10+) of each of the surface lights. This is unrelated to the bug where setting "_deviance" "0" on a surface light would also spam copies.. This explains why they were going crazy for some people during the map jam, and the extra long compile times with surface lights.

That should be fixed in the nightly builds. I'm working on some speedups for light right now and hope to have a new release soon. 

available on the website: http://ericwa.github.io/tyrutils-ericw/

Changes:
* qbsp: add "-maxNodeSize" option, from txqbsp-xt. Defaults to 1024. Makes large maps process much faster and should generate better bsp trees. If it causes a problem disable with "-maxNodeSize 0"
* qbsp: make "mixed face contents" and "degenerate edge" non-fatal, from txqbsp-xt
* qbsp: make "-oldaxis" the default. new "-nooldaxis" flag to get the previous behaviour.
* light: add "-surflight_subdivide" flag to control amount of surface lights created
* light, vis: use below normal process priority on Windows
* light: allow negative surface light offset
* light: average the lit file color components to generate the bsp lightmap value. TODO: use a perceptually weighted average.
* light: fix lighting of hipnotic rotating entities.
* light: fix crash in "Bad texture axes on face:"
* light: fix surface lights being mistakenly duplicated
* light: add "-onlyents"
* light: add "-dirtangle" setting to control dirtmapping cone angle, default 88 degrees.
 

But what about phone shading!!! 

Apple or Android? 

http://triptohell.info/moodles/junk/tyr-h2.patch
adds -hexen2 argument to qbsp to generate a h2(mp) bsp.
vis and light also accept hexen2 bsps.

doesn't do anything about palettes.
silently ignores hexen2's extra 'light' attribute of each plane, if specified. this is consistent with other hexen2 tools (iiuc).
doesn't do any special behaviour with watervis, so unlike hexen2 lava is watervised by default.
do NOT try loading a hexen2 bsp in a quake engine (other than ones that explicitly support it). doing so will likely result in crashes (and vice versa).

-hexen2 -bsp2 are accepted simultaneously. fteqw supports this, other hexen2 engines will need to be tweaked now that there's a tool that can actually generate them. this relaxes the clipnode limit that otherwise severely limits the sizes of hexen2 maps (to two fifths of a quake map, approx).

let me know if I broke anything... 

wow, thanks! this will be nice to have.
I will test this a bit and merge it in.

ExportClipNodes is confusing, I don't get what the "diff" variable is doing and why was it only modifying model->headnode[1], but it will probably be clear if I watch it in the debugger. 

yeah, that took me a while to figure out too...

its reordering the clipnode trees because they're calculated by hulls then models, but stored in the file as models then hulls, so the previously stored hulls need to be remapped to cope with the clipnodes added into the previous models (ie: clipcount has changed since the tree for the previous hull was generated).
the alternative would be to store the trees as-is and fix them up later.

I forgot to do anything about world.spawnflags&1 signifying mission pack+hulls. I'm not sure that there's much point in it not being set, but meh. 

Hexen 2 bsp2 support - cool, I might finish my big H2 map then. I considered using it elsewhere but it doesn't really match there either. It has been just collecting dust since it broke the format like a clumsy child breaks eggs. :-/

just like my ROEM maps have been collecting dust since I got vaguely pissed off with RMQ gameplay and Quake at large but was too bored, sick, busy to do much about it. Can't puzzle out the gameplay but also can't release them for vanilla quake (too big, too spacious etc)

anyway, hordes of fucking archer knights, at the ready? I'll have to try H2BSP2 some day.

uh, Hexen 2 jam in honour of this feature? Or am I hallucinating. I probably am. No one makes Hexen 2 maps anymore. If you want to Hexen 2 map, hit me up? 

Detail brushes that are (I imagine) accidentally used to seal the void are bad, right? Might it be worth putting in a -nodetail switch or something that lets you do a test compile that discards all the detail brushes, allowing you to find leaks that are purely in the (non-detail) world brushes? 

If you're using TB you can actually hide certain brushes.

Just go to the View tab on the right and deselect Detail Brushes. 

I use Netradiant, and never could get into TB unfortunately (although I like the sound of TB2 - I may have to have a goosey at that).

For now, I notice that rebb's txqbsp has an option to "make detail leak" for this exact purpose, so I can try that I guess. 

Since func_detail is an entity, I imagine your editor must have some facility for hiding/showing groups of entities ... altho I don't know much about Radiant these days. 

Since func_detail is an entity, I imagine your editor must have some facility for hiding/showing groups of entities ... altho I don't know much about Radiant these days.

Hiding anything in netradiant does not exclude it from compile, so that would not help in debugging detail-sealing-void issues 

Use txqbsp_xt, there is a switch -makedetailleak that does what you want. 

Aye, that will have to do 

In radiant, you just press L to bring up the entity list, and select all the func_details by clicking the first one and shift-clicking the last one in the list... you just just delete them, save as, and compile the detail-less version. 

In radiant, you just press L to bring up the entity list, and select all the func_details by clicking the first one and shift-clicking the last one in the list... you just just delete them, save as, and compile the detail-less version. 

I know there's been plenty of talk of a prefab feature before, and I think last time it ended with people talking about doing it editor-side.

However, I never like the idea of restricting the choice of editors, and I know plenty of us are using an editor that is no longer in active development (e.g. netradiant) and really want to stick with it, so is it worth talking about a compiler-side prefab feature?

The user interface would be simple - a "func_prefab" entity with a key that points to the filepath of a .map file containing whatever you want copying over. Rotation should work as expected. I don't think scaling would get used as much but that might also be worth supporting

Of course in old editors you'd lose the ability to see the geometry in your map, but in a lot of cases I don't think this would be much of an issue as you'd position the brushes in your prefab map file so that a sensible anchor point would be at the origin.

Thoughts? 

Is how to ensure that the textures are still aligned. Translation is easy, scaling is not so easy, and rotation is a bitch. Also difficult are targetnames etc.