R0J0hound's Forum Posts

  • Fengist

    It doesn't crash for me either, and I'm not sure why you'd be running into a memory limit with asm.js in your capx.

    One thing that does stand out is sprite3 is animated. The physics engine has to re-calculate the collision polygon every time the frame changes, which I guess may be using up memory. Often what I do is create an invisible second object with one frame to handle the physics, and then remove physics from the animated object and pin it to the other object.

    Also you can avoid the memory limit entirely by changing "project properties"->"Physics engine" from "asm.js box2d" to "box2d web". The only difference is the performance may not be as good.

  • Actually picking is as efficient as looping over all the tiles, since each tile would need to be looked at to see if it should be picked. But like eliasfrost said you don't have to loop over all the tiles only the ones the player is overlapping.

    Link with examples to look at only overlapping tiles:

    Alternatively you could use just sprites instead of the tilemap to be able to do picking.

  • Sounds like the file is corrupted, and from what I've seen that means anything beyond that point in the file is gone. Cap files contain info in this order "layout", "animations", "images"... But if the file is corrupted beyond that point the only real thing you may be able to recover is images up to that point. If you post a link to your cap file I can see what images can be recovered.

  • You can't use lerp() to do acceleration. You have two options. One is to use a third party plugin like litetween to do the easing or you can do it with math.

    For the math route to do acceleration you need to keep track of the object's speed. Then using this formula to calculate the stopping distance:

    stoppingDistance = (speed^2)/(2*acceleration)

    You could do this:

    global number acceleration=100

    global number velocityX=0

    global number velocityY=0

    global number targetX=0

    global number targetY=0

    global number angleToTarget=0

    system: compare distance(sprite.x,sprite.y,targetX,targetY) > (distance(0,0,velocityX,velocityY)^2)/(2*acceleration)

    set angleToTarget to angle(sprite.x,sprite.y,targetX,targetY)

    add cos(angleToTarget )*acceleration*dt to velocityX

    add sin(angleToTarget )*acceleration*dt to velocityY

    Else

    set angleToTarget to angle(sprite.x,sprite.y,targetX,targetY)

    add cos(angleToTarget )*-acceleration*dt to velocityX

    add sin(angleToTarget )*-acceleration*dt to velocityY

    Every tick

    sprite: set position to (self.x+velocityX*dt, self.y+velocityY*dt)

  • I can't open your capx right now, but you could use the clamp() expression to set the menu's position when dragging and on drop.

  • That condition is working correctly. You're picking the nearest line and setting it's width to the distance between the player and a node. The issue is finder.node is updated a few frames later so the width calculation will be the same and every frame the next closest line is destroyed.

    To fix it you'll need to synchronize destroying lines when you change nodes. A simple way would be to give the lines a variable with it's node number, then in the "step=finder.noSteps" event add a sub-event that picks the line with the old node number and destroy it there.

  • You need to put those events as sub-events of the start of layout event. As it is now they will all be run every frame.

  • That "system compare" doesn't pick anything so all the frames will change if the first instance of sprite makes the condition true. To fix use "pick by comparison" instead or add a "for each sprite" above the compare.

  • MiniHulk

    That's interesting it pauses for a bit, no idea why it does that. The behavior actually has nothing in place to support save/load currently.

  • megatronx

    Here's another iteration that adds other units (moving and not) that can push each other around. They're all circles.

    https://www.dropbox.com/s/98xzy7n9jrri6 ... .capx?dl=0

    Tokinsom

    If you're interested the smooth motion around the corners is done by using voronoi region around the polygon. The light blue region is closest to an edge and dark blue to a corner. It then finds the distance and angle between the object and that point or edge of that region. With that it can calculate how far to move away if too close.

    https://www.dropbox.com/s/ethfdnbvqlfij ... n.png?dl=0

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • [quote:8pibyrav]Then you can use the UID to pick them, and the sprite.count-1 to determine the last one.

    sprite.UID=Sprite.count-1

    that will select the last one created.

    That will only work if Sprite is the only object type you have in your game. Using iid might work though.

  • Bug. It pastes it regardless right now.

  • megatronx

    Here's the capx changed in a different way. It still uses imagepoints, but as long as there is three or more, and the points define a convex shape it will work. For isometric you could position the points in a diamond shape.

    https://www.dropbox.com/s/xvn63ri2yw9ir ... .capx?dl=0

  • Here's a non-regex way to do it. It just loops through the input a character at a time. It's longer but I do find it more readable.

    https://dl.dropboxusercontent.com/u/542 ... parse.capx

  • Mahbub918

    You can do it with the "take snapshot" action. Just set the canvas size to the layout size, capture, then set the canvas size back to normal. There's probably some browser limits to how big you can make the canvas though.

    start of layout

    system: set canvas size to layoutWidth x layoutHeight

    system: Take snapshot of canvas

    system: on canvas snapshot

    browser: invoke download of canvassnapshot with filename "layout.png"

    system: set canvas size to 640 x 480