# Full Dominoes — Pack 04 Cinco arreglos. Cuatro los pude confirmar en el código; el quinto (el segundo giro de la cadena) no lo consigo reproducir y necesito una captura — lo explico al final. --- ## 1. Archivos | Archivo | Destino | Tipo | |---|---|---| | `public/home.html` | `public/` | **reemplaza** | | `public/assets/js/btn-lobby-pack.js` | `public/assets/js/` | **reemplaza** (v2) | | `public/assets/js/fd-experiencia.js` | `public/assets/js/` | **reemplaza** (v3) | | `public/assets/js/fd-profundidad.js` | `public/assets/js/` | **reemplaza** | | `public/assets/css/fd-experiencia.css` | `public/assets/css/` | **reemplaza** | --- ## 2. El botón de Ayuda — era un carácter Línea 540 de tu `home.html`: ```html ↑ ``` Esa barra invertida antes de la comilla. Alpine recibe la expresión `mostrarAyuda()\`, que no es JavaScript válido, así que la evaluación falla y el handler nunca corre. El botón se dibuja perfecto y no hace nada — el peor tipo de bug, porque no deja rastro visible. Corregido en el `home.html` que va en el pack. Vale la pena buscar `()\"` en el resto de los HTML por si se coló en más lugares. --- ## 3. Las ondas no salían Las ondas dependían de que `fd-experiencia.css` estuviera enlazado en esa pantalla **y** de que el WebView no estuviera sirviendo una versión vieja cacheada. Si faltaba cualquiera de las dos, los elementos de la onda se creaban igual pero sin ninguna regla que los pintara: invisibles. Desde afuera se ve exactamente como "el click no hace nada", y no hay forma de diagnosticarlo mirando la pantalla. Ahora `fd-experiencia.js` **inyecta su propio CSS** al arrancar. Las ondas funcionan aunque no cargues el `.css`, aunque esté cacheado y sin importar el orden de los ` ``` **b)** Y aunque no lo cambiaras, ahora **entra igual**. Si el tag ya está definido, el pack no intenta redefinirlo: busca las instancias que ya están en la página y les reescribe el shadow root con el estilo nuevo. Como todo el estilo vive dentro del shadow root, eso alcanza. Un `MutationObserver` cubre las que Alpine monte después (`x-if`, `x-for`). O sea: funcione o no la edición del HTML, los botones se ven bien. Lo verifiqué simulando el caso feo — tag predefinido por el archivo viejo + instancia ya en el DOM → repintada correctamente. --- ## 5. Desfase y duplicidad de la imagen Era mío, del pack 02. El paralaje movía `background-position` del ``: ```css body.fd-con-paralaje.fd-vivo { background-position: calc(50% + var(--fd-par-x) * 0.20) ...; } ``` Varias pantallas apilan **dos** capas de fondo (un degradado encima de la imagen). `background-position` con un solo valor mueve las dos por igual, así que el degradado se desalineaba de la foto y el borde donde terminaba se leía como un corte o como una segunda copia del fondo. Al recargar era peor, porque el valor arranca en 0 y salta de golpe a la primera lectura del giroscopio. Dos cambios: - **La foto ya no se mueve.** Se quitó esa regla. La profundidad sigue saliendo igual de bien de las otras tres capas — y un horizonte real tampoco se mueve, así que además es más correcto. - **El paralaje queda desactivado en la mesa de juego.** Ahí el canvas 3D proyecta con su propia cámara y las zonas de "soltar aquí" se posicionan con esa misma matriz; cualquier desplazamiento CSS extra mete un desfase entre lo que se ve y donde se puede soltar la ficha. --- ## 6. La caja de regalo El halo amarillo no era una sombra: era luz saliendo de un objeto que no emite luz. Por eso se leía como sticker pegado. ```css /* antes */ filter: drop-shadow(0 8px 14px rgba(0,0,0,.45)) drop-shadow(0 0 8px rgba(251,191,36,.35)); /* ← el halo */ /* ahora: tres capas, todas hacia ABAJO */ filter: drop-shadow(0 2px 3px rgba(0,0,0,.55)) /* contacto */ drop-shadow(0 8px 12px rgba(0,0,0,.42)) /* volumen */ drop-shadow(0 18px 26px rgba(0,0,0,.32)); /* ambiental */ ``` Una sombra real tiene contacto (corta y oscura, dice "esto está apoyado"), volumen y ambiental (larga y difusa, da la altura). Ninguna va alrededor. Si querés brillo dorado, tiene que venir del material de la caja, no de un aura. --- ## 7. El segundo giro — necesito verlo Este no lo pude reproducir, y prefiero decírtelo antes que mandarte otra suposición. Simulé una mano completa de 28 fichas y verifiqué **hueco entre cada ficha y la anterior**, siguiendo las dos cadenas por separado: ``` == cadena DERECHA == ok #9(257,0 54x27) -> #11(270,41 27x54) hueco=0.0 == cadena IZQUIERDA == ok #10(-257,0 54x27) -> #12(-270,-41 27x54) hueco=0.0 ``` Todas las fichas se tocan, los giros forman la L correcta y no hay ni un solapamiento. El problema: con 28 fichas y el límite actual de 300px, cada lado alcanza a girar **una sola vez** (entran ~11 fichas por renglón). O sea que en mi simulación el "segundo giro" no llega a ocurrir, y por eso no lo veo. Dos posibilidades y no puedo elegir entre ellas desde acá: 1. **No aplicaste el `sala.js` del pack 02.** Ese archivo es donde vive la corrección del giro. El pack 03 solo traía `tablero3d.js`. Si el `sala.js` sigue siendo el original, el primer giro también estaría mal — pero decís que el primero cruza bien, así que esto parece descartado. 2. **El límite de renglón real es más chico que el que asumo**, y en tu pantalla entran menos fichas por fila, así que sí llegás a un segundo giro que yo no alcanzo. En ese caso el defecto estaría en el encadenamiento de dos codos seguidos y necesito ver dónde queda cada pieza. **Lo que me destraba:** una captura de la mesa con el segundo giro a la vista. Con eso lo ubico igual que ubiqué el rectángulo oscuro. Si además me decís cuántas fichas había puestas, mejor todavía.