Please help with map - entity leaked + texture errors

[RotaryFist.cz]

Hello,

Im an occasional and rather noobish map-maker, and Im quite desperate from the map Im working on now in GtkRadiant 1.4. Basically it is a medium-size Q3 (with TA entity support) map with caves, skybox and occasional liquids. I tried to do test compilation yesterday and now Im really frantic from the result. Let me explain the problem:

I have two versions of the map - the newest one, and a backup (older just few days). Both are bugged, but in a different way.

1) The first version of the map has some illogical errors I just cant understand. The first odd thing were leaks - the debug window kept showing me leaks where actually were no leaks (possible phantom brushes?). I did the ugly thing and boxed the map a bit, just for a test before I could look into those leaks, but to my surprise, another errors showed up.

Code: Select all

Entity 6, Brush 0 Leaked

If I would erase this entity, the editor would simply report another entity next time, and if I would make a new entity, it would get leaked as well. Strangely, the map got compiled, and when I tried it in Q3, it was "working" (except few phantom brushes), but with a MAJOR error - each entity (including spawns, lights and patches) were moved about 128 units to the left (while they have good coordinates in GtkRadiant). I have no idea how to repair this, but maybe someone has?

Misplaced doors entity. Interestingly, all entities are misplaced like this.

2) The backup version, suprisingly, has neither brush leaks neither "entity leaks". However, some rooms which work in the first version, don't have textures displayed - especially the "cave" brushes. I have no idea why this problem doesnt occur in the "first version".

The brushes inside the cave system show up with no texture.

Please, can somebody help me with these oddities? Im frantic.. errors like that never occured for me. I should also note that both those compilations were made with -BSP meta, -vis fast, -light fast, and my PC specs are rather low...

Thanks for any help you can give!

[pjw]

For the leak(s), are you aware that you can go File-->Pointfile after a leak is found, and radiant will give you a line leading from the leaking entity out of the map, so you can see where the hole is?

If you were to link to your .map file, I'm guessing that someone here would probably give it a look and be able to tell you what the problem is...

And yeah, fix your leaks when they show up. Saying "I'll fix that later." and boxing the map is really begging the mapping gods to rape you...

[RotaryFist.cz]

Hi and thanks for the answer!
(also: Beneath a distant sun )

I use pointfile everytime I get leak errors, however I dont understand it this time - the line goes right through the brushes as if they wouldn't be there - they should be all structural thought.

Here is a link for the map files, rotary08.map is the one suffering with leaks, while rotary08b.map is the backup (without leaks but with lost textures at some places).

http://www.yousendit.com/download/dVlva ... VWxMWEE9PQ

Any help provided would be greatly appreciated, Im absolutely out of ideas...

[monaster]

I'm not sure if it is a smart thing to do, but since I unfortunately don't have time right now to check your map, I can only guess what might be the problem. Let's just hope that my guess ain't too stupid so it would have been even better to first look at your map and answer a few days later instead of writing crap here; we'll see.
Probably these cave textures you're using are having some sort of shader that makes them detail or something like that: when these shaders are taken into account by the engine (your first map) and there is a brush textured with the shaded cave texture AND in case the void is lying directly behind this brush, then this would answer the leaking error message.
To your 2nd version: if for whatever reason the shader file which caused the leaking error before hasn't been taken into account for your "backup map", then there's no leak problem anyway, because the problematic brushes are now all structural. And... dammit these speculations are going too far right now, I don't know how I wanted to explain the missing textures but I think that it could probably had something to do with the missing shader file, too.

Main message: check if your shader file hasn't been changed in any way between the creation of your first and second map version. If you don't have an additional shader file, just tell me and I quickly delete the stuff I've just written because it would be absolutely useless in this situation.

[RotaryFist.cz]

Hi!
The shader file is same for both maps and so far includes only skybox, a bouncepad texture and a glowing texture for some details; the cave texture used is the vanilla pjrock7d (organics). If I remember correctly, the cave brushes didnt change in any way between the new version and backup, at least not in the area where the bugs occur (eg theres a whole outside "cavey" area which compiles fine).

[pjw]

Okay, I just took a quick look at the rotary08.map. You have two major problems.

1) First, you had an origin key on your worldspawn. This is probably what was causing everything to appear shifted in-game, and what was causing most of your "entity leaked" errors. Entities can't have their origin in solid/structural, and when they do, you get that error. Even though most of your entities were fine in-editor, they were getting shifted by the errant origin key. To remove it, just select any normal brush, hit "N", and select the origin key and hit the delete key/value pair button. You'll still have at least one entity leak from some model lights with their origin inside a structural brush. They will either need to be shifted, or the brush turned "detail". Which brings us to...

2) Please, please learn to use detail brushes. I can't seem to find a good tutorial right now (help, anyone?), but the basic idea is that major brushwork that would actually serve to block visibility into other areas should remain structural (opposite of detail), and all the little fussy bits and oddly-shaped rocks, etc. get turned into detail brushes (via Ctrl-M). The benefit is mainly faster compiling times, but this also allows you to easily filter detail brushes and create a nice, clean, simple structural hull for your map. This will make it a lot easier to see what's going on with portals as well. Note that detail brushes don't seal, so that structural hull will still need to be sealed.

Edit: Also, yeah, unbox your map at some point...

[RotaryFist.cz]

Hi again,
you are right, the misplaced entitites were caused by the worldspawn... I think I somehow messed up with it when going from Gtk 1.3 to 1.4

Also, going to look on the details (and boxing) right now Do you think those non-displayed textures in caves might be caused by the fact these brushes werent detail?

Thanks a lot for help!

[obsidian]

Do you think those non-displayed textures in caves might be caused by the fact these brushes werent detail?

Probably not. Detail brushes has nothing to do with whether objects are actually visible to the player or what their textures will look like. They only affect the creation of portals which are used by the engine to determine whether the next room will be drawn or not. Doing these calculations are rather complicated and can be time consuming when you compile. Converting ANY brushes which doesn't affect visibility portal calculations can improve performance and significantly reduce compile time. A typical map without detail brushes may take hours to compile the -vis stage, a well detailed map can take as little as a few seconds.

Take a look at Q's sample map thread, excellent tutorial for some general building tips.
http://www.quake3world.com/ubb/Archives ... 20488.html

And something a little more advanced if you need to understand how -vis and hints work (also more good links attached)
http://www.quake3world.com/forum/viewtopic.php?t=3620

[RotaryFist.cz]

Do you think those non-displayed textures in caves might be caused by the fact these brushes werent detail?

Probably not. Detail brushes has nothing to do with whether objects are actually visible to the player or what their textures will look like. They only affect the creation of portals which are used by the engine to determine whether the next room will be drawn or not. Doing these calculations are rather complicated and can be time consuming when you compile. Converting ANY brushes which doesn't affect visibility portal calculations can improve performance and significantly reduce compile time. A typical map without detail brushes may take hours to compile the -vis stage, a well detailed map can take as little as a few seconds.

Take a look at Q's sample map thread, excellent tutorial for some general building tips.
http://www.quake3world.com/ubb/Archives ... 20488.html

And something a little more advanced if you need to understand how -vis and hints work (also more good links attached)
http://www.quake3world.com/forum/viewtopic.php?t=3620

Thanks for the tips

[RotaryFist.cz]

Hello again,

Im finishing this map but I encountered one more problem which I cant find an answer to Its just a minor but annoying bug regarding diagonals on walls and some edges of brushes. First I noticed it on a "cave" brush, where i were moving vertices, and it looks something like this:


Note it is not two brushes with a leak in middle of them, just one brush with an oddly displayed diagonal

However, I understand that moving vertices frequently leads to odd bugs and errors, so I just deleted the buggy brushes and tried for a new geometry, which usually worked. Except this case...



On left you can see a glowing patch with few radiant-generated 9-gonal brushes around it. On right is the very same - copied - object, but with those graphic bugs on few edges (I had to scale it a bit in the pic, but its quite visible in the game).

I searched the interweb and tried few things in the radiant, but didnt find out anything useful... any ideas?

Thanks for any possible help!

[RotaryFist.cz]

no idea anyone?

[obsidian]

Probably problems with T-junctions or vertexes being off grid.

[pjw]

I understand that moving vertices frequently leads to odd bugs and errors

Yeah, safest practice is to just NOT move verts manually. Ever. Use a combination of edge-dragging (E) and the clipper tool instead, and you can do anything that vert-dragging will do, with a lot less brush breakage.

Snap the offending brushes back on to the grid (Ctrl-G), and the problem may go away, or you may have to rebuild the problem brushes from scratch (without vert-dragging!).

radiant-generated 9-gonal brushes

I didn't try it, but I'm guessing radiant probably makes those off the grid as well, and they need to be snapped-to. Also, why 9-sided brushes? Use 8-sided brushes. No one will tell the difference, and you can make those yourself by just chopping the corners off a cube and resizing/stretching a bit if necessary.