I'm happy you seem to be able to use 1.5 easily (personally I consider it unuseable after earlier versions). But the simple fact is, some tasks take longer or take more steps. It was unecessary to change the brush manipulation stuff (if it ain't broke, don't fix it!). The new brush controls might make it easier to learn the editor or might make it more comfortable for maya/wordlcraft/whatever users to adjust...

...but for experienced radiant users, it just plain sucks. What GtkRadiant had over other editors was the sheer speed and efficiency with which you could manipulate brushes (create, re-size, edge & vert manipulation, etc).

Once you get used to it, you'll be just as fast as you were with old style radiant.

Its simply not true. In 1.5.x, you drag and edge or a vert, you have to select the brush, then turn on edge/vert mode, then select the vert/edge, and then drag it. In older versions, you just select the brush, hit edge mode and drag the vert straight away. 1.5.x adds the unecessary step of having to manually select the verts you want to move before moving them. Therefore it will always take longer to perform basic operations like dragging verts and edges. Therefore mapping time increases substantially over the course of a project. The sole benefit that the new 1.5 method brings is that you can select more than one vert at a time to drag... but considering you probably only want to do that at most 1-5% of the time, you lose more time than you save.

Basically all the new brush manipulation stuff is pants. Most especially the texturing. OMG having to select the brush, then hit face mode, then select some shitty handle on the face you want, THEN you can finally apply a texture to it? I mean what in the flying fuck... Radiant had an awesome texturing system, you could do so much cool stuff quickly, why change it?

New methods of doing stuff is fine and good but make it an option and put the traditional Radiant style editing back as the default. There are a few new things that work well and should stay (eg the Maya style handles for rotation of brushes only, but the new stuff should be optional and the old stuff should be restored as the defaults. Come on SpoG, at the very least put an option in there for old style editing that actually works. 

yeah. 

i actually hate this change in radiant 

I will try it this evening, thanks a lot for this advice: it's a very good idea !!!
Just a few question: have you tried this method with lightning in one of your map before ??? 

You can hit the magic "q" key, and have the brush resizing etc the same as in previous versions of GTK. But yes, I prefer to use 1.4 myself, and for DooM3, I am quite liking the built in editor, although there are things i wish were different, and more GTK like, but oh well.......................

Having an option to either have the new style, or the old style (with selected improvements) would be nice 

Vorelord: that's nice in theory, but in practice it actually does not revert back to the original controls if you press Q. It does allow you to do old-style brush moving and resizing, but, you still have to switch modes back to the new stuff to do vert/edge manipulation. And of course you still have to switch to face mode to texture stuff.. etc.

The fact that radiant editing features mostly were not broken up into different modes (eg face mode, move mode, select mode.. etc) is the main thing that set it apart from the other editors, and one of the big reasons Radiant was the editor of choice even for games like Quake (which it didn't natively support).

I don't mean to bitch so much... I do appreciate the efforts of SpoG and everyone else who has contributed to GtkR. I'd really love to be able to upgrade to 1.5.x as there's some cool new features and improvements, however on the balance of things it is not worth upgrading because of the big backwards step in editing speed and efficiency. 

It's not a "fix" to revert to the old, it just gives you some of the old ways back. I prefer the old way myself, IMO, it was far more intuitive. 

I haven't used it, but I have been using an older version of GtkR for Q1 mapping for some time. Based on the very detailed rants by Frib, I can totally agree with what seems to be the general opinion: it wasn't broke => it shouldn't have been fixed. 

I've been forcing myself to use GtkRadiant 1.5 while working on my q3 map and here's what I've noticed...

-middle mouse for copying textures was a priceless feature, and yes I know it will be back
-using ctrl for skew was really fast when vertex manipulation is overkill
-face selection mode is good for texturing a lot of faces at once, but for doing a single face the old method was 10x faster. There's no reason the shift-ctrl method should have been removed 

is the new method faster for selecting multiple faces than the old shift-ctrl-alt method? O_o 

necros: no.

And I agree with all general comments that texturing and skewing was a lot faster in GTKRadiant versions before 1.5. I can understand trying to unify the interface, but making something slower and then not listening to your testers when they ask you to make it faster is just not a good policy.

Frib: out of curiosity, what version of GTKR do you currently use? I have 1.4.0 from Dec 21, 2003 and there are a few bugs in there that really get me annoyed (b0rked edge selection and clipper preview are the big ones). 

I've made it clear that I'll be using GTK for the first time when I start my third map. Taking in all these comments, I'm pretty sure I'll use the 1.4 version.

Two reasons: It will be a Q3 bsp, so I don't need 1.5's native Q1 support.

Also, am I right in assuming that 1.4 is more similar to DoomEdit than 1.5? I'd imagine that would be handy when (if) I start D3 mapping.

But mainly, all this talk of 1.5's clunky interface has really put me off. 

Check the latest beta from www.qeradiant.com, it has old-style vertex/edge dragging... 

necros: Not faster no, but when you attempt the scale multiple brushes along a common plane, I find it's very handy to be able to drag in only 1 direction, rather than the old style where it'd be common that you'd accidentally pulled a bit to another direction and ended up with one of the brushes with a side moved that you didn't intend. 

well, in 1.4, there are three buttons on the tool bar, X, Y, Z which lock the scaling in only that one direction at a time... so i fail to see the advantage... 

Is that what those buttons do!? I never touched them, figuring them to be shortcuts to scale on axis by a value. Thanks :D 

I use 1.2.13 which is the last stable version which has all the features I like working and stuff. 1.4 is ok but it has a few old features that are broken (like paste to camera, dragging and dropping textures onto faces from the texture window, etc etc).

I've tried 1.3.8 and 1.4 but they don't really offer anything new that is useful for quake based editing, and some features are broken or missing, so you're really not missing anything if you're mapping for q1. For anyone doing q1 stuff I'd recommend using 1.2.13, for sure... edit mostly in q3 mode and then use a map converter or DuBSP to directly import the q3 map format. So, to get it all working

1. Install GtkRadiantSetup-1.2.11-Q3RTCW.exe
2. GtkRadiantSetup-1.2.13-update.exe
3. Use Tigger-on's setup guide here: http://industri.sourceforge.net/howto.php
4. Map and be happy! 

RPG: yeah, I don't like the dodgy clipper thing either.

Kell: It will be a Q3 bsp, so I don't need 1.5's native Q1 support.

You don't need native Q1 support to map for Q1 in Radiant anyways. I guess it probably helps in some ways, but once you have it all set up (and yes, it is a pain in the ass, but Tig's setup guide makes it a lot easier) its plain sailing from then on.

I do use Riot's DuBSP so I don't have to worry about converting the .map to Q1 format, but you can use Sleepwalkr's map converter to convert it and then use any old bsp compiler too.

Aquire: It would be really awesome if you could include Q3 map format support in your BSP programs. Its really handy in DuBSP to be able to just use the -q3import switch and have it all work like magic. The map converter is ok but its an extra step and its a bit of a hassle at times. 

Well, I've implemented your method to have a permanent lightning effect, and it works fine :)... I've just a problem of "location" of the lightning beam (at the bottom of the door instead of the top as wanted...), but it's pretty easy to correct...
So, just great thanks for your help man.. Bye.. 

does that paste only the position of the camera or does it include rotations and stuff in gtkrad? I remember using paste to camera position with brushes in conjunction with a command to get the normal for a face in ogier to angle sunlight the way you wanted without having to think about what numbers to put in yourself. 

If all goes well, the upcoming version of my compilers will have a -q2map option which enables support for Q2/Q3 style map format from e.g. GtkRadiant. 

When playing through Kona's Carved In Flesh pak, I suddenly was thrown out of the engine with a Trigger in clipping list messagebox. It happened when I fired the newly acquired positron beam weapon in a certain direction. Does anyone recognize this or know what the cause could be?

It appears to have some similarity to the recently fixed e2m2 easy skill crash (also appearing in Ariadat). I've tried several engines with the same results. 

after compiling well for a period my arghlight suddenly fails to run on winxp.
Now everytime the message appears
light.exe failed
or
file read error
and
SV/model/index:modelprogs/player.mdl not precached

It just happens after a time of well compiling,
what goes wrong? 

this is more of a qc problem then engine oriented.

quake builds a clipping list at some point during map load. when you switch an entity's .solid setting later on, this causes a problem because quake finds things in the list that don't belong there.
the trick is to use a setorigin(self, self.origin) to 'refresh' the list.

i guess an engine alternative would be to refresh the list everytime qc changes the .solid setting... 

Thanks for the info, after some investigation I also think it's somehow QC related, possibly the self.solid isn't properly set (to SOLID_NOT?) after the player has grabbed the positron weapon.

I had this problem now and then throughout the whole pak which prevented me from using that weapon effectively.

I've now at least added the classname of the malplaced trigger edict (here posibeam) to the printout to ease troubleshooting.