Navigation

    forum

    • Login
    • Search
    • Categories
    • Recent
    • Popular
    • Users
    • Groups
    1. Home
    2. dragoonreas
    3. Topics
    • Flag Profile
    • block_user
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Groups
    • Blog

    Topics created by dragoonreas

    • Missing NPC Terminal in E100S30 on Shard0
      Technical Issues and Bugs • • dragoonreas

      2
      2
      Posts
      4197
      Views

      The issue has been fixed! Thank you for reporting it to us
    • Construction site blocked by walkable object
      Technical Issues and Bugs • • dragoonreas

      3
      3
      Posts
      6343
      Views

      While that PR does look necessary for constancy sake between what the client returns to the player code and what intent is actually registered, it doesn't doesn't address this problem. The problem is coming from the sole reliance of C.OBSTACLE_OBJECT_TYPES to check for non-walkable objects in second part of the if statement (taken from here, although it also occurs here in a similar fashion): if(_.contains(C.OBSTACLE_OBJECT_TYPES, target.structureType) && (_.any(roomObjects, (i) => i.x == target.x && i.y == target.y && _.contains(C.OBSTACLE_OBJECT_TYPES, i.type)))) { return; } Earlier in Screeps development everything of a type listed in the C.OBSTACLE_OBJECT_TYPES constant was always non-walkable and thus an obstacle, but that's not true anymore. Now you need an additional check to see if a creep (one of the types listed in C.OBSTACLE_OBJECT_TYPES) is walkable or not, because a creep can be walkable when it's a hostile creep in a room you've activated safe mode in.