Physics Tilemap Bug

[Bigbeto123]

I'm sorry but I could not find any way to reproduce this bug in a smaller file. Spent 1 hour trying to but couldn't. In this specific project, whenever you apply the physics (immovable) behavior to the tilemap, the whole area of it will become immovable, instead of just the tiles themselves, pulling every single object with physics out of the layout.

Attach a .c3p

bug.zip

1. Create objects with the physics behavior inside the layout
2. Create a tilemap with physics (immovable)
3. Due to some unknown combination of behaviors and effects, in this specific scenario, it'll pull every single object out of its area (the whole layout).

Objects are pulled out of the layout

the should not. Physics should only affect the TILES, not the whole tilemap area.

More details

Affected browsers/platforms:

First affected release: r194

System details

View details

Platform information Browser: Chrome Browser version: 80.0.3987.163 Browser engine: Chromium Browser architecture: 64-bit Context: webapp Operating system: Windows Operating system version: 10 Operating system architecture: 64-bit Device type: desktop Device pixel ratio: 1.25 Logical CPU cores: 8 Approx. device memory: 8 GB User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36 C3 release: r194 (beta) Language setting: en-US Local storage Storage quota (approx): 133 gb Storage usage (approx): 435 mb (0.3%) Persistant storage: Yes Browser support notes This list contains missing features that are not required, but could improve performance or user experience if supported. Nothing is missing. Everything is OK! WebGL information Version string: WebGL 2.0 (OpenGL ES 3.0 Chromium) Numeric version: 2 Supports NPOT textures: yes Supports GPU profiling: yes Supports highp precision: yes Vendor: Google Inc. Renderer: ANGLE (Intel(R) HD Graphics 630 Direct3D11 vs_5_0 ps_5_0) Major performance caveat: no Maximum texture size: 16384 Point size range: 1 to 1024 Extensions: EXT_color_buffer_float EXT_disjoint_timer_query_webgl2 EXT_float_blend EXT_texture_filter_anisotropic KHR_parallel_shader_compile OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context OVR_multiview2 Audio information System sample rate: 48000 Hz Output channels: 2 Output interpretation: speakers Supported decode formats: Ogg Opus (audio/ogg; codecs=opus) WebM Opus (audio/webm; codecs=opus) Ogg Vorbis (audio/ogg; codecs=vorbis) WebM Vorbis (audio/webm; codecs=vorbis) MPEG-4 AAC (audio/mp4; codecs=mp4a.40.5) MP3 (audio/mpeg) FLAC (audio/flac) PCM WAV (audio/wav; codecs=1) Supported encode formats: WebM Opus (audio/webm; codecs=opus) Video information Supported decode formats: WebM VP9 (video/webm; codecs=vp9) WebM VP8 (video/webm; codecs=vp8) Ogg Theora (video/ogg; codecs=theora) H.264 (video/mp4; codecs=avc1.42E01E) Supported encode formats: WebM VP9 (video/webm; codecs=vp9) WebM VP8 (video/webm; codecs=vp8)

[Bigbeto123]

Before you classify it as "not a bug", I've already tried removing the 8 directional and solid behaviors from every single object present (due to its "conflict" with the physics behavior), and the bug still happens anyways. Also, I'd like to ask a question. What's the point of a physics behavior if it can't be used along with any kind of movement behaviors? (Like you said previously, 8d and physics are "incompatible") This isn't a problem in ANY engine I know, and so I'd like to know the answer, as this one is MUCH more expensive to use than unity or godot, for example.

[dop2000]

Before you classify it as "not a bug", I've already tried removing the 8 directional and solid behaviors from every single object present.

Then you should post an example where all these other behaviors are removed. Without the correct example your bug report will be closed. In the project you shared your TileSolid object has Solid+Physics behaviors, your enemies have Solid+Pathfinding+Physics, your player has Solid+8direction+Physics. You can't do this!

[Bigbeto123]

Just remove the behaviors, please. From "Player" sprite, "Tilemap" tileset and "Enemies" family. Can't be that hard. Delete all the movement and solid behaviors present, and the issue will STILL reoccur. Also this exact same layout and gameplay used to work with the obstacle set being composed of sprites and NOT a tilemap, so this is clearly a tilemap related bug, and not otherwise (if it wasn't then why would the sprites work along with it in the first place?) By the way, if this does get ignored and not resolved I am cancelling my subscription. Literally no other respectable engines out there can't simulate physics for a player/AI-controllable object. If you can't do in this engine, then what would be the point of even bothering to have a physics behavior in the first place? To simulate lifeless debris? Come on, it's a pretty known fact that MANY people have been using the physics behavior along with movement behaviors to create 2d shooters in construct - to simulate recoil, impact and so on - you can find plenty of examples on yt. If your engine is improper for the way people are using it, then what's the point? Already working around many construct limitations with my projects, but this one I most definitely cannot do it. I will not switch a tilemap for god-knows-how-many sprite objects I would have to use to accomplish this.

[Bigbeto123]

Just went ahead of it myself and removed the behaviors manually. Surprise surprise, it's still bugged, as I stated previously. Here it is: bug2.zip

[dop2000]

I run the project and all I see is a black rectangle. What is supposed to happen? Where is the bug and how do I replicate it?

You can use physics in combination with other behaviors if you do it properly and make sure they are not conflicting with each other. For example, when your player dies, you can disable 8direction and enable Physics to allow it to fall down bouncing off obstacles. But if both behaviors are active at the same time, they will be pulling the object in different directions, all physics calculations will be wrong and you will get unpredictable results.

[dop2000]

Ok, I removed some stuff and was able to run your game. There are two instances of TileSolid tilemap. One is your map, and another one is empty. Looks like the empty tilemap acts like a big immovable object, blocking everything inside of it. If you delete the empty tilemap, your game will work correctly. I don't know if this is a bug or by design.

[Bigbeto123]

But if both behaviors are active at the same time, they will be pulling the object in different directions, all physics calculations will be wrong and you will get unpredictable results.[/quote]

For recoil and kick I disable the 8d temporarily and let the physics impulse the object away and then re-enable it. Seems to work pretty solid so far.

I run the project and all I see is a black rectangle. What is supposed to happen? Where is the bug and how do I replicate it?

By the looks of the editor screen, that's quite obviously the bug itself. The characters should simply stay inside the layout and NOT collide with the tilemap area (without tiles).

Ok, I removed some stuff and was able to run your game. There are two instances of TileSolid tilemap. One is your map, and another one is empty. Looks like the empty tilemap acts like a big immovable object, blocking everything inside of it. If you delete the empty tilemap, your game will work correctly. I don't know if this is a bug or by design.

Yes, I see. I must have created the another one by mistake at the time I accidentally changed the zoom of the chrome window (weird stuff happens in construct that way). Althought, I removed it as well and saw something quite strange happen to say the least... While having the solid behavior deleted from the tileset (with physics only), it worked normally (except for the part that 8d objects can literally move through it...). Then, later I added the solid behavior to it - back to the previous bug... So I accidentally moved the tileset 1 tile to the left of the layout (leaving 1 column of it out of the layout)... And things simply worked. However, it's getting pretty clear to me that this is a bug, and some "design" choice.

Also got some questions. Why in the world is the physics behavior tied only to "dead" objects?? Which kind of ACTUAL movement based game that doesn't uses physics nowadays? Wanna make a shooter? Ok, just without recoil, impact or any feature that decent shooter games have. Wanna make a racing game? Alright, but no car-to-car collision, else things will break. Can't you see a little problem in here? Not that hard to figure it out why there aren't any actually famous/relevant games made in this engine... For example, every single soul in the college I'm studying on (game design classes) downplays construct due to its countless limitations, as mostly move on to Unity, Unreal, Godot or engines as such. Being only regarded as "game jam material". Used to always question why people underestimate construct so much, but now I'm afraid I have quite the answer.

So basically, the instance was deleted. Alright, but the whole editor area of the tilemap is still counting as an solid object whenever I put both the solid and physics behavior on it. Unless it's got part of it out of the layout. What the heck? So you're telling me that I can't possibly add recoil and ANY collision reactions to a shooting game with any kind of obstacles (cause the 8d object will simply go past through it)???

I simply can't see why a tilemap object can't have both the physics (for stopping physics objects from going past through it) and solid (for stopping 8d objects from moving past through it) behaviors at the same time... While sprites actually CAN (despite the claims of it being incompatible and such), causing absolutely NO unexpected behaviors nor problems with the game. Easiest option I can see, is to simply fix this "incompatibility" with tilemaps, as in the very engine there's nothing stopping you from including both behaviors on them. Shouldn't be any hard since sprites already work with both of them just fine.

But now, as I suggestion I'd like to say that construct SHOULD have a better integration of movement behaviors AND physics. Either you merge them into the same behavior (just like MANY engines, such as unity do) or at least add an "advanced" menu for more enthusiast users to tinker with it. I simply cannot see the logic behind 8d objects simply ignoring collision with immovable physics objects (which clearly SHOULD be considered solids by the movement behavior standards). There's no possible practical situation you wouldn't want them to be.

[Bigbeto123]

By the way, just expanded the tilemap to the left of the layout (leaving one column out of it) and then have re-drawn the tiles where they should be... And it works just fine, without any kind of "incompatibilities". So you technically already have this "incompatibility" ironed out, just with a minor bug related to tilemaps plaguing it. Yeah, so this is a BUG. So please, fix this issue with tilemaps bug.zip

Uploaded the example right above so you can see it with your own eyes.

Basically the thing you guys said that wouldn't work in your own engine actually works, so do yourselves a favor and expand it as a feature at least?

[dop2000]

Why in the world is the physics behavior tied only to "dead" objects?

I didn't say that! You can make a physics platformer, physics racing game, physics top-down shooter. Just try not to control the same object with physics and non-physics behaviors.

simply can't see why a tilemap object can't have both the physics (for stopping physics objects from going past through it) and solid

You can! You can set your tilemap Immovable and Solid. It will stop physics objects and it will stop non-physics objects with other behaviors. But if a moving object has both Bullet+Physics for example, and it collides with this tilemap, both behaviors will try to handle the collision in different ways and who knows what will happen..

[Bigbeto123]

I didn't say that! You can make a physics platformer, physics racing game, physics top-down shooter. Just try not to control the same object with physics and non-physics behaviors.

Fair enough. But then why do all movement plugins have no integrations with the physics behavior, and instead only with the solid's? I know I can make player controls via applying impulse/force to objects when keys are pressed, but it'd be quite time consuming and not as fleshed out as the control behaviors themselves, am I wrong?

You can! You can set your tilemap Immovable and Solid. It will stop physics objects and it will stop non-physics objects with other behaviors. But if a moving object has both Bullet+Physics for example, and it collides with this tilemap, both behaviors will try to handle the collision in different ways and who knows what will happen..

Loads of bullets, physics debris and solid/8d objects ARE in fact colliding with it, and in my many sessions testing this project, absolutely nothing unexpected/'unstable' happened. In the former case, I was using sprites as objects (with both immovable physics and solid behaviors) instead of tilemaps. The ONLY change. Now, I can't see why expanding a tilemap out of the layout could possible logically be the answer for this issue, but it sure works that way. Not quite an intuitive behavior to say the least. But a very minor bug for such a grand scale incompatibility.

And now, with this "hotfix" of mine, things are stable as ever. No weird bullet interactions nor any of the objects.

[dop2000]

absolutely nothing unexpected/'unstable' happened

My guess it's because usually one behavior "overpowers" another. You can continue doing this. But when the next bug (inevitably) happens, you will know why.

[Bigbeto123]

So the one actual solution for this issue would be to make a movement "behavior" from scratch utilizing the physics behavior force and impulse events? I mean, I can do this, but wasn't the key selling point of this engine to be intuitive and simple? I'm quite puzzled by these design decisions.

Btw, so the tilemap bug (that I found a quite simple but weird) workaround won't be fixed?

Would physics support for movement behaviors be unviable/undoable by any means? In my sincere opinion this would be quite a high impact improvement for the overall functionality and accessibility of the engine.

One last suggestion. In a more realistic point of view, how hard would it be to add in an option to "unlink" the built in solid behavior from the movement behaviors, so you can either add the solid behavior itself or physics to the objects? Which would quite largely benefit more advanced users... And in a quite simple way resolve both the issues I'm currently having (and imagine many other people are, since I learned to make these shooters DIRECTLY from youtube tutorials, so quite a lot of people are doing it the same way) with the engine. Not only that but it'd make creating overlap-able moving objects MUCH easier than it currently is (which is by adding exclusive collision filters to them through the additional solid behavior). In a quite more optimized/perform-friendly way, I'd say.

[Bigbeto123]

Small update: After quite some headache, I've managed to create an identical physics-based function of movement for the player object. Things are, in fact, quite smoother. However, I'd still like to know the answer to the questions above. Also, a small doubt: When the object (in the 8 directional movement behavior) is moving at diagonals, to simulate it through physics would be to set its X and Y velocity roughly to 2/3 of its original value, correct?

Oh, and how on earth can I possibly re-create the pathfinder behavior through physics?

[Bigbeto123]

New Update: Finished removing all the incompatible behaviors present in the project... And the tilemap bug is STILL happening, so yeah, that definitely needs to be fixed. Here's the project: bug3.zip

As a sidenote, the player (in game) is appearing in a diferente place than he was at the editor, like some invisble object was pushing him upwards.. (and there's absolutely nothing in there, double checked it)

[AshleyScirra]

I'm afraid we can't investigate reports like this. People routinely file issues that are just mistakes in their projects. If you cannot reproduce the issue in a new project, this is generally good evidence that Construct is working correctly and the mistake is in your project. Here's a minimal project I made that demonstrates physics on the Tilemap object working correctly: tilemap-physics-working.zip This works fine in both the latest stable and latest beta, which is strong evidence it is working correctly and therefore is not the cause of the problem in your project.

Unfortunately as a small team we simply do not have the resources to spend hours sifting through people's projects looking for something that might be a bug in Construct, especially if it seems likely this would only identify a mistake in the project. Part of the reason the bug report guidelines are there is to avoid us having to do this since it would be a major drain on our resources. Therefore I'm closing this as all the evidence so far appears to point to Construct working correctly and there being some mistake in the project.

As for the design aspect, in short physics simulations are very CPU-intensive, and have their own sets of issues regarding limitations, precision, and determinism. Most games don't need to be burdened by all of that, so the existing behaviors don't use a physics engine, making them fast, lightweight and predictable. If you do use a physics engine, then everything has to happen in the physics simulation for it to work correctly, which does not include existing behaviors. This is covered in the tutorials and documentation for physics. I'd add that from a quick glance at your game, it does not appear to be the type of game that actually needs to use realistic physics simulations at all. So you could potentially remove the use of physics entirely, and it would significantly improve performance and remove any behavior/events/physics conflicts.

[Bigbeto123]

I guarantee you that I couldn't find any other way to reproduce this issue. It IS a bug, though. Must be a very specific one, but still. Triple checked every single event block and behavior present in this project, every single instance on the editor and the answer is: there are no single incompatible behaviors present, no duplicate objects nor anything that could drive the tilemap to act like a giant collision block with the immovable physics behavior tied to it.

What I asked was to give the option to the user to integrate physics to one of the movement behaviors, not to burden all of them with mandatory physics. As, in my recent experience, it is quite time consuming to re-create one of them through the physics behavior, specially ones like the 8d and car-movement.

And no, features like recoil, kick and impact are mandatory in this project, so it isn't unnecessary at all. This is only a minor prototype and will be expanded on as soon as the sprites are done. Btw, as I said previously, I've removed every single incompatible behavior present, so there's is no excuse for it to still be plagued with bugs...

Downloaded the last beta update, and it is STILL happening.

Inside the tilemap, all objects are being pushed to the nearest edges when it starts... And the player, specifically is being pushed through it, to outside of the layout Again, ONLY physics behaviors present.

Even went as far as deleting every single tile from the tilemap... And it STILL happens exactly the same way. The object's data has clearly been corrupted. And this is not the first time I've had issues with tilemaps, they always seem to be the buggiest objects in the engine. Created another tilemap from scratch, and then applied the Shadow caster and immovable Physics behavior to it.... the exactly same thing happened again;;;

[dop2000]

I guarantee you that I couldn't find any other way to reproduce this issue.

@Bigbeto123 Wanna bet? :) Here is a minimum project with this bug: https://www.dropbox.com/s/0clu46euqx4sx9u/PhysicsTilemapBug.c3p?dl=0 No events, no unnecessary objects. I suggest you log a new bug report using this example. Problem description - Green player sprite gets pushed out of the tilemap and becomes invisible. Other objects are misplaced too, but they stay inside of the tilemap.

[Bigbeto123]

Yeah, just found a way to reproduce it as well hahah Filed a new report already. But thanks tho Btw, the enemies falling down are due to the world gravity not being set to 0, so that's not a bug;. Only the player vanishing

[dop2000]

If you watch closely, you will see that enemies appear not where they should - shifted a couple of cells to the right/left/up. Also, there is no need to be toxic and sarcastic. Your previous bug reports were closed because you didn't follow the reporting guidelines, posted big complex projects, instead of a small demo clearly demonstrating the problem. When you are cooperative with developers, most bugs reports are resolved quickly.

[Bigbeto123]

I'm sorry, but for such an expensive service (yes, not a one time payment product, a SERVICE), construct should have WAY less bugs and technical problems this far (almost in the 200th update), in my sincere opinion. Specially when many of those were already present, AND FIXED in construct 2 - one of the reasons many people would rather stick with it instead of buying its successor. And to add it up, most of the problems I've been having are, in fact, related to the tilemap obiect... Last game jam I took part in, the position to tile function wasn't working out properly (and just recently got fixed... Again), and forced me to use sprites instead of tilemaps (for a building game), which has made me quite disappointed and frustrated with construct to say the least. That is not to mention the countless collision issues related, as solids "pushing it other" for no reason (without any physics behavior turnt on), sprites that are not colliding with objects move-blocking them and so on... Also countless objects getting literally stuck in the editor and being unable to move them anymore (and no, the layer wasn't locked). Issues that I wasn't with the slightest drop of patience to replicate and report, one of the reason being all this bureaucracy needed in order to actually prove that said bug exists.

And now, after an undeniable bug was discovered, it simply gets disregarded... And a quite (in my view) high priority one. i know I know, guidelines. But the thing is, finding bugs is not MY job, and taking my time to demonstrate them in a new project is not either, its (or should be) the "playtesters" job. Now, I know, the team is small, but for such a high monthly price tag, does it really needs to be? Of course, this is much likely not the fault of the developers, but of whoever took these decisions, I suppose. To sum it up, it's not a great system to say the least. Whereas many other companies go as far as to even reward users for uncovering bugs.

So yeah, I'm not maliciously being toxic or sarcastic, I'm just fed up with these reoccurring issues.

[AshleyScirra]

No software is perfect and tracking down problems can indeed be difficult or frustrating at times. However please note this is not an excuse to have a combative attitude. Issue reports are still held to the Forum & Community guidelines. Please review those and ensure your conduct is within those rules.