The difference is, not everybody wants to drag it with the mouse. I'd prefer to use the keyboard shortcuts to move stuff when it makes sense to do so (for greater accuracy and/or speed).

This would be particularly true once you add the fly camera mode, so you could stay in that mode (assuming it's a toggle) and not have to turn it off to move something. (I'm assuming like Radiant and Hammer, you'd lock the cursor to the middle of the screen when engaging free fly mode so as not to allow it to drift out of the viewport). 

Interesting idea. But I think it already does this, because if you paste while something is selected, the pasted stuff is positioned such that the grid-snapped center of the bounds of the objects of the clipboard is at the same position as the grid-snapped center of the current selecction.

So the workflow would be like so: You go to the other end of the map and copy some shit. Then you go to its destination position, select something that's rougly where you want the copied shit to go, and paste.

The only thing you can't do is repeadly transport objects to a target destination without returning to that destination. I guess this is where camera bookmarks, also a planned feature, will come in handy ;-). 

SleepwalkR

No, sorry, your idea sounds good. I was referring to the 3 duplicate answers in a row. :P 

I see the 'render edges' option now. I completely missed that before. Thanks everyone! (I will now request a keyboard shortcut to toggle it in a very small voice... please, sir...) 

For duplicating, I like the sound of selecting and dragging something while holding a key (shift or whatever). That's a pretty comfortable method I've seen in various editors and 3d apps.

The complex multiple key methods and with fixed offsets always feel clunky.

The texture argument is moot. Sorry. No matter how good a set of texture controls in another editor might feel, worldcraft wins because it has those extended controls for texture projection. (Yes, the ones that break Worldcraft compatability with everything else...)

https://www.dropbox.com/s/l1go2qe6l3eakvg/texture_controls.PNG?m

Those justify controls automatically scale and align the texture to the face. The align world/face controls change the projection to one that actually fits on a non-orthagonal surface. Aligning rotated textures is a doddle with the additional buttons for scale, rotation and shift.

Replace is very powerful as well, allowing you to change all instances of a texture in a level with a few clicks, or just select all instances and modify how they;re aligned, scaled or whatever.

For me at least, these controls made all the hassle of the valve 220 format worth it. If we could have that level of efficiency in texture application but not have to piss about converting textures then it'd be like mapping in the future. 

Frib, I'm not adverse to adding the copy + displace in one direction commands that you proposed.

I'm just saying that the duplicate command, whether it displaces by some constant amount in a direction that is dependent on the camera direction (the way it is now), or whether it doesn't displace at all, is not as useful because

- either it puts stuff where you don't want it or
- you might miss that you actually duplicated something (although the selection would flash white to give feedback) and end up with unwanted brushes.

I agree that it should be possible to duplicate stuff with the keyboard, but it should give the user the option to control where the duplicated stuff goes. So Ctrl+Direction keys to duplicate with the keyboard and Ctrl+Mouse drag to duplicate with the mouse. Problem solved. 

One idea that I loved from Hammer when I was doing Left 4 Dead mapping is that Valve does this great this where it pastes to the spot you're pointing at with the mouse. This is HUGELY useful for items and deco stuff.

You already have really good code for pointing into the world (the clipping tool and vertex modes obviously use it), so that would be easy to implement. 

Interesting idea. But I think it already does this, because if you paste while something is selected, the pasted stuff is positioned such that the grid-snapped center of the bounds of the objects of the clipboard is at the same position as the grid-snapped center of the current selecction.

Hmm, it doesn't seem to do that for me (if it did, that would most likely be a fine solution as you suggest). It always pastes it at the same default distance from the camera here, and does not seem to be influenced in any way by the current selection. 

Not exactly a request, just thinking out loud. Would it be possible? I can't think of any alternatives to WC/Hammer for HL1, but an editor like TB could be interesting.

Food for thought when supporting other games, perhaps? 

The justify controls are what my Align button will do. The rest hinges on Valve 220 support, which is planned for release 1.2.

Texture replace is something that could be solved with the search filter. Just filter the map by the texture name you want to replace, select all faces, then switch to the face tab and select another texture.

Not sure if that will work currently, as the search filter is quite rudimentary, but if it doesn't I'll be happy to implement it. 

Ctrl+Direction keys to duplicate with the keyboard and Ctrl+Mouse drag to duplicate with the mouse. Problem solved.

I understand now, and agree that that sounds like a good solution. 

I forgot to reply to that one.

The flythrough mode will allow you to keep editing. The cursor will be frozen in the center (as a crosshair), and you will be able to do anything just like before. Of course, moving stuff will also rotate the camera, but that doesn't seem to hurt as can be observed in this cool video:

http://www.youtube.com/watch?v=ZkFT1ra2w-A 

The new copy and paste code is in the 1.1 codebase, sorry. 

In 1.1, paste will just paste in the original position (if nothing else is selected). I like your idea and will try it out. 

Way to go! I am all about good tool pipelines for game development. Imagine what folks would have done back in the day if the developer tools allowed such an intuitive environment for level authoring. This rocks! I cant say enough how much I appreciate this project.

I have a big soft spot for the older retro games but I have become spoiled by the likes of UDK and unity for level editing. Going back to the old editors lacking a proper 3d editing environment is a big hurdle these days. We are so used to more polished programs.

I think you might just have injected new life into the older titles sir! If you add quake 2 support "KMquake2 entity support would be even better" then I would be lost for months on end making new content for that game.

Cheers and keep up the great work! 

Thanks, and Quake 2 and Quake 3 support is on my todo list. Quite a number of people are asking for it, so I guess it will happen rather sooner than later.

I don't know about KMquake2, is it a mod? If so, all you need is a proper entity definition file (TrenchBroom will load .FGD and .DEF files). 

I mean to write "all you WILL need", because I'd have to do Quake 2 support first. 

Is a Quake2 mod, one that adds a massive amount of stuff. 

Quake 2 and 3 are on my todo list. You're the second person to ask for Hexen 2 support. I have no idea what would be necessary to support that game though. But I'll look into it once I start supporting other games.

Thanks! The H2 community is pretty small but we'd all really appreciate it. I don't think there is that much of a difference between the engines, but I'll see if I can find any necessary details myself. 

Yes, that would be helpful. When the time comes, I can also talk to Ozkan Sezer, who develops the uHexen2 engine. 

If anyone is wondering (and is making odd or very angular geometry) I have found the texture alignment on Tyr's tools to be more accurate when you use the -oldaxis command line argument on the bsp program. Dunno why this is though... 

Maybe we should mention this in the docs:

- In txQBSP, you must NOT supply the -altAxis argument for TrenchBroom.
- In Tyrann's tools, you must supply the -oldAxis argument for TrenchBroom.

The reason is in the method to select the projection axis for the textures. I'll add this to the issue tracker so that we can add it to the docs. 

Well its a recompiled quake 2 engine with tons of extra features added. Indeed it has the .FGD and .DEF files setup. Well sir you had my curiosity now you have my attention.

Cheers! 

Time to put away the Hammer and pick up the Broom.

Just when it seems like things are slowing down around here. Out comes all these wonderful new toys. 

i read this thread lsat week and thought hmm that might be an editor suited for me, Dl'ed it installed crashed checked the req's dl�d MS c++ crap, found out already had that installed. Then i see videocard drivers mentioned and im currently using my Mobo's gfx, meh (burned my gfx card on diablo3)