I’ve been doing some googling and can’t find any official word from epic so hopefully someone can enlighten me. Are there plans for blueprint to properly/fully support scene components? To put this into context, Imagine a virtual control desk with buttons and sliders. Seems logical to make the desk an actor and the buttons and sliders can be their own scene component class so they can be self contained and easily configured. (for example a designer could make a blueprint of a slider class and easily visually swap out the meshes, adjust the scale, and see their work in the viewport etc etc. Only when you extend a scene component cpp class with a blueprint, you don’t get any wysiwyg control over individual elements (for example a slider backing mesh, the top and bottom ‘constraints’ etc. So my structure of Actor with many scene components that have their own children components defined in their base cpp class doesn’t allow easy designer interaction.
Is there a best practice that I’m failing to grasp? I guess you could handle all the wysiwyg design work manually in the actor that contains the components but this seems like it has potential to spaghetti quickly so I’m hesitant.
I know that a solution is just to make the sliders and buttons actors rather than scene components, but this seems both untidy, like it would lead to the use of child actor components for designer visualization (which were nightmarishly unreliable when I last tried to work with them in about 4.14), and like it would increase the complexity and work required for a clean network replication flow.
If you know of epics stance on this, or can correct any misconceptions I may have, I’d love to hear it before I decide which way I’m going to refactor my code haha.
Extra thought: My current approach is based on seeing, perhaps incorrectly, scene components as hierarchical ‘groupings’ of logic and child components. However I’m now just realizing that maybe all of that’s irrelevant because when I create a new scene component within a scene component, it might be no different to spawning it at the actor level?
Components are elements that compose actor, since actor don’t even need physical form and i does not need same physical form, components are things that define physical form of actor, this is there main function. Using it as component as a preset set of components is probably use case as you see components as that simply Epic didn’t predict, that why you can not preset child components using blueprint editor. And you need to remember that blueprint-made components was not avable from the start (aka 4.0).
Scene component as class is base of all physical components and on actor it is only used as dummy to group components in to single position so you don’t need to loop thru all of them to change something in them via code. But that not it’s main role as a class, it has core code for all physical components, so “grouping” use of scene component class is just hack using ANY scene component (this include meshes and such) ability to attach component one to another. It just can do this if you want to but it really was not made for that simple as that.
I actually wonder if you are aware of class hierarchy of USceneComponent, considering some components are deeper in the tree you might missed that USceneComponet class is actually base for all physical components and by that it obviues what it’s role is
There’s a bit of a language barrier but I think I understand what you’re saying, all of which seems like good info just not really an answer to the question.
I understand that originally you couldn’t blueprint components. My question in regards to the current functionality is more, “Do epic hope to improve on it in the future, or is this how they wanted it to be”.
I understand what scene components are and what they’re for (and agree with your description as far as I can tell), and that’s what I’m using them for in my cpp implementations.
I’m also aware of the SceneComp heirarchy and when I’m creating some custom scene component it doesn’t seem to make much sense to extend any of it’s children that I’m aware of - they each have a specific role/purpose, just as my custom scene comps have a specific role/purpose. (a difference being epic create scene comps in the OnRegister() of a scene comp, which definitely suggests my use case is unintended despite logically() sound)
I think the most important takeaway is I understand the engine doesn’t currently support nesting comps with blueprint, I’m just wanting to find out if this is because it’s yet to be improved, or because epic uses/wants us to use child actors for this kind of thing?
I don’t think so, components suppose to be code you attach to the actor i don’t think they see it as you see it. Child actor is to let you attach actor as component, but that does not change fact it is still separate actor just following component position. It’s not like Epic want you to use something in perticillar way, as oyu aware they might not see components the way you see it, keep in mind that at the end you always have option to write such functionality yourself one way or another if you see it fit in you use case, it’s not like you bound to what Epic is doing.
Well you could try write a suggestion in feedback forum because this was number one place for this kind of questions, i don’t know how much is readed right now by epic devs as i didn’t post there for long time but i can see Amanda posting there if feature is in route. Also you might be on good timing, 4.21 preview got just released that means there gonna be traditional new feature showcase stream on incoming Thursday, tomorrow or maybe next week, i think this is best chance to shoot this kind of question in there (you can ask questions during streams and they answered in the end) and you might get answer in matter of hour.