Skip to content
Snippets Groups Projects
  1. Nov 14, 2019
  2. Oct 08, 2019
  3. Sep 20, 2019
  4. Sep 17, 2019
  5. Sep 07, 2019
  6. Aug 29, 2019
  7. Aug 24, 2019
  8. Aug 23, 2019
  9. Aug 22, 2019
  10. Aug 20, 2019
  11. Aug 18, 2019
  12. Aug 17, 2019
  13. Aug 16, 2019
  14. Aug 15, 2019
    • Monster Iestyn's avatar
      Merge branch 'polyobj-fixes-backport' into 'next' · 392cb89f
      Monster Iestyn authored
      PolyObject fixes backport
      
      See merge request STJr/SRB2!505
      392cb89f
    • Monster Iestyn's avatar
      After looking at the FOF part of P_LineOpening for a while I now realise many... · 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
      bbefc3b7
    • Monster Iestyn's avatar
      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
      cda81cc1
Loading