Error message: Can’t connect ‘As child Class Ref’ and ‘Target’ : ‘child Class Ref Reference’ is not compatible with Self Reference.
This always happens when I try to call an overridden function inside a blueprint of the parent blueprint class after casting to a child-type (with a valid reference).
The function is always forced to be the parent version and the child version cannot be called.
.
.
Solutionish workaround
You need an external source to call your functions. A function library works perfectly well. Just create a function with the same name and the same inputs + your baseclass reference. Just call the function you want with your base-class reference and it’ll morph to the proper child class.
Ups and downs:
++ This workaround won’t stop working when the original problem is fixed. You can just leave it like that and lose a tiny amount of cpu-time (neglectable in most cases) or take some time to fix it.
– This workaround is really really unhealthy for your workflow. Every single function you fix like this will be visible from everywhere (you may pack them into groups like ‘uglyChildFix|myClass1’).
You can do some precomputing and/or input adjustments without another extra call (that’s a tiny little plus, bad method but still viable if you don’t care)
This might work with a macro library as well (no extra function call, no parameter passing) but it’s not worth testing for me and I really don’t want to put more time into this…
I don’t really get why you even have blueprints. Whenever I try “fast prototyping” with blueprints I encounter problems that stem from unfinished/bugging “features”. This is a basic programming feature that really simplifies a lot of things.
This might not be easy to implement but I really do not need 5 different ways to “align” my nodes and/or describe functions and macros. I need my functions and macros to work.
I’m sorry to hear you are having trouble with blueprints. Are there any specific sticking points that may be causing trouble or specific bugs you are running into that may not yet be known? I’ll be happy to take a look. Additionally, we do have access to C++ if you prefer programming.
90+% of my probject is c++ code because whenver I try blueprints I run into an unsolvable problem.
What I want right now (all my previous problems got my own c++ implementation):
Build an Entity through blueprints that has the following characteristics:
Be made up of parts
Parts are made up of the same parts as well (example: part a contains part b and part c; part b contains part c as well)
Parts may contain visual and/or effect properties
Parts may change results for any effect/function (for example: resultingDamage = part_n.reducedDamage(x) will call the reducedDamage(value) function provided by all children to compute the end result)
Parts may change basic behavior like NOT calling child functions to compute results
I am well aware that this can be archieved iteratively and/or with my own function tables. Sadly this would blow up really fast without polimorphic recursion.
With recursion adding a part with medium complexity takes between a few seconds and 5 minutes mainly depending on how complex that part is. Without polimorphic recursion adding a part takes between a few seconds and a few centuries; mainly depending on how many parts were already added.
Serious question though. Why can’t you just warn me about problems as soon as I create a child blueprint? Today I ran into 2 problems with them and the whole day I wasted because I was looking through my code again. Only to find out it’s a known problem. This is my hobby, I like programming a lot. Enough to have payed for the engine before you made it free. Sadly I don’t have as much time as I wante and I lose days to editor bugs on a regular basis.
.
PS: I’m not upset with you and this is not meant to be rude. I’m just upset with the fact that everything blueprint-related takes ages till it runs.
Right, you want another problem? 5 minutes after posting my last post I got the next one. I am currently working on a workaround for the previous problem (and I think it’s manageable through function libraries becasue they are calling from outside the class).
Child List provides a list with actor references. The standard implementation returns an empty array. The overwritten function, however, provides a filled array.
Currently the ShipPartInitialize function just prints the name of the ship part.
With the “ForEachLoop” connected (exec and array element pin connected), I get the error ‘Accessed None ‘ShipPart’ from node Print String in graph ShipPart_Initialize in blueprint ShipPart_ExternalCaller’.
With the get(0) connected it prints the class name and whatever else I want.
.
PS: I’m not upset with you and this is not meant to be rude. I’m just upset with the fact that everything blueprint-related takes ages till it runs.
Is this the best working version cough or because of some engine update? If this is just an engine update error, how do I get the working version back?
Have you tried utilizing child blueprints for this? If you create blueprints a, b, and c, then have b and c be children of a and c a child of b, then you can add all of these to your main blueprint as child actors and interact with them individually for the functionality you are looking for. By utilizing child blueprints you should be able to accomplish exactly what you are looking for here.
It looks like your foreachloop may have been improperly updated during an engine update. On my end in 4.10.2, it seems to be functioning exactly as I’d expect:
Where are you populating Child List? It may be a problem where the array is not getting populated fully or receives a null value, so it throws the error in response. Additionally, try running a verify on your engine build through the launcher>library>4.10 context menu>verify to repair/replace damaged or missing files.
It has to be dynamic. Let’s say I want to aquire an additional weapon for my spaceship. Or a shield. I can’t decide what the player wants before he does it. It may as well happen that part a contains another instance of a.
Doing that would be easy if parent-child relations would be working as intended. Since I already found a workaround (updated main post), I do not need another method. Without the workaround it’d be rather hard.
It works properly with my own loop (and this fixed version). I just never expected the base macro to not work. I just randomly double-clicked it or would have never found it.
