Paquetes de soporte
Un paquete de soporte es un ZIP único que empaqueta el estado del puente en el momento en que algo salió mal. Es el único artefacto que solicitaremos al clasificar un ticket. Esta página describe exactamente lo que hay en uno, para que sepas lo que estás enviando.
Cómo exportar uno
- Abra FFB-Bridge y navegue hasta la Soporte página (barra lateral), luego el Diagnóstico pestaña.
- Haga clic Paquete de soporte (arriba a la derecha de la tarjeta de Diagnóstico).
- Después de un breve retraso, un banner muestra el nombre del archivo y el tamaño, con un enlace al formulario de comentarios y, cuando esté disponible, Revelar archivo.
- Abra el formulario de comentarios y adjunte el ZIP si desea enviarlo.


¿Qué hay en el paquete?
Un paquete es un ZIP simple. Los nombres de archivos a continuación son la lista completa de permitidos: el paquete nunca contener cualquier cosa fuera de este conjunto.
sysinfo.txt
Metadatos del sistema. Texto sin formato, líneas clave:valor. Campos:
os-name— “Windows”, “Linux” o “macOS”.os-version— versión del kernel, cadena de compilación de Windows o versión de macOS.distro— en Linux, /etc/os-releasePRETTY_NAME.cpu-model,cpu-cores— de/proc/cpuinfooWin32_Processor.ram-total-mb— de/proc/meminfooWin32_ComputerSystem.dotnet-version— versión en tiempo de ejecución del .NET incluido.platform- clave explícita para la rama Linux-vs-Windows.locale— configuración regional del usuario actual.bridge-version,build-hash- versión puente y git SHA en el momento de la compilación.
sesión.log
Registro completo de eventos para la sesión actual. El mismo contenido que la tira de registro de la pestaña Diagnóstico, pero incluye todo desde el inicio, no solo lo que está visible. UTF-8.
último-crash.log
Si el lanzamiento anterior falló, el registro de fallos llega aquí. Seguimiento de pila, volcados de subprocesos, las últimas líneas de registro antes del fallo. Ausente si la sesión no ha fallado.
previous-session.log
El registro rotado de la ejecución anterior a la actual, cuando existe. Tras un informe de crash y reinicio, suele ser el archivo que muestra qué ocurrió antes del reinicio.
doctor.json
Los controles de estado más recientes se escanean desde la página de soporte en formato legible por máquina. Cada fila lleva el nombre de la verificación, el estado (aprobado / información / advertencia / falla / listo / verificando / n/a) y la cadena de detalles sin formato. Esto nos permite ver el estado de su control de salud sin que tenga que pegar capturas de pantalla. El archivo se llama
doctor.json Por razones históricas, la página de soporte solía llamarse Doctor.
tunables.json
Los valores del perfil de ajuste activo en el momento de la exportación. Mismo esquema que un perfil guardado. Se utiliza para reproducir la configuración de fuerza exacta que estabas volando.
hardware-settings.json
Ajustes de compatibilidad de hardware en el momento de exportación: mezcla por software, Smooth steady forces, polaridad de ejes, intercambio pitch/roll, preferencia raw-HID, opt-in de dispositivo no listado y si los interruptores en vivo diferían de los ajustes guardados.
simconnect.txt
MSFS SimConnect.xml si el bridge pudo leer uno, con las direcciones IP no locales redactadas. Si no se encontró ninguno, este archivo lo indica en vez de adivinar.
Platform extras
Windows bundles include hid-devices.txt para registros de dispositivos Plug and Play coincidentes. Los paquetes de Linux incluyen
usb.txt, evdev.txt, udev.txt, y dmesg.txt para contexto de la pila USB/entrada. Cada paquete también incluye README.txt con un resumen del contenido y una nota de privacidad.
Lo que NO está en el paquete
El creador del paquete de soporte utiliza una lista estricta de nombres de archivos permitidos. No incluirá nada fuera de esa lista, incluso si hay algo que coincida en el mismo directorio. En particular:
- No hay contraseñas ni credenciales guardadas. El puente no almacena nada.
- Sin archivos de perfil aparte de el activo.
- No hay registros del sistema, diarios ni nada fuera de los directorios de datos del puente.
- No hay capturas de paquetes de red.
- Sin tokens de nube (el puente no usa ninguno).
Procesamiento del lado del servidor
Cuando adjunta un paquete a un informe de comentarios, el trabajador de admisión del sitio lo analiza para extraer datos indexables útiles en nuestra base de datos:
- Información del sistema en una fila de resumen para agruparla (“¿cuántos informes hay de esta distribución?”).
- Líneas de advertencia y error del registro, con firmas de error estables, para que podamos ver de un vistazo cuántas personas tienen el mismo error.
- Resultados de la verificación de estado para obtener un desglose de lo que está fallando en la base de usuarios.
- El texto del archivo textual de cada entrada de la lista permitida, almacenado para que podamos volver a leer el contexto al realizar la clasificación.
El paquete sin procesar en sí se conserva durante un período breve (30 días de forma predeterminada) para que podamos volver a analizarlo si nuestra lógica de extracción mejora. Después de eso, se conservan los datos analizados; el blob sin procesar se descarta.
Límites
| Límite | Valor |
|---|---|
| Tamaño total del paquete | 50 MB comprimidos |
| Tamaño sin comprimir por entrada | 5 MB |
| Entradas máximas | 30 |
| Total sin comprimir | 20 megas |
| Codificación | Solo archivos de texto UTF-8 (más XML) |
En la práctica, un paquete normal tiene menos de un megabyte. Estos límites existen para descartar cargas hostiles, no para descartar informes reales.
Enviar sin el formulario de comentarios
Si prefiere enviar el paquete por correo electrónico directamente, escriba a
feedback·ffb-bridge.com (reemplace el · con una @) y adjunte el ZIP. El analizador del lado del servidor no se ejecuta para el correo electrónico, por lo que la clasificación es más lenta, pero el paquete es igual de utilizable.