In my case i’m selecting one of two vectors.
First of them is constant and another one is specifically made to produce error(i’m trying to get location from actor variable that was never assigned).
Select node configured to pick first vector, but tries to calculate second input also, producing error message as a result.
LogTemp:Display: ULDCommandInitLevel::OnStartup
PIE:Error: Error Blueprint Runtime Error: Accessed None trying to property NewVar_1 from function: 'ExecuteUbergraph_blueprintName' from node: Print String in graph: EventGraph in object: blueprintName with description: Accessed None trying to property NewVar_1
LogBlueprintUserMessages: [blueprintName_1168] X=0.000 Y=0.000 Z=0.000
UE-20044 was marked as cannot reproduce because it was tested in a later internal build. If you are still interested in investigating this on your end, you can download the master branch from Github and test there. As a note, the master branch is not fully tested and should not be used for development.
It’s confusing that version that i’m using(4.15) is not listed in UE-20044’s Affect Versions(4.8.3, 4.9, 4.10). And based on that list, bug should have been fixed some releases ago. So i’ve decided to post this report in case fix did not account for my specific usecase of select node.
Any info on which UE version(not github branch) this fix will be released?
This was tested on an internal version of 4.16 where it did not reproduce. If you do continue to see this issue after 4.16 is released, please let us know so we can investigate further.
Just tried to reproduce this bug in fresh 4.16 preview from Launcher. With success. Same blueprint, from above, same error. Version: 4.16.0-3405315+++UE4+Release-4.16
LogLoad: Game class is 'GameModeBase'
LogWorld: Bringing World /Game/StarterContent/Maps/UEDPIE_0_Minimal_Default.Minimal_Default up for play (max tick rate 0) at 2017.04.26-14.45.04
LogWorld: Bringing up level for play took: 0.001545
LogScript:Warning: Accessed None trying to property NewVar_0
Minimal_Default_C /Game/StarterContent/Maps/UEDPIE_0_Minimal_Default.Minimal_Default:PersistentLevel.Minimal_Default_C_1
Function /Game/StarterContent/Maps/Minimal_Default.Minimal_Default_C:ExecuteUbergraph_Minimal_Default:0028
PIE:Error: Error Blueprint Runtime Error: Accessed None trying to property NewVar_0 from function: 'ExecuteUbergraph_Minimal_Default' from node: Print String in graph: EventGraph in object: Minimal_Default with description: Accessed None trying to property NewVar_0
LogBlueprintUserMessages: [Minimal_Default_C_1] X=0.000 Y=0.000 Z=0.000
PIE: Info Play in editor start time for /Game/StarterContent/Maps/UEDPIE_0_Minimal_Default 0.526
Should this happen? Is this bug fixed in 4.16 final but not in preview?
Thank you user340634534, I was able to confirm that this is occurring in the 4.16 preview and have reopened the original report for further investigation.
This cannot be fixed only by changing Select implementation. It requires to change the order of pure node execution that BP-compiler use (and all nodes expect). The reason this is marked as won’t fix is because to fix this issue would require an overhaul of the blueprint execution system.
I can confirm it is still happening in 4.22.3, but if what said is true, i don’t think it will be fixed any time soon.
This kind of changes requires the system to be redesigned and may take many iterations to make it as stable as the engine is right now.
It is the kind of thing you have to live with until a new mayor update is released, maybe in UE 5?
Lucily it can be easily bypassed with a couple of braches or isValid(exec) nodes, not ideal, but a solution nonetheless.
So, basically, we shouldn’t fix anything because it might take some work?
That’s a terrible attitude for software development, and leads to bad software where the technical debt just piles up until the software becomes unusable under its own weight.
That’s not what I’m trying to say, although I see why you see it that way. It wouldn’t be the first time to see this happen in a project.
Usually when you develop a software this massive you tend to find problems of this caliber that are pretty hard to predict when you are designing the fundamentals at the begining, even years and iterations after you still see them comming. So it’s pretty much unavoidable to make this kind of mistakes.
However, it is best to focus in smaller or more affordable bugs that don’t require a mayor redesign of the features or systems (alongside updates and new small features), and leave those for the bigger updates.
Once you have more data and bugs reported you can see the bigger picture and know how to address those problems with a better design in mind. This is the same with big new content or features.
I’d say is better this way. If you try to fix problems like this one on the spot, you’ll end up rewriting core parts of your system very often, not letting it get stable, and overall, developing the software very slowly.
Hope the point I’m trying to make is more clear now.
