Invisible brush of death: its doing my head in.

[Lux]

It would also be neat if DR drew a bold red connecting line (or lines; top and bottom) between any two visportals on the same plane or even within 1 unit of each other. Might negate the "visportals on the same plane" issue because it would be obvious to the mapper that one of them needs moved.

[chedap]

if DR drew a bold red connecting line

A long corridor (e.g. in a hotel) with a row of doors into different rooms would not cause the discussed behavior, so red lines would just clutter DR even though most of the time nothing would be wrong.

[Bikerdude]

@SteveL, you might want to take the Anti-portal discussion to a seperate thread, so your fixes on the VP issue listed in the OP dont get intertwined.

[SteveL]

@SteveL, you might want to take the Anti-portal discussion to a seperate thread, so your fixes on the VP issue listed in the OP.

Good point. Done it right now before the discussions get intertwined.

[SteveL]

It would also be neat if DR drew a bold red connecting line (or lines; top and bottom) between any two visportals on the same plane or even within 1 unit of each other. Might negate the "visportals on the same plane" issue because it would be obvious to the mapper that one of them needs moved.

A long corridor (e.g. in a hotel) with a row of doors into different rooms would not cause the discussed behavior, so red lines would just clutter DR even though most of the time nothing would be wrong.

I agree, if we can't fix this in the game code the next best thing will be to look for a way to flag it in DR or during dmapping. Probably dmapping, given that DR won't easily be able to tell where the visleafs end as in the corridoor example. But I'm really hoping the code fix I outlined above will check out ok. If it works, it could do more good than just fix the freeze problems. They are the extreme examples. But as shown in my test map, and chedap's example on the prev page, there's a lot of needless rendering can happen as a result of the player getting into line with a single VP. In a heavily detailed spot, that would express itself as a briefer hiccup during play.

[SteveL]

I've committed a fix, plus compiled game binaries to svn so you can test NHAT without making changes to the map if you want, Biker. Although that would mean waiting for 2.03 to re-release it.

 

It's as outlined above, except instead of using the visportal radius and distance to work out whether the player is really standing in the VP, it tests whether the player* is within 1 unit of the VP's bounds. That should handle long or wide VPs better.

 

* technically, the view origin

 

One thing I can't test for is whether I've reintroduced whatever problem led to bugfix #1 in the first place. There's no record, and if I disable the bugfix completely, I don't see any glitches. The main place to look out for in testing will be odd-shaped VPs made of out several VPs touching in a plane. That's the only place I can think of where the player might be able to look through a portal from within 1 unit of its plane, without having bugfix #1 doing its thing.