light emmiting customs

When I compile using the -wadinclude <wadname> pram, the light from my custom textures doesn't iluminate nearby surfaces which it did without the -wadinclude command. Heres a screen so that you you know what I mean what I'm saying:

I trust you compiled with the correct .rad file, and have entries for those textures in your .rad file?

I've never had any trouble with -wadinclude breaking texture lights, very strange

If you have tried multiple times with both wadinclude and NOT
wadinclude, and it always comes out like this, then my only suggestion
would be to use -nowadtextures. That parameter includes all the used
textures into the map, rather than just the specified ones. If you are
using mostly custom textures then it won't make much difference to
using -wadinclude in terms of resulting file size, though it will be a
big waste of space if you are using mostly default textures. Chances
are it will make no difference, but it is at least worth a shot.

-wadinclude definately should not break texture lights. I agree with ReNo though, -nowadtextures is usually faster/more convenient. On the other hand, I think that screenshot looks pretty cool, kind of like a Tron-style level. :smile:

Campaignjunkie said:
-wadinclude definately should not break texture lights. I agree with ReNo though, -nowadtextures is usually faster/more convenient. On the other hand, I think that screenshot looks pretty cool, kind of like a Tron-style level. :smile:

You havn't seen it lightned yet :razz: , Thanks I'm going to compile in a minute, the problem is it takes about 30mins+ per compile, so I have to ration them to ensure I've made enough change to the map to warrant it. And I have the RAD file with names of textures and lights set up, which worked without the new pram, so I'll have to see what happens when I do this compile.

I'm still having the problem, even when I don't include the new pram. Heres a pic of the pram list, perhaps it differs in some way to everbody elses. Could someody tell me if its in the right order?

looks fine matt.

if your still getting the same problem, even without -wadinclude or -nowadtextures, then the 1^st place i suggest looking is the .rad file you're using.

what values have you given this texture?

labstep 0 94 249 50 <-- that being the custom texture
~LIGHT3C 253 253 0 50
~LIGHT5A 0 26 255 50

Did another compile, and its still not working, so I'm a but lost now

Umm you dont have CSG checked in the screen you've shown.

labstep 0 94 249 50

the 50 seems a bit low. normally i'd think of what value i'd want to use if it was a point light, and then add a zero. i suspected this was the case when i seen that the texture was emitting light in the pic, but not enough to illuminate it's surroundings.

try 500

there's 2 instances of csg in the pic. only one needs to be checked. :razz:

I'll try anything once :smile:

Ah, I think Fishy is right here. In the screenshots, the texture is lit as if it is a working texture light, but it emits bugger all, and a brightness of 50 explains that. Bump it up to at least the hundreds and see how it is, you may have to go even higher to get it looking how you want.

Depending on how bright you want it to appear, I usally take my light
values from the already present .rad file with VHE - 1000+ at least is
needed to light even the smallest areas.

ta, I'll bar that in mind. Once I've successfully compiled later (VHE keeps crashing) and it works, I'll mark the post resolved.

one time i had a target for a texlight and it "teleported" the light just in case i highly doubt it was that . it was very odd maybe i should try and recreate it it may be useful someday...