Hi, is there a tutorial or something that i can follow using the fps template so i can replace a gun for a vacuum (like in slime rancher) that can pick up, store and spit objects?
Hi there,
I checked slime rancher (nice game). In that it does many things.
- Vacuum object to the gun.
- Hold it there
- Also push them (like leaf blower)
So there can be many parts that we could possibly need to implement. Starting with pulling objects into gun. A simple phsyics based grabbing objects is something like this
Something like this you are trying to do as simplified version I assume?
Explain details how it should work at its very basis, we help even there is no tutorial.
1 Like
Yes! That´s exactly what i´m looking for in the second video, first, a physics-based mechanic where you can pick up and drop objects from the enviroment and then a gun that can pick up, store and throw those objects as well.
Great Let’s do together. First things first, I won’t dump all information over here.
So lets do this like a designer does 
Let’s assume couple of things.
- This is a single player game, for now in order not to go in details with networking we can just assume our prototype is single player.
- Lets assume that we can pick any object, wheter its physics simulated or not. Still we have to distinguish what is pickable or not. We can just check a tag on objects like “Pickable” that would be enough. This way we don’t limit ourselves with phsyics simulated only.
- We know that we will collect them, and want to throw them later on. So a tag is good for distinguish but it won’t tell us what it is. We can use an interface or something else, we decide that later.
- Weapon (Pickup, Deploy), Inventory (GiveItem, RemoveItem) atleast let’s seperate systems a bit. For now we will focus on Weapon only.
- Weapon 2 inputs, lets make for now. RightClick Rules PickupSystem and LeftClick Rules ShootingSystem . Shooting will require what we have in inventory, can shoot that will require conditions, we will come to that. Lets purely focus for now on Pickup.
I opened a FirstPerson template new.
Opens like this there should be nothing.
In the content browser there should be something called BP_ShooterPickup drag that into the level.
When you put that into level on the details panel there should be weapon Type set that to granade launcher.
Window->WorldSettings–>GameMode set that to ShooterGameMode
When you play in editor you should be able to pick up like this
This game mode uses BP_ShooterCharacter which has many things already assigned, so we don’t have to worry about the pick, first person viewmodels etc. If you already have these or using a similar template its ok too just making sure covering every step.
Great now we have weapon and it shoots something (A Projectile) we will change those later. Lets focus on Vacuum part.
Under content browser variant shooter ->input actions there is some action. Copy paste IA shoot and name it IA Vacuum
Go to Input folder and open InputMappingContext IMC_Weapons,
open and + add one more map IA_Vacuum over there.
Go back to character and add input event to there IA_Vacuum
Add a validate get before prints so if we dont have weapon nothing can be triggered.
Make a sphere in level, check box simulate phsyics and add a tag, I added “Pickable”
Copy paste them around so we have some objects to test with.
In Character I made a sphere trace node, as start point we get camera location world.
As end location we get actor forward vector, normalize it, then multiply with a distance variaable. Created a vaariable as MaxVacuumDistance , give a number of your choice 500 add to camera location and set as end to trace.
So what we did is basically shoot a ray from the camera to the world, we will use this to detect objects that are pickable.
So after that we check if something is hit, then we break hit results and get actor check tag, if the actor has tag that we want. If so we promote this actor to a variable, CurrentVacuumCandidate
OnRelease button we set this aagain but empty.
Under it we get the tickevent and check if CurrentVacuumCandidate is valid. (convert to validate get right click) if there is something like this. we get its location and camera location and set the actors location on tick with VinterpTo. This will slowly pull this object to our camera.
At this stage it should be something like this.
Advanced the logic with a bool is VacuumInProgress and with a StartVacuumEvent, passed actor variable inside as Target which is the candidate.
What happens here is , first the object comes to camera , if reaches a certain distance (100) between camera and object then we get this candidate and StartVacuum, which we will, disable phsyics, collision and attach first to the Weapon on the socket “weapon_r_muzzle”. This will stop the object near camera attached to us in world. Now we can do a scale and movement to the muzzle of the weapon.
Made a timeline
I made a float track like this
On update we set actor location and scale from where it is to the weapons Muzzle location and scale it down like 0.3 . It gets smaller and closer to muzzle, after when the timeline finish we destroy this actor since we don’t need anymore and set VacuumInProgress = False.
As last stage there should be an event EventOnWeaponActivated in BP_ShooterCharacter. On that event do this
and change mesh reference to this
Now we visually atleast make a vacuum to weapon to a certain object. We will do more things here but later on, like add to inventory information and shoot them later if there is something in the inventory.
This is probably a very big information (I am assuming you are beginner) so I will let you do this much first, then come back. I will help if not me some else pretty sure will continue.
It should look something like this as end results and let us know if you get stuck, have a specific question or you achieve till this stage. Also we can modify things if doesn’t fits into your vision, you want a spesific behaviour on vacuum
1 Like
Wow, first, thanks a lot for the fast reply, i really appreciate it.
Meanwhile, i´ve been checking a couple of tutorials for the physics system and i found a really good one from game devs journey (https://youtu.be/P-c0NUZm0l0?si=_wsym09D61Zqsnf_). I followed it step by step and i already achieved a mechanic wehere i can pick up and throw objects (i wants this to always be an option for the game, so the user can always pick thing up by hand.
And yes, you are correct. 1. Yes, its a single player game (i don´t want to deal with multiplayer stuff right now) 2.- Yes, in the game i want to have “grabbable” and “non-grabbable” objects. 3.- Nice, i was about to mention implementing an inventory system, but it should be something for later on. 4.- I like the option for “picking up” the vacuum, it was not my first option design-wise to create some sort of progression, but i can work with it haha, np. 5.- Yes, those inputs for the vacuum are perfect.
Now, as i mentioned before, using the “prototype” that i achieved with the help of the video, what do you recommend? To keep using this same template or start a new one?. This is because, i was checking the images that you uploaded, my project doesn´t have (or i can´t seem to find) the “BP_ShooterPickup actor.
That’s great!
You can use any template you like, without any template you can implement anything. That template should also have a weapon etc. The reason we use templates is to shortcut ground work.
So with physics handle you did, that is great. Also you should know that there are some differences in Physics Grab vs Kinematic Movement way I show you. There are no winners between them just trade offs and approach.
- With Physics Handle : Object we grab have to be simulated. That means we can not grab objects without simulation. While grabbing object to ourselves it still interacts with world. We can fundamentally grab non simulated objects by filtering them with tag then simulating them and grabbing. This means during grabbing we have to modify them and if player cancels we have to run a deferred scripts that waits for it to reach ground ->stop-> sleep → put simulation off state. Why ? Cause : We don’t want objects stay in mid air after grab to maintain their states.
- We can choose a path to grab only physics simulated objects. But what about the non simulated ones? Like a character, when / if we want to grab them we have to do the same. Which is ok but its a choice.
- This one you show a bit works like a gravity gun, half life or other gamas. Not exactly like a vacuum gun. In my model, you grab->but you can cancel mid air and it will drop, we didn’t do that part yet. After reaching a certain distance now its point of no return and its sucked into gun->inventory. These are choices ofc, we can directly pull into gun without cancel method. Is this bad? not really its just there is no space for error, depends on the game needs and what you want to achieve.
So choice is a bit around 1st do you want physics simulated objects only or anything that has a tag?
Which way you want to go, we can go that way.
1 Like
Hello!
So, by your reply about the system that i´ve already made what i understand is that i chave to choose which elements are able to interact (grab, move and vacuum) if they are physics symulated or they have a tag?
If so, i think the better option is to assign them with a tag, so i can have a little more freedom to add objects that are “only grabbable” and others that are “only suckable”.
I think the use of labels on the objects could be a really handy choice for future uses on this project, now i can even design some objects that have both tags so the player can grab or suck them with the vacuum.
Now, talking about the vacuum “gun”, based on your design, rewatching the video i noticed that every time you activate it, it creates a cone that detects the object, but i want to kow, what happens if you keep pressing the button to suck the objects? and What happens if you move while pressing it? Does it creates a ton of “cones” that can lead to the game slowing down or not?
And one last thing, although i´m not sure if you can help me with this, but with the tutorial that i followed, when you grab an object and it collides with something else (grabbable object or enviroment) it fully stops (i think it is because the symulated physics stop when detecting collission with anything else), but i would like for it to try to “follow” more closely the player and even be able to push or pull other grabbable items. Do you think it would be too difficult to correct?
So in the one that I made its not super different. Yes you can use tags to distinguish from what is pickable or not.
Additionaly If you try picking up something not simulated it wont work however you can set simulated then pickup. Basically you can detect object type and do necessary changes before grabbing.
In my proto it doesn’t cares if its simulated or not. However if its not simulated we could require to do some logic not to leave objects mid air or make vacuum one shot. I am already pressing button (hold) and that cone is just trace 1 frame to detect objects . It’s debug view which can be closed. I put a video below to show how it behaves atm. During vacuum if player releases we cancel vacuum however as rule if it reaches the player a certain distance, we stop object infront attach to player, then move the location and scale to muzzle of the gun so it give this vacuum effect.Can be different ofc. Can be once you click it just get smaller and closer to weapon and its sucked in, there is no cancel, these are all gameplay behaviour choices.
About your questions : object and it collides with something else (grabbable object or enviroment) it fully stops : Well it should be since there is collision, having no collision at that moment means that it can go inside walls etc. So it kinda makes sense to have collisions. What you can do ? You can simply get item closer to player after that
If you want to go one step further. After you grab object comes to player location, you set it attached to player, set collisions none. If player releases it then you detach, set collision again and set simulation back.
I quickly demonstrated a video below between a physics grab and a kinematic vacuum. Blue pawn is not simulated notice we can grab that in first video. Also notice if i cancel grab mid air how it stays in empty space mid air. So these demonstrates the design and use cases of what behaviour it results of choices. In every scenerario there are trade offs either you grab with phsyics or kinematic pretty much everything can be done in terms of behaviour
I put a simple demo how to get object close to you with physics handle.
1 Like
Thanks a lot for the response.
First of all, i apologize in advance, english is not my first language so i might not fully understand the intent of some parts of your replies. So, for us to be on the same page i just wanna ask for your advice to achieve what i have in mind, that is for the player to be able to pick stuff up and throw by hand and also, being able to get a vacuum gun to suck and throw those objects (while being able to determine which are pickable, suckable or both using tags).
So, what do you recommend, to start a new project from the start and use your instructions to achieve those two mechanics or should i keep using what i have made and add your vacuum mechanic (tbh, i don´t mind starting from scratch, it didn´t took me that much time, it was a short tutorial)?
No worries, fair enough.
You can just use your already existing setup and introduce something like
So you can get objects closer. Replicate this first then lets talk.
Then we put more logic in it and check tags. we introduce a method also after you pick, throw or suck (put into inventory).
You already can grab so try getting them closer to player after pickup.
1 Like
Hi, so i´ve been replicating the blueprint on the BP_FirstpersonCharacter Event graph and i´ve made it this far.
But i´m noticing that you have a component called “Physics Handle”, how or where do i create it?
And about the lower part of the last blueprint that you sent, are you suggesting that i should modify the one that i have to yours so the object gets closer to the character when it collides with another object?
This is the part of my blueprint that (if i´m not wrong) handles the grabbing action.
On the left
Add + and search for PhysicsHandle and add to your pawn. (which feels like your HoldComponent),
You can modify that one too yes on the tick, let’s just get your object close to you as much as possible.
On your old script
this part was defining how far it should be away from the camera.
It’s the same in my scripts
Only the below is wrong.
Whatever its not important just add the PhysicsHandle
and try replicating exaclty. So we can be in sync of what we talk next.
1 Like
Ok, so now i created the physics handle component and managed to copy the blueprints.
They look like this.
But, in the tutorial i saw, there´s this piece of the blueprint.
And it calls for a couple of functions (traceforgrabbable and releaseobject) Are we going to re-do them, use them or not use them at all? (whichever way is ok for me).
Also, i was thinking that maybe it could be better for us to stay on the same page if i just create a new project (using the fps template) and i do as you say so we can have the same thing. What do you recommend?
We already do trace and release with our terms so you don’t have to worry about it.
Did you test, is it fine for now grabbing and releasing objects with new scripts? Looks similar to what I demonstrated in videos?
1 Like
Yes, i´ve been testing, but now i can´t even pick things up normally.
Its ok
Make your
something like 20
Also make sure your input is setup like this (there is press and release)
You before tutorial probably another shortcut tutorial so forget about that , delete related logic if still there is. Try again and it should work.
After you make it work, here is one step further I will just re organise it first.
1- Making Detect Object Function
Select these and collapse to function
Name as TraceObjects
Go inside function and tidy it up. What it does, it make a trace and if some object is hit it returns its detail as “OutHit” if nothing is hit then OutHit will return nothing.
2- Making a CanGrab checker
Select these and collapse to macro not function
Name it CanGrab
Go inside and organise.
So whaat it happens, we check object make a trace, then we check if CanGrab → if we should grab this object? first if actor exists, then checks tag, checks simulation, checks if we are holding something or not.
Your graph should become more organised like this.
3- Making ExecuteGrab function.
Lets make a function that can execute both grabbing and dropping (relese)
Select these and convert to function
Go in and organise, Make a new branch and set a bool GrabOn
So when GrabOn=True we try grab object and when GrabOn=False we try release object if any.
You can delete / rename/ add inputs selecting execute node , probably you did before. Reminding just in case.
In the EventGraph lets organise again since we change pins etc. You can delete old pins
Graph becomes this
For the tick what it does is basically
So these are actually , to warmup you with basic scripting, using tools available in scripting, introducing you to some logic. If you think they are doing the same thing however now we are more structured.
Why this is important, its important to stay tidy, unorganised things in code cause problems , more bugs, hard time for your collegues in the future or now, worser performance and so on. The first one I demonstrated wasn’t “unorganised”, its just a technique I use to flatten the hierarchy so it becomes more trackable for beginners aand explaining to others generally etc. not because I don’t like functions
So I won’t introduce something new at this stage. Try to come to this stage first, then we will do Throwing.
Use case to do next :
“As a player, when I grab objects without a weapon, I would like to be able to throw them to the direction i am looking with force”
1 Like