oosyrag's Forum Posts

  • 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.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That isn't how orbits work...

    In a stable orbit, no constant forces besides gravity should be acting upon an object.

    The forward momentum should be preserved and the angle of motion set perpendicular to the angle of gravity.

    The magnitude of forward momentum depends on the distance from the center and the amount of gravity acting upon the object.

    Anyways even if you get the math right, setting up a stable orbit with physics is going to be inconsistent at best. Recommend toggling an orbiting state, turning off physics, and using the orbit behavior when appropriate instead.

  • You can have finer control by making your own typewriter text behavior.

    You'll need a variable or other data structure to hold the source text.

    + System: Every X seconds

    + System: len(Text.Text) ≠ sourceText

    -> Text: Set text to left(sourceText.Text, len(Text.Text) + 1)

    It should typewriter out letters from sourceText until the length matches, and continue if you append to sourceText.

  • construct.net/en/blogs/construct-official-blog-1/remember-not-waste-memory-796

    Although, modern devices should be able to handle 1G worth of vram use. But 600 is still quite a bit unless your project is massive, so I'm sure there are ways you can optimize memory use.

  • This is a very common, classic group movement pathfinding problem, not exclusive to C3, and not an easy issue to solve.

    striketactics.net/devblog/starcraft-1-pathfinding-technical-analysis

    sandruski.github.io/RTS-Group-Movement

    A few options from simplest to most complex:

    A. Use different targets to move to, don't move to the same place, at the same time.

    B. Spread out upon reaching the destination, or triggered when in an undesirable state of overlapping.

    C. Have units attempt to maintain relative distance by slowing down or speeding up while moving. This is a portion of flocking systems.

    D. Implement full steering/flocking mechanics: gamedevelopment.tutsplus.com/series/understanding-steering-behaviors--gamedev-12732

    E. All of the above.

  • 400 doesn't sound unreasonable. Do you have some large sprite(s)? Maybe something over a couple thousand pixels wide and tall?

  • Oh interesting. I was using On clicked object and it was working fine.