Speedy1SonicBoy's Forum Posts

  • First of all - never use "Trigger once" condition with objects that have multiple instances.

    Deleted that part now.

    You need to make sure that your ghosts can actually find a path. The easiest way is to add some visual feedback. For example:

    > Ghost On path found → Ghost set opacity to 100
    Ghost On failed to find path → Ghost set opacity to 30
    

    If you see that them turning semi-transparent, try tweaking the pathfinding settings, such as cell size or padding.

    No semi-transparency happening here.

    Once you fix that problem, I suggest you use MoveTo behavior for movement, it's more accurate. And it has "Move along pathfinding path" action.

    I figured out that the reason it isn't moving is because the MoveTo had "Stop on Solids" active.

    I thought that was the way to ensure that the obstacle would act as such, but I'm guessing the size of the blocks didn't allow any movement at all.

    Now that "Stop on Solids" is no longer active, how would I make sure the ghostblock doesn't ever overlap the red?

    Edit: Figured out I had the numbers halved on the grid setup. Now that's working as intended, and there's no overlap because I added cost to the pathfinding overlapping red.

    Now the issue is in perpetual motion. What I've done so far is made a target move randomly between cell positions thusly:

    I want to figure out how to make it so that when ghostblock arrives at Target, the target changes location.

  • By reading the official manual! :)

    Admittedly helpful.

    Ok, given that, and with the assumption that it's all set up correctly... my character still doesn't move. What am I doing wrong here?

    If this helps, here's a basic rendition of my layout:

    The red is the border (Obstacle), the orange are the cells that spawn the characters (currently none since the focus is on the enemy sprite), and the brown is the enemy sprite.

  • I would also use Pathfinding+MoveTo. MoveTo is a lot easier to deal with than TileMovement.

    Configure the pathfinding grid correctly, disable acceleration/deceleration in MoveTo. Find path, move to the first node on the path. On arrived - move to the second node and so on. You can use tilemap expressions like SnapX/SnapY to find the exact center of the destination tile.

    Interesting. How would I go about configuring the pathfinding grid?

  • I plan to do something like Pac-Man's ghosts' AI in terms of movement fluidity, but using tile movement behavior instead of bullet behavior. I already looked into how "Eat 'em All" does it but came up short, as it uses bullet behavior instead of tile movement.

    Any help, as ever, is appreciated.

  • That's only a small part of the code. Did you implement all other steps? It feels like you don't fully understand the idea.

    Here is a demo - click any molek sprite to destroy it and break apart the remaining chain.

    Very cool. I see what you mean now. But now it leads to another question: with everything implemented before (That is here: construct.net/en/forum/construct-3/how-do-i-8/attach-sprite-specific-way-183986), with everything formerly worked on there, how would I now implement the new into the old?

  • Just so I can figure out if I got the aforementioned code right:

    But I must be doing something wrong, because very little has changed.

  • That's why we use families:

    > Molek is attached
    MolekFamily is NOT attached
    Molek overlapping MolekFamily
    

    I figured as much. Would I use MolekFamily instead of Molek for all the preceding code as well?

  • What do you mean? Where what would go?

    I meant to say, where would the script go in terms of lines? Also, would I have to replace every instance of molek with the family in the script?

  • You'll need to add Molek sprite to a family, and move instance variables from the sprite to the family level.

    Then you will be able to pick both in the same event, something like this:

    > Chemic pick children Molek
    Chemic pick children MolekFamily
    
    Molek is attached
    MolekFamily is NOT attached
    Molek overlapping MolekFamily 
    ----> MolekFamily set attached to true
    

    This confuses me a little. Where would it go?

  • I'm not sure I can answer your question. Your game is pretty complex, and while switching to hierarchies has probably made things a bit cleaner and more organized, it's still a complex system.

    All I can do is share how I would probably approach this task:

    1. Pick all moleks that are still in the hierarchy (i.e. children of Chemic). First, set attached = false for all of them.
    2. For each molek in the hierarchy that is directly overlapping (touching) Chemic: set attached = true.
    3. For each molek in the hierarchy with attached=false: check if it’s overlapping another molek with attached=true. If so, change its attached to true. (You might need to use a family: “Molek is overlapping MolekFamily.”)
    4. Repeat previous step until none such moleks left.
    5. Any remaining moleks in the hierarchy that still have attached=false at this point have broken off from the chain. Remove them from the hierarchy and launch them away.

    This helps. How would Step 3 look like?

  • So the easiest fix is this:

    > + Molek: On destroyed -> Wait 0 seconds
    ----+ System: Pick all Molek
    ----+ System: For each Molek
    
    

    That works... too well. Lol Now I'm having instances of molek fly off that are part of other chains.

    How would I be able to isolate only the affected chain, what in the conditions below would I have to amend/add?

  • I just realized I had a line similar to this, and added the add key line in the end. I'm assuming it needed a value of 1 so that's what I put down.

    What's next?

    This is what I put down underneath the main clause that breaks the chain visually, but so far it does nothing. Is there anything here I'm missing? Or might I be missing something somewhere else?

  • Here is an example:

    > Chemic pick children Molek
    For each Molek
    ... Dictionary add key Molek.dx & "," & Molek.dy
    

    I just realized I had a line similar to this, and added the add key line in the end. I'm assuming it needed a value of 1 so that's what I put down.

    What's next?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • One other thing to consider about the hierarchy system: it doesn't support loops. So if you need looped chains, like in the image below - you’ll have to connect all Moleks directly to Chemic.

    In that case, when any Molek is removed, you'll need to check which Moleks are still connected to Chemic and rebuild the hierarchy accordingly.

    Good to know! Looks like I'll have to do that to support loops. Still, building a dictionary from hierarchy... how would I go about doing this?

  • There are two ways to build the hierarchy: either attach all Moleks directly to the parent Chemic, or create a chain. I’m guessing the chain would be more suitable in your game. If a middle (blue) Molek in the chain is removed, it will automatically break into two smaller chains. Or you can detach pink molek from yellow as well.

    I'll try for the latter case in this instance. Basically anything breaking off from the chain will act as they would if Z were pressed, and (in this example) pink and yellow would bullet out of there separately from each other.

    I’d strongly suggest using the hierarchy feature instead, it will be A LOT easier. Attach Moleks to Chemic as children - this way, they’ll automatically move together and stay logically connected. You won’t need dictionaries or extra variables at all. You can find parent or child object at any time with "Pick parent/child" condition.

    The dictionary will be necessary for another aspect of the overall project that this stems from, where I'll need to call on it for an overall shape to be built, checking if numbers match the shape intended.

    construct.net/en/forum/construct-3/how-do-i-8/check-shape-built-185425

    It seems to be the only thing that works so far, and to remove the dictionary entirely would mean to overhaul this system that's worked for me.

    With all this in mind, where would you suggest the overhaul begin?