All of the user-defined variables in my Character blueprint are being repeatedly reset to zero. I’ve fixed the values again and again, but they keep resetting to zero. This happened one day when I editing my HUD blueprint. Suddenly I couldn’t move because the “CanMove” variable in my Character blueprint was set to false.
I’ve had this issue as well. All my Blueprints that were trigger boxes with public variables got reset to default value.
I can’t replicate this all the time, seems to be something that happens infrequently.
Hey eglynum-
At what point are the variables being reset to default? Is it when you close the blueprint or when you play in editor or at other times? Also, what are the variables supposed to control in the character blueprint? Keep in mind it’s always best to recompile after any changes made to your blueprints.
Cheers
I’m not exactly sure when it happens. Opening and closing the blueprint or playing the game doesn’t trigger it. I think Unreal has to be closed and reopened before it happens. I always save and compile after i fix the zeros. Here’s a picture of the variables that get reset. Some are set at run-time, but the one’s that aren’t (like MaxHealth and BaseTurnRate) are the problem.
Which template did you base your game on (first person, third person, code, etc.)? Also, which version of the engine are you working in and would it be possible to show where these values are being set?
We started with the first-person template. We are using Unreal 4.4.1. And the values are initially being set in the Defaults tab of the CharacterObie blueprint. After that they are modified at run-time by various blueprints (mostly within CharacterObie, but sometimes from other blueprints - CanFire for example is modified by an animation blueprint. Maybe it could help to mention that CharacterObie serves as the base blueprint for other derived blueprints.
I am still trying to find the cause of this issue. As xrouter pointed out, are the variables you’re using set to public or private? Also, what did you change in your HUD blueprint prior to when this bug started happening? Could you please supply screenshots of your HUD blueprint (what had changed).
“Team” is public. The rest are private. A lot of things changed in HUDObie. Here’s a couple of screenshots for before and after. I apologize that it’s too small to , it’s really just to show you how much changed. Most of it is gathering info about the player and calling “Draw Text”, “Draw Texture”, or “Draw Material”. Info about the player is being gathered by getting the owning player controller → controlled pawn → cast to CharacterObie → get info. The “AFTER” version also has some ray casting to see if it’s aiming at an enemy.
After manually resetting the values and playing the game in editor do the values reset when you stop playing? Is it something you only see when you open the project? Does the bug occur on a clean project that you add a variable to? I apologize for the barrage of questions, just trying to gather as much information on what is happening as possible. Also if you could post a screenshot of your HUD blueprint to see if something in there is causing the problem.
After manually resetting and playing the game in editor the values do not reset. Yes, it only happens when I open the project (and it happens every time I open the project). I’ve only work in this project, so I’m not sure if I could make it happen on a clean project. I thought of a couple other things that may be of interest. We use perforce with Unreal and there are frequently many files that Unreal wants to check-out and save that seem to have nothing to do with what I’ve been working on (like if I change the CharacterObie blueprint and it wants to save all the blueprints that derive from it), so I leave them locked and unsaved. Also, this project was created using Unreal 4.2 and it’s been upgraded through every version since.
Did you post the comment about wanting a screenshot of the HUD blueprint before I edited my previous post, or did you want a series of close-up shots to see all the details?
I had asked for the screenshots before you had edited, I can try working with those that you posted for the time being.
As for perforce wanting to save excess files, that is a known issue that is being investigated and will have a fix included in a future update.
For the variable defaults issue could you try to reproduce that in a fresh project. If so that would give us a place to start looking for the cause of the problem.
This issue didn’t show up for 2-3 months into development, and when it finally did, it happened unexpectedly. I don’t know what I’d do after creating a clean project to reproduce it, so I’m gonna pass on that for now. If you need any more info let me know.
Based on what we’ve discussed it sounds like some relation between your character blueprint and your HUD blueprint. Could you create a new project and migrate those files into it?
I created a new project based off of the “First Person Blueprint” template and migrated one of my characters (which included CharacterObie, HUDObie, and tons of other things). The zeroing issue seems to be gone. So now I’m wondering what’s the easiest way to migrate my entire project?
I had another thought while doing this. We started this project using the “First Person Code” project, then we decided to convert everything that was code to blueprints (code was to be used sparingly). Any thoughts?
While I don’t believe the strict process of converting from code to blueprint would cause the problem, it is possible that a reference somewhere was disassociated during the switch. If you are able to migrate your project over to the new one feel free to respond to this thread if the issue with variables resetting to zero shows up again. I would suggest saving and testing each part that is migrated to try and catch the portion of the project causing the problem.
Cheers
I was wrong… after the migration, the zeroing problem is still there. We had something in the construction script that hid the problem, but it’s definite still happening.
So it sounds like the issue is being caused by one of the blueprints. To further investigate what is happening I would need to see your blueprint, preferably the one you migrated in that still had the problem. It would also help if you could point out the part of the construction script that was masking the problem after migrating.
It looks like that’s going to be about 12 pictures. Is there a better way for me to get it to you? Also, there were a total of 13 blueprints migrated because of dependencies. If you need to look at those, getting pictures might be tedious.
It would probably be best if you could zip the blueprints and attach them.
The blueprints are attached. The one that gets zeroed is CharacterObie. It is the base blueprint for CharacterG. Also, I should note that this issue appeared first after a change to HUDObie.
link text