News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
 
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 
how do I give a static entity a damage exposure? 
Fast Answer 
you cannot, it is static! 
PaintBroom 
 
BrownStrokes 
 
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 
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 
the thing you want is a trigger_hurt

I think 
Leaks And Portals 
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 
Also, what causes clipping warnings? I'm guessing it's when two brushes intersect in the same space. Is this correct? 
More On Grafx2 
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... 
Clipping 
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". 
Ruin 
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. 
 
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... 
 
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. 
 
If the texture name start with a "*" it's liquid. 
 
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
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.