vee41's Forum Posts

  • Your solution is good for one button, but what, when each button will have other sound, and they are pressed on the same time?

    The events should work with any number of buttons/sounds. I'd place different buttons as different animations to that single object.

  • If its tilebased, I'd start flooding every non-walled tile starting from the castle and see if flooding makes it to the edge of screen. Basically check if any tiles surrounding flooded tiles are not flooded and flood them. Walls would block flooding. Could be optimized but that might not be necessary :)

  • If it

  • Link to .capx file (required!): capx

    Steps to reproduce:

    1. Run the layout

    2. Disable the add obstacle event and run layout again

    Observed result:

    Both objects move the same way around the obstacle, while only one of them has obstacle added.

    Expected result:

    The other object should go through the obstacle. This is fixed when objects have separate cell sizes.

    Manual quote :     "For best efficiency, use the same cell size and border for all objects using the Pathfinding behavior in a layout. If different objects use different values, then the Pathfinding behavior must generate multiple obstacle grids in memory, and pathfind along them separately."

    Changing cell size is poor mans fix to have them generate separate obstacle maps, but as mentioned in the manual this can have performance implications.

    Browsers affected:

    Chrome: yes

    Operating system & service pack:

    Win 7

    Construct 2 version:

    r148

  • Here is what I was talking about: dl.dropboxusercontent.com/u/19921470/testmyfile.capx

  • Because IID's are just indexes of objects. Manual explains it better. :)

    I'd recommend you use UID's and use the 'pick by uid' condition instead of referring to IID's in expressions. Referring to things in expressions is coderish way of doing things and not necessary in C2 :)

  • Put your UI elements in separate layer that has parallax scrolling set to 0,0

  • One way to do it would be this:

    variable lastTouched

    On object clicked

    .. set lastTouched : object.UID

    On button clicked

    pick object by UID lastTouched

    .. object destroy

    So every time you click on object you save the objects UID to a variable. When a button is pressed, we pick the object indicated in variable and destroy it.

  • You can pick things separately in sub event, your higher level picked objects will stay intact. Do something like this:

    variable: count

    .. complex stuff picking here

    .... pick all stuff

    .... pick stuff you want to count

    .... set count as stuff.pickedcount

    .. do things with before mentioned complex picked stuff

  • Or just use 'Stop animation' action on start of the layout.

  • If I understood you correctly, you'd want to save reference to a sprite in array? One way would be to save objects UID there, so you know which object is where.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Here is one simple way to do it:

    Camera movement

  • Can you share a .capx? Otherwise I'd probably try posting to the bug forums.

  • I was not talking about Behaviours. A well executed troll, My hats off to you.

    Then I misunderstood this part: "Rather than having it so every movement is already on delta time, they make it so you need to add a special little formula to make your game actually work the same on every system. "

    Did not understand the trolling part.

  • > Every default behavior uses dt by design.

    Here you go:

    Tutorialk on delta time.

    Be sure to read it all. especially this part:

    se dt everywhere

    > Any time you move an object at a steady speed, you need to use dt in that way to achieve framerate independence. For example, Sprite's Move forward action takes a number of pixels to move the object forward. If you constantly move the object forwards, you could move it forward 60 * dt pixels to move it at 60 pixels per second at its current angle.

    >

    Obviously it is not default. Especially when you are dealing with Physics.

    I'm well aware of that document. I said default behavior, move forward is standard sprite action, not a behavior. :)