First of all, those brushes are lost. You cannot replace nan with anything because the information is lost.

Second of all, does the editor load the map despite those errors? It should just skip these brushes and continue loading. If it doesn't, then that's a bug that I need to fix.

Thirdly, you might be able to go back to an early state of the map where these errors haven't occurred yet by looking at the autosaves. These are in a directory called autosave within the directory where you map file is located.

Finally, it would be super useful if you could somehow replicate this problem. It must be some tool or some transformation, or a combination of them, that leads to this. Maybe if you go back to an earlier state you can remember exactly what you did to these brushes? Please try to nail this down and then give me an example map file with instructions to replicate the problem so that I can fix it. 

No, the editor refuses to load the map. It just gives me the error message quoted above.

What I've managed to do in the mean time, though (before I read your reply), is to replace every instance of "nan" with "0" in a text editor, using find+replace. Afterwards the editor loaded this modified map.

For what it's worth, in every instance where I had "nan" in the map file, it was one of the last three numbers on the line, and the other two were "1" -- i.e., the line ended in
nan 1 1
and I changed it to
0 1 1

I don't seem to have an "autosave" directory -- TB never seems to create one in any of the directories where I keep my map files. This is TrenchBroom 2 on Linux, by the way. 

I kept a copy of the map file with "nan", though. 

Ok, but those brushes should be quite distorted now, if they show up in the editor at all. Can you still try to reproduce this?

I have created bug reports for the map loading issue and for the missing autosaves on Linux. 

unless the nan was created as a number approached 0? 

For what it's worth, in every instance where I had "nan" in the map file, it was one of the last three numbers on the line, and the other two were "1" -- i.e., the line ended in
nan 1 1
and I changed it to
0 1 1


That's just the rotation part of the texture info, correct?

(# # #) (# # #) (# # #) name offset offset rotation scale scale

Seems like changing it to zero should work fine. 

Good find, Rick. Total_newbie, please send me that mapfile. Maybe I was on the wrong track. 

Sounds like you may be narrowing it down, but I saw this article the other day on floating point exceptions - throwing an exception when the code does something that generates a NAN. It's VisualStudio specific, I think, but could be useful for debugging.

https://randomascii.wordpress.com/2012/04/21/exceptional-floating-point/ 

 

 

and got amazed. In The Joker's words, it's a wonderful toy.

It still doesn't deal very well with Valve220 maps, right? I opened an old level and the textures were all crazy rotated. Something about Quake format not supporting texture rotation like Valve220?

Not even a request, just a feedback. Congrats and thanks to SleepwarkR for this amazing tool. 

"SleepwalkR" grrrr... sleepy post. 

Is only supported in TrenchBroom 2, currently in development. 

SleepwarkR 

That's me... while playing your maps! 

Here is the bug report for the nan issue in case you find out how to reproduce it:

https://github.com/kduske/TrenchBroom/issues/1069 

Ok, thanks; I'll keep trying to reproduce it and I responded on github. 

I am making new test builds right now. I have done some open heart surgery on TB2 by replacing one of its core data structures with a different one. If all went well, you will only notice that maps load a little bit slower now. Otherwise, the new data structure should behave in the same way as the old one, but the code is much better and hopefully it will have fewer strange bugs once the initial kinks are out.

Regarding the performance of map loading, there's potential for optimization, but as it's still very fast, I'm probably not going to realize that potential as the optimizations would make the code less clear.

My own testing indicates that the new code works fine, but I'm sure you guys will find edge cases that I haven't considered. I'm sure if necros tries the new build, he'll make it crash on first launch. 

It crashes while loading jam6_ericwtronyn.map though (included in the mapjam6 zip.) - segfault in Polyhedron::intersectWithPlane. 

Thanks ;-) 

Turned it into a test case and will investigate tomorrow. 

 

The bug is now fixed and the map loads fine. I'm uploading new builds now.

What do you think about the difference in load time? 

Confirmed that jam6_ericwtronyn.map loads. That fixed telefragged.map (from the RRP devkit) as well.

The load times seem fine, telefragged.map loads in about 5 seconds, jam6_ericwtronyn.map in 2. 

I don't think it's necessary to optimize that then as loading happens rarely. It's tempting, but the advantage of the current algorithm is that it has a simpler invariant.