10. Check events and networking from your own Actor
Build this example in your Unreal project and compare the result at each step.
On this page
Here you will check two different things: On Value Changed signals a local component change, and replication carries the server’s value to the client component. A local setter can also fire the event; seeing it printed, by itself, does not prove that the value arrived over the network.
First: observe a local change
- Return to the Normal Actor. Select Wallet and add its On Value Changed event from Details.
- To avoid context-free numbers, convert Previous Value and New Value with To Fixed String, Decimal Places 2. Use Format Text with the pattern
Change: {Previous} -> {New}, connect both values, convert the text to String, and send it to Print String. Enable Print to Log if you also want to keep the message in Output Log. - Run your buttons. Going from 1000 to 1025 should print
Change: 1000.00 -> 1025.00. Assigning exactly the same value again should not generate another event. You can also use two Print Scientific Number nodes, but then you will see two separate numbers: one is the previous value and the other is the new value, not two current balances.
Next: configure an isolated network test
- Duplicate the Normal Actor as BP_MiRed. Remove widget creation from this copy and disconnect the earlier exercises from BeginPlay, including Practica 2 if it initializes Wallet to 1000. Keep your original exercises in the earlier Actor. This test should have only one writer: the server.
- Enable Replicates and Always Relevant in Class Defaults. Always Relevant simplifies this small scenario without a character. Check that Wallet still has replication enabled.
- Connect BeginPlay directly to Switch Has Authority. In Authority, connect Try Set Value on Wallet with Make Scientific Number, Base 125 and Exponent 0. Check Return Value with Branch: on True, print
Server: set to 125; on False, send Out Error to Print Scientific Number Error. - On the Remote branch of that same BeginPlay Switch, print
Client: waiting for stateand connect Delay 2 seconds -> Get Value on Wallet -> To Fixed String -> messageRead after 2 s: {Value}-> Print String. Get Value is pure: its output is evaluated when the print executes after the Delay. This wait is only a teaching observation, not a guarantee of network delivery time. - Keep On Value Changed -> message
Change: {Previous} -> {New}-> Print String as a separate flow. Do not connect the Delay or another Switch Has Authority here. This lets you distinguish the change notification from the one-time read after BeginPlay. - Place only BP_MiRed in the level. In the Play options, set Number of Players = 2, Net Mode = Play As Listen Server, and use separate windows. Press Play and wait for the client’s read.
What you should see after completing step 6
A listen server also has a local player. With two players there is one server world and one client world; they are not two independent clients.
| Message source | Expected result in this test |
|---|---|
| Server, after a successful setter | Server: set to 125 |
| Server, change event | Change: 0.00 -> 125.00, if Wallet started at zero and the event was connected before the change |
| Client, BeginPlay | Client: waiting for state |
| Client, when a different value arrives | An event whose new value is 125.00. The previous value will be its prior local state; it may be zero. Do not require an exact message order for success. |
| Client, read after the Delay | Read after 2 s: 125.00, once the server’s state has arrived |
The main check: the server sets 125, the client eventually reads 125, and the Remote branch does not run any setter. If the read is still zero, check the setter’s success, Actor Replicates, Wallet replication, and whether both worlds contain the Actor; observe whether it arrives later. The Delay does not perform or force replication.
How to read Unreal’s messages: Print String automatically adds Server: or Client 1: in Play In Editor. That is why printing the text Server produces Server: Server: it is not an error. Recent messages usually appear at the top. With Run Under One Process enabled, on-screen messages can appear mixed or duplicated in both windows because they share the engine; pay attention to the prefix identifying their source, not only the window where the text appears.
If you see 0, 1000, and then 125: check whether you kept the previous wallet initialization. A local change from 0 to 1000 prints Previous Value = 0 and New Value = 1000. Later, when 125 arrives, the event can print Previous Value = 1000 and New Value = 125. The two 1000 values describe the destination of the first change and the source of the second. Another print of 125 may be the read after the Delay; it does not prove a second write or duplicate replication. Without labels and the full graph, you cannot identify every line with certainty.
Confirm where changes originate
- Repeat with Play As Client and a dedicated server; then disable Run Under One Process to test separate processes. A dedicated server has no player window: check its log for its messages. Prefixes and presentation may change outside PIE; keep the labels from the exercise.
- Put a breakpoint on Try Set Value and select the appropriate instance in the debugger: the setter in this graph should execute on the server, while the client receives the state without passing through it. A setter run locally on the client can change its copy, but does not authorize or send that change to the server. Keep authoritative balance writes on the server.
This exercise uses replication on Scientific Number Value Component (Normal). The Safe component does not replicate automatically: when using it in a multiplayer game, define how the server validates operations and communicates state to clients.