10. Comprueba eventos y red desde tu propio Actor

Aquí comprobarás dos cosas diferentes: On Value Changed avisa de un cambio local del componente, y la replicación lleva el valor del servidor al componente del cliente. El evento también puede dispararse por un setter local; verlo impreso, por sí solo, no demuestra que haya llegado por red.

Primero: observa un cambio local

1. Vuelve al Actor Normal. Selecciona Wallet y añade su evento On Value Changed desde Details.
2. Para evitar números sin contexto, convierte Previous Value y New Value con To Fixed String, Decimal Places 2. Usa Format Text con el patrón Cambio: {Anterior} -> {Nuevo}, conecta ambos valores, convierte el texto a String y llévalo a Print String. Activa Print to Log si también quieres conservar el mensaje en Output Log.
3. Ejecuta tus botones. Pasar de 1000 a 1025 debe imprimir Cambio: 1000.00 -> 1025.00. Reasignar exactamente el mismo valor no debe generar otro evento. También puedes usar dos Print Scientific Number, pero entonces verás dos números separados: uno es el anterior y el otro es el nuevo, no dos saldos actuales.

Después: configura una prueba de red aislada

1. Duplica el Actor Normal como BP_MiRed. Elimina de esta copia la creación del widget y desconecta del BeginPlay las prácticas anteriores, incluida Practica 2 si inicializa Wallet a 1000. Conserva tus ejercicios originales en el Actor anterior. En esta prueba debe haber un solo escritor: el servidor.
2. Activa Replicates y Always Relevant en Class Defaults. Always Relevant facilita este pequeño escenario sin personaje. Comprueba que Wallet mantiene activada su replicación.
3. Conecta BeginPlay directamente a Switch Has Authority. En Authority, conecta Try Set Value de Wallet con Make Scientific Number, Base 125 y Exponent 0. Comprueba Return Value con Branch: en True imprime Servidor: establecido 125; en False, Out Error mediante Print Scientific Number Error.
4. En la rama Remote de ese mismo Switch de BeginPlay, imprime Cliente: esperando estado y conecta Delay 2 segundos -> Get Value de Wallet -> To Fixed String -> mensaje Lectura tras 2 s: {Valor} -> Print String. Get Value es puro: su salida se evalúa cuando se ejecuta la impresión después del Delay. Esta espera es solo una observación didáctica, no una garantía de tiempo de entrega de red.
5. Conserva On Value Changed -> mensaje Cambio: {Anterior} -> {Nuevo} -> Print String como un flujo independiente. No conectes aquí el Delay ni otro Switch Has Authority. Así distingues la notificación de cambio de la lectura puntual después de BeginPlay.
6. Coloca solo BP_MiRed en el nivel. En las opciones de Play pon Number of Players = 2, Net Mode = Play As Listen Server y ventanas separadas. Pulsa Play y espera la lectura del cliente.

Qué deberías ver al completar el punto 6

Un listen server también tiene un jugador local. Con dos jugadores hay un mundo servidor y un mundo cliente; no son dos clientes independientes.

Origen del mensaje	Resultado esperado en esta prueba
Servidor, después del setter correcto	Servidor: establecido 125
Servidor, evento de cambio	Cambio: 0.00 -> 125.00, si Wallet partía de cero y el evento estaba conectado antes del cambio
Cliente, BeginPlay	Cliente: esperando estado
Cliente, al recibir un valor distinto	Un evento cuyo nuevo valor sea 125.00. El anterior será su estado local previo; puede ser cero. No uses un orden exacto de mensajes como condición de éxito
Cliente, lectura después del Delay	Lectura tras 2 s: 125.00, una vez recibido el estado del servidor

La comprobación principal: el servidor establece 125, el cliente termina leyendo 125 y la rama Remote no ejecuta ningún setter. Si la lectura todavía es cero, comprueba el éxito del setter, Actor Replicates, la replicación de Wallet y que ambos mundos tienen el Actor; observa si llega después. El Delay no realiza la replicación ni la fuerza.

Cómo leer los mensajes de Unreal: Print String añade automáticamente Server: o Client 1: en Play In Editor. Por eso imprimir el texto Server produce Server: Server: no es un error. Los mensajes recientes suelen aparecer arriba. Con Run Under One Process activado, los mensajes de pantalla pueden verse mezclados o repetidos en ambas ventanas porque comparten el motor; fíjate en el prefijo que identifica su origen, no solo en qué ventana aparece el texto.

Si ves 0, 1000 y después 125: comprueba si conservaste la inicialización de la cartera anterior. Un cambio local de 0 a 1000 imprime Previous Value = 0 y New Value = 1000. Después, al llegar 125, el evento puede imprimir Previous Value = 1000 y New Value = 125. Los dos 1000 describen el destino del primer cambio y el origen del segundo. Otra impresión de 125 puede ser la lectura tras el Delay; no demuestra una segunda escritura ni una doble replicación. Sin etiquetas y sin ver el grafo completo no se puede atribuir cada línea con certeza.

Confirma el origen de los cambios

7. Repite con Play As Client y servidor dedicado; después desactiva Run Under One Process para probar procesos separados. El servidor dedicado no tiene una ventana de jugador: consulta su log para sus mensajes. Los prefijos y la presentación pueden cambiar fuera de PIE; conserva las etiquetas propias del ejercicio.
8. Pon un breakpoint en Try Set Value y selecciona la instancia adecuada en el depurador: el setter de este grafo debe ejecutarse en el servidor, mientras el cliente recibe el estado sin pasar por él. Un setter ejecutado localmente en el cliente puede cambiar su copia, pero no autoriza ni envía ese cambio al servidor. Mantén las escrituras del saldo autoritativo en el servidor.

Esta práctica usa la replicación de Scientific Number Value Component (Normal). El componente Safe no replica automáticamente: si lo utilizas en un juego multijugador, debes definir cómo el servidor valida las operaciones y comunica el estado a los clientes.