Registros de administración de DayZ: qué registra el archivo vanilla `.ADM` y qué no puede demostrar

Un archivo .ADM puede resolver rápidamente algunas preguntas de DayZ: quién se conectó, qué dice una línea de daño, si se registró una acción de construcción configurada o en qué posición colocó a alguien una instantánea de jugadores de cinco minutos. No puede convertir un servidor en una repetición. La lectura útil empieza por identificar el archivo, comprobar los requisitos de lanzamiento y configuración, y tratar cada línea como un evento acotado, no como el relato completo de las acciones de un superviviente.

Antes de interpretar un extracto, confirma a qué flujo vanilla pertenece, qué categorías opcionales estaban activadas y qué parte del archivo compartió el administrador. Esos detalles determinan qué pueden demostrar las líneas y qué no puede demostrar un intervalo vacío.

Qué cuenta como archivo .ADM vanilla y dónde se encuentra

Antes de tratar una línea compartida como evidencia, identifica el archivo que hay detrás. El .ADM vanilla es el flujo de administración del servidor de DayZ: la salida del sistema de registros integrado del juego para los eventos que vanilla expone. No es un registro general de todo lo que ocurre en el servidor, y el registro adicional de un mod del servidor no forma parte automáticamente del formato vanilla.

A hosted log viewer showing the executable-named .ADM file and AdminLog entries.

El requisito global es el parámetro de lanzamiento -adminlog. El servidor debe iniciarse con ese parámetro para activar los registros de administración vanilla; tener un archivo de configuración o abrir un panel de alojamiento no sustituye ese requisito. El parámetro separado -config elige qué archivo de configuración lee el servidor, así que ese archivo no tiene que llamarse literalmente serverDZ.cfg. Su nombre y el nombre del archivo .ADM son asuntos distintos.

En un servidor dedicado, la regla de nombres es sencilla: toma el nombre del ejecutable del servidor y añade .ADM. En forma general, el archivo es server_exe_name.ADM y se crea en la carpeta de perfiles seleccionada por -profiles. DayZServer_x64.ADM es un ejemplo histórico útil de esa regla, no un nombre que debas asumir en todos los proveedores actuales. Si administras un servidor de PC, empieza por la ruta exacta de -profiles en el comando de lanzamiento en lugar de buscar al azar dentro de la instalación.

Los servidores alojados pueden ocultar esa estructura de archivos. Un proveedor puede mostrar el archivo mediante un visor o explorador, ofrecer una descarga, rotar la copia visible o hacer que un archivo recién escrito esté disponible solo después de un reinicio. Las etiquetas y rutas del panel cambian según el proveedor, así que una descarga que no muestre visiblemente la carpeta -profiles no tiene por qué ser el archivo equivocado. Pregunta al administrador qué registro exportó, qué intervalo temporal cubre y si el panel se había reiniciado o actualizado antes de compartirlo.

Mantén separados los nombres de los registros vecinos cuando alguien te entregue varios archivos:

Esa separación da una primera comprobación concreta. Supón que el propietario de un servidor de PC inicia el ejecutable con -adminlog y dirige -profiles a una carpeta de perfiles dedicada: el artefacto vanilla esperado es un archivo .ADM cuyo nombre deriva del ejecutable en esa carpeta. Un propietario con servidor alojado podría enviarte una descarga desde la vista de registros del proveedor. En cambio, un adjunto .RPT, server_console.log o una consola puede servir para otra investigación, pero no responde a la misma pregunta. Cuando confirmes la identidad, el origen y el intervalo temporal cubierto por el archivo, pasa a comprobar qué ajustes del servidor determinaron lo que podía entrar en él.

Qué ajustes determinan lo que puede ver el archivo

Una vez identificado el archivo, relaciona la pregunta con el control opcional que podría haber producido la línea relevante. Estos controles son independientes: un servidor puede registrar impactos de jugadores sin registrar colocaciones, o tomar instantáneas de jugadores cada cinco minutos sin registrar acciones de construcción de bases.

La referencia pública actual muestra los cuatro valores adminLog* como 0. Lee esos valores como ejemplo o línea base de la referencia, no como el estado real de todos los servidores de la comunidad. Un ajuste del proveedor, las modificaciones del propietario o las opciones guardadas en un panel pueden ser distintos. Si un administrador comparte un extracto .ADM, hay que confirmar por separado el ajuste relevante antes de dar significado a la presencia o ausencia de una línea opcional.

Los cuatro controles adminLog*

adminLogPlayerHitsOnly cambia el alcance de las líneas de impacto, no activa ni desactiva las demás clases de eventos. Con adminLogPlayerHitsOnly=1, el registro de impactos se limita a los impactos de jugadores. Con adminLogPlayerHitsOnly=0, incluye todos los impactos, incluidos los causados por animales e infectados. Esto importa si el informe trata de un lobo o un infectado: no se espera que un archivo configurado para registrar solo impactos de jugadores contenga esas líneas documentadas de impactos de animales o infectados.

adminLogPlacement=1 activa acciones de colocación como colocar trampas y tiendas de campaña. Relaciónalo con la pregunta de colocación. No significa que el archivo sea un inventario ni que aparezca cada objeto movido por un contenedor. Con el ajuste en 0, quien busque una línea sobre una trampa o tienda no debe asumir que un intervalo vacío demuestra que nunca ocurrió.

adminLogBuildActions=1 activa acciones de construcción de bases como construir, desmontar y destruir. Es el ajuste que debes consultar cuando una disputa trata de una valla u otra acción de construcción registrada. No convierte automáticamente el archivo en un registro de cada paso de un asalto, interacción con cerraduras, daño o cambio de inventario; esas son preguntas distintas de si la acción de construcción estaba habilitada para el registro.

adminLogPlayerList=1 activa una lista periódica de jugadores con la posición de cada uno. La instantánea se emite cada cinco minutos. Ofrece puntos de control de posición útiles para el propietario o el investigador, pero no una ruta actualizada continuamente: dos instantáneas muestran dónde estaba el jugador en esos momentos, no cada movimiento entre ellos. Si el ajuste está en 0, es normal que falte el bloque PlayerList aunque otras categorías del registro de administración estén activas.

Relaciona la pregunta con el ajuste

Por ejemplo, si compruebas una supuesta brecha en una base y el extracto no contiene ninguna línea built, dismantled o destroy, pregunta primero si adminLogBuildActions estaba en 1 durante el periodo relevante. Si compruebas la colocación de una trampa, pregunta por adminLogPlacement; un ajuste no sustituye al otro. Para una pregunta de ubicación, usa adminLogPlayerList para identificar puntos de control de cinco minutos y no conviertas los huecos entre ellos en una historia de movimiento continuo.

Los cambios en servidores alojados dependen del flujo del proveedor

En un servidor dedicado, el propietario edita la configuración que usa el comando de lanzamiento. En un servidor alojado, las mismas opciones pueden aparecer como casillas con etiquetas distintas, o estar ocultas tras las páginas de ajustes y registros del proveedor. El procedimiento operativo seguro es seleccionar las opciones necesarias, guardarlas y reiniciar el servidor si el proveedor exige un reinicio para aplicar los cambios. El proveedor puede mostrar el resultado mediante un visor o una descarga en lugar del archivo de configuración subyacente, y la ruta de su explorador de archivos es específica del proveedor.

El propietario activa las categorías necesarias mediante el proceso documentado de guardado y reinicio del proveedor, e informa de qué ajustes estaban activos y qué intervalo cubre el archivo. El jugador puede entonces clasificar las líneas visibles frente a las familias de eventos documentadas, sin asumir que se registró cada categoría opcional.

Qué registra el flujo de eventos vanilla documentado

La referencia pública actual corrobora los cuatro controles adminLog*, mientras que la tabla oficial de eventos de Administration Logs es explícitamente una referencia del parche 1.02. Las familias siguientes son el vocabulario vanilla documentado, no una garantía exhaustiva de cada evento interno de la versión 1.29. Agrúpalas por el tipo de evidencia que aportan: identidad y presencia, comunicación, combate y salud, acciones del mundo y puntos de posición periódicos.

Identidad y presencia

Los eventos básicos de presencia son las conexiones y desconexiones de jugadores. Estas líneas registran que un jugador entra o sale de la sesión del servidor, y dan al administrador un evento del servidor para el inicio o final de esa conexión. Pertenecen al flujo integrado, no al esquema ampliado de un mod de registros del servidor.

Comunicación e informes

El ADM vanilla también documenta líneas del chat de jugadores. Los ejemplos incluyen el nombre y el ID del jugador junto con el mensaje, lo que permite identificar qué se envió por el canal de chat registrado y cuándo apareció en el flujo.

Los informes enviados mediante el chat #toadmin del juego forman una familia de comunicación documentada aparte. En una investigación, un informe enviado por la vía de informes para administradores del juego no equivale a un mensaje privado de Discord, un ticket en la web de una comunidad ni un resumen posterior de un moderador. La línea de ADM representa el evento del informe que llegó al sistema de registro integrado del servidor.

Eventos de combate y salud

La parte de combate del flujo documentado contiene más información que una simple marca de «el jugador recibió un impacto». Una línea de daño puede incluir:

Los ejemplos cubren causas distintas del fuego entre jugadores: otro superviviente, una fuente animal o parecida a un infectado como un lobo, daño por caída y fuego de una chimenea aparecen en el conjunto de eventos documentado. El filtro adminLogPlayerHitsOnly cambia qué líneas de impacto pueden aparecer. Con adminLogPlayerHitsOnly=1, el flujo de impactos se limita a los jugadores; con adminLogPlayerHitsOnly=0, también incluye impactos de animales e infectados. Ese ajuste cambia la cobertura de impactos, no el significado de las demás familias de eventos.

El mismo grupo de combate y salud incluye las transiciones de consciencia. Los eventos documentados registran que un jugador queda inconsciente y que después recupera la consciencia. Esto puede demostrar que esas transiciones de estado se registraron, mientras que las familias de daño o muerte aportan otros tipos de información.

Las líneas de muerte tienen varias formas documentadas. Una muerte causada por otro jugador u otra fuente puede identificar la fuente, el arma y la distancia cuando esos detalles están disponibles. La tabla de eventos también incluye un estado de muerte genérico, suicidio y muerte por desangrado. Algunas entradas genéricas de muerte contienen información de estado como agua, energía o la fuente del sangrado. Por tanto, una línea de muerte identifica un evento de muerte y los detalles de esa forma concreta; no reconstruye por completo cada acción o herida que llevó a la muerte.

Eventos de acciones del mundo

Las líneas de colocación y construcción de bases son añadidos opcionales al flujo principal, así que su ausencia o presencia debe relacionarse con el control de configuración correspondiente.

Con adminLogPlacement=1, la familia de colocación documentada puede registrar acciones como colocar una trampa para osos, una chimenea o una tienda de campaña. Son eventos de acciones del mundo: muestran la acción de colocación registrada, no una contabilidad universal de cada objeto que un jugador llevó, movió, soltó o transfirió.

Con adminLogBuildActions=1, la familia de acciones de construcción puede registrar acciones como construir o desmontar una valla. El comentario de configuración también menciona destruir como acción de construcción de base compatible. La evidencia útil es, por tanto, el actor registrado y la acción de construcción representada por esa línea; no debe ampliarse hasta prometer que cada interacción con una cerradura, paso de un asalto, evento de daño o cambio de inventario tendrá la misma entrada.

Bloques periódicos de posición de jugadores

adminLogPlayerList=1 añade una forma distinta de evidencia: una impresión periódica de la lista de jugadores con el número de jugadores y la posición actual de cada uno. El intervalo documentado es de cinco minutos. Así, el archivo contiene puntos de control de posición junto a sus líneas de eventos, pero no se convierte en un registro de movimiento actualizado continuamente.

La diferencia entre estas familias es práctica. Una línea de conexión trata de un evento de sesión; una línea de #toadmin trata de un informe enviado; una línea de daño o muerte trata de combate o salud; una línea de colocación o construcción depende de su ajuste de acciones del mundo; y un bloque PlayerList depende del ajuste de instantáneas de cinco minutos. Clasificar la línea por familia mantiene la afirmación proporcional a lo que el servidor dice haber registrado.

Clasifica una línea visible por familia y anota solo el evento y los campos que realmente contiene; después usa el orden de lectura siguiente para construir una cronología acotada.

Cómo leer un extracto .ADM compartido sin sobreinterpretarlo

La forma más segura de leer un extracto es convertirlo en una cronología acotada, línea por línea. Empieza siempre con los mismos anclajes: la marca temporal HH:MM:SS, el verbo del evento, el nombre del jugador y el id= repetido, el valor pos=<x,y,z> y los campos propios de ese evento. Después compara la línea con sus vecinas y con cualquier instantánea cercana de la lista de jugadores de cinco minutos. Así sabrás qué registró el servidor en un momento concreto sin convertir una entrada en una historia completa.

Usa el mismo orden de lectura para cada línea

1. Marca temporal: Anota primero el valor HH:MM:SS. Coloca el evento en la secuencia de hora del servidor que estás examinando. Una marca temporal ordena las líneas recibidas; por sí sola no indica cuánto del registro circundante se omitió.
2. Verbo del evento: Identifica qué ocurrió en la línea —por ejemplo, una conexión, impacto, muerte, colocación, acción de construcción o impresión PlayerList—. El verbo determina qué campos son pertinentes y evita que leas un campo de combate dentro de un evento de construcción.
3. Jugador e ID: Anota el nombre mostrado y el valor id=. Cuando vuelve a aparecer el mismo ID, ayuda a correlacionar esa línea con la misma identidad registrada en otra parte del extracto, aunque cambie el nombre o haya jugadores con nombres parecidos. La referencia disponible no establece una conversión de identidad específica de plataforma desde ese valor hasta un DAYZGUID, y un ID repetido por sí solo no demuestra la identidad de una cuenta fuera del contexto del registro.
4. Posición: Captura pos=<x,y,z> cuando aparezca. Trátala como la posición asociada al evento o instantánea registrada. Puedes pegar las coordenadas en una herramienta de mapa compatible como ayuda práctica, siempre que elijas el mapa correcto; no deduzcas una URL, convención de ejes o ruta a partir de la coordenada por sí sola.
5. Campos propios del evento: Anota solo la carga útil que corresponde a ese evento. Un impacto puede incluir salud, zona de impacto, componente, daño, munición, arma, fuente y distancia. Una línea de construcción puede identificar la acción y al actor. Una lista de jugadores aporta un grupo de jugadores y posiciones. «No aparece» es distinto de «cero» y de «no corresponde».
6. Contexto cercano: Lee las líneas anterior y siguiente antes de sacar una conclusión. Una conexión, impacto, cambio de consciencia, muerte, colocación o construcción puede cambiar cómo interpretas el evento siguiente. Un bloque cercano de PlayerList puede aportar un punto de control, pero no puede rellenar cada instante entre puntos de control.

Este orden mantiene útiles los ID repetidos sin hacerles soportar más peso del que permite la evidencia. Estás correlacionando cadenas dentro del archivo compartido, no haciendo una consulta de titularidad de cuenta. Si el administrador necesita vincular un ID registrado con un jugador fuera de ese extracto, pide el contexto de identidad del servidor en lugar de tratar el formato del ID como una prueba autosuficiente.

Ejemplo: recorre una línea de impacto PvP campo por campo

Supón que un extracto contiene una entrada de impacto a las 18:42:11 con el nombre de la víctima, un id= repetido, una posición pos=<x,y,z>, los PS actuales, un atacante u otra fuente de daño, una zona de impacto y un componente, un valor de daño, datos de munición y arma, y una distancia del impacto a distancia. Léela en este orden:

• 18:42:11 coloca el impacto en la secuencia local que estás examinando.
• El nombre y el ID de la víctima identifican al objetivo registrado; compara ese ID con otras líneas antes de considerar que las entradas posteriores pertenecen a la misma identidad registrada.
• pos=<x,y,z> sitúa el evento tal como se registró. Es un punto asociado al impacto, no una ruta que muestre cómo llegó cualquiera de los dos jugadores.
• Los PS actuales, la zona de impacto, el componente y el daño describen el efecto registrado. Mantén separado el número de daño de la pregunta posterior de si la víctima murió.
• El atacante o la fuente, la munición, el arma y la distancia describen los detalles de origen que suministra esa línea concreta. Si falta un campo, no lo completes con una suposición ni con la entrada de otro jugador.

Esa lectura permite una afirmación precisa: el extracto registra un impacto que involucra a los jugadores o la fuente nombrados, en la hora y posición registradas, con los detalles de daño enumerados. Por sí sola no reconstruye todo el tiroteo, no demuestra cada disparo anterior ni decide las reglas del servidor. Para una decisión sobre reglas o tickets, usa los requisitos del propio servidor y las evidencias que acepta; el trabajo de esta sección es mantener proporcional la interpretación del ADM a lo que dice la línea.

Contrasta una acción de construcción con un punto de control de posición

Una disputa de construcción de base tiene otra forma de línea. Si el extracto contiene built, dismantled o destroy, lee el actor registrado, el ID repetido, la marca temporal, la posición y la acción nombrada. Eso es evidencia útil de la acción de construcción registrada solo cuando adminLogBuildActions=1 estaba activo durante el periodo relevante. No demuestra quién era el propietario de la base, si la acción estaba permitida ni qué otra actividad de asalto ocurrió. Una entrada de trampa, tienda o chimenea sigue la misma disciplina de campos, pero pertenece al registro de colocaciones y depende de adminLogPlacement=1; no debe leerse como un inventario.

Ahora compárala con un bloque PlayerList. Cuando adminLogPlayerList=1 está activo, el archivo imprime una lista de jugadores con posiciones cada cinco minutos. Trata cada bloque como un punto de control: anota la hora, los jugadores listados y cada posición, y compáralo con los impactos, muertes, colocaciones o construcciones cercanos. Si un punto de control muestra a un jugador en una posición y el siguiente lo muestra en otra, el extracto respalda esos dos puntos observados, no la ruta continua, las paradas, la presencia o las acciones entre ellos.

El resultado práctico es una secuencia anotada con límites claros: hora, evento, identidad registrada, posición y los campos que aporta realmente ese evento. Cuando respondas al administrador, pregunta qué ajuste estaba activo, qué intervalo cubre el archivo y qué línea concreta respalda la afirmación. Así obtendrás una cronología defendible sin pedirle a un extracto .ADM compartido que demuestre más de lo que registra.

Cuando el archivo guarda silencio, pregunta qué no podía registrar

Un intervalo vacío necesita una comprobación de cobertura antes de convertirse en evidencia. La ausencia de una línea puede reflejar el intervalo temporal del archivo, una puerta de registro desactivada, una exportación o retención parcial, o una acción fuera de las categorías que promete la referencia vanilla.

Una lista de archivos alojada ilustra por qué el registro exportado y su periodo de retención necesitan contexto.

Lo que vanilla ADM no promete

El flujo vanilla documentado tampoco promete un registro completo de estas categorías:

Estos son límites de la evidencia, no una afirmación de que ninguna función posterior o configuración del servidor pueda añadir esos registros. Una línea de colocación puede demostrar que se registró la colocación de una trampa, tienda o chimenea cuando el registro de colocaciones estaba activo; no convierte el archivo en una contabilidad del recorrido previo del objeto por el inventario. Una línea de construcción puede demostrar la acción registrada de construir, desmontar o destruir cuando el registro de acciones de construcción estaba activo; no demuestra cada paso del asalto, interacción con una cerradura, evento de daño o afirmación de propiedad.

Cuándo otro registro es la evidencia correcta

Los mods del servidor pueden ampliar los registros, pero su salida es otro flujo de evidencia. Un mod como MoreAdminLogs puede escribir sus propios archivos .log o .ljson y añadir categorías de movimiento, posiciones más frecuentes, vehículos, equipo, objetos en las manos, artesanía, objetos y acciones ampliadas. Esos archivos tienen sus propios nombres, claves de configuración y esquema; no deben leerse línea por línea como si fueran el archivo .ADM cuyo nombre deriva del ejecutable vanilla.

Si el servidor usa mods, pregunta qué mod produjo el archivo adicional, solicita ese archivo para el periodo relevante y pide el esquema o la configuración del mod. Una entrada de movimiento o inventario de un mod puede responder una pregunta que ADM vanilla no puede responder, pero solo dentro de la versión, los ajustes y la ventana de retención de ese mod. No uses la presencia de un archivo llamado «admin» para ampliar silenciosamente el contrato vanilla.

Los problemas técnicos deben dirigirse a otros registros. Usa el RPT del servidor para fallos de inicio, carga de mods, comprobaciones de firmas y cierres graves; usa los registros de scripts para errores de Enforce Script y muchos fallos del lado del mod; usa el registro del cliente para un problema que ocurra en la máquina del jugador. Un extracto ADM puede mostrar eventos de jugabilidad alrededor de un fallo, pero no es el registro de diagnóstico adecuado para explicar por qué el servidor no inició, rechazó una firma, produjo un error de script o generó un fallo del cliente.

La tarjeta de diagnóstico de una línea ausente

Supón que un administrador comparte un extracto ADM de una disputa de base y no hay ninguna línea built, dismantled o destroy. Antes de tratar esa ausencia como prueba de que la acción no ocurrió, comprueba estas cuatro condiciones:

1. Puerta global: Confirma que el servidor se inició con -adminlog durante el periodo relevante. El archivo de configuración por sí solo no demuestra que el flujo vanilla estuviera activo.
2. Filtro relevante: Confirma que adminLogBuildActions=1 estaba activo mientras pudo ocurrir la acción. Otro ajuste adminLog*, como el de colocaciones o la lista de jugadores, no lo sustituye.
3. Cobertura temporal: Compara la hora de la supuesta acción con la primera y la última entrada del archivo entregado. Comprueba si hubo un reinicio, una rotación o un extracto que empezara después del evento discutido.
4. Exportación y retención: Pregunta si la copia procede directamente de la carpeta -profiles o de un visor/descarga del proveedor, y si el proveedor actualizó, truncó, rotó o conservó solo un periodo limitado del archivo.

Si falla alguna comprobación, la conclusión correcta es únicamente que esa copia no puede responder a la pregunta sobre construcción de bases. Si las cuatro pasan y no aparece ninguna línea coincidente, el extracto es una evidencia más fuerte de lo que registró el flujo vanilla configurado, pero aun así debe expresarse como «no aparece ninguna línea coincidente en el archivo cubierto», no como una reconstrucción absoluta de lo que ocurrió fuera de ese flujo.

Aplica la misma disciplina a otras ausencias: verifica adminLogPlacement antes de interpretar la falta de una línea de trampa o tienda, verifica adminLogPlayerList antes de dar significado a la falta de bloques de posición y verifica el filtro de impactos antes de sacar conclusiones de la ausencia de daño de animales o infectados. Después solicita el flujo de evidencia que corresponda a la pregunta pendiente: el ADM original o exportado correctamente para eventos vanilla, el archivo y esquema propios del mod para categorías añadidas por mods, o los registros RPT, de scripts o del cliente para fallos técnicos.

Antes de presentar una acusación o exoneración, envía al administrador una solicitud precisa del estado de -adminlog, del valor de adminLog* relevante, de las marcas temporales que cubre el archivo y de su contexto de exportación o retención. Si la pregunta trata de un mod, solicita su registro con esquema separado; si trata de un cierre, rechazo de firma, fallo de inicio o error de script, solicita la evidencia RPT, de scripts o del cliente correspondiente antes de decidir qué demuestra el registro.