TileMap's "Erase Tile Range" action creating error

Problem Description

When using a tilemap based level I have a bomb going off after 3 seconds of being lit, but it seems no matter how I arrange it that Erase Tile Range action produces a Uncaught Abort() at Error with physics. I have literally disabled every part of my code and this is the only line that creates the error.

Wait 3 seconds

Erase Tile Range

X: TilePlanet.PositionToTileX(abs(bomb.ImagePointX(0) - 128)) + 1

Y: TilePlanet.PositionToTileY(abs(bomb.ImagePointY(0) - 128)) + 1

Width: 8

Height: 8

UPDATE: I have tried limiting to one at a time and using Erase Tile Range in other fashions This action always seems to produce this error after awile. I have also used Erase Tile marching the 8 x 8 square range and erasing each tile manually and it still produces this same error.

Description of Capx

____ Concise description of what this CapX does ____

It is a side view game with physics items that allows you to light matches, bombs and those bombs explode the terrain in order to dig.

Steps to Reproduce Bug

Simply using Erase Tile Range Whatsoever

Operating System and Service Pack

____ Your operating system and service pack ____

Windows 7 SP 1

Construct 2 Version ID

____ Exact version ID of Construct 2 you're using ____

Release 244 (32-bit)

Does the "bomb" exist after the three seconds?

Yes, it only gets deleted after the tile map erase I have also tried manually going through the tile and just using Erase Tile on a case by case scenario and I still get the same error. It seems there is something going on with erasing a tile on a tilemap next to an object with physics. Also tried disabling all the physics I could during the tile erase and no luck so far.

Physics_behavior.js:10 Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 33554432, (2) compile with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents some optimizations, or (3) set Module.TOTAL_MEMORY before the program runs.
Physics_behavior.js:7 Uncaught abort() at Error
    at fb (http://localhost:50000/Physics_behavior.js:31:26)
    at ua (http://localhost:50000/Physics_behavior.js:417:61)
    at Function.o [as W] (http://localhost:50000/Physics_behavior.js:17:91)
    at nc (http://localhost:50000/Physics_behavior.js:167:483)
    at NB (http://localhost:50000/Physics_behavior.js:196:40914)
    at _f (http://localhost:50000/Physics_behavior.js:184:24253)
    at Fx [as g] (http://localhost:50000/Physics_behavior.js:654:22)
    at behaviorProto.Instance.behinstProto.createBody (http://localhost:50000/Physics_behavior.js:1551:16)
    at behaviorProto.Instance.behinstProto.tick (http://localhost:50000/Physics_behavior.js:1888:9)
    at Runtime.logic (http://localhost:50000/preview.js:2634:29)
If this abort() is unexpected, build with -s ASSERTIONS=1 which can give more information.[/code:171v320o]

Should I rebuild the procedural generated level to be individual sprites instead of a tilemap If i want to make explosions like this?

Update: [b]No problems If I don't use any physics.[/b] Hate to give them up it looked so awesome. I know it is something I am needlessly mixing up stuff in the background probably, because in my mind it shouldn't be a calculation issue with removing an 8 x 8 tile range and physics objects simply dropping because nothing is below them. Can't figure out what I am doing wrong. procedural generated tilemap levels with explosions that erase tile ranged near bomb. Hmmm Objects that had physics behavior is Matches, Bombs and the Foreground Tilemap (solid level one)

Replicate the error in a capx of minimal events.

Reports without a c2 file are useless.

Sorry, I thought this was a "I have a bug in my program" forum I didn't know these were meant for declaring a bug with construct 2 itself. I think I may have posted in the wrong place, excuse me.

If it throws an error message, then its a bug, but it has to be replicable.

It's not likely to be the fault of the tilemap, but of physics.

Build in Physics can not handle changes in the collision polygon.

It is known, and reported several times, but, i guess, flagged a "wont fix'.

Basically Physics creates a new object every time the collision polygon is changing, and therefor runs out of memory. For a tilemap, i gamble that it creates a physics object for each tile.

Look here for suggestions, Rojohound suggested a work arround, but also his plugin does not have that problem.

I made an excellent substitute using the bullet behavior with gravity and bounce off solids property. All I really needed was a few modifications to make a decent fake physics. First I took 1/5th off total speed on the solid bounce via collision event and when object is moving rotate by X - LastX, then update lastX. After 100's of tests I really appreciate the bullet behavior setup I have decided on. I am glad it seems a workaround is always just a brainstorm away with this system.

99InstancesToGo - Thanks for the update on the situation, It probably is doing those collision calculations across the entire board when using a tilemap and physics. With 100 x 1000 tilemap it can't be too easy on those calculations especially if a memory issue is present. I am not really trying to animate so much as completely erase one tile. I don't know if 100k physics objects (most immovable) is even a thought worthy project, but I am tempted to just stick with NES style physics for now.

Newt - Well it does give an error message and All you have to do to produce the bug is to use a big tilemap and toss some physics objects on it and after try erasing tiles. I apologize about the lack of resources, but as a commercial game I am not sure what I can and can't do. While I can most likely trust you guys being other developers on this network I have really no clue who is going to get a hold of something If I post it. I figured as broad as this problem is that a project file might not be needed to diagnose this issue.

Thanks for replying both of you!

I would have hoped that there would be a difference between changing the collision polygon and completely removing the object. As you said about a new "collision instance" is created when you change the polygon, but nothing new is created when you erase something so I personally consider this to be a bug or something that needs work within the utility. If I was animating things I would just use the invisible collider, but removing them from the game world bringing up the same issue looks to me more like problematic built-in physics. Either way still loving construct.

Closing, please see the bug report requirements. We need a .capx file to be able to investigate bugs.