Announcement

Collapse
No announcement yet.

Blueprint pitfalls and death traps

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Well, if we're going to necro this one, I might as well make a new note...

    My current principles are these: Every single base class is C++. All interfaces are defined in C++. Everything that isn't completely trivial is C++.

    Blueprints are, when used, strictly positioned as the final leaf node on the end of every branch, twig or sprout of the game code, and if anything even remotely complicated has to happen inside them, then that logic is swiftly packaged into a BP-callable native method. As soon as more than three wires are crossed in a graph, native code is written to replace that part of the graph. This has proved a reliable way to go about it so far, and it provides a crystal-clear demarcation between cosmetic/visual (BP) and everything else (C++).

    Leave a comment:


  • replied
    Lol, I'm like since when I posted in this thread, ohhh, 2014. The general idea is this, I avoid CastTo custom BP unless just doing dirty debug checks. I almost never really use CastTo unless it's casting to native base classes. There is always other ways around to implement, and it will make your BP/functions more flexible. One of which is be able to just implement a interface and then suddenly this BP is usable to interact with BP that calls by interface. It takes a bit more time to setup, and when you realize that your interface might need a update on event/function input/output it also takes more work. But it's like the safest way to do things for me. Cheers~

    Leave a comment:


  • replied
    The MacroLibrary deathtrap is also still present in 4.10

    Leave a comment:


  • replied
    fast forward to 4.10 .

    I'm STILL having this problem. Once a while. I'l get this issue of Can't Connect Pin warning. Or absolutely senseless error that doesn't recognize an object's inheritance.

    e.g A is parent of B. and you get error not recognizing B as compatible with pins requiring A.

    A re-compile will show work perfectly fine. Until you restart editor and you get the error again. i'm okay with recompiling at every startup. However when any one of these load error pop up ,
    you absolutely cannot cook your project anymore until you fix. it.

    I'm super tired of trying to beat around the bush with this one. any report to answerhub will ask me to reproduce it , this doesn't seems like an option. How am i to reproduce a bug like this.. sigh. Blueprint is hopeless

    Leave a comment:


  • replied
    Related to the newly added pitfall, maybe this link should be added on the main post: https://answers.unrealengine.com/que...nt-122527-form

    Problem very well described, as with donwload project that has the issue [v4.4.3]

    Leave a comment:


  • replied
    We need to compile the list & make a list to feedback to Epic for future fix.

    Leave a comment:


  • replied
    i just read through this whole thread of doom , i hope my project loads fine tomorrow !
    Although i came upon the Collision problem which will prevent the project form loading and force close it , but in the logs it says it is somehow related to collision .
    I think it was 4.3 when they released capsule collision primitive , and my problem was exactly capsule collision primitive , i deleted the asset using it , in the project folder , and it started to look good again . i didnt use capsule collision ever again , but i think they fixed it anyway .

    Leave a comment:


  • replied
    I posted about this a while ago and also put this into wiki in Blueprint Fundamentals.

    I think after this thread collects enough examples and gotchas, we should compile it in a wiki page.

    One common solution to spot this type of problem is to check if any BP got dirty flag set to need compiling again when you compile current one.

    And make a habit to use interface implemented check is better than use a cast. also, cast to native class before you send to a event/function call can usually "break the loop."

    if you have too many inter-dependencies, it's a good time to stop and review your approach.

    Leave a comment:


  • replied
    Glad to see that a lot of good information has come out of this already. Not glad that you're having problems of course, but we're getting lots of good hints and strategies listed here!

    Leave a comment:


  • replied
    Generally I would agree, but in my case there was no crash dump so I was lucky to have read this post the night before.

    Leave a comment:


  • replied
    Originally posted by Mike.Beach View Post
    Yeah, usually there's one asset that's problematic. The one that "completed the loop". Any assets in the chain can generally be removed to unblock you, and allow for a successful load. This can help narrow down assets that are part of the circular dependency chain. Usually you only have to roll back a singular asset, but narrowing it down can be tough if you underwent a lot of changes in one session.

    So if you hit something like this, try removing the most recent files that you've worked on. It can help narrow down the culprit(s), and help you identify the dependency chain that you may have been unaware of. This is obviously not THE solution, like I said we have a plan in place to address this, but this advice could help unblock people in the meantime. And like I said, if you figure out the dependency loop, then please let us know so that we ensure the scenario is fixed by our refactor.
    I wanted to briefly add on to this that the error logs are invaluable for fixing a crash issue like this. I had one recently when porting up to 4.3 from 4.2.1, which resulted in one of the assets I had not loading its collision volumes right.

    I was just about to roll back the project to a previous revision (which would have undone a fair amount of work) when I went through to the logs and found that it was one particular asset crashing - so I was able to revert that one single asset and get the project working again.

    Leave a comment:


  • replied
    Originally posted by Gooner44 View Post
    So, at least for me so far, the fix was easy. Rather than roll back since that caused other issues for some reason, I just deleted my macro library.
    Yeah, usually there's one asset that's problematic. The one that "completed the loop". Any assets in the chain can generally be removed to unblock you, and allow for a successful load. This can help narrow down assets that are part of the circular dependency chain. Usually you only have to roll back a singular asset, but narrowing it down can be tough if you underwent a lot of changes in one session.

    So if you hit something like this, try removing the most recent files that you've worked on. It can help narrow down the culprit(s), and help you identify the dependency chain that you may have been unaware of. This is obviously not THE solution, like I said we have a plan in place to address this, but this advice could help unblock people in the meantime. And like I said, if you figure out the dependency loop, then please let us know so that we ensure the scenario is fixed by our refactor.
    Last edited by User-1420270633; 08-14-2014, 11:24 AM.

    Leave a comment:


  • replied
    So, at least for me so far, the fix was easy. Rather than roll back since that caused other issues for some reason, I just deleted my macro library. Doing that allowed me to open the project, get a ton of errors about missing macros and fix them. Once I fixed all those errors, I was able to re-get my macro library from my Perforce server and all is well... so far. I deleted all macros that did what you mention above so I don't do this again.

    To be fair, my project is small and simple so who knows if that's going to be a feasible solution for others, but it worked for me. Hopefully won't hit all the other pitfalls now.

    Leave a comment:


  • replied
    I hate you. I read this last night in bed on my iPad after shutting down UE4 for the night and though, huh, I do that, but have not issues. Today, when I launched my project, it crashed. Thanks for that. J/K, glad I saw this or I'd have no idea where to start.

    Now, my issue is that I moved a bunch of assets and when I roll back I have 2 of each in different places. Seems like some work some don't and I have no idea how to fix that. This is going to be a long day...

    Leave a comment:


  • replied
    Originally posted by Mike.Beach View Post
    Off the cuff, both issues you call out sound like circular dependency issues.
    Yes, that was (one of) my conclusion(s) as well. They can be hard to spot when you are in the middle of a blueprinting frenzy.

    Great to hear that you are working on it! Your explanation is definitely satisfactory.

    Leave a comment:

Working...
X