I would like to select an actor, either with a basic selection or through for-each loop functions or some other sorting method, and then check every blueprint attached to the chosen actor for a variable. The output would be a bool. I’d like to have the blueprints that returned true into an array and then be able to cast to those blueprints without needing to name them for the sole purpose of editing the variable within selected blueprint that I had checked for earlier.
As to what this would be used for, I feel it might offer more options within the blueprint system, to be able to cast to blueprints that fit a criteria rather than by name. An example would be I have a blueprint that performs an action on anything it touches. I have two other differently-named blueprints that each have their own “health” variable. I’d like to set the health of both blueprints to different values (one to 2 health and one to 5 health) without needing to cast to either’s name (in case I come up with 50 or more blueprints with different names all with health), without needing to use the child-of-actor-blueprint system, without needing to set up an interface, and without needing to have health be set to its own individual blueprint. That’s not what I’m currently working on- just the first example that popped into my head. I’m sure many more examples of specific variable editing can be come up with. I’m sure there are multiple ways to go about doing what I am suggesting, but a “variable-search” system option that can go through blueprints attached to specific actors may open up more room in terms of what users would be able to get done.
I’m sorry for the late reply. I think a better title for it would be ‘Get-All-Classes-Of-Variable-From-Selected-Actor’ Blueprint Node. What I meant before was that I don’t want to have to cast to a blueprint via its name. Yes I want to cast to it, but not by me having be required to remember or even know the name of the blueprint in question. It would simply be another way to help deal with multitudes of blueprints that all have variables that the user would want to edit. Its an alternate route to take within a single node, rather than being forced to mention by name every single blueprint affected and rather than being forced to use interfaces and design your system around an interface that may over-complicate your project, especially when working in teams where the other programmers must go through each blueprint, interface, enums, etc. just to figure out how everything holds up together. If it uses casts or interfaces under the hood in the C++ coding, it does not matter to me as I am requesting that this feature be implemented within a singe Blueprint node with an actor input, a string input (for searching for the variable in question), a bool output, and a class array output.
In the example picture, I have two separate characters who are not tied together in any way. They have different camera setups, different controls and they are played in two very different ways. One is not and cannot be the child of the other. I could have 50 different controllers like this. Each of them has their own “health variable” or “unpause game” function that I would like to call. I understand that there are ways to do this. However, I believe my suggestion above would prove to be good enough to warrant it as a future feature.
Then you have your architecture setup wrong, make a master class that is the parent of both but implements none of the “custom” parts of either, place the common functions inside of that master class and re-parent them to it, you can literally do this now to both of those without issue.
Both characters remain unique and are not parented to each other but they now share some common functions that you can call by casting them to the base class.
Your suggestion would be a very slow version of this, as it would have to sort through the UProperty References for the specific var type/name instead of just directing modifying it in the parent space.
That or use an interface, which would be less ideal here unless you want non characters to also share the same variables and functions.
I think the point I was trying to make has been missed. I know that there are other ways of doing this like by going through the trouble of making an interface and making all blueprints revolve around the interface, or properly creating parent classes. However, with the parent class suggestion, I’m having a hard time imagining that it can be done simply, easily, or within a small span of time with say 50-100 separate character classes that have each already been created, possibly even in separate projects that have been moved into a single project. I’m not asking how to go about doing it. I know how to go about doing it with what is currently available. What I am doing here is making a feature request to help simplify processes through the use of a singular node. Can no one see the benefit of having it done through a single node without the need to set up anything else like an interface? I’m not just talking about characters alone, but any large number of different blueprint classes that may share variable names. Again, I’m not asking for help on any specific issue. This is just a suggestion for a single blueprint node that I know for a fact I could make use of.
While this is technically feasible due to the reflection system, it is an incredibly bad way to architecture something - and components and interfaces solve this problem in a much better way. Generally speaking if you find yourself fighting the engine to achieve some end goal, you’re system is probably badly designed.
Adding support for something like this wouldn’t be optimal. You would have to iterate through all UProperty*'s of each class, cast to the required type of UProperty*, and check it’s name against a provided name. Neither of those things are even remotely efficient.
Also: such change would open a door to hell.
Once in engine, it would be rarely used to solve described issue. Unexperienced users would abuse such function, they would partially ignore concept of objects and proper data structure. The performance and entire project’s structure would suffer badly.
All characters in game should inherit after single class. Or few classes, i.e. some characters actually inherits after APawn, not ACharacter. It’s gamedev 101.
If this was ignored in the given project, you probably encounter many other issues: duplicating methods, data, default values. And then you pay a cost of maintaing so many different scripts.
Solution for this can’t be an engine feature that creates loophole for OOP.