Let’s say you have one blueprint that is an event, in this example, spawn a group of enemies when entering boundary, kill them and a chest appears at custom location.
The way I am currently handling it is to make an array of references to the enemy in the event BP, set the references in the editor event BP defaults (enemy 1, enemy 2 etc.) so the event knows which enemies are involved, then on construction script/begin play the event looks through this array and then sets a variable within each enemy that is a reference to this Event BP so each enemy knows it is involved also. Then, once an enemy is killed it updates a counter in the Event BP and so on.
This is good and works in PIE but NOT in Standalone. It doesn’t read the arrays in either construction or begin play and the event fails due to compiler errors I believe. (logs show issues)
I’m curious to know if there is a better, more efficient way of doing this? I have considered event dispatchers but I am unsure how I would go about setting these up without having to make new enemies for each event (not all events will be kill X enemies, receive Y).
Thoughts?
Why is this in construction script? Is your enemies list valid during construction? Is this something you need to see in the editor? If not I’d recommend putting it in beginplay or make your own initialize function.
If enemies isn’t already assigned before begin play/construction it’s not going to do anything. Also, if enemies was assigned by a different actor’s beginplay, it also will probably not work because there is no way of determining which actor initializes begin play first, if Bob needs to talk to Bill to tell Bill his enemies before Bill runs his beginplay function, but Bill already did his and then Bob does his, then it will be screwed up.
That’s why I mention making a function titled initialize or something similar, that way in one singular actor/blueprint such as a GameMode blueprint, in GameModes beginplay you can call the function initialize for Bob and then Bill, as an example.
I do something similar in my own game where my GameMode calls a function to my procedural generator actor, which does its stuff and generates roads, then tells the roads to initialize their functions, then the roads make buildings and tell them to initialize, etc.
That way there’s really only one beginplay for that in GameMode, and it calls a function which calls a function which calls a function until it returns the very end, vs random beginplays being called out of order.
Construction scripts are typically regulated to stuff you have to see in the editor before playing the game/simulating.
Thanks for the advice Deathstick, you breaking down the logic has made it quite clear why it was failing. My main reason in this case of using the construction script was to highlight the involved enemies in the editor and assign a text render component above their location to make them easy to distinguish and that they were properly setup with the event, but I’m sure I can come up with an alternative following your advice.
I’ll try and move the offending assigns to my gamestate this afternoon. Thanks for the nudge in the right direction!
Out of curiosity how are variable Defaults treated in the ordering/lifecycle of gamestate/blueprints? I set my event bounds, enemies and chest spawn location via Defaults that update the construction script and I am wondering if this is a problem also.
I’m still having issues with Standalone, my gamestate blueprint is below
My gamestate’s begin play leads into the above. According to the print screen both the enemies and owning puzzle are referenced correctly but the initialize function is not being fired in Standalone Player at all, which is mind boggling (printscreen within function at beginning doesn’t appear).
The only thing I can think of as to why that would happen is that the Initialize function is somehow not ready on gamestate begin play?
I would be interested in seeing how you have set up your gamestate initialize calls if you feel like sharing a snippet on blueprintue.com or some screen caps?
Edit to add -
Yep, no Functions from the BP will fire on beginplay in gamestate. So my current choices are to basically move the puzzle bp to the gamestate (which is just stupid, messy and impractical), or move the functions to the gamestate tick, assuming it fires after begin play and with enough time to establish the Functions (which is also stupid and impractical). Very frustrating, any ideas?
This is bad; use “Interfaces” for things like this.
Thanks BrUnO, got it. Ridiculously simple and now I feel a fool for the other method! Now to forget this bad practice.
It’s really difficult to know without a programming background what the do’s and don’t’s are in UE4. My general thought process has been ‘if it works in the editor then it must be okay’, but it is becoming increasingly obvious that that is not the case. This isn’t helped by the fact that there is a lot of ‘bad practice’ floating around the interwebs and youtube. I’m glad you mentioned it when you did as I can tidy up some mess elsewhere.
I suppose the term ambition outweighing knowledge comes to mind… 
Thanks for the nudge in the right direction
Bingo, you got it right, that’s why I found Unreal Engine so frustrating to try to set my game up in.
Because I have a big game but to try to fit my game inside the confines of Unreal Engine’s Do’s and Don’ts rules
was the hard part. If you don’t have the unreal programming background it will be harder to know what the limits are you can work with.
Yep, I would say 80% of the engine is straightforward and easy to learn, at least to a basic implementation level, the tricky part is doing things right so the code behind the scenes is functional and the performance is optimised. I suppose I am part of the new game dev breed - mostly artists, creators and designers wanting to develop games on their own will little to no programming background. We don’t have the logical thought processes that programmers do so we rely on visual information to say “correct” or “wrong”.
Part of me wonders if it’s better to go down the verified training route so you know exactly what you are dealing with behind the scenes, but that is a huge money and time sink that most of us don’t have the opportunity to take.
For now I will settle with you helpful folks here on the forums along with a dash of my own intuition (god help us all…) >:D
Programming is a skill learned from spending time doing it, just like becoming good at modeling or designing. When I started out a couple years ago with blueprint scripting I didn’t even know how to properly use a freaking simple array, and nowadays I’ve been able to implement working flood-fill, queue stacking, breadth-first search algorithms, etc. in blueprints and I’ve started learning C++ as well. The bright side is if you know blueprints, you kind of already know how UE4 sort of works, so it’ll be easier to find the correct macro/function in C++ later.
So yeah, just keep at it! Programming is like fun puzzle-solving with occasional headbashing, then two weeks later you look back at your code and go “how could I of been so stupid then!” 
