Official Mumble VoIP Forums

Unreal Engine 4 Link plugin

Mumble about Mumble
My plan is to make an Unreal Engine 4(UE4) plugin for mumble. I have some initial ideas for the plugin that I would like to share. This way people can put feedback on the ideas and implementation.

The main idea is to use the UE4 plugins option to implement a mumble link plugin. This UE4 plugin would along with the LinkedMemory also provide options for the UE4 editor to help the developers setup the mumble support for their game.

The initial step is quite straightforward. Take the information from the wiki page about link and rewrite it, so it complies to the coding standard of Epic. Then make a update function that will extract the needed information from the engine and put it in the LinkedMemory. Here it already starts to become a bit more complicated. How to get the information from the engine, without editing the source of the engine. The last part is the trickiest part. Add a UE editor interface so the developers can easily link cameras, characters, and ID's to the mumble plugin.

I will post new messages when I have more information. :)
First step the translation to EPIC standards.

Code: Select all

/** A struct that organizes the information passed throught the linked memory */
struct LinkedMemory {
	/** Version of the Link plugin */
	uint32	PluginVersion;

	/** Counter to check if information has been updated */
	uint32	UpdateCounter;

	/** In game Avatar Position */
	float		AvatarPosition[3];

	/** In game Avatar Front Vector */
	float		AvatarFrontVector[3];

	/** In game Avatar Top Vector */
	float		AvatarTopVector[3];

	/** Name of the game that is using this plugin */
	wchar_t	GameName[256];

	/** In game Camera Position of the players viewport */
	float		CameraPosition[3];

	/** In game Camera Front Vector of the players viewport */
	float		CameraFrontVector[3];

	/** In game Camera Top Vector of the players viewport */
	float		CameraTopVector[3];

	/** String to Identity a player uniquely in the context */
	wchar_t	PlayerIdentity[256];

	/** The length of the context string */
	uint32 	ContextLength;

	/** Context string that will determine which player should hear each other positionaly */
	unsigned char	PlayerContext[256];

	/** A description of the plugin */
	wchar_t 	PluginDescription[2048];
};
  • All the unsigned ints (4 bytes) have been changed to uint32.
  • The character types could not be translated to UE4 portable aliases as they advise to use TCHAR, which is compiler settings depended. This will mean that all the in game string will need to be formatted appropriately.
  • All the names of the variables have been altered to their standard. No underscore, first letter of word is capitalized, type and variable names are nouns, and names should be descriptive.
BTW why is context a unsigned char and why do we need to provide a length with it?
Cool. Should hopefully be pretty straight-forward to get the basic stuff working. Saw parts of someones cryengine implementation and their API pretty much had all you wanted available.
rawnar wrote:BTW why is context a unsigned char and why do we need to provide a length with it?
I don't think the original design saw it this way but the context is basically an arbitrary binary string. You have to pass the size because you can have zero terminations throughout it. Not quite sure why slicer designed it this way but it's already used in the basic plugin interface where you plugins context is generally prefixed with "pluginname\0" followed by whatever your actual context is (link plugin isn't bound by this convention).

No idea why wchar_t was chosen for the other stuff either. I guess thinking of unicode from a windows world? QString is backed by 16bit unicode chars so maybe that was a factor. You'd have to ask slicer. All those design decision predate my time with the project ;)
Are you talking about Ivan Hawkes plugin that one can find on Bitbucket? I will check it out.

My idea at the moment is to give the developers some freedom how to integrate the plugin into their game. For instance they can pick which character and camera they want to link to the plugin. Also they can provide there own description, name, context, and identity. And when the plugin is active or inactive. But it would be nice to get a game developers opinion what they would prefer.

At the moment I have found that the camera and pawn classes are derived from the AActor class. This AActor class has some nice function calls that would help me get the correct information for the plugin.

Code: Select all

 FVector GetActorLocation() 
Returns the location of the RootComponent of this Actor

Code: Select all

 FVector GetActorForwardVector() 
Get the forward (X) vector (length 1.0) from this Actor, in world space.

Code: Select all

 FVector GetActorUpVector() 
Get the up (Z) vector (length 1.0) from this Actor, in world space.

The idea is to make a class for which two AActor pointers are exposed to the Unreal Editor, so that the developer can link them in the blueprint. For the character type of variables I do not have a concrete idea yet. Next to this the plugin will need a function call to activate and deactivate the plugin. And some variable were the developer can provide the conversion from game units into meters.
Sorry for reopening a 3 year old thread , but 'm in the same situation and want to know if you have done it or not.