♦

Impossible to compile in command prompt. It crashes even earlier.

just found out that it happens with any map. Light will crash like that in any map, even a single box map.

♦

No such file? But the map is there in the same folder as q3map2. ??? Now I'm beginning to belive that the error is not in q3map2's code, but it's something related to windows and/or the file system itself.

if the map is in the same folder as q3map2 the error is that "no such file". But if the map is in OA's folder, the error changes to "Access Violation".

Hmmm, the map compilation has nothing to do with the map being loaded in netradiant or not… It can even be compiled without loading it in netradiant neither starting netradiant at all when knowing what command to type.

Well, the only relation between netradiant and the map compiler is the protocol they use so netradiant can know what happens if the compilation fails, not that much.

Those kind of fail that happens given this or that option, even just changes in the environment are weird.

Sometimes if I close netradiant and reopen it fixes Access Violation. Sometimes just reopening the map fixes too.

My map compiled 100x faster. Previously it'd take more than 24 hours or even more than 48 hours with 1024 x 1024 and samplesize 2 and bounce 8. With samplesize 4 it took half an hour or less.

Not sure if this is the cause for long VIS stage and also hitn brushes becoming solids. It seems that if the map's script folder does not contain shaderlist and in the shaderlist the map's shader, hint brushes become solid and vis takes too much time.

Of course, yes, missing or incomplete shaderlist.txt can lead to hint brushes being solid. I have fixed the one of the map on my end, but I haven't checked it there is one provided with openarena, if missing maybe that's the reason why I got super slow VIS stage, I'll investigate this on openarena side.

Another strange behavior. Now it seems that if I just reload the map, q3map2 won't crash with access violation.

What do you mean by reloading? Reloading NetRadiant?

Not sure if this is the cause for long VIS stage and also hitn brushes becoming solids. It seems that if the map's script folder does not contain shaderlist and in the shaderlist the map's shader, hint brushes become solid and vis takes too much time.

Another strange behavior. Now it seems that if I just reload the map, q3map2 won't crash with access violation.

In the shader script I forced all textures to have external lightmaps and the res and samplesize are all in there, not in command line.

I renamed openarena's folder to not contain any dots or "-". I don't know if q3map2 is picky with folder's names.

Strange, 1024 x 1024 samplesize 12 also crashes.

IT seems that q3map2 is forcibly choosing lightmaps with the same res and samplesize. I do change the script and reload, but I just noticed that everytime I rebuild the light it chooses the same res and samplesize. Something is overriding the shader. Somevalues cause crash even though the generated lightmap is the of the same size as the previous build.

EDIT: Found out why it was stuck with the same values for lightmap. I renamed the map and the textures. But I kept the old pk3 and was editing the new map. For some reason netradiant was reading the shaders from the old version, while I was editing the new shader. I totally forgot to edit the texture names in MAP file. I was editing a map with a new filename while all texture references were pointing at the old shader and names.

I'm not sure if this is related to memory in some way.

The previous issues of the TGA and BSP being corrupted made me first think about it, but then you figured out it was because you used an unsupported ZIP compression, so, maybe your system is fine (I hope it for you 🙂).

Those access violations are really weird because no one ever reported them before. Did you manage to reproduce the access violation with the build from April 2020, or do you only tested the more recent build I sent to you?