Every time I change a Material in a base class, it completely overwrites my parent BP’s Material forcing me to go back to every single BP and change them back to what I had originally. I would have to do this every single time I need to change the Base Material. This has already created a couple holy crap… oh no moments today so I hope Epic is able to issue a fix quick on this one
I think it was mentioned by Tim Lincoln or Stephen Ellis on the forums that a fix for the parent/child editing issue was already finished. Please fix this issue and implement the other regarding base properties not being editable by the Parent in 4.9 in the first hotfix. These are very serious issues that are unfortunately going to complicate production until that happens.
I have another game I’ll keep in 4.8.3 for the time being but I’m keeping my eyes peeled for another hotfix
Thanks guys and let me know if you need any further info. Take Care!
Thank you for taking the time to create this report. Would you mind providing me with some simple reproducible steps so I can get this issue to appear on my end in a clean 4.9 project?
The issue Stephen mentions here could be unrelated, but to make sure I would like to get this issue to reproduce on my end.
Much appreciated buddy and absolutely. I think this should work but try to simply create a Blueprint with a Mesh Component. Create a parent BP and change the Material on the parent. After re-compiling the BP, go back to the Base BP and change the Material there then re-compile. It should override the Material in all Parent BPs.
Let me know if this works and hope all is well Andrew!
I ran some tests on my end and think I found where you could be running into the issue.
So in order to change the material of the Parent Blueprint I also need a mesh component, so the Base Blueprint (Child Blueprint) can inherit the properties of the mesh and materials.
I created the Base Blueprint and added the Static Mesh as you suggested and referenced my Parent_BP as the Parent Class. I recompile between all of my steps just for your clarification.
Here is where I believe the problem is introduced. If your Parent_BP has a static mesh with a material on it, and you create a Child_BP referencing the Parent_BP as the Parent Class, it will inherit the static mesh and the material as well.
In other words, if you create a static mesh within the Child_BP and then reference the Parent_BP that already has the same static mesh within, you will now have two static mesh components in your Child_BP. They will be in the exact same location, and if they have different materials you are going to get Z-fighting between both meshes attempting to render their material on top of on another.
Here I have placed both blueprints in my scene so you can get a better visual of the Child blueprint inheriting the Parent’s static mesh. From this I was unable to reproduce what you are reporting here. Let me know if you still need help.
Okay, so the base Blueprint has a StaticMeshComponent however there isn’t a secondary mesh thankfully in the Child BP so I don’t have to worry about the Z-Fighting between 2 meshes so all good there.
Now, I might actually be wrong but I could’ve sworn that all past builds, I could change the Material on the Child BP and if I ever changed the default for the Parent, that it didn’t alter the children since they were one step higher on the chain.
Honestly, I could be wrong because I typically create a Property ‘Material’ that is of the type MaterialInterface (so I can use either material or instances) and then in the Constructor (C++) or Construction Script in the case of BPs, I create a Dynamic Material instance (if needed or simple Material Instance instead) and apply that to the Static Mesh upon construction of the Actor.
I’ll have to test this with 4.8.3 to see if I’m not loosing my mind here
Now granted in theory, since its a Child I do think it should override anything on the parent if that’s possible with how Blueprints are put together underneath the covers and would be extremely helpful if this never existed but maybe I’m guessing with variables/properties yes, but the properties of a component, no. In case its not like that, it would awesome if it could exist.
Let me do some testing for you on Tuesday to see if those yield different results and get back to you in case it did work different in early releases of the engine. I’ll do 2 tests, one like mentioned in this post and the other like I mentioned above where using an intermediate variable to handle application of the Material to the mesh.
EDIT: Actually, now that I think about it. I’m likely wrong. Because the component was setup in the base, and it’s not a variable we are talking about here. However, if lets say in the case of C++, in my child class, I could override variables of other objects in the Constructor before the object is instanciated and then in that case, yes this should exist. But BPs are a different beast all together and if Epic were able to expose that so you had confidence that any property or sub-property you modified in a Child, would never be affected by the Parent unless its already set to the default value anyways.
But we’ll catch up early next week and take it easy.
Okay, this must have been my confusion. I just created a Material Instance variable and made it editable. In the base class, I set it to a default material.
In the Child BP, I altered the Material Instance it was referencing, changed the one in the Parent to another, re-compiled and it did not alter the material set.
Because I was dealing with a Component Property in this case instead of a local variable, that’s why I got confused and what I mentioned above is likely why since the component was created in the parent.
If you don’t mind me asking, is it possible that in the future with Blueprints, we can change the value of a component’s property and maybe underneath the covers when the object is being initialized, it can set the value of those properties on the component if altered by a Child Class/BP? I think it would be helpful if developers can rely on any edits made in any children BPs and them not eventually altered due to a change in the parent if that change was on a Component’s property in this case. If that is possible, it would just make things that much better.
But thanks and let me know your thoughts on my question above when you get a chance. Thanks!
The idea is not a bad one, but I feel that would eliminate the purpose of the Parent/Child Blueprint workflow as you only have to edit a single value on one (Parent BP Component) to affect all of its children versus individual Blueprint edits.
I am pretty sure you can create a variable the is not public and is only exposed to the Child_BP so that when you edit the value, it does not translate to the Parent. I could make the suggestion you mention in a feature request, but I am pretty sure the developers would have a similar response to mine (that is unless I misunderstood the question).
In any case, I am glad we found some clarity while troubleshooting your issue, and let me know if you have further comments or questions.
Thanks for the response. Yea, the variable on its own does work like that but if it could be extended to properties of an object, that would be great. In the meantime, in the case of Materials, I’ll be using the additional instance variable to store/apply the material and don’t need to worry about it being altered by the parent.
Either way, much appreciated once again and hope you have a great day Andrew! Take it easy.
