Ok, now THATs a gap

[Springheel]

If people think it's a good idea, it can be extended to include options to find slivers, overlapping brushes, duplicate brushes, distant faces aligned with VPs, etc.

 

Sounds very cool...I'll test that out too.

[Springheel]

Is it possible for this problem to be caused by func_statics or models?? I thought only worldspawn needed to be considered.

 

Well, copying all patches and func_statics, as well as brushwork, to a new map retains the problem, so it would seem so.....

[RJFerret]

It strikes me that finding off-grid worldspawn and slivers and the like is an ideal job for DR's scripting capabilities.

 

Funny, last night I had the thought this should be an automatic function too. Brilliant you made it! Sadly the script is generating a lot of false positives.

 

Using your script, it selected all my visportals, as well as other objects (set to grid 1), which were all on grid. Nevertheless I ctrl-g to snap to grid, and the script selected them yet again. I snapped vertices to grid, and it picked them again. Most the objects were not cubes, but some were as well (which was aligned to a grid of four).

 

That brush was not selected when the dropdown of script was switched to four, but it was selected if set to one.

 

Edit to add: It seems to be selecting anything that has an angle, or has something intersecting with it.

Edited February 3, 2014 by RJFerret

[SteveL]

I'm working on the false positives. Damn, they didn't show up in a test map, my fault for posting before trying it in a full map.

 

What's happening is arithmetic weirdness. I thought there'd be no floating-point errors to worry about since everything is in base 2 (grid size 0.125 upwards), but I'm seeing results like 352.0 mod 0.125 = 0.125, and occasionally 1.42108547152e-13.

 

Apologies, I'll take this to a new thread after trying to fix the arithmetic, implementing it manually rather than relying on the library function if need be.

[Springheel]

*sigh*

 

Hour 3 of trying to track down what's causing this damn gap.

 

Can someone who understands the way tris are generated help me with this screenshot? The red arrows are pointing to the top/left edges of the gap...it should be a solid wall. Is this shot giving me any useful information? Is it weird the way all the tris are meeting in the center like that?

[Springheel]

So, this has been my afternoon.

 

Load up testmap with problem building. Try deleting something or turning something to func_static. Sit around for 3 minutes for it to dmap. Test to see if gap is still there. It is.

 

Repeat

 

Repeat

 

Repeat

 

Repeat

 

Repeat

 

Repeat

 

Repeat

 

Repeat a few more times.

 

Finally find a small, hidden brush that was z-fighting with problem wall. Delete it. Dmap and load map. Gap is gone!! Yay! Problem is solved. But just to be sure....

 

Recreate testmap with complete building. Delete problem z-fighting brush. Dmap and load.

 

Gap is still there! Curse. Swear.

 

 

So apparently, fixing it requires a combination of deleting that brush and something I did during the dozen experiments, which I now have to go back to and repeat one at a time.

[SeriousToni]

This reminds me of the days I've spent trying to get my head model into the game. It didn't end up succesfully btw.

[grayman]

@Spring,

 

Can you make your current map available? The corner where the tris are meeting (at the green arrow) indicates that the edge of something is touching the wall at that point.

 

I'd like to see what that might be.

 

Perhaps your map has some corruption in it. Perhaps a poorly-defined brush that DR won't draw but that dmap tries to do something with.

[Springheel]

Ok, there's now a head-shaped hole in my wall from all the banging against it I've been doing, and I've gotten nowhere. I'll PM you a copy.