Hi,
Not sure if everyone will agree this is a bug, but to me it is. That said, I wouldn’t be upset if this post was moved.
If a server has no clients then it will not run multicast functionality locally. While this may be fine for some applications, for others (i.e. persistent worlds) this means we have to add functionality that we could avoid with a simple change. It would be helpful if the server always ran multicast code locally and optionally triggered it on any connected clients as per usual.
The way it is now, we have to do a lot to call the functionality once and only once on the server. Again, sorry if this doesn’t officially qualify as a bug. It’s definitely been bugging me.
Thanks!
There are problems with implementing this functionality, because multicasts are mostly often used for FX and cosmetics. Imagine your server spawning particles locally without even asking you - it will kill your performance.
If i need something to run on server as well as on clients, i define a _onServer function, a _multicast function, and a _locally function.
The _onServer and _multicast versions then can both call _locally version, which contains all the juice.
A year is a lot longer than it seems. Now I know better. The way I wanted it, I’d need a SwitchHasAuthority to tell the difference and that’s doubly inefficient. So yeah, two separate functions (for both of us I suppose hehe). What I’d like now is a multicast option that only sends to the non-owning clients.
imo that’s the most important missing feature in UE4 networking. i need it badly too.
i have two workaround for this. one is described here: Best way to replicate timeline-changing anim variable? - Editor Scripting - Unreal Engine Forums
and is BP timeline oriented, being hacky and unrecommended.
the second way is C++ and is adding a 4th version for the function, which in my case i call _startThenSync
you can call _locally from inside of it and then triggering _onServer. (which calls multicast afterwards)
on need you can add more logics for the calling client into that _startThenSync, like for example GUI update (which can be irrelevant to multicast if it’s player-specific GUI).
This way you can also avoid command delays, because you start your action straightaway in offline before the server receives and triggers multicast back. of course you need to apply caution and prevent cheating form happening, so that would be bad for damage/death etc…
If you utilize that wisely, actions won’t happen twice on the calling client (once locally then second time by multicast)
btw if you find a better way i would be very glad to hear it!
Actually, it looks like servers will call multicast code when there are no clients connected. I guess they changed it. I mean, it does say “Run on All” so that means run on all. If you want to make that description consistent then I guess they considered it a bug too.
I’m pretty sure this is the case because I put print strings in my Multicast events (when a bullet hits something) and set up some bot-on-bot action. The strings were being printed without any clients.
I still agree with you on efficiency but I think I prefer it this way. It makes coding easier, even with the extra check on authority. I’m sure Epic is handling the situation as efficiently as possible. And I know they don’t accept extra processing easily because they wouldn’t change a FORCEINLINE to virtual so we could change the character capsule origin and get it to work right…
There is no crash so there is no report. This was about functionality. Thanks tho.