I'll probably just keep using the version from quakeadaptor then. Converting wads takes maybe 30 seconds, so it's not really a problem. 

Although in general 3.3 has more micro-bugs. 

one of these days I have to try this out...
u should try hammer instead 

Like what? (apart from not working on a bunch of people's GPU) 

I've noticed, though mostly with the entities management of fields getting wiped and it being difficult to set angles on stuff.

I'll miss the entity report feature though, and proper texture lock, so might hold off on a switch until later. 

I've been using the full version of 1.6 for like 5 years, this is old news to me(or is that olds?). But, WC 1.6's 3d viewport doesn't render correctly with my new graphics card (gets all fuzzy) unless I resize it to a perfect square, so I just use the 3.3 version with all the wad converts. I much prefer 3.3 because of the TL rotation as said above, for the viewport fly mode with "z", and for the ability to select objects in the 3d viewport (there's a gliche with this in 1.6 that required turning off hardware acceleration, hince the viewport getting all fuzzy) 

cause texture lock has never worked for me.. no matter what version I use.. mah

anyway I'll stick with 3.3+qadapter 

I think worldcraft 1.6 might be on a halflife disc i bought not to long ago. It advertised having some version of worldcraft on it. 

Should I use this or Radiant? 

But others say that they prefer Radiant. I recommend trying the Quakeadapter on your rig, its dead easy to set up! 

BSPeditor - since its built for Quake and maintained. 

All versions are glitchy. But its a very well built editor, level designers have been complaining at programmers for an intensive period in order to have the level of user-friendliness it provides.

Fucking hell. I'm still drunk. 

I dont know if I mentioned this before but you can drop this .exe file straight into a Quaked Worldcraft 3.3 DIR. It's basically Hammer 3.5.
You can load pointfiles into the editor and 3.5 will let you see the line in the 3d viewport. That was not possible in 3.3. I dont know what the other differences are, but I'm sure it must be better in some way.

http://games.softpedia.com/get/Tools/Valve-Hammer-Editor.shtml 

Thanks - maybe some of the entity bugs are fixed. 

But forgot. Doesn't work for me since it complains that the textures aren't Wad3 format. 

was 2.0 I think 

Added texture-lock brush rotation to QuakeED ...

http://www.celephais.net/board/view_thread.php?id=60225 ...

We could probably have a nicer and newbie friendly editor than Worldcraft and an open source one that can get updates and improvements like FitzQuake or the mapping tools or anything else the community uses.

If you look at the archaic stuff accumulating a ton of rust ... like QME or Worldcraft ... the flaw is that they are closed-source and cannot get an update. So even things like the BSP Editor is ... if you think about ... a non-starter.

And NetRadiant/GTK Radiant 1.5 just isn't "right" ... if Necros won't switch away from 1.4 you know that 1.5 isn't quite a step "forward". 

Can it actually work? The Quake map format has only decimal texture offsets, isn't that too coarse if you want to do correct texture rotation when rotating a brush? 

i've been using sikkpin's qe3 for years now. ne_tower was almost completely made with it.

it's basically gtkr1.4 but works with q1 assets natively.

i wish sikkpin would come back to work on it some more though, as there are some bugs still left. :(

-rotating brushes while texture lock is on with the 90 degree rotations sometimes add or subtract a single unit of offset so that after any rotations you end up with offsets like '3, 63' instead of '0, 64'
-there's some kind of coordinate inaccuracy that shows up when you go near the edge of the grid boundary (+-4096). the solution is to just use a larger grid boundary but that sort of defeats the purpose.
-any undo action that concerns more than 1 entity and a brush will convert all entities except for 1 into a brush the size of the entity bbox and prevent you from saving because of corrupted data. you have to delete all the 'fake' brushes from the broken entities and those entities are lost forever.
-turning off 'use brush float precision' will actually make the editor almost useless for terrain or anything involving vertex manip. turning it on fixes that, but the idea of that option is contrary to what it actually does.
-sometimes vertex manip will split a face that doesn't have to be split. you end up with 2 faces that are coplanar which is sometimes ok, but can often create microfissures when compiling. selecting the brush and moving it will make the editor run a check on the brush faces and remove coplanar faces like that, but that means you have to adjust your vertices and then move the brush. it should do the check automatically.

this is just off the top of my head. but you can work around all the bugs i'm aware of. in spite of all that, it's a great editor.

annd, i'm not really sure why i used this thread as a bug report, but i don't want to erase it now. :S 

-there's some kind of coordinate inaccuracy that shows up when you go near the edge of the grid boundary (+-4096). the solution is to just use a larger grid boundary but that sort of defeats the purpose.

to explain this a bit more...

it seems to be only affecting the visual reproduction in the editor. specifically, brushes seem to be 'ripped apart' and faces disappear. the brush data is still correctly saved, but any brush manip like vertex manip or 3 point clipping seems to use the visual brush as a base and will fail. 

Has additional information in the .map to allow true texture lock. On rare occasions it goes wrong when slicing, creating a 'texture axis perpendicular to face' error. 

So you'll need extra compilers? 

 

Thing is that if you rotate a brush, you have to touch texture rotation and both offsets to compensate for the way Quake handles textures. The integer texture offsets just seem to be too imprecise to do it properly, but I'd have to think about it some more. Does it always work precisely in WC 3.3, ijed? I mean for Quake? 

Like I say, there's the odd screw-up, but rarely from only rotating things. The texture .map entry looks like this:

( 224 -1856 -128 ) ( 224 -1792 -128 ) ( 320 -1792 -128 ) COP1_2A [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1

And there are world or face options for projection.

As far as I know the extra information is culled by the compiler and only used by the editor itself.