RPC Functions in BP

Is there a reason why UE4 doesn’t support RPC on Blueprint Functions?

It supports RPC for Blueprint Events (which I assume is just a more complex function) so why not Functions?

I usually develop in C++ but sometimes if it’s a simple feature, I tend to make it with Blueprint because it’s far quicker to develop with. However, there’s been a few times now where I have had to migrate a relatively simple feature from BP to C++ solely because of BP lacking RPC Functions. It really does waste quite a bit of time.

RPC´s can´t return anything and you can´t return anything in a Blueprint Event so I guess that is why they don´t allow Blueprint Functions to be RPC´s since it would give the impression that return values are allowed.


That does make sense but surely Epic can just give an error message or only show RPC settings on void Functions.

Beginners won’t understand how RPCs work anyways so preventing us that do from using them because of something like that seems a bit odd.

I like to work in Functions over the Event Graph because it’s just far cleaner and works better with my OOP mindset. I am sure many C++ programmers find Functions easier to work with too.

Pack your logic in a function then create an event to call the function.

1 Like

That would not achieve anything other than having an extra “function” call.

The boilerplate for RPC´s even in C++ will expose the function so trying to make it private or protected won´t help either.

Why is it a problem to build an event that does the thing, when doing it in Blueprint?

You can collapse all the nodes of the event into a single node (collapsed graph), which has inputs & outputs just like a function or macro. You can also have multiple event graphs and put the replicated events into separate event graphs based on their “type” (e.g. attack events).

I have seen Collapsed Graphs to some extent with certain plugins, however, I never quite delved into it myself.
I may look into them as well as multiple Event Graphs the next time I have this problem but it’s a rather complicated solution (which forces a certain style of scripting) as opposed to simply allowing us to specify the RPC type on a Function.

The problem I have with it is that it is fairly inconvenient.
We all know Functions are a standard way of OOP and UE4 BP clearly supports them so why should we be forced to script our game in a very specific and ‘unconventional’ way just to achieve something that should be fairly easy to do?

RPCs are supported in BP Events and C++ Functions, so is it really that difficult to also allow BP Functions to support them?
If there’s a genuine reason for BP Functions not supporting RPC then that’s fine.

From a semantics point of view your logic should be event driven. So, {Some RPC Event → RPC Function Logic} is pretty standard.

To me that’s not a far leap from $a → Foo();


Class MyClass {
    void Foo();

int Main {
  Myclass o;
  fgetc ( stdin );
  return (0);

Because of the threading/interpretation mode of Blueprints, there are things that can be done in Events that cannot be done in Functions – for example, the “delay” node, or the “gate” nodes. Similarly, you can bind to other events with direct references, rather than having to create a dynamic event, but only when you’re in an event graph.

Thus, it seems as if supporting events is pretty desirable.

Supporting ALSO doing functions could probably be done, but I don’t see the big deal. You have some particular idea of what a “function” is in Blueprint, and how it maps to a “function” in C++, but that’s your own personal mind map, and not a particularly strong reason to change the design IMO. Events work just fine for me.

In fact, with Events, I can separate all of them out on separate event graphs, whereas with functions, I just see them in a small list box where the only arrangement mechanism I have is a category. So, preferences vary.


^This^… Its an understated point actually, as Blueprint-functions often feel like a claustrophobic popup coding box, and completely unlike how they are in source / script. If coders can make RPC’s inside functions on a whim (VOID when there’s no return node), then auditing Blueprints is going to be a lot more PITA time consuming.

Look at Marketplace-pack quality control. Nod to anyone whose ever tweaked singleplayer packs to make them multiplayer-ready. Overall there’s no clear rules when something should be a function. So often creators just go overkill, burying stuff or over-engineering things inside 100’s of functions that would be just fine as simple variables or easy formulas in the graph. Its almost a ‘look at what I can do mom’ thing, rather than encapsulation or re-usability or something that has any real reasoning / strategy / direction. But hey, classic KISS-type rules apply to Blueprints just as well as anything else. :wink:

Whereas having RPC’s in the graph forces them out in the open at least. Its also easier to convert singleplayer marketplace packs to multiplayer by only ever having to work at the graph level. As it allows devs to more easily place high-contrast color-coded comments around these sections to separate networking code from core gameplay.

I’ve never understood why functions are crippled off to the side anyway. They’re too important for that arguably. But that’s how it is… Why can’t we have Magic-Nodes / Math-Expression like integration right into the exec chain of the graph? It’d be faster for quick-editing / tweaks. But hey, Collapsed-graphs are the greater evil here along with Macros. :stuck_out_tongue: But both of them arguably have way better editor usability - go figure. :confounded:

So am I wrong to think that it is generally more ideal to use Events over void Functions anyways (unless there’s an obvious reason to use a Function - like reusability or something)?

But wouldn’t that make maintaining wires a bit of a pain? Since I usually put everything in Functions, I just get a direct reference to the variable every time I need it as opposed to spreading wires everywhere.
I believe with an Event, you either have to deal with the wires or use prefixed global variables.

Not necessarily… Use whatever makes you happy as long as its readable / performant… But recognize there is skill / familiarity to keeping BP readable. So a little humility goes a long way (initially at least versus falling into the trap of the planet-sized-ego-coder that assumes Blueprints is way too easy). Have a look at the random spaghetti here…

What’s wrong with this picture? :stuck_out_tongue: References are dragged everywhere. Blame YouTube micos for this. :grimacing: That’s what’s wrong with dragging when you can just use direct references. No reroute nodes either. Easy fix there… As is lowering the exec-wire splines in the editor settings (straight-lines work great). Plus how about using more Custom-Events to break things up, so exec wires don’t have to be dragged across planets.

Even if that seems unavoidable, breaking sections up with clearly categorized color-coded comment boxes helps a lot. It’d have been great if Epic pushed guidelines here similar to Allar’s naming standards doc. So for example, assign particular colors to code that’s math circuits vs movement-code vs RPCs and so on. Or include a Map Legend…

What else… Just designing code badly. Like how business heads like to code or create Office / Excel macros from hell and then hand them off to the IT dept for er- maintenance. :stuck_out_tongue: There is a need maybe to use more class-level variables (so not global variables per se). But actually that really helps a lot with debugging. While Pure Functions / temp-vars seem great, they’re not always helpful when bug hunting. That’s where Epic could really improve the editor UX. BP Variable-Watch is a thing of hilarity versus practicality. :wink:

I don’t like spaghetti graphs. They’re a PITA to comeback to down the road and review. Much less debug. I like creating graphs to house specific grouped chunks of logic…organized.

e.g. Movement Graph, Weapon Graph, Interaction Graph etc and so forth.

In said graph I will have Events that execute chains of “Function” logic.

Init Event → Func → Func → RPC Event Call
RPC Event :: Function

For the primary Event Graph I try and keep it bound to Tick, Begin Play, Hit and Overlap events unless the overall complexity of the actor/class is generally simple.

Events just as functions can have Inputs. You don’t have to have globals all over the place. You can pipe directly from function to event or to another function. You can then set locals in the new function. Or you can have a function that acts as a container for multiple functions outputting the combined results.

1 Like

Sorry about that. I did mean to say class-level variables. I just never really call them anything other than ‘variables’ so I kinda forget the actual name for them.

This probably will be the method I will use in the future (I already do this to some extent) but it does seem like it’s a cheap solution to this RPC Function problem.
I guess if you were to also incorporate Delays and other Event-exclusive features, it would be worth it.

It is what it is. I didn’t like it at first, but I got use to it and it does force “Event Driven” into my brain.

You’ll definitely use this process for timers and timelines.