In my experience, it is the number of nodes in the blueprint. Something I have done to solve long compilation times, is convert my functions over to C++ (This also solves memory leak issues I have had in extremely large Blueprints).
I have come to same conclusion - as BP gets rather large compile times really start to take a while due to the number of nodes.
Splitting into graphs/functions seems to have no effect.
I’m gonna have to move a bunch of code and logic down into c++ (at least for this large Hero BP).
The main point of BP for me is fast iteration, and these long compile times are breaking that.
Maybe I need to buy a Threadripper or 10-core 7900x… not sure how much that would help though
If I inherit a new BP off the old slow one, the new one compiles like 20 times faster.
So one approach for keeping fast iteration would be to simply create a new child every time it starts getting slow…
Of course this might lead to quite the tangled inheritance chain mess, so might be better to separate by concern…
e.g.
AttackBP->InventoryBP->TargetingBP
I am still planning to push a bunch of the performance critical stuff into c++ - but at least there is another option to keep the iteration speed fast
Refactoring into Components is definitely a good idea - Thanks!
Not sure I follow - each instance has it’s own copies of all the child and parent variables? (The child can access parent variables and/or define new variables if needed - no need to override or replace those in the parent)