Hi Steve,
Yeah, that’s true in the case of weak pointers but most of our problematic use cases involve soft object pointers to actors where the path changes due to PIE remapping or due to WP runtime cell paths vs editor paths, but the string paths stay unique since the actor is only inserted once.
I suppose though you could have two entries for the same actor, one with the editor path and one with the runtime path and then after canonicalizing them there are now duplicates, which you are right, is problematic.
Is it safe to use the FName of the actor as a key since I believe those are unique in WP and not remapped? There isn’t a nice already existing smart pointer type though. I would say basically all of our use cases here that are not trivial to replace are actors so maybe having a specific TSoftActorPtr vs using the generic TSoftObjectPtr that internally just used the actors FName + Level or something to make then safe to use as container keys? I guess we could make this manually by using FNames but then you lose a bunch of ergonomics in BP and also things like editor eyedropper etc.
Anyway, thanks for looking into this. I’m mostly just elaborating on our use cases incase it’s helpful for Epic’s future plans. My problem is solved for now.