Glitched Ground

[nubcake]

Hey guys, for my map for the amu comp, i found a serious glitch. For some reason the ground on this brush is glitched (like caulk), it isnt clipping anything, and it only has the hall of mirrors effect when you look at it from an angle (ie doesnt glitch when you run across it and face the horizon, but when you look at it) Any ideas?

In game:



In Radiant:

[Kaleo]

Are there any overlapping brushes? I've had this sort of problem and found that an overlapping brush was the culprit.

[Plague Bringer]

Yeah. Generally the cause is duplicating a brush (say a wall, or a piece of ground) and duplicating it one too many times.

[nubcake]

no overlapping brushes, and the ground wasnt copied it was created like a normal brush

[Kaleo]

Try recompiling the map with a different build setup. You're screenshot looked like it was a fast compile.

[nubcake]

No it was full compile, but ill try a different compile

[TRaK]

I had a similar problem in Eden. I worked around it by scrapping the brushwork and rebuilding it differently. I dug up the thread if it's any use: http://tremulous.net/forum/index.php?topic=5569.0

It might be a vis glitch, you could try compiling the map with no vis, or fast vis, and see if that changes anything. Otherwise, rebuilding the area is probably your best bet.

[nubcake]

I had a similar problem in Eden. I worked around it by scrapping the brushwork and rebuilding it differently. I dug up the thread if it's any use: http://tremulous.net/forum/index.php?topic=5569.0

It might be a vis glitch, you could try compiling the map with no vis, or fast vis, and see if that changes anything. Otherwise, rebuilding the area is probably your best bet.

Thanks for your help. I think I will have to try that

[Odin]

Every once in a while q3map2 will choke on a surface or two and bork the coordinates completely. It tends to do this after the the vis stage(somehow), which means it won't leak, and you never know it happened until you test the map after a complete compile. The best way to fix the problem(which will recur every time you compile) is to just delete the brush and remake it in GtkRadiant.

The fact that you have to remake the brush probably suggests that it is a bug in GtkRadiant, not q3map2 or Tremulous. GtkRadiant might be outputting the wrong data into the .map for the brush, but it still parses OK for GtkRadiant(since it doesn't need to know much besides the coordinates for the brush, and the texture on the sides). Fixing the .map by hand is probably impossible unless you know how to read a .map file.

[Kaleo]

Every once in a while q3map2 will choke on a surface or two and bork the coordinates completely. It tends to do this after the the vis stage(somehow), which means it won't leak, and you never know it happened until you test the map after a complete compile. The best way to fix the problem(which will recur every time you compile) is to just delete the brush and remake it in GtkRadiant.

The fact that you have to remake the brush probably suggests that it is a bug in GtkRadiant, not q3map2 or Tremulous. GtkRadiant might be outputting the wrong data into the .map for the brush, but it still parses OK for GtkRadiant(since it doesn't need to know much besides the coordinates for the brush, and the texture on the sides). Fixing the .map by hand is probably impossible unless you know how to read a .map file.

It seems to do this with lighting as well. I got one of those fullbright borks the other day.

[nubcake]

Well i found out my problem. I had to change the ground texture which is highly annoying Such a shame to have to put my vision of hand for some stupid glitch. Topic solved

[Odin]

Yea, us mappers are often having to put off what we want our stuff to look like but are at the mercy of the limitations of the engine.