[SOLVED] Ignoring Objects on a Layer

This forum is currently in read-only mode.
From the Asset Store
Welcome! I-Spy (Hidden objects) is an educational puzzle that is more than just seek-and-find activities.
  • Is it possible to instruct an object to ignore all objects on a specific layer? Specifically, I want a line-of-sight behavior to ignore all solids on a layer different than its own.

  • Most objects have a condition "Is on layer"

    If an object is picked you can use an inverted "Is on layer" to exclude the ones from the layer you want to be ignored.

    EDIT: Didn't read correctly. No need for inverting. Just test for the same layer with the normal "Is on layer"

  • I'm not sure how to apply that to the problem I have. I have two objects with line-of-sight behavior (LOS1 and LOS2), and two objects with the solid attribute (S1 and S2). I want LOS1 to treat both S1 and S2 as obstacles, but I want LOS2 to treat only S2 as an obstacle.

    I want to avoid using custom obstacles, leaving both line-of-sight behaviors on 'solid'. I want to put S1 and S2 on different layers and tell LOS2 to ignore S1 (perhaps to ignore the entire layer it's on).

    The way I currently have it set up, S1 is not directly targeted at all. LOS1 and LOS2 are both targeting an object behind S1, so I'm not sure how to get LOS2 to ignore S1 or the layer it's on.

  • Pretty much how tulamide said.

    When you test LOS1, you put no other condition. So LOS1 should react to any object (whatever layer it is on).

    When you test LOS2, you add another condition, being "Is on layer" (See Tulamide's post). This way, LOS2 will only react to objects on its same layer.

    LOS2 needs to be on a different layer than S1, and S2 needs to be on the same layer.

    If you're still stuck, consider posting a .cap with the setup you described that will help give you back the proper code.

  • If your testing for "solid", then telling it not to test for solid on a layer wont do. Its either all in, or all out when comparing an attribute.

    However you can test if an object is on a layer, and then set the collision mode for those objects to none.

  • mediafire.com

    I've got LOS2 and S2 on a different layer, but I can't seem to get LOS2 to acknowledge the target and ignore S1.

  • Ah, now I see what you are aiming for. There is a simpler way to achieve this.

    In the LOS behavior, set Obstacles to "Custom"

    In the event sheet, whereever needed, use the behaviors actions "Clear obstacles" and "Add obstacle" to build your own list of objects to be treated as obstacles.

    Download: http://www.mediafire.com/file/f1rq4dgb9g64p7g/LOScustom.cap

  • That's the first thing I tried. Unfortunately, custom LOS settings kill the framerate after the application runs for a minute or two. I have no idea why this occurs, but I know my machine isn't the only one that experiences this issue. Here's the original .cap running with custom LOS:


    It'll run at a healthy 70+ fps for about half a minute, then start dropping into the 30s, and finally plateau at below 10 fps. This may not be an issue on fast machines, but this is meant to be a simple, 16-bit-style game. If my machine, which can just barely run Orange Box, can't handle it, a lot of my target audience won't be able to either.

    That's why I need to figure out how to bypass the need for custom LOS. I was hoping there's a way to ignore an entire layer, or something to that effect.

  • It's not the LOS behavior but an error you made in the cap. You will get a more detailed answer and the corrected cap soon

  • Tested your cap out with Tulimide in chat, and we found a solution, as well as a bug.

    It seems you were constantly adding the boundaries to the los obstacles, and thats most probably what was causing the fps drop.

    So if you look at event 28 you'll see the always event, just change that to a trigger once while true, and drag your sub-event on its own. It doesn't need the always.

    Now that will fix the fps, but Tulimide found a real bug with los picking multiple instances, and while it doesn't seem to harm the preview it drives the debugger crazy, and if you try to click on one of the "extra" instance's reference it will crash the preview. So I would say its probably not a good idea at this time to add an object that has multiple instances to the los behaviors "add obstacle". Instead you can place the object you know will have multiple instances into a family and add that family to your "add obstacle" event.

    Like so:

    trigger once while true-> los add obstacle family.black

    Fixed cap in link.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • *facepalm*

    I can't believe I overlooked something like that. I'm glad it was an oversight on my part rather than an issue with Construct.

    Thanks a lot for your help, both of you!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)