Did you get my last two emails? 

Yes indeed. It just takes me time to reply, cos I have to go home and extract stuff and walk back to the 'netcafe then remember I need to visit an ATM and...you get the idea :P

Mail imminent, btw. 

I was looking for a GTK q1 map compiler
that dosen't use java. I thought i saw a
version which didn't require java.
Any help.
thanks in advance. 

I believe GTK 1.5 supports q1 "out of the box". 

GTK 1.5?
I only see 1.4. 

http://zerowing.idsoftware.com/radiant-files/nightly/1.5.0/

much has changed since 1.4 though... 

Life is good....
Now if i can only learn to map like others.
Thanks for the HELP.
-water 

what's the deal with 1.5?
when you say "much has changed" how much is much?

i realise the chief change in 1.5 is that you can load q1 .maps and load q1 .wads, but what about the controls? are they the same?

i still use 1.4 because using batch files and converting the q2 map files into q1 before compile really doesn't bother. how much am i gaining by switching over? 

necros - well, hehe, I'm a Hammer user atm, so I don't actually use GTK, but I follow its development because I will be using it to make my next map - which will be a Q3BSP for DarkPlaces. I'm sure there are plenty of 1.5 users here though that will be happy to explain the changes.

h20ryder - you're welcome! 

Your using 1.4?
What do you use for compliling may i ask.
That was my original question..
Thanks.

I'm going to try 1.5 anyway. 

well, i map as normal in 1.4, saving the map file as a q3 map.

since the file format difference between q3 and q2 is practically zero, i use sleepwalkR's mapconv utility to convert the .map into a q1 map file.

then i use aguire's compile tools ( http://user.tninet.se/~xir870k/ ) as i normally would on a q1 map.

all of this is up in a bunch of different batch files, so i just type "quick map" and it does all the stuff to map.map :) 

sorry for the double post.

i've got a map with 32unit thick bars every 32 units, so there are gaps in between these bars of 32 units. on the floor.

monsters won't cross over these gaps when running/walking. even if there is a clip brush which overlaps these bars and gaps.

what gives? i thought the clip brush basically added the collision data to hull1 and hull2... so why do the monsters still treat the area as if there were gaps in them? 

Yes! I've been meaning to ask this very same question - I noticed it in Bastion, and other maps and it has always bothered me. 

it must be something to do with tracelines in the movetogoal code only using hull0 or something. 

Part of the code that monsters use to do pathfinding uses hull0, i think. 

Could anyone point me to some basic tutorials on D3 mapping preferably non video ones as my poor 56kb wouldn't like it. 

Could someone tell me how to open the texture window with actual textures in. 

Scrap that, got it all working, yes I suck. 

I've seen some really good tutorials on map scripting (like how to get custom machines to animate properly) at doom3world.org.

Also, http://www.splashdamage.com/index.php?name=pnPHPbb2&file=index , has a forum to help level designers specifically on multiplayer matters. 

Have a dig around this site/forums, you should find some useful stuff.

http://www.doom3world.org/index.php 

sorry, didn't see it already above in HT's post 

I like being able to load wads into the editor without all the fuss. However in 1.5 i am unable to select a single face to change the textures. Is this a bug? Or is it me.
Thanks in advance.
-water 

It is you. http://zerowing.idsoftware.com/radiant-files/nightly/1.5.0/docs/ 

i hacky way to get monsters to cross gaps in the floor is to make an invisible func_wall entity (like hipnotic's func_togglewall)
that way, you still can't see it, but tracelines *will* impact on it's surface.

the downside is that you can't shoot through the gaps anymore, and gibs will land on them as well...

i suppose it could be possible to make an entity somehow toggle on and off depending on if a rocket was touching it or not, but i doubt that would work well... 

i get allocblock: Full.

now, i know this has to do with lightmaps and sealing the map usuall helps, but this is a little different than normal.

the map is still very small, only 1000 brushes or so. i've had maps that were 3000 or so brushes, unsealed with tons of lights without bothering quake a bit.
this map only has half a dozen or so lights.

also, i noticed the light compile time took much longer than normal. a few versions ago, it was lighting in about 1 sec while on this attempt it took 10 seconds.

aguire: this might be some issue with the actual light utility (or something i did which made an issue with the light utility) so i'm going to be messing around with stuff a bit to see what i can do.

thought you'd like to know or you might know what to do?