Hi,
I’m trying to spawn an actor into a volume that has ECC_Pawn response set to ECR_Block.
The pawn itself has ECR_Overlap on the volume’s object type.
I’ve checked the source code.
The function UWorld::EncroachingBlockingGeometry(AActor* TestActor, FVector TestLocation, FRotator TestRotation, FVector* ProposedAdjustment ) searches for:
bFoundBlockingHit = OverlapMultiByChannel(Overlaps, TestLocation, FQuat::Identity, BlockingChannel, FCollisionShape::MakeCapsule(FMath::Max(Capsule->GetScaledCapsuleRadius() - Epsilon, 0.1f), FMath::Max(Capsule->GetScaledCapsuleHalfHeight() - Epsilon, 0.1f)), Params);
By definition OverlapMultiByChannel(…) checks for overlaps. Here though the result is defined as a blocking hit.
Further down the road the function will not check whether or not the TestActor actually has his response set to ECR_Block.
In my case the actor which I want to spawn into the blocking volume has its response set to ECR_Overlap. But still I can’t spawn the actor into the blocking volume.
This goes against the definition that always the least will be valid (from ECR_Ignore being the least and ECR_Block the most): https://de45xmedrsdbp.cloudfront.net/blog/FilterTable-900x490-756106034.jpg .
Edit: This also happens for ECR_Ignore on the spawned pawn.
Hi ,
Would you be able to provide more information about how you are setting up both the blocking volume and pawn, as well as specifically how you are spawning the actor inside the blocking volume? I ran some tests and was unable to see an instance when the pawn was not successfully spawned.
This is what I did:
- Created a custom collision channel, then added a blocking volume to the scene and set the object type to use the custom channel.
- Changed the collision settings for the blocking volume to ignore everything except Pawn, which is blocked.
- Created a new Blueprint derived from Pawn.
- Added a StaticMeshComponent to the new Blueprint and set it as the root component.
- Set the collision settings for the StaticMeshComponent to ignore everything except the custom collision channel, which it was set to overlap, and set a static mesh for it to use.
- Added a key input node to the character Blueprint to spawn an instance of the new Pawn Blueprint inside the blocking volume.
- Started PIE and pressed the key to spawn the Pawn Blueprint instance.
The pawn was successfully spawned each time. What am I doing differently from what you are doing when the pawn does not spawn?
Does the pawn actually spawn at the desired location or is the location changed to find a place next to the blocking volume? Because
UWorld::EncroachingBlockingGeometry
looks for an “appropriate” adjustment when it is blocked and then the pawn might be spawned just next to the blocking volume on the shortest way. Or even below the volume (as my pawn once spawned below the ground).
Do you by any know why I can’t set default classes in my project settings for a C++ blank project? The options are greyed out. The Arrow button to set an asset from content doesn’t do anything either.
The pawn does spawn at the desired location. I have it set up so that it gets the location of the transform of the blocking volume (which is in the center of the volume) and spawns there. So when I spawn the pawn during PIE, it looks like this (that is the pawn in the image, not a projectile):
When I stop PIE, the outlines of the volume are shown and the center is seen where the pawn was located:
I also made a small change to have the pawn output a list of actors that it is overlapping, and the only actor it shows is the blocking volume.
With regards to your other question, creating a new Basic Code project gives you a very basic GameMode class that cannot be altered. If you make a new GameMode Blueprint, you can select this as your default GameMode, and then change the defaults for that GameMode.
Hey ,
thanks for your answer!
Here is what I did to reproduce it:
- Create new blank C++ Code project
- Blueprint of GameMode in Project Settings
- Create Blueprint of Character:
- Set Capsule collision to Overlap all, only block channel Vehicle
- Set my ground floor to be of collision object type Vehicle (for this matter… just to let the character stand)
- Create Blocking Volume and block Pawn (which should be Character’s capsule collision object type as well by default)
- Set my character blueprint to be used as default pawn (in project settings)
Now the pawn is spawned outside the blocking volume. The key code lines are in UWorld::SpawnActor(…)
AActor* Template = SpawnParameters.Template;
// Use class's default actor as a template.
if( !Template )
{
Template = Class->GetDefaultObject<AActor>();
}
check(Template!=NULL);
and
if( !SpawnParameters.bNoCollisionFail && Template->GetRootComponent() && Template->bCollideWhenPlacing && Template->GetRootComponent()->ShouldCollideWhenPlacing() )
{
// Try to find a spawn position
if ( !FindTeleportSpot(Template, NewLocation, NewRotation) )
{
UE_LOG(LogSpawn, Log, TEXT("SpawnActor failed because of collision at the spawn location [%s] for [%s]"), *NewLocation.ToString(), *Class->GetName() );
return NULL;
}
}
He needs to enter the FindTeleportSpot(…) command which he only does when the Template default object has a root component. The Pawn default object does not have that, therefore a Character object is needed.
I guess otherwise it won’t enter the function UWorld::EncroachingBlockingGeometry()
which I mentioned in the initial post of this report.
So, now even the character’s collision is set to overlap all channels except Vehicle and the blocking volume is set to collision preset Invisible Wall which blocks pawn channel: The Character’s overlap setting is ignored when spawning.
Just tested: You can even go as far as Ignoring all channel collisions of the character’s components. It still will not spawn into the blocking volume.
Thank you for the additional information. I believe I was able to reproduce what you described. I am trying to gather some additional information here to find out what may be happening here.
Hi ,
Sorry for the delay on this issue, it had slipped off my radar. I wanted to let you know that I have reproduced the issue that you described, and I have submitted a report of my observations to have this investigated further (UE-20980).
