At work a couple of years ago, I designed and wrote a bespoke pixel-pushing tool in Unity, for making proper pixel-art 8-bit textures (that use a specific palette with defined gradients and whatnot).

Had some crazy features like painting relief maps, and then lighting them to get realistic highlights and shadows. That was probably a bit OTT, as I found the hand-drawn painterly stuff always had more charm.

A useful feature was the ability to paint on a tiled canvas. Really sucks that you can't do that in photoshop.

At some point I'd like to get permission to release it into the wild. It was PERFECT for quake textures, as I made double sure :} 

You have my permission to release it. Thanks! 

I think I mentioned finding that Grafx2 thing here a year or two ago. I've played around a bit with it, but never tried using it to actually make anything.

I mainly use it as an accessory to look at things such as which colors are actually used in a texture and how many pixels there are of each color used.

The interface is hard to get used to, but it does work. 

To make a new art tool and call it TrenchBrush 

how do I give a static entity a damage exposure? 

you cannot, it is static! 

 

 

Go code! 

...for all the answers to my texture programme question way back in #15383. I guess the discussion has since taken on a life of its own, but I still wanted to say thanks. :) 

forget the static entity, let's say I want to give a place a damage function.
Would a door that's blocked someway, and made invissible be a manner? 

the thing you want is a trigger_hurt

I think 

I'm currently working on a new map, and I keep getting a leak message. When I load the pts in Trenchbroom, the line squiggles all over the level, and is nearly impossible to find where the leak is coming from. I tried zeroing in on the coordinates that the compiler pops out, but of course, its just the player entity.

Also, I'm getting a lot if clipping warnings, but I'm not getting an outputted .por file.

Does anyone have advice for this?

Thanks.

Ruin 

Also, what causes clipping warnings? I'm guessing it's when two brushes intersect in the same space. Is this correct? 

Have played about making a tiling texture in grafx2. It does support this, but the interface and documentation is really hard to follow, so a quick guide:

Imagine we want to make a 64x64 tiling texture, but while we work on it we'd like to have a 2x2 array of our texture to see how it tiles. Start a new image in grafx2 and click on the screen size icon. In the box you can edit the dimensions of the texture to be 128x128 (the size of the 2x2 tiling of our desired texture). How to do this was certainly not as obvious to me as to the developers!

Next click on the FX icon, and click on Grid. Set the grid size to be 64x64, but turn off Snap. Now click FX again (confusingly the Grid icon will not appear active if you have turned off the snap feature, but it is working). Click tilemap and then close the FX box. Now you can draw on the texture and all four tiles are altered at once.

This is great until you want to edit a texture, where you need to do things slightly differently. Load the original texture and then resize the image to fit a 2x2 grid. But before you turn on the grid and the tilemap, you need to copy-paste the tile into the other four quadrants, or it won't work.

Why? Well, the program is a bit too clever for its own good. When you turn on the tilemap, it looks to see which grid squares are currently identical to one-another, and connects matching patterns of tile for simultaneous editing. This lets you paste an entire screen from Mario Bros, then edit all the bricks at once, then all the grounds at once etc. But when we have an existing texture and 3 surrounding empty tiles, the 3 empty tiles are tied together, but the actual texture is kept separate! 

"Also, what causes clipping warnings? I'm guessing it's when two brushes intersect in the same space. Is this correct? "

No, the whole purpose of QBSP is to clip and trim overlapping brushes. Well, almost.

What's the specific error? It's usually off grid stuff that annoys it... 

I'm not near my pc at the moment, but I can check when I get home.

I just thought of something, though.

I could copy the map into a new file, piece by piece, and compile it piece by piece until I get an error or a warning. That way I'd be able to pinpoint in exactly which section I'm receiving the warning or error (aside from the inevitable leaks from parsing the level in pieces, of course). 

if floating point error is your problem, copying the map piece by piece is just going to make it 1000 times worse. delete parts of the map until it DOES build.

don't go a little bit at a time, though. you can save time by deleting half the map, and continue with just the half that built. repeat. 

You need to post the exact error message. If it's warning: CutNodePortals_r:new portal was clipped away, that can be ignored or fixed depending on where it is. I can't off hand remember any other errors that mention "clip". 

couple of ideas:
-Make sure you're on the latest TB1 release (1.1.6).
-Use the "force integer plane points" mode in Map Properties. (save a backup first)
-Try both rebbs tools ( http://www.voidspark.net/projects/bjptools_xt ) and tyrann's/mine: http://ericwa.github.io/tyrutils-ericw/
-keep the map boundary brushes that face the void tidy, use simple rectangular slabs
-give the .PTS viewer in TB another chance. the leak lines can look like nonsense at first but try following the line from one end to the other. 

I picked up a map I abandoned ages ago, because I think the map itself is a nice design. I have a light leak that I can't find. No matter what I do it tends to persist.

Can one of you guys help me find the culprit brush?

https://www.dropbox.com/s/229q4jt4rbuvmt8/hellvert.map?dl=0

As an aside, should I persist and try and find said leak now, or should I continue with the map and try and find it later?

Cheers. 

Can't open that .map in gtkradiant... weird?

Anyway, generally the best way to find a leak in a weird place is to cover half the map in a large brush, compile, if it still leaks, cover half the leaky side in a brush, etc etc until you narrow down the area where it leaks.

If it's a bad brush, it will likely be something non-cube, so keep that in mind once you narrow down the area. 

I have a non-ideal solution that works for the time being. I will need to revisit it later though... 

You wrapped the whole level inside *rift1 liquid walls? When I replaced all *rift1 with a solid texture it worked. 

rift is liquid?

I "solved" the problem by putting a giant hollowed cube outside of the sky. I thought I still had shitty geometry that was causing the problems.