StartFire Replication On Multiple Clients Fails

[petergpls]

Does anyone have an example of Weapon firing to be replicated on multiple clients via the dedicated server. Given that other clients are not owner clients they do not have a weapon and StartFire does not work on all clients even though the documentation says that the ServerStartFire does deal with all clients.

I have followed and tried most google things but I am wondering if anyone has the same problem and has solved it. If not then I will just continue to research and see what I come up with

[Solid Snake]

http://udn.epicgames.com/Three/ReplicationProxy.html

This explains the replication proxy pattern.

[Markus Rannare]

The link Solid Snake posts gathers the information quite good. To elaborate a bit more. The proxy pattern communicate through another entity. In the case of Weapon/WeaponAttachment they do their communication through the Pawn. So when a client fires, it sends the fire command to the server by a server function. The server then updates the FireMode and HitLocation (among some variables) on the Pawn, and replicate this to the relevant clients (as the pawn is relevant on other clients). The pawn in turn sends this information to the WeaponAttachment when it's updated on the the WeaponAttachment spawns the fire effects.

[petergpls]

Thanks. I was looking at the documentation links and was not expecting the potential solution (will try it out tonight) to be under 'Proxy Pattern'.
Just wondering if the DVD on eat3d (Solid Snake) may know, does it cover this sort of replication stuff or is it more or less an intro? I would like to buy it as it looks like it would be good for C++ developers learning UScript.

[Solid Snake]

It covers replication on the topics I talk about the DVDs.

Each DVD is designed to be a vertical slice of each iteration of the game. At each vertical slice, all the features work in multiplayer.

[petergpls]

Thanks to all for your input here. Will grab the DVD tonight.

[_h2o_]

i do not know what is your problem, but when i did same thing it was not workable too. i mean UDN article does not cover all spects, and the logic on 1st|3rd person game and rts or rpg is different.
So what can you check:

clients are not owner clients they do not have a weapon

because invenotry manager is replicated only to owner. so first you need to replicate invManager to client

StartFire does not work on all clients even though the documentation says that the ServerStartFire does deal with all clients.

yes. stupid documentation, firstly i understood it same. but it is totally wrong!
ServerStartFire fires on the server, when server is firing it spawns projectile to all clients who relevant to it, so check your projectile relevancy, settings and try to add bAlwaysRelevant = true;
so StartFire never calls on clients, it is just calls on server throught simulated function and then projectile spawns to all relevant clients

UDK documentation sometimes is a real ****!

that is mine not too old thread with almost same question: http://forums.epicgames.com/threads/...1#post30123341

[Solid Snake]

StartFire does not work on all clients even though the documentation says that the ServerStartFire does deal with all clients.

Where on the UDN is that said?

UDK documentation sometimes is a real ****!

Please help by indicating where this is.

[_h2o_]

Where on the UDN is that said?

in weapon docs, and in weapon firing logic.
there is some like: "bla bla, start fire calls server startfire and local startfire"

Please help by indicating where this is.

this is everywhere in UDN docs! there articles do not covers all aspects or all sides of development things, but maybe the biggest reason that all documentation is about 1st person UT game, so some time it is hard to understand how to use it for other type of games.
i mean you read at UDN that something works so and so, but when you are doing same in your non FPS|TPS game it does not work! because there it should work with very different logic.
for example ownership for replication: as you remember you told me about it, but i did not understand because UDN says other..
UDN should divide info for which game type this info is.
for example, if non FPS, and my PC has no pawn, then client will not fire localy...

[Solid Snake]

but i did not understand because UDN says other..

You didn't mention that in your thread back then? Where in the UDN does it say one thing, and me saying another thing?

for example, if non FPS, and my PC has no pawn, then client will not fire localy...

How does that actually resolve anything? Code works in one way, and not a million other ways?

Anyways, if something doesn't work or isn't commented right on the UDN; please don't just brood and complain about it. Do something to help to make it better... by posting on the forums so that someone is aware of it.

[VendorX]

@_h2o_ : When you don't understand how replication work, it doesn't mean that something is F***...

[petergpls]

Hi,

I just tried setting bAlwaysRelevant = true and that made my effects display on multiple clients - great.

BUT I can not get StartFire to work on non-owning clients.

_h20_ can you give me an example of how I would replicate the InvManager as when I try to place as follows:

replication
{
if (bNetDirty) InvManager;
}

I placed this in a derived Pawn class but compiler errors.

It would be great if I could have a small working example on just getting StartFire(...) to work on non-owner clients.

Cheers

[petergpls]

About documentation - why not take this simple example of getting StartFire to work on non-owner clients and show me a document that helps newbies to do this. The link for the UDN about the Proxy Pattern shows code in UTPawn and other classes but its not that straightforward to understand.

[_h2o_]

@_h2o_ : When you don't understand how replication work, it doesn't mean that something is F***...

answer is close:

About documentation - why not take this simple example of getting StartFire to work on non-owner clients and show me a document that helps newbies to do this. The link for the UDN about the Proxy Pattern shows code in UTPawn and other classes but its not that straightforward to understand.

thats why!

it is F*** not because i do not understand, but at start no one understand, and documentation should be so to help understand and show how it works. a very simple explanation and maybe code example can show much more rather than nothing in tons of words!
for me every doc is F*** if i read it more than twice and i still did not understand how.

really, i read UDN replication docs 3 times, and there is some basics, but after reading i still had many question how to do that and that and that.. and i started to trying, it gets me more understanding, but i wasted a weeks before i understood some things, some other advices or info i get from Solid Snake and D1sregard, and really they told me more than F**** UDN docs!

petergpls

replication
{
if (bNetDirty) InvManager;
}

it gets you error because it is declared in parent and it is not your declaration;

i do not know is it right, but i did it so and it works for me:

var repnotify InventoryManager myInvManager; 

replication
{
	// Replicate if server
	if (Role == ROLE_Authority && (bNetInitial || bNetDirty))

	myInvManager;
}

simulated event ReplicatedEvent(name VarName)
{
	if (VarName == 'myInvManager')
	{
		if (myInvManager != none)
		{
			invManager = myInvManager;
			invManager.SetOwner(self);
		}
	}
	else
	{
		super.ReplicatedEvent(VarName);
	}
}

[Solid Snake]

Let's start right from the top, and let's use the UDN documentation to provide us answers. So the original question was:

Does anyone have an example of Weapon firing to be replicated on multiple clients via the dedicated server. Given that other clients are not owner clients they do not have a weapon and StartFire does not work on all clients even though the documentation says that the ServerStartFire does deal with all clients.

So how exactly does the weapon replicate between the client and the server and vice versa?

A search on the UDN for "Weapon Replication" reveals the following links:

• http://udn.epicgames.com/Three/ReplicationWeapons.html
• http://udn.epicgames.com/Three/ReplicationProxy.html
• http://udn.epicgames.com/Three/ReplicationHome.html
• http://udn.epicgames.com/Three/NetworkingOverview.html
• http://udn.epicgames.com/Three/Weapo...icalGuide.html

There also appears to be documentation within the source code itself (in Weapon.uc).

Using this documentation, http://udn.epicgames.com/Three/ReplicationWeapons.html, it is understood that on the client:

• The local client controller calls StartFire() within Weapon.
• Ask the server's version of Weapon to call ServerStartFire() and also call BeginFire() on the client's version.
• Set the byte in the pending fire array within the client's version of InventoryManager.
• If the client's version of the weapon is in the 'Active' state, it will then send the client's version of the weapon to the appropriate firing state.

So this is pretty rich? What is it meant by local client? The UDN doesn't provide concrete information about this is, so a quick Google search for the definition defines a local client as "A local workstation application acting as a client to the Office Communicator server.". However, if you have a background in network programming, you'd also know that a local client refers directly to a single machine that is running the client; which is more or less the same meaning as what Google provides.

What does it mean by asking the server's version of Weapon?



So with this image (in the same documentation), we can see a series of functions being called. There is something called StartFire() [Client] which suddenly jumps to ServerStartFire() [Server]. What the heck is that? Looking at the source code, we see that the function is defined as:

reliable server function ServerStartFire(byte FireModeNum)
{
	if( Instigator == None || !Instigator.bNoWeaponFiring )
	{
		// A client has fired, so the server needs to
		// begin to fire as well
		BeginFire(FireModeNum);
	}
}

What the heck is "reliable server" prefixes before the function declaration.

A UDN search for "reliable server" reveals the following links:

• http://udn.epicgames.com/Three/FunctionReplication.html
• http://udn.epicgames.com/Three/GameS...plication.html
• http://udn.epicgames.com/Three/Unrea...Reference.html
• http://udn.epicgames.com/Three/NetworkingOverview.html

Ok, so what do each of these keywords mean. A few key points in the following documentation help us to search in other places.

Function replication is now defined by means of function specifiers ( Server, Client, Reliable )

So we know these function specifiers point to something called "function replication". And there is a UDN documentation about function replication. Huzzah!

While in a single player game, functions are always executed, networking throws another wrinkle into the matter. A function can either be executed on the local machine, replicated across the network to be executed on the remote machine, or ignored altogether. The process of sending a function across the network to be executed is sometimes called remote procedure calls (RPC), but Unreal calls it function replication.

Right, so this over view discusses that within a single player game, everything is always executed ... but on the network things can become complicated. It states that there are three possibilities; functions may:

• Execute on the local machine
• Replicate across the network to be executed on the remote machine
• Ignored altogether

So what do these three things means?

A function executes on the local machine ... means that the function is run on the machine that calls it. Replicate across the network to be executed on the remote machine ... means that replication is happening to cause a remote machine (a machine on the other side) executes a function. Ignored altogether ... means that some functions are ever called even when asked to aka ignored.

Ok, so we know that ServerStartFire is a reliable server function, and we now know this is to do with replication. So what does it mean to be reliable server?

So according to the UDN (http://udn.epicgames.com/Three/Repli...ents/functions),

• Reliable - These events or functions will always be sent and received in order to the client or server.
• Server - When these events or functions are called on the client, they will be executed on the server. Server side actors shouldn't call these events or functions directly, but rather an event or function which does the actual logic. Thus server should act as a bridge of communication between the client and the server.

Right, so based on those two explanations we know that a reliable replication function means that it is always sent to the client/server and is always received in order (in the order that it is being called). We also know that server indicates that if the function is called from the client ... they will wind up being called on the server. It is also noted that the server shouldn't call these and that it is a method for clients to communicate with the server.

Ok! Very good, so know we know what ServerStartFire() is doing. When the client calls ServerStartFire(), it doesn't actually execute it on the local machine, it is reliably replicating across the network to the server! Cool! So why is it not telling all clients about this?

So after some logging, it is noted that other player's weapons don't exist on the other clients. Does that matter? So according to the UDN documentation on Networking Overview (http://udn.epicgames.com/Three/Netwo...%20replication).

So, by this point, the low-level mechanisms by which Unreal multiplayer games operate should be clear. The server is updating the game state and making all of the big game decisions. The server is replicating some Actors to clients. The server is replicating some variables to clients. And, the server is replicating some function calls to clients.

It should also be clear that not all Actors need to be replicated. For example, if an Actor is halfway across the level and way out of your sight, you don't need to waste bandwidth sending updates about it. Also, all variables don't need to be updated. For example, the variables that the server uses to make AI decisions don't need to be sent to clients; the clients only need to know about their display variables, animation variables and physics variables. Also, most functions executed on the server shouldn't be replicated. Only the function calls that result in the client seeing or hearing something need to be replicated. So, in all, the server contains a huge amount of data, and only a small fraction of it matters to the client - the ones which affect things the player sees, hears or feels.

Thus, the next logical question is, "How does the Unreal engine know what Actors, variables, and function calls need to replicated?"

The answer is, the programmer who writes a script for an actor is responsible for determining what variables and functions, in that script, need to be replicated. And, he is responsible for writing a little piece of code called a "replication statement", in that script, to tell the Unreal Engine what needs to be replicated under what conditions. For a real-world example, consider some of the things defined in the Actor class.

Right, so it appears that the programmer defines exactly what gets replicated and what doesn't. So let's investigate why Weapon doesn't appear on the other clients! So let's find out how and why Weapon doesn't replicate. So looking through Weapon.uc, we see that there aren't many replication properties ... except for:

bOnlyRelevantToOwner=true
bReplicateInstigator=true
bOnlyDirtyReplication=false
RemoteRole=ROLE_SimulatedProxy

So what do these mean?

[Solid Snake]

Looking at the replication glossary (http://udn.epicgames.com/Three/Repli...ents/functions).

• bOnlyRelevantToOwner - This actor is only relevant to its owner.
• bReplicateInstigator - Replicate the instigator variable to the client.
• bOnlyDirtyReplication - Only replicate this actor if bNetDirty is true. This is only used if bAlwaysRelevant is true.
• RemoteRole - The role for the actor on the remote run time.

Right, so right from the start we know that Weapons are only ever relevant to the owner. We also know that weapons always replicate the instigator variable to the client. We also know that this Weapon is not only replicated when bNetDirty is true, since bOnlyDirtyReplication is false. And we know that the remote role controls the role on the remote machine. Ok, so we've now got more information about things we don't know. What's relevancy, what's the instigator variable? What's it mean by bNetDirty? What is role?

So a UDN search for relevancy reveals this documentation (http://udn.epicgames.com/Three/Repli...Relevancy.html). Oh right! So relevancy indicates that some Actors are important to some clients, and if they aren't relevant then they aren't sent to the other clients! So, based that we know that this actor is only relevant to its owner ... we need to know what the Owner is. So searching through code we find...

var const Actor	Owner;			// Owner actor.

Right, so it's an Actor reference to another actor. So who owns a Weapon? So let's search in UTGame, and how weapons are given to players. Searching for any one of the UT Weapon classes, we find a function in UTCheatManager...

/* AllWeapons
	Give player all available weapons
*/
exec function AllWeapons()
{
	if( (WorldInfo.NetMode!=NM_Standalone) || (Pawn == None) )
		return;

	GiveWeapon("UTGame.UTWeap_LinkGun");
	GiveWeapon("UTGameContent.UTWeap_RocketLauncher_Content");
	GiveWeapon("UTGameContent.UTWeap_ShockRifle");
	GiveWeapon("UTGame.UTWeap_Physicsgun");
}

So what the heck does GiveWeapon() do? Searching through the code base, we find this function in CheatManager...

/**
 * Give a specified weapon to the Pawn.
 * If weapon is not carried by player, then it is created.
 * Weapon given is returned as the function's return parmater.
 */
exec function Weapon GiveWeapon( String WeaponClassStr )
{
	Local Weapon		Weap;
	local class<Weapon> WeaponClass;

	WeaponClass = class<Weapon>(DynamicLoadObject(WeaponClassStr, class'Class'));
	Weap		= Weapon(Pawn.FindInventoryType(WeaponClass));
	if( Weap != None )
	{
		return Weap;
	}
	return Weapon(Pawn.CreateInventory( WeaponClass ));
}

Right! So GiveWeapon() asks the Pawn to CreateInventory... so let's find that.

event final Inventory CreateInventory( class<Inventory> NewInvClass, optional bool bDoNotActivate )
{
	if ( InvManager != None )
		return InvManager.CreateInventory( NewInvClass, bDoNotActivate );

	return None;
}

Right, so Pawn.CreateInventory() just calls InvManager.CreateInventory(). So what is InvManager?

var repnotify InventoryManager			InvManager;

So we see that it's a reference to an InventoryManager. Ok, so what does CreateInventory() do within InventoryManager.

/**
 * Spawns a new Inventory actor of NewInventoryItemClass type, and adds it to the Inventory Manager.
 * @param	NewInventoryItemClass		Class of inventory item to spawn and add.
 * @return	Inventory actor, None if couldn't be spawned.
 */
simulated function Inventory CreateInventory(class<Inventory> NewInventoryItemClass, optional bool bDoNotActivate)
{
	local Inventory	Inv;

	if( NewInventoryItemClass != None )
	{
		inv = Spawn(NewInventoryItemClass, Owner);
		if( inv != None )
		{
			if( !AddInventory(Inv, bDoNotActivate) )
			{
				`warn("InventoryManager::CreateInventory - Couldn't Add newly created inventory" @ Inv);
				Inv.Destroy();
				Inv = None;
			}
		}
		else
		{
			`warn("InventoryManager::CreateInventory - Couldn't spawn inventory" @ NewInventoryItemClass);
		}
	}

	return Inv;
}

Right, so this class spawns the inventory and adds it to itself. Aha, we see it using Owner! So let's look up the definition of Spawn to see why Owner is used there.

/** Spawn an actor. Returns an actor of the specified class, not
 * of class Actor (this is hardcoded in the compiler). Returns None
 * if the actor could not be spawned (if that happens, there will be a log warning indicating why)
 * Defaults to spawning at the spawner's location.
 *
 * @note: ActorTemplate is sent for replicated actors and therefore its properties will also be applied
 * at initial creation on the client. However, because of this, ActorTemplate must be a static resource
 * (an actor archetype, default object, or a bStatic/bNoDelete actor in a level package)
 * or the spawned Actor cannot be replicated
 */
native noexport final function coerce actor Spawn
(
	class<actor>      SpawnClass,
	optional actor	  SpawnOwner,
	optional name     SpawnTag,
	optional vector   SpawnLocation,
	optional rotator  SpawnRotation,
	optional Actor    ActorTemplate,
	optional bool	  bNoCollisionFail
);

Ahh right! So when spawning an actor, you can define its owner, right from the start. So when weapons are spawned, they have their Owner set to the same Actor that owns the InventoryManager. So who owns the InventoryManager? So let's find where InvManager is spawned.

	// Spawn Inventory Container
	if (Role == ROLE_Authority && InvManager == None && InventoryManagerClass != None)
	{
		InvManager = Spawn(InventoryManagerClass, Self);
		if ( InvManager == None )
			`log("Warning! Couldn't spawn InventoryManager" @ InventoryManagerClass @ "for" @ Self @ GetHumanReadableName() );
		else
			InvManager.SetupFor( Self );
	}

Ahh right, so the InventoryManager is owned by the Pawn that spawned it. Is the pawn owned by anyone else?

function PossessedBy(Controller C, bool bVehicleTransition)
{
	Controller			= C;
	NetPriority			= 3;
	NetUpdateFrequency	= 100;
	bForceNetUpdate = TRUE;

	if ( C.PlayerReplicationInfo != None )
	{
		PlayerReplicationInfo = C.PlayerReplicationInfo;
	}
	UpdateControllerOnPossess(bVehicleTransition);

	SetOwner(Controller);	// for network replication
	Eyeheight = BaseEyeHeight;

	if ( C.IsA('PlayerController') )
	{
		if ( WorldInfo.NetMode != NM_Standalone )
		{
			RemoteRole = ROLE_AutonomousProxy;
		}

		// inform client of current weapon
		if( Weapon != None )
		{
			Weapon.ClientWeaponSet(FALSE);
		}
	}
	else
	{
		RemoteRole = Default.RemoteRole;
	}


	//Update the AIController cache
	if (Weapon != None)
	{
		Weapon.CacheAIController();
	}
}

Aha! So the Pawn is owned by the Controller that possess it in the end.

So after all that, it is deduced that the Weapon is only relevant to the Owner which is either a PlayerController or AIController. If the Weapon is only relevant to the Owner (as defined by bOnlyRelevantToOwner); and since relevancy determines who receives information... then that means that Weapon is only ever replicated to a single PlayerController or AIController.

If no replication occurs then this would explain why other clients wouldn't get each other Weapons. So if the Weapon doesn't exist on the client, does this mean that the Weapon function replication wouldn't get called?

According to (http://udn.epicgames.com/Three/Funct...nction%20calls),

On the client, every function has to originate from a 'source'. A source can be a server-client replicated function, an exec function, or an event. Events, while not covered previously, are quite simple. An event is any function that is called from native code. Events happen both on the server and on the client. The server does not directly tell the client to execute the event, but the client knows to execute the event based upon the game state (colliding actors, hitting a wall, a timer event, ticking of the game state, etc). If that event is simulated, then it can also serve as a 'source' of client side function calls. A source can call any function it wishes, assuming it meets the client side execution conditions, which can then call any...and so on.

Right, so every function has to originate from a source. If there is no corresponding actor, there can't be a server-client replicated function, exec function or an event because there simply isn't an instance of that Actor on the client.

[Solid Snake]

Ok, after all that what can we do about this?

So we know that UT somehow syncs other clients about clients weapons... so let's search on the UDN for "Weapon Attachment Replication". We find...

• http://udn.epicgames.com/Three/ReplicationProxy.html
  http://udn.epicgames.com/Three/Netwo...%20Attachments

The Networking Overview document says....

Avoid having interrelated groups of Actors all replicated, both because of performance and to minimize synchronization issues.

In Unreal Tournament, Weapons are only replicated to the owning client. Weapon Attachments are not replicated, but spawned client side and controlled through some replicated Pawn properties. Pawns replicate FlashCount and FiringMode, and UT Pawns replicate CurrentWeaponAttachmentClass. The ViewPitch property in Pawn is another example of this pattern in use.

Right, so it confirms what we found out about Weapon replication. So, here it suggests to use weapon attachments which are spawned on the client side and controlled via replicated pawn properties. So what document describes this, what about the other one?

Aha, so ReplicationProxy discussed Weapon Attachments in more details! So one way to do this, is to use this pattern of having pawn replicate properties .... ....

So after all this, I wonder if the UDN discusses anything about variable replication?

http://udn.epicgames.com/Three/VariableReplication.html ... yeah I think so.

even though the documentation says that the ServerStartFire does deal with all clients.

I also didn't see where this was stated within the documentation; unless this was just a misinterpretation.

[slowJusko]

My understanding is that Start Fire is only used for the client who wants to fire and server - no one else.
Press fire -> call StartFire on Client -> call ServerStartFire on Server -> server version of weapon does its logic, increments Pawn.FlashCount -> FlashCount is replicated to all other clients -> all other clients play firing animations, sounds and effects.
So yes, StartFire is never called on other clients.

[Ompakim]

Let's start right from the top, and let's use the UDN documentation to provide us answers.

Snake went on a rampage! Megakill! Lovin it

[meowcat]

I hope all future thread readers appreciate what Solid Snake posted! For many coders/mod makers (on older versions of UT) it took months, if not years, to completely understand/trace through the weapon replication code and learn what he has so thoroughly and succinctly explained above! Thank you Solid Snake!

[VendorX]

@Solid Snake: That was great - should be Sticky.

[_h2o_]

yes it should be another Solid Snake's gem on UDN about Multiplayer and replication

i hope Epic Games admins will do it.

tnx Solid Snake!

[petergpls]

Well definately a very big thank you to such a descriptive thread as what was supplied by Solid Snake and I as a newbie to this forum and to UScript as a C++ developer from way back thank you again.

I have read through the description and just as I thought I may have a resolve to my current dilemma (and maybe others) either by using the much appreciated descriptive and followed through entry by Solid Snake or by using the InvManager replication as supplied by _h20_ I am not closer to solving this.

@_h20_: Thanks for the example InvManager and I tried the code by adding it to a derived class from UTPawn and used some debug only to find that myInvManager never gets repnotified (probably because I need to do something else which is missing??). The outcome is that the non-owner client pawn does not fire even though the owner pawn does fire. Yes Flashcount is called on all clients when StartFire is called but there are no fire effects, projectile no nothing!

@Solid Snake: Thanks again and I can hardly wait to grab the DVD over the weekend but at the end of your entry you said:
"Aha, so ReplicationProxy discussed Weapon Attachments in more details! So one way to do this, is to use this pattern of having pawn replicate properties .... .... "
HOW DO YOU USE THE PATTERN OF HAVING PAWN REPLICATE PROPERTIES IN ORDER FOR ME TO ACHIEVE FIRING IN ALL CLIENTS? The code examples in the Proxy Patterns are referring to code used in base classes and the documentation says to look closely at the logic. What do I need to do in my derived Pawn class or derived Weapon class to get this working. I must be missing something here - an example that will work would be a great assistance and this could then be related to your very descriptive entry.

[_h2o_]

you should change your invmanager, weapon, inventory and others classes of inventory and weapons you have to not be replicated only to owner. and to them that they are always relevant with bAlwaysRelevant=true
and look also maybe weapon replication only works for owner too, then do like with invmanager

[Solid Snake]

There is a lot of documentation on variable replication. Honestly, dont do what h2o is suggesting.

Short answer is, I believe FlashCount is tagged as RepNotify....

[petergpls]

Yes I can see that flashcount is replicated in non-owner clients and I can catch that in ReplicatedEvent so I need to somehow get PlayFireEffects to be called.. No worries will look up the documentation as you suggested and see where I go from there. Thanks to all of you for all your great help.