
Yeah, I just humiliated my DOOR... awesome!
Yeah, I just humiliated my DOOR... awesome!
Erm... why the hell can you gauntlet a DOOR? Thing is, I created a map or two, put some func_door on a few brushes, gave them an angle of 270 and so on, compiled the map, started that thing, triggered the door by standing in front of it and then started "gauntling" the rest of the door still looking out of the wall.
Can't really kill my door though, so no real humi but whatever! My player char TRIED to! So what the dilliyo!?!

If you are caught on a golf course during a storm and are afraid of lightning, hold up a 1-iron. Not even God can hit a 1-iron.
-Lee Trevino, golfer who actually has been struck by lightning.
-Lee Trevino, golfer who actually has been struck by lightning.
Re: Yeah, I just humiliated my DOOR... awesome!
Nothing amazing, you can trigger most doors by shooting them, so your player is just trying to shoot it open (even though it's already open).
Re: Yeah, I just humiliated my DOOR... awesome!
A terrific role model, monaster, has done it again.
Re: Yeah, I just humiliated my DOOR... awesome!
Thanks
And now for something more serious: how come that every time I save and compile my map under a new name (test1
test2 for example) all the effort put into removing z-fighting between doors and walls goes to hell? I don't mean "How does GTK radiant do this (that's clear to me)" I need to know "WHY does the editor do this" and "what can I do to avoid that in the future?" (since I don't want to do removing the z-fighting as the last thing on my project).
If it helps: Compiling is done with "-vis -fast" (tried it with "-vis" once, resulted in the same problem), GTK radiant version is 1.2.1 and it seems that the 2nd z-fighting issue occurs on only one side of the doors although I have reduced all the door brushes on BOTH sides for a length of 4 regarding the grid (so the doors would nicely slide into the nearby wall brushes as soon as the doors are opened and therefore avoid z-fighting); I hope you know what I want to say.

And now for something more serious: how come that every time I save and compile my map under a new name (test1

If it helps: Compiling is done with "-vis -fast" (tried it with "-vis" once, resulted in the same problem), GTK radiant version is 1.2.1 and it seems that the 2nd z-fighting issue occurs on only one side of the doors although I have reduced all the door brushes on BOTH sides for a length of 4 regarding the grid (so the doors would nicely slide into the nearby wall brushes as soon as the doors are opened and therefore avoid z-fighting); I hope you know what I want to say.
If you are caught on a golf course during a storm and are afraid of lightning, hold up a 1-iron. Not even God can hit a 1-iron.
-Lee Trevino, golfer who actually has been struck by lightning.
-Lee Trevino, golfer who actually has been struck by lightning.
Re: Yeah, I just humiliated my DOOR... awesome!
Z-fighting occurs in 2 cases:
- Co-planar textured faces. You should eliminate these at all costs, there is no reason why you should have 2 co-planar textured faces overlapping.
- Overdraw issues, when you have 2 textured faces in relatively close proximity and viewed from a great distance (due to the long distance, the close proximity values are being rounded off to be the same). This particularily becomes problematic when running the game at 16-bit colour mode. You can reduce most of these issues by reducing overdraw (textured faces behind other texture faces), but there may be a few cases where you'll notice a few issues while running the game in 16-bit mode that you may need to live with. Try to reduce the line of sight in the layout of the map to prevent the player from viewing all the surface from a large distance. Probably a good idea from a gameplay perspective anyway.
Re: Yeah, I just humiliated my DOOR... awesome!
I'll consider that, promised!
By the way how can I hold the editor (still GTK Radiant) back from deleting brushes with a size of 0.25 (either x,y OR z-coordinates)? I use these brushes not only for posters but more important for a few rooms to get an alternative wall texture without having the need to clip something. Unfortunately all these brushes are gone after compiling with -fast-vis and saving under a new name (it seems this is somehow the same problem with my doors mentioned above; maybe the editor tries to "correct" brushes with a size of xx.25 units? If so what can be done to avoid that?)

By the way how can I hold the editor (still GTK Radiant) back from deleting brushes with a size of 0.25 (either x,y OR z-coordinates)? I use these brushes not only for posters but more important for a few rooms to get an alternative wall texture without having the need to clip something. Unfortunately all these brushes are gone after compiling with -fast-vis and saving under a new name (it seems this is somehow the same problem with my doors mentioned above; maybe the editor tries to "correct" brushes with a size of xx.25 units? If so what can be done to avoid that?)
If you are caught on a golf course during a storm and are afraid of lightning, hold up a 1-iron. Not even God can hit a 1-iron.
-Lee Trevino, golfer who actually has been struck by lightning.
-Lee Trevino, golfer who actually has been struck by lightning.
Re: Yeah, I just humiliated my DOOR... awesome!
Building on a .25 grid makes Baby Jesus cry. Don't do that. It's generally good practice to use as large a grid as possible at all times, and keep all brush verts on that grid (or at least a grid, almost never less than 1, and usually way larger. Radiant is not a modelling program, and when you get into that sort of granularity, you're asking for trouble.
If you want an alternative wall texture, use the clipper and make another brush/face. If you want posters, make them out of a simple flat patch mesh, and float it just off the surface (and, like obsidian said, watch the view distance, and if they z-fight at a distance, then pop them out a bit more).
If you want an alternative wall texture, use the clipper and make another brush/face. If you want posters, make them out of a simple flat patch mesh, and float it just off the surface (and, like obsidian said, watch the view distance, and if they z-fight at a distance, then pop them out a bit more).
Re: Yeah, I just humiliated my DOOR... awesome!
Or use the _decal entity, that projects the patch on top of the surface it's 'pointed' towards. Though IIRC this requires the user to play the game with 32bit and not 16, but I don't think that's too much of a problem these days anyway.
Re: Yeah, I just humiliated my DOOR... awesome!
Now you're getting too complicated for him. He's a beginner and _decal entities have many, many requirements. Besides, decals aren't used simply because you want another wall texture.
Re: Yeah, I just humiliated my DOOR... awesome!
It was in reply to pjw's poster comment. Calm down.