Is there a Blueprint UDP Listener?

Development Programming & Scripting Multiplayer & Networking
, , , , ,
1

You’ve probably already seen this;
http://www.osnapgames.com/2014/05/24/connecting-to-a-third-party-socket-server-in-unreal-engine-4/

So no, at present nothing that’s already exposed to blueprints. Take heart, if you can understand JS, you can understand anything at all…

2

Note: I come from a PHP/JS background, so C++ is a bit beyond the scope of my comprehension right now.

Is there a pre-existing Blueprint/Class which can act as a simple UDP listener?

In my imagination the class would essentially have…one public variable (port)(Although I guess a second for an IP address on the off chance that the machine has more than one).

Then the class would also have a function/event that would fire when data is received on that port, and then we could use all of the other great blueprint functionality to respond to those events.

Theoretically, this seems like something a C++ coder could do, building off of the FSocket class and HasPendingData/Recv, but I looked at that and almost threw up on myself, so there’s that.

3

I would really like to know if this is possible as well, and if no - is there any other way to implement an UDP-listener into the project, or just another way at all to send data into the engine?

4

Yes I saw, but… C++. C++ looks like Javascript if someone took javascript and said "Hey, let’s add a bunch of &, and *, and 8 and :: and make a lot of the class names and variable names exceedingly complicated.

In my fever dreams, it would look like this.

var udplistener;

$(document).ready(){
 
    udplistener =  UDPListener({'port' : '8888');

}

$(document).addEventListener('udpEvent', function(e){

  var bp = Blueprint('blueprintobjectname');

  if (e.incomingMessage = 'FIRE')
  {
        bp.trigger('FIRE', e.incomingIPaddress);       
  }

});
5

Ha! The udpListener is scoped to the DOM, bp only exists within the eventListener. Easy Peasy. Coding so simple, that even -I- can do it.

6

(and thank you, so very much, I appreciate it!)

7

That looks pretty. But how to tell where scope starts and ends? It probably starts at the top of the answerhub page and ends at the bottom of it, thereby stretching back in time to the launch of UE4.

I’ll take a look at the links on the osnap games page and try and translate your fevered scribble into something more elegant…

8

No worries, it’ll be this evening UK time tho…

9

You’re going to use your time and skill, freely, to help me with a problem for no reason whatsoever?

I -guess- I can wait.

(Thank You)

10

No problem, I’m learning the engine so it’s all time well spent. Also something I’m interested in.

So I entered the line
FSocket *socket = ISocketSubsystem::Get()->CreateSocket(“default”, “default”, false);

into the header file of the GameMode of a project I’m playing with, and it compiles no problem.

Then I entered;
In the header file;
UFUNCTION(BlueprintCallable, Category = Networking)
FSocket *GetNewSocket() const;
In the cpp file;
FSocket *ALedgeGrabGameMode::GetNewSocket() const{
FSocket *socket = ISocketSubsystem::Get()->CreateSocket(“default”, “default”, false);
return socket;
}

It didnt compile. Its a quick attempt to use whats on that Osnap page to make a function that returns the pointer to the socket and is exposed to blueprints. It gave the error “unrecognised type “FSocket””. (I have loaded the socket dependency in build.cs obviously, otherwise the first one wouldnt have compiled).

I wouldnt know enough to know why the compiler doesnt like FSocket in the declaration of a UFUNCTION. its an interface so its abstract, virtual functions etc. That may be why its a problem.

The only way to do this, probably, is to do it in the C++ and only expose the bits of it that will work as Uproperties, Ufunctions etc. So you have a node in BP that gathers all the data that needs to be sent on tick, and one that collects all the data that 's receivable, and what its passing is the game types etc. The socket is a private variable in the GameMode class that is never directly referenced from BP.

Have you watched these videos yet;

11

Yes, I’ve watched them, (well, the first 4). They don’t ever really expose the “UDPness of it all”, so I can’t really modify them to work with the data I’m sending to the game.

Your description seemed sensible, in what part of it I understood. The part I didn’t fused both sides of my brain, and made me weep.

12

Do they, at any point, tell you exactly what is being sent? Whats replication? I could probably write something for you, if you work out exactly what data is being sent and put it in something that I can pass to a function in the module. I’ll watch those videos over the weekend. So, you do the blueprint side of it- make an on tick event, gather the data and package it. Presumably whats being received is data from another instance of what you’re building?

13

Come to think of it, two machines are unlikely to have the same frame rate, so there’d have to be a game time node or something like that.

14

Actually, it’s sent and received as 8 bit integers.

Also, look at this;

And this;

Looks like what you really want is TCP?

15

Scratch that:

So its just the small matter of turning all the data into 8 bit ints and deciding how to deal with it, if some of it never gets there…

16

Okay, just catching up. The videos give me the impression that networking (at least that method) is fairly abstracted away from the user.

Although I should give a bit more explanation of the use case, this isn’t for an instance-to-instance communication. This is for an external app (in this case Arduino) to send data to the instance, so the game time isn’t necessary.

I’m using UDP (as opposed to TCP) because it has a lower overhead, and sequencing doesn’t matter (or can be handled easily), so hopefully there’ll be less latency. I haven’t looked at FTcpSocketBuilder or FTcpListener to check out the helper classes for UDP though, so I’ll do that shortly!

(I have however read the GafferonGames article)

So I -think- it’s a question of creation a BluePrint (constructor?) which utilizes the UDP helper functions at game start to open the port, and then a different function which is attached to a tick, which checks the port for any incoming messages?

17

Are you send anything to it or only receiving?

18

I guess that makes it easier- take a look at this;

I am not yet clear on where its been abstracted away and where you just have to code stuff. Turning data into packets sounds a bit like encoding for compression or something, which I’ve done before. But that would seem like it would be very specific to the game and what is being sent. A delegate sounds promising- maybe a pointer to a function…

19

Correction. It looks like they’ve separated the UDP functions, in the Common folder I see

UdpSocketBuilder.h
UdpSocketReceiver.h

The builder has a class FudpSocketBuilder, which just has a description for the constructor. But then the function BoundEndpoint would need to be called (with the ip address and port)

(I don’t understand the multicast or broadcasting stuff)

Then the receiver class has an object FUdpSocketReceiver the socket that was just created, and I imagine that would also run at “game start” as well.

It accepts a few variables, the Socket that was just created, the time to wait, and a description for debugging.

Then there’s something in the "FOnSocketDataReceived& OnDataReceived(), which “returns a delegate that is executed when data has been received”

I don’t REALLY know what that means, but I imagine it’d be great if that delegate was a function that fired an Event, which the BluePrint item could be listening for and react to.

20

For now just receiving, but I think sending would work almost the exact same way? Except using the UdpSocketReceiver class, and waiting for an event from the Blueprint and calling the Send function with the data, and the recipient IP? (probably also configured in the blueprint)