Like it says in the header, does this really matter ( in blueprint ).
If it does matter, what are you supposed to do with the classic, doors / controller problem: the doors need to know about the controller, but the controller needs to know about the doors.
If you write it with dependency, it works fine. If it’s not correct, what is the problem?
Thanks 
En ningun momento tuve ese problema trabajando con Blueprints. Quiza sea la forma de escribir el script o la manera que en que Blueprints compila. sin embargo Tengo proyectos grandes con referencias de un lado y otro y jamas vi un error de dependencias.
En cpp es muy comun ese problema.
Thanks for your answer. I’ve had no errors ( apart from strange crashes ). I’m just wondering if it’s ‘dark magic’ and should be avoided…
I ran a dependency checker ( Circular Dependencies Detector in Code Plugins - UE Marketplace ), and my project is like a piece of swiss cheese
Thanks for your answer. But what IS tight coupling actually, and does it matter?..
It’s an indication of a bad design and tight coupling. So it should be avoided.
But, if it works and the editor doesn’t complain, then who cares?
The wikipedia article describes it well Coupling (computer programming).
Interfaces and events are usually used to decouple classes or BPs in this case.
In design terms, a simple example would be the classic “Interact” objects problem, which I’m sure you familiar with.
You have several types of objects, switches, chests, crates, terminals and so on, with whom you want to interact. So:
Something like that.
Didn’t know about this plugin. Thanks.
Tight coupling it’s not an issue per se. The more independent a class or system is, the easier it’s to change, test and escalate.
Also, a good example of dependencies gone wrong in BP, is when you try to use a reference in a BP of something that doesn’t exist yet, and results in a “Accessed None…” error.
Making things as losely coupled as possible is just good practice.
Ok, I’m with you. But a tight coupling isn’t a bad thing.
Also you have the concept of symbiosis, that’s a good thing.
If it’s an issue, why does the BP compile throw a wobbly when you try and do it?
Sure, but that’s a separate thing.
But… say I decide to get around the problem with BP interfaces. I have BP-a, implements an interface. Then I come along with BP-b and I want to call the interface on BP-a, I still need a reference to it, to be the target. So I’m back to square one, no?..
Right, but when you call ‘off’ in the switch, you are referencing a class specific function.
Also, again, if you used interfaces, you would still need the actor reference as the target for the interfcace call…
:-/
Sorry, don’t quite it. If you want the switch to turn on light B ( out of A, B, C ), then you have to reference B to send the ‘On’ interace call, no?
( maybe I’m missing something fundamental here )
Of course, you have to reference Light B in the switch instance, but the BP itself doesn’t need that reference to work correctly. As I understand from the programming notion, circular dependency means one module cannot properly function without another one, and vice versa, that’s why it’s called dependency. If two instances reference each other on a level, that doesn’t constitute dependency. Like if you put two people in the room, they can talk to each other and give commands to each other, but then they leave the room and they are their own beings. That’s my understanding.
Ok, maybe a small ■■■■■ of light at the end of the tunnel.
So my BP-a can just have an actor reference and call the interface on BP-b, even though it doesn’t know what it is.
But now, just about everything in my project is an actor, surely that’s worse, there’s more possible ways to create dependencies ( across the whole project, not just between two BPs ). ???
E.g. I have a switch that turns on a machine, the machine does its job, and then resets the switch. Of course they reference each other, but these references are just Actor variables/arrays, so the array may be empty or the variable null, and there will be no errors since you don’t call any class-specific functions, just send interface messages. I don’t think having individual actor instances reference each other fully qualifies as circular dependency in this case.
The Switch Reset is also done by interface; what I mean is my BPs don’t contain hard references to anything, they can send interface messages to NULL and it’s totally fine. In other words, there’s no dependency because the operation of the BP itself is absolutely independent of any other specific BP. The switch may turn on any actor that implements the given interface, and any actor may reset the switch if needed. You just show the instances what to affect.
The key point: BP-b doesn’t care about what BP-a is. It doesn’t matter if it’s an actor, character, a pawn, an actor-X or Y.
To be decoupled, you can’t create in BP-b a BP-a reference. If you do that, then, interfaces are not needed and you can just use references directly.
For example. If an overlap event in BP-b, you get the hitted actor but you don’t cast it to BP-a, you just call the interface. That’s decoupling: BP-b doesn’t need to know if it’s BP-a.
Following Tuerer, you can even save the hitted actor in a type actor variable. What it can’t be is a type BP-a variable.
The fundamental, is for the switch not knowing what A, B and C really are.
For him, they are just Actors, and if you want to have direct references to them inside the switch, then you put them in Actor variables and not in Light type variables.
But the moment you cast one of them to A or B or C, then the decoupling ends. Interfaces removes the need of casting.
Right. In fact, I answered your other post below, but that seems to have gone into the ether.
What I said was that surely if your resort to actor type variables, that’s worse because it opens up the whole project to be a possible region for dependency…
A real example here:
My save game → My structure definition → Actor A that uses this structure → Actor B → my save game.
I have routes like this all over the place. Is this bad?
Can you explain this route a little more?