So the player can remove items from the inventory. And the items will spawn in the world, close to the player. Some of these items are vital for the player to progress.
What if the item falls into a big hole, or it spawns behind a wall, where the player can’t reach? Are there any tried and true methods to prevent that?
Thanks.
Simplest thing you can do is to make a linetrace or boxtrace from the players camera forward. Then based what it hits and where for example:
- if it hits ground and it has space spawn
- if its too close or it doesn’t have space pick different spot you hit and keep checking
- if there is no space just print a message that there is no spot to drop an item
Also if you have nav mesh generated everywhere you can query it for closest walkable location near player.
And when spawning an item there are actor spawn parameters that can adjust you the location of spawn if it would be colliding with something.
For vital items i would consider blocking ability to drop it entirely but depending on your game design and structure you might want to handle it in some way.
Hopefully this answers your question
2 Likes
I think the safest thing to do is to use an Environment Query System that looks at all the options you want.
1 Like
Thanks.
But how would you check for space?
That means I would have to assign AI to all the items in the game, right? Is that efficient?
The character capsule component should prevent you from getting into too iffy of a place. The interact collision of the item should be centralized to the actor and mesh and large enough to cover most of the item. With all of these setup I trace from pelvis down for the spawn location. Haven’t run into an issue where I can’t pickup the item again.
Other option is to have UI interaction. Multi-Sphere trace around the player (1.5m from knee height) and list all hit pickup items in the UI. Then click and drag to pickup.
1 Like
EQS are AI-independent and can be used in any blueprint.
They simply generate a grid of points around any location you want or search for actors by class and tag, and then you can discard and score each one.
For example, here I use it to spawn enemies only in places the player can’t see or behind them, that have valid paths and aren’t near walls(space check).
You can also check the result in case it doesn’t find any points.
1 Like
I was using the item mesh itself for the interact collision. Do you mean you can have a separate component for that? And if so, what?
I’m trying to spawn the items in front of the player, mid air, and maybe give them a little push so they go down in an arc. They will have physics enabled. I’m not spawning them straight on the floor. Is a trace safe enough for that to ensure they don’t end up in an unreachable spot?
Thanks, can you share the Environment Query graph?
I use collision components (Box, Sphere, Capsule). The Mesh collision is disabled.
No. You need to do a robust sweep, possibly even use predict projectile path (advanced)
1 Like
You can fetch that data from mesh collision, have another component act as simpler collider, like @Rev0verDrive already mentioned or use bounds.
So for example if player is too close to wall either spawn it inside the player, behind him or prevent spawning it at all and display some message. If minimum distance is kept you can spawn the item in front of the camera and attach it to the player. For it to not going through the wall use CCD (continuous collision detection)
1 Like
But how do you simulate physics if the collision is disabled?
Thanks a lot. Can I ask you a semi related question? I’m using the 3rd person character mesh for the player character, and i want it to collide with the items physically. But the player gets affected by the item as well. Can I prevent that, so that only the items will be pushed aside by the player and not the reverse?
What about just adding Box Simplified Collision to the mesh in the mesh editor?
The issue with movement is caused by the item collision hitting the capsule component. Fix is to create a custom “PawnCapsule” collision in project settings. Then have your collision on items ignore “PawnCapsule”, but block Pawn.
That’s a Collision Hull. Collision components are an entirely different thing.
1 Like
Thanks a lot. So, what’s the difference? Only the Hit and Overlap events etc?
I have items on which I only need to simulate physics, and to hit by line trace. But also items on which I need to do all the above, plus run Overlap events on too.
Performance and proficiency in detecting trace hits and overlaps at high speeds.
Best test you could ever do to clarify this is to setup a projectile class (PMC) hitting a sheet plane.
Using a mesh as root you will not get consistent hits. Whereas using a collision component as root they’ll hit every time.
Collision radius 0.1cm
Muzzle velocity 600,000 cm/s ( 6 kilometers a sec)
Sheet plane: 100x100x0, single box collision hull.
1 Like
Just to clarify, do you mean you NEED to set them as root, or can they be anywhere in the hierarchy?
This is the way all movement components work.
In characters, CMC moves the capsule component which is what interacts with the world. No other component can actually block. They are ignored. The skeletal mesh and all other child components simply tag along.
The collision that will block, generate hits, must be the root component. Components that generate specialized overlaps should be children of the root.
Proper projectile is as shown (Collision, Visual, PMC)
The image “Bullet-Visual” is a mesh, but collision is disabled on it.
For all other Actors, those not using movement components, the hierarchy doesn’t really matter.
Semantics wise you’d have either a Scene, or the primary mesh as Root. Really depends on what you’re doing.
My pick up items use a Scene as root, then mesh (no collision), then collision component for interaction as a child of the mesh.
This is the same actor I used in the demo vid a few posts up.
1 Like