x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

[4.7] - Defaults are zeroed out upon BP Construction

Hey Guys,

I am having an issue right now where the default values within one of my Blueprints are being zeroed out before the Construction Script is being run. I eventually realized that I had to manually click the reset button next to each field in any BP that inherited that base class however it is not letting me reset private variables.

What I am having to do is manually uncheck private, reset the field, then click private again as a solution. Is there an easier way or is this an issue with the BP's being upgraded to 4.7 where it should be taking the inherited default value?

Also, considering its private, shouldn't parent BP classes not have the ability to override the default value?

Thanks again!

Product Version: Not Selected
Tags:
more ▼

asked Feb 26 '15 at 02:24 AM in Bug Reports

avatar image

MC Stryker
453 22 37 48

avatar image Ohriginal Feb 26 '15 at 02:40 AM

I am experiencing the same bug. If you have a parent class with a float with default value of say 100, and derive a child from it, the child's default will become 0 when you restart the editor.

avatar image MC Stryker Feb 26 '15 at 02:44 AM

I just figured it out, go ahead and uncheck those variables as private, go into the child BP that are hiding those defaults and you should see it's set to 0 but has the yellow reset icon next to it. Click that then go back into the Parent Blueprint and set it back to Private again and recompile. It's a little bit of a pain but it does the trick :D

avatar image MC Stryker Feb 26 '15 at 02:40 AM

Thankfully that trick worked and now my Pawn is working again! But I'm guessing a bug took place when upgrading the assets from 4.6.1 to 4.7 and should've carried the defaults with it.

  • My only guess as far as how you could replicate it to look into further is create a new project in 4.6.1 and create a Blueprint w/ Pawn or any Actor as the Parent Class.

  • Create a variable that can store a default value and set it to some value other than 0 but make it private. Then create another Blueprint that uses that previous BP as it's parent.

  • At that point the default should be the same or probably not visible since it's private.

  • Go ahead and retarget that project for 4.7 and you should notice that if you uncheck private on the first BP, go into the second BP you created that is the child of the first, you will now see it's set to 0 and likely has the reset icon next to it.

Hope this helps and thanks again!

avatar image MC Stryker Feb 26 '15 at 04:04 AM

For some odd reason, this only works in the editor and not in Standalone mode. I am still getting zeroed values and its not changing even after doing the trick. I am going to try and clean my build and rebuild it in Visual Studio in hopes that makes the difference but now I'm confused. Hopefully that takes care of it but its almost like what is being used in my Standalone Build is not being recompiled. As a note, I got the same result from Packaging a build. The mystery continues... Ohriginal, if you figure anything out, keep me posted. Appreciate it.

avatar image CodeSpartan Mar 01 '15 at 07:46 PM

Also experiencing the same bug, for both public and private variables of all types. It's a very nasty issue so hopefully it it will get fixed soon!

Does setting the derived bp's variable to a different vaue than the parent bp fix this for you? It fixes it for me, so I just zero the parent's variables however it's still a very annoying bug.

If someone from Epic is willing to look into this, I can email a project with this bug.

avatar image Ben Halliday STAFF Mar 01 '15 at 08:58 PM

Hi CodeSpartan,

If you're able to put together a small test project for us, that would be great! Just put it somewhere online and let us know the download link. Thanks!

avatar image CodeSpartan Mar 01 '15 at 10:31 PM

Hello,

I've managed to narrow it down to what seems to be a circular dependency issue.

To reproduce:

1) create a MyCharacter blueprint, add an int variable and set its default value

2) create a MyCharacter_Child blueprint, based on the first blueprint

3) create an UMG widget with a button that when clicked, gets the player character and tries to cast it to MyCharacter_Child

4) in MyCharacter blueprint, create that widget in BeginPlay

5) close the project and reopen (you don't even have to click play) - the default value of the int variable will be reset to 0 on the child bp

avatar image redbox Mar 01 '15 at 08:46 PM

Similar issue here. I have few booleans in parent BP, and It's not private.

When editor starts, this booleans set to "True" in parent BP by default. It's ok. But all childs have this set to "False".

If change value in parent BP from "True" to "False", and vise versa, and recompile parent BP, all childs get this parameters with last saved in parent (in this case - "True")

avatar image Ben Halliday STAFF Mar 01 '15 at 08:57 PM

Hi all,

This issue has been assigned to a member of our staff who will begun looking into it as soon as possible. Thanks for your patience!

avatar image MC Stryker Mar 01 '15 at 11:40 PM

Thanks Ben for the update, looking forward to the fix! Hey CodeSpartan and redbox, does this happen to you guys only in Standalone Mode? I had this happen but what I had to do was to uncheck Private and manually set the default in any BP that inherited that base that contained those variables. This worked in the editor but still doesn't reflect in Standalone Mode, Launch or packaging a Staging Build.

avatar image CodeSpartan Mar 01 '15 at 11:50 PM

This happens for me for both public and private variables so I didn't try the workaround.

avatar image MC Stryker Mar 01 '15 at 11:56 PM

Interesting. It definitely is some issue with inheritance. In your example above with MyCharacter_Child, if you look at the values of those variables there that come from the base class in the child class, do the defaults in the child BP have your original defaults or are you seeing a 0 in there?

avatar image CodeSpartan Mar 02 '15 at 12:19 AM

If I leave the defaults unchanged, they are zeroed to 0 after the editor restart and the yellow arrow appears. For example if in parent I set the variable's default value to 200, and save both blueprints, the child's default value of that variable becomes 200 as it should, but only until the editor restart.

avatar image MC Stryker Mar 02 '15 at 03:05 AM

Gotcha, well I'm hoping the issue gets patched for the next hotfix. Let us know Ben if there is anything additional you need us to test. Thanks!

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

1 answer: sort voted first

Hi all,

We believe this is related to the issue reported here:

https://answers.unrealengine.com/questions/177658/floats-read-0-in-47.html

which states:

This was caused by default values for inherited values being initialized to zero, rather than the values in their 'super' blueprint. For instance, lets say I have two blueprints: BP_Super, and BP_Child. with BP_Child being based on BP_Super. Values in BP_Child could show up as 0, even if they were set to something non-zero in BP_Super.

Thanks for pointing that out, Slavq! There is a GitHub pull request located here that should resolve the issue for you, that will be included in the 4.7.3 release:

https://github.com/EpicGames/UnrealEngine/commit/5b06ef7cd541deb6dc0c57fc7ed19868ba7a1916

Thanks for the reports, everyone!

more ▼

answered Mar 04 '15 at 01:50 AM

avatar image MC Stryker Mar 04 '15 at 03:06 AM

Thanks Ben for the update!

avatar image CodeSpartan Mar 04 '15 at 05:28 AM

Guys, don't try to add those changes manually, let's wait for 4.7.3. I tried to add them and rebuilt the engine and it broke custom enums in my project (I have version control so it's ok)

avatar image MC Stryker Mar 04 '15 at 07:12 AM

Thanks for the heads up CodeSpartan and glad to hear you had a backup.

avatar image John Alcatraz Mar 11 '15 at 05:15 PM

Ben, I am using the 4.7 branch from yesterday and the issue is not fixed there. If I set a default value for a struct, save the blueprint, close the project, open the project, open the blueprint, all variables in the struct are set back to parents defaults.

avatar image Sandstrike Mar 11 '15 at 06:44 AM

The following probably relates to the answer but just in case:

I found that the default values for the skeletal mesh, animation blueprint etc of the child actors also get set to none when launching a standalone (this doesn't happen in PIE). Can anyone else confirm this?

avatar image Slavq Mar 11 '15 at 01:01 PM

Yes, my anim blueprint (and skeletal mesh settings like position/rotation in some cases) was resetting after playing in Standalone or packaging game - HERE is the bug report, and as they say, it should be already fixed in 4.7 (Zak Middleton managed to fix it), but i didn't checked it yet...

avatar image MC Stryker Mar 18 '15 at 01:26 AM

Hey Ben... this now seems fixed for me however, the post above from CodeSpartan relating to Enumerations being broke is now an issue for me but it's not as bad as it sounds thankfully. I checked and all the enumerations are intact and correct and when you run in the editor, any enumerations converted to text to be displayed are fine. However, when you run in the game as Standalone as it's own process, it doesn't properly list them and all come out as the default: NewEnumerator0... NewEnumerator1... etc. I also filled Eric K. on another thread who is lending a hand. Thanks!

avatar image Ben Halliday STAFF Mar 18 '15 at 01:28 AM

Hi MC Stryker,

Glad this problem is fixed for you now! If there isn't one already, would you mind opening a new post for the Standalone enum problem? Thanks!

avatar image MC Stryker Mar 18 '15 at 01:31 AM

Absolutely, hope you and the team are having a great day!

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question