Creating a _sun in GTKRadiant 1.2.1 for Q3A?

[monaster]

That is exactly my problem. Since I'm working on a side project where there's a sun needed that casts light on many many houses (normal brushes, many clipped ones, no terrain), and since I only know of GTKRadiant 1.5.0 directly offering the creation of a sun entity (via an entity key), but having the obligation to use GTK 1.2.1 and nothing else, I wondered if there's a possibility to create a sun entity in that older version? I'd be glad if I don't have to work with shaders because I use a common id-sky texture (toxicskytim_ctf1) because I want to experiment a bit with the sun's position without having to change the shader every time.

I tried to use a light entity connected with an info_null entity and changed the radius but it's still too small to influence the whole map; additionally this method only creates a very intense light source that makes one part of the map extremely bright but rapidly loses light intensity in a further distance. So if anyone has some advise or yet experience with creating a sun for very large maps, that would be great.

[pjw]

but having the obligation to use GTK 1.2.1 and nothing else

Why?

[Scourge]

Wasn't 1.2.1 the anti-christ of Radiant?

[$NulL]

You'd use the same _sun key in 1.2.1 as you would with 1.5.0. Just make sure you have a version of q3map2 that supports the _sun key in light entitys, i dont know if q3map2 that came with 1.2.1 did.

[Kaz]

I still use 1.2.11

[a13n]

/me 1.2.11 + 1.2.13-update
If only 1.2.14.

[Silicone_Milk]

I've always used, and still do, 1.4

1.5 feels odd to me and I haven't had any issues with 1.4 so no reason to move on.

[Fjoggs]

Switched to 1.5 many years ago. Even before they fixed the ctrl-shift-selecting of faces in the 3d-window, which was one of the things that kept people from it.
Now it's the excact same, only better. No reason not to use it.

[fKd]

im still using q3radient2.02. i only use gtk for rotating brushes as q3rad fucks em up wholesale.

[Silicone_Milk]

Switched to 1.5 many years ago. Even before they fixed the ctrl-shift-selecting of faces in the 3d-window, which was one of the things that kept people from it.
Now it's the excact same, only better. No reason not to use it.

Camera control is the same? That was the major turn off for me. No right clicking the camera window and moving around with mouse look.

[Fjoggs]

It's the same. Can't remember it ever being different either.

[Kaz]

That's DOOM/Q4Rad

[a13n]

Switched to 1.5 many years ago. Even before they fixed the ctrl-shift-selecting of faces in the 3d-window, which was one of the things that kept people from it.
Now it's the excact same, only better. No reason not to use it.

Camera control is the same? That was the major turn off for me. No right clicking the camera window and moving around with mouse look.

more turn-off :
texture drag&drop to 3d-window does not werk
strictly, hardly werks

[monaster]

@pjw's "why"?: Because of this:

I still use 1.2.11

and this:

/me 1.2.11 + 1.2.13-update
If only 1.2.14.

and this:

"the ctrl-shift-selecting of faces in the 3d-window, which was one of the things that kept people from it."

I have the non-fixed version of 1.5.0

and this:

more turn-off :
texture drag&drop to 3d-window does not werk
strictly, hardly werks

So much for unnecessary quoting...

Besides that, the q3map2 that came with my 1.2.1 is far more tolerable regarding map size (especially map size!) and a few other things that constantly result in max_map_xxxx errors when using q3map2 with 1.5.0. Other than that, the compiling process is like 10 times faster with the 1.2.1 build, the information output inside GTK 1.2.1 during compiling is 20 times faster (and that actually IS important because the next compiling step -i.e. the vis commands- only start when everything from the earlier compiling step is already displayed; I hope that this explanation is somehow understandable), the scale left to the grid window defining the grid units (0, 64, 128, 256,...) is gone in my 1.5.0 and last but not least 1.2.1 didn't need any extra .dlls in the system32 dir under WinXP Pro - 1.5.0 did (I can't remember which one but it was REALLY annoying to find these). Oh yeah: When editing a larger map (that means one with many brushes, curves,... OR one that has very high x/y/z values OR both), 1.5.0 starts MUCH MORE earlier to judder than 1.2.1 if you're not using a high-end PC.
By the way: is it possible to use two different versions of q3map2 seperately on only one HDD? This way I might have less compiling problems with 1.5.0 because I'm using the q3map2 originally built for GTK1.2.1 for both GTK versions: 1.2.1 and 1.5.0

[monaster]

Thanks for your advise, $NulLm almost forgot about you! I'll check it.
@Scourge: The "Anti-Christ of Radiant"?

[Scourge]

If I remember right, there were numerous shader and directory issues with 1.2.1. I'll see if I can dig up some info on that.

[obsidian]

Mostly misinformed stuff.

GtkRadiant 1.2.11 is quite old and actually rather buggy. IIRC, it's one of the worst releases. If you want the same style functionality, try the very stable 1.4.0 which comes with a recent version of Q3Map2. GtkRadiant 1.5.0 "feels" very different because of some significant changes in how you do things, but once you get used to it, it's really not that bad. 1.5.0 has a better rendering engine that just feels so much smoother, you just have to get used to the new shortcuts and stuff. Both 1.4.0 and 1.5.0 have updated entity definition files, so your _sun entities appear in the menus out of the box.

Grid scales works for me in GtkRadiant 1.5.0. Maybe it's because you're deleting .dll files off of your computer without knowing what they do. I should also mention that I'm using a 5 year old computer and 1.4.0 and 1.5.0 all work fine.

In short, use either 1.4.0 or 1.5.0 depending if you like the classic layout or the new fangled one. Anything else is just old and buggy. That's all up to preference, so you can do what you like.



As far as Q3Map2 goes, I think you are greatly mistaken. Compiled maps are just compiled maps, there should be no significant difference as far as file sizes go unless you are rendering a higher resolution lightmap or something. The chunk data of BSP's is pretty insignificant so I don't know what you are talking about map size.

If you are getting a max_map_xxx error, you are probably doing something wrong in the first place. Q3Map2 2.5.16 compiles more "cleanly" than older versions, so if anything it's compiling things correctly and therefore picking up errors that you've done that it used to gloss over. Using apples-to-apples compile switches, newer Q3Map2 versions are much faster than older versions. If you are getting longer compile times, you're probably making use of additional radiosity passes or something for better quality lightmaps that you don't know about or didn't put into consideration.

The BSP and VIS stages of compiling a map should only take a few seconds or a minute at most. Any longer then you are doing something wrong. Light stages can take minutes to hours depending on settings.

Don't use the default compile options built into Radiant's BSP menu options, quite frankly, they suck. Learn to compile with a batch file or a front-end like Q3Map2Toolz. Much better results and you will be using Q3Map2's full potential.

Yes you can have more than one version of Q3Map2, they are just a command line executable and a few .dll files. Execute them as mentioned above, using a batch or front-end program.