You'll be happy to know that the old way to draw brushes is coming back in TB2. You will have to enable the brush tool to do it, but then you can just bang out the brushes by dragging as usual. The new mode is only activated if you hold shift while clicking or dragging. 

that does indeed make me happy. Getting the brush mode to work has been a bug-bear of mine though. I've struggled to make brushes in TB2 in 3d view. Also, it would be nice to see a return of the 64x64 unit brush as a starting point when you start working on a new map. 

I was under the impression that BSP2 removed the original +/- 4096 loop boundary but this still happens to me in BSP2 compiled maps. Does it require engine support too? I'm using QS 0.90.1 

BSP2 does not remove the 4096^3 boundaries. 

ohh whoops, i thought those two were kind the same thing. :S 

Caught me by surprise too when I found about it. 

No, the 4096 is tied into the networking protocol and other things I believe. Would be hard to remove. :-/ 

map format already supports larger map sizes, it's the network protocol that is the limiting factor.

I didn't add this feature to protocol 666 because I couldn't think of a good way that wouldn't make packet sizes bigger for normal-size maps. This means you'd get a packet overflow on some older maps that wouldn't overflow on protocol 15. 

The empty map will contain an initial room at some point in the future. If you want to testdrive the new / old create brush tool, I can upload a new build that contains it. 

Mankrip, da man behind Makaku and Retroquad engines, runned my jam 6 level and reported two bugs that pop in software render.

The mipmaps of my fixed rock_brown texture were wrong. I used Wally to edit the wads. Apparently the default settings for Remip Deluxe doesn't work well with Quake software render. I had to go to View / Options / Remip and click the "Use Quake Lookalike Settings" button.

Also, liquid textures bigger than 64x64 get distorted by software render. I was using *lava4a. For full compatibility, I'm changing to *lava1.

DLC will have both fixes. 

How are those custom ammo boxes done, given that this is just a bsp file? 

Do Fitz/QS engines have a command to turn off .lit support? Something to easily see what a map looks like without colored lighting (even if you have to reload the level) 

Hm, just went through all the commands and such in QS, not Fitz though, but QS does not seem to have this. Would be a cool option. Something like r_uselit.

The fastest way now is to rename the lit file to something like lit~ and then restart the map in QS. A bit tedious, but it works. Also damn, some maps look horrible without the lit file, like Skacky's Jam5 map. Super blown out. I think it has to do with the thing that ericw mentioned a while back somewhere about using dark lightcolours. 

Unless you are using BSP2, reQuiem has gl_loadlitfiles 0/1 (also available in the menus). 

Also damn, some maps look horrible without the lit file, like Skacky's Jam5 map. Super blown out. I think it has to do with the thing that ericw mentioned a while back somewhere about using dark lightcolours.

That's suprising, i would have assumed that the non-colored version of the lighting would just desaturate the color while keeping the apparent brightness. 

It could have to do with how .lit support was added to tyrutils, the bsp lighting didn't use the _color keys at all. I changed it, for the next release of my fork, to average the RGB components of the ilt sample to get the greyscale value for the bsp. 

That's a very good solution for sure. And great work on the compile tools in general. 

Careful with averaging RGB, that would give you some weird results. You rather want to calculate the (perceived) lightness of the color. I would need to go through my docs but if you can't find a good solution give me a nudge.

I wonder if the weird green tint on explosions/dynamic lights when playing games with (reddish?) lit files is also due to this. Noticed it a lot in the jam6 maps with QS. 

Actually it looks like averaging won't work..
The constraint is the LightNormalize function that MarkV is using (Baker mentioned that he took it from some QW engines). It scales the lit data based on the bsp file lighting, supposedly to prevent cheating in MP by using a fullbright lit file.

I looked at it again and, to prevent MarkV from scaling the lit data, the bsp needs to contain max(r,g,b). This kind of sucks because it forces your bsp to have overblown greyscale lighting, or else have potentially distorted colors in MarkV. 

1. as Spirit says, don't just do a staight average of RGB. Try instead using one of the formulas from here: http://stackoverflow.com/questions/596216/formula-to-determine-brightness-of-rgb-color

2. Spirit, regarding the green tint on explosions, this happens because the explosion is blowing out the lightmap to white. At the edges of the explosion, only certain color channels are blown out, so you get different colored rings around the explosion based on the color of the explosion and the color of the pre-existing lightmap. To preserve the color better, probably an engine would have to calculate the correct color first for each lightmap point, then clamp all 3 channels to different values to preserve it. 

I wonder if the weird green tint on explosions/dynamic lights when playing games with (reddish?) lit files is also due to this. Noticed it a lot in the jam6 maps with QS.
I think I see this with the rocks in jam6_daz, pretty sure it is completely normal (the rocks have a bit of green in them, the explosions are white so the orange tinted lighting briefly changes to white) 

I think it is more of an optical illusion as well. Partly the rock colours, partly the amount of red on screen getting your retinas to get cyan/greenish afterimages a bit.

If you look at this shot with it looks a bit greenish on the rim of the light sphere.
https://dl.dropboxusercontent.com/u/15588722/post/func_msg/lighting_1.png

When looking at it with lightmap only it is a lot more yellow looking, and there really are no greens as such, but some dirty yellows.
https://dl.dropboxusercontent.com/u/15588722/post/func_msg/lighting_2.png 

Contrast/complement effect from red tinted faces? Someone should test if we see red if the lights are rather green. 

Just made a quick test room with greenish cyan light.

Plop in there and shoot some rockets at the walls. Esp the blue wall looks weirdly purple-ish. So it seems like it does work at least a bit.

https://dl.dropboxusercontent.com/u/15588722/post/func_msg/complementtest.bsp