Replication/Client Features Issue

[Feralidragon]

Well, I have 2 features that spawn effects client side only ("broken" BSP blocks/stones from an explosion through a decal (giving the illusion that you actually broke a wall or gave at least some real damage to it other than the decal itself, which means, BSP visually like stones with the hit wall texture) and some carcasses effects such as flames and such).

It happens that everything works perfectly both offline and online, but regarding only the client "owner" or "instigator", which means that on offline everything works like a charm, and on online play only the instigator of those effects is able to see the featured extra client side effects.

On online play, you're able to see the flaming head on a headshot from the boltrifle or 1 single chunk on fire when using the combo or the super bolt one (the ones that exist both in the server and all clients, but the rest of the chunks (spawned only client side by the engine from what it seems) don't get flamed at all, and not even a single stone from the "broken" BSP appears.

In resume, I tested my new weapon pack with my bro today, and regarding only these 2 functions, everytime he was the instigator of those effects, he saw them on his end but not me in my end, and when I was the instigator, I saw my own instigated effects, but he didn't, so basically these features are only working for the instigator for some reason.

Basically, what I want to know is: What might be happenning (in general terms) so that only the "instigator" is able to see these effects on his end?
What is the correct thing to do when I want to handle some effects fully client side, but on all clients?

Basically I try to spawn stuff client side only depending on the client settings (decals enabled for instance), but I use "bNetTemporary=True" with "Simulated" and "None" proxies actors, and a "Level.NetMode != NM_DedicatedServer" filter. Should I use Roles filtering instead? (like "Level.NetMode == NM_StandAlone || Role < ROLE_Authority").

What I am really needing here is mostly knowledge on "client side only stuff spawning further stuff" of sort to speak.

[anth]

Try bAlwaysRelevant=True and NetPriority=4.0. You might also want to check the replication deobfuscation document which explains the replication rules in great detail.

[Rakiayn]

try bnettomporarely = false

[Feralidragon]

Try bAlwaysRelevant=True and NetPriority=4.0. You might also want to check the replication deobfuscation document which explains the replication rules in great detail.

I want to avoid bAlwaysRelevant to avoid unnecessary bandwidth usage (which can a lot in this kind of effects), but I will see with NetPriority tweaks.
Regarding that document, that's the document I used to "learn" replication, together with the already built-in actors to see differences in replication, but I guess it's better to check it again to see if I missing something...

try bnettomporarely = false

Quite the same reason why I don't want to use bAlwaysRelevant, besides bNetTemporary=True kinda "breaks" the ties between server and client actors once spawned (so the server doesn't affect the client version of the object after spawning), which is what I want, with bNetTemporary=False the tie between client and server would still exist always (changes on the server version would always affect the client version as long as the variables could be replicated), which is great with actors that do need server updates to the client times to times (like a seeking projectile, or something that acts differently and can't be fully simulated in the client, like in case something in the server happens, or just something simulated that has still to make updates from server to client).

Besides, the issue here is that some stuff is spawned only client side (the server doesn't even "know" anything about those effects in theory), the bNetTemporary=False wouldn't affect a thing actually, or would even avoid the existence or correct settings of the spawned client actor.

EDIT: Both features origin (actors that spawn effects) have already bNetTemporary=False, perhaps is what I am doing wrong since I want the server to forget about these client side.


Either ways, thanks both, I will take a better look at that document a try a few things, as the only weird thing is that the instigator always sees the effects, no matter what (offline and online), just other clients online can't see them, so something is missing or something shouldn't be there, something that makes these effects relevant to the instigator and not the other clients.
And I have been thinking: could it be the setting "bReplicateInstigator"? That's the only setting connected to the instigator relevancy...

[Rakiayn]

maybe it has to do with the owner ( instigator is probally als the owner)
maybe you have bonlyownersee set to true?

[gopostal]

Perhaps backing up a bit and finding out why spawned blocks don't replicate correctly but projectile-caused explosions (and the like) do. Compare them and at worst case, make them an offshoot of the projectile class at least long enough to see if they replicate that way? I'll bet you some sort of replication class will need to be declared for them. When I played a bit wih the texture thing it was clearly a replication issue causing the failure, and by extension I think the same is true here.

{Get it? "Offshoot"..."projectile"...heh heh...}

[Feralidragon]

The problem was that these kind of projectiles and effects are spawned only client side depending on the client settings, while the normal projectiles are spawned both server and client side, as most of their effects.

I wouldn't bother much with this, but I really wanted to aplly at least the decal one in some of my nukes, and since most people actually wait to see the nuclear explosion in the current version, in the new version they should be able to fully see it as well on all their glory.

Btw, notice the "was" word at the first sentence, well I guess I finally managed to understand why and how to solve it.

I took the advice of Antrax and took a look again at that document about replication and I tried bAlwaysRelevant=True in one of the effects (the decal based one), it worked. You are able to see the effects, as all the clients around (each one with their settings), plus from the 2 stages of relevancy on replication, my effects passed both for the instigator, but didn't pass the the 2nd stage regarding other clients, and I noticed this in the document:
If its Instigator is the client, then it is relevant. - This explains all the issue alone.

The effects "controllers" are hidden, soundless and ghostly (no collision) actors, which from the client point of view their are never relevant for them. To be relevant they have to be either: viewable, have any collision or have some sort of audible ambient sound, but for the instigator, it's always relevant no matter what, and so the issue.

And well, I still want them be hidden and relevant to all the clients, and using bAlwaysRelevant is the wrong way of doing things (since with bAlwaysRelevant the actors are always relevant for all the clients no matter if the actor is here and the client in the other side of the map, which in case of 10 players, it can represents ping issues or effects cutting without any need, and it gets even worse if used in MH, since some monsters also use these weapons).

And now that I think about it, I remember a really good trick to make an hidden object relevant wise to the clients, without using bAlwaysRelevant, and I already used this trick before to another replication issue I had of this type (I guess on XPickups or NW2X), and worked great, and that I will use it in this case as well, making the final solution.

Basically I will set:
bHidden=False
DisplayType=DT_Sprite
Texture=Texture'TransInvisible' (a fully black tiny texture)
Style=STY_Translucent
perhaps a DrawScale adjustment to avoid unnecessary rendering processing regarding the translucency

and that's it! It gets "hidden" from the real point of view, but for the game and server, it's something visible and that is rendered, and therefore relevant to all the client with a line of sight to it (which is all I want here).


Well, thanks for the help guys

[gopostal]

This is exactly why I am such a fan of your work. You won't quit until you work it out.

Well done! I'm anxious to see it.