What is supposed to happen with the goal cube?
Also, where is the power supposed to be coming from? The start cube, or the start pipe?
Ah, now that makes sense. Most of the metal cubes seem picky about it and I’m not sure why they won’t light up now.
As for the goal cube, that is intended to indicate that the puzzle has been solved. I was thinking of having that goal cube trigger a way to the next level.
Initially, I thought of the start pipe being there just for effect; but then, I thought about it giving the power to the start cube since that is supposed to be attached to the start pipe all the time.
UPDATE: After examining each metal cube during a simulation to test the BP, I found that the cubes’ Lifetime numbers are going way below 0 and the first two flicker in a small range of numbers. Yet the Lifetime number on every Metal Cube is set to 0. I wonder if there’s a bug in the program, or if I should double-check the number for the Lifetime variable under Cube_BP. Even after I set the number under each int > int node to Lifetime as opposed to 0, it doesn’t seem to work (probably because Lifetime is set to 0 as well).
Ok, this is it:
I’ll try and cover everything, if I’ve missed something, just ask.
-
There is now a parent called ‘conductor parent’. All it contains is enough to manage the overlaps for the physics, and power on and off. Notice, it doesn’t have a mesh by default.
-
Then we have the main class ( inherits from 1 ), ‘conductor’. It has all the code you probably recognize. It responds to power pulses, decrements the power, and when it powers on, sends the power token to any nearby conductors. You can set the mesh to anything you like.
-
We still have the ‘starter’ object, again, the mesh can be a cube or a pipe etc. And it just sends power to any nearby conductors. You can choose a particle system for the starter object if you want. ( The water font object is similar ).
-
We have the goal object ( just called ‘goal’ ). If this receives power, it will wait 2 secs and then load the level that has been set in it’s properties. Now, in the default level, you just need to push that missing cube into place, and level2 will load. Level2 is very boring ( just one cube ), but I’m just showing you how to load another level.
-
Lastly the rubber cube. It inherits from conductor parent, but has no code.
One of the main points, is you can generalize everything. So all the conductors are the same thing, they just have different meshes:
These are all the SAME blueprint, I just told it a different mesh:
Keep a copy of the download somewhere so you can refer to it 
After looking over the newer file, I can see how much more flexible the BPs are, since I see Mesh and Static Mesh variables that make the meshes of each actor easily adjustable.
Including the Moveable Boolean does make sense, and it’s a lot less work than trying to lock the axes. Though I do wonder if the collision boxes are a little too large, I know they work for sure. But, the reason I included the X and Y Axis Collisions earlier was because I didn’t want the cubes to move too freely when pushed; I only wanted them to move along the floor without tumbling. Maybe I should adjust the Linear Damping.
I also wonder how you managed to fix the Lifetime variable to keep it from going too far downwards from 0. I meant to say before that the later cubes’ rapidly going far into the negative numbers was a bug. I tried to find the Lifetime number when simulating the newer file, but I wasn’t able to find that variable’s number on each Conductor cube. So, how did you manage to fix that? I’m really just asking that so I can prevent/fix the next problem I’ll surely be faced with. I do wonder if the Overlapping Actors variable has anything to do with that.
Lastly, don’t worry about the second level. I will make more levels on my own, especially with the BPs set up. I plan on making up to five levels total for the playable demo, and I may or may not use the same objects in some level, along with “broken” pipes and, maybe, smaller cubes as well.
Anyway, thanks for all your help! Again, I’m sorry I’ve made this thread longer than I intended, but I’m glad we got this fixed at last.
I’ve made a second level and the Lifetime variable still causes objects to flicker instead of staying on. It seems as if that level is picky about how many objects I put on the map; if I put over 20 objects that conduct electricity, the last one or two objects start to flicker. I made a third level map, but the goal pipe doesn’t take me to the next map.
The life variable going < 0 doesn’t matter, because the moment something offers the conductor a higher value, it takes it. That’s what this code is:
If you have a lot of cubes, you only need to adjust the initial source life time in the starter:
If you left it on 20, then naturally, when you get to 20 objects, the last ones will flicker 
BTW, feel free to select one of the posts and mark it as the answer
With the hard part resolved, I’ll gladly mark that last one as a solution. I know I’ve said this many times already, but thanks for your help. Now I can continue my work on the puzzle demo that I need for a job application.
You’re welcome.
I meant to say, you can make a variable in the starter class and expose it. Use it to set the amount you’re sending. That way, you can choose how much ‘power’ a starter has when you drop it in the level…