Hey! Thanks! Are you up the whole night coding? Like I was many years ago. 
Looking forward for more on this later. Be well!
As you can see this code is in the construction script of an actor that is placed in the sublevel in the Unreal Engine Editor. All this code runs in the editor as well as the packaged shipping build. I tested it several times.
1 Like
How do you know its running in the packaged game, and didnât just do it during packaging?.. 
Why not try a script that does something different every time you run it, like chooses the color of a cube in the level.
If the cube changes color every time you load the level in a packaged build, my theory is shot 
Iâm too old for that anymore. I just have a skewed schedule. Yesterday was a late late late one.
Is your project single player or multiplayer?
If MP, Listen or dedicated?
Are you using World Composition?
Modification to SELF should work fine in CS. Accessing other actors in the level and their data is the issue.
Actors have to be loaded, read from drive and stored in memory, to access data about them. The class executing the code and whether or not itâs client or server-side matters.
1 Like
Right, but this is always an issue, even in editor.
I have no idea about MP 
As far as I know, the code that runs in the cooking process gets all the data required, and then it is cooked with all levels and actors because the game runs without any errors, the player can shoot enemies or pick up objects, and the next time the game is run, the destroyed actors are removed. I can load a checkpoint or start a new game, continue from a checkpoint after the player is killed, etc., etc., which is the main mechanic of the game, and it works perfectly. So even if the code runs in the packaging only, which is what really happens, my objective is achieved. But I will try this randomly changing color cube to see if the code actually runs in the packaged game and get back to you. Thanks for the collaboration.
1 Like
Actors we place in a level are technically spawned at run time. The Level simply stores transforms and class names for what goes where.
Instances of an actor have to be loaded in memory and instantiated in order to reference it. CS will cook a class reference, but no data about the class will be stored. An object reference is essentially a pointer to an address in memory.
For example Get all actors of class will only access whatâs loaded in memory and instantiated at the time of execution. You can have 20 instances of a class in a level, but only get 5 results.
Iâll work up a good demo example this weekend.
1 Like
I believe you 
my game is a single-player FPS. I am using world composition, with sublevel streaming based on the playerâs proximity.
Looking forward to this.
True, but when I place my enemies in the level and check the variables i want se they are always correct because I am running them in the construction script. So, theoretically, what is IN THE LEVEL is calculated before beginplay and added to the variables. This is not a speculation. I tested this. My packages game was tested on several machines and ran correctly, updating saves, loading values, restating the game, starting from a checkpoint, etc.
Can I just voice of reason ask - why bother with this?
Just move the code to begin play - and add some proper isValid checking like you should do anyway when accessing any actor.
And thatsâs that.
From trying this - you basically have no guarantee that on create will run even when you (or maybe specifically when you) manually spawn in the object.
On destroy doesnât even work right, so if you are good at what you do you just create your own garbage collector in c++ insteadâŚ
And sure, Maybe this works at the level blueprint level - but one can also argue that using level blueprints is bad practice and shouldnât be done. So itâs kind of a âmooâ pointâŚ
1 Like
The level blueprint is not used for any coding purposes. The actors are placed in the level manually. all save load and spawn code is in the game instance and game manager, and the respective code for player and Ai in parent blueprints. The level bps are there by design. When you create sublevels, the level blueprints are created. I use a Level Manager to look after spawning and destroying in each sublevel.
Doesnât really change much of anything - construction/destruction would be good for blueprint accessible garbage collection for instance - but it doesnât work. (Never has reliably).
So what everyone does is to use begin play and specifically levarage whatever death function you create or custom destruction you need as an interface call - if you want to manually fuss over proper disposal of things via blueprint.
Not saying you canât do whatever you want - saying that testing it and figuring it out when its going to change on you tomorrow because an epic employee got up on the wrong side of the bed is pointless - since you have Begin Play which will never really change behaviourâŚ
Thanks! What you say makes sense. But I am on UE 4.27.2 and itâs very unlikely that anyone will bother to update anything on this version anytime soon, but what you say is true. Iâll change things around and see if my game still works as it is.
1 Like