It was. Also, every commercial project I’ve ever worked on has had it’s own set of containers, along with very strict coding guidelines to never ever use STL. Sometimes, a project’s container is backed by STL, but it’s pretty much always better to have your own layer between your app and STL, so you can replace it when you find that STL is not sufficient.
Outer is freakishly weird. Owner is usually pretty obvious. I don’t think I’ve used Outer since UE2.
… ? Constructors run on any instances… they’re just … often not useful, because most things people would want to do in constructor are better done in something that occurs after construction. Data saved in your blueprints are loaded after constructor. The item doesn’t exist in the world until after constructor. The things that you can do in a constructor are relatively limited, simply because most of the time you’re going to be dependent upon values that simply do not exist at construct time.
Also, yes, there is a “Class Default Object”. When you use a class for the first time, an instance is created. So the constructor is going to be called for the default object, as well as any objects that are in world. pretty decent thread talking about that: What is CDO? … there may be others as we ll
That depends on which subsystem type you’re using. I have a GameInstanceSubsystem that is able to GetWorld(). Subsystems that are initialized prior to that may not be able to GetWorld() especially during initialization. I’m not positive if GetWorld() after the fact works, I think it does not, if the subsystem existed before the world did. I didn’t really take notes on it, but I have a Plugin that has a EngineSubsystem that does some things, and then I have in my game layer, a GameInstanceSubsystem that refers back to the Plugin subsystem to add additional functionality that is only available once there is a World available. I believe I did that because it wasn’t possible to directly access World in the Subsystem even after the world was created. It may have just been because it was easier to work with. I don’t 100% remember. But I did do it that way.
I haven’t done any work in UE5 yet, but I’m told that the situation is much better in UE5 – other devs that I speak with regularly have said that the improvements in Live Coding in UE5 that allow for most classes to be completely reloaded, have made using Live Coding a big improvement over it in UE4. In UE4, Live Coding only works when you don’t materially change the structure of an object, but in UE5, you can do that.
Pre-Live Coding, i avoided doing native coding as much as possible, but these days it’s pretty decent. (I do wish there was an obvious way to turn off use of distributed build systems while doing live coding, though!!! distributed build is amazing for long builds, but for short builds, it just really gets in the way)