R0J0hound's Recent Forum Activity

  • You could I guess if you could figure out what the minifier renamed cocoonlazyload to, but that's not really possible. Also yes you can find a few js minifiers online to do it later I suppose.

  • Thanks Little Stain

    Can you please give me the link for that Plugin and if possible some documentation to implement that plugin so that i can test that in my game.

    The quickest way to find it is to use the forum search and search for "svg"

    Just scroll down till you see a topic with "[PLUGIN]". To use it, presumably that topic will have some documentation, although I doubt it's just a simple matter of replacing sprites with svg.

    Also I second immortalx's idea, it's much simpler.

  • socialpilgrim

    I don't use mobile export at all so I can't test. It should work though, since a html5 canvas' are the most basic things that should work everywhere, and the plugin does nothing unique with it. Does any drawing work at all? Does it work with "webgl off"?

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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