moving self-referencing sectors?

So I noticed that self-referencing sectors aren't very good at moving, for example if I try to "lift lower wait raise" or "lower to 8 above highest floor" them, they don't seem to be moving at all. Are there any actions that can move them or maybe some hacky tricks to make all actions work on them normally?

They don't have any adjacent sectors because they're self-referencing. Create an out of map dummy sector and merge it with your self-ref sector, and then attach another dummy sector to that. Now it has an adjacent sector to move to.

Memfis said:

So I noticed that self-referencing sectors aren't very good at moving, for example if I try to "lift lower wait raise" or "lower to 8 above highest floor" them, they don't seem to be moving at all.

Well, this is pretty consistent with the sectors being self-referencing. "Lower to 8 above highest floor".....what floor? Of which neighboring sector? Its own floor maybe? See why this cannot work?

esselfortium said:

They don't have any adjacent sectors because they're self-referencing. Create an out of map dummy sector and merge it with your self-ref sector, and then attach another dummy sector to that. Now it has an adjacent sector to move to.

Won't that affect any or all of the self-referencing sector's properties, like e.g. being "transparent"?

Oh, I thought it must be something like that but for some reason didn't try and created this thread instead. Thanks.

Maes said:

esselfortium said:

They don't have any adjacent sectors because they're self-referencing. Create an out of map dummy sector and merge it with your self-ref sector, and then attach another dummy sector to that. Now it has an adjacent sector to move to.

Won't that affect any or all of the self-referencing sector's properties, like e.g. being "transparent"?

Nope. You can have a sector that's self-referencing in some places but not in others -- this is why a broken sector only leaks out from the linedef that has the broken references, not from all its other lines.

You can also use the same method I described to make self-referencing sectors affected by any of the strobe/flicker/glow sector lighting specials, using the adjacent dummy sector to give it a light level to flicker to.

One more thing to note is that self-referencing sectors are considered to be adjacent to themselves for purposes of finding an adjacent sector to match heights with. So, for example, the "floor down to highest adjacent floor" actions cannot be used to lower a self-referencing sector, since the sector will consider itself to be the highest adjacent floor, resulting in no movement.

Isn't what you're calling a self-referencing sector just a collection of self-referencing linedefs, and for this discussion could be treated as such with better clarity.
I know of no self-referencing effects upon a sector, only upon linedefs with the same sector on both sides.

Does it even matter if your collection of self-referencing linedefs was closed into a pseudo-sector shape or was open.

Technically, it's a subsector (or group of subsectors) bounded by self-referencing linedefs. The subsector can be open, just like any other subsector, but nodebuilders will not always construct subsectors correctly from an open sector, which can cause the effect to cover a smaller or larger area than intended.

For moving sectors, the region of the sector outside the map is its own subsector (which is not self-referencing), and has no effect on how the self-referencing subsector works.

The self-referencing linedefs are what makes the effect itself work, though: since self-referencing lines are not rendered on the (correct) assumption that if both sides of a line are in the same sector, the upper and lower textures can never be seen, and since flats are drawn from linedefs, if all the linedefs making up a subsector are self-referencing, the subsector's flats will never be rendered. (The assumption that a linedef's sector references actually indicate what sector(s) are one each side of the line is what is broken. A self-referencing line by itself with correct references does not produce any unusual effects.)

I know of the code test that would prevent the upper and lower textures from being seen. If both sides of a linedef are the same sector, they will always give same height.

The bit about flats being drawn from linedefs, and if all the sector linedefs are self-ref the sector flats will not be seen. That does not explain it, I do not recognize this in any code I know of.

Flat drawing starts from a linedef. It is clipped by the adjacent linedef drawing. It can be deliberately combined with an adjacent flat drawing, crossing linedef with the same flat, light, and height on both sides.
Sometimes the flat combining can fail, resulting in flat bleeding.
This must what the self-ref effect relies upon.
What I cannot see is how making it a closed sector affects it.

If a nodebuilder tolerates a single self-ref linedef, then why would the same code indifference not tolerate a series of them arranged in a circle, closed or not.

The closed circle of self-ref linedef would seem to be more problematic to the nodebuilder. It appears to be a sector, but is it recognized or rejected? Which search is it getting left out of that causes the noted effects ??
The nodebuilder use vertex position to build the node map, but what effect does the sector references have upon the node mapping. Does the effect differ with different nodebuilders?

Code diving would not likely answer these questions, so I am not going to try that.

wesleyjohnson said:

If a nodebuilder tolerates a single self-ref linedef, then why would the same code indifference not tolerate a series of them arranged in a circle, closed or not.

There's absolutely nothing problematic about self-referencing linedefs, as long as both sides of the line really are in the same sector (eg, you merge two connected sectors without deleting the linedef between them). It's the sector references not matching that causes problems, not the shape of the sector. Also, while unconnected lines and unclosed shapes can cause problems for nodebuilders, this is the case whether there are self-referencing linedefs involved or not.

wesleyjohnson said:

The closed circle of self-ref linedef would seem to be more problematic to the nodebuilder. It appears to be a sector, but is it recognized or rejected? Which search is it getting left out of that causes the noted effects ??

The nodebuilder use vertex position to build the node map, but what effect does the sector references have upon the node mapping. Does the effect differ with different nodebuilders?

The purpose of the nodebuilder is to divide sectors (which may be of any shape) into contiguous, convex regions (called subsectors), and sort them into a BSP tree. The subsectors are what are actually rendered in the game, and each subsector references a sector to determine properties such as flats, heights, etc. But how does the nodebuilder know which sector to associate with each subsector? From the linedefs (sidedefs, actually). But if the linedefs have inconsistent sector references, the nodebuilder may associate the wrong sector with certain subsectors, causing various problems (which, again, happens whether self-referencing lines are involved or not, but creating a self-referencing sector is by far the most common reason for inconsistent sector references).

Most (all?) of the newer nodebuilders have special case code for self-referencing lines which (usually) prevents the latter issue (but not the former - unclosed sectors are still problematic), but the older ones didn't, so creating self-referencing sectors with old nodebuilders was a bit hit-and-miss.

Foxpup said:
so creating self-referencing sectors with old nodebuilders was a bit hit-and-miss.

This is the reason why the Doomworld Editing Tricks tutorials sometimes mentions different approaches for different nodesbuilders.