So I’m trying to build a simple prototype combat system to learn how to use UE4 and get a couple of ideas out of my head and into the real world. Eventually it will be this:
The idea would be to have the player character locked to those tiles and have button presses move between those tiles precisely. So far I’ve managed to detach the player’s view from the character, build an array of those tiles to reference and find the position of the guy, and set up a button press system to move him between those points on the array.
When I try and hook that into a timeline and lerp setup he drifts to an arbitrary point in space rather than move to the next point in the array.
My worry at this point is that I might be trying to implement a system that’s intended for 3D space or a player character when something else would be more correct and effective. Is a lerp even the right idea for what I’m trying to do?
Here’s what I had built that was functional before I started hacking in the timeline/lerp nodes:
Hey there Stinkhorse. Great name! I also really love the way you arrange your nodes, it’s very pleasing to look at. Compact and legible.
Ok, here’s the nitty-gritty. First, you should probably move your logic out of your Level Blueprint and into your Player Character’s blueprint. This is because Level blueprints can’t communicate through interfaces, can’t turn off their ticks, or ever be culled. It’s more performant to split up your functionality across specialized instanced Blueprints because you can turn off Ticks when you don’t need them.
Lerping Timelines are a great way to go. I don’t know how you had them set up before, but the general idea is to have a timeline that iterates from 0 to 1 over 1 second, then you divide the return value of that by the number of seconds you want the motion to take (so you don’t have to have multiple timelines, just one that does it all) and plug that into the alpha on your Lerp function. Depending on wher your Camera is, you’ll want to cancel out one plane of motion. Generally in 2D, this means the X vector. Just make sure X is 0 (if your camera is facing down the X vector) and Y and Z can be whatever you want.
For your A and B on the lerp, you’ll want to take your player’s position before playing the timeline for A, not his current position because that will keep moving the goalposts for the Lerp. B would be the final destination. Then just call “Set Actor Location” every Update from the Timeline and you should be golden.
Alternatively you can use iTween (free, in signature) to handle this motion for you, where you just tell it what you’re moving, from where (current location) and to where (final destination) and how many seconds it should take with an optional easing equation to smooth out the motion and that’s it.
If you’re still having problems, if you can post a screenshot of the current problematic Blueprint or even better take a video of the action, I can better help.
Hoooo boy. I am a four year old with a power drill and a boat hull, I swear to god.
I turned my sprite player character into a class blueprint, transferred over all the scripts, and rebuilt the associated variables locally. I also did the same for the tile object, turning it into a class, and then instanced it across the level believing that it would make it easier to reference to create an array. It’s around this point that things started going really sideways. I attempted to get an array of the tiles based on their tags (which was conveniently set to ‘tile’) inside the player character’s class blueprint, and while that didn’t spit back an error it clearly didn’t work because nothing happened on button press. So I figured that the tags simply aren’t reading, but I didn’t know how to be sure of that without checking to make sure the script itself worked, so I decoupled all the dynamic array stuff and tried to rebuild it by hand with sprite actor references. At this point I realized I can’t reference the tiles, either as a blueprint class or components or their base assets. I can’t create reference the player character asset in it’s own blueprint. I’ve attempted to remake the array using most of the methods I’ve been able to look up and nothing seems to be working. I have a node that seems to reference things but then it tells me it has no reference on compile.
I don’t know where or when my tile array should be built, or at this point even how to. I don’t know how to get my classes to talk to one another and half of them have been deleted in an attempt to regain access to dropping sprite references into my blueprints. I’m getting pretty close to scuttling this whole dumb thing and rebuilding it from scratch but that’s honestly not going to help me learn anything in the long run.
I’d throw up some screen shots but honestly very little has changed other than it’s all parted out into class blueprints that refuse to talk to one another.
Any help would be REALLY appreciated at this point.
Ok! A lot going on here. Let me just throw some pointers at you.
-You can reference the player character in its own blueprint by searching “this” or “self” in the context browser.
-There’s a node called “Get All Actors of Class” that will return an array of actors of the specified class. You can get the tiles and then plug the return value into a local array. No tags needed! After getting the array, you may want to run a foreach loop on it that gets teh display name of each tile and prints it so you know your array is good.
What base class are you using for your player? Pawn, Actor, Character? If you’re using Actor, reparent (File->Reparent blueprint) the character blueprint to use Pawn or Character since they’re built to take input. In the class defaults, make sure it’s listening for input from Player 0 and NOT blocking input.
Man thank you so much for the help ! I’m one of those people who learns best by dialogue, so even these few replies have gotten me ahead of what would have been weeks of bumping into answers in the dark.
I’ll be able to sit down Teusday evening and try some of this stuff out so I’ll let you know then, in the meantime here’s an image from the wiki that shows a likely example of what I was misunderstanding:
That node that has both “target” and “sparks” looks like what I was attempting to use to call something from another blueprint. When I moused over the “target+thing” node it pulled up a tooltip that contained the location of the blueprint that the information was being pulled from, and it’s target was labeled “self”, so I thought I should leave it alone as it logically (to me; an idiot) was already referring to the blueprint it was pulling from. I also didn’t know at that point that you could turn other blueprints into variables to reference as targets, so that’ll probably be my first attempt at a fix.
As for the character, it’s a pawn currently, but the camera isn’t focused on it and player controller aren’t being cast to it. He was moving without the addition of a player controller, but I’m guessing that was because his controls were in the level blueprint itself? If that’s the case, and he does needs some sort of player controller, how do I keep the camera detached from his movement? I eventually want the camera to be independent of the player, but casually rubberbanded to an average between his position and that of the single enemy he’ll be fighting.
The actors of class should be doable now that I know how to create variable references to other objects. I kept trying to find the class using the drop down menu under the purple pin, and then using the tag option to filter, but that obviously wasn’t working correctly.
Honestly looking back over yesterday I’ve got a lot to feel accomplished about. I’m getting comfortable creating referenceable blueprint classes and instancing them as objects now, busting out a variable isn’t the big concern it used to be, and before I caught your post I was in the process of repurposing the constructor script from the content example levels to dynamically build out the stage based on an integer. And lastly, thanks to your help I’m right on the cusp of understanding how to get blueprints to talk to one another, which is going to be super powerful going forward!
I also checked out your plug in, and it’s definitely going into my toolbox, but I think I’d like to learn how to do it the long way around first just so I have the general concepts down. Important bits like referencing a single curve and altering it with some math on the spot are just things that I wouldn’t have thought of, but clearly leverage the engine’s strengths. That sort of thing.
Once again, huge thanks, and if anything I’ve got up there sounds suspicious or alarming, let me know and I’ll correct my implementation to match!
Sounds like you’re getting a handle on it, that’s great!
The only thing I can pick out of your post for now that I wanna touch upon is the Player Controller. Unreal unfortunately has a lot of esoteric concepts that aren’t made readily apparent what their use is. Let me try to run it down for you.
Game Instance - an object that is persistent throughout the life of the game; that is to say that it is never destroyed until the game is quit, unlike other pieces I’ll touch on. Generally this is used to hold together multiplayer games as the maps load and things of that nature. I like to use it in single-player games for variables that I’ll always need to see so I don’t have to keep loading and saving to a SaveGame object. I also like to put a StateMachine enum variable in here that shows what “state” the game is in, i.e. Main Menu, cutscene, in game, etc.
Game Mode - An object that acts as the master of the current level’s Player Controller, Player Pawn, Game State, Player State, etc. The docs say this is used for the “rules” of the game, but I use it to spawn objects and hold references to my important objects so if I need my player, I just get my Game Mode and Get my Player Pawn reference variable.
Player Controller - is generally used to receive input then send instructions from that input to an appropriate pawn. This is completely optional to use, but is a good idea to use if you want to use the Player Camera Manager (which I honestly never have) or switch pawns during gameplay (which I do with some frequency).
Pawn - you can put all of the input logic on this if you’d like. Some games work that way just as well. I personally recommend splitting input between the PC listening for instructions and sending a message to the pawn to carry out those instructions. For example, the PC hears the player tilt the thumbstick. It says, okay, if input is enabled and we’re using the human pawn, we’ll send a message to the human pawn to move forward. If we’re using the turret pawn, we’ll send a message to the turret to rotate upward. Again, you can just put the input on the pawn if you want, the PC just makes it easier to manage multiple pawns and share variables.
Game State - this is used for networking as I understand it, and I’ve not had much experience with Unreal’s online infrastructure yet so I don’t have much to share. Sorry!
Player State - If I understand correctly, this shares some info from the Game State but is used locally on each client in a networked game. Again, no experience here
So right now it looks like you have a camera actor in the scene that is independent of the pawn anyway. If you’re calling Set Target View with Blend or whatever it’s called when the game starts, you’re overriding the Player Camera Manager’s auto-camera already, so you’re golden whether you decide to use a Player Controller or not. Then it’s just a matter of moving the camera appropriately when you need to which can be one with a boolean, VInterp or iTween, and an event to fire off that camera change event.
YES! All of that info is exactly what I’ve been needing! I’ve been casting around for a notion of a global variable, and it looks like it’s the location that it’s built in that really decides that rather than it being an enshrined concept in it’s own right.
I’m going to use what little free time I have this evening to get the class blueprints rebuilt and look into a quick test bed for casting an input. On that note, the descriptions describing casting are a little unclear and I’m not super certain if a cast node:
A) Sends information to the named blueprint where a listening node needs to be set up to catch it
or
B) Reaches out to make a link with another blueprint and then creates a conduit to it allowing further nodes to make and set variables that exist in that now linked blueprint.
Global variables don’t really exist in Blueprints, but there are global objects that can hold variables. Your Game Instance is great for that, but your Game Mode can work too if you’re fine with saving and loading those variables to and from a Save Game object throughout the game rather than just at the beginning.
As far as casting goes, some object references will be of a more base class (like actor) but you need a child class’ stuff (like character’s movement component).
So say you have a box that checks for collisions with other actors. When a collision happens, it’ll fire off an event and give you a reference to the “other actor” that collided with it.
While Character inherits from Pawn which inherits from Actor (I assume you know about class inheritance as a programming concept), not all Actors are Characters or Pawns. Likewise, your custom Hero class that inherits from Character is a Character, Pawn, and Actor, but not every Actor is a Hero.
So you’d cast this other actor to a Hero blueprint. The impure Cast node (the one with execution pins) will ask the other actor if it is a Hero, and if it is the node will treat the other actor as a Hero (with all of its specific variables and functions) instead of as just an Actor (which doesn’t have any of the functions or variables of Pawn, Character, or Hero).
In this case, let’s say you want your Hero to be damaged when he enters a box volume. Your Hero has a custom function called “ApplyDamage()” on it that will decrease his health when it’s called. The box will check for collisions every frame, and every time it senses a collision it will fire off its collision event. It will pass the actor that it collided with as well, so on that event you would cast that other actor to a Hero. If the cast is successful, then that means your box collided with the Hero and you can drag out from the cast node “As Hero” and call ApplyDamage() from that.
I spent a few years in game development as a designer, enough to pick up some terminology, but never enough to be trusted with anything significantly dangerous. I’m basically leaning on every overheard conversation from that time as hard as I can, so while I might be able to leap to what you’re saying before I finish reading a paragraph it would safer to presume I’m just as entry level as every other schlub that picked up a free editor.
While I wasn’t able to get everything to work, I did get my class blueprints rebuilt and a few scripts moved from their previous homes. Here’s what I built tonight. None of it seems to work, but on the bright side it compiles again.
Player Controller Blueprint
That print screen script is so not even slightly the way it’s supposed to be, but I couldn’t find anything that broke down how to pull and convert information from an array for display, so it was all guess work.
Oh, and I’ve run into an issue where sometimes an array’s output wont plug into a node of a given type, but if I delete the various objects and recreate them, suddenly everything plugs in, fine and dandy.
It’s got me working on a solid “four lights” twitch.
Alrighty, let’s break it down per blueprint. I’ve got a few questions on each and a few edits on each! I’m gonna critique you like I critique my students because that’s the only way I know how, so I hope I don’t come across as condescending or insulting. Without further ado, let’s do it.
Level BP - Why do you set the player character’s location to be the player character’s current location? I mean, on Event Begin Play it really won’t hurt anything but I’m curious if there’s something I’m missing as this doesn’t really do anything to change the game. Additionally, what do you use the “Delta Seconds” float variable for? Do you have any other logic on your level bp? If not, you can delete that portion of the blueprint since the variable will only be visible by the level bp itself and it’s doing this every Tick, so you’re throwing unnecessary overhead into the works. The only thing I’d keep personally is the Set View Target with Blend node because it’s easier to reference a Camera Actor from the level bp but even then it could easily be done in the Player Controller. As you can tell I’m not a fan of level blueprints
(Side note on level blueprints, when I first started with Unreal I used the level bp a lot too. It worked out great for a while until of course I wanted to change maps. Then I either had to recreate all of the variables in the new level bp because copy and paste only copies the nodes, not any variables or functions, or move everything out of the level bp and into a class blueprint. Now I just avoid the level bp whenever possible and use it only for temporary stuff like spawning a widget or something until I have all of my ducks in a row. Perhaps I’m just a jilted ex-boyfriend about them but I’d strongly recommend against using them. /rant)
Player Controller - So the reason your foreach loop isn’t working here is because the loop only keeps the object in memory during the loop body. When it’s completed, it doesn’t pass an array element. Every UObject (the base class from which all actors and Widgets inherit from) has a function called “Get Display Name.” What you’d want to do is execute print string every loop body and Get Display Name from the array element, plugging the return value from that into the print string node.
Debtor BP Begin Play - Like your level bp, you’re setting your pawn’s position to be its current position. There may be a reason for this, but I just don’t know. Instead of using the variable you created for “debtor” you can just use “Get a reference to self” to ensure that you’ll always be referencing the debtor and won’t end up with a broken reference. I say this because there doesn’t seem to be anywhere that you tell the engine what the debtor is. Lastly, you make a Current Tile Array twice, once in the Player Controller and once here. You only really need one and you can reference it from the other blueprint. It probably won’t hurt performance much to have two arrays with the same information, but it does take up unnecessary memory. I think the pawn works better than the player controller for that since the Player Controller never references the current tile while the pawn references it a lot, so you can save yourself the overhead of Get Player Controller->Cast to My Player Controller->Get Current Tile Array.
I would have begin play be like this (this pic is missing the part where you populate the current tile array; this should come after that):
Just set the tile index you want to start with (which this assumes to be 2 on every level) then set your debtor’s location to be the location of the tile plus your pawn’s Z box extent. The box extent is the distance from the center of the actor to the very top of it, or its half-height. You can open up structs (a vector is a struct of three floats) by right-clicking on a struct pin and choosing “Split Struct Pin.” I do it this way in case you ever need to change your pawn in the future. It may never happen, but it’s better to be prepared for any contingency, in my opinion.
Debtor Press Right - Unless you will have no more than 7 tiles in any given scene, you should make the branch check more like this:
So now it will check how many tiles there are in the scene, subtract 1 (because arrays are 0-based) and will only then move if the current index is less than the last index.
You can also use the “Last Index” property on the array which is the same as Length - 1, I just didn’t think of it when I took the screenshot. It isn’t a thing in most programming languages, it’s just a nice blueprint feature.
Debtor Press Left - This looks great! The only thing that jumps out at me is that you’re setting the current tile index to be itself +1 every time the Timeline updates, so depending on your frame rate you could end up with a current tile index of over 60 after a second.
Debtor Both Presses - This stuff applies to both press left and press right. You should increment the current tile index right after checking the branch. This way you are sure to do it only once and you won’t have to add or subtract from the current tile when you’re getting the tile’s location. Also the do once macro isn’t really needed if you’re resetting it when the key is released. Pressing a key down only fires once for each time you do it; it isn’t continuous. Do once is great if you have to do some logic on Tick or something but you only want to run it one time or if you only want a button press to trigger something one time, not multiple times.
As for your other post, I’m not sure exactly what the problem is without seeing it. Can you post a screenshot of the error tooltip you get when you hover the pin over the other pin?
A few ideas that come to mind that may or may not apply: Arrays can not plug into single pins, only array pins; use a get node if it’s a single pin. Alternatively, if you have an array pin already plugged into another array input pin, cut the connection, then try to plug in another array it will not work because it’s still listening for that particular array. You’ll have to recreate the nodes in that situation.
I accidentally voted this thread as a 1 star when I was aiming for 5, sorry about that. This is a really good read, I appreciate both of your inputs on this topic.
Haha oh man, No it’s cool Distul, I am definetly one star material but thank you for any stars you might give!
If anyone else ever benefits from my bumbling at the kindergarten level that would be a consolation.
Ok , I just finished a first pass read off all of your questions and suggestions, and while I don’t have the time for a complete response to all of the notes, the two big ones to hit are:
You did not, and one of my few points of pride is that I LOVE criticism. I’ve worked hard to wear down the impulse to defend my decisions in the face of people who are genuinely trying to help me. Please don’t hold back!
The answer to almost every instance of this question is a either “Ignorance” or “That’s the only way I’ve seen it done in examples and don’t understand the underlying method enough to deviate” or a combination of the two.
I’ll be trying out a bunch of these once I’m home tonight and I’ll be able to respond to your points more clearly then.
(rant)The big take away is that I don’t understand a lot of the fundamentals of how the engine operates, or how it’s parts interact with one another, or that I would already know a bunch of programming concepts. None of this would be a show stopper if the tutorials available reached a bit further in their explanations for how things hook up to one another and why. I’ve mentioned this before elsewhere but everything seems to go from “you are looking at a game engine” to the higher level concepts under the assumption that you have magically picked up how everything interrelates across the larger program.(/rant)
Seriously though, thank you so very much and I can’t wait to dig into it tonight!
As promised here is the more detailed response to your questions and suggestions:
Right off the bat a lot of the questions you have can be answered with, “I didn’t know any better.”
Setting the player character’s location to reference his location mostly comes from seeing images of nodes set up like that, without any wider context for what blueprint they might be in, or how that might even be important. I read that as being similar to setting a variable to ensure the system knew where the guy is from the start, but I suppose if I’m plunking him down in the map at start and not spawning him from the aether that really is necessary. Similarly, up until you described calling “self” as a target I honestly thought that was a way of allowing another class or actor to call into a script in another blueprint and have it populate with it’s own info. For example the Debtor could call for a location check in another blueprint, and when it found the script it would automatically replace “self” with “debtor”. So, that’s the sort of misunderstanding and baseless assumptions we’re dislodging here.
Some of the weird decisions are vestigial hold overs from when I was attempting other things, such as the delta seconds. My initial thought when I started this was to get a functional prototype running in a single room, completely out of the level blueprint, but with no real intention of chasing down a broader implementation. It’s becoming clear that a lot of the engine’s functionality really doesn’t look favorably upon that sort of set up and I need to get comfortable parting things out quick.
We have a thing at work where new people begin working with Adobe Illustrator and they try and keep all their objects separate with layers, but past a certain point they realize that the work we do really doesn’t require that and can create more complications in the long run. Your suggestions regarding the avoidance of the Level Blueprint sounds very much like that sort of advice that doesn’t seem safe to the beginner, but is coming from a ton of experience, so I’m going to start trying to implement that.
I don’t quite follow the class hierarchy aspect, and I’m still not super sure what a ‘loop’ is. Is it like a CPU ‘tick’?
Not sending any data on completion does make sense though, so I understand enough from your image and explanation to implement this with confidence. What I had came from the misunderstanding that the ‘loop’ was something that would cycle but never complete, and thus it needed the completion pin to actually output anything.
I’m going to implement the switch over from the named Debtor variable to the “self” reference, but your mentioning that I don’t tell the engine what it refers to is a huge red flag that I clearly am missing something. When I created that variable I want to say I had the character selected in the view port and then did a convert to reference variable in the Blueprint. Does a “set” need to happen for that to mean anything?
I’ll be looking this over a few times before I completely understand what’s going on here, but I think I get the gist of it. I’ll get that all plugged in tonight.
On the suggestion of character placement and height, I’m all about getting things set up to endure shifts in the underlying art/object arrangement in the future where possible. I’m really used to the notion of an object having a local origin and being able to offset that point for other actors to use as a snap reference, or as point to allow them to sink into a floor by a few pixels before they collide with it programmatically. Would something like this setup, or even some sort of offset work for that, or should I be looking more at the the object’s bounding boxes in the sprite editor?
This one I think I actually understand a bit better now thanks! Arrays are exciting because they’re where I gave up on math completely in school so this feels like a second chance to learn about them in a real world setting. I’ll get that all plugged in tonight as well. I’m willing to bet implementing them will help some of the logic click.
Oooh! This one took me a few minutes to process. It’s not the fact that the variable is being set at the end, it’s the fact that it’s still technically running as part of the overall timeline call. It needs to be attached to the “finished” pin on the timeline doesn’t it! So that brings up the question: once the final tick of the timeline is complete and the actor has finished moving to it’s final spot, does “set actor location” need to be called on the finish to cement the location? My gut says no, because the location has already been set by the last part of the timeline event.
UPDATE: Having read the rest of your suggestions it’s clear that the variable set should be happening sooner (before the timeline/movement action entirely). I still want to say my earlier conclusion regarding the positioning off the finish point of the timeline would be a potential correct answer, even if it isnt the best possible answer to this problem.
Yeah my concern was multiple fires on the set an release. I’ll get that corrected. And the positioning on the variable set makes sense too in terms of organization, but I do have concerns for the future. Suppose I’ve got the Debtor in a movement between two tiles, and mid move I want to include the possibility of a button press allowing the player to interrupt that movement and monkey roll to the next tile? Even as I’m saying this I can see how I would get around that. It would take the currently set tile, increment it by +1 again, and then get the Debtor’s current position in space to apply a different animation from there.
Actually the underlying concern regarding interrupt events isnt unfounded, but I think I’m far enough away from that at the moment that it really doesn’t matter just yet. I’ll burn that bridge when I get to it.
The array pin and the various ways to convert them I understand well enough. This was something different I believe. I’ll be sure to get a screen shot the next time I bumble into that problem. I think the last time I saw it it said something to the effect that an “Actor Object Reference can’t plug into an Actor Reference”. It’s probably the “listening” issue you mentioned. The recreation of the nodes has worked in the past so I’d bet money on it in fact.
Ok on that note I’ve got a LOT of work ahead of me tonight. Thanks a whole bunch . I’ll post up the results when I have them!
Ah man. So it looks like I’ll actually be rebuilding the project from scratch. A few of my Blueprints are crashing the editor if I so much as right click on them. Guess that “LOT” of work was more appropriate than I thought.
There’s a lot of ground to cover here, so I’m just going to write my thoughts as I go through this post. It’ll be in order
-It seems like you’re getting a hold on what I’m putting down. I’m not 100% sure we’re on the same page, but if you have anymore problems with things you don’t specifically understand, I can help
-In object-oriented programming (C++, C#, Blueprints, etc) objects are either types of classes. You have your types like bool, int, float, etc. Classes are objects that hold data, functions, and structures like Actor, Pawn, UObject, Widget, etc. So say your game has enemies and you want all of these enemies to have a health meter, a level of aggression, and a power level. You first create a class that inherits from the actor class, because Actors all have a transform (so they can exist physically in the world), and call it Enemy. You give it the aforementioned variables. Now you want to have robot enemies and human enemies. Human enemies and robot enemies all have the aforementioned properties. Robot enemies also have a battery power property, which human enemies do not have. So you’d create another class that inherits from Enemy called Robot Enemy and add the BatteryPower property. The human enemy can just use the regular Enemy class because it doesn’t have any need for a BatteryPower property. Does that make sense? This is a (rather long but rather excellent) video on inheritance by the always-helpful Shadowriver: https://www.youtube.com/watch?v=R9QIIBB_qVc He goes very in-depth, and while he does talk a lot about C++, don’t worry too much about the fact that you’re working in blueprints - just try to understand the concepts as they’re the same for Blueprints and C++.
-Loops run within one “Tick” but not the CPU’s tick, the world’s frame Tick. There are two main types of loops (though there are more than just these two), the for loop and the foreach loop. The for loop runs through a block of code or loop body a certain number of user-defined times. You might say “I want the CPU to print the current time 7 times.” That’s a bad example, but you get what it does. The compiler will then check the time 7 times and print the current time to the screen as fast as it possibly can before exiting the loop. You can see this excellent video by the brilliant Zak Parrish on for loops here: https://www.youtube.com/watch?v=hXSKGYQvZsI
-Foreach loops iterate over the items in an array and does something with them. In your game, you have an array of tiles. When we run a foreach loop on it, the compiler will look at every one of the tiles in the array and execute a block of code, the loop body. In this case we want to get the display name of each array element (tile) and print it. Once it prints, it moves on to the next item in the array until it’s iterated over all of them. You can see a similar video about foreach loops here: https://www.youtube.com/watch?v=F-Ab8oS6YDU
-I’m not sure what you mean by “I had the character selected in the view port and then did a convert to reference variable in the Blueprint.” Maybe this a new feature that I don’t know about? If not, a “Set” does need to happen. You can create a new variable in your class blueprint and set it to be the Debtor class, but the variable still has to reference a specific instance of the Debtor from your scene to do anything. You can do this a few different ways: You can make the variable editable by clicking the eye icon next to it in the variables pane then placing the blueprint in your scene and in the details pane selecting the debtor that’s placed in your scene. Another way is to Get All Actors Of Class and check each one with a foreach loop to see if it matches a certain criteria (such as a specific display name or location) and grab the one that matches and place it into a variable (after casting if necessary). Yet another way is to spawn the object from the blueprint containing the variable and, when spawned, set the variable as the spawned object.
-Yep, as you have probably surmised, “self” refers to the very blueprint object that holds the graph you’re working on.
-I’m not sure exactly what you’re asking in the paragraph that begins with “On the suggestion of character placement and height…” Could you elaborate on what you’re trying to achieve?
-Yes, the CurrentTileIndex set here could definitely go after the timeline finishes if you so choose. It would be essentially no functionally different from setting it earlier, I would just encourage setting it earlier to save yourself a CPU tick by only performing arithmetic once as opposed to adding or subtracting from CurrentTileIndex twice or more. It’s such a small performance difference that it would be imperceptible, but if you can optimise, why not right?
-You don’t need to call a solidifying set actor location again when the timeline is finished unless you need a really precise exact location. If you need just a close-enough-that-the-imprecision-is-inconsequential-and-imperceptible location then you don’t need to worry about it.
-Your interrupt scenario would work with setting the variable earlier. I don’t want to make a recommendation yet about how to handle that without seeing where you go from here but there’s most definitely always a way
That’s that, I really hope you get this thing up and running. I hope that I’ve helped you get a better handle on how the engine works and some programming concepts. If you need any more help don’t hesitate to ask!
This happens sometimes and it’s hard to tell what exactly is causing the crashes. Best thing to do is to go back to an earlier version of the offending blueprints. You can find them in your project’s folder under \Saved\Backup. Just remove the timestamp from the file names and overwrite the one in your project.
