Depends on what you’re doing. For client gameplay actions such as movement or firing/attacking you want to account for lag … aka lag compensation. So do first on client, let the server authenticate and apply. e.g. Firing a weapon. You can fakie the action locally, but the server determines and applies the result.
For the chest example you want the overlap (trigger) to applied on the servers proxy. Thus Switch on Authority (authority) -> proceed with logic.
It will probably execute in the same tick/frame from the client so it does not matter. Lag compensation is a method of normalizing server-side the state of the world for each player as that player’s user commands are executed. You can think of lag compensation as taking a step back in time, on the server, and looking at the state of the world at the exact instant that the user performed some action.
For the chest example I wanted to show the difference between repNotify and multicast. It does not matter how it triggers.
**TL;DR: **It all really depends, and you’ll really only find out what you need by trying to execute it.
Not always the case. If a player has a ping of 250ms then there’s an rpc travel time of 125ms to server (several frames/ticks), server processing and response (frame), and another 125ms back to client. Also, as far as I’m aware RPC’s are only sent at start of tick/frame.
Where should X be at “this” moment in time on the processing system. Lag comp in a nutshell.
e.g. Client fires (FX, anim etc), then rpc’s server (timestamp, transform etc). Server receives and calculates where the projectile should be based on shot time (predict projectile path advanced), spawns projectile at synced position, velocity etc.
My example of lag comp was in reference to the client responsiveness aspects of it. Similar to how CMC functionality works add movement/pitch/yaw input and so forth. Your not waiting on the server to do and respond. Instead it simply corrects on prediction error.
Gotcha. For me that equates to Relevancy vs Bandwidth, Network Saturation
Command is executed in the same frame on the client side.
If you set in the Event:
Client max speed -> then Set it on the server or
first Set it on the server -> then on the client is the same. 
Both commands will be executed locally first (in the same frame of tick). You can even print out and debug it and you will see that it will be executed in the same frame (for instance RPC in tick for test purposes).
If you want to execute/simulate with 125ms delay because the client is local and theres no delay, you can use Client command -> delay 0.125 -> RPC, otherwise it will be executed in the same frame.
For instance:
1 frame: client walk
10 frame: client press Sprint button -> client will set max speed and send RPC in this frame (Same event, does not matter order in this case)
11 frame: delay
12 frame: delay…
21 frame:…delay, server received request from that client, processing and response
40 frame: client(s) receive response from the server
(for example)
The point is that there is no difference what is put first in this case, and even if there is, it will not affect the accuracy or incorrect position prediction or the like.
I hope I am not wrong
Ok I see where we hitched. Misunderstanding.
Flow of inline processing logic doesn’t matter. It all does execute in a single frame. This isn’t my argument.
Top portion is client responsive.
Bottom portion is what I’m arguing against. This case is what’s constantly being provided as the way to go. On the forums and Answer hub. Which ALWAYS results in jitter and what feels like input responsiveness delays when dealing with “Characters”.
This same process is the route I see most take for weapon firing, item pickup etc. My opinion is for these types of things is to fakie the action (fx, anims etc) locally and have the server do the authoritative aspects during this downtime.
e.g. while the packet is in route the gun is recoiling, muzzle flash, sound etc. You’ll typically have a response (projectile replication) way before the muzzle has hit its recoil apex, flash is offscreen, sound has ended. Versus… trigger, wait for server, then animate, fx etc.
Me saying “Do local first, then server” is all about getting the new dev working in the right mindset and maintaining client-responsiveness.
Yes, that could be bad It’s already executed on the client side, so no need server authority to execute on the Owning client (in this case).
However, this is a different example (look at my first post in the thread), nothing like that you talked about has been shown. Misunderstanding probably.
Ok super geniuses! Riddle me this!?
Using a “Character” blueprint and character movement, I have come to a hitch, and I’m sure there’s a simple workaround.
I need to adjust my capsule height on my players for crouching. Obviously the server executes it fine, but the clients have 2 options.
OR
Is there something I’m missing in regards to replication where I can say “hey, if it’s the client that called this command, don’t update them again” ??
Ha! It was really simple once I realized the conditions for my variables included “Skip owner”… oh thank god…
hehehe yeah