oosyrag's Recent Forum Activity

  • Use BBCode by setting the text to 

    [outline=white]Text[/outline]

  • Add trigger once condition?

  • C2 will also still work after July 1st... Same as it always has.

  • Upload your minimal/new project file, otherwise can't say without more information.

  • Well firstly in this situation where levels are involved, I would use a separate layout instead, or at least destroy the old level upon transitioning to the new. If I needed to preserve the level to revisit later, I would definitely use a separate layout.

    If in the case of a menu and clicking, I usually have the "layer is visible" condition in the menu events.

    I can't think of much for the layer off the top of my head, but I can definitely say there are a billion and one uses for invisible helper sprites, and I definitely want those interactable. I don't see why layer visibility should behave different than object visibility. The question is why make an entire layer invisible to begin with? I'd imagine maybe for inventory or menus and other interface elements, but again a single condition on the input event solves that. Usually doesn't involve solids.

    The main use case for having solids on layers that become visible and invisible would be maybe something like floors in a building. IIRC this is one of the big issues the collision filtering and tag feature was developed to address, besides stuff like half height objects that block movement but not visibility/bullets ect.

    You don't even need to manually enter a lot of collision tags for solids - just use a loop on start of layout to set the tag to the layer name the object is on. When the player changes layers, set their solid collision filter to the layer they are on, so they can only interact with things on that layer.

    Also, the solid behavior can be enabled or disabled. If you're already changing layer visibility, you can enable solids on the new layer and disable on the old just as easily. There are many ways to deal with this.

    One use case I just thought of for hiding a layer and still have solid interactions is if you wanted a certain set of information hidden from the player, say they got blinded, or hidden enemies. They still need to pathfind, bullets still need to hit walls, ect. even when they are not visible.

    Anyways sorry that was a bit long and rambly, so TLDR back to "So is there a way to make a layer 'not interactable'?". There are a few options, as usual, depending on what the situation requires.

    A. Use the "Layer is visible" condition

    B. Use collision filters. Doesn't necessarily mean a lot of work, and it was designed for stuff like this.

    C. Disable solids on the layer that isn't in use.

    D. Don't use a layer like this to begin with (ie. destroy and create objects as needed instead of just making them invisible), or move to a different layout instead.

  • Invisible means not visible. It does not mean not interactable.

  • I believe you should be able to, if you include a websocket server in your app. That is probably outside the scope of these forums though. I suspect you might have less trouble just including a local signalling server instead.

  • I imagine you would use a snapping system, when you got close enough, to manually position the object in and disable platforming. Or give yourself some wiggle room so the fit isn't so tight.

    I mean even in real life, if you had two shapes like that that were EXACTLY fitted, it would be hard to connect them. There's usually some wiggle room or flexibility, even if very little.

    It depends on what the goal is. Is it just an obstacle you'll pass by, or is it an object you want to "dock" or connect with?

  • I believe directly adjacent bounding boxes are considered colliding/overlapping. Even if they weren't, rounding errors would ensure that exact fit shapes like this would never actually fit together.

    I've seen some solutions use tile movement, others disable solids/collisions (or adjust the bounding box to be smaller as you mentioned) and implement a snapping system. The platform behavior by itself will likely be insufficient to handle perfect fits like this.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It doesn't work because nothing in a normal orbit has to do with a 45 degree angle between anything.

  • Apologies, the second condition should be len(sourceText) instead of just sourceText.

    This should work without that condition at all actually I think.

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 39 followers

Trophy Case

  • 12-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

22/44
How to earn trophies