#15417 posted by Rick on 2015/09/12 20:59:30
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.
I'll Pester Sleepwalker
To make a new art tool and call it TrenchBrush
Fast Question
#15419 posted by madfox on 2015/09/13 03:26:06
how do I give a static entity a damage exposure?
Fast Answer
#15420 posted by necros on 2015/09/13 04:31:26
you cannot, it is static!
PaintBroom
#15421 posted by SleepwalkR on 2015/09/13 08:20:39
BrownStrokes
#15422 posted by Kinn on 2015/09/13 10:05:51
YES
Go code!
Thanks Everyone...
...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. :)
Slow Consideration
#15425 posted by madfox on 2015/09/13 21:04:22
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?
Trigger_hurt
#15426 posted by Lunaran on 2015/09/14 02:41:39
the thing you want is a trigger_hurt
I think
Leaks And Portals
#15427 posted by Ruin on 2015/09/14 08:57:36
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
Clipping
#15428 posted by Ruin on 2015/09/14 09:01:53
Also, what causes clipping warnings? I'm guessing it's when two brushes intersect in the same space. Is this correct?
More On Grafx2
#15429 posted by Preach on 2015/09/14 12:18:40
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!
#15430 posted by JneeraZ on 2015/09/14 12:43:24
"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...
Clipping
#15431 posted by Ruin on 2015/09/15 02:54:50
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).
#15432 posted by Lunaran on 2015/09/15 04:46:56
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.
#15433 posted by Rick on 2015/09/15 05:33:31
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".
Ruin
#15434 posted by ericw on 2015/09/15 05:45:25
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.
Can't Find A Light Leak
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.
#15436 posted by - on 2015/09/16 15:00:28
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.
Thanks Scampie
I have a non-ideal solution that works for the time being. I will need to revisit it later though...
#15438 posted by adib on 2015/09/16 18:20:20
You wrapped the whole level inside *rift1 liquid walls? When I replaced all *rift1 with a solid texture it worked.
The Shame
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.
#15440 posted by JneeraZ on 2015/09/16 18:56:29
If the texture name start with a "*" it's liquid.
#15441 posted by Lunaran on 2015/09/16 19:52:29
Don't box your maps because you can't find a leak. Every editor loads pointfiles, just use the tools to fix the leak. Otherwise you're tripling the size of your .bsp with a ton of useless surfaces, all lightmapped with acres of black.
The compiler needs a leak-free hull to know what surfaces to prune away. When you put the whole map in a box, the compiler prunes away just the outside of that box and keeps everything else.
|