Re: Sort of a not really a potential bug report. -ish.
- From: ras2 <shrike@xxxxxxxxxx>
- To: yadex@xxxxxxxxxxxxx
- Date: Thu, 20 Nov 2003 02:10:32 +0100
On 2003-11-19 at 18:23:11 +0100, Andre Majorel <amajorel@xxxxxxxxx> wrote:
> On 2003-11-19 15:54 +0100, ras2 wrote:
> > On 2003-11-19 at 13:24:39 +0100, Andre Majorel <amajorel@xxxxxxxxx> wrote:
> > > On 2003-11-19 02:34 +0100, ras2 wrote:
> > >
> > > > If you look at linedef #1051 in linedef mode, you'll see that it's
> > > > drawn as two-sided despite only having one sidedef and if you look
> > > > at it in sector mode, it's drawn as if it doesn't belong to sector
> > > > #1 (and in blue too where the rest of the sector's linedefs are in
> > > > green).
> > >
> > > That's because it's superimposed with linedef 1184, which is
> > > double-sided.
> >
> > hmm. 1051 and 1184 run parallel to each other and are separated by 24
> > units, so I don't see how they can be superimposed?
>
> Sorry, make that 1185.
okay. It's beginning to make more sense. I didn't know, or remember, that
linedefs could share vertices that way
> > > a) Change the order in which objects are drawn (or highlighted)
> > > so that the highlight matches the display. One bad side-effect
> > > of doing this is that it would remove the only hint that you
> > > have superimposed linedefs.
> >
> > That wouldn't be nice.
>
> Attached is a patch against 1.6.0 that does that for vertices,
> linedefs and things. Apply it and look at your level. :-)
And suddenly all became clear...
hm. This info is quite a bit more useful than the default, but like you
said, you wouldn't know that you had a need for it because you couldn't
see that there was a problem.
Is there a use for such doubled linedefs? bsp 5.1 doesn't seem to remove
them, but I don't know if that means anything.
> > If that's the case, might it be possible, and better, to use some symbol
> > on the map to show superimposed objects? Then one would know where they
> > are and could just shuffle linedefs in the usual manner to get at them.
>
> Yes, possibly. But I'm afraid it might be even more CPU
> -intensive than multiple info boxes. At a zeroth approximation,
> the latter is a plain O(n) scan, and the former involves at the
> minimum allocating and sorting (O(n log n)) a table of size n.
> Doesn't seem like a good idea to put that in draw_map().
okay.
> > > The code that handles joining sectors rarely does the right thing. I
> > > know I nearly always end up having the fix the linedef properties by
> > > hand.
> >
> > yeah. Is it possible that it has gotten worse? I'm seeing some rather
> > peculiar choices being made sometimes and I don't remember them being
> > quite as odd in the past.
>
> Not that I remember. As I recall, it's always been weird.
I may just be unlucky, but I'm seeing many more cases where a linedef far
from the area I'm working on suddenly disappears (for example, there was
a linedef that ran parallel with linedef 1058, with about 4 units between
them, and that disappeared when I rearranged the linedefs near 1051).
It's a bit risky because it often happens on linedefs that are out of
sight, so it can take quite a while before you notice it.
> > It was in 2000 and sort of the opposite of this; I had a two-sided linedef
> > that was shown as impassable (white) when it wasn't and you just went on
> > about how it wasn't possible because of some stuff in the code and whatnot
> > and yet I had that great and terrible white linedef right there, staring
> > me right into my bloodshot eyes and defying me to deny its existence.
> > It was quite traumatic, I tell you.
>
> Looking in my archives, I think the reason we never solved that
> issue is that you tried dragging the vertices, but not *changing*
> them. Just dragging won't do a thing if the linedefs share the
> same vertices.
I suspect it wasn't clear to me what you meant then.
-R.
--
[SFX: Interröbang Cartel - The George Hammond Conspiracy - Needs More Wanger]
Other related posts:
