I have two blueprints that cast back and forth to exchange variables and trigger events but when I compile one the other decompiles and depending on the order the PIE compiles them some events don’t work. Is there a better way to pass the variables along than having it cast to and set?
Would it be worth me having a master blueprint that contains all the shared variables that my various blueprints need to access and have them cast to that instead?
I’m still double checking everything but I think I’ve sorted this for my situation at least. The problem was if I had a blueprint cast to a blueprint, which then cast back to that blueprint, compiling one would cause the other to need recompiling so both could never be compiled correctly at the same time. The result was every other time I pushed play the blueprints compiled in a different order and my game would work and then not work.
Now I’ve split things up a bit more so the blueprint holding the variables never has to cast to another blueprint itself. This seems to work but with one caveat. The blueprints need to be recompiled in a specific order or they start making each other need to recompile again, is this intended behavior? If it is I’m not sure it’s a good thing since PIE seems to recompile in a more or less random order so it could do things in the wrong order and make it seem like the blueprints have errors.
I would be careful when you have 2 or more objects that cast back and forth or basically cast in a loop. I had this same problem with the compiling and when I tried to load my project 2 days later it crashed on load. Then I had to remove one of the blueprints from my project files just to load. Then I could put the blueprint back into the directory after it had loaded.
Try and keep the flow going in one direction and don’t let it loop back on itself. Even if it doesn’t seem to directly cause an execution loop, something in there doesn’t like it.
If you can create a blueprint to hold a number of common variables I would suggest doing so. I hear in 4.2 they are giving us access to structs so that should help.
What?!? Wait, wait – wait – so if you have a PlayerController and a PlayerCharacter and you need to get data to the Controller from the Character using GetContolledPawn and casting to the PlayerCharacter blueprint or you need data from inside the Character from the Controller using GetController and casting to PlayerController, this causes a problem??
There has to be something else going on here, because I have Blueprints invalidating compilation of other blueprints and I moved shared data - now when the SharedBlueprint is compiled, the Blueprints that reference the Shared blueprint go dirty and there is no functionality in the SharedBlueprint.
Casting between shared blueprints shouldn’t be an issue - that doesn’t make any sense, casting happens all the time. If this were the issue, wouldn’t (or rather shouldn’t) there be circular reference warnings? Also, given this is the only post on the topic of decompiling blueprints and the pervasiveness of casting, I think we need to look elsewhere for the root cause of this…
I know this is an old post, but I think this should be looked at…