R0J0hound's Forum Posts

  • The “trigger once” is throwing it off. Basically they all need to not be frame 1 before the event can run again.

    I’d do the logic under a “on frame changed” condition.

  • The tilemap has some expressions you can use to get that. Namely the row and column of the tile at a certain xy. Then you can use another expression to get the xy of the tile at a certain column and row. That will give you the tiles center then you can get the sides by adding/subtracting half the tile width/height.

    But you can calculate all that directly. For example if the tilemap is at 0,0 with a 32x32 tile size, and the player objects are smaller than 32x32, then this will give you the bounding boxes of each of the tiles the player could be overlapping.

    Gridx= int(player.x/32)

    Gridy=int(player.y/32)

    For i=-1 to 1

    For j=-1 to 1

    Tile at (gridx+i,gridy+j) != -1

    — left = (gridx+i)*32-32

    — right=(gridx+i)*32

    — top=(gridy+j)*32-32

    — bottom=(gridy+j)*32

    — resolve collision

  • An alternative if no one has the add-on is you can manually remove all references to it from the capx.

    Capx files are just zip files and you can access the .c2proj and .xml files for the layouts and events to remove it from them.

  • Wouldn’t setting the layout scale, as you would to zoom in with normal 2d games work?

  • Here's an idea how to make the bullets meander a bit before reaching their target.

    Basically this gradually increases the turning force, and uses sin() to meander in a curvy way. All the numbers in event 4 can be tweaked to change the effect in various ways.

    dropbox.com/s/ffnik6zpbie7vte/chaos_bullet3.capx

  • If it keeps sliding you have friction set to 0. That’s what your screenshot shows anyways. Set it to a value between 0 to 1 so it will slow down.

  • The order of the actions matter. Set the angle first, then move forward.

  • You won't be able to make it perfect by using a wait. I mean you can calculate how long it will take to rotate with time=(360/sprite.count)/speed, but since things update at 60fps you'll be off by 1/60sec or so which will add up. Plus, wait makes it harder to track what your events will do, which can make it hard to find the reason things aren't working.

    Conceptually you just need to rotate it a set number of degrees and then stop. Maybe with an ease?

    At any rate here is one way. The arrow keys change the goal angle, then the actual angle changes toward that. It will robustly stop at the correct angle.

    dropbox.com/s/d9ljfr2sade5orp/revolver_menu.capx

    There may be a simpler way too, but this should be simple enough to understand so you can use it in your project and customize.

  • The idea is the pinned object is just a bit bigger to visually hide the gap. All interaction/collision would be with the object underneath.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Looks like you can do it by recursively picking each child and adding up all the child counts. Simpler enough if all the object types are the same from the looks of it but it would complicate things with differing types. 

    Function descendentCount(uid)
Sprite: Pick by uid: uid
— local number count
— set count to sprite.childCount
— Repeat count times
— sprite: pick “sprite” child loopindex
— — add descendentCount(sprite.uid) to count
— set return to count

    Or depending on how the js api lets you access children it may work better because it doesn’t care about object types. 

    function descendentCount(obj)
{
 let count = obj.children.length;
 for(let i=0; i<obj.children.length;i++) {
 count+=descendentCount(obj.children[i]);
 }
 return count;
}

  • There’s nothing amiss. The physics engine has a thing called “slop” where it adds a slight gap between objects to make the simulation more robust. Anyways, this isn’t controllable in construct.

    A solution is to make the collision polygon slightly smaller so the gap isn’t visible. A more exact solution would be to have an a separate object pinned to the physics object. Just add 1 to the height and width.

    At least that’s an immediate solution based on what we can do.

  • The random(1) expression causes the “for each ordered” to loop over the instances in a random order. The loopindex is 1 when it’s on the second instance.

  • Another way that is useful in some situations is:

    For each sprite ordered by random(1)

    — do stuff

    — compare: loopindex=1

    — — stop loop

  • The effect does the outline by shifting copies of the image in four directions. So the corners would look off.

    I may have remembered wrong. It may be 8 directions and the diagonals had sqrt(2) multiplied by it.

    Anyways, I haven’t touched in a long time. Not sure how to get more perfect results.