As I know UPrimitiveComponent::UpdateOverlaps method was changed in 4.8. Most probably this bug is already fixed. Try the latest 4.8 preview build to check it out. Please let me know when you check it
I tried to reproduce the issue that you described but was unable to do so. Were you able to try this in 4.8 and saw the same results? If so, could you provide more information about how you are setting this up?
Yup, I managed to reproduce it (This time, OverlapIdx was 4, ArrayNum was 0). There is a very specific series of steps and conditions I do to reproduce it so hopefully this’ll help you narrow it down. Throughout the text I will add code snippets and I’ll group them into pastebins with relevant, but not necesarily same-file information.
First of all, the context is enemies wielding weapons and me disabling collision on those weapons when the enemy dies. The weapons can be melee or ranged, and are child actor components.
Perhaps significant is the fact that I create and populate those child actors via the construction script, as seen here.
Now, my ranged weapons have a child actor component which is the projectile (So basically my enemy’s child actor has a child actor). I set that to any object of the ProjectileBase class in my blueprint. The ProjectileBase header and implementation can be seen here.
Now, when my enemy dies and goes into ragdoll, I don’t want him flailing around because he’s colliding with his own weapon. This is the code snippet that turns off the weapon collision.
The error happens at line 12 - trying to turn off the collision of the projectile, but only, and only if the ranged weapon / projectile overlaps the melee weapon. I accidentally forgot to attach them both to the right hand and the bug didn’t occur - if they don’t overlap, nothing bad happens.
I hope this is enough for you to replicate it, or at least get a better understanding. Let me know if I can help in any other way.
Thanks for providing the code you are using. I am attempting to get a project to build using your code (there are some references to code that wasn’t provided, I need to comment out those references and make sure it still works correctly to reproduce the issue), and then will try to simplify the project as much as possible while still reproducing the issue.
Would it be possible to get the callstack provided by the crash reporter when running the project in the Editor?
Unfortunately I am also sporting this awesome bug:
But VS should provide the stack at the time of a break so it should be fine, I’ll get to it first thing in the morning when I get back to the office. Alternatively if the build I have at home can reproduce the bug I can have the stack in an hour.
Also, given the referenced code (I only included relevant bits) I will try and make a small project that just replicates the bug for you. Will get back asap.
Edit:
Also if you mean the weapon component code, I included pastebin links to those at the bottom of the first link. Here they are:
Creating the test project might take a bit, but here’s the callstack:
Line 349 in ProcessDamage is line 12 in the last code snippet I provided in my original explanation.
Also, for what it’s worth I personally think this can be traced down to ChildActorComponent, it’s always been an odd beast and I am using it in a very colorful manner.
I believe I am very close to completing the set up to reproduce this issue, but have one more question. How have you declared the Weapons array that you are iterating through in the loop that is causing the crash? The initial declaration I used for that array did not allow me to actually specify any weapons in the Blueprint I created from the enemy class.
Sorry for leaving that out. I imagine you’re talking about the Weapons array found in this snippet. That is actually a Map. Here’s a pastebin with comments on how it’s all done.
It’s a tad bit convoluted, I hope this doesn’t throw you off too much. Basically, Weapons is a map so that I can quickly access the weapons with a GetWeapons(FWeaponSlot Slot) function. The FWeaponSlot is just the socket it attaches to + whether it’s melee or ranged. Having the weapons in a map speeds up accessing like this.
The map itself is initialized by the CombatComponent (where all of this resides), but the caller for the InitializeWeapons() function is the EnemyCharacter, as you can see that weapons require the owner’s skeletal mesh to initialize (so they know where to look for their respective attach socket.
Last week turned out to be a bit crazy for me, and this week doesn’t look much better. I did have some time to look into this again yesterday, and I still think I’m close, but I am still missing some little thing that will allow me to reproduce the issue.
Would it be possible to take a look at the entire project? If I can see it happening in your project, I may be able to work backwards from there to determine where the issue is coming from.
I just talked to my higher ups and I can send you a striped down version with the bug through a private channel if that’s ok. If you can give me an email address to send the link to I can have the build by tomorrow morning.
If you have a private DropBox, Google Drive, or similar that you can upload a zip file to, you can send me a link via [private message][1] on the forums.
If that isn’t possible and you need to attach a zip file directly to an email, go ahead and send me a PM on the forums and let me know, and I will get you my email address.
Thank you for providing the test project. I have been able to narrow down where the the issue is occurring. Now I just need to figure out why this is happening with the particular setup that you are using with the character.
I was able to reproduce the issue right away. I think it is just that you have a very unique character set up, and you are perhaps doing something we had not anticipated. I spent a big chunk of today slowly working through the source code that is being run to find out where things were going wrong. Now that I know roughly where that is happening, I am hoping I can start picking stuff apart to find out why it is going bad in this case.