Make Array Stopped working correctly with polymorphic types in 4.18

Hey!

In 4.18 when making an array in blueprint it always changes its type to the first object that is dragged into the array, even if the array already has a type specified. See images below for a better explanation. Note: I have acess to the UE4 Perforce, I’m also using my own compilated engine so I have no problem applying changes if this has already been fixed.

First Image: I made an array node from the children input node. The type becomes composite widget.

Second Image: I drag the UMG content browser objects into the make array node and the type of the array becomes “Content Browser Object”.

Third Image: I now instead use the search box as the first pin dragged into the make array and the type of the array becomes “Text Input Box”.

Fourth Image: I Construct a composite widget and drag that as the first type into the make array and now I can connect all the input pins since the type of the array remains as “Composite Widget”.

The best practice with those is to disconnect the array pin first. Connect the widgets and then AddChildren. The panels do not care what type the child is, but the index and array pins on the MakeArray node can be a bit fiddly.

This is also quite noticeable on the Select node.

Hello thank you for your answer. Unfortunately this does not either help, I get the exact same problem as stated in the question using this method. This has not been an issue prior to 4.18 so I suspect that this is a new bug specific to 4.18 rather than me actually doing something wrong.

(I base this on me having used the make array node since like 4.15 without any problems at all)

Not sure if that helps but I’ll clarify what I meant:

222789-untitled.png

Do note that I did not even select a class for my widget.

The moment you set type of the pin in the Make Array node, the returned array becomes of the same type. So the best way of working with make array is to make its type the base parent class. This will not work if the array pin is connected, though.

If you make the first pin a UserWidgetObject, you can then connect any user widget to any pin and the output array will still be UserWidgetObject, acceptable by any UMG panels. (this will not work for native widgets like stand alone buttons)

In your case (screenshot 2):
You’re making the first pin UMGContentBrowserObject type, the second pin cannot accept anything else anymore as the whole MakeArray became of type of the first pin.

In your 4th screenshot, you can disconnect pin 0, and remove it altogether and it will be fine. Apparently both of your widgets inherit from the CompositeWidget.

Ah I see what you mean. This is what I’ve done to solve the issue, I construct a CompositeWidget and plug it in as first pin and then remove it when the rest has been plugged in. Though this is no solution at all. In my opinion this is only a hack to make it work and I shouldn’t be required to make this a part of my workflow with make arrays.

Since my old method of just plugging in nodes of same inheritance into the make array worked until 4.18 something has to have changed in 4.18 which caused the bug I am experiencing. So while I appreciate your answer it is unfortunately not a solution to my problem. Since it’s likely something Epic have to fix on their end.

In my opinion this is only a hack to
make it work

Hard to disagree; it is a hack in a way. Ideally, the pin could have a dropdown for a superclass. Like the Select node does:

222869-untitled.png

Sorted.

From my experience, the behaviour has always been like this but if you asked me to bet my £££ on it, I wouldn’t.

So while I appreciate your answer it
is unfortunately not a solution to my
problem. Since it’s likely something
Epic have to fix on their end.

It would be a nice feature to have, agreed. Consider starting a thread in the [Feedback Section][2] and link this issue there for better visibility. If enough interest from the community is shown, Epic’s staff will step in and add it to the ever-growing list of requested features.

Upvoted, hopefully it makes a difference.

Good luck.