Using multicast function to spawn weapon effects.

[envenger]

I went through the shooter code and saw a variable is used spawn the firing sounds and muzzle flash. What would be the disadvantage if I use a multicast function instead and spawn it when the client firing takes place.

I wont have a listen server in game only a dedicated server and mostly I don't think players will be able to abuse the firing sound or muzzle flash. I might be wrong though.

[oasf]

I asked a similar question here yesterday, and based on the answers I got, you should use multicast.

I was told that multicast is, as opposed to OnRep, instant.
Unlike OnRep, multicast is only called on clients close by. That shouldn't be too hard to rationalize though, since it is sounds and light you want replicated.

(Depending on scope, multicast should also be cheaper, bandwidth wise... Correct me if I am wrong. This is far outside my comfort zone...)

[alexgrist]

Using a NetMulticast will work fine, otherwise it seems that you can also loop through the connected clients and separately call a Client RPC to each of them.

[envenger]

Using a NetMulticast will work fine, otherwise it seems that you can also loop through the connected clients and separately call a Client RPC to each of them.

How do I do that? Basically my problem is when the firing takes place, I want to spawn the event on the owner client instantly. Then I will if I use the server to spawn the effect and replicate it to all clients wont the owner client get 2 effects? To solve that issue I want to use multicasts any easier way out?

[oasf]

I feel like I'm a bit of a knowitall here now, since I was schooled on this very topic yesterday.
But, since I am shameless:
Multicast is the way to go, IMO. Unless you need to be sure that all clients receive the call. Then I would use OnRep.

To iterate through actors, as suggested, sounds like trading a lot of CPU-time for a little bandwidth.
Not sure about this though....

EDIT: When you use OnRep events, the function will be called on clients only. That is why people usually call the function directly (from server), after they have changed the DoRep var...

[Elvince]

NetMulticast will cost more than a standard replication. The RPC system cost more than replication. I can't give you detail on this, but this have be mentionned many times on network thread in the forums.

What were the pro to use NetMulticast instead of a std replication?
If you are looking for instant replication, you can tell you actor to replicate immediatly and not wait until the next replication time.

As far as I know, NetMulticast has no scope. It will call the client function on all connected client. So there are no "bandwith" saving and it may be the opposite if you set it as reliable.

ShooterGame approach is what's Epic is using in UT4 also. It's was also the same approach in UDK, UE3. I think you can rely on this design to setup your game unless you really have some specific gameplay that need a specific design. It's always case by case.

@Oasf,
Could you please post the link to the thread you mentionned for the discussion on Multicast, I will be interested to read this?
thanks,

[iniside]

I went through the shooter code and saw a variable is used spawn the firing sounds and muzzle flash. What would be the disadvantage if I use a multicast function instead and spawn it when the client firing takes place.

I wont have a listen server in game only a dedicated server and mostly I don't think players will be able to abuse the firing sound or muzzle flash. I might be wrong though.

NetMulticast will be called before any replication occurs. It's executed right after it's called in code. Which might be desired behaviour, or it might not. That is up to you.

What is the real problem here is that calling any RPC function halt execution of rest of code, until RPC is fully executed (so nothing will replicate, because everything is waiting until functions are excuted).

In general you should avoid using NetMulticast and in general RPC for cosmetic effects. Instead use simple replicated int8 and increment it every time you need to spawn some effects on clients.

Unlike OnRep, multicast is only called on clients close by. That shouldn't be too hard to rationalize though, since it is sounds and light you want replicated.

Not true. Both are called only on clients relevant to the actor, which called them.

[joeGraf]

What is the real problem here is that calling any RPC function halt execution of rest of code, until RPC is fully executed (so nothing will replicate, because everything is waiting until functions are excuted).

That's not correct. The RPC is placed into the outgoing buffer and then code resumes executing as if it has completed. It may not arrive until many ticks later if there are network errors or latency issues.

[joeGraf]

NetMulticast will cost more than a standard replication. The RPC system cost more than replication

Correct. Variable replication is the cheaper solution

[joeGraf]

Using a NetMulticast will work fine, otherwise it seems that you can also loop through the connected clients and separately call a Client RPC to each of them.

Those two approaches are identical, as a NetMulticast iterates each client sending the RPC

[iniside]

That's not correct. The RPC is placed into the outgoing buffer and then code resumes executing as if it has completed. It may not arrive until many ticks later if there are network errors or latency issues.

Oh thanks, for clarification. I thought I heard on one stream, that RPC will just stall execution until it's done. It's good to know it's not the case!.

[oasf]

@Inside:
You say the same in this thread.
I was stuck on Acrens claim that multicast is only replicated on clients close to the actor..

Thanks for clearing this up, Inside and Graf