FYI - I updated my earlier post to reflect an improved capx that attempts frame rate independence.

arthymon

You can delete X elements of the array to clear it, but be sure to leave at least 1 X element with valid coordinates (usually the starting position of the character). If you completely delete the array, the game will read a non-existent element as 0.

DUTOIT

cesarzevil did this translation, and I sent him the Capx. I'm not sure what he did with it after that.

Roccinio

If you want the Capx, you'll need to request it from cesarzevil. I find myself in a moral dilemma. While I'd like to help you, I feel somewhat obligate to not divulge how the movement works despite there being no agreement between me and cesarzevil to that end. Hopefully a high level overview is enough to get you started. There are 2 states to the movement:

• The rope is firing - Increase the rope's width until it collides with a surface it should stick to.
• The player is pulled in the direction of the rope - Once the rope is attached to a surface, calculate the appropriate force to add to the player's dx and dy so it moves towards the point in which the rope collides with the surface.

It's more complicated than that, but this should be enough to get you started. Make sure you're familiar with loops and basic trig, as they're integral to achieving the effect.

For each sprite, use their Y position to project the X intercept coordinate of the force field. If Sprite.X is less than the projected X, move it to a layer above the force field. Otherwise, move it to a layer below.

Demo

Capx

edgaredgar

Have you considered using separate sprite object(s) specifically for collision? Each potential collision polygon would need to be programed in, but it would give you more flexibility without a huge file size increase.

The problem is with your events. When not moving, you're continually starting the animation to it's current frame. So if the instance stops moving while it's frame is 1, your events will continually set the animation frame to 1, making it look like the animation isn't playing at all. When the Pacman instance is moving, events are no longer continually setting the animation frame, so the animation plays normally.

There is no way currently. This has been requested once or twice before, but I don't think there has been a response from Ashley. Hopefully it's on the to do list.

Ashley

I tested the above capx with r157. It looks like the appropriate tiles are available when making the tilemap larger, but when making the tilemap smaller, tiles that fall outside the object's dimensions are still displayed. When the above Capx is run, I would expect the top tilemap instance to only display 1 row of tiles.

Is this intended behavior for the tilemap object?

Link to .capx file (required!):

Capx

Steps to reproduce:

1. Add a tilemap object to the project.

2. Create an instance of the tilemap in the layout.

3. Add events to re-size tilemap.

4. If making a tilemap instance larger, add events to set tiles that should now be visible/available. If making a tilemap instance smaller, add events to set the tiles that should no longer be visible/available.

5. Preview the Capx

Observed result:

The visible/available tiles do not change at runtime. The debugger confirms the width and height of the instance changes, but the visible tiles suggests otherwise.

When running the above capx, the top tilemap instance displays a 2nd row of tiles. The bottom tilemap instance does not display a cactus at tilemap position 0,2.

Expected result:

Resizing a tilemap instance at run time updates the displayed/available tiles according to the instance's new size, similar to how the tilemap instance behaves in the editor.

When running the above capx, the top tilemap should only display a single row of tiles since the instance's height was reduced to the height of a single tile. The bottom tilemap should display a cactus at tilemap position 0,2) since the instance's height was increased to 4x the height of a single tile.

Browsers affected:

Firefox: yes

iOS: yes

Operating system & service pack:

Windows 7 64 bit SP1

iOS 7.0.4

Construct 2 version:

r156

FYI, there's an excellent userscript created by BadgerPriest that generates a performance chart on any LD author's page. Here's a link to his post with the file, and basic installation instructions. With the script installed, here's what my author page looks like:

<center><img src="http://i.imgur.com/LsmoJqn.png" border="0"></center>

Results are up. Congratulations to everyone who entered.

I ran into this limitation with one of my projects. I got around it by changing the canvas size to match the image size, taking a snapshot, then going back to the normal canvas size.

You can take dt into account when recording player movements and replaying them with another object. Take a look at this example. The example is for a braid-like rewind effect that takes dt into account when recording/rewinding. It could easily be modified to create a doppelganger effect. Instead of "rewinding" the recorded movement data, you can just replay the recording on a delay.

If the game's frame rate differs greatly when recording vs. rewinding, the replay can look choppy, but you could probably smooth it out by tweening the recorded data.