Ajustes false en Luau: por qué un valor predeterminado volvió a activar la música

Define qué significa cada valor #

Imagina un juego ficticio de paseos por una isla con una preferencia de música ambiental. Un jugador desactiva la música, por lo que los datos del ejercicio contienen false. Un jugador nuevo todavía no ha elegido: su entrada es nil. El autor quiere activar la música por defecto únicamente en el segundo caso. Este acuerdo distingue una decisión deliberada de la ausencia de información antes de que una expresión mezcle ambas situaciones.

El ejercicio no afirma que este ajuste ya exista en nuestros juegos. Empezamos con una función Luau y valores normales. No hay Sound, solicitudes DataStore, botones ni eventos de red conectados. Esas integraciones necesitan su propia implementación y pruebas posteriores en Studio. Anota primero el acuerdo: true significa activado, false desactivado y nil que no se ha proporcionado un valor.

Reproduce el error con or #

La expresión savedMusic or true parece una forma cómoda de elegir un valor predeterminado. Sin embargo, or no comprueba exclusivamente que falte información. La referencia oficial explica que devuelve el primer operando cuando se considera verdadero y el segundo en caso contrario. Con savedMusic=false devuelve true. Una preferencia expresamente desactivada acaba activándose durante la interpretación.

Ejecuta un ejemplo corto con false e imprime el resultado. Repítelo con true y nil. True se conserva; false y nil seleccionan el valor alternativo. Este es el comportamiento del lenguaje, no una prueba de que la carga haya fallado. No reescribas el registro antes de revisar la expresión: una entrada correctamente recibida puede convertirse en un estado incorrecto después de leerla.

Abrir imagen a tamaño completo ↗

local savedMusic = false
print(savedMusic or true)
print(0 or 9)
print(true and false or true)

No interpretes cero o texto vacío como desactivación #

En Luau, false y nil se consideran falsos, mientras que 0 y una cadena vacía se consideran verdaderos. Por eso 0 or 9 devuelve cero, y una cadena vacía combinada con un texto alternativo mediante or sigue vacía. Una etiqueta sin texto no necesariamente recibirá el mensaje esperado usando esta expresión. Comprueba qué valor llegó antes de atribuir el problema a la visualización.

Para nuestra preferencia, cero tampoco es una desactivación válida. El acuerdo admite booleanos, no cualquier valor con un comportamiento de verdad determinado. La cadena "false" no equivale al booleano false. Incluye esos valores como entradas incorrectas. Pasar una condición if no demuestra que el tipo sea válido ni que el dato represente una elección confirmada del jugador.

Sustituye únicamente nil con una comprobación explícita #

La función booleanPreference comprueba primero raw==nil. Solo esa rama utiliza el defaultValue acordado. Si existe un valor, comprueba por separado type(raw)=="boolean". Los valores reales true y false pasan sin cambiar. Un número o una cadena produce rechazo, no una sustitución silenciosa. Así distinguimos ausencia de datos, preferencia desactivada y entrada incorrecta.

En este ejercicio, defaultValue también debe ser booleano. Una assertion señala un error de programación al llamar a la función; no constituye una política completa para manejar cualquier entrada de una interfaz real. Decide de dónde sale el valor predeterminado permitido y qué hace la aplicación tras un rechazo. Un texto no revisado del jugador no debería convertirse inesperadamente en la preferencia por defecto.

local function booleanPreference(raw, defaultValue)
    assert(type(defaultValue) == "boolean")
    if raw == nil then
        return defaultValue, true
    end
    if type(raw) ~= "boolean" then
        return nil, false
    end
    return raw, true
end
local value, valid = booleanPreference(false, true)
print(value, valid)
value, valid = booleanPreference(nil, false)
print(value, valid)
value, valid = booleanPreference("false", true)
print(value, valid)

Separa el valor de la validación correcta #

La función devuelve dos resultados: la preferencia y valid. Una elección desactivada correcta es false,true. Un rechazo es nil,false. Si quien llama comprueba únicamente el primer resultado, puede enviar una desactivación válida a la misma rama que un error. Comprueba valid primero y aplica value después. Saber si la operación fue válida y saber qué preferencia produjo son preguntas diferentes.

Un futuro controlador del botón podría recibir false,true y mostrar el estado desactivado. Nil,false necesita una ruta de error prevista, no una activación automática del sonido. El artículo no decide toda la política de tu producto. Conservar el último estado confirmado y comunicar el problema puede encajar en tu diseño. Lo esencial es no presentar el rechazo como una nueva elección del jugador.

Abrir imagen a tamaño completo ↗

Revisa el atajo and/or #

La expresión condition and selectedValue or fallback se usa a veces como una selección abreviada. No conserva todos los resultados permitidos. Si condition=true y selectedValue=false, el resultado intermedio es false y or elige fallback. En nuestro caso, true and false or true vuelve a producir true. Una condición verdadera no protege un resultado falso en esta construcción.

Utiliza una rama explícita si el valor elegido puede ser false o nil. La brevedad no demuestra corrección. Mantén una prueba con condición verdadera y resultado elegido falso: los ejemplos que usan únicamente true no detectarían el fallo. El artículo sobre umbrales selecciona la primera rama numérica adecuada; este ejercicio distinto conserva un resultado que el lenguaje considera falso.

Ejecuta una matriz de entradas #

Comprueba los casos correctos por separado. False con valor predeterminado true debe producir false,true. True con valor predeterminado false debe producir true,true. Nil con valor predeterminado true produce true,true. Añade nil con valor predeterminado false como caso inverso de ausencia de datos. Escribe las expectativas antes de ejecutar para no aceptar una activación accidental como nuevo resultado deseado.

Después pasa cero, una cadena vacía, el texto "false" y el número uno. Según nuestro acuerdo, todos deben producir nil,false. Comprueba ambos resultados, no solamente que no haya un fallo de ejecución. El conjunto original de assertions se ejecutó realmente en un intérprete Luau independiente. Verifica estas operaciones con datos; no verifica música audible, pulsaciones del menú ni preferencias guardadas dentro de Roblox.

Integra el menú en una fase separada #

Una vez comprobada la función, describe la procedencia del dato, cuándo termina la lectura y qué estado confirmado recibe el menú. Reabrir el panel debe conservar una preferencia desactivada. Cuando falta el dato, utiliza el valor acordado en el escenario previsto. Dibujar la interfaz otra vez no debería reinterpretar false como ausencia simplemente porque se repite la presentación del mismo panel.

No extiendas una prueba correcta con datos a una afirmación sobre DataStore o el servidor. Un fallo de carga, un registro inexistente y un tipo rechazado pueden requerir acciones diferentes. Las comprobaciones del servidor y el tratamiento fiable de errores siguen siendo tareas propias. No sobrescribas un registro con un valor alternativo porque el panel apareció antes de terminar la lectura. Define estos casos temporales antes de implementar persistencia.

Deja una entrega reproducible #

Anota los tipos permitidos, el significado de nil, los dos resultados y los casos de rechazo. Incluye los archivos originales y el resultado real de las comprobaciones. Esto ayuda más que decir que arreglaste la música: otro desarrollador podrá repetir la prueba sin acceder a una sesión de juego. Usa valores ficticios y deja fuera identificadores reales de jugadores y credenciales.

Si el acuerdo cambia, actualiza la función, las expectativas y la explicación juntos. Admitir un modo representado por texto exige una interpretación explícita y pruebas nuevas, no simplemente eliminar la comprobación de tipo. Mantén separadas la decisión del producto y las reglas del lenguaje. La referencia oficial establece cómo funcionan los operadores; tu proyecto decide qué preferencias tienen significado y están permitidas.

Comprueba el resultado antes de entregarlo #

El ejercicio funciona cuando false guardado sigue siendo false, nil recibe solo el valor acordado y los tipos incorrectos producen un rechazo separado. Comprueba los dos valores predeterminados posibles y llamadas repetidas. Confirma que el código que llama utiliza valid para decidir si puede aplicar el resultado. Busca atajos and/or donde un resultado válido pueda ser false.

Tras integrar, repite las comprobaciones en el panel real de Studio y prueba por separado guardar y volver a leer. Estos son pasos futuros, no observaciones de juego ya realizadas. El ejemplo original y su fuente explican la causa del error, pero no significan que un juego existente se haya modificado. Registra por separado el resultado confirmado de la función y el eventual resultado dentro del juego.