1. 14 Nov, 2019 2 commits
  2. 08 Oct, 2019 6 commits
  3. 20 Sep, 2019 2 commits
  4. 17 Sep, 2019 2 commits
  5. 07 Sep, 2019 1 commit
  6. 29 Aug, 2019 2 commits
  7. 24 Aug, 2019 6 commits
  8. 23 Aug, 2019 1 commit
  9. 22 Aug, 2019 2 commits
  10. 20 Aug, 2019 2 commits
  11. 18 Aug, 2019 1 commit
  12. 17 Aug, 2019 6 commits
  13. 16 Aug, 2019 4 commits
  14. 15 Aug, 2019 3 commits
    • Merge branch 'polyobj-fixes-backport' into 'next' · 392cb89f
      Monster Iestyn authored
      PolyObject fixes backport
      
      See merge request !505
    • After looking at the FOF part of P_LineOpening for a while I now realise many of… · bbefc3b7
      Monster Iestyn authored
      After looking at the FOF part of P_LineOpening for a while I now realise many of these variables aren't even necessary, so I removed them all.
      
      (Naturally I did the same to the camera equivalent)
      
      # Conflicts:
      #	src/p_maputl.c
    • Edit a lot of the rest of the polyobject-related code in P_LineOpening to make… · cda81cc1
      Monster Iestyn authored
      Edit a lot of the rest of the polyobject-related code in P_LineOpening to make more sense and be more optimised.
      
      * If you collide with a line belonging to a polyobject, you should NEVER have to care about any FOFs that might be present in either sector of the linedef. This could lead to colliding with ghostly FOFs that aren't actually there or something dumb, if someone decided to give either of the polyobject's control sectors FOFs for some reason. We don't want that, obviously.
      * Polyobjects without POF_CLIPPLANE apparently are supposed to have a top and bottom "physical" height of value INT32_MAX and _MIN respectively, according to P_CheckPosition ...let's be consistent with this.
      * Finally, there is no more need for that back = front nonsense hack anymore with my changes made.
      
      # Conflicts:
      #	src/p_maputl.c