I wish to be able to change the default settings of the child actor component inside the blueprint editor.
I know this is not currently a feature, so im also looking for a work around.
My situation is this, i am designing rooms in the blueprint editor with all of there various actors needed inside of them.
I am doing this in the blueprint editor and not the world editor because my rooms are connected to each other by procedural generation.
So my room is a static mesh, with some custom child actors in it to give it the functionality it needs,
for example i have a power system that requires node actors i made in c++ (the basically send âpowerâ to each other), now because i cannot edit any values of a child actor in the editor other then its transform i need to make a different blueprint for each time i want a different default value. for example they have a int thatâs editable anywhere, however it can not be changed once its in the blueprint editor as a child actor.
Example, i have a key that can have a int range of 5 (think of it maybe as a security clearance card)
i would need to make 5 blueprints of this key and then add them to the room as child actors to make all 5 levels of the key.
whereas in the world editor i can select its properties and make the key int exposed and editable. Meaning i can use one blueprint and change its default values on the fly.
example 2,
or a loot blueprint with a enum and you can select what kind of loot it will spawn, because you can not edit the defaults of the enum from the blueprint editor once its a child actor you cannot use it in the same way as the world editor.
So, what am i doing wrong? How can i get around this? have i done it all wrong?!
Ah, i have discovered that what i need to do is build a custom component. I dont think this can be done with blueprints, if a MOD sees this could they move it to the C++ forum? (thanks)
Does anyone know of a tutorial on making a custom component? i am trying to use existing ones as a template.
I think it would be a nice feature to expose properties of a child actor component based on its class type. Right now it just uses the default values of the properties but in this scenario it could be similar to editing values on a per instance basis, for example when you a blueprint in the world you can edit the properties per that instance. Anyways, just food for thought as Iâm sure it is also a difficult problem to tackle.
You could just cast to the child blueprint from values you set in the parent blueprint. Just make them public and then set the child blueprint values to be what the parent passes across when it spawns.
Hello,
To modify child actor, from return value of the âadd child actor componentâ drag a âget child actorâ, âcast toâ your blueprint type and modify what you want.
I recently tried to modify things in a child actor blueprint from its parent in construction script for procedural level : from return value of the âadd child actor componentâ drag a âget child actorâ (the blue one) âcast toâ your type of blueprint and reference it. Then using it to change value in child blueprint. It works fine but doesnât update visual elements. Blueprint needs to be activated by itself to update, so you canât just move it but, if you create a function / custom event in child blueprint with two set locations (+1 and -1) and call it in parent from your child actor reference once you have modify what you wanted, it updates.
IHMO thatâs a severe problem in the current implementation of child actors. Why is it still not possible to set class defaults in the details panel? That would allow a truly multi-purpose component system. ActorComponents do not work as a substitute (canât handle input, arenât allowed to to asynchronous stuff like timelines etc.)
Wow. Iâm having an issue with this as well. I donât think itâs acceptable that I have to create âsubclssesâ of my blueprint just so I can set a couple defaults. Why is it not yet possible to edit the defaults of an actor inside of a child actor component. Come on Epic. Be epic and fix this.
@Fen Has the right idea. It may not be perfect, but itâs a usable work-around.
To put it into simpler terms:
In the BP that will be a child actor, the one that you want to edit the instance of and will be within an âouter BPâ, make a Function that uses the values you want to change. Effectively an âUpdateâ Function that handles updating in-editor visuals/settings for that instance, that would normally be handled in the construction script.
This Update Function can be called in the construction script normally, but more importantly can be called by the âouterâ BP this will be in.
In the âouterâ BP that has the child, make another âUpdateâ Function that:
Gets a reference to the child actor using âGet Child Actorâ,
Casts it to the class of the child actor,
Sets the values you need changed in the child actor,
Calls the Update Function within the child actor.
This doesnât technically need to be a function. If you do it all in the construction script, itâll work just fine. But having it be a function keeps things neat and allows you to mark the function âCall In Editorâ for an easy button-press test if itâs not in the construction script.
Have variables for the child actorâs values, on the âouterâ BP. That way you can modify them in-editor and see updates.
As an example, I haveâŚ
An Animated Door BP that has a bunch of variables for the kind of door, single/double door, open state, movement method, etc.
A Level Streaming Volume BP that handles level streaming when interacted with.
I want the Animated Doorwithin the Level Streaming Volume, as a child actor that I can adjust for single/double doors, etc.
I set up a bunch of variables in the construction script of the Animated Door to update the door when changed. I selected all that in the construction script and collapsed it into a Function I called âUpdateDoorâ. That function is still called in the Construction Script, and works fine.
I added the Animated Door BP to the Level Stream Volume BP as a Child Actor, and canât update the Door any more. So, I have to get a reference to the Child Actor, cast it to Animated Door BP, and set the values from there. However, that alone doesnât update the child actor instance. I need to call the UpdateDoor function after I set the relevant values.
I suspect the reason direct editing of child actor templates within a parent BP isnât a thing already is because of nesting. How many layers worth of child actors can be within any one BP is effectively limitless, so to make all of that editable in the outer-most instance would be insane, even with details drop-down categories.
