SetSimulatePhysics causes abort when enabled

This is on Mac, OSX 10.10.5, UE 4.8.3, XCode 6.3.1, Mid-2010 dual Xeon 22GB ram.

The scenario is that I spawn weapons at game start, laying around the ground, parented at root level. I pick them up by raycasting discovery. When I pick them up/equip them, I setsimulatephysics to false and no collision and use the Attach to component, they become a child of the character and work fine, and I can drop them using the following code:

void AFPSWeapon::RemoveFromParent() {
    SetActorRelativeLocation(FVector(100.0f,0.0f,0.0f)); //temp location, tossed out in front
    MeshReference->SetSimulatePhysics(true); //  <-------- **here is the sometimes abort**

MeshReference is derived at the startup of the weapon beginplay with:

    TArray<UStaticMeshComponent*> comps;
    if(comps.Num()>0) MeshReference=comps[0];

It’s .h entry, which is in the Item class I derive my Weapon class from, is:

UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Physics Control")
UStaticMeshComponent* MeshReference;

Now for the problem. When I despawn the weapon into inventory, then respawn it back into the player’s hands, it aborts on the statement marked up at the top. The MeshReference is not NULL, but it dies with an exception (EXC BAD ACCESS) here:

    0x102b47061 <+1937>: callq  0x10365621c               ; symbol stub for: FWeakObjectPtr::Get(bool) const
    0x102b47066 <+1942>: movq   %rax, %r15
    0x102b47069 <+1945>: xorl   $0x1, %r14d
->  0x102b4706d <+1949>: movq   (%r15), %rax

The above is in FBodyInstance::SetInstanceSimulatePhysics(bool, bool)

I have double checked my Casts from the two separate spawn routines and gone through all the code that builds the weapon from inventory, but I can’t find a difference, and both types (a fresh spawn at game start and a spawn from inventory) work identically in every other way.

I also ruled out timing by rearranging when I detach the weapon from the player to be done by a timer and rearranged the order of detach versus setting physics on.

If I comment out the physics enable, I am able to “drop” either type weapon (of course it sits in mid air) pick them up, use them, save them, stop the editor, restart and still use them normally. Interestingly, when I set the collision on, also pointed to by MeshReference, it never has a problem.

I’ve reached the end of my debugging ideas. What sort of thing can cause the SetSimulatePhysics to abort like this. I am just looking for more ideas to chase on this.

Edit: I continued to debug and decided to punt and go another way. I eliminated the code I show above where the abort was occurring, and replaced this with a BlueprintableEvent. When I fire that event, I execute blueprint code to detach and Set Simulate Physics off. This aborts also and ends up in the same machine code with the same error. If you are looking at this question, consider that I may have something fundamental wrong. The blueprint that I derive from my weapons class is very trivial, it has the staticmesh as the top level under the class, no other components (except on the fly such as the projectile which gets spawned during the Fire()). It turns out that the on-the-fly components, such as weapon barrels, stocks etc are related. If I create a weapon with no barrel, stock, scope or clip, all works correctly. It appears that the children attachment classes are involved, physics is off on them as is collision. A clue?

This is not actually a real solution to the SetSimulatePhysics Abort, what I did was disable Simulation and Collision on all subobjects, and only turn it on, in cases where a weapon attachment (e.g., barrel, stock etc) is laying around in the level unattached to the weapon. For the weapon, starting with it on, in all cases, then turning it off when equipped worked. The subtle difference is that the weapon didn’t have physics at spawn per se, not in the blueprint, and was turned on in C++ code if needed (if the spawn was not from inventory). Then, when dropping the weapon on the ground, the SetSimulate(true); could be used.

This is likely a bug, but I’ve managed to eliminate the combination of events that would cause it now. If it’s not a bug, it’s a misinterpretation on my part about the flexibility in how physics of an object and it’s children should be set up initially within the blueprint. If anyone runs into it, just turn all the settings upside down (initially on if you were starting with it off, etc) and it will probably correct itself like mine did. Just comment to this answer if a better explanation is needed.

I also suspect it’s mac specific or someone else would have run across it.

Since the topic is similar to my problem I’ll toss it in here. I am using blueprints only. My AI, when they spawn into thte game, are without a weapon, and get one spawned to them. When they die I do a DetachfromParent, setsimulkating physics and turn on collision of a sphere collision mesh attached to the weapon.
I want the weapon acting as a ammunition pick up and this functionality is fine.

What is wierd is that the weapon kinda flies around the map or even goes through walls…will speed up and slow down “at will” and I saw one even walk straight up a wall and just stop about halfway up. Its as if each weapon thats dropped on AI Death has a ghost of its own.

I have special collision “presets” or categories including AICollide, Weapons, Player. the collision sphere around the weapon meant to overlap Player (the rest is on ignore) works, i can get my ammo from it and its destroyed.

Previously the weapion would fall naturally to the ground. once i added that collision sphere it began acting strange. since the sphere4 ignore all but the players collision…this makes no sense.

also the pickup to get ammo did not function until i dragged the collision sphere onto the weapon mesh to parent it. at this point all this wierdity began.

Thanks for any insight or help!

I solved this problem finally.

In the set collision block I simply made it collide by query only.