One method that can be really handy for diagnosing these kinds of problems is to create a Text object, and then create an event inside the loop to print debuging info into that Text object.

e.g.

Insert the following event as a sub-event of the

"Segments.ImagePointCount = 2", and

"Segments.ImagePointCount = 3".

Event:

* Compare ( loopindex >= 0 )

* Compare ( loopindex <= 3 )

// This event will run 4 times, for the loop indexes 0, 1, 2, and 3.

Actions:

* Append text ( " Loopindex:" & loopindex )

* Append text ( " SegUID:" & Segments.UID )

* Append text ( " platUID:" & PlatformCollision.UID )

* Append text ( " plat2UID:" & PlatformCollision2.UID ) // Only needed for count = 3

* Append text ( " Seg.ImgPtX1" & Segments.ImagePointX(1) )

* Append text ( " Seg.ImgPtY1" & Segments.ImagePointY(1) )

* Append text ( " Seg.ImgPtX2" & Segments.ImagePointX(2) ) // Only needed for count = 3

* Append text ( " Seg.ImgPtY2" & Segments.ImagePointY(2) ) // Only needed for count = 3

* Append text ( " Seg.Col:" & Segments.Collision)

* Append text ( newline )

The "newline" at the end will make each loop iteration print out on it's own line.

Be sure to use "Append text" and NOT "Set text".

Note that some of the actions in the above event only apply to the case where "Segments.ImagePointCount = 3", and not when it "= 2". For the "= 2" case, you can remove all the actions that are commented "// Only needed for count = 3".

You'll probably have to stretch out the text object so that it has room to display multiple lines.

You may also want to set it's font size to something, small like 8 point, and set it's initial text to be blank.

Hey kaleu50,

To my knowledge C2 uses a polygon collision system, rather than calculating per-pixel collisions, meaning you would need a polygon collision object, or several, that match the contents of the canvas.

It's theoretically possible to create invisible collision objects via events that overlay the drawn-on parts of the canvas, but it's not likely to be very practical outside of some special cases.

One possible approach might be to use the tile map object, set the tiles to 1x1 pixels, and create a "solid" tile with a square collision polygon. if you can paint 1x1 collision tiles over the same area your canvas brush is painting color, then it might work.

Granted I've never used the tile map for anything like that so I don't know if there would be performance issues. I expect there would be. Though I think the tile map would still be much better than a ton of 1x1 sprites, which might not even run at all.

Update:

Okay I just tried the tile map setup I described, and to my astonishment, it actually runs in realtime without issue. Granted that was with 1 px wide lines. When I blocked in 50% of the 832, 480 screen with a solid mass of 1x1 collision tiles (over 200,000 collidable tiles) the game still ran smoothly. It started to slow down a bit when I got to 75% coverage (over 300,000 tiles). Practically speaking, if you could cull out the center tiles, and only make the edges of objects collidable, then you could probably make a pretty decent per pixel collision system.

I tried both 8-Direction and Platform behavior with it and it seems to work as you'd expect.

Also, the 1x1 pixel tiles are only important if you're doing something like simulating a per-pixel collidable terrain for a platformer. If super precise collision detection isn't essential, such as testing for loose overlaps with the mouse pointer, you could make the tiles 4x4 pixels and the whole setup would have 16 times fewer tiles in filled areas.

(By "16 times fewer" I mean "1/16th the amount of tiles", but both ways of phrasing it sound weird, now that I'm looking at them.)

In any case, I hope that helps somewhat.

No problem, glad I could help

No problem.

Interesting.

Thanks for pointing out that they can be declared in onCreate

I was going to ask about that specifically, as I wasn't sure if there was anything special needed to use it reliably. It sounds like it just works.

Between Instance and onCreate, is there a particular reason one might be preferable to the other, or is it more just a matter of style or convention?

I was trying to remember why I did one versus the other, and looking back through the original SDK templates (I mainly work from custom templates) I found the following comment inside the pluginProto.Instance body:

this.type = type;

this.runtime = type.runtime;

// any other properties you need, e.g...

// this.myValue = 0;

I think this may be why I've been putting properties there. I'm not sure if it makes a difference.

That said, the official Dictionary plugin declares properties in onCreate, and the official AJAX plugin declares properties in pluginProto.Instance. So I'm not sure if there's anything important about one vs the other, or if it's just down to preference.

When adding properties to my object in the SDK runtime, should I create instance properties in:

(Edit: By "properties" I mean JavaScript Object properties, not C2 property-panel properties.)

pluginProto.Instance = function(type) { ... }

or

instanceProto.onCreate = function() { ... }

Currently I'm creating them inside "pluginProto.Instance" as that's what I've seen in other plugins.

Is there any situation where one is better than the other?

Hey cmbbar,

I think the two main things you're probably looking for are global variables, and the "Persist" behavior.

(Those links go to the corresponding C2 manual pages.)

Global variables keep their values between layouts.

The Persist behavior, saves and preserves the state of objects between layouts, such that when you go back to a layout, the persistent objects will be wherever you left them last, instead of resetting to their starting positions.

Hey p0tayters,

Below are a few things that came to mind.

David Silverman - Match 3 in Construct 2 (from scratch)

RexRainbow - Match 3 demo

RexRainbow - Plugins Website

RexRainbow has built a ton of plugins for C2, and several are tailored to board & tile game mechanics.

My best wishes for your gaming grandmother.

You sound like an awesome grandkid.

Hey DiVeR, <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

I believe a family can only have one kind of object (plugin) in it.

e.g. Only Sprite objects, or only Text objects, or only Tilemap objects.

The icon of the family is borrowed from the object (plugin) type it currently contains.

Manual > Families: https://www.scirra.com/manual/142/families

• "All the object types in a family must be from the same plugin ..."

The problem you're having might be that you're trying to add a Tilemap object into a family already dedicated to Sprite objects.

Hey ChefSeth,

I'm not sure I quite understand what aspects of the code are currently not working.

The first thing I notice that might be an issue is that in your last two events, there is no icon for either the PlatformCollision object, or the PlatformCollision2 object. I don't know if that's indicative of a problem, but it might shed some light on what's going on.

In particular, in the "Set animation" actions, it looks like there's no way to visually tell which object is being acted on. I assume they should be PlatformCollision and then PlatformCollision2, but if they're not, that might be causing a problem.

It looks like every object in the Segments family has a private var named "collision", just out of curiosity, what does it do, and what would cause it to be greater than 900?

Hey JasonS,

One possible approach might be to separate the problem of path finding from the problem of overlap prevention.

Instead of having the Soldier be the object doing the path finding, make your current path finding object invisible, and make a new soldier object to follow the path finding object. Then give that Follower object the physics behavior, with a constant force pulling it towards its personal Pathfinder. By default, Physics objects won't overlap each other, and will instead slide past each other, or bunch up like gumballs in a jar.

But what if there's a physics traffic jam, and one of the physics Followers can't keep up with its Pathfinder object? After all, if a Pathfinder goes around a corner while the Follower is stuck, even if the Follower later gets un-stuck the Follower may not be able to reach the Pathfinder by moving straight at it, via a physics force. We need to make sure a Follower never gets left behind.

Basically each Pathfinder should be a mini Dr. Alan Grant. :)

To prevent Followers from getting left behind, you can pause the Pathfinder if it gets too far from the Follower. "Too far" in this case might mean 1 or 2 soldier widths. Ideally the soldier (Follower) will nearly always be just behind, and almost touching its Pathfinder.

No problem, glad to help. :D