KeldrinADMINISTRADOR DE SERVIDORES DEDICADOS

Versión preliminar para desarrolladores

Referencia de comandos

Seis comandos de solo lectura, con límites claros entre estructura, semántica, firmas, reproducción de Setup y aceptación real en el juego.

SDK, versión preliminar para desarrolladores

El SDK 0.9.140, con licencia MIT, es una herramienta de creación, no una certificación completa del juego. Descarga e inicio rápido · Requisitos.

Los seis comandos

Esta página describe los seis comandos. Empieza por el paquete verificado y la guía rápida; la salida del SDK no es una certificación del juego.

describe-contract y author-schema describen todo el vocabulario actual, incluidos SelectImportedSubdirectory, UnrealReadyLogMarker y las políticas de detención que tienen en cuenta el guardado.

Interfaz de comandos de la versión preliminar para desarrolladores del SDK 0.9.140
Comando y entradasQué compruebaQué no demuestra
describe-contract

Sin opciones.

Vocabulario seleccionado, límites y restricciones de proveedores.No es un esquema completo ni una autorización para activar un proveedor.
author-schema

Sin opciones.

JSON Schema estructural Draft 2020-12 generado a partir de los tipos reales del manifiesto y del serializador estricto.Descubrimiento para editores, no una validación semántica completa ni una certificación.
author-lint

--manifest obligatorio; --host-version y --evidence opcionales.

Análisis estricto de la carga útil sin firmar y comprobaciones semánticas compartidas del contrato del autor.Sin identidad de paquete verificada, compilación firmada ni plan de ejecución ejecutable.
canonical-payload

Solo --manifest, obligatorio.

Bytes validados de la carga útil compacta sin firmar.No firma. Los bytes nuevos requieren nuevas vinculaciones de evidencias y de resúmenes de fixtures.
verify-package

--archive obligatorio; --host-version y --evidence opcionales.

La firma con la clave oficial fija del archivo real, la compatibilidad con el anfitrión y la compilación firmada.No es una instalación, una admisión en el catálogo, una aceptación contra reversiones ni una prueba del juego.
test-contract

Exactamente uno entre --manifest o --archive; --fixtures obligatorio; --host-version opcional.

Casos sintéticos de Setup vinculados por resumen, usando las reglas compartidas reales de Setup. Una entrada de archivo firmado se verifica y se compila primero.No inicia un juego ni certifica la configuración real, los guardados, los jugadores ni ninguna fila de verificación completa.

Ninguno de estos comandos firma, instala, activa ni publica un adaptador, inicia un juego ni sigue las referencias de evidencias externas aportadas por un autor. test-contract evalúa sus casos declarativos y acotados de Setup; eso no es una ejecución del juego.

Lee los campos de garantía

  1. Descubrimiento estructural: author-schema exporta un esquema estructural Draft 2020-12. Es útil para un editor, pero no puede expresar todas las restricciones semánticas o de proveedor.
  2. Semántica sin firmar: author-lint y canonical-payload también usan comprobaciones compartidas independientes de la confianza. AuthorContractChecked puede ser true mientras SignatureVerified y CompilerChecked siguen siendo false. No se fabrica ningún paquete verificado ni plan de ejecución.
  3. Compilación firmada: verify-package autentica el archivo oficial real con la raíz de confianza pública fija y compila ese resultado verificado. No ofrece ninguna anulación arbitraria de la confianza y no admite un catálogo ni instala un perfil.
  4. Reproducción sintética de Setup: test-contract comprueba las expectativas con las reglas compartidas reales de Setup. La reproducción sin firmar no crea un contenedor verificado, un plan de ejecución compilado ni un perfil de servidor. Una entrada firmada se verifica y se compila primero.
  5. Aceptación del funcionamiento en el juego: unas evidencias independientes deben mostrar la configuración, el ciclo de vida, los guardados, la red, los clientes y la recuperación reales. AcceptanceVerifiedByTool y ReleaseCertified siguen siendo false; el SDK no es una herramienta de certificación de juegos.

Apunta al anfitrión previsto

Usa un --host-version explícito en los comandos que lo admitan. Si se omite, se usa la versión de compilación de tres partes de la herramienta, no la versión de la app instalada. Comprueba HostVersion, HostCompatible, los límites declarados y las limitaciones del proveedor. Las versiones deben usar la forma canónica de tres partes; no uses variantes con ceros a la izquierda.

canonical-payload solo acepta --manifest; describe-contract y author-schema no aceptan opciones. Una versión mínima indicada por el descubrimiento del contrato es un mínimo de declaración, no una promesa de que todos los anfitriones con esa versión implementen todas las combinaciones de proveedores. El anfitrión de destino real y el catálogo firmado compatible siguen siendo importantes.

Contrato de fixtures de Setup

Los fixtures usan JSON estricto: SchemaVersion 1, el InputSha256 de la entrada exacta y entre 1 y 32 Cases, dentro de 64 KiB y una profundidad de 24. Cada caso necesita un Id único y acotado, un objeto Setup no nulo y un booleano ExpectAccepted real. Un objeto Setup vacío prueba los valores predeterminados.

Los casos aceptados pueden comprobar ExpectedActivePortIds, ExpectedActiveFirewallRuleIds y ExpectedArgumentCount. Los casos de rechazo no pueden afirmar salidas positivas. El resultado vincula los resúmenes de la entrada y del fixture, e informa de los ID de los casos más motivos cerrados de PASS/FAIL, no de configuración, credenciales, perfiles ni valores de inicio.

En test-contract, el código de salida 0 significa que se cumplieron todas las expectativas, 1 que falló una expectativa y 2 que se rechazaron la entrada o las comprobaciones. Para el resto de comandos, un resultado correcto sigue requiriendo inspeccionar State, HostCompatible y los campos de garantía; el código de salida 0 por sí solo no es una aprobación de publicación.

Bytes canónicos y evidencias

canonical-payload emite la carga útil compacta sin firmar, sin firmar ni escribir ningún archivo. Comprueba que el comando se completó correctamente antes de usar su salida: la salida de un rechazo es un informe de diagnóstico, no una carga útil. La canonicalización cambia el resumen de la entrada; firmar un archivo crea a su vez otra entrada distinta. Vuelve a vincular los fixtures y las evidencias a los bytes realmente comprobados.

La entrada de la carga útil está limitada a 256 KiB, los archivos de paquete a 1 MiB y las evidencias explícitas a 64 KiB. Usa archivos de creación de confianza y revisados, no configuraciones en uso, mundos privados ni credenciales.

¿Qué se ha reproducido?

La versión preliminar para desarrolladores 0.9.140 superó una extracción limpia, los seis comandos en 21 invocaciones, las sumas de comprobación exactas de los miembros y 76 casos de Setup vinculados al código fuente, con verify-package confirmando la referencia firmada de Core Keeper en el anfitrión Keldrin 0.9.140. Las comprobaciones independientes con los archivos firmados de Abiotic Factor e Icarus superaron 33 casos. Son comprobantes de herramientas, no una certificación de jugabilidad. Se incluye la referencia firmada de Core Keeper 1.0.4, solo JSON, sin recursos de terceros.

Lee primero el README del paquete (en inglés); prevalece sobre los documentos de referencia copiados en el paquete.

Evidencias y límites de publicación

¿Encontraste un problema en la documentación? Cuéntanoslo en Comentarios (en inglés). No incluyas credenciales ni datos privados de juegos.

Interfaz real de la Web local de Keldrin · datos de demostración sintéticos