For the past weeks i am battling with collision issues inside my paper2d project.
For reasons that i cannot explain, collision triggers (on begin overlap) for the first couple of times fire as intended and after that all hell breaks loose!
It registers collisions hundreds of units away and yesterday i even saw a collision trigger fire from an object that wasnt even present on my level!
Any help pinpointing this and solving it would be great since this issue hinders the progress of my game .
I simply cannot create any interactions between characters since collisions seem random.
Please list specific instances of the collision issues you have experienced with as many details as you have available, images included if possible. You mentioned another collision issue with your wall cling functionality when I spoke with you earlier; is that still occurring?
It seems that this behaviour is happening only with blueprints that have a CharacterMovement component(character BP).With any other blueprint type collisions seem to work fine.
I cannot see how i can explain better in writing to you the problem since you already have my project and you can see it happening realtime in your own computer.The only thing i can do to help further is to send you the latest version of my file that has all the optimizations that you suggested.
I am not 100% sure but i think i cracked it!
When my hero collides with the capsuleComponent of a BP that has CharacterMovement component everything seem to work fine.The problem is when he collides with a box collider that has been added to the above blueprint!
I just added a box collider in my archer and i have the same exact problems.If i collide with him using only his capsuleComponent then everything seems normal.
I was finally able to reproduce this in a custom project. The one thing that set it off was, as you discovered, having two sources for collision. In my custom enemy, the CapsuleComponent collision preset is set to Pawn. In the CollisionBox, it is also set to Pawn, but with one difference: it is set to ignore Pawns. If it is not set to ignore pawns, the two conflict and all sorts of weird things start to happen.
It may be different in your project (I’ll test that out later), as if I remember correctly you have your Spartan character’s collision preset set to Vehicle? Making all of the different collision interactions work properly in your project may involve setting custom object types and collision presets, which you can do in Project Settings > Collision.
I’m letting a developer know it’s been narrowed down.
I am not crazy after all.Thanks Ben!
In your experience should i wait a little longer in case this thing is resolved swiftly or should i put in the man hours (since i have quite a few interactions between characters) to set everything as you mentioned above?
I wouldn’t wait. Having collision component conflicts shouldn’t cause this kind of behavior, but you wouldn’t want them in your project even if they didn’t as they would likely cause many other issues. A good, clean collision setup for your whole project can be challenging, but in the end it’s going to be worth the effort.
I totally understand what you are saying but shouldn’t the engine being able to know when there are multiple collision detectors within the same blueprint and disable conflicts and collisions between them automatically?
Creating a clean collision system between collision components within a blueprint does not make any sense to me .You would soon run out of custom collision presets anyway.
For the time being until this is fixed from the collision guys i will have to do it the hard way. Thank you again Ben for you time and patience!
Just a heads up.Your observations are partially true.
I just finished a set of tests and it appears the problem is deeper than we thought.
I have my capsuleComponen interact with a detect block so it knows when to turn left or right and of course with static objects so it wont fall off the level.I also have a collision box that interacts with the main hero.Even if i set them not to interact between them (in my case it was already set up this way at least in the version i am working now) the result is the same .it still freaks out.The reason it didnt do the same to you is because you didn’t have a third collision in the equation! If i disable one collision (ignore the patrol block which is world dynamic ) from my capsuleComponent then it works.
As you can see this new evidence makes things chaotic and impossible to create any proper collision system.
And please do not forget that if you change your BP collision settings for a component and you do not delete and re import the instance to the viewport then the new settings do not update.
Hello Ben, did you have any progress in solving this problem?
Has anyone figured out what is going on so i can start working again on collision interactions between characters?
Someone PLEASE help me with this.Its been almost 2 months that i am facing this problem and it is so severe that i cannot create anything in my game that requires collisions between character Blueprints that have more than one collision box inside them.
I’m going to try to build this bug up from the bottom. I created a new SideScroller 2D project and set up a very basic representation of what you had set up in your project. I’ve included an enemy with 2 Box components in addition to its Capsule Component, as well as a couple of Patrol Blocks with their own Collision Channel and Preset (PatrolBlock). With this basic setup, I have not been able to reproduce the problem (though I still see it occurring in the project you sent me awhile back).
To help me narrow it down, can you pull down this project and take a quick look, see if I’m missing anything you need, and let me know? I’d like to get the root cause of the issue nailed down, and it appears that having an additional Box component is not, in itself, causing the problem.
Here’s a Dropbox link to the test project:
nice to have you back!
I managed to recreate the problem and i am uploading the project and a video as well ,just in case
And please do not forget to report that the engine does not apply any new collision settings that you change to a bp character until you delete them from the map and put them back in.For example if you change “block pawn” to “overlap pawn” to a collision box from your character blueprint that will not take effect until you delete and re-import the blueprint character to your map.This is a VERY serious bug because you can spend days wondering why your collisions do not work as intended.I personally spend more than 2 days trying to figure out what the heck was wrong until i discovered the above.Thank you!
Note:Please download and watch the video.Preview from dropbox is really bad quality.
I’m not seeing the same collision issues you initially described, in which jumping on the enemy would cause that weird looping bounce.
What I’m seeing right now is that the Overlap in the EnemyCharacter isn’t always detecting collision with MyCharacter. I’ll take a look to see if there isn’t something we’re missing and then bug that if necessary.
I’ll also look into the issue you described with needing to replace a BP in the level after making changes to its collision settings. I haven’t seen that before, but I’ll take another look in this project. Did you see that same behavior in this project?
But I still am not seeing the weird continual collision issue that we first saw in your project. Are you able to duplicate that in this project at all?
you did not see that continuous bouncing problem because i have set up the collision here as overlap and not block.If you set it to block while it fires you will see the exact same behaviour.As for the second part ,yes it got me fooled again!lol. i was setting up the project and while i was changing the collision presets for the enemy when i pressed play to check what i did it simply did not work.Then i remembered i had to delete them and re-import them and then the system updated the collisions and it worked as intended.
Okay, I was able to reproduce the weird bouncing issue when I turned Block Pawns on for the Collision Presets of the CollisionBoxBottom component and the CapsuleComponent for EnemyCharacter, as well as for the CapsuleComponent of MyCharacter. Only one CollisionBox component needed to have conflicting collision with the CapsuleComponent to reproduce this. I suspect it may also have something to do with Paper Character Blueprints specifically, as I could not get this to happen with any other type of Blueprint in any other type of project, even if Constrain to Plane is enabled.
I entered TTP# 347803 for this one. In the meantime, the best way to avoid this issue, as I mentioned below, is to make sure components within a Blueprint are not blocking each other. This may involve many custom Object Channels if your project is especially complex, but careful use of this feature and avoiding collision conflicts results in a cleaner project. I would be happy to update the Dropbox project to show you how this can be done, if you’d like.
I was also able to reproduce the issue with collision presets requiring a fresh instance of the character blueprint being dropped in the level, and entered TTP# 34775 for it. This does not appear to be specific to Paper2D, but to Blueprints that use the CharacterMovement component (Character.h, PaperCharacter.h, etc).
I’m still narrowing down the issue with inconsistent overlap detection. It seems like it may involve only components and not actors. I’ll let you know when I have it in a TTP.
I’ll keep you up to date when I see changes on these bug reports. Thanks for your help!
I would like to know if we had any progress regarding this bug and if your team is planning for a fix anytime soon.It was the beginning of July when i first encountered this problem and it would really make me happy to finally start seeing some interaction between my characters.Right now i do not place any Enemies inside my levels because of all the collision problems,and my game looks so empty and sad.
The second bug is being looked at for 4.7, though they’re not currently sure how they will fix it. I’m checking to see what the devs have to say about the first issue, and will let you know when I get a response.