Fixed Touching the side of a PolyObject with Effect 5 on its first line crashes SRB2

Lately, when I touch the side of a PolyObject, the screen sometimes goes black and I get the standard Windows crash dialog. I originally thought it was a problem with my levels, but after seeing this a lot I'm starting to think it's a bug in the game.

EDIT: In case it helps, I'm pretty sure that every time the PolyObjects made the game crash in this way, it was when the player was in a "falling" state, and moving against the side of the PolyObject.

Fawfulfan said:

I'm starting to think it's a bug in the game.

Click to expand...

Does it happen in ACZ1?

Haven't checked it there...I think that it is more apparent in some PolyObjects than others.

Example maps, please?

A little test map with a polyobject that exhibits this effect would help us out SO much.

EDIT: I think I get it...the PolyObjects which cause the crashes have the Effect 5 flag checked on their First Lines. In other words, the PolyObjects set to stack their side textures. Maybe the game gets upset when it tries to work out how the collision detection of stacked-texture PolyObjects should be done.

The collision should be irrelevant even if the texture is stacked, it will be intangible outside the PO bounds.

SSNTails said:

The collision should be irrelevant even if the texture is stacked, it will be intangible outside the PO bounds.

Click to expand...

Well, maybe I'm wrong about the cause, but I'm pretty sure I'm right about the effect. Touching the side of a stacked-texture PolyObject can crash the game.

EDIT: Here's the proof: http://www.4shared.com/file/uU93M5Zu/s_polyobjectcrash.html

This sample level contains two PolyObjects--one with unstacked textures, the other with stacked textures. Try jumping into the side of the unstacked PolyObject, and then try jumping into the side of the stacked PolyObject.

For me it didnt crash but something wierd happened:

I could not get out after.

Yeah, that happened to me as well.

Also, this is related http://mb.srb2.org/showthread.php?t=33740, except in my case I could still touch the sides of the polyobject but not flying over it without crashing.

I have no idea why Fawfulfan's polyobjects behave differently from the ones I used (I don't have any example wad right now), I mean, I even built them the exact same way...

I could walk through it fine its only when your airborne it happens.

The thing is, you shouldn't even be able to go through it, since the polyobject's floor is at the same height as the floor surrounding it.

After being shown this topic via IRC just a moment ago, I've just realised why this bug could be happening, having peered into the section of SRB2's source code for Polys some time ago.

See, for those who don't know it already, Linedef Type 20 is also the linedef special to change the PolyObject's POF flags (which ideally should be on the Parameters linedef, rather than on the PolyObject's Boundaries itself for some odd reason).

However, even for those who do know it already, the SRB2 Wiki's page for lists only a few of the effects supposed to be settable, since only some of them will be of any use to anyone.

By default, Polyobjects have the flags POF_SOLID (or POF_CLIPLINES and POF_CLIPPLANES combined), POF_TESTHEIGHT, and POF_RENDERSIDES.

The following linedef flags change the Polyobject's flags:

• Not Climbable - adds POF_LDEXEC; Basically means it can trigger any instances of Linedef Type 316 (Which is actually obsolete - it turns out PolyObjects can use Sector specials!)
• Effect 1 - adds POF_ONESIDE; This basically just renders the front sides of the Polyobject. Should be obvious how useful this is.
• Effect 2 - removes POF_SOLID; Makes the Polyobject intangible, of course
• Effect 3 - adds POF_PUSHABLESTOP; Pushables can stop PolyObjects in their tracks, rather than being shoved away by them!
• Effect 4 - adds POF_RENDERPLANES; This would be really useful if it weren't for the fact it doesn't work at all yet =V
• Effect 5 - removes POF_CLIPPLANES; Now THIS...This means that the flats aren't solid - probably explaining some of the problems here in this topic.

As unneccessary as some of this explanation here may be, I hope this explains this bug and some other bugs around. =E