Thank you very much for this! It’s nice to see a system developed in both C++ and BP. Also your other tutorials are very informative. Please keep them coming!
No where that I can find is there an OnUsed function defined on the character. Or is that supposed to be from the item? Because I don’t get how it’s on the character’s event graph unless it’s a function of the character.
If it is a function on the character, what’s the definition?
If it’s the BP_UsableItem function OnUsed, how do you even add that to the character’s event graph? I can’t figure out any way to do it.
Edit: May I suggest putting the actual blueprints in with the tutorial content so that people can verify they’re doing stuff right?
It’s a function from the item. This is where the Context Sensitive option is critical. Make sure that is checked and drag a line from “Usable Actor” (<- Get Usable Actor node) and now you should find the correct nodes to call “On Used” on that item.
This is a bit confusing, I will see if I can make this more clear in the tutorial!
Edit: Also btw, I had a similar problem with getting the Cast To UsableItem node to show up. I think what happened was that when I had Context Sensitive checked, I wasn’t drilling down through the categories and looking close enough. I ended up promoting the hit actor to a variable and then dragging off that to get the node.
@Tom, I want to have a system with my items where unique properties are persistent, mostly to (at first) support being able to partially eat food rather than consuming it at-once.
The OnUsed function in UseableItem destroys the actor. I was wondering what your thoughts would be on passing it over in a more direct way to the player’s inventory without destroying it, or at least, preserving the parameters that are persistent.
I will of course be contributing back anything cool I build in terms of a persistent-item inventory system, as I feel that not enough games feature that sort of thing (i.e., if you use 2 rounds of a 10 round magazine, and drop it, and someone picks it up later they will find it has only 8 rounds, not 10).
Edit: Also as a tip for improvement of the tutorial I think it might be nice to have a blurb about BaseEyeHeight in this blueprint: http://i0.wp.com/www.tomlooman.com/wp-content/uploads/2014/06/getusableactor01.jpg because there’s not really anything about it. I personally just changed it to use the camera and such as that’s better for my needs, but it would improve the tutorial to have it mentioned so that people following along don’t get confused by it.
Edit again: Another observation is that you might want to put the gifs demonstrating how stuff works in a collapsible section so that after the reader is done looking at it, they can hide it away in order to better read the text.
I would look into using structs to pass blocks of information between items or consider datatables, last I heard they made a big improvement for accessing DataTable through Blueprint for upcoming 4.3 (available already on GitHub) I haven’t really dug into this type of feature yet, definitely interesting and something I’d like to look at in the future! Let me know if you made something cool with that!
Thanks, I’ll consider updating that part - it does indeed assume you’re doing a default FPS. Thanks!
I definitely agree this would be better. I should look for a 9gag-like plugin that allows me to stop/continue gifs. Thanks for your feedback on that!
Edit: Updated the site, GIFs no longer auto-play and support stop/continue! Much easier on the eyes.
I kept getting distracted by the (awesome and helpful - most tutorials don’t go that far!) gifs while reading the text.
I’ll see what I can do with datatables, should be fun.
Edit: Looks like I might have to backburner the persistent items until a bit later, since I’m trying to build as much gameplay as possible with blueprints before I dive into doing C++ (I am a C++ programmer, but I want to get familiar with blueprints and also avoid getting bogged down in C++ code to start with, and focus on getting core gameplay implemented).
Also btw, you can actually copy your blueprints and share them via plain text. So for things like the Cast To and such which can be annoying to have show up, it might be easiest to supply a text version of the nodes in the tutorial body (with a warning that they will error if the names of the class and stuff are wrong or whatever). Also nice to keep in mind that you can share nodes via pastebin in general.
In the tutorial, it says to assign the BP_UsableItem blueprint an asset with a collision volume and such. I set mine up with an empty static mesh in the base blueprint, with the plan to assign an asset to it in the child blueprints. Is that not how to do that? It doesn’t seem like you can edit the inherited objects in a child blueprint at all.
Edit: Well, I just ended up adding another static mesh with the asset I want in the child blueprint, and that works.
By the way, for those who might end up finishing the second part of the tutorial and become stumped by how to design a system for actually using your items, you’ll want to look into Blueprint Interfaces, and basically make a common Use interface for all the UsableInventoryItem (or whatever the name you use for items that are actually in the player’s inventory is).
@vblanco, awesome - I’m trying to stay in blueprint for now, so I’ll be using a blueprint interface myself, but I’m definitely going to reimplement into C++ later and will be using your tut then.
I have strayed away from Interfaces since I was not able to “Cast To” on an interface, therefor I had to cast to the lowest class implementation instead, kind of defeating the purpose of interfaces.
As for overriding the Static Mesh, I would recommend extending your base blueprint from StaticMeshActor so you can easily assign new meshes on your child blueprints. I’ll update the tutorial for that.
The copy blueprint text is a good idea. They easily corrupt though unless you make the exact names AND folder structure.
I just went to take a look, and its true, there is no “interface cast” node in Blueprint, but i saw that you can use the “Does Implement Interface” node to see if a object is Usable, and then just call its Use function if it IS usable.
Strange there is no InterfaceCast in blueprint.
Hm… I hope I can work around that somehow - I was hoping to not have to have specialized logic all sitting in the base UsableActor class. If not I guess I’ll have to just take the time and set up the C++ I need to do it right. Kind of weird that Interfaces don’t behave as you’d expect in BP, and there’s no real way to call child functions.
Might want to have a couple of pictures showing this step - I had to fiddle with it before I realized that I needed to be adding a variable rather than a component for the mesh variable to show up on the Defaults page of the child blueprints.
Yeah I think it’s mainly nice for those problem nodes, and/or making it a bit quicker to just get the nodes placed down. If all or most of the nodes are generic, the text pasting should be pretty useful, as it will probably just show error/warning in the BP editor for the jacked up nodes, and the user can just replace them. I guess I just want to make more people aware that they can also share their nodes via text in order to cut down on the time we all spend looking at images and switching back and forth to make sure they’re correct.
BTW @Tom, I’ve been working on my inventory system based on your tutorial, and have some improvements.
One bug I noticed though is that the tutorial doesn’t account for deleting InventoryActors when an item is dropped, so you end up with tons of them if you pickup/drop items over and over. Easy fix, though.