CTRL++ or - to scale the grid. or Ctrl+1 or other numbers to jump between scales.

I would also advise you to give the door some framing with an inset, or you will get nasty z-fighting when the door moves into the wall. 

Thanks for the scaling tip, I had no idea about that.

I'm not sure what you mean by 'framing with an inset' for the door. 

At the moment the door is flush with the wall. I mean making the door a bit thinner than the wall. So if your wall was say 32 units thick, make the door like 16 to have 8 units space on each side. It will look like the door is actually INSIDE the wall. 

Ah ok, got it. I think scaling is going to help a lot as I learn to map. Thanks again. 

 

trying hold shift when a brush is selected. Then as you move your cursor around you shall find different faces will be highlighted, you should be able to click and push the face in or out. 

Thanks FifthElephant, that's really useful. 

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.