News | Forum | People | FAQ | Links | Search | Register | Log in
Tyrutils-ericw V0.15.1
Hey, I got around to setting up a website for my branch of tyrutils: (complete with lots of screenshots of different settings of AO, sunlight, etc!)
and making an "official" release of it.

Nothing major changed compared with the last snapshot (may 1st), but a couple new things:

* .lux file support from Spike, for deluxemapping
* gamma control with -gamma flag and "_gamma" key
* rename -dirty flag to -dirt for consistency
* fence texture tracing is now opt-in only with the "-fence" flag.
* light should run a bit faster

This doesn't have lit2. Not sure what to do with that, tbh.

If there's a demand for it, I was thinking I could make a tool that upscales all textures in a wad by 2x or 4x, and adds a "-2x"/"-4x" suffix to the names. You could then manually get the higher-res lightmap on certain faces by applying the upscaled texture, and lowering the texture scale to 0.5 or 0.25 in your editor.

The only real disadvantage of this hacky method over lit2 is more face subdivision by qbsp. This isn't great, but it shouldn't be an issue if the hack is used sparingly (and bsp2 can be used if needed for higher face/vert limits.)

Anyway, enjoy, I hope this is pretty bug-free.
First | Previous | Next | Last
I Have An Iq Of -94 
Sleepwalkr, I'm fixing the fgd but I don't understand a few parts of it.

_range(integer) : "Global light range" : 0.5 : "Scales the brightness range of all lights without affecting their fade discance. Values of n more than 0.5 makes lights brighter and n less than 0.5 makes lights less bright. The same effect can be achieved on individual lights by adjusting both the 'light' and 'wait' attributes"

If I just set the value type to float instead of integer will that fix the error? This value defaults to 0.5 and 1 will change light values in the map.

@baseclass base(Appearflags) flags(Angle) size(-16 -16 -24, 16 16 32) offset(0 0 24)
color(0 255 0) = PlayerClass []

Honestly I just copied this from the fgd that ships with Jackhammer so I don't actually understand it. Can you post the correct syntax and I can update it!

<3 <3 
For float values, just use string! 
The integer vs. float thing: Integers cannot (or at least should not) have non-integer values, so that default value of 0.5 is nonsensical. Either use float or use an integer default value. If non-integer values are supposed to be okay, then do this:

_range(float) : "Global light range" : "0.5" : "yadda yadda"

As necros said, default values for floats should be in quotes.

As for the flags thing, what are these flags actually for? Does that specify additional spawnflags? Maybe it's something only JH understands.

Either way, TB2 now ignores such things (and gives a warning), but it would be cool if that FGD were compatible with all editors.

If you want, I'll make you a TB2 build to test with so that you can make all warnings go away. 
TB1 also doesn't like the "color255" types used by JH. 
It might be JH specific. Thinking about it now it might be the part that tells the editor to show the direction arrow in the 3d view for info_* and monster_* entities.

I will change to a float for those two non integer integers.

Onetruepurple : the color255 brings up the colour wheel for selecting light colours in an rgb 255 format. it's too useful to remove. It would be wonderful if TB supported something like this but for now I guess sleepwalkr can ignore this specific attribute? 
TB has a full fledged color picker but I wasn't sure how to replace color255 with it. 
It Does? 
I can't find it. TB or TB2? 
I'm not sure how it's set up internally, but if you add a "_color" key to a light in TB1, a color editor shows up when that row is selected. 
i think it is hardcoded currently? _sunlight_color gives a picker, but _sunlight2_color does not, for example. 
TB1 Doesn't Support It 
TB2 will at some point. Right now, the special semantics of that property are ignored, but it will load and it will show up in the editor. 
The Color Picker 
it's not hardcoded, but it tries to guess whether a property is a color property by examining it's name. It's flaky, and the color255 and color1 property definitions in the FGD would surely help. I will support those in TB 2.1 
I just tried out this new light utility. I'm have trouble getting lava to look right, but I'm sure I'll get it figured out. One question. Is there a limit to how many surface lights? Because I'm getting some ideas here. I realize it's just one light per texture name, but if I have 30 different light type textures, each can have a different type of surface light emit? 
no problem having multiple surface lights with the same texture name.

The way to think of it is the "_surface" key causes a light to be deleted, and then copies placed across surfaces with that texture.
There is currently a 65k limit on total number of lights, for no good reason, but the light tool will be really slow if you get anywhere near that number of lights. 
Okay, so it's possible to have multiple different style lights per texture name in addition to many light emitting textures. This is pretty cool.

Just as an experiment I lit up a rock formation inside a cave with a func_wall then removed the brush using killtarget on a trigger when the map loaded. Worked fine.

I like that the color of the light is controllable. The Quake 2 surface light color was taken from the texture which probably contributed to its reputation for garishly colored lighting. 
Surface Lights Moved From Jam Thread... 
yeah, what happens is the surface lights are already spawning arrays of lights, then each of those lights gets another array of lights. I ran into the same thing, but when you think about it, deviance on surface lights is only necessary if it is a single light (eg: a small wall texture), but not in the case of lava.

i wonder if you could track how many lights have been spawned as part of the surface lighting and if it is over a threshold, do not apply deviance lighting. just some internal tracking, nothing added to the actual map or anything.

because you would want to use deviance lights for small 32x32 lights, for example. 
Hm Good Idea 
That would be nice to have. Maybe I was premature to disable combining _deviance + _surface; I could just make it print a warning. 

I had to switch to a faster computer for building the bsp because light was getting pretty slow on my editing computer. I now get those jitterning messages I asked about in the mapping thread. First time I've seen them. Not just a few, but screen after screen of it, but it doesn't take very long to get to the progress indication and the resulting bsp is fine, I just thought you might like to know. 
Can You Check You're On The Latest Version? 
Stupid me. There's a copy of the 7/13/2015 zip sitting right there in the maps folder. I guess I downloaded the newer version but forgot to extract it, because the exe in that folder (the one I'm using) is dated 5/15/2015. 
Windows Symlinks 
is there a problem with reading .wads from symlinks? I can only use a single .wad file, if i try to add more than one, it will only read one of them.

although... maybe it's not related to symlinks as it happens if it is absolute or relative paths. 
Help Installing Tyrutils-ericw On Linux 
So I've downloaded and extracted the tgz archive, but I don't know where to go from here (can't remember how I got the original tyrutils up and running, and I'm sure I didn't do it in the most elegant way).

Also, I'm not sure if downloading the archive was the best first step, as I'd ideally like to set it up so as to be directly update-able from github (the way I've got TB2 set up -- but I needed a hell of a lot of help in getting that up and running too, and understood virtually nothing of what I was doing!).

Could someone give me some noob-friendly instructions, or tell me where I can find them? 
I should add these to the readme. Assuming you start in your home directory,

git clone
cd tyrutils-ericw

If there are no errors this will generate ~/tyrutils-ericw/bin/qbsp, etc.

To update:

cd tyrutils-ericw
git pull
make clean
Thank You So Much! 
That was painless :)

Am I correct that the actual programmes are now in tyrutils-ericw/bin? Do I need to cd into that directory every time I wish to compile, light, etc.?

Also, do I need to have the files I want to use (e.g. the .map file from which I want to create a .bsp) inside the tyrutils-ericw/bin directory? I ask because that was the only way I could ever get the original tyrutils to work, but I suspect there might be another way... 
the actual programmes are now in tyrutils-ericw/bin

You can run the from another directory by using the full path to the tool, like this, if you had maps in ~/maps:
cd maps


What I actually do is use this build script:

If you want to try that, save it as, update the UTILSPATH and DEST variables to match your tyrutils bin path and quake/id1/maps path, run chmod +x to make it executable, and copy it to your mapping directory.

Now you can do:
and it will compile and copy the resulting bsp/lit to your quake/id1/maps folder. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.