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.
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.
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.
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.
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.
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.
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.
