Some basic map info on the Quakewiki you might want to look at here:
https://quakewiki.org/wiki/Getting_Started_Mapping


You can get some very nice Q1 map compile tools from here:
http://ericwa.github.io/tyrutils-ericw/ 

 

 

Trenchbroom 2 Beta is super unstable for me, I would love to send crash report, but it crashes too :P

What I'm doing is snapping vertices on a 1 unit grid... 

 

 

 

Feature request! :) Rock primitive like J.A.C.K. Pick your number of faces, randomly generate valid brush. 

 

I just want to say, thank you for convex merge. <3 

Be sure to play with CSG subtract, too. It's pretty smart. 

https://www.youtube.com/watch?v=3x2p2ZD4vWg

This happened to me a while ago now but I never filed a report as the video was all I had. I was somehow able to select a group while it was hidden and this mess of lines happened.

Should I make a bug report anyway? Doesn't seem like much help, i can't recreate it or anything. 

really want to eat strawberry laces now 

But I have seen this before. Did you send me an email? 

Yeah, I did. I wasn't sure if you got that! I'll file an issue, but all I can include is the video... I don't even have that version of the map any more. 

 

"Due to how incredibly buggy TrenchBroom is I spend more time trying to work around the bugs (hello non-integer's)"

Ruh-roh. Is there actually an real issue with non-integer coordinates? I have these all over the place due to clipping tool (ab)use, but they never prevented me from compiling and playing the map I'm working on. Haven't run vis, though. 

Non-integer vertices are not so problematic per se. Non-integer plane points can be, but if you're using the clipping tool more than the vertex tool you might not have too many of those. Also depends on which brushes are affected and how. 

I used to be very sloppy with my brushwork and had a lot of non-integer points/planes, and that never caused an issue with map compile. What really caused issues was vis, which would fail and would generate path files that went straight through solid brushes.

Not every "malformed" brush will cause this, but it's something that you need to be wary of, and test for as often as possible. You can then either fix the brush in question, or create another, simpler brush to cover the gap and help vis succeed. 

Best keep the brushes simple and clean. 

Thanks, that answered my question. 

In a perfect world, math would be much different so there would be only one set of parameters for a numerically stable representation of a brush plane, and not an infinite amount that makes it hard to pick. This is what I really envy from mesh-based modeling. :P 

Mesh-based modelling still suffers from non-planar quads, yet quads are recommended since because edge loops.

I've found that having large brush entities (even func_detail's) that extend into the void can cause the weird vis bug where a leak goes straight through a solid face. I found that enclosing the end point of the pointfile tracer with a solid world brush eliminated the leak. Enclose the end point that is in the void (blue end in JACK I believe). 

DONT FOLLOW THAT LINK