No announcement yet.

Please expose more API functions to Blueprints

  • Filter
  • Time
  • Show
Clear All
new posts

    Imo everything should be exposed to BP (if possible of course!). The dev should decide if he wants to use Quats or Rotators (as an example).
    The Problem I see with UE C++ simply is that that as an Indie/Casual programmer you correct too many compile errors because of Macros.
    Writing code in C++ is juggling with the Macros' compile errors. Only a small part of the programming is actual C++ code at least that's my experience.

    BP are so much faster and easier to work with and many people would be happy if they would have the same power (API-wise).


      Thanks all for your input and interesting discussion!

      Konflict You can create custom loops in BPs too, decremental ones, custom iteration step ones, etc. Of course when you really have some performance critical part of logic you want to do this in pure C++, but if we're talking about things like optimized for loop, in most real world cases the difference is unnoticeable these days [ ] - especially when it comes to a typical video game mechanics.

      About possible context menu lag after adding many API functions - I'm not sure about that, but for now everything shows up instantly even on my old HDD. (Will be buying an SSD soon, don't worry ) One of the easiest solutions for a possible problem like that would be to group these functions into catagories, and load certain function list only if user searches for something within this category. Something like chunking on 3D world
      ... Or a simple switch like 'Show All API functions' somewhere in the blueprint/project settings. Then we can decide if we want to use simple 'instant' blueprint function set or have access to more advanced functions, even if it would cost some intellisense-style lag.


        Originally posted by Konflict View Post
        How many functions you wish to have the blueprints? Where's the limit?
        In my experience? Just few of them.
        It's just few convenient methods or concepts from standard programming we're missing here. Lack of quats actually makes some blueprint operations really messy.
        TSets and TMaps are perfect example where adding something new to blueprints give us performance boost.

        Seriously, not too much is missing to script a lot of "simpler games" entirely in blueprints. Maybe not that easy if we're talking about multiplayer, online systems, complex AI. But these areas should be usually covered by C++. For performance sake, but also blueprints wouldn't be that useful here

        Personally I'd love to see need improvements in blueprint editor. Less hassle when editing graphs. Proper support for local variables in UI, easier composing of looped operations, that kind of stuff.

        Originally posted by Konflict View Post
        You know the thing is, even a sophisticated intellisense of Visual Studio having a really hard time to dealing with the engine code, because it is very very large, and you can believe me on this.
        I don't consider Intellisense a "sophisticated thing". I don't understand why it's still that slow and retarded after some many years of development. Why MS didn't buy Visual Assist?
        You know it's still quite unfair to compare crappy Intellisense which scans every line of codebase and analyzes it to simply displaying pre-compiled list of functions in blueprints. I guess it's somehow pre-compiled because I never waited for this list to show up.
        Last edited by Doctor Ergot; 09-06-2017, 07:23 AM.


          This is all you need to know to expose anything from your classes. But even more, you can also modify the engine as well and expose everything for yourself. I wish you all good luck with your new learning experiences that will rocket you to the sky.
          Last edited by Konflict; 09-06-2017, 10:33 AM.
          * Sharp and responsive Temporal Anti-Aliasing tips and tricks
          * Pitch-shift source effect (DSP) over the network (VOIP)
          * My Portfolio and Developer Blog


            Exposing API functions manually is a solution, but not applicable to e.g. pure Blueprint Marketplace products or other for people who want to keep their projects 100% BP.
            Anyway, more Blueprint power won't hurt anyone... Quite the opposite, as far as I know.


              they develop firstly in C++, i think they don't have time and human to test, and guarantee all c++ code also work good when implement on Blueprint, and it rise up more Bugs.


                If you ever tried to actually make your own custom blueprint function you know that it's quite simple to just find whatver piece of code in the engine files and re-work it to output into blueprint nodes.

                there are at least 2 important things you should do for every project anyway. Quaternions as mentioned and a double type via string for better calculations then float.
                really it would be just nice if Epic properly exposed real Doubles and we didn't have the overload of string conversion...

                Speaking of, aren't Doubles almost a must with raytracing?