Could you add support for Xonotic? They're using NetRadiant for mapping, so there's a good chance Xonotic's engine is Quake-descendant. 

Xonotic uses DarkPlaces, but they might be using q3bsp which DarkPlaces supports. If they're just using the normal Quake map format, it should just be a matter of getting the entities straight. 

and if they are enough people asking for it, then yes. 

Some of the levels look like they got a lot of curves, so likely Quake3 format. 

I posted this in the Mapping Help thread earlier, but it then got sort of lost among (very interesting) posts about methods for creating rock brushes, clipping, etc. As I wasn't sure if I was posting in the right thread anyway, I'll try again here:


Just created something in TrenchBroom, saved it, and when I tried to open it again, it gave me an error saying

(line 441, column 107)Expected integer or decimal, but got 'nan'

So I opened the file in a text editor and on line 441 one of the coordinates is indeed "nan" -- but in also in a few other places as well. I am guessing "nan" means "not a number" or "not a valid number"; is this correct?

How on earth does this happen, and how can one fix it? Should I replace all instances of "nan" with something else in my text editor, and if so, with what?

(I should perhaps also mention that I have done nothing really intricate in this map; no rotation; everything on grid.) 

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 ;-)