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. 

is there any way to get the standard 4 window (XYZ+3d Views) setup instead of the default wierd 1 top down + 3d + z thing?

also, the "inspectors" window can't be closed... like, you press T and it switches to textures, but pressing t again doesn't close the window... can it be done? 

If you go to the view menu/toggle, select top, side, front etc, they will open, but they are stacked on top of each other, so just drag them aside, position and resize them to your liking.

Inspector window, no I don't beleive it can be closed,(well it can, but then you have trouble reopening it, without restarting the editor) you can manualy move it out of the way, a pain I know, I have started just having it on the lower right, and leaving it there, you can also double click the individual tabs in the inspector window, and they will undock, when you close them they automatically redock in the inspector window.

I have settled for one half screen for the autho veiews, quarter screen 3d view, and quarter view inspector window. I wish I could get rid of the Z window all together, but it just gets hidden out of view anyway. 

I wish it could be set up just like I use GTK 1.4 and previous. I have basically one window open at a time (maximised) and just toggle through the top, side and front views when needed, or ctrl/shift/c for the camera view, and you just hit T, O, or N to bring up the tex,con or ent windows, but alas........... having to use little windows makes me feel like I have to bend down and try to peek in, I much rather the full screen area (maximised) for each window, much better. GTK 1.5 doesn't seem to allow me to do this either. But beggers can't be choosers 

When looking at the "Carved In Flesh" thread here I noticed that cyBeAr also had the same problem with the positron gun with Win/FitzQuake, but DarkPlaces handled it better.

After some investigation, it appears to be fixable in the engine so I've done the same in my engines. It might still be a problem caused in QC of course. 

well... one could argue it is a problem with the engine, because, really, it should check and refresh the list when a change is made to an entity's solid type, however, it's easily fixable (by using a setorigin function right after) so it can also be argued that it is the qc coder's fault that he/she did not take this into account.
therefore, i'd suggest you actually leave it as it was (broke) so that when people test their mods out on your engine, they will get that error, find out what it is and fix it so it works in all engines.

0.02 ;) 

make the coders work for their crust! 

since the major goal with my engines is to be able to load (and play) maps that others can't, I can hardly leave it broken if there's an easy way around it.

Also, using my engines as a test for classic engine load/playability, is not really recommended since they have significantly higher limits. 

well, ultimatly it's your choice, but this is simply a bug that should have been fixed in the progs.dat. changing the engine so it doesn't complain about a bug that could have been fixed doesn't make sense to me.