When you want to populate a List View, you need a WBP class with list entry interface. There are two. “UserListEntry” and “UserObjectListEntry”. I know how the object one works but it’s a bit clunky as you need you own object class. I was hoping the UserListEntry is a lighter weight version where you don’t need to define your own object class to store the entry data in.
If I set WBP class to have UserListEntry interface, it can be selected as the Entry Widget Class in the list view, but how would I then add entry to the list view?
With UserObjectListEntry it’s simple, since the Add Item function of the List View takes UObject, but if I am using UserListEntry, not UserObjectListEntry, how do I create the entries in ListView? Or in other words, does anyone know what the UserListEntry interface is for?
Isn’t UserListEntry a base class for the UserObjectListEntry. Afaik you must have an object to get it to work with UMG. Perhaps more diverse functionality was planned for this at some point.
edit:
#include "UObject/Interface.h"
#include "Kismet/BlueprintFunctionLibrary.h"
#include "IUserListEntry.generated.h"
class UUserWidget;
class UListViewBase;
class IObjectTableRow;
/**
* Required interface for any UUserWidget class to be usable as entry widget in a UListViewBase
* Provides access to getters and events for changes to the status of the widget as an entry that represents an item in a list.
* @see UListViewBase @see ITypedUMGListView
*
* Note: To be usable as an entry for UListView, UTileView, or UTreeView, implement IUserObjectListEntry instead
*/
Somewhat unrelated: interestingly enough, the last time I played with interface inheritance, I could not get it to work. Unlike the base, the children can have the implementation but cannot be added as the actual interface. So not sure how that is supposed to work, or whether it’s supposed to work in the first place.
I am still confused by this. To have list view working, you need a List View UMG element, then a Entry Widget Class which describes how entries UI looks like, and then on top of that a UObject class which describes what the entries contain.
What’s really ugly here is that the UserObjectListEntry interface’s “EventOnListItemObjectSet” even returns just top level object class:
So one has to cast. For every single entry in the list view, user has no choice but to cast despite usually being certain what the object class will be. I can imagine this getting very expensive on long lists.
Maybe I am doing something wrong, but to me it just doesn’t feel right having some interface return me parent class of the object I know the final class of in advance, and then having to cast for something as minor as a list view entry
I just don’t understand why the Entry Widget Class could not also act as a the carrier of the data, instead of being separated just to take care of the graphical interpretation of the List View entry.
Aye, it seems so. The thing is that you do not need to push in a base uObject. You can push whatever you want as Item, providing it inherits from uObject, and everything does. Hence the need for casting. If you have a bunch of actors, pawns, or something with deep inheritance chain, you can actually use that instead of the additional uObject. As in:
I just don’t understand why the Entry Widget Class could not also act as a the carrier of the data, instead of being separated just to take care of the graphical interpretation of the List View entry.
Seconded and agreed - I’d like to push in a struct (by reference!) please! @Epic
But I am afraid there will be no proper way to handle the representation of that struct in the list
I guess it makes sense that the items in the list view can be of totally different classes, and you could then use chain of casts to determine what they are. It certainly gives some flexibility, but it sounds really inefficient from performance standpoint, since we are talking casting in BP and list usually existing to display large counts of entries
It is UE5, yes, but I don’t remember if it was already possible or not in UE4 You can grab AddItem in UE4 and see if it takes an asset or a subclass of UObject
Overall, I was also very wary of UE5 at the start, but when I ported my quite complex RTS game over, I was quite surprised nothing broke. Even physics remained surprisingly same despite Chaos replacing PhysX. That game is a giant cobweb of blueprints, yet everything survived. I was also expecting lower performance due to the engine bloat, yet I actually got even slightly better framerates.
It does not. Best I can do is to push in a material function, see what that breaks ;p:
Overall, I was also very vary of UE5 at the start, but when I ported my quite complex RTS game over, I was quite surprised nothing broke. Even physics remained surprisingly same despite Chaos replacing PhysX. That game is a giant cobweb of blueprints, yet everything survived. I was also expecting lower performance due to the engine bloat, yet I actually got even slightly better framerates.
Impressive. I’d call it a testament to your own skills tbh. Last thing I remember you working on was a minimap camera frustum. I think!
I dread converting to UE5, don’t want to even think about it. Also, aren’t they going to phase out PhysX completely at some point? I was under the impression Chaos will take over fully - meaning redoing everything simulation related.
PhysX is already completely gone in UE5 AFAIK. But they’ve translated pretty much every PhysX parameter to chaos one, so from the UI standpoint, nothing changes. Unless you use PhysX to do something really deterministic in your game, which gameplay relies on, I doubt you will even notice there’s a different physics engine running it under the hood.
Oh! Somehow I missed that VERY IMPORTANT tidbit! I could not care less about the deterministic nature of it all but I do have a bunch of somewhat involved PID controllers.
Looks like you’ve given me plenty of homework… See you lads in UE5, possibly in about a month. Clocking out.
So not sure how that is supposed to work, or whether it’s supposed to work in the first place.
Also, aren’t they going to phase out PhysX completely at some point? I was under the impression Chaos will take over fully - meaning redoing everything simulation related.