Spawn Actor from Class.. Placed Items Work corrently, Spawned items Do not

[GrumpyMunkyIndy]

Ok, So I Have this little System for scrubbing stains, when I place them into the level from the content Browser, they respond and work correctly, return a print string to show overlap begin and end, etc.

However, I decided it be fun, if the player drops an object, to spawn a stain at that location, used the spawn actor from class node, set up the transform to orientate it, all works perfectly.

Except the stains spawned from actor class node, dont respond at all, its as if the overlap events are not being triggered.

I thought at first it might be that the actor reference isnt getting set for them (Since the actor reference is set manually in editor when placed into the level from the content browser and these are getting spawned and missing that step.

So I set a begin play event for the player, to cast into an existing stain, get the actor reference, then on future stains, their event play is to grab that reference from the player character and set it to their own.

This didnt seem to resolve the issues, so im not sure what the issue is. Ive noticed its the ‘Stain_BP_c’ thats set as the object to be spawned, whenever i place it into the level I dont use the _C variant? is this the issue? I mean this seems like it should just function. All the code is in the blueprint, spawn the actor from the blueprint, run the same code. Its ridiculous to me that this kind of obvious functionality is leading to such a massive ball ache simply by not being there.

I mean Im SURE im doing something WRONG, or NOT doing something I SHOULD. But come ON! A spawned object to behave as it blueprint dictates? Am I A minority here thinking that should be BASIC functionality???

EDIT

Additional Info:

-Tried setting a line trace connected to the N key, casting to the stains blueprint on hit, print to return for a success and a print on cast fail, the comparison ALWAYS FAILS, this is being handled in the first person character blueprint.

-Tried setting a line trace to CLASS, targeted the stains bp class as the target, cast always fails.

My current assumption is that not only is it not registering any of the blueprint code when its spawned, its not even coming with any collision.

Dragged the out hit of the spawn actor from class node, set it as the target for enable collision to channel, and attempted to manually set its collision to the visible channel after its been created, no effect.

Is it better to set this up as a decal somehow instead? How would I Do this? This seems like such a cut n dry ‘this should JUST WORK’ issue im kinda aghast it doesnt.

[WaxOff]

I can’t be sure without seeing the blueprints, but I have a guess.

Not sure if it would solve your problem, but it may, and I think it may be an overall better approach, without changing much of what you already got working.


I’m guessing the issue may be related to where your logic is; it’s not entirely clear from your description, but I’m guessing the Spawn Actor From Class node is used in one of your actors’ blueprints.

If that’s indeed the case - instead of spawning your stains via the actor blueprint, try doing the following:

1. Create a Custom Event in either your Level or GameMode blueprint’s Event Graph (I’d use GameMode to have this behavior independent of that specific level you’re working on), name it SpawnStain (or whatever, you know) and add a Transform input to it (you can name that SpawnTransform).
2. Move your Spawn Actor From Class behavior to the selected blueprint (Level/GameMode) by cut-paste & connect the SpawnTransform event input to the Spawn Actor node’s Spawn Transform pin (remember to set other values as you did in your existing blueprint segment, if you didn’t cut-paste it directly).
3. Whenever you’d spawn that stain from within your actor blueprint in the beginning - instead of calling your old Spawn Actor segment - get a reference to your Level/GameMode blueprint, then use it to call the SpawnStain event & connect the transform you used before the changes into the event’s SpawnTransform input.
   
   
   
   From my experience -
   having such a spawning mechanism is mostly more reliable than having other actors spawn them, but without seeing your actual blueprints - I can’t tell for sure whether this will solve your issue or not.
   
   It could be an ownership issue, a collision issue, or one of many other types of issues - I really can’t tell.
   
   
   Oh, and it kinda does sound like you may wanna use Decals in the long run - it may somewhat simplify your Stain entity - but again, without code it’s kinda impossible to tell for sure.
   
   
   Good luck in any case.

[Nebula_Games_Inc]

screen shots of the blueprints would be very helpful right now…

[GrumpyMunkyIndy]

Thank You!

I Am indeed calling the Spawn actor from the actor thats creating the hit event, so the coffee cup hits the ground THAT specific cup, call the Spawn Actor event.

So Basically it goes Coffee Cup > Hits ground > Obtains a break hit from the location and Normal to get position and Z > spawns actor based on that criteria.

So just so Im getting this down right because Ive had a few beers to try and get my head around this during the afternoon.

In the Cup Actor, on hit, break the result as normal, store as a publicly readable variable, cast to, say, first person character blueprint, feed in the variables and call a custom event in first person character blueprint, which then performs the actual spawn action itself?

Thats the way Im reading it, feel free to correct me if Im wrong, Im more trying to get an idea of whats causing the loss of functionality, a solution is somewhat secondary to be honest, an UNDERSTANDING of the CAUSE is kinda what im after here!

Thanks for the help to, I will give that a try at first available opputunity and il leave a few screens here to help.

[Nebula_Games_Inc]

Reading you second post and looking at your screen shots (which are missing a bunch of important stuff FYI like where you set “actor” reference) and trying to piece together what is going on, not gonna lie I am still a bit confused at the whole implementation of what you are trying to do. I get the general “premise” you want to dynamically spawn an actor (stain) where another actor (coffee cup) hits the ground. This is not hard at all and I think you’ve managed that just fine. The issue I am seeing and still not comprehending the logic you’ve put together on this is how the “player” interacts with said “stains”. So when your player “overlaps” a stain I am assuming that sets the bool “sponge on stain” to true and allows the player to “clean” the stain. So far so good. However…none of this makes sense to me from your original post:

"So I set a begin play event for the player, to cast into an existing stain, get the actor reference, then on future stains, their event play is to grab that reference from the player character and set it to their own.

This didnt seem to resolve the issues, so im not sure what the issue is. Ive noticed its the ‘Stain_BP_c’ thats set as the object to be spawned, whenever i place it into the level I dont use the _C variant? is this the issue?"

The first part is weird because you are setting a reference to an existing stain, then spawning new stains and telling them to set a variable in themselves to be “the existing stain” even though that is NOT what they are so overlap events and such would never work for a new stain because the reference is pointing to a completely different object.

The second part just adds fuel to the fire of confusion because you are now saying you’re using 2 separate actor types one “Stain_BP_c” and another “Stain_BP”.

[GrumpyMunkyIndy]

So I Updated the Cups hit event to set a set of variables and call the spawn event from the first person character blueprint

The First person blueprint simply calls the spawn function from the given transform set by the impact

Still, the spawned object doesnt recognize anything. Overlaps, Collisions, Line traces, Nothing returns any kind of result

Im kinda at a loss as to why this would happen, it seems insane to me that a spawned object doesnt mimic the functionality of one that u can place in the level manually, id accept its just lacking the actor reference were it not for the fact it doesnt return a result off a line trace either.

To me, it MUST be some kind of inheritance issue, I had problems like i said with the progress bars on any copies of the actor that werent the original, so maybe Im not setting up something properly? I Dont know. I mean this must be easily solvable or you would never be able to create a game with interactable objects spawned on the fly, which we all know isnt true, so there MUST be a SOLUTION! its so frustrating having such a simple thing cause such a MASSIVE problem.

[Nebula_Games_Inc]

Putting all of this together with the first major area of confusion, you MIGHT even be setting the actor variable of “Stain_BP_c” to point to a reference of “Stain_BP” (since those are the ones you drag into your world which you said you tried referencing). I think some re-working of the basic “logic” for this gameplay event might be the best thing. You said you would rather “understand” than find a solution to this which I think is a good idea. And in that spirit here is what I think will help your understanding.

1. Whether you spawn an actor (ie stain) or place it in the world in order to have your player manipulate anything in that blueprint you are going to need a reference TO THE SPECIFIC stain, this is called an “instance”
2. When you create a variable to store a “reference” as its data any use of that variable will ONLY affect the specific actor you stored in that variable as a reference
3. If you want to use the same variable again you need to “Set” it to a NEW actor (or stain) which means you need to somehow tell the computer which stain you want it to remember. Once you tell it to remember stain B, it will “forget” stain A and any further use of that variable will only affect stain B
4. Overlap events are great ways to “create” the reference because the computer will know exactly what actor is touching what other actor on overlap, this is a common way to tell the computer “hey, I am touching a stain right now, please remember what stain this is” and you do that by “Setting” the variable which in your case you called “actor reference”
5. Even if “Stain_BP_c” and “Stain_BP” are exactly the same and are coded to do the exact same thing, to the computer “Stain_BP_c” may be a missile launcher and “Stain_BP” could be a bunny rabbit, you can’t use things interchangeably like that, so whatever you want you “Stains” to be, only use that BP class no others.

Those are my main thoughts, hopefully some of that was useful haha

[GrumpyMunkyIndy]

Thats Kinda confirming what I suspected, since the progress bar only ever fills off the first one placed, that being the only one with a clean instance ID I presume?

So if you dont mind me picking your brain for a moment let me try and clarify a bit better.

The actor reference is set in the stain_bp, when I placed the stain_bp in the level through the editor, i selected it, and pointed that reference to the ‘sponge_bp’, gave the stain mesh no colllision and placed a collision box inside it in the viewport, and directed an overlap event to set a boolean, so on begin overlap it sets it to true, on end overlap sets it to false, the sponge_bp has no actual code, its all contained in the stain.

Hence the confusion about the event begin plays, i at first thought the fault lay with the fact the newly spawned stains DIDNT have the manual actor reference I had set on the ones Id placed via the editor, so was attempting, on their spawn, to get them to derive that reference from one of the stains existing in the world, i removed all of that entirely once I realised the dynamically spawned stains wouldnt return a true value for a line trace, so if i couldnt get it to do that, trying to get it to bounce around collecting variables was probably making it more complex, and tried to go to a method where I could try and confirm all the various stages a stage at a time.

So… Im trying to get my head around this, if I spawn a stain, and set the return value to a variable i can then store, I can in theory, compare that variable, to another derived from an overlap event?

So for example, I spawn a stain, take the return from the spawn actor class and pump it into a variable node, and maybe add that to a table or array somehow, (if thats possible) then when the sponge triggers its overlap, it compares its id, to one of the ones that have been stored from previously spawned stains, and destroys itself?

Or am I WILDLY off base? lol

[GrumpyMunkyIndy]

Thing that really baffles me is all the manually placed ones behave correctly, there are hundreds and bar the progress bar issue, they all update, recognize the sponge overlapping them, and destroy themselves on cue, manipulating the ‘seconds cleaned’ variable in first person player bp as designed, each one of them, even though im not manually switching and re referencing them every time. Respond correctly.

I can totally understand the need to track ID’s and understand which object is being referenced at any given time, Im not disputing that at all.

Im just baffled that the only discernable difference between the stains that work and ones that dont, is their method of placement, they use the same blueprint and same logic.

The only difference that I keep coming back to is that when i place them manually i just place stain_bp but when calling the spawn, I can only spawn stain_bp_c or the class variant i presume, problem is i dont understand the difference between the two or the fundamentals of why you would use one over the other and the difference in funtionality between the two

[GrumpyMunkyIndy]

I threw together a line trace returning name, so I could check that the stain physically existed, no result at first, I forced the visible channel of the collision box component of the stain to block and returned the name of the object with the C suffix.

I keep making the distinction between stain_bp and stain_bp_c because the game does, whenever you try and cast to a bp it always gives you two options, one ive been taking to be the actual blueprint I created ie the object in the content browser labelled ‘stain_bp’ and the other being ‘stain_bp_c’ which since its what the spawn object from class keeps pointing to in the spawn node, im assuming, its an overcall ‘class’ to control instances of that blueprint.

I get what your saying i think, store the name of the spawned stain, so I can reference it later.

Thats fine.

PROBLEM IS, getting the Spawned Stains to recognize the SPONGE, to even trigger that comparison to take place,is the issue here, all the ones placed via the editor trigger their overlaps, the spawned ones do not. If i cant get the stain to trigger the overlap event when the sponge overlaps it, it will never set the variable to make the comparison.

The Placed ones do this, Spawned ones do not. Its so weird to me.

Its not like im saying ok sponge are you touching stain_001, or stain_002, or spawning a stain and going ok, this is stain_002, sponge, check if u ever touch this stain.

Im spawning every stain to check for sponge_01

its like this:

stain_01 checks for sponge_01, success
stain_02, checks for sponge_01, success
stain_03, checks for sponge _01 all success

the sponges name never changes, only the way the objects are spawned

stain_01_c_01, spawned during gameplay, always with that c suffix, checks for sponge_01, just like the placed ones, but never sees it. the actor reference is always sponge_01, and is always made by the stain, not the sponge,only the manually placed ones ever return a success.

[WaxOff]

I think you should be learning a bit more about object oriented programming, just to better understand how this whole thing works.

Your desired result is not hard to achieve, but it would be impossible to carry out well without some planning and knowing how stuff works in OOP in general, like classes, objects, variables, data types and so on.


In short - if I understood this correctly - it seems to me like you’re referencing a stain_bp INSTANCE (meaning, one specific instance of stain_bp you’ve already initialized and placed in the world) within stain_bp itself, which is ill-advised to say the least (not to mention, logically problematic).

Your approach for stain_bp in general, IMO, should be “I’m creating an object representing one independent stain”, then spawn those as needed (and, btw - your spawning logic is still in your character blueprint, NOT Level/GameMode - THIS MATTERS! - your spawned stains may currently be misbehaving because they may all be somehow attached to your character).

Each such stain may have an ID if that’s somehow needed - I highly doubt that though.

This whole thing sounds like it could be solved by using the GameMode blueprint more often, in order to keep track of whatever counts that interest you (total stain count? current stain count? etc.), e.g., create a Custom Event for editing your count (either use appropriate inputs or split into standalone event along the lines of ‘add stain to count’/‘deduct stain from count’), then call that event from wherever you’re logically creating new stains or cleaning existing ones.

The GameMode blueprint can be referenced by any other blueprint, so that’s highly useful.


It’s quite a lot of notes, I know - but you’ll have an IMMENSELY hard time doing this ‘the hard way’, in any case.

I hope that helps!

[Nebula_Games_Inc]

To be honest, without actually staring at your code and actually doing the “manual” vs “spawn” placement myself this is a difficult thing to specify your particular issue. One thing with poorly written code (we all do it at times, no offense meant) is it makes it difficult to debug. It is usually a lot easier to just re-work the logic from scratch it will save you time in the long run. Also I am not sure what you mean by “when you cast it gives you 2 options”. Casting shouldn’t have “multiple” options. “Cast to Stain_BP” can only mean one thing. If in the editor you type in “Cast to Stain…” and you see “Cast to Stain_BP” AND “Cast to Stain_BP_c” to select from then you actually…somewhere…somehow have TWO “Stain_BPs” in your content browser. My suggestion, for testing purposes and to possibly fix your issue is build a super simple system and get it to work first. So I would do this:

1. create a blueprint to be the “stain” call it something VERY different like “MESS BP”
2. Set up “Mess BP’s” collision to ensure that it will overlap “Sponge BP” (also not sure where sponge BP is…is that something attached to character BP? but it’s own BP? or is it a component of character BP?? not sure, regardless…no worries)
3. Have the level BP “spawn” “Mess BP” or however you would like to “spawn” these “Mess BPs”. But don’t spawn them from the character…try and keep that separate for now.
4. Have an overlap event in “Mess BP” to check for sponge…which means a “box collision” as a component of “Mess BP”, this box collision will “on overlap” cast to “Sponge BP”…if it succeeds print success or whatever you like
5. If this works, then you can modify any progress bars, variables etc of the sponge or the specific “Mess BP” interacting with the sponge at that time.
6. If there are variables in the character BP you want modified we can deal with that later through casting to player character (a simple step).

Point is, this interaction shouldn’t be hard to get

[GrumpyMunkyIndy]

Your totally correct with regards to object oriented programming, Im basically learning what I need as I go, so im running into a lot of situations where Im attempting to either learn something new, or why something I have already done isnt working.

So. The container for the blueprint is important, parenting properly is important, and some basic set up and learning in this area will probably not only aid me to understand what I did wrong and prevent it in the future?

That is one of the difficulties Im finding with learning, youtube only gets you so far and lynda etc are kinda out of my price range so im really struggling when I come across something I dont understand.

So when Im setting up the level and just ctrl+W’ing the stains around from the blueprint i dragged in, these are ‘instances’ of the blueprint, but what are they parented to? Is the original I place a master copy even within the level and all the others are derivative instances?

When I spawn actor from class with the _c denotation, how is that fundamentally different?

I agree I need to learn but finding sources to get the knowledge from is difficult.

Currently Ive set up a very messy brute force method, basically on hit the stain sets the ID of whats hitting it as a variable in my character, the sponge on event play, sets its own ID as a second variable, when the stain recognizes a hit, it sets its own name as a third, and triggers a custom even to compare the first two and on true, destroy the third (the stain originally contacted’s instance?) either way it works exactly how I want and might not be elegant, but when i deconstruct whats going on and clean it up, move it to the game mode or level bp, im hoping it will help me better understand what im doing wrong.

[GrumpyMunkyIndy]

I actually got it working this morning.

But your method was what i had, in stain, collision box, overlap with sponge, cast to sponge, modify variables on success. Sponge is just held on physics handle, the ONLY difference in them was that they were being spawned by the coffee actor. Any spawned ones failed the overlap, so no other code ever ran. I think the main take away here is to use the level bp to spawn them, and not a pawn or actor.

I worked around it with this

Basically the sponge sets its own ID (I noticed it changed every time I hit play) as part of its event play, records this in the player character, whenever a stain is hit, it triggers hit event, sends its own ID to the first person character, and the ID of the object touching it. If ID 1 and ID 2 match (the sponge ID’s) it deletes ID 3 (Stain ID)

what im referring too regarding the duplicate cast options, its not duplicate items as u suspected, my fault for not being clear.

and when im referring to the difference between the dynamically spawned variant and the manually placed variants, here, see when I line trace a ‘placed’ stain, it returns the ID as such, only the number ever changes,always WITHOUT the addition of the C_,

however, all dynamically spawned variants name always is presented in the last image, with that additional suffix and again a different number.

all placed vs spawned stains Always return their names this way.

Im trying to understand what the difference is Im getting the impression from reading over all the posts (and thanks so much ) that im placing instances of the blueprint into the level via the editor but spawning the controlling ‘Class’ version into the level, but expecting the instance to control the class, I think, is what im doing wrong here

[GrumpyMunkyIndy]

So I moved everything over to the first person game mode, since apparently I cant cast directly to the level blueprint, this seemed easier.

The top section handles the spawning, the transformation information is fed into variables stored in first person game mode, and at the bottom, is the ID comparison between the Sponges ID and the ID the stain is registering during its hit event. At the same time as the hit event being triggered, it also feeds its own ID in as a third variable, and thats how Im choosing which stain to erase.

After feeding in Its own name, and the name of the object hitting it, it triggers the killstain custom event in the game mode blueprint, this compares the two names, and if true, deletes the third, which is the stain which called the hit event, so is always the one being triggered, and even if another object ‘hits’ it, the comparison in game mode will fail, meaning, only when a sponge, contacts a stain, will the event run, and then the only stain that can be affected is the one that registered the hit.

Yeah its not great probably, and Im probably doing a hundred things wrong, but it works and im pretty pleased with the solution.

[WaxOff]

What I believe both of us were trying to say is, you probably don’t need those IDs at all.

If your Stain_Bp had a ‘removeStain’ custom event, which handled everything that’s related to properly ‘cleaning up’ a stain (which is probably registering counts accordingly & self-destroying) - it would then be rather quick & intuitive to create an overlap event, check if you’re overlapping with the sponge & if so - call the stain’s ‘remove’ event.

I’d do one of the following, while keeping in mind that the first is better in terms of best practice but requires a tad more work, and the second one is quick, dirty & kinda hacky, but would probably work:

1. Create a Sponge blueprint, move everything from your character blueprint that’s sponge-related to Sponge_BP, then replace the existing sponge with a Child Actor component attached to the character.
   Note that you’ll then have to set your ChildActor’s type to Sponge_BP, and use the GetChildActor node before ever trying to refer to your child actor specifically as a Sponge.
   Once that’s properly set up - you simply add an overlap event to your Sponge_BP, cast Hit Actor to Stain_BP - if successful - call that stain’s ‘removeStain’ event, and it will properly self-destroy & disappear (if all is properly set up within Stain_BP, of course).
   
2. Keep your sponge as an integral part of your character blueprint, then add an overlap event to your Stain_BP, first casting Hit Actor to your character blueprint, then if successful - check if the overlapped component (Other Comp) is definitely that sponge (can’t tell you exactly how to do this - it depends on how you set up your sponge, but you can probably investigate Other Comp’s parameters to somehow make sure that’s your sponge). Then, again, if that check is successful - call self’s ‘removeStain’ event (since we’re doing all of this inside Stain_BP).

Again, I'd go with the first approach just to make things easier to maintain & understand later on.

[WaxOff]

im placing instances of the blueprint into the level via the editor but spawning the controlling ‘Class’ version into the level, but expecting the instance to control the class, I think, is what im doing wrong here

That's exactly right; I didn't quite understand what exactly you tried to do to the instances, but for changes to take place for all of this "type"'s instances - they have to be made in its blueprint, i.e. Stain_Bp.
I can't tell for sure about learning OOP from scratch online, but approaching UE w/o any OOP background sounds like an absolute nightmare to me. It takes enough time for actual programmers to properly dive into UE, so doing so w/o knowing the very basics is borderline suicidal IMHO.
It's definitely not impossible to learn this by yourself - but you're gonna have to be able to troubleshoot yourself via Google as a second nature.
I'd probably start off with learning a bit about Algorithms, then proceed to learn just about any OOP language, to properly 'feel' those concepts & how they come in handy when coding. There are plenty of free online courses, and some of those languages have incredible communities, tutorials and overall online support.

Good luck (:

[GrumpyMunkyIndy]

Oh Its frustrating but also very rewarding, Im a bit of a sado when it comes to that, I think my problem is I worked a LOT in FPSC, and that is a very different thing entirely and I have brought a lot of bad habits over from my time in there onto Unreal, Ive been using UE4 for about a month or so, Im very new at this and just trying really to understand how Unreal wants me to ‘talk to it’ for want of a better explanation.

The help has been massively useful and thank you all for that, I have what I wanted and also a decent lead/head start on heading in the right direction to learn more and get an understanding for this.

Im not new to game design, I developed and almost released a semi-full game on FPSC (My gf actually streamed it for a few hours) but since it required installation of dx7 and some manual dll placement to get the exe to even work on modern systems (Not to mention the work s4real and NomadSoul put into even getting the actual FPSC SDK to run on anything above win 7) it seemed fool hardy to try and push that out as a commercial product.

But trigger events, calls to other functions, variables etc, everything all worked differently and trying to accomplish things I could do there very easily (Like declare a variable global, and boom, any other ‘script’ could just read it without casts, owner ship etc) require a lot more effort and understanding to set up in Unreal, But I Will get there, Google, Youtube, forums will be my guide!

Thanks for the help, Just having some folks who know what theyre doing to bounce off and try and figure out for myself how to actually implement a solution was immensely helpful! Dont go leaving the country, im sure i will be back lol

[Nebula_Games_Inc]

No worries, you’ll get there! I started about a year and a half ago not even knowing what a game engine was let alone OOP. I picked everything up on the fly from reading, YouTube and experimenting with UE4. And now I’m pretty confident I can do just about anything I want in the engine using blueprints. As for “leaving the country” not likely. I started a YouTube channel actually to make beginner tutorials and answer questions through videos so you can find me there if you have other blueprint issues. Good luck!

Nebula Games Inc