Mordeth Posted July 10, 2016 When going back to work on a older certain portal-heavy map, I noticed that some (but not all) simple doors (action 1, door sector tagged) have stopped working. Pressing use doesn't open the door anymore, but does elicit the 'oompf' noise. Bullet buffs appear as normal when shooting it. GZDoombuilder does not report errors on that level. Door resume to work normally when switching back to SVN build 283; in later builds (eg 418) they appear broken. I don't see this behaviour in my latest map, which by all accounts is bigger. Edit: the 'oompf' noise can also be triggered by a freestanding player pressing 'use' but not in all sections of the map and not for all specific directions. Edit2: And you can still trigger nonfunctional doors by turning on clipping and pressing 'use' while getting closer to the door to the point of almost standing inside the door sector. 0 Share this post Link to post
printz Posted July 10, 2016 Do you still have the 7z of "svn383"? I'd like to know its full name, especially the hexadecimal hash. 0 Share this post Link to post
Mordeth Posted July 10, 2016 Last working build was Eternity-r3.40.46-284-gb6e15a6.7z; next build was Eternity-r3.40.46-418-gd0bd47d.7z which has these door problems. 0 Share this post Link to post
printz Posted July 11, 2016 OK. They seem to be between start of February and start of March. If I can't guess the cause of the bug, I'll send you all my builds between those days so you can test each of them until it happens. 0 Share this post Link to post
Mordeth Posted July 11, 2016 I suspect something in the way the portals in that particular map are "glued together" is not quite right. Reordering the portal parts and rebuilding does not change anything. There's even one DR door with one side working while the opposite one doesn't. 0 Share this post Link to post
printz Posted July 11, 2016 Here are 35 Eternity builds. Can you test them and tell me which number breaks? You can do a binary search to reduce your time (start from middle, then continue with the middle of the interesting half). https://dl.dropboxusercontent.com/u/5103936/temp/eternity-builds.7z 0 Share this post Link to post
Mordeth Posted July 11, 2016 I've tested some of those builds, all without custom EDF / ACS. I've disabled the beta last soul emulation in things.edf, since some builds didn't know the keyword 'frameblock'. Straight from eternity-1.exe, one single DR door becomes unresponsive. All other DR doors (as tested) remain functional. Continued to test with eternity-2, -3, -4, -14, -21 and -25, with the same result as eternity-1. From eternity-26, all the DR doors stop responding similar to described in the original post. This also goes for S1 switches, but not for W1 actions which continue to work as normal. Behaviour under eternity-27 and -30 remains the same as eternity-26. 0 Share this post Link to post
printz Posted July 12, 2016 Hmm. This does not look easy, because eternity-26 is the moment portal functionality has been integrated. Does your map have doors just beyond line portals? Of course glaring bugs may be left in the portal aware P_UseLines, because they may only happen in maps with linked portals... Do you think you can send me a tiny slice of your map, just enough to have one such case? 0 Share this post Link to post
Blastfrog Posted July 12, 2016 printz said:Do you think you can send me a tiny slice of your map, just enough to have one such case?I don't wanna get between you two, but I think giving printz the whole map would more effectively narrow down the problem - it's not like he's going to leak it. A small slice may or may not be as effective. 0 Share this post Link to post
printz Posted July 12, 2016 Fixed. There was a bug in the portal-aware line-using tracer, where data was read from the wrong location, causing unpredictable behaviour. It wasn't specially triggered by linedef portals — it was simply that the map needed to have linked portals in it. 0 Share this post Link to post