I am having a very serious problem where multiple Blueprints are not displaying in Standalone Mode but do perfectly in the other in-editor play modes. I believe this is due to a bug or something is corrupt since with a variable ‘Distance Between’ that I explain about in the post above about this issue in one particular area, it didn’t work correctly until I readded a new Get node for that variable.
I am in the midst of getting a prototype ready and am on a strict timeline. Please help me resolve this, thanks!
“nodes that are failing and that is working so something is definitely corrupt about my Blueprint. It’s odd because everything works great in the editor but something is definitely wrong with UE4 if the nodes causing the problems are being worked around by recreating and wiring them the same as before with absolutely no changes. I really need to know if there is someway to clean out all the compiled code and recompile this thing from scratch”
How many nodes to you have in your graph?
Are you subdividing the work into functions?
Wherever you are having nodes that are misbehaving I recommend selecting a bunch of them, right clicking, and compress them into a function.
The more functions you have the easier it will be for the compiler to maintain things as blueprints get very large
Let me know if that helps
I dont have answer for the level being dark though!
Rama!!! Good to see you again buddy. Actually as far as subdivision goes, I do have a couple helper functions to calculate let’s say the points around a circle and to make a location relative. The blueprint has a couple variables to easily create multiple instances and rotate and place them along a given path or curve and is there to increase the productivity when creating a couple test levels for my prototype.
Give me a second and I’ll post an image of the graph…
Oh and to give you one concrete example of what I was saying about re-doing things, I have a Vector variable called ‘Distance Between’ and it’s used by multiplying it against the current index of the ForLoop and to add that distance to each instance. In that specific instance, I had to delete the get node and re place and re-wire it up and it magically worked.
So in the above image, you will see I have two separate ForEach loops. the one that was originally working at the top, I re-created it and had to even recreate the connection and subtraction from the Index (you’ll see the old ones below it). The problem is this is in a lot of areas I think between 2 different BPs and it could take a lot of time to continually go through this and try to fix it.
I am not sure what would cause this issue to happen in only Standalone mode but not any other, it’s a mystery at the moment but I’m hopeful of the outcome, thanks again.
“I am recommending subdividing in some fashion, maybe even just sub-graphs!”
Sure, I don’t mind doing some refactoring while waiting and I was under the impression it was simply for organization purposes. Does that actually make it a little easier for the BP compiler to manage?
Oh also, another example… if you look at the graph, at the ForEach in the beginning… The ‘Count’ variable at the top was the original. It also failed and I had to add another getter node right below that and that worked.
Ahh, good to know. I do have separate functions for different features but not different sub-graphs. I’m going to go look them up in the documentation but does sub-dividing a function with a couple different subgraphs limit the scope of the function?
Also I agree that in C++, you would never keep everything contained in a singular function or constructor. The amount of workload in the function at the moment in question in my BP I felt was pretty negligible considering that function isn’t much bigger than in the image I had showed you. I knew about having sub-graphs but I thought it was not for compiler management but simplifying the visual representation to make it easier to go through a BP. I could easily go re-program all these classes in C++ but it would take a good amount of time to get that done. But thanks for the heads up, I’ll go look up sub-graphs right now and take a closer look at the documentation to understand how best to manage a BP. Thanks
Sure, I don’t mind doing some refactoring while waiting and I was under the impression it was simply for organization purposes. Does that actually make it a little easier for the BP compiler to manage?
#THAT IS MY WHOLE POINT!!! (tone: emphatic)
MC Stryker!
A single BP has limits!
You must subdivide!
Start subdividing!
Functions, and subgraphs!
It makes a huge difference!
A single BP graph has an actual hard coded limit on how much it can handle
In C++ Programming you’d never have everything done in a single place, you always use functions
People who use BP dont know this rule and overwhelm the system with too much stuff in a single graph
Epic will be releasing my article on BP Functions soon
You must subdivide sections of your BP into different sub graphs or functions!
both functions and graphs get their own compile space
"The amount of workload in the function at the moment in question in my BP I felt was pretty negligible considering that function isn’t much bigger than in the image I had showed you. "
hmmm
well
ummmm
then I am not sure why your BP is getting unhappy
At this point, if it were me, I’d try reparenting it to some other base class just to “snap it out” of whatever funk it got into
Running out of ideas here, I hope Epic helps you with this soon!
Oh, and one last thing, the Blueprints in question did work before with workload they have wired up currently. I also disconnected any Pins to additional stuff since the last time I tested in Standalone mode. Would there be any differences with how it would be compiled and used in the editor modes vs Standalone?
"then I am not sure why your BP is getting unhappy
At this point, if it were me, I’d try reparenting it to some other base class just to “snap it out” of whatever funk it got into
Running out of ideas here, I hope Epic helps you with this soon!
Rama"
Me too buddy
Normally, I would excuse this and simply demo this prototype at the time in the editor but Microsoft is sending me an Xbox One Dev Kit shortly and I also need to run this externally of the editor to showcase Oculus Rift support. If worse comes to worse, I’ll re-design these in C++ but it’s going to add some time so I’m hoping that Epic can help me with this. Thanks again Rama and it’s possible I am confused about what I’m calling a “sub-graph”. What I thought the feature was, is taking a portion of a given graph and collapsing it to a node. Similar to when you highlight the Math Expressions node and it shows the inner bits that are connected but it just makes is easier to collapse part of a graph for visually going through a complex BP. If you are referring to having separate functions, events, construction script, etc that breaks up the functionality similar to how you would arrange things in C++ code then YES, I am doing that in this particular case
But if there is a feature in BPs that can not only collapse a section of a graph but somehow simplify things further for the compiler then I want to make sure I take advantage of that as well
It actually is parented to Actor :P, I think if I make it parented to an object, it may break further. I possibly could create a class that is based off of an Actor and then re-parent it to that then back to Actor and see if that helps.
Sorry we did not get to you sooner. I apologize for that. A technician has been assigned to this post now and will be assisting your further. Once he has had a to attempt to reproduce the issue, we will be able to get back to your with some more information or questions.
Thank you very much for your understanding and patience.
