Quake 1 Lights

(joan_of_clark) #1

i discovered this by accident and thought it could be useful to some. i was messin around w/ mapping under the Tenebrae for quake 1 and came across a utility called mapcon_java. mapcon_java included a quake1.def file for Radiant. this allows for the editing of quake 1 levels in Radiant.

if i place a quake 1 light_flouro and bring up ent box, i get these options:

`3
Non-displayed light. Makes steady
flourescent humming sound

Flags:
“start-off”
starts off until triggered

Keys:
“light”
sets brightness, 300 is default
“style”
0 = normal
1 = flicker (first variety)
2 = slow strong pulse
3 = candle (first variety)
4 = fast strobe
5 = gentle pulse
6 = flicker (second variety)
7 = candle (second variety)
8 = candle (third variety)
9 = slow strobe
10 = flourescent flicker
11 = slow pulse, not fading to black

styles 32-62 are assigned by the
light program for switchable lights
0 is default

so i styled a light w/ style 6 and placed it in a quake 3 True Combat map. i compiled the map w/ q3map_2.5.6_win32_x86 and the light worked. it was styled.

im a recreational mapper so im not up to date on everything. i thought i read the lightstyles process for q3 involved shaders and such. and i thought perhaps this was an easier way to style lights.

the utility that contained the quake1.def file can be found on this page:

http://gd.tuwien.ac.at/utils/sf/i/industri/

(ratty redemption) #2

I think we can make our own .def files for most of the radiant editors, but unless the engine and compilers recognizes the classes, keys and values in the .def file then they won`t be compiled.

eg, I use an additional ratty.def file for wolf as well as the default one, where I have changed the colors of some of the wolf classes, and added in a func_group2 class, which helps me group and filter the parts of the map I`m working on.

this works fine in radiant, but I wouldnt expect q3map2 to compile it... this is also useful for having groups visible in the editor, but not having them compiled... if I then want them to, I just select one brush from a func_group2 and change its class to a normal func_group, then the compiler will recognize it.

I hope that makes sense to some of you guys at least :wink:

(ydnar) #3

I’d suggest upgrading to the latest version of Q3Map2 (2.5.10 as of now).

The lightstyles stuff for Q3/RTCW is experimental, but usable. Don’t overuse it though.

Note the lightstyles from Q1 do not correspond to the Q3Map2 lightstyles.

y

(Hewster) #4

Great idea :slight_smile:
I edited the lightjunior entity shape cos someone in their wisdom decided
to make these the same smape as point lights :confused: although in older
Radiants they were different.

I’m gona use your func_group idea, I have always wanted a way to
group differnt parts / types of the map into easily selecteable groups,
(like Worldcraft, which IMO has a great grouping & naming function)

Ydnar, would it be possible to add a function to q3map2, where if , say
it begins with “func_group1” it will be treated as a normal func_group,
and “func_group2” gets ignored ?

This way we could have “func_group1_2xlightmaps” that would be
treated as a normal func_group (maybe used to group all brushes with
a lightmapscale of 0.5) and another called “func_group2_lights1”
which will get ignored (maybe used for grouping all point lights with a
certain value)

Just an idea :slight_smile:

Hewster

Hewster

(ratty redemption) #5

Great idea I edited the lightjunior entity shape cos someone in their wisdom decided to make these the same shape as point lights although in older Radiants they were different.

I’m gona use your func_group idea, I have always wanted a way to group different parts / types of the map into easily selecteable groups, (like Worldcraft, which IMO has a great grouping & naming function)
thanx, and I also resize some of the non brush ents, as well as recolor them for simliar reasons you mention.

to filter the func_group2, use the gtk filter ents... it seems all the new definitions that the editors doesn`t recognize as treated as ents, even if they are brush based.

Ydnar, would it be possible to add a function to q3map2, where if , say it begins with “func_group1” it will be treated as a normal func_group, and “func_group2” gets ignored ?

This way we could have “func_group1_2xlightmaps” that would be treated as a normal func_group (maybe used to group all brushes with a lightmapscale of 0.5) and another called “func_group2_lights1” which will get ignored (maybe used for grouping all point lights with a certain value)

I also add the key “name” to some of my brush groups, whether they be the original func_groups, or func_group2 etc… the value then helps me organize them in the editor, and we can use the gtk entity info window to select them, as well as clicking on them in the 2d and cam windows… and this name key doesn`t appear to fook up the complies or the map in game.

the problem with grouping non brush ents like this in radiant, is it seems we can only have one classname for each of class, like lightJunior or func_group, but not both.

so perhaps the gtk guys or ydnar could code us some new key, values so we can have a classname of say lightJunior and also have group key?

certainly it would be cool to have custom filtering or moving group options for the non brush ents.

(GlassMan) #6

I’d like to use a quake 1 style flicker on my Q3A flames. I’ve tried using lightstyles with a noise wave parameter but this is causing framerate problems which I guess are related to the 312kb shader file created which is swapping in & out the lightmaps.

In q1 the flicker is hard coded thus:

// 1 FLICKER (first variety)
lightstyle(1, “mmnmmommommnonmmonqnmmo”);

The letters refer to the level of light, cycle over about a second or two and can range from a-z. You can see this flicker operates in a narrow range in the middle and only has 4 distinct light levels.

I’m wondering if there is a way that this effect could be emulated in a way that wouldn’t cause framerate problems and not require so many extra shaders & light maps. I guess that would mean not using the noise wave parameter but none of the others provide the “randomness” required.

(ratty redemption) #7

that type of flickering, using values represented by a-z is used in wolf dlights (dynamic point lights) but they do appear to affect fr… also that is hardcoded into the engine.

I agree it would be cool if we could emulate this in shaders without too much impact on fr, but Im guessing its not easy as it probably would of been done by now.

(joan_of_clark) #8

5th horseman pointed out to me that it had nothing to do w/ the quake1.def but that i was using the style key in ent box. q3 defaults to a random flicker when the style key is set. i’m a tool… :wink: