Floating, bobbing FOF problem?

[123 Runite]

OCZ:

Upon level start, a floating, bobbing FOF is intended to spawn on top of a damaging translucent water FOF with Effect 5 (water ripples effect) checked, just like how floating, bobbing FOF's are usually placed when designers want floating, bobbing platforms over water. However, the floating, bobbing FOF somehow glitches and ends up floating above the water FOF once the entire level is loaded.

I have not encountered this in v.1.09, but when I ported OCZ to 2.0, the "bug?" has popped up. I might have done something wrong, I do not know, which is why I am asking here. I have asked much long ago in my OCZ topic, but nobody seemed to pay attention or knew a solution. The Wiki does not state any known problems Linedef 160 (FOF: floating, bobbing) possesses.

I have provided a couple of images of the problem for clarity: one right at level start (before zone titles show up and things starts moving) that has the floating, bobbing FOF in its intended position; and another at the instant the zone titles show up and all level effects occur. And, by the way, disregard anything that is displayed in the console.



If you do not know what I'm asking for here, then you need to consider reading this again. The question should've been obviously implied: what can I do to fix this problem? Or, if there is no solution to it right now, then can this be considered a v.2.0.4 bug that will be fixed (or has been already) in the next patch?

---------- Post added at 10:24 PM ---------- Previous post was at 09:58 PM ----------

I have forgotten to mention that a single control sector for the floating, bobbing FOF was made to span over three distinct sectors so that three of such FOFs would respawn, each having the same properties. It should then be understood that those three sectors also share the same damaging translucent water FOF control sector. These three sectors were merged into one sector of three "subsectors," as I call them, as they all are separate polygons merged to share a single property (or properties) in order to reduce lag (optimization technique).

You can see in the two images above two of the three sectors containing the FOFs.

As an experiment, just now I have decided to delete two of the three sectors. I have discovered that there was no problem that the floating, bobbing FOF exhibited during the test. I also decided to do another test with deleting only one of the three sectors so that there are only two sectors with the same properties. The topical problem was encountered; however, the floating, bobbing FOF 'glitched' but fewer FU's above the water FOF than before.

Now the question: why does this glitch occur when one floating, bobbing FOF control sector that spawns such FOF over a water FOF is applied to multiple sectors (or joined) with identical properties? Though, I do not recall if this was done cleanly in other published levels. So, if there are certain circumstances for this glitch to occur, then I would like to know how I can avoid it from ever happening again in the future. I already have one solution I've mentioned already: have one floating, bobbing FOF control sector apply for only one sector, not for two.

 

[Liliam]

This would be a lot easier to diagnose if you posted an example wad instead of a couple of screenshots. You don't have to post that level in particular, just make a wad with the same exact setup you have right now.

 

[123 Runite]

In three sections (Roman Numerals displayed on map as viewed in a map editor):

I. Floating, bobbing FOF (linedef action 160) over stationary damaging translucent water FOF, as laid out in OCZ

II. Floating, bobbing FOF over damaging translucent water FOF with rising and falling ceilings, as laid out in OCZ

III. Replicated glitch in a new area, though, floating, bobbing FOFs do not glitch as high above the water.

You can play around with the Player 1 start location so you can see what happens to the floating, bobbing FOFs upon level load in each of the three areas. All share similar symptoms. The floating, bobbing FOF glitches above the water.


http://STJrSilver.sepwich.com/123_Runite/160bug.wad

 

[Liliam]

Okay, it seems that the floating block checks the entire area contained within its own vertices in order to find out what is the highest floor, which is what it will rest upon (imagine a large floating FOF that's over two different sectors, when it falls, it will "land" on the one with the highest floor, so it doesn't burrow into the ground in any circumstance).

The problem arises when you have a concave sector. The floating block again checks the area contained within all of its vertices, even going as far as cross-checking across other sectors which it isn't even over. If the sector with the highest floor ends up being one which the floating block isn't tagged to, but is within the area described by connecting all of the tagged sector's vertices to each other, then that sector WILL prevent the FOF from sinking, even though logically it shouldn't.

Maybe an example wad will explain better: http://nande.planetaclix.pt/floating_fof_quirk.zip

I wouldn't call this a bug, because it was probably programmed to work exactly this way. That doesn't mean a more robust version which negates this problem cannot be made, but it does mean that it would sacrifice speed in cases where this one works just fine.

EDIT: doi, forgot to explain the original bug

In your level, 123 Runite, you have exactly this problem. If you connect all the vertices of the three "separate" blocks in your level, you'll notice that one of the lines will go over a high ledge that's off to the side. The floating block incorrectly assumes this is where it should rest, and doesn't sink past that point.

 

[123 Runite]

Thanks for coming to this conclusion; such information is in dire need of being published on the Wiki, should anyone else fall into the same problem. I have not even thought of the other sectors within the boundaries of the FOFs, when connected together, to be the cause of this.

By the way, your explanation was clear enough for me to understand, and the example wad was not necessary; but, thank you for going through the effort to explain this "quirk."