Very odd behavior of tools

[motorsep]

This relates to this issue https://github.com/qbism/q2tools-220/issues/13

Basically I build Debug build and it was still ignoring .wals flags. My tools are on D: drive, buried deep in subfolders. Then I copied .exe files into baseq2/ which is on F: folder, not too deep into subfolders. Compiling map worked wonderfully.

Then I decided to rebuild Release build. Copies and overwrote Debug .exe files in baseq2/ folder. The map compiled with all surface/content flags ignored again. So I went back and copied over Debug .exe files that previously worked just fine and .... now they compiled map ignoring all surface/content flags.

What's going on here ?! :/

[motorsep]

The only odd thing I noticed that tools have to be in baseq2\ or else there are some issues happening.

Also worth mentioning that on Windows, 4bsp and 4vis do well with \ in the path, but 4rad can't handle \ and for whatever reason requires / to be used in the path instead (e.g. 4rad maps/ad_sepulcher.bsp works, while 4rad maps\ad_sepulcher.bsp won't - 4rad will complain about not finding path or something like that).

P.S. I think all the surface/contents flags issues were resolved in the most recent build.

[motorsep]

So, today nothing works. I compiled master branch last night and anything I build today corrupts BSP. Player spawns outside the map's bounds, all surface flags/contents are ignored. As if the tools only work when they want to work on Windows :(

[motorsep]

Alright, totally black magic stuff.. I compiled with my old repo, where Paril advised me to add various fixes. Player spawns where he should, but of course there are issues with surface / contents flags. Then I tried compiling current master again - not only I got issues with surface/contents flags, but player spawns outside the bounds. Then I downloaded pre-built binaries - same story, corrupt BSP.

Here is the map, textures and BSP if you want to look into it. Sorry, I give up :(

https://drive.google.com/file/d/1Zo5QFjEF_dU65lhQmvoSgJ3EGvnKt_rf/view?usp=sharing

[Paril]

We've narrowed down the issue to this commit: https://github.com/qbism/q2tools-220/commit/1f89b4c13bd63b04fe4c98d0224d6cf86734f6ae The version I had committed (which didn't include this commit) worked fine, something in this commit causes the map to get cut down into a 2048x2048x2048 cube (1024 on each axis).

I noticed that the max_size/max_block stuff changed quite a bit, but you changed it later on in another commit so I'm not certain. Maybe you have an idea off top of your head?

EDIT: changing block_size back to 1024 seems to fix it. I think the algorithm for custom block sizing might be busted?

[qbism]

block_size implementation was not completed for some reason, with many places still coded with the default. That's been finished. The expectation is faster processing of large maps. However, when I timed a comparison, larger block sizes turned out to increase compile time. Therefore in the latest commit it's a manual setting rather than automatic if anyone wants to play with it.

[qbism]

This issue has morphed into two but I think both are fixed. Please open a completely new issue if any .wal problems remain.