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. 

And Ben Jardrup modified the compiler tools to recognize floats.

This is in part why the Worldcraft 3.3 map format is a bit different and part of the reason the texture rotation stuffs work correctly in 3.3 but not 1.6

[And why 3.3 map format 220 isn't backwards compatible for other editors.] 

Makes sense. What compilers, apart from the old ones, don't support floats now though? 

But it doesn't make that .map format backwards compatible for the other editors to be able to import what is in effect a non-standard .map format.

[Except maybe Quark ... but JPL, Spirit or the other Quark users need to post their 2 cents on whether or not it can import Valve 220 map format.]

@ Necros ... I have in the past looked at the QuakeEd source and it is very maintainable. I don't recall looking at it from a multi-platform point-of-view like Spirit would want. That being said, if you can give me a month and 1/2 to wrap up important projects I am attracted to QuakeEd as important project because *THE* Quake 1 mapper swears by it. Sorry, but Necros is the real Slim Shady. You know it, I know it, we all know it. You other mapper may be the next best thing, but you ain't Necros ... 

thanks Baker for clearing that up. 

We're just imitating? Will get me back to the 8 mile. 

i'm not sure if the last part is sarcastically sarcastic or not, but thanks... i guess. o.0

in any case, when you start taking a look at the qe3 code, let me know and i'll start compiling a more complete bug list.

and if you're amenable, maybe a wish list? there are a few things that i miss from gtkr1.4 like being able to ctrl+rightclick to use 3 point clipping. sikkpin really wanted it to require pressing x first. :( 

It's something to be used with caution. Simple brushwork may work fine, like crates and other axial structures, but as soon as sloped surfaces, odd scaling or rotations are involved, things can get tricky. For instance, Radiant tends to use floats to align such textures, which then look right in the editor but do not correspond to the compiler output. It usually results in micro-misaligned textures, off by <1 unit or so. 

Nope :) 

I have noticed this. I use tl a lot and I often notice that a surface needs to be re-aligned with the standard origins then re-positioned, simply because it had drifted a small distance in one direction. I should use 3.5 for a while and see if it helps.... 

For instance, Radiant tends to use floats to align such textures, which then look right in the editor but do not correspond to the compiler output. It usually results in micro-misaligned textures, off by <1 unit or so.

this would explain why when i rotate stuff with TL on, it looks fine, but when i compile or reload the map, the texture alignment is off. :( 

Nah ... not sarcasm at all. Once Upon Atrocity and couple other of your maps were at the top of my all-time favorites list. And I couldn't believe that one with the incredible lighting ... The Living End, I believe.

You might consider posting your wish list and bug list in the thread sooner rather than later. There is no guarantee of any sooner rather than later action on it, but I sure would like to get an idea of what you think needs to be improved.

I mean QER is potentially the most viable open source editor and maybe a graft or 2 of source code from another editor could remedy whatever it does to make it better. I'll never have the time to be an expert mapper, but I sure have a knack for understanding and porting features from one source code to another. ;) 

> 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".

Radiant 1.5 is a very nifty editor, and it is a multi-game editor with a Q1 gamepack.

Any editor will have a learning curve, and nothing about Quake mapping is newbie friendly. How many newbies do you see here?

If you think that Quake editors could ever attract mapping newbies, then you haven't used Sandbox. Quake is about the last game a sane person would map for. Sorry.

For mappers, open source tools are ironically less important (unless they use non-Windows). Functionality and user friendliness, i.e. the ability to create effortlessly, is 2000% more important than open source.

A tool, first and foremost, needs to be suited to the job. If it is closed source or expensive, so be it. What counts is if it's a great tool.

This may not sound like me, but I've lately come to re-evaluate a lot of stuff since I map for newer games.