[UT2K4 Replication] Objects as parameters in replicated functions

  • Two Factor Authentication is now available on BeyondUnreal Forums. To configure it, visit your Profile and look for the "Two Step Verification" option on the left side. We can send codes via email (may be slower) or you can set up any TOTP Authenticator app on your phone (Authy, Google Authenticator, etc) to deliver codes. It is highly recommended that you configure this to keep your account safe.
T

TheSoepkip

New Member
Nov 15, 2004
3
0
0
Hello everyone,

Once again a question about replication... I've read several replication docs out there but I still find it difficult to get from the theory to a working application. I was hoping someone could enlighten me by pointing out my mistakes and perhaps provide or point me to a working or similair example.

The situation: I've some code in which players can form teams. A player can send an 'invite' to another player. The other player can either accept or decline the invitation. Upon accepting the invitation, the other invitee is added to the team object of the inviter. Everything works up to the point where the sever is to tell the invitee what his new team looks like. The latter is displayed in the HUD. I've tried this using function which more or less looks like this:

"setTeam(Team newTeam)"

This function is called from a pawn which is the baseclass of the pawn used by the playercontroller. When add some logs to the application, I get the following output:

[server] setTeam( package Base.Team );
[client] setTeam( none );

Because of this I concluded it's not possible to call client methods with objects as parameters. Is this correct and could someone explain why the team object 'disappears' ?

Thanks,
 
M

Mychaeel

New Member
Oct 3, 2001
3,830
0
0
47
Frankfurt/Main, Germany
www.planetjailbreak.com
It is perfectly possible to pass object references in replicated functions, but doing so doesn't automatically replicate the referenced object itself. If, in your case, that TeamInfo actor doesn't happen to be replicated to the client at the time the function is called, the client will receive a "None" reference instead of a valid TeamInfo reference.

However, since TeamInfo is derived from ReplicationInfo, it should be replicated to clients. Maybe you're just dealing with a timing problem here because you're calling your function too soon after spawning the TeamInfo actor.
 
T

TheSoepkip

New Member
Nov 15, 2004
3
0
0
Thanks for the reply Mychaeel.

I wasn't clear on this. The team object I'm referring to is "just" an Object, it's not an object of the TeamInfo class from unreal script.

I have some experience with other game engines, which is both an advantage and disadvantage ... The last engine I worked with passed objects as an id, which basically implied that as long as the object exists on both server and client you can pass it without any problems. I am more or less expecting Unreal to work the same way, which it obviously isn't :(

I've tried wrapping it into a ReplicationInfo, but that didn't seem to work; in fact it only made it worse so to say. Perhaps I'm approaching this the wrong way ... that's why I asked if perhaps someone had an example of using the replicationinfo.
 
M

Mychaeel

New Member
Oct 3, 2001
3,830
0
0
47
Frankfurt/Main, Germany
www.planetjailbreak.com
TheSoepkip said:
I wasn't clear on this. The team object I'm referring to is "just" an Object, it's not an object of the TeamInfo class from unreal script.
Click to expand...
Objects of classes not derived from Actor don't work with replication; all the native replication magic is in Actor. Thus, since your object cannot be replicated to the client, passing a reference to it from server to client won't do any good -- even if the client receives some sort of unique object identifier (which it probably does), there's no corresponding object on the client to point it to.

The last engine I worked with passed objects as an id, which basically implied that as long as the object exists on both server and client you can pass it without any problems.
Click to expand...
There's the point: Your object doesn't exist on both server and client. Only Actor-derived objects can do that trick.

I've tried wrapping it into a ReplicationInfo, but that didn't seem to work; in fact it only made it worse so to say. Perhaps I'm approaching this the wrong way ... that's why I asked if perhaps someone had an example of using the replicationinfo.
Click to expand...
ReplicationInfo is merely an Actor subclass with some replication-related default properties conveniently set; there's no special magic in ReplicationInfo. (Actually, you can look at the ReplicationInfo source code to see which properties are set there -- you could do the same with any Actor-derived class.)

If you want to pass structured information from server to client, maybe you should consider using a struct instead of an object. Structs are passed by value (instead of by reference), so you can safely pass them through a replicated function as long as their size doesn't exceed a certain limit (about 384 characters total for all function parameters, I think). If your struct contains references to objects, the limitations mentioned above apply for those too, of course.
 
T

TheSoepkip

New Member
Nov 15, 2004
3
0
0
Hey Mychaeel,

Thanks for your reply, this makes things much clearer.

Mychaeel said:
Objects of classes not derived from Actor don't work with replication; all the native replication magic is in Actor. Thus, since your object cannot be replicated to the client, passing a reference to it from server to client won't do any good -- even if the client receives some sort of unique object identifier (which it probably does), there's no corresponding object on the client to point it to.
Click to expand...

Well just for the sake of (a pointless) argument: there is a corresponding object on both server and client. I create the object on both client and server. Therefore "it should" be able to pass it ... Guess I'm asking too much.

Mychaeel said:
There's the point: Your object doesn't exist on both server and client. Only Actor-derived objects can do that trick.
Click to expand...

Yeah that's the point indeed ... I don't want to use actors. Actors come with a lot of overhead which I really don't need when replicating maps, sets and other simple datastructures.

Mychaeel said:
If you want to pass structured information from server to client, maybe you should consider using a struct instead of an object. If your struct contains references to objects, the limitations mentioned above apply for those too, of course.
Click to expand...

I think I will resort to do that. Back to the old event driven updates I guess.

Once again thanks for the insights M. If I sound a bit grudgy please don't take it personally... this has been very helpful. I'm just a bit fed up with not making that much progress at the moment. I feel that replication should have either used event driven netupdates or fully transparent RPC ... it all feels a bit like it's stuck somewhere in between :(.

Anyway .... back to the design table ;).

Thanks !
 
Last edited:
You must log in or register to reply here.
Top Bottom