The new 2.5/1.5 update has caused a change in 2-sided poly behaviour - they no longer push you/knock you away when they run into you.
See demo wad, the blue one is 1-sided, the green one 2-sided. Running r2560/gz899 has only the blue one pushing me, the green one just stops until I get out of the way (even with compat_polyobj enabled). Running an older version (I used r2386/gz825) has both of them pushing me as expected.
Would it be possible to reinstate the old 2-sided poly behaviour (within compat_polyobj if neccessary).
[r2560]/[gz899] 2-sided poly behaviour
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
-
The Ultimate DooMer
- Posts: 2109
- Joined: Tue Jul 15, 2003 5:29 pm
- Location: Industrial Zone
[r2560]/[gz899] 2-sided poly behaviour
- Attachments
-
polytest.zip- (1.71 KiB) Downloaded 32 times
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49223
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [r2560]/[gz899] 2-sided poly behaviour
I don't think a compatibility option is needed here. This one's clearly a bug.
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49223
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [r2560]/[gz899] 2-sided poly behaviour
fixed. What happened is that both sides of the linedef did their job and cancelled each other out.
However, looking at that code in general I wonder what Raven's developers were smoking when writing it. The entire thrust calculation makes no sense at all and only takes the linedef's orientation into account but not the polyobject's movement.
At least now I know why this code behaves like utter crap. Because it *IS* utter crap!
However, looking at that code in general I wonder what Raven's developers were smoking when writing it. The entire thrust calculation makes no sense at all and only takes the linedef's orientation into account but not the polyobject's movement.
At least now I know why this code behaves like utter crap. Because it *IS* utter crap!