Output en Roblox Studio: encontrar la causa y comprobar la solución

Empieza por un caso repetible #

Cuando un botón no responde o falta una recompensa, anota la acción, el resultado esperado y el real. Por ejemplo: «Inicié la prueba, hice un clic, esperaba un mensaje de compra y no apareció». Así tendrás un caso concreto para repetir tras modificar el código.

Usa un proyecto de práctica separado. Los ejercicios muestran mensajes y comparan valores locales; no acceden a dinero de jugadores ni a datos guardados. El objetivo es relacionar una señal del programa con una acción. Después aplica el mismo proceso a una parte pequeña de tu proyecto.

1. Abre Output y prepara la vista #

La documentación actual sitúa Output en el menú Window y en la barra de la pestaña Script. Abre el panel y colócalo de modo que veas las nuevas líneas durante la prueba. Si la distribución cambia, busca el nombre de la ventana.

Revisa los filtros de tipo, contexto y texto. Para el primer ejercicio, elimina la búsqueda de texto y muestra mensajes del servidor, mensajes normales y advertencias. Activa Show Source para ver script y línea cuando estén disponibles. Guarda lo importante antes de limpiar: limpiar la ventana elimina mensajes visibles; corregir el código es otra acción.

2. Crea un Script de servidor #

En Explorer, añade un Script normal llamado OutputPractice dentro de ServerScriptService. El RunContext Legacy predeterminado sirve para esta práctica; también puedes escoger Server explícitamente. Pega el primer ejemplo y comprueba que el script esté activado.

Inicia una prueba de Studio. Debes ver coins con 8 y después Unexpected coin count como advertencia. Revisa su contexto de servidor. Si aparecen varios pares idénticos, busca copias del ejercicio. Cada script adicional genera sus propias líneas y puede hacer que una ejecución parezca varias repeticiones del mismo fallo.

local expectedCoins = 10
local actualCoins = 8
print("coins", actualCoins)

if actualCoins ~= expectedCoins then
    warn("Unexpected coin count")
end

3. Distingue mensajes, advertencias y errores #

print() muestra un valor o marca una etapa completada. warn() destaca una condición elegida por quien escribió el código. Aquí avisa porque 8 difiere de 10. Lee esa condición antes de deducir que hay un fallo del motor.

Un error de ejecución indica que una operación concreta no pudo completarse. Lee el texto junto con su fuente y los pasos de la prueba. El color por sí solo no identifica la causa. Comprueba si la línea pertenece a tu script, a otro componente o a una prueba anterior. El esquema separa estos tres tipos de señales.

4. Cambia un valor y repite la prueba #

Detén la prueba. En el OutputPractice original, cambia actualCoins de 8 a 10 y conserva expectedCoins en 10. Inicia otra prueba con el historial limpio o anotando la nueva hora de inicio. El mensaje normal debe mostrar 10 y la advertencia de esta condición debe desaparecer.

Estás comprobando un cambio. Modificar a la vez condición, nombre de variable y ubicación dificulta saber qué ayudó. Los cambios de objetos durante la prueba pueden restablecerse con Stop. Edita el proyecto original después de detenerlo y guarda la corrección confirmada.

5. Investiga un error de práctica seguro #

Sustituye el contenido por el segundo ejemplo y prueba otra vez. inventory vale nil deliberadamente; inventory.Coins no puede leer un campo de una tabla. Espera un error asociado a ese acceso. Su redacción exacta puede variar, pero la fuente debe llevar al ejemplo.

Detén la prueba y sustituye local inventory = nil por local inventory = {Coins = 10}. Al reiniciar, el acceso produce un número y Output debe mostrar 10. Esto corrige el dato usado por la operación. Quitar print() solo eliminaría el ejercicio sin explicar por qué era inválido el acceso anterior.

local inventory = nil
print(inventory.Coins)

6. Si no hay mensaje, revisa la ejecución #

Vuelve al primer ejemplo y coloca temporalmente print("OutputPractice started") al principio. Si tampoco aparece, verifica que hay una prueba activa, que el Script está habilitado y que contenedor y RunContext son adecuados. Después revisa filtros y contexto. Comprueba que el código alcanza el cálculo antes de investigar sus valores.

Para un LocalScript real, considera la ejecución del cliente y su contenedor. Una salida del servidor no confirma un manejador del cliente. Las marcas antes y después de una acción acotan el problema: solo la primera apunta al código intermedio; ninguna invita a revisar inicio o visibilidad.

7. Lee la fuente y conserva información útil #

Busca nombre del script y número de línea. Show Source muestra esa relación cuando existe; un enlace disponible lleva al código. Si hay una cadena de llamadas, revisa también quién llamó al fragmento. La línea es un punto de partida: el valor incorrecto puede proceder de antes.

Registra pasos, comportamiento esperado y real, texto del error, script y contexto Client o Server. Incluye un fragmento mínimo relevante al pedir ayuda. Elimina credenciales y datos de jugadores antes de compartir. Evita imprimir cada fotograma: el flujo continuo dificulta encontrar la primera señal útil.

8. Comprueba también el comportamiento #

Repite los pasos originales. Verifica que ocurrió la acción esperada y que no reapareció el error relacionado. En el primer ejemplo significa 10 sin advertencia de la comparación; en un botón significa su acción prevista. Un Output vacío no demuestra por sí solo que un botón esté arreglado.

Prueba después un caso cercano, como repetir la acción u otra entrada válida. Retira mensajes temporales excesivos y conserva el diagnóstico útil. Si persiste el problema, registra la nueva observación e investiga una causa otra vez. Este ciclo mantiene comprensible cada paso y una versión comprobada a la que volver.