Interactive hybrid is on the way out, I don’t think the penetration issues with it are actually solvable and the standard physics grip is better overall.
That being said I should either fix it or remove it entirely so i’ll go over it again tomorrow and make a choice. Its strange that you are not having the physics constraint getting removed though, I have a debug flag that auto triggers when there are more physics handles than actual grips so it is at the very least going through with the destruction code.
I’ll take a look, I did some revisions recently to that grip type.
What are you packaging it for in shipping? A non windows platform? It packages to win32 and win64 bit shipping fine for me and force inline shouldn’t have issues.
: Win64 Shipping. It should also be noted that I’m using an older version, the version right before the split of the Steam and NoSteam version of the plugin, haven’t upgraded yet as project is already a ways in. So may be a non-issue on the current build. And on the build I was using it was only an issue when trying to compile as Shipping. I’m primarily adding the info to help anyone else who runs into that problem.
The main thing that was odd about it is that it compiled fine in Development Editor. Compiling it as Shipping or as Development (without Editor) I got the errors I posted in the original post. And then afterwards I noticed they were what looked like linker issues and FORCED INLINE.
You don’t have any replication steps do you? I can’t duplicate or the continued rotation after destroying. I ran a break point and the destroying function never fails during hybrid and I am not getting duplicate overlaps, just the normal character intersection overlap spam that the engine throws.
Can you PM or link in here the compilation warnings if you add forced inline back in? I didn’t have shipping issues in previous versions either, but if its system specific I may need to inline them instead of FORCEINLINE to give the compiler a choice.
I tested only in full Authority mode
I get an Overlaping, but not for actor himself(gripped Actor->RootComponent), but for the child to RootComponent(for AGrippableStaticMeshActor Root is UStaticMeshComponent) I create a simple UBoxComponent(Attach for RootComponent(UStaticMeshComponent)) and set for component OnBeginOverlap function( I try to overlap UCapsuleComponent) . is only noticeable if you use VR controller, rather than keyboard simulation of hand, Since here it is important to move apart and a slight turn(the motion controller’s hand is always slightly rotated when moved). You get a lot of intersections, even when the object is already Overlaped… All intersection objects are valid and true, but it creates the feeling that there are many copies of the object In slightly different places, very closely spaced copies
void UVRMotionController::WeaponHitEvent(UPrimitiveComponent* OverlappedComp, AActor* OtherActor, UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult)
{
if (OtherActor && OtherComp)
{
if(OtherActor->IsA(AEnemyCharacterBase::StaticClass()))
{
So Many Overlapp here, even we Already overlapped
.....
I’m using the child(UBoxComponent ) element(not Root), because I need different type of intersections(different parts of the Actor)
and for different type of enemy component
I moved forward in solving problem, the fault was setSimPhys(false for default -> set true(when colliding) - then false = Here the problems begin, before first “true-false” all are okey!), not for u functions DestroyPhysicsHandle
Wow, i finally Solved the problem. The problem is actually very important, who will use many components of the collision and switching Phys Simulating
1)When we use SetSimPhys(true) for Root Component in BodyInsrance.cpp
void FBodyInstance::SetInstanceSimulatePhysics(bool bSimulate, bool bMaintainPhysicsBlending)
{
.....
// If we are enabling simulation, and we are the root body of our component, we detach the component
if (OwnerComponentInst && OwnerComponentInst->IsRegistered() && OwnerComponentInst->GetBodyInstance() == )
{
if (OwnerComponentInst->GetAttachParent())
{
OwnerComponentInst->DetachFromComponent(FDetachmentTransformRules::KeepWorldTransform);
}
if (bSimulatePhysics == false) //if we're switching from kinematic to simulated
{
ApplyWeldOnChildren(); //THISS !!!
}
}
void FBodyInstance::ApplyWeldOnChildren()
{
.... Browse all the children
const ECollisionEnabled::Type ChildCollision = ChildBI->GetCollisionEnabled();
if(ChildCollision == ECollisionEnabled::PhysicsOnly || ChildCollision == ECollisionEnabled::QueryAndPhysics)
{
if(UPrimitiveComponent* PrimOwnerComponent = ChildBI->OwnerComponent.Get())
{
Weld(ChildBI, PrimOwnerComponent->GetSocketTransform(ChildrenLabels[ChildIdx]));
}
}
2)And If U use ChildCollision == ECollisionEnabled::PhysicsOnly || ChildCollision == ECollisionEnabled::QueryAndPhysics type collision of u childComponent
function makes all child bodies => IsValidBodyInstance() = false(kill our PxRigidActor)
creates major problems in the Overlap Events for child Component
4)To solve problem need to set the ChildComponent->BodyInstance.SetCollisionEnabled(ECollisionEnabled::NoCollision, true);
For all Child who used ECollisionEnabled::PhysicsOnly Or ECollisionEnabled::QueryAndPhysics
Before SetSimPhys(true) On RootComponent in InteractiveHybridCollisionWithSweep type, or maybe From other places Where you want to enable Root simulation Or we cant use OnComponentBeginOverlapp for child Component normally
5)When we again SetSimPhys(false) on Root Component You need to return the old collision settings
ChildComponent->BodyInstance.SetCollisionEnabled(ECollisionEnabled::QueryAndPhysics, true); For all child Component Who had it before
Oh so you are talking about attached children to a simulating component throwing bad overlap events?
I gather that you are talking about turning off collision on all sub components prior to simulation, something that I don’t think I should do by default in the plugin as it may break intended behavior for other users.
What you are talking about is how the engine behaves in general, you are getting overlaps between children components when simulation is active correct?
I’m sorry your english is a little rough, its been hard to read over your posts, but I really do appreciate detailed feedback.
Yes, my English is not very good. But i try to explain. I Want to say When set RootComponent->SetSimPhys(true) All Child of RootComponent get IsValidBodyInstance() = false(invalid bodies) becose all child bodies Are welding to the root and make Trouble in the definition of a collision Event These children Component when we turn off SetSimPhys .
I agree that it maybe not be inserted into the plugin, but as a special case, it is possible for someone to use it.
I found another way to overcome , just when we turn off RootComponent->SetSimPhys(false) use:
For all children ->
FBodyInstance *NewRootBI = &ChildOfRootComponent->BodyInstance;
//create new root
root->BodyInstance.UnWeld(NewRootBI); //don't bother fixing up shapes if RootComponent is about to be deleted
NewRootBI->bWelded = false;
FPlatformAtomics::InterlockedExchangePtr((void**)&NewRootBI->WeldParent, nullptr);
bool bHasBodySetup = ChildOfRootComponent->GetBodySetup() != nullptr;
//if BodyInstance hasn't already been created we need to initialize it
if (bHasBodySetup && NewRootBI->IsValidBodyInstance() == false)
{
bool bPrevAutoWeld = NewRootBI->bAutoWeld;
NewRootBI->bAutoWeld = false;
NewRootBI->InitBody(ChildOfRootComponent->GetBodySetup(), ChildOfRootComponent->GetComponentToWorld(), ChildOfRootComponent,
GetWorld()->GetPhysicsScene());
NewRootBI->bAutoWeld = bPrevAutoWeld;
}
Just Unweld and Init Body Again
We CANT use ChildOfRootComponent->UnWeldFromParent();
Because NewRootBI->bWelded always = false, and UnWeldFromParent() not worked …it is bug or not… but bWelded dont set = true when welding component in SetSimPhys
may be i report problem(bWelded and UnWeldFromParent()) later
Some time ago I could easily build the template project, after downloading today though, there’s no way I can actually get the template run in any scenario.
I have another plugin of mine that I packaged into the template to handle voice and sessions. You will have to delete the voice nodes on the character to get it compiled without that plugin.
Spoke with him on Discord, was using wrong engine version
Thanks, just out of curiosity how easy would be to slap into a project originally meant for an fps? Also I found the plugin and added it to my own project. Is that ok or is that not open source?
Also adding it to a FPS wouldn’t be that difficult, you would just have to handle AI, UI, and level layouts that may need tweaking for VR. And pacing of course.
Thanks! Pacing isn’t a concern. I’ll dial back if I have too, but I’m throwing the player to the wolves as far as difficulty. I"m trying to merge project with the multiplayer survival game template.
The bit with the server work you’ve got hooked up in here. Is that as optimized as you can get it? It’s fairly sluggish. What might I need to add to an existing multiplayer system for it to be optimal for vr?
You mean server finding? If you are testing it in LAN it is using a lan beacon which is slow to find servers, steam is faster to search generally.
That being said steam waits for all servers to return before displaying results, most companies start filling in lists as each chunk arrives instead, but its not my code, its epics subsystem backend handling it, I just interface with it.
Hi . I’ve got a StaticMeshGrippable actor with a Child Actor Component. I’ve noticed a subtle problem in that the mass of the child actor seems to affect the gripped object (seems to make it heavier/grip softer) even with the child actor not set to simulate.
Is it possible there is a bug or info that I need to know about on how your plugin handles child actors of the gripped actor? It’s likely not a bug just my poor understanding on what is actually going on but I’ve eliminated some obvious things I thought it could be with no effect and thought I’d ask.
I’m not welding physics bodies unless I misunderstand. I have a GrippableStaticMesh actor which has greyed-out SimulatePhysics and MassInKg boxes. I can grip just fine with Interactive Collision with Physics & Late updates always off.
If I add BP_Box as a child actor that weighs 100Kg to the grippable actor but with Simulate false on the child actor I am expecting the 100Kg not to contribute to the mass of the gripped object. I.e. just act as another collision primitive. Is there any way I can setup behaviour?
Child components auto weld to their parents, you need to turn that off in the settings if you don’t want it to effect weight (uncheck auto weld in the component/actor).
