![\"El](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/studio-01-studio-editor-visor.webp\")
Con el SDK puedes añadir botones, formularios y funciones a Nelkano, o crear un tema propio. Escribes el módulo en JavaScript o TypeScript, lo pruebas en Studio y lo instalas en la app como un archivo .nelkmod.
\nAndroid, Desktop y SDK Studio comparten la versión 3.0.3-beta. El contrato que declaras en sdkVersion sigue siendo 0.2.0; la versión de tu módulo la eliges tú.
También puedes guardar datos propios, crear formularios y conectar servicios. Cada capítulo indica los permisos necesarios y cómo comprobar si el dispositivo o el motor admite la función.
\nEl visor de Studio usa juegos, cuentas, guardados y hardware simulados. Sirve para probar el código y la interfaz; las conexiones externas autorizadas sí pueden usar Internet.
\nPrueba después el paquete en cada plataforma que declares en el manifiesto. En Nelkano, abre Ajustes → General → Módulos: Instalados permite importar un archivo y Explorar abre el catálogo. La app verifica el paquete y muestra sus permisos antes de instalarlo.
\nAndroid, Desktop y Studio mantienen el mismo número de versión, con un instalador y un canal de actualización propios para cada destino. Los módulos se versionan y actualizan por separado.
\nUn paquete V2 puede incluir un motor nativo compilado por ti para Android o escritorio. Necesitarás preparar sus binarios, describir sus capacidades y probar cada destino. Sigue Paquete V2 con un motor compilado y consulta las operaciones del motor. Studio simula su integración; no ejecuta una prueba real del motor.
"},{"id":"de520020-2026-4000-8000-000000000002","language":"es","title":"Cómo funciona un módulo","path":"/es/sdk-de-nelkano/funcionamiento","content":"El archivo principal del módulo exporta createModule(host). host reúne las funciones del SDK: consultar juegos, guardar datos o actuar sobre una partida, entre otras.
activate() prepara el módulo al activarlo.contributions(context) devuelve los botones, secciones o ajustes que deben aparecer en la pantalla actual.dispatch(action, payload, context) atiende la acción del usuario. Puede abrir un formulario o cerrar el panel.deactivate() libera los recursos al desactivarlo.Por ejemplo, un módulo de notas añade un botón a la ficha del juego. La acción lee su nota y devuelve un formulario. Al guardar, escribe el dato y devuelve {kind:'close-panel'}.
![\"Del](\"/modules/custom/nelkano_home/assets/docs/sdk/module-lifecycle.svg\")
\ncontext.surface identifica la pantalla. El contexto puede incluir también gameId, systemId, session y selection. En Biblioteca, selection contiene los juegos seleccionados; en Ajustes puede no haber ningún juego abierto.
Para actuar sobre una partida, usa la sesión recibida en esa acción. Su id y generation identifican esa apertura del juego. Si la partida cambia, la app rechaza la referencia anterior.
Implementa onEvent(event) para recibir avisos:
data-changed: han cambiado datos.hooks-changed: ha cambiado una integración entre módulos.library-imported y context-changed: avisos adicionales de Android.Los eventos de partida y guardados se describen en Emulación. Lee los datos cuando los necesites y responde a sus avisos, sin volver a consultarlos continuamente.
\nPrueba los cambios de sesión en la app. Studio reconstruye el módulo al recargar y no reproduce todos los detalles de su cierre en Android.
\ncontributions(context) debe describir la interfaz usando el contexto y tus datos. Guarda los cambios en las acciones o los eventos: Nelkano puede reutilizar las contribuciones ya calculadas entre repintados.
close-panel cierra el formulario después de actualizar contribuciones y filtros.Mantén breves activate() y contributions(context): pueden ejecutarse durante el arranque. Inicia el trabajo costoso desde una acción del usuario o una tarea.
onHook(request) responde a un gancho: una integración que otro módulo ha declarado.onService(request) ejecuta un método de un servicio registrado por tu módulo.onProfile(request) valida y normaliza documentos del perfil. Durante esa validación no se puede llamar al SDK.onBackground(event) recibe task-due y, mientras trabaja, connection-changed. Debe funcionar tanto en una instancia nueva, sin pasar por activate(), como en una instancia ya activa.
Studio simula las tareas y entrega sus avisos a onEvent. No utiliza el planificador nativo de Android o escritorio.
Crea un proyecto, prueba una acción en Studio y exporta el paquete firmado. Después instala ese mismo archivo en la app para probarlo en Android o escritorio.
\n.exe para Windows x64.Incluye Node.js, Java, los tipos y los ejemplos. No necesitas instalar npm, un JDK ni Android Studio para crear módulos JavaScript o TypeScript.
\nGuarda tus proyectos fuera de la carpeta de instalación. Si prefieres la terminal, abre PowerShell en la carpeta de instalación de Studio y utiliza .\\nelkmod.cmd:
.\\nelkmod.cmd init C:/mis-modulos/mi-modulo\n.\\nelkmod.cmd dev C:/mis-modulos/mi-moduloEl proyecto contiene manifest.json, el código en src y sus recursos. El manifiesto declara nombre, ID, versión, permisos y archivos incluidos. Añade cada archivo nuevo a files; Studio ofrece hacerlo al crearlo.
![\"Crear](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/studio-02-nuevo-modulo-basico.webp\")
\n.nelkmod firmado.Al abrir Studio desde Inicio, la clave de firma está en %LOCALAPPDATA%\\Nelkano\\SDK\\.nelkdev\\author.pem. Si abres una carpeta con la CLI, se guarda en .nelkdev/author.pem dentro de esa carpeta. No incluyas la clave en files ni la publiques en Git.
Crea primero C:/claves. Usa destinos que todavía no existan para generar las claves y el paquete:
.\\nelkmod.cmd check C:/mis-modulos/mi-modulo\n.\\nelkmod.cmd keygen C:/claves/author.pem C:/claves/author-public.pem\n.\\nelkmod.cmd pack C:/mis-modulos/mi-modulo C:/claves/author.pem C:/mis-modulos/mi-modulo.nelkmod\n.\\nelkmod.cmd verify C:/mis-modulos/mi-modulo.nelkmod.nelkmod.Para importar una actualización, desactiva primero el módulo. El nuevo archivo debe conservar su ID y la clave del autor.
\n![\"Archivo](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/studio-06-exportado-nelkmod.webp\")
\nLa verificación comprueba tamaño, SHA-256, firma Ed25519, autor y compatibilidad. La firma identifica al autor y detecta cambios en sus archivos; sigue siendo necesario revisar lo que permite hacer al módulo.
\nLa ficha agrupa la información adicional en Compatibilidad, Versiones y Detalles técnicos. Este último permite copiar identificadores, dependencias e identidad del autor.
\nEn Instalados puedes activar y desactivar módulos opcionales. Desinstalar pide confirmación y conserva sus datos, salvo que marques Eliminar también sus datos. Los de Módulos esenciales vienen con Nelkano y se actualizan con la app.
\n![\"Autor,](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-11-install-review.webp\")
\nX.Y.Z, por ejemplo de 0.1.0 a 0.1.1.El servidor verifica el paquete y conserva las versiones anteriores con sus hashes. Reparar una versión ya registrada exige subir exactamente los mismos bytes.
\nNelkano comprueba al arrancar y al volver al primer plano, con seis horas entre comprobaciones automáticas. Puedes comprobar antes desde Módulos → Instalados → Comprobar actualizaciones.
\nSe ofrecen versiones superiores de módulos opcionales, con el mismo autor y compatibles con el SDK y la plataforma actuales. Cuando la app está libre, el aviso permite Ver actualizaciones o Más tarde. También aparece Actualizar módulo en Instalados; no se envía una notificación del sistema operativo.
\nCancelar la descarga o la revisión no instala nada. La actualización conserva los datos y recupera la instalación anterior si falla la sustitución. Gestionar módulo abre su entrada en Instalados cuando corresponde. También puedes actualizar mediante Importar módulo, con el módulo desactivado y la misma clave.
\nLos esenciales se actualizan con Nelkano. En primer plano, la app revisa el acceso de la cuenta cada minuto: cerrar sesión o perder el rol o permiso retira las actualizaciones privadas.
\nUna cuenta con permiso de administración de módulos puede crear la ficha con acceso Sólo Tester y subir el .nelkmod firmado. El archivo se aloja en almacenamiento privado de la web; la ficha no utiliza repositorio ni admite imágenes públicas.
El acceso se elige al crear la ficha. Sus siguientes versiones deben mantener el ID del módulo y la clave del autor. Se admiten paquetes V1 de hasta 32 MiB, comprobando firma, inventario, tamaño y SHA-256.
\nTester y quienes administran módulos ven y descargan tanto los públicos como los reservados. Las demás cuentas y los visitantes sólo ven los públicos. La app utiliza la sesión para autorizar cada descarga privada; cerrar sesión o perder el acceso retira sus fichas, versiones y descargas. La instalación sigue exigiendo verificación y revisión de permisos.
\nLos módulos públicos usan un enlace externo de descarga y pueden añadir un repositorio opcional.
\nAmbos sirven. En TypeScript importa los tipos con import type { Host, Extension } from '@nelkano/sdk'. Para archivos locales usa rutas como ./model.js.
V1 contiene JavaScript y recursos; no incluye Node.js ni librerías npm ejecutables. Revisa files antes de exportar y deja fuera las ROMs y las claves privadas. V2 añade motores nativos compilados, descritos más abajo.
El catálogo acepta paquetes V1 de hasta 32 MiB y sólo los permisos indicados como admitidos en Permisos y datos. Si tu V1 utiliza otros, como network.external, modules.services, runtime.tasks o emulation.input, distribúyelo para Importar módulo. Los paquetes V2 con motores nativos también requieren importación local.
Una tarea creada con tasks.schedule({id,delayMs,intervalMs?,payload?,background:true}) puede iniciar el módulo y llamar a onBackground(event) sin ejecutar activate().
createModule(host) sin inicializar la interfaz ni depender de variables preparadas en activate().tasks.update.Las tareas normales de la app siguen usando onEvent con task-due.
native/build.json con repositorio, commit, receta y hashes de las herramientas.nelkmod engine build ./mi-modulo --target windows-x86_64.nativeEngines del manifiesto, con formatVersion:2.nelkmod engine archive para reunir nk-engine-worker(.exe), la DLL/SO y sus dependencias.nelkmod pack para generar el único .nelkmod que importará el usuario.La ABI, el ejecutor, la plantilla Android y un ejemplo están en native/, dentro de la instalación de Studio.
La receta comprueba el commit y los cambios en archivos seguidos por Git. Cada ejecutable debe ser un alias o una ruta absoluta de la lista verificada: se comprueba su hash antes de ejecutarlo, sin buscarlo en PATH. Fija también los compiladores y las herramientas invocadas por CMake.
La compilación sólo se ejecuta al pedirla. Abrir o guardar el proyecto no lanza la receta.
\nnativeEngines declara motor, release, protocolo/ABI, descriptor y hash de su JSON canónico. El descriptor recoge sistemas y extensiones, controles, opciones, recursos o BIOS, API gráficas y compatibilidad de estados y almacenamiento.
Cada artefacto indica target, ruta, tamaño y SHA-256: engines/id/android-arm64-v8a.apk, windows-x86_64.zip o linux-x86_64.zip. Incluye sus dependencias.
packageId, service y certificateSha256.entryPoint de la DLL/SO.minApi, CPU y runtime describen restricciones; no hacen compatible un binario con otra plataforma.El contenedor usa ZIP32 STORE. Manifest y firma van primero; no admite ZIP64, cifrado, enlaces, campos extra ni descriptores de datos. La firma Ed25519 incluye la lista de archivos, tamaños y hashes de todos los destinos.
\nLa verificación lee los artefactos por tramos y sólo extrae a disco el destino actual; no los carga en el mapa de bytes de JavaScript. Los paquetes V1 siguen siendo compatibles.
\nEn Android, prepara un APK sin interfaz, firmado con tu certificado, distinto del de Nelkano. La app comprueba paquete, servicio, certificado y contrato antes de conceder recursos y superficie gráfica.
\nEl motor utiliza un proceso con UID propio. La ruta gráfica emplea un UID normal dedicado, sin permisos de red o almacenamiento. En escritorio, el proceso separado utiliza los permisos del usuario. La firma identifica el código; instalarlo requiere confiar en su autor.
\nRecuperar una instalación anterior no rebaja automáticamente un APK ya instalado. Android sigue gestionando esos APK y su desinstalación. El paquete se puede importar localmente sin publicarlo en el catálogo.
"},{"id":"de520020-2026-4000-8000-000000000011","language":"es","title":"Usar SDK Studio","path":"/es/sdk-de-nelkano/simulador","content":"Studio reúne el editor del módulo, un visor de Nelkano y las herramientas para probarlo y exportarlo.
\n.exe y completa la instalación.Node.js y Java vienen incluidos. Crea tus proyectos en una carpeta propia, fuera de la instalación. El manifiesto del módulo utiliza sdkVersion: \"0.2.0\".
Puedes crear archivos y carpetas e importar PNG y TTF. Los archivos pendientes de guardar llevan un asterisco. Si otro programa cambia uno que estás editando, Studio avisa antes de sobrescribirlo.
![\"Archivos](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/studio-04-arbol-manifest.webp\")
El visor reproduce las pantallas de Nelkano con la presentación Android. Incluye biblioteca, fichas, guardados y ajustes de prueba. Permite comprobar la navegación y las acciones del módulo, pero no ejecuta ROMs ni reproduce audio o mandos físicos.
Desde Ajustes puedes cambiar entre vertical y horizontal. El visor utiliza 420 × 800 y 800 × 420 puntos, ajustados al espacio disponible. Restablecer datos recupera los juegos de ejemplo y borra las preferencias simuladas, tras pedir confirmación.
Prueba también el paquete en cada plataforma de destino. Guardar el código recarga tu módulo, pero las actualizaciones de las pantallas compartidas necesitan una nueva distribución de Studio.
\nAbre Ajustes → General → Módulos. Instalados muestra los proyectos de ejemplo y separa los opcionales; su catálogo simulado no acredita los paquetes incluidos en la app. Explorar usa un catálogo local de los proyectos de tu carpeta, con búsqueda, filtros y fichas.
Este catálogo no consulta producción ni instala paquetes descargados. Comprobar actualizaciones revisa los metadatos locales. La comprobación de Actualización de Nelkano también es local y no instala una versión de la app.
Para comprobar la retirada de un proyecto, utiliza su interruptor en el panel Módulos de Studio. Esta herramienta de desarrollo permite apagar proyectos aunque el visor los presente como esenciales.
\ncodex o claude funciona en una terminal.codex login o abriendo claude.Studio consulta los modelos y niveles que comunica la sesión del CLI; no mantiene una lista fija. Si no puede confirmar la sesión o recibir un catálogo, explica el motivo y no ofrece modelos de ese agente. En Codex, comprueba las instalaciones detectadas y utiliza la más reciente. El servicio comprueba el acceso al enviar cada petición.
\nEl chat trabaja en la carpeta del proyecto seleccionado. Antes de enviar, Studio guarda los archivos; al terminar, actualiza el editor y el visor. Detener cancela el proceso y conserva las ediciones ya hechas. Las conversaciones se guardan por carpeta y agente.
\nAntes de cada mensaje, también al reanudar una conversación, Studio prepara .nelkano-sdk dentro del proyecto. Su README.md contiene el índice de:
El agente recibe la ruta del índice y la revisión de la referencia, y puede leer los capítulos, tipos y ejemplos que necesite. Las firmas de los tipos instalados determinan qué API puede utilizar. Esta carpeta es generada por Studio y se excluye de Git; no la edites como parte de tu módulo.
\nAl enviar mensajes, Studio revalida el libro con ETag si han pasado cinco minutos desde la última consulta. Si no hay conexión, conserva la última copia válida o utiliza la incluida en el SDK. Los tipos y ejemplos proceden de la instalación local: actualizar el libro no añade API a una entrega antigua.
\nLa fuente predeterminada es la referencia pública del SDK. Si desarrollas Studio contra otra web, puedes cambiarla con NELKANO_SDK_REFERENCE_URL o con tooling/reference/source.local.json. Ese archivo es configuración del entorno local y no se distribuye.
El CLI utiliza tu sesión y configuración para enviar la petición y los archivos que lea a su servicio. Studio no instala el agente ni inicia sesión por ti. El chat tampoco exporta el módulo, publica versiones o hace operaciones de Git automáticamente.
\nStudio utiliza una identidad de firma estable. Consérvala para las actualizaciones del módulo. Para empaquetar con otra clave utiliza la CLI; Studio no tiene selector de clave.
\nCrea un proyecto con la plantilla Amigos (simulación). En Biblioteca del visor, pulsa Amigos y accede con demo@nelkano.test y Nelkano123. El registro y las fotos son ficticios; no utilices credenciales reales.
Los juegos de prueba incluyen PSP, GameCube y Switch para revisar sus controles. Switch es solo una simulación: su core no está incluido en las apps Android ni Desktop. Si no aparecen en una biblioteca simulada antigua, restablece los datos del visor. Las pulsaciones físicas se comprueban después en el dispositivo.
\nEl explorador utiliza memoria simulada. Consulta Modificar un juego para los pasos y límites de cada operación.
\n![\"Explorador](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/studio-08-explorador-memoria.webp\")
Abre PowerShell en la carpeta de instalación y ejecuta .\\nelkmod.cmd con el comando que necesites. Utiliza rutas completas para tus proyectos; el lanzador usa el Node.js incluido. Para los motores V2 debes instalar también las herramientas de compilación que requiera tu receta.
.\\nelkmod.cmd example multiplayer C:/mis-modulos/mi-multiplayer\n.\\nelkmod.cmd example multiplayer-adapter C:/mis-modulos/mi-adaptadorCarga Amigos, Multijugador y el adaptador de ejemplo. Abre la sesión ficticia de CHIP-8 y comprueba sus botones y mensajes. Las cuentas, partidas y conexiones multijugador son simuladas.
Los formularios de un módulo se abren desde la pantalla que amplía. Si requieren cuenta, inicia sesión con una ficticia. La simulación mantiene las comprobaciones de identidad y permisos; la conexión real se prueba al exportar.
\nEjecuta .\\nelkmod.cmd dev C:/mis-modulos o usa Ajustes → Seleccionar carpeta de módulos. Studio detecta los manifiestos de las subcarpetas inmediatas y admite hasta doce proyectos; omite carpetas sin manifiesto y enlaces simbólicos.
El desplegable de Proyectos cambia el árbol y las pestañas al módulo seleccionado, conservando los borradores de los demás. Crear archivos e importar recursos actúa sobre ese módulo. También puedes abrir directamente un proyecto incompleto para repararlo. La ruta de trabajo aparece al pie y se puede copiar.
\nAbre el panel inferior desde Ajustes. Sus tres pestañas sirven para:
![\"Error](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/studio-05-problema-ubicacion.webp\")
Arrastra los separadores para ampliar el editor o el visor. En ventanas pequeñas puedes alternar Editor y Vista previa; Proyectos se repliega cuando falta espacio. Ajustes permite recuperar los paneles cerrados y Restablecer distribución vuelve a la disposición inicial conservando los datos.
\nconnections realiza HTTP y WebSocket reales a los destinos autorizados. Usa servidores y credenciales de prueba. Las tareas del entorno de desarrollo se eliminan al detener o reconstruir el módulo.
Studio verifica el ZIP oficial, cierra el programa y abre la versión nueva con tus proyectos. Conserva fuentes, claves y datos de desarrollo. La actualización incluye las herramientas, Node.js y Java.
La comprobación también se realiza al abrir, recuperar el foco y cada seis horas. La primera entrega se instala por el procedimiento habitual; las siguientes aparecerán cuando estén disponibles en el canal de nelkano.com.
\nhost.transfers utiliza juegos y guardados sintéticos. Permite comprobar bloques, hashes, revisiones, reintentos, revocación y caducidad entre entornos de desarrollo.
En Studio, los límites son 32 MiB por archivo, 127 miembros y 8 MiB por payload; en la app nativa, hasta 64 GiB y 100 000 archivos. Los paquetes de prueba solo se importan en Studio. La compatibilidad de estados reales y el rendimiento se comprueban en los dispositivos de destino.
\nStudio ofrece datos de prueba para traducción, capturas, clips, packs, gráficos, micrófono, audio, timeline y cámara. Consulta capabilities y simulated para distinguir el soporte simulado.
Puedes comprobar argumentos, formularios, permisos, conflictos y liberación de recursos. Las repeticiones del visor no son compatibles con un motor nativo. La exportación de vídeo se prueba con el selector de documentos de la app instalada. Los perfiles sí utilizan y validan los documentos registrados por los proveedores del entorno.
\nStudio no ejecuta el planificador nativo de onBackground. Sus temporizadores avisan mediante onEvent y anuncian persistent:false y closedApp:false.
Prueba las tareas persistentes en la app. El callback debe funcionar tanto en una instancia nueva sin activate() como en una ya activa. El sistema operativo decide cuándo ejecutarlo.
Prepara la receta de tu proyecto y selecciona Compilar motores nativos · receta del proyecto. Studio la ejecuta en tu PC y muestra los resultados. Revisa esa receta y sus herramientas antes de ejecutarlas: son código del autor.
Exportar genera un .nelkmod autocontenido y aplica las mismas verificaciones V2 que la CLI.
El visor simula host.engines: selección de motor, controles, opciones, recursos y medios, con simulated:true y native:false. Los binarios del motor, la GPU, los estados y el rendimiento se prueban en Android o escritorio.
Vas a añadir la opción Hola a Ajustes. Al pulsarla se abrirá un panel llamado Hola desde mi módulo. Este ejemplo no necesita permisos porque no consulta ni modifica datos de la app.
\nsrc/index.js, o créalo si la plantilla utiliza TypeScript.\nexport function createModule(host) {\n return {\n async activate() {},\n async deactivate() {},\n async contributions(context) {\n if (context.surface !== 'settings') return [];\n return [{\n moduleId: 'example.hello', id: 'hello',\n slot: 'SETTINGS_SECTION', section: 'Mis módulos',\n label: 'Hola', actionId: 'open', icon: 'standard:settings'\n }];\n },\n async dispatch(action) {\n if (action === 'close') return { kind: 'close-panel' };\n return {\n kind: 'panel', layout: 'form', id: 'hello',\n title: 'Hola desde mi módulo', dismissAction: 'close',\n fields: [], rows: [],\n actions: [{ actionId: 'close', label: 'Cerrar', submitFields: false }]\n };\n }\n };\n}contributions ofrece la opción sólo en Ajustes. dispatch abre el panel al pulsarla y lo cierra con la acción close. El panel no tiene campos ni filas: primero comprobarás que la integración funciona.
Guarda el código en src/index.js y comprueba estos valores de manifest.json:
\"id\":\"example.hello\"\"entry\":\"src/index.js\"\"files\":[\"src/index.js\"]Si la plantilla usaba src/index.ts, sustituye esa ruta en entry y files. El código anterior se copia sin cambios en el archivo JavaScript.
Para dar una función al botón, continúa con Emulación: operaciones y eventos, donde puedes añadir pausa o guardado.
\n![\"El](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/studio-03-hola-panel.webp\")
"},{"id":"de520020-2026-4000-8000-000000000004","language":"es","title":"Permisos y datos","path":"/es/sdk-de-nelkano/permisos","content":"Declara en capabilities los permisos que necesita tu módulo. Por ejemplo, storage.private.cas para guardar un ajuste y library.read para consultar juegos. La app los muestra al instalar y rechaza las llamadas no autorizadas.
\nconst doc = await host.storage.read('preferences');\nconst saved = await host.storage.compareAndSwap(\n 'preferences', doc.revision, { enabled: true }\n);\nif (!saved) throw new Error('El ajuste cambió. Vuelve a intentarlo.');La revisión evita sobrescribir un cambio más reciente. Los datos pertenecen a tu módulo y autor: desactivar los conserva; al desinstalar, el usuario puede borrarlos.
\nconst games = await host.library.list();\nif (games.length === 0) throw new Error('La biblioteca está vacía.');\nawait host.library.requestDelete([games[0].id]);requestDelete pide confirmación y permite cancelar. En Android elimina la copia privada del juego y sus guardados, conservando el archivo original importado. Studio sólo elimina datos ficticios.
![\"Permisos](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/studio-07-modulos-permisos.webp\")
\naccount.session: identidad, inicio de sesión, registro y cierre de sesión.network.account: peticiones a los endpoints de cuenta aprobados de nelkano.com.resources.image: referencia de una foto elegida por el usuario, sin revelar su ruta privada.Android utiliza una sesión cifrada y permisos firmados. Studio utiliza cuentas ficticias. Para conectar con otro servidor necesitas network.external.
input.gamepad: detectar mandos y aplicar o capturar asignaciones.media.second-screen: buscar y conectar un receptor local.media.streaming: iniciar y detener WebRTC con confirmación del usuario.appearance.locale: aplicar un diccionario. Elegir un tema requiere también presentation.appearance.resources.patch: elegir un parche y crear una copia del juego.Actualizar la app o perder el proceso no cambia la elección de activar o desactivar un módulo opcional. En Android y escritorio, la recuperación en primer plano funciona así:
\nLos cinco esenciales permanecen habilitados: Apariencia, Nelkano básicos, Editor de controles, Amigos y Multijugador. Si una versión anterior los dejó apagados o desinstalados, la app los recupera con los datos que existan.
\nConsulta las capacidades antes de ofrecer una acción que dependa del motor. Usa la sesión actual: una referencia antigua se rechaza. El SDK entrega datos y referencias limitadas, sin revelar al JavaScript rutas privadas ni tokens de cuenta.
\nhost.gameMod requiere emulation.game-mod y el permiso de cada operación:
emulation.read: consultar capacidades.emulation.memory.read: leer y listar reglas.emulation.memory.write: escribir o retirar una regla.Los hosts antiguos rechazan el permiso nuevo; no ejecutan el paquete parcialmente. Consulta los límites y la retirada de cambios en Modificar un juego. Estos permisos no dan acceso a archivos privados ni envían datos a servidores.
\nCon storage.entities, define los tipos mediante entities.define({name,version,schema,indexes,relations}). Después utiliza get, query, transact y migrate.
Admite relaciones dentro del módulo, filtros de igualdad, índices, ordenación y páginas. Los lotes usan expectedRevision y se aplican completos; las migraciones son transaccionales.
Los datos pertenecen al módulo y autor. Se guardan localmente en SQLite en Android/escritorio y en JSON en Studio; no se suben a Nelkano. Una actualización fallida recupera las entidades anteriores. Las preferencias CAS mantienen su formato.
\nnetwork.external y los destinos en origins, con origen HTTP o HTTPS, servidor y puerto concretos.connections.request/socket/read/send/close. Un origen autoriza también su WebSocket WS o WSS correspondiente.requestOrigin. La decisión se conserva para el módulo y autor.Android admite HTTPS/WSS; escritorio y Studio también HTTP/WS. Las peticiones no heredan cookies ni claves de la cuenta Nelkano y no siguen redirecciones.
\nHay hasta 12 trabajos simultáneos: 8 HTTP y 4 sockets. Los cuerpos y mensajes admiten 64 KiB. onEvent recibe connection-changed y connection-origin-reviewed; desactivar cancela las conexiones. Studio sí utiliza la red: usa datos de prueba.
Con runtime.tasks puedes consultar host.tasks.capabilities() y utilizar:
schedule({id,delayMs,intervalMs?,payload?,background?}): programar.read(id): consultar el estado.update(id,{state?,progress?,message?,result?}): publicar avances y resultado.cancel(id): cancelar.Las tareas normales entregan task-due a onEvent. Admiten 32 registros por módulo, intervalos de 100 ms a 24 h y datos de 32 KiB. Comprueba persistent y closedApp antes de ofrecer trabajo con la interfaz cerrada.
Declara también runtime.tasks.background y programa con background:true. El planificador nativo conserva el registro y ejecuta onBackground(event). Puede reutilizar la instancia activa o crear otra sin llamar a activate().
update.Android utiliza JobScheduler. En escritorio se utiliza Task Scheduler del usuario o systemd --user, con la sesión iniciada y acceso exclusivo a los datos. Antes de ejecutar se comprueban paquete, firma, habilitación y permisos.
En esa ejecución puedes usar tareas, transferencias, secretos, CAS, listados de biblioteca y guardados, y HTTP a destinos autorizados. No abre juegos, ventanas ni sockets, ni solicita permisos. Las transferencias requieren la partida cerrada.
\nDeclara storage.files. Puedes listar, leer y eliminar con files.list/read/remove; para escribir:
begin recibe name, expectedRevision y, opcionalmente, mimeType.write añade tramos consecutivos de hasta 64 KiB.commit publica el archivo completo. Si otra revisión ha cambiado, devuelve un conflicto. abort descarta la escritura.Límites: 16 archivos, 1 MiB por archivo, 4 MiB por módulo/autor y dos escritores abiertos por módulo. Desactivar descarta escrituras sin publicar y conserva los archivos terminados. Una actualización fallida recupera los anteriores.
\nfiles.import/export requiere también resources.documents. Abre el selector de Android o escritorio para que el usuario elija origen o destino; el módulo no recibe rutas ni URI.
Studio guarda archivos locales, pero anuncia importExport:false para el selector nativo. Una página puede usar un PNG privado con resource: file:imagen.png, ligado al registro activo y de hasta 1024×1024.
Con storage.secrets, usa secrets.get/put/remove/capabilities. Admite 64 claves, 4 KiB por valor y 64 KiB por módulo/autor.
Consulta persistent después de guardar. La recuperación de actualizaciones utiliza copias cifradas o referencias opacas, sin escribir secretos en texto plano en el registro de recuperación. Este servicio no comparte la sesión de Nelkano.
library.transfer y saves.transfer permiten importar y exportar mediante host.transfers, con referencias privadas del módulo y autor. La app verifica los archivos antes de incorporarlos.
Reemplazar guardados exige la revisión actual del destino: si cambió, se rechaza. La importación sustituye el conjunto completo de progreso y elimina los archivos de progreso que no estén en la copia recibida. La categoría de juegos no sustituye silenciosamente otro contenido con la misma identidad.
\nPara transferir por red necesitas sus permisos y orígenes. Consulta Emulación y transferencias para el contrato completo.
\ntranslation.local: analizar, editar y reconstruir traducciones con los proveedores anunciados por el host.media.capture: capturar la imagen del juego.media.record: grabar clips.resources.packs: preparar capas de archivos propias del módulo.profile.provide y registra los documentos CAS con host.profile.register({version:1,keys}).onProfile({operation:'validate',version,documents}). Devuelve {documents} normalizados con las mismas claves; el host valida un documento por llamada y no permite llamadas al SDK durante ella.profile-restored, recarga el estado publicado.Declara profile.backup. Consulta host.profile.capabilities() y list(); después:
export({moduleIds?}) devuelve ID, tamaño y SHA-256. Lee con read({id,offset,length}).beginImport({size,sha256}), write({id,offset,dataBase64}) y preview({id}). La vista previa devuelve la revisión agregada del destino.commit({id,expectedRevision}).abort({id}) o release({id}).La restauración requiere proveedores activos con la misma identidad y autor. Valida todos los documentos y publica el lote completo con revisiones locales nuevas. El módulo importador no puede restaurarse a sí mismo durante esa llamada.
\nBásicos, Editor y Apariencia registran preferencias, colecciones/favoritos y controles. Restaurar no reconecta el streaming. El perfil excluye secretos, archivos arbitrarios, entidades y partidas; para el progreso utiliza host.transfers. Tampoco incluye claves que no se hayan registrado.
Límites: 32 proveedores, 16 claves por proveedor, 96 KiB por documento y 64 MiB por contenedor. Tramos de 64 KiB, dos referencias abiertas por módulo y ocho globales; caducan tras diez minutos sin actividad.
\ngraphics.shaders: Postprocesar en GPU la imagen presentada del juego, separado de controles y texto superpuesto.graphics.options: Cambiar opciones gráficas que anuncie el core, inicialmente raster GameCube 1×/2×/4×.graphics.textures: Cargar PNG privados y sustituir texturas observadas por su hash dentro del core compatible.media.microphone: Capturar PCM del micrófono después del permiso nativo; se detiene al pasar a segundo plano.audio.dsp: Procesar el PCM del core antes de reproducirlo mediante ganancias, biquads y FIR.runtime.tasks.background: Junto con runtime.tasks, conservar y ejecutar registros background:true con la interfaz cerrada.Consulta capabilities antes de ofrecer la función. Los permisos gráficos no entregan contextos GPU, JNI ni rutas y rechazan sesiones antiguas. Grabar el juego no autoriza el micrófono.
emulation.timeline: historial, rebobinado, runahead, avance y repeticiones editables cuando el core lo admite; inicialmente CHIP-8.audio.mix: clips PCM16LE privados, sincronizados con la partida antes del DSP y la reproducción.media.camera: captura Camera2 en Android con permiso nativo. Entregar la imagen a CAM 3DS necesita también emulation.input.Cada servicio requiere su permiso. Las tareas con la interfaz cerrada mantienen sus restricciones: estos permisos no les permiten abrir juegos, mostrar interfaz, solicitar permisos ni usar cámara, reproducción o un core.
\nnative.execute autoriza los artefactos nativos declarados y revisados de un paquete V2; native.gpu, su integración gráfica. El JavaScript no recibe punteros, JNI, contextos GL ni rutas privadas.
Las operaciones de host.engines requieren además emulation.read, emulation.control, emulation.input o emulation.resources, según la acción. engines.importGame necesita también library.transfer y resources.documents: abre el selector con motor y sistema explícitos.
El código nativo se ejecuta fuera de QuickJS y requiere confiar en su autor. Desactivar retira su proveedor y recursos, y cierra las sesiones que dependían de él. Declarar una capacidad no demuestra que el motor implemente memoria, cámara o timeline.
\nEl catálogo web acepta V1 de hasta 32 MiB con los siguientes permisos:
\nlibrary.read, library.delete, library.launch, library.cover, saves.read, saves.autosave, saves.write, saves.load.emulation.game-mod, emulation.memory.read, emulation.memory.write, emulation.resources, emulation.handoff, emulation.read, emulation.control.presentation.overlay, presentation.player, presentation.appearance, presentation.control-layouts, environment.display, appearance.locale.runtime.events, storage.private.cas, modules.hooks.account.session, network.account, network.multiplayer.resources.image, resources.patch, input.gamepad, media.second-screen, media.streaming.Los demás permisos de esta página requieren un paquete compatible instalado mediante Importar módulo. Ser V1 no basta para entrar en el catálogo. V2 se distribuye por importación local.
"},{"id":"de520020-2026-4000-8000-000000000005","language":"es","title":"Añadir botones y ajustes","path":"/es/sdk-de-nelkano/ganchos-android","content":"Devuelve un botón o ajuste desde contributions(context), indicando dónde aparece y qué acción llama. Nelkano lo dibuja con el estilo de la app.
const contribution = {\n moduleId: 'example.tools', id: 'open',\n slot: 'SETTINGS_SECTION', section: 'Biblioteca',\n label: 'Mis herramientas', actionId: 'open',\n icon: 'standard:settings'\n};HOME_SECTION: sección en Home.LIBRARY_ACTION: botón en los filtros de Biblioteca, alineado con los controles nativos y con la altura del tema.LIBRARY_SELECTION_ACTION: acción para los juegos seleccionados.GAME_HEADER_ACTION: icono en la cabecera de la ficha.GAME_ARTWORK_ACTION: botón en la esquina inferior de la carátula.GAME_LAUNCH_ACTION: acción dentro de la ficha.SAVE_ACTION: acción sobre un guardado.SETTINGS_SECTION: fila en Ajustes → General.SYSTEM_ACTION y SYSTEM_SETTINGS_SECTION: acciones y ajustes de un sistema.EMULATION_SETTINGS_SECTION: ajuste durante una partida.PLAYER_ACTION y PLAYER_MENU: acciones durante la partida y en su menú.PLAYER_SYSTEM_BUTTON: botón sobre el área de emulación.section agrupa filas dentro de General; no crea una pestaña. Para un interruptor, usa kind:'toggle' y checked. La acción recibe el nuevo valor en payload.checked.
Desde dispatch, devuelve un panel con title, fields, rows y actions. Puedes añadir campos de texto, selección y JSON. Devuelve {kind:'close-panel'} para cerrarlo. El ejemplo mínimo contiene un panel completo.
enabled desactiva una acción. visibility filtra por sistema, capacidades o disponibilidad de juego, sesión y conexión. Para limitarla a un juego, comprueba context.gameId en contributions(context): visibility no filtra por ese ID. Vuelve a comprobar la disponibilidad al ejecutar.
PLAYER_SYSTEM_BUTTON: payload.controlId reutiliza un control existente.GAME_LAUNCH_ACTION: payload.primaryLaunch:true sitúa la acción junto a Jugar.PLAYER_MENU: payload.menuAction con save, load o reset utiliza las tarjetas del menú de guardados.Estos valores eligen ubicación y estilo. actionId sigue llamando a tu módulo: debes implementar la operación.
![\"Formulario](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-10-checkbox-selector.webp\")
\nthumbnail:{gameId,slot} muestra la captura junto al texto.slot:null usa la carátula actual; añade original:true para la portada original.preview:{gameId,slot} muestra una imagen grande arriba.Usa los IDs devueltos por la app, sin pasar rutas ni PNG. Una captura requiere saves.read; una carátula, library.read. Si falta la imagen, se muestra la portada de reserva.
LIBRARY_HEADER_ACTION añade acciones al buscador de Biblioteca y Guardados. Comprueba surface:library o surface:saves para decidir dónde contribuir.
LIBRARY_ACTION permanece en los filtros de Biblioteca. SAVE_ACTION conserva las acciones de Guardados sin saveId. El host reúne buscador, importar y filtros en una fila horizontal; en vertical utiliza dos.
La búsqueda de Guardados es local por título y se combina con sistema, orden y filtros del módulo. Restablecer limpia también la búsqueda.
\nDevuelve kind:page, title, fields, rows y actions. La página mantiene la navegación; kind:panel abre un diálogo.
Los campos admiten también password, email y checkbox. En una casilla, initial es booleano. En un select puede ser texto, número finito, booleano o null.
Conserva el tipo de cada opción: initial:0 selecciona el número cero; initial:\"0\", un texto. Aplicar sin editar y onChangeAction envían ese mismo tipo. Un botón con submitFields:false puede navegar aunque queden campos sin completar.
onChangeAction envía las ediciones tras 350 ms sin cambios, incluso al volver al valor anterior. Actualizar initial desde el módulo no genera una edición. En un selector se envía el valor con su tipo.
onChangeMinLength fija la longitud mínima; usa 0 si necesitas recibir una búsqueda vacía.
placement:header sin icono mantiene una acción encima del formulario.icon:profile o icon:refresh. Aparecen junto al título fijo, usan label como nombre accesible y tienen un área táctil de 48 dp.presentation:compact reduce el avatar y ajusta el texto de los botones.placement:overflow añade la acción al menú ⋮ y conserva payload, confirmación, condiciones y permisos. No se admite en acciones superiores; las acciones de fila no admiten icon.position:header sitúa una fila antes de los campos.Una fila admite avatar con label, color, imagen PNG en Base64 o url. La imagen local tiene prioridad.
Android carga de forma asíncrona las URL del origen de cuenta permitido y requiere network.account. Studio no descarga imágenes remotas.
Usa kind:\"page\",layout:\"settings\" para tener cabecera y botón de volver. En un selector, presentation:\"tabs\" muestra pestañas; initial selecciona la activa y onChangeAction recibe su valor sin añadir comillas.
En rows, elige una presentación:
section: encabezado.actions: botones agrupados en una fila, del mismo tamaño y respetando primary.setting: título, subtitle y value, con badge o icon opcional.list: fila sencilla que se puede pulsar.La primera acción se ejecuta al pulsar una fila de ajuste o lista. Su icono puede ser un recurso declarado en files o un icono standard. placement:\"footer\" sitúa una acción al pie del formulario.
Todos los kind:\"panel\", con o sin layout:\"form\", comparten el mismo diálogo en Android, Desktop y Studio: título y × fijos, cuerpo desplazable y acciones placement:\"footer\" al pie. Las demás acciones, incluidas las de filas, permanecen en el cuerpo.
Las páginas conservan su navegación; layout:\"settings\" se utiliza sólo con kind:\"page\".
dismissAction:\"close\" utiliza una acción existente con submitFields:false para la × y para cerrar el diálogo, respetando su confirmación.
Sin dismissAction, el host sólo recoge una acción inequívoca de cerrar/cancelar que no envíe campos ni pida confirmación. Si hay varias candidatas, conserva los botones y la × cierra desde el host. No se permite cerrar mientras se procesa una acción.
Asigna un id estable al formulario: el borrador se conserva al actualizar el mismo módulo, formulario y sesión. Cambiar de formulario o sesión lo reinicia. En paneles antiguos sin ID se distinguen título y esquema de campos.
Los avisos nativos y los formularios de cuenta, colecciones, mandos, streaming, parches y módulos utilizan esta presentación. Los lienzos del editor y las superficies de vídeo o mando mantienen su función.
\nUsa visibleWhen:{field:\"role\",values:[\"host\"]}, o combina condiciones con {all:[...]} y {any:[...]}. El campo referido debe ser un selector o una casilla del mismo formulario. Los valores deben existir entre sus opciones; las casillas usan booleanos.
Las condiciones se evalúan localmente al seleccionar, sin ejecutar JavaScript ni consultar el servidor. Admiten cuatro niveles, 32 nodos por condición y 32 valores por hoja.
\nUn campo oculto conserva el borrador, pero no se valida como requerido ni se envía en el payload.
\nenabledWhen utiliza las mismas condiciones y se combina con enabled. description añade una ayuda de hasta 256 caracteres bajo el botón.
Son condiciones de presentación: valida de nuevo los parámetros y permisos al ejecutar. Para elecciones cortas, como Crear partida/Unirse o 2/3/4, puedes usar kind:\"select\",presentation:\"tabs\". El borrador resiste las actualizaciones de estado y se reinicia al cambiar la sesión.
presentation.extend permite ui.page, mount, patch, remove, open, close y targets. Puedes crear secciones, filas, botones, formularios, pestañas, modales, imágenes PNG y lienzos con figuras. dispatch recibe acciones y valores.
home/library/game/saves/settings/emulation.before y .after..content para ocultar y sustituir el cuerpo.actionId. También puedes ampliar componentes de otros módulos.Los conflictos entre autores se rechazan. Desactivar retira los cambios. Límites: 32 registros por módulo, 256 globales, 96 KiB de contenido, 512 nodos y profundidad 16.
\nLa app y Studio comparten el renderizador. Los componentes se programan en JavaScript o TypeScript; no ejecutan HTML arbitrario. Revisa el resultado en el visor.
\nEn presentation.extend, kind:\"modal\" usa el mismo marco. label es el título y actionId recibe el cierre. Sólo sus hijos directos pueden usar placement:\"footer\"; el resto se desplaza con el contenido.
const dialog = {id:\"dialog\",kind:\"modal\",label:\"Editar nombre\",actionId:\"cancel\",children:[\n {id:\"name\",kind:\"field\",label:\"Nombre\",value:\"Ada\"},\n {id:\"actions\",kind:\"row\",placement:\"footer\",children:[\n {id:\"save\",kind:\"button\",label:\"Guardar\",actionId:\"save\"}\n ]}\n]};El host rechaza placement fuera de un hijo directo de modal o con otro valor. Las acciones siguen sujetas a la propiedad del módulo, el registro, la revisión y sus permisos.
files.{id:\"imagen\",kind:\"image\",resource:\"file:imagen.png\"}.storage.files y presentation.extend.El host valida formato y dimensiones. La imagen queda ligada al módulo/autor y a la revisión del registro de interfaz; otro módulo no puede leerla. Funciona en la app y Studio. También puedes componer nodos y dibujar figuras sin generar una imagen.
\nui.targets({offset,limit}), entities.types({offset,limit}) y services.list(name,{offset,limit}) devuelven 32 entradas por defecto, con un máximo de 128 y 112 KiB.
Aumenta offset por el número de entradas recibidas hasta obtener una página vacía. Una página puede terminar antes de limit por su tamaño.
Puedes añadir secciones a Home y acciones a la ficha de un juego. Nelkano básicos utiliza estas contribuciones para Favoritos, Continuar y la elección de carátula.
\nPublica una sección con los ID de los juegos que quieras mostrar:
{\n moduleId: 'example.home', id: 'my-games',\n slot: 'HOME_SECTION', label: 'Mis juegos', actionId: 'open',\n payload: { section: {\n kind: 'game-carousel', gameIds: ['id-del-juego'],\n emptyLabel: 'Todavía no hay juegos'\n }}\n}Los ID deben existir en la biblioteca. Nelkano dibuja las tarjetas y abre su ficha al pulsarlas. emptyLabel es el texto que aparece cuando la sección está vacía.
\n![\"Juegos](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-01-home.webp\")
![\"Sección](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-03-favorites.webp\")
Favoritos ya viene integrado en Básicos. La estrella de la ficha añade o quita el juego de esa colección, y Home muestra su sección. No necesitas instalar Colecciones por separado; los datos se conservan al actualizar.
\nUsa GAME_HEADER_ACTION. Para una acción que se pueda marcar, indica su estado con checked; así funciona la estrella de Favoritos.
\n![\"Ficha](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-02-game-details.webp\")
Jugar abre el juego sin cargar un estado de Nelkano; su progreso interno se recupera desde los menús del propio juego. También se puede cargar un estado concreto desde su miniatura, aunque los autoguardados estén desactivados.
\nGAME_ARTWORK_ACTION coloca una acción en la esquina inferior de la portada. Básicos la utiliza para abrir el selector de capturas. Para cambiar la carátula desde tu módulo:
\n// Requiere library.cover. Los IDs vienen de library.list y saves.list.\nawait host.library.setCover(gameId, slot);\n// Volver a la portada original:\nawait host.library.setCover(gameId, null);Obtén los juegos con library.list y los guardados con saves.list. hasThumbnail indica si un estado tiene captura; coverSlot identifica la carátula elegida. Solo se aceptan juegos existentes, slots del 0 al 6 y guardados con captura. La elección se conserva al volver a abrir Nelkano.
"},{"id":"de520020-2026-4000-8000-000000000006","language":"es","title":"Conectar dos módulos","path":"/es/sdk-de-nelkano/ganchos-modulos","content":"Un módulo puede publicar funciones que otros utilicen. Por ejemplo, el editor de controles admite botones e iconos aportados por otro módulo.
\nprovides.consumes.modules.hooks.Marca optional:true si el consumidor debe funcionar aunque falte el proveedor.
![\"Conexión](\"/modules/custom/nelkano_home/assets/docs/sdk/module-hooks.svg\")
\nawait host.hooks.contribute(\n 'nelkano.control-editor', 'system-buttons', 'my-button',\n { actionId: 'my-action', label: 'Mi botón', icon: 'assets/button.png' }\n);Añade assets/button.png a files. Cuando el usuario pulse el botón, tu módulo recibe onHook con operation:'my-action'. El editor entrega el contexto de partida en request.value.context; úsalo en las operaciones de emulación.
La app incluye el proveedor nelkano.control-editor. La plantilla Editor de controles de Studio utiliza example.control-editor: para probar con ella, usa ese ID tanto en consumes.provider como en hooks.contribute y carga también la carpeta del proveedor en Studio.
Con target:'sys-pause' puedes reutilizar un control existente y conservar su posición. Sin target, se añade un control independiente.
hooks.status: comprobar disponibilidad.hooks.list: obtener aportaciones.hooks.invoke: llamar al proveedor.invokeContributor: responder al consumidor desde el proveedor.Entradas y salidas deben cumplir el esquema del gancho. Al desactivar o retirar un módulo desaparecen sus botones e iconos. El editor conserva las elecciones para cuando se reactive.
\nDeclara modules.services y registra name, version y methods. Cada método define input/output con los mismos tipos de esquema que los ganchos.
await host.services.register({\n name: \"example.counter\", version: \"1.0.0\",\n methods: { add: { input: {type: \"integer\"}, output: {type: \"integer\"} } }\n});\n// Otro módulo, con modules.services:\nconst next = await host.services.call(\"example.counter\", \"add\", 4);\n// El proveedor implementa onService(request) y devuelve el resultado.Implementa onService: recibe service, method, value, caller y provider, con la identidad real del módulo y autor. La base usa author:builtin. El servicio se ejecuta dentro del entorno aislado del proveedor.
list(name) encuentra proveedores.unregister(name) retira únicamente los tuyos.call admite proveedor, autor y versión mínima compatible dentro de la misma versión mayor.Un mismo nombre y versión mayor deben mantener métodos y esquemas. El servicio no comparte código ni datos privados. Se rechazan ciclos y llamadas a un entorno ocupado. Límites: 256 proveedores, 32 métodos, profundidad de esquema 8 y datos de hasta 96 KiB.
\nIndica options.provider en services.call para elegir uno concreto. Sin proveedor explícito ni preferencia guardada, se utiliza la implementación integrada; si no existe, se puede elegir al único proveedor disponible. Si hay varios y ninguno integrado, debes elegir.
Cada llamada verifica permisos y compatibilidad del contrato.
\nLa base publica nelkano.emulation versión 1.0.0, método execute, entrada {operation,args} y salida {value:resultado}. Consulta list(\"nelkano.emulation\") para copiar el contrato exacto.
Abarca snapshot, pausa/reset, presentación, guardar/cargar, library.launch y library.setCover. Las API anteriores delegan en él conservando sus permisos. Otro proveedor puede cambiar el comportamiento y delegar a la base con provider:\"nelkano.base\",author:\"builtin\".
Consumidor y proveedor necesitan el permiso original de cada operación. Este servicio afecta a las operaciones solicitadas por módulos; no sustituye las llamadas internas de la app ni los motores nativos.
\nCon modules.events:
define(topic,schema). Su nombre debe empezar por el ID de tu módulo y un punto.subscribe(topic), incluso antes de que exista el publicador.emit(topic,value). Sólo él puede emitir.onEvent con {type:\"module-event\",topic,value,sender:{moduleId,author}}. unsubscribe(topic) cancela la suscripción.Son eventos locales; no se envían a servidores. Límites: 256 temas, 64 suscripciones y 64 eventos pendientes por módulo. Si se llena una cola, se rechaza todo el envío sin entregas parciales.
\nSe entregan hasta ocho eventos por ronda, aproximadamente cada 50 ms en primer plano, sin garantía de persistencia ni de tiempo exacto. Desactivar limpia servicios, temas, suscripciones y colas. Los ganchos siguen disponibles y Studio reproduce estos contratos.
\nRegistra services.intercept({id,name,method,phase,order}) con fase before o after. onService recibe phase y hookId; devuelve un valor compatible con el esquema del método. Retira la transformación con removeInterceptor(id).
Admite 32 por módulo y 128 globales. Las llamadas propias no vuelven a entrar en su interceptor. Un error posterior a la operación no deshace sus efectos.
"},{"id":"de520020-2026-4000-8000-000000000009","language":"es","title":"Qué hacen los módulos incluidos","path":"/es/sdk-de-nelkano/ejemplos-distribuidos","content":"Nelkano incluye cinco módulos esenciales: Básicos, Editor de controles, Apariencia, Amigos y Multijugador. Sus funciones también sirven de ejemplo para crear las tuyas con el SDK.
\nAbre Ajustes → General → Módulos → Instalados. Los esenciales están agrupados en Módulos esenciales: permanecen activos, no se pueden desinstalar y se actualizan con la app. Si uno falla al arrancar, puedes reintentar su activación.
\nLos módulos que crees serán opcionales. El usuario podrá importar su archivo .nelkmod, desactivarlo conservando los datos o desinstalarlo. Declarar un valor en el manifiesto no permite convertirlo en esencial.
\nReúne las colecciones y Favoritos, la gestión de juegos, Continuar, los autoguardados, las carátulas y los botones de emulación. También ofrece la configuración de mandos, segunda pantalla y streaming.
\nLas colecciones, los favoritos y el filtro se conservan al actualizar. Colecciones ya está integrado en Básicos: el ejemplo independiente del SDK es material para autores y no necesita instalarse en la app.
\nPermite mover, redimensionar y ocultar controles. Se abre desde Ajustes → General → Controles → Editor de controles o desde el menú de la partida. Otros módulos pueden añadirle botones e iconos mediante sus ganchos.
\nOfrece el idioma y los temas de la app. Un módulo puede aportar temas mediante sus contratos.
\nGestiona la cuenta, las solicitudes de amistad y el perfil. Sus ganchos permiten añadir acciones y consultar los datos compartidos. Studio utiliza cuentas ficticias para probarlo.
\nParches está temporalmente excluido de los módulos cargados en Android y escritorio. Sus fuentes y el servicio del SDK se conservan para revisión; no aparece Aplicar parche en la ficha.
\nOfrece la interfaz de conexión entre jugadores. Cada modo necesita un motor y un adaptador compatibles; la interfaz por sí sola no añade multijugador a cualquier juego.
\n\nAbre la plantilla del módulo que quieras estudiar; la de Nelkano básicos incluye las colecciones. Studio permite activar y desactivar los proyectos para comprobar cómo añaden y retiran sus funciones. Las plantillas adicionales, incluida Parches, no establecen paridad con los paquetes incluidos en la app.
\nUtiliza los formularios del SDK: mantienen el título y el cierre arriba, las acciones al pie y el contenido desplazable. Este patrón se usa en Amigos, Apariencia y los formularios auxiliares del Editor.
Módulos tiene pestañas Instalados y Explorar; ocupa una pantalla en Android y una ventana en escritorio. La ficha del juego conserva Jugar y Continuar al pie. Reutiliza estas superficies para que tu función encaje en la navegación de Nelkano.
"},{"id":"de520020-2026-4000-8000-000000000007","language":"es","title":"Cambiar la apariencia","path":"/es/sdk-de-nelkano/apariencia","content":"Un módulo de apariencia puede ofrecer colores, fondo, fuente, iconos, tamaños y opciones de distribución. Parte de la plantilla Apariencia de Studio para probarlos en el visor.
\npresentation.appearance.skins, con id y label.Las propiedades disponibles son colors, background, font, icons, cornerRadius, spacing, controlHeight, headerHeight, navigation y libraryView.
background e icons: recursos del paquete.font: archivo TTF declarado en files.navigation: top o bottom.libraryView: grid o list.En un formulario, select muestra un desplegable. presentation:tabs lo presenta como pestañas, conservando el valor JSON seleccionado.
![\"Apariencia](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-07-language-dark.webp\")
\n![\"Tema](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-08-language-light.webp\")
\nSelecciona el estilo en el visor y revísalo también en Android antes de distribuirlo.
\nUn estilo modifica los componentes que Nelkano ya muestra. Para añadir páginas o formularios, utiliza la API de interfaz: el estilo no ejecuta HTML ni instala vistas Android.
"},{"id":"de520020-2026-4000-8000-000000000010","language":"es","title":"Qué puedes hacer y qué falta","path":"/es/sdk-de-nelkano/limites","content":"Para elegir las API de tu módulo, empieza por la tarea que quieres resolver. La disponibilidad depende de la plataforma y del motor: consulta sus capacidades antes de ofrecer una acción.
\n![\"Android,](\"/modules/custom/nelkano_home/assets/docs/sdk/sdk-environments.svg\")
La interfaz se construye con los componentes de Nelkano. El JavaScript del módulo utiliza las operaciones autorizadas del SDK: no dispone de Node.js, acceso libre a archivos ni vistas Android. Los proveedores permiten sustituir los puntos que la app u otro módulo hayan publicado.
\nhost.gameMod permite leer y buscar memoria, escribir comprobando los valores anteriores, ejecutar reglas antes de cada fotograma, enviar pulsaciones y modificar temporalmente la ROM cargada. La memoria y la ROM están conectadas a GBA en Android y escritorio. GB/GBC y NDS ofrecen lecturas específicas mediante host.gameRuntime; comprueba qué admite la sesión.
El archivo ROM original se conserva, pero los efectos pueden quedar en los guardados. Puedes declarar que una partida necesite tu módulo o requiera empezar de nuevo cuando el motor lo permita. Consulta Modificar un juego antes de escribir: explica los conflictos, la retirada del módulo y los requisitos de guardados.
\nhost.media ofrece capturas y clips cuando el motor entrega la imagen o el audio necesarios. host.translation analiza, edita y reconstruye los formatos de texto compatibles de GBA/NDS. Android puede traducir con modelos locales descargables; escritorio permite editar las entradas o recibir traducciones de tu servicio. Para reconocer texto dentro de una imagen, aporta un OCR.
host.graphics ofrece filtros y las opciones gráficas del motor. El postprocesamiento requiere Android API 33+ o Skia en escritorio. PS1, PSP y GameCube admiten reemplazos PNG de texturas; GameCube ofrece resolución interna 1×, 2× y 4×. Consulta las capacidades y los límites del modo de renderizado: el mismo pack no sirve para todos los juegos.
host.audioDsp filtra el PCM del juego y host.audioMix mezcla PCM externo cuando la sesión lo admite. host.microphone captura audio del dispositivo con su permiso. host.camera captura imágenes en Android; escritorio anuncia capture:false. Tu módulo debe aportar el reconocimiento de voz, el doblaje o la interpretación de imágenes. Entregar una imagen a la cámara emulada de 3DS requiere además su capacidad y permiso.
host.timeline permite rebobinado, avance y repeticiones editables en motores con ejecución determinista. La integración inicial es CHIP-8. Poder guardar y cargar estados no implica que un motor admita estas funciones.
host.transfers exporta e importa juegos y partidas en Android y escritorio. Tu módulo resuelve la conexión entre dispositivos y los conflictos. El destino necesita un motor compatible con el formato del estado; los guardados internos también pueden depender de la plataforma o versión. Los guardados MV/MZ de WebView quedan fuera.
host.resourcePacks prepara capas de archivos y host.profile permite copiar las preferencias que registren sus proveedores. Los packs excluyen los proyectos RPG Maker que guardan su progreso dentro del proyecto. Los reemplazos gráficos por hash utilizan el servicio de texturas.
Para sincronizar con tu servicio, combina transferencias, conexiones, secretos y tareas. Implementa su autenticación y declara los destinos de red. La transferencia de juegos y progreso necesita la partida cerrada.
\nDeclara las plataformas en el manifiesto y prueba el paquete en cada una. Ten en cuenta estas diferencias:
Comprueba también mandos, gráficos y rendimiento en los dispositivos que quieras admitir, incluida Steam Deck si es uno de tus destinos.
\nAmigos y Multijugador vienen incluidos. Multijugador ofrece su interfaz en GB/GBC, GBA y NDS; cada modo necesita un motor y un adaptador compatibles.
\nUn paquete V2 puede incluir un motor compilado para Android o escritorio. Su descriptor declara sistemas, controles, opciones, discos, recursos y formatos de guardado. La partida conserva el motor y la versión con los que se abrió. El ejemplo nativo del SDK sirve para probar vídeo CPU/OpenGL/Vulkan, audio PCM, entrada y estados.
\nEn escritorio, el motor se ejecuta con los permisos del usuario. En Android se instala un APK auxiliar con UID y certificado propios; la ruta gráfica no utiliza isolatedProcess. Revisa el código nativo y sus dependencias antes de distribuirlos. Linux utiliza X11/GLX o Vulkan y necesita XWayland en un escritorio Wayland.
Los juegos y dispositivos de Studio son simulados; las conexiones externas autorizadas sí usan la red. Los módulos opcionales se distribuyen por separado. Los cinco esenciales se actualizan con Nelkano.
"},{"id":"de520020-2026-4000-8000-000000000013","language":"es","title":"Editor de controles","path":"/es/sdk-de-nelkano/editor-de-controles","content":"El Editor de controles permite cambiar posición, tamaño, visibilidad e iconos. Guarda un diseño por perfil y orientación. GB y GBC comparten GAME_BOY; NDS y SNES utilizan NDS.
Pulsa Guardar para aplicar los cambios. Cerrar con la × descarta el borrador.
\n![\"Distribución](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-05-controls-before.webp\")
![\"Botón](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-06-controls-after.webp\")
environment.snapshot() obtiene el tamaño y la densidad de pantalla. Requiere environment.display.presentation.applyControlLayouts() aplica el diseño guardado y releaseControlLayouts() lo retira. Ambas necesitan presentation.control-layouts.Guarda las preferencias del módulo en su almacenamiento privado, con el permiso correspondiente.
\nCada control utiliza x e y entre 0 y 1, scale entre 0.5 y 2 y visible. Los perfiles separan PORTRAIT y LANDSCAPE. El editor y la partida utilizan las mismas coordenadas.
\nEl Editor publica dos ganchos, ambos en la versión 1.0.0:
Si tu módulo publica su propio PLAYER_SYSTEM_BUTTON, usa como target module:ID-del-consumidor:ID-del-botón. Así el Editor lo mueve sin duplicarlo y tu módulo conserva sus acciones y paneles. Publica las mismas posiciones iniciales en el botón y en placement.
\nSi el Editor publica el botón, llama a tu módulo mediante invokeContributor con el contexto de la partida. Si publicas tu propio PLAYER_SYSTEM_BUTTON y su target empieza por module:ID_DEL_CONSUMIDOR:, la acción se envía directamente a tu módulo; el Editor conserva la colocación.
Implementa la operación en tu módulo. Aportar un icono de captura o streaming no implementa esas funciones. Los iconos se dibujan dentro del marco común de los botones de sistema.
\nBásicos aporta pausa, guardar, cargar, estirar, pantalla completa y el selector de pantalla NDS/3DS. Reutiliza sus ID estables, como sys-pause y sys-save, para conservar las posiciones que haya elegido el usuario.
Definir un control en el perfil no basta para que aparezca: necesita una acción disponible en la partida.
\nSus claves son PSP, GAMECUBE y SWITCH. GameCube ofrece stick principal y C-stick; PSP, un stick principal. LEFT_STICK y RIGHT_STICK identifican controles JOYSTICK. Actualmente envían direcciones independientes, sin intensidad proporcional de inclinación.
Los tipos BuiltinControlProfile y StickControlInput ayudan a programarlos. El contrato también admite claves de texto para crear perfiles propios. Las plantillas del Editor y de Básicos incluyen estos perfiles. El perfil Switch se conserva en el SDK y en Studio; no habilita su core, excluido de las apps Android y Desktop.
El perfil RPG Maker incluye Teclado, identificado por sys-keyboard. Se puede mover, redimensionar y ocultar por orientación. Durante la partida abre el teclado de Android para escribir, borrar con Backspace y confirmar con Enter.
Esta función pertenece al reproductor Android; no requiere un permiso nuevo del SDK ni ofrece un teclado virtual en escritorio o Studio.
"},{"id":"de520020-2026-4000-8000-000000000014","language":"es","title":"Emulación: operaciones y eventos","path":"/es/sdk-de-nelkano/emulacion","content":"Usa estas operaciones para pausar, guardar, cambiar la presentación o crear herramientas sobre una partida. Android y escritorio trabajan con el juego abierto; Studio utiliza datos simulados.
\nconst state = await host.emulation.snapshot();\nif (!state) return; // No hay partida abierta.\nconst session = state.session;Declara emulation.read. La respuesta incluye gameId, systemId, paused, capabilities, slots, canSave y display. En display encontrarás fullscreen, stretch, screenMode y selectedSlot. Consulta esas capacidades antes de ofrecer una operación.
\nawait host.emulation.setPaused(session, true); // Pausar.\nawait host.emulation.setPaused(session, false); // Reanudar.\nawait host.emulation.reset(session);\nawait host.emulation.setFullscreen(session, true);\nawait host.emulation.setStretch(session, true);\nawait host.emulation.setScreenMode(session, 1);\nawait host.emulation.selectSlot(session, 2);\nawait host.saves.save(session, 2);\nawait host.saves.load(session, 2);screenMode admite 0 (Ambas), 1 (Superior) y 2 (Inferior), en motores con DUAL_SCREEN.
\nLos slots manuales van del 0 al 5. El 6 es el autoguardado: puedes cargarlo, pero saves.save no permite escribir en él. Comprueba canSave y capabilities; algunos motores no admiten estados.
\nSNES, PSP y GameCube utilizan estas mismas operaciones. Para cargar necesitas el mismo juego y un formato de estado compatible. Las pruebas de Switch con Dynarmic pertenecen al core de desarrollo PC; Switch está excluido de las apps Android y Desktop. Los perfiles y botones del editor no habilitan un core ni sus estados.
\nawait host.library.launch(gameId); // Abre el juego sin cargar un estado de Nelkano.\nawait host.library.launch(gameId, 6); // Desde el autoguardado.Requiere library.launch. El gameId debe existir en la biblioteca y, si indicas un slot, ese estado debe estar guardado. Sin slot se abre el juego sin cargar un estado de Nelkano; el progreso interno se recupera desde los menús del juego. No se trabaja con rutas de ROM.
Declara emulation.read y emulation.control. Publica el botón en contributions y responde a su pulsación en dispatch:
async contributions(context) {\n if (context.surface !== 'emulation' || !context.session) return [];\n return [{\n moduleId: 'example.pause', id: 'pause',\n slot: 'PLAYER_SYSTEM_BUTTON', label: 'Pausa',\n actionId: 'pause', icon: 'assets/pause.png',\n payload: { controlId: 'sys-pause' }\n }];\n},\nasync dispatch(action, payload, context) {\n if (action !== 'pause') return null;\n const state = await host.emulation.snapshot();\n if (!state || state.session.id !== context.session?.id ||\n state.session.generation !== context.session?.generation) {\n throw new Error('Esta partida ya terminó.');\n }\n await host.emulation.setPaused(context.session, !state.paused);\n return null;\n}Incluye el PNG en files. controlId reutiliza sys-pause y la posición elegida en el Editor. Si lo omites, creas otro botón. Evita que varios módulos publiquen simultáneamente el mismo control.
\nAl guardar se captura la imagen del motor, sin los controles. En NDS y 3DS, las miniaturas muestran la pantalla superior aunque estés viendo otra. Los estados anteriores sin captura la obtienen al volver a guardarse.
\nawait host.saves.setAutoSave(true);\nawait host.saves.setAutoSave(false);Requiere saves.autosave. La app sobrescribe el slot 6 cada 60 segundos de juego sin pausa, cuando el motor lo permite. Los slots manuales se conservan.
Cada módulo tiene su propia solicitud: basta una activa para mantener el autoguardado. Al desactivar o desinstalar el módulo se retira la suya. Guarda tu preferencia y aplícala de nuevo en activate. El intervalo, el destino y la cantidad de copias no son configurables desde esta API.
\nCon emulation.read, onEvent recibe session-started, session-paused, session-resumed, session-closed, session-reset, save-created, save-loaded y display-changed.
async onEvent(event) {\n if (event.type === 'save-created') {\n console.log('Guardado', event.slot, event.automatic);\n }\n return null;\n}Los avisos incluyen session y gameId. Los de guardado añaden slot y automatic, que es true para el autoguardado. Consulta snapshot si necesitas el estado actualizado. Estos eventos no se emiten por fotograma.
\nUtiliza la sesión recibida en la acción. La app comprueba su id y generation y rechaza referencias de una partida anterior. Captura los errores para explicar al usuario qué operación falló.
Studio permite probar las llamadas y miniaturas simuladas. Para comprobar que un estado recupera el juego correctamente, pruébalo en la app de destino. library.setCover puede utilizar su captura como portada.
\nconst active = await host.emulation.snapshot();\nif (!active || active.systemId !== \"gba\") return;\nconst result = await host.gameRuntime.read(active.session, {\n ranges: [{address: 0x02000000, length: 16}]\n});\n// result.ranges[0].data contiene los bytes en Base64.host.gameRuntime.read() admite hasta 32 rangos y 64 KiB por petición; cada rango puede tener hasta 32 KiB. patch() recibe writes con address, data y expected. Solo funciona en adaptadores con escritura y compara los bytes esperados antes de aplicar el cambio.
Los permisos de estas operaciones son:
read: emulation.memory.read.patch: emulation.memory.write.rom, romSearch y frame: emulation.resources.emulation.handoff.subscribe: runtime.events.overlay: presentation.overlay.overlay(session, nodes) publica hasta 32 PNG y etiquetas en coordenadas del frame. Respeta los límites de imagen anunciados. Una lista vacía limpia la capa; cerrar la sesión o desactivar el módulo también la retira.
\ncheckpoint conserva un estado privado del módulo y su autor. checkpointRead lo lee por bloques; checkpointPatch crea otro comprobando expected y las regiones RAM del motor. restore exige el mismo juego. No aparece entre los slots manuales.
\nprojectWrite y projectRead utilizan una copia privada del proyecto. Admiten Save/, Graphics/Characters/ y Graphics/Trainers/, con bloques de hasta 32 KiB y archivos de hasta 2 MiB. projectLaunch abre esa copia.
invoke llama a un método sin argumentos de Game o de una constante RGSS terminada en Bridge, mediante {receiver, method}. El juego debe ofrecer ese puente. external configura el transporte de mensajes RGSS. Estas operaciones requieren emulation.handoff.
Save/ es una ruta lógica de la copia privada. El host admite los archivos RGSS relativos a la raíz o a Save/ y lee la copia más reciente. El proyecto importado original se conserva.
Antes de invocar funciones de una copia privada, consulta projectActive(session, {gameId}). Su respuesta {active} confirma si esa partida está usando la copia de tu módulo, sin revelar su ruta.
\nAñade id y camera al nodo de overlay. Con camera, x e y son coordenadas del mundo; x e y dentro de camera indican el origen de cámara observado al preparar el nodo. El host compara ese origen con los registros del fotograma y ajusta el dibujo al desplazarse el mapa.
\nawait host.gameRuntime.overlay(session, [{\n id: \"jugador-2\", x: 620, y: 180, width: 16, height: 32,\n image: pngBase64, label: \"Mi amigo\",\n camera: {xAddress: 0x04000014, yAddress: 0x04000016,\n x: 500, y: 100, modulus: 512}\n}]);Requiere emulation.memory.read y presentation.overlay. Se admiten los registros GBA alineados de 16 bits entre 0x04000010 y 0x0400001e, y los registros GB/GBC SCY/SCX en 0xff42/0xff43. Utiliza los registros que entregue el adaptador: si faltan en el frame, el nodo se oculta.
modulus debe ser una potencia de dos entre 2 y 65536. Las coordenadas de cámara se limitan a ±65536. Sin camera, el nodo usa coordenadas de pantalla. Un id estable conserva su identidad y suaviza los desplazamientos remotos entre posiciones.
Durante una conexión online en espera, activa o recuperándose, la partida debe avanzar: el host oculta Pausa y rechaza la pausa hasta desconectar. Studio reproduce esta regla con su conexión ficticia.
Consulta pauseAllowed en host.emulation.snapshot(). Si es false, setPaused(session, true) devuelve false y la partida continúa. Si falta el campo en un host anterior, trátalo como permitido. Reanudar sigue disponible.
Utiliza host.gameMod para los espacios de memoria, escrituras por lotes y reglas. GBA ofrece memoria y ROM temporal; Studio las simula. host.gameRuntime conserva sus operaciones específicas. El capítulo Modificar un juego explica capacidades, permisos, conflictos y retirada del módulo.
RPG Maker XP/RGSS y MV/MZ usan los guardados internos del juego y no admiten guardar, cargar ni autoguardar estados de emulación. Los estados anteriores se conservan como archivos, pero no aparecen en Guardados o Continuar.
\nhost.transfers intercambia contenido entre Android y escritorio. Declara library.transfer para juegos y saves.transfer para progreso. Cada permiso permite exportar e importar su categoría. Implementa la conexión y la interfaz de usuario; el host valida los datos y los incorpora a la biblioteca.
capabilities() para obtener disponibilidad y cuotas.inspect({gameId}). Recibes contentFingerprint, savesRevision, saveKinds, plataforma y limitaciones.exportGame({gameId}) o exportSaves({gameId}). La respuesta es {id,format,kind,gameId,title,systemId,size,sha256}.read({id,offset,length}), que devuelve dataBase64.close({id}).beginImport({kind,gameId,size,sha256}) crea una recepción privada.write({id,offset,dataBase64}) y comprueba el total recibido.commit({id,expectedRevision?}) verifica tamaño, SHA-256, manifiesto y hashes antes de publicar el contenido.La respuesta incluye la identidad, importedGame, importedSaves (número de slots) e importedSaveFiles (total de archivos de progreso). El éxito consume la recepción. Si falla, puedes reintentar o descartarla con abort({id}). close y abort devuelven false si el identificador ya no existe o no es tuyo.
Obtén la revisión en el dispositivo de destino con inspect y envíala como expectedRevision. El host comprueba que no haya cambiado mientras preparabas la transferencia. Sin revisión solo se importa progreso si aún no existe.
Se reemplaza el conjunto completo: también se eliminan los archivos de progreso ausentes del paquete. Explica la sustitución al usuario y resuelve los conflictos. Si ya existe el juego con contenido diferente, se rechaza la importación sin sobrescribirlo.
\nnelkano-transfer/1 es un ZIP de datos con manifest.json y data/. Es independiente del paquete ejecutable .nelkmod. Conserva el gameId original y verifica la identidad del sistema, la entrada y el índice de archivos con tamaños y hashes.
Los juegos incluyen ROM, disco y pistas o proyecto completo, también sus directorios vacíos. El progreso incluye slots 0–6, capturas, batería/SRAM, carátula, archivos nativos por juego y Save de RGSS. Conserva los requisitos de módulos y autores de los guardados. Los datos privados de otros módulos quedan fuera.
Inspeccionar, preparar una exportación y publicar una importación requieren la sesión cerrada. Puedes recibir bloques o leer una exportación ya preparada mientras se usa la app. Tras una interrupción, el host completa o revierte la publicación antes de abrir otra partida.
La transferencia conserva bytes; no convierte estados entre motores. El destino necesita un formato compatible y algunos guardados internos dependen de la plataforma o versión. Consulta la inspección y el manifiesto. Los guardados MV/MZ de WebView quedan fuera. Los paquetes sintéticos de Studio solo se importan en Studio.
\nEl espacio y la velocidad dependen del dispositivo. Las transferencias largas tienen su propio límite de comunicación entre procesos; no se sujetan al de cinco segundos del código JavaScript.
\nhost.media.capabilities() para saber si la sesión entrega imagen, audio y captura CPU o de superficie.capture({session,screen?,region?,format?}) para capturar en PNG o JPEG, con resolución completa o recorte.read({id,offset,length}).release({id}).startRecording({session,fps?,maxSeconds?}), recording({id}) y stopRecording({id}) graban un AVI con MJPEG y PCM si el motor entrega audio. Los límites son 30 fps, 300 segundos y 1 GiB. export({id}) abre el selector de documentos para guardarlo y remove({id}) lo descarta.
Se graba el juego, sin escritorio, micrófono ni cámara. Pasar al fondo termina la grabación; revocar el módulo elimina sus recursos. Cada resultado conserva el permiso y la generación de sesión con los que se creó.
\nruntime.overlay admite textos de hasta 4096 caracteres. Puedes indicar textWidth en píxeles del juego, fontSize de 8 a 48 sp, maxLines de 1 a 16 y textColor/backgroundColor con formato #AARRGGBB. Omitir estos campos conserva la presentación anterior.
host.translation.capabilities() para conocer los formatos y proveedores.projects() recupera los proyectos de tu módulo, también tras reiniciar la app.analyze({gameId}). Usa job({jobId}) para seguirlo o cancel({jobId}) para cancelarlo.entries({projectId,offset?,limit?}) y guarda ediciones con update({projectId,resourceId,textId,translation,expectedRevision}).translate({projectId,provider,sourceLanguage,targetLanguage,limit?}) prepara un borrador automático. También admite traducir {text,provider,sourceLanguage,targetLanguage,context?} sin crear un proyecto. Con la partida cerrada, build({projectId,title?,allowPartial?}) reconstruye y registra una copia independiente del juego. remove({projectId}) elimina el proyecto privado.
Se admiten los formatos de texto reconocidos de GBA/NDS. Android utiliza ML Kit y descarga los modelos al solicitarlos. Escritorio permite analizar, editar y reconstruir; puedes incorporar traducciones de un servicio externo mediante update, pero no incluye traducción automática local.
Esta API no incluye OCR. Comprueba el espacio disponible, las fuentes y la maquetación en el juego reconstruido.
\nDeclara graphics.shaders y consulta host.graphics.capabilities({session}). shader({session,id,source,uniforms?}) aplica el efecto y devuelve {id,revision}; removeShader({session,id}) devuelve {removed} al retirarlo.
La fuente SkSL/AGSL utiliza uniform shader content, uniform float2 resolution y half4 main(float2 p). Los uniforms adicionales deben ser floats finitos. Se admite un efecto y propietario por sesión, hasta 16 KiB de fuente y 16 uniforms adicionales, sin bucles for, while o do.
El shader solo filtra los píxeles del juego. En Android requiere API 33 y una salida CPU; en escritorio utiliza Skia. Las superficies nativas separadas no ofrecen ese postprocesamiento. Las capturas conservan la imagen original del motor. Cerrar la sesión o revocar el módulo retira el efecto.
\nCon graphics.options, llama a host.graphics.options({session,resolutionScale}); devuelve {resolutionScale}. GameCube admite 1×, 2× y 4× en Android y escritorio. Se vuelven a dibujar las primitivas, conservando la memoria y los estados que utiliza el juego.
La superficie máxima es 2560×2112, con hasta dos copias visuales escaladas de 720×576. Otros tamaños mantienen su salida nativa. La imagen de mayor resolución solo se muestra si coincide con el framebuffer que presenta el juego y la CPU no lo ha modificado.
Activar escala o reemplazos en GameCube desactiva Vulkan y utiliza el rasterizador software. Al retirarlos puede recuperar la selección anterior. Prueba el rendimiento y la imagen en cada juego.
\ngraphics.textures permite reemplazos PNG en GameCube, PS1 y PSP. Se conservan la VRAM y las lecturas originales del juego. textureIds({session,offset?,limit?}) devuelve {items:[{textureId,width,height}],total,offset}. La observación empieza al consultar y conserva hasta 512 identidades SHA-256 basadas en formato, dimensiones, datos y paleta.
PS1 y PSP anuncian resolución 1×: un reemplazo de textura no aumenta la resolución de la geometría.
\nbeginTexture({session,textureId,width,height,size,sha256}).writeTexture({id,offset,dataBase64}).commitTexture({id}); el host verifica hash y dimensiones.textures({session}) lista tus reemplazos y removeTexture({session,textureId}) los retira. Límites: 2048×2048, 16 MiB por PNG, bloques de 64 KiB, 64 reemplazos y 128 MiB de píxeles en el banco del motor. Las cargas caducan a los diez minutos. Otro módulo no puede sustituir un recurso activo y no se genera una pirámide mip HD. Revocar el módulo o cerrar la sesión retira los recursos.
Declara media.microphone. Consulta host.microphone.capabilities(), inicia con start({sampleRate?,blockMs?,maxSeconds?}), recoge bloques con read({id,maxBlocks?}) y termina con stop({id}). Android solicita RECORD_AUDIO; escritorio utiliza los permisos de audio del sistema.
El audio es PCM16LE mono, a 16/24/48 kHz, con bloques de 20/40/100 ms en Base64 y número de secuencia. Se admite una captura activa y hasta cinco minutos. Lee a tiempo: droppedBlocks indica los bloques perdidos.
Pasar al fondo, revocar el permiso o cerrar cancela la captura y las lecturas pendientes. El reconocimiento de voz debe implementarlo tu módulo.
\nDeclara audio.dsp y consulta host.audioDsp.capabilities({session}). list({session}) devuelve tus cadenas de filtros. set({session,id,expectedRevision,sampleRate,stages}) crea o actualiza una cadena comprobando expectedRevision.
Las etapas admitidas son {kind:'gain',gain}, {kind:'biquad',b0,b1,b2,a1,a2} y {kind:'fir',coefficients}. La respuesta indica si se aplicó el cambio, su revisión y la cadena resultante. remove({session,id,expectedRevision}) la retira. El host comprueba valores finitos, estabilidad, coste y saturación PCM16.
Se admiten cuatro cadenas por propietario, dieciséis globales y filtros FIR de hasta 64 coeficientes. Se aplican por propietario e ID. El historial del filtro se reinicia al pausar, cambiar de generación o modificar la configuración; una frecuencia distinta de la declarada omite la cadena.
Solo se filtra el PCM del motor antes de reproducirlo. Los sonidos por órdenes, películas, WebAudio y beep quedan fuera. Grabaciones y observadores reciben el PCM original.
\nDeclara emulation.timeline para utilizar host.timeline. Consulta capabilities({session}): el motor debe ofrecer un estado completo, avance exacto por fotograma y ausencia de efectos externos. La integración inicial es CHIP-8. Un único propietario controla el historial y las repeticiones de la sesión.
configure({session,historyFrames?,historyBytes?,runaheadFrames?,rewinding?}) configura el historial y status({session}) consulta su posición, pausa y actividad. rewind({session,frames}) retrocede y pausa; rewinding:true mantiene el rebobinado. Runahead admite 0–2 fotogramas especulativos: presenta vídeo adelantado, mantiene el audio confirmado y restaura el estado confirmado.
step({session,frames?,inputs?,commit?}) necesita la partida pausada y admite hasta 120 fotogramas. Cada entrada contiene keys y, opcionalmente, touch. Sin entradas se usa una neutra; una entrada única se repite. commit:false restaura el estado al terminar, sin publicar imagen o audio especulativos. Si esa restauración falla, la sesión queda no disponible.
startRecording({session}) inicia una grabación, stopRecording({session}) la termina y recording({session,id?,offset?,limit?}) permite leerla por páginas. Incluye las entradas efectivas físicas y de módulos y, cuando está disponible, el hash del estado.
replay({session,id,fromFrame?,toFrame?}) reproduce las entradas y pausa al terminar. seek({session,id?,frame}) reconstruye una posición sin mostrar resultados intermedios. Se registra por fotogramas, sin tiempos inferiores a uno. Reiniciar, cargar un estado externo, cerrar o revocar termina el controlador. release({session}) libera sus datos.
export({session,id?}) devuelve {id,format:'nelkano-replay/1',size,sha256}. Lee los bloques Base64 con read({id,offset,length}). Para importar, utiliza beginImport({session,size,sha256}), write({id,offset,dataBase64}) y commit({session,id}); abort({id}) cancela.
El JSON editable contiene formatVersion:1, coreFormat, romSha256, firstFrame, un estado inicial opaco y las entradas por fotograma. En un editor TAS puedes modificar entradas y retirar los stateSha256 posteriores que hayan dejado de ser válidos. El host verifica ROM, formato, hash y estado inicial antes de restaurar.
Límites: 3600 estados y 64 MiB de historial; dos grabaciones privadas de hasta 36 000 fotogramas y 8 MiB cada una. Una repetición exportada admite 16 MiB y bloques de 64 KiB. Hay dos operaciones abiertas por módulo y ocho globales, con caducidad tras diez minutos sin actividad. La duración del historial depende del tamaño de los estados y del rendimiento.
\nDeclara audio.mix para utilizar host.audioMix. Consulta capabilities({session}) para conocer el formato PCM16LE, la frecuencia, los canales y el reloj {frame,epoch,paused}. El frame es la referencia publicada por el host, no necesariamente el VBlank físico del motor. El audio se mezcla antes de los filtros DSP y la reproducción.
begin({session,size,sha256,sampleRate,channels}), write({id,offset,dataBase64}) y commit({id}). Su PCM16LE mono o estéreo debe tener la misma frecuencia y canales que el motor; no hay remuestreo automático.play({session,id,atFrame?,gain?,originalGain?}). Devuelve playbackId y la frontera elegida. Puedes mezclarlo con el original o silenciar este durante el clip.status({session}) o detén las reproducciones con stop({session,playbackId?}).remove({id}) descarta una carga o clip y sus reproducciones.Se admiten 16 MiB por clip, 32 MiB por propietario, 64 MiB globales, ocho reproducciones programadas y bloques de 64 KiB. Los recursos pertenecen a la sesión y caducan tras diez minutos sin actividad.
Pausar, restaurar, cambiar de generación o formato, pasar al fondo o revocar cancela las reproducciones. Capturas, grabaciones y observadores conservan el PCM original. No permite separar voces, música o efectos que el motor no entregue como pistas distintas; sonidos por órdenes, películas, WebAudio y beep quedan fuera.
\nDeclara media.camera y utiliza host.camera.capabilities(), list(), start, read y stop. Android solicita CAMERA; escritorio anuncia captura no disponible y Studio utiliza una imagen sintética.
start({cameraId,width?,height?,fps?,format?}). El valor predeterminado es JPEG a 640×480 y 5 fps; se admiten JPEG/PNG hasta 1280×720 y 15 fps. Comprueba el tamaño real devuelto.read({id}) fija una instantánea y devuelve un frame o null.read({id,frameId,offset,length}) en bloques de hasta 64 KiB, conservando el mismo frameId durante toda la lectura.Se admite una captura activa, dos instantáneas por captura y hasta 4 MiB por imagen.
\nConsulta capabilities({session}) para conocer los puertos. deliver({id,session,port}) necesita además emulation.input y envía la última imagen al puerto compatible.
La integración inicial es la cámara emulada de 3DS: cam1 y cam2 convierten a RGB565/YUYV con el tamaño solicitado por el juego. La imagen externa no se guarda dentro de sus estados. NDS normal no anuncia cámara; la óptica, calibración estéreo y sincronización física de 3DS son parciales.
stop({id}), pasar al fondo o revocar el módulo cierra la captura y retira entregas y solicitudes pendientes.
Consulta host.engines.capabilities(). list({gameId}) o list({systemId}) lista los proveedores, identidad, versión, selección y compatibilidad de guardados.
select({gameId,engineId}) elige el motor de un juego; select({systemId,engineId}), el de un sistema. Indica solo uno de los dos. engineId null recupera el predeterminado. La elección se aplica al volver a abrir: una partida en marcha conserva su motor.
controls({session}) describe los puertos y controles. input({session,port,control,value}) envía valores dentro de sus rangos, incluidos ejes y gatillos.options({session}) devuelve el esquema y los valores. configure aplica opciones o guarda las de la próxima apertura por engineId, respetando tipos, rangos y requisitos de reinicio.resources({engineId,gameId?}) describe los archivos o BIOS necesarios. importResource abre el selector del host sin revelar rutas privadas.importGame({engineId,systemId}) abre el selector y vincula el juego importado al motor. Requiere library.transfer y resources.documents. Indicar systemId resuelve extensiones ambiguas, como ISO.media({session}) y changeMedia({session,slot,contentId?}) consultan y cambian los discos o medios anunciados.Cada operación exige sus permisos de lectura, control, entrada o recursos.
\nLos estados manuales admiten hasta 128 MiB y viajan en bloques de 64 KiB. El puerto timeline tiene un límite independiente de 16 MiB. Los estados y el progreso persistente utilizan identificadores de compatibilidad distintos y un espacio de almacenamiento asociado al motor.
Coincidir en el juego no permite cargar el estado de otro motor. Adapta la VFS del core para utilizar los recursos autorizados y el almacenamiento privado del host: escribir solo en su carpeta temporal no conserva el progreso.
\nLa ABI C versionada comprueba que el descriptor corresponda al binario compilado. Memoria, reglas, observación, texturas, resolución, cámara, medios y timeline deben declararse e implementarse con sus callbacks. Si faltan, esas capacidades permanecen no disponibles.
El puente opcional utiliza métodos JSON acotados y bloques para estados e imágenes. Poder ejecutar una ROM o guardar estados no implica admitir escritura de memoria o rebobinado determinista. El ejemplo de GPU no anuncia esos puertos.
El motor entrega PCM al transporte de audio y puede utilizar superficies GPU separadas. Las capturas compuestas requieren su implementación en el adaptador. Consulta las capacidades concretas: una salida GPU no habilita automáticamente shaders, capturas u otras operaciones gráficas.
\n"},{"id":"de520020-2026-4000-8000-000000000021","language":"es","title":"Modificar un juego","path":"/es/sdk-de-nelkano/modificar-juego","content":"Usa host.gameMod para leer datos de una partida y cambiar su comportamiento. Tu módulo debe conocer el juego: qué representan sus datos, dónde están y cuándo es seguro modificarlos.
GBA admite lectura, escritura, valores numéricos, observaciones y reglas en Android y Windows/Linux. Studio ofrece memoria de prueba. En cualquier motor, consulta primero las capacidades de la sesión.
\nDeclara en capabilities los permisos de las operaciones que uses. Los ejemplos de este capítulo utilizan:
\"capabilities\": [\n \"emulation.game-mod\", \"emulation.read\",\n \"emulation.memory.read\", \"emulation.memory.write\", \"runtime.events\"\n]emulation.game-mod identifica este contrato; un host antiguo rechaza el paquete. Cada operación necesita además sus permisos:
emulation.read.emulation.memory.read.emulation.memory.write.const active = await host.emulation.snapshot();\nif (active) {\n const support = await host.gameMod.capabilities(active.session);\n console.log(support.systemId, support.spaces, support.frameRules);\n}Revisa estos campos de la respuesta antes de operar:
Un core sin acceso a memoria devuelve espacios vacíos, funciones de memoria en false y límites en cero. Comprueba input, saveRequirements y newGame por separado: pueden tener otra disponibilidad.
\nEn GBA, el espacio cpu utiliza direcciones absolutas de 32 bits y orden little endian:
Cada operación debe quedar dentro de una región anunciada.
Las direcciones del bus ROM incluyen sus espejos de memoria; no son offsets del archivo. Para leer el archivo original utiliza host.gameRuntime.rom. La inspección conserva el estado del cartucho y de la comunicación serie.
cpu no permite escribir en IO ni en su bus ROM. Para cambiar el cartucho cargado, utiliza el espacio rom descrito más abajo.
\nEl ejemplo usa una ROM propia que reserva 0x0203FFF0 como byte de prueba. En otro juego debes localizar una dirección adecuada antes de escribir.
async function changeScratchByte(host, session) {\n const support = await host.gameMod.capabilities(session);\n if (!support.memoryRead || !support.atomicWrite) {\n throw new Error(\"Este core no permite esta modificación.\");\n }\n const address = 0x0203FFF0;\n const current = await host.gameMod.read(session, {\n ranges: [{space: \"cpu\", address, length: 1}]\n });\n return host.gameMod.write(session, {\n writes: [{space: \"cpu\", address,\n expected: current.ranges[0].data, data: \"AQ==\"}]\n });\n}AQ== representa un byte con valor 1.Antes de escribir, el host compara todos los expected. Si alguno ha cambiado, devuelve {applied:false, conflictIndex} con el primer conflicto, sin aplicar el lote. Si coinciden, devuelve {applied:true}.
Ante un conflicto, decide si debes volver a leer. Repetir la escritura sin revisar los datos puede sobrescribir un cambio del juego.
\nreadValues admite u8, i8, u16, i16, u32, i32, f32 y f64. Cada entrada lleva space, address y type; endian puede ser little o big y usa por defecto el orden del espacio.
La respuesta incluye value, data Base64 y el endian efectivo. Un float no finito devuelve value:null y conserva data. Utiliza read/write de bytes para comparar bits exactos, NaN, infinito o cero con signo.
\nconst current = await host.gameMod.readValues(session, {\n values: [{space: \"cpu\", address: 0x0203FFF0, type: \"u16\"}]\n});\nconst previous = current.values[0].value;\nconst result = await host.gameMod.writeValues(session, {\n writes: [{space: \"cpu\", address: 0x0203FFF0, type: \"u16\",\n expected: previous, value: (previous + 1) & 65535}]\n});Este ejemplo necesita dos bytes reservados por tu ROM. writeValues valida y convierte el lote completo antes de escribir:
En hosts anteriores, comprueba que existan readValues y writeValues.
\nobserve necesita emulation.game-mod, emulation.memory.read y runtime.events. Comprueba memoryObserve, maxWatches, maxWatchBytes y maxWatchRanges.
El adaptador toma muestras y el host agrupa los avisos; tu JavaScript no se ejecuta en cada frame.
\nawait host.gameMod.observe(session, {\n id: \"scratch-value\", everyFrames: 4,\n ranges: [{space: \"cpu\", address: 0x0203FFF0, length: 2}]\n});\n// Dentro de onEvent(event):\nif (event.type === \"game-memory-changed\") {\n console.log(event.watchId, event.changes, event.ranges);\n}\n// Para dejar de observar:\nawait host.gameMod.unobserve(session, \"scratch-value\");La primera muestra se toma al registrar. everyFrames admite 1–600, con valor inicial 1. Las siguientes muestras llegan después de avanzar el juego; pausar o capturar una imagen no cuenta.
Reiniciar o cargar dentro de la misma sesión conserva la observación. La comparación continúa cuando el juego vuelve a avanzar.
game-memory-changed entrega session, watchId, sequence, frame, changes y ranges. Cada rango contiene space, address, before y data en Base64.
Solo hay un aviso pendiente por observación: conserva el primer before, el último data y el número de muestras con cambios. Si un valor cambia y vuelve al inicial, changes puede ser mayor que cero aunque before y data coincidan. Los cambios entre muestras pueden pasar inadvertidos.
En GBA, todos los módulos de una sesión comparten 16 observaciones, 32 rangos y 16 KiB observados. Observar no reserva zonas de escritura. Retirar un módulo que solo observa mantiene abierta la partida.
\nSolicita emulation.game-mod y emulation.memory.read. Comprueba memorySearch y los límites maxSearches, maxScanBytes, maxSearchBytes y maxSearchResults.
GBA y Studio admiten por sesión hasta cuatro búsquedas, 256 KiB por búsqueda y 1 MiB de capturas en total. Cada página devuelve hasta 128 resultados. Otros motores, incluidos los V2 con un puerto propio, pueden anunciar límites distintos.
\nconst search = await host.gameMod.searchStart(session, {\n space: \"cpu\", address: 0x02000000, length: 262144,\n type: \"u16\", mode: \"unknown\"\n});\n// Después de cambiar algo en el juego:\nconst refined = await host.gameMod.searchRefine(session, {\n id: search.id, mode: \"increased\"\n});\nconst page = await host.gameMod.searchRead(session, {\n id: search.id, offset: 0, limit: 32\n});\nawait host.gameMod.searchClose(session, {id: search.id});Configura searchStart con:
El rango completo debe caber en una región legible.
searchRefine conserva los candidatos que cumplen la comparación y actualiza la captura de referencia al terminar:
equal compara números y redondea f32 a su representación. Los valores no finitos se entregan como null y no coinciden con uno finito.
\nLas respuestas incluyen id, matchCount, scannedBytes, revision, space, address, length, type, endian, alignment y paged. searchRead añade offset, results y hasMore.
Cada resultado contiene dirección, tipo, orden, value y data Base64 de la última captura. Consultar otra página no vuelve a leer el juego ni pierde los candidatos restantes.
Las capturas usan tramos de hasta 32 KiB. Si necesitas un instante coherente entre tramos, pausa el juego antes de capturar.
Las búsquedas pertenecen al módulo y autor que las creó. searchClose devuelve false si no encuentra una búsqueda propia. Retirar un módulo que solo busca conserva abierta la partida.
Cerrar o cambiar la sesión descarta las búsquedas. Reiniciar o cargar dentro de la misma sesión conserva la captura hasta la siguiente refinación.
\nLa escritura generada lee expected y comprueba el resultado. La observación requiere también runtime.events.
Cambiar valor de prueba modifica RAM sintética y respeta las zonas reservadas por módulos. Cerrar el explorador libera sus búsquedas; los valores se conservan hasta cerrar o restablecer la sesión.
El explorador no se conecta a partidas reales ni edita tus archivos automáticamente.
\ninstallRule registra una regla de la sesión. Antes de cada frame, el core comprueba sus condiciones y todos los expected; aplica el lote solo si coinciden. La regla se ejecuta junto al core, sin llamadas a JavaScript ni esperas de red, y se detiene mientras el juego está pausado.
En esta ROM propia, 0x0203FFF1 es una señal. Cuando vale 1 y el byte anterior vale 0, la regla escribe 2 en ese byte anterior:
await host.gameMod.installRule(session, {\n id: \"scratch-rule\",\n conditions: [{space: \"cpu\", address: 0x0203FFF1,\n expected: \"AQ==\"}],\n writes: [{space: \"cpu\", address: 0x0203FFF0,\n expected: \"AA==\", data: \"Ag==\"}]\n});{id}.const myRules = await host.gameMod.listRules(session);\nconst removed = await host.gameMod.removeRule(session, \"scratch-rule\");listRules devuelve tus reglas con id, conditions y writes. removeRule devuelve true si retira una regla propia y false si no existía. Un módulo no puede listar ni retirar las de otro, aunque compartan autor.
\nUtiliza los límites anunciados por el host de destino.
Escribir en una zona reservada por otro módulo devuelve modification-conflict. Retirar una regla detiene su ejecución, pero no libera las zonas reservadas hasta cerrar la sesión: todavía pueden conservar sus efectos.
El control de solapamientos incluye las escrituras de host.gameRuntime.patch. Los módulos que solo usan ese puerto anterior conservan su comportamiento al retirarse; el cierre de sesión descrito aquí se aplica a las nuevas escrituras o reglas de gameMod.
Cerrar la sesión elimina reglas y modificaciones activas; el archivo ROM original permanece intacto. Reiniciar o cargar un estado dentro de la misma sesión conserva las reglas y vuelve a comprobar conditions y expected.
Retirar una regla no restaura los bytes anteriores. Si un módulo ha modificado la sesión, desactivarlo, actualizarlo o perder su proceso cierra esa sesión, aunque ya hubiera retirado las reglas. Las referencias antiguas de sesión dejan de ser válidas.
Los efectos pueden quedar en los guardados habituales. Informa al usuario antes de modificar su progreso. Si cargar la partida exige tu módulo o empezar de cero, declara los requisitos de guardado explicados más abajo.
\nEn Studio, simulated:true permite probar el código y el contrato. Revisa permisos, expected incorrectos, rangos no disponibles, conflictos entre módulos, carga/reinicio, desactivación y cambio de sesión. Después prueba el paquete con una ROM propia en la app de destino.
Construye la interfaz con páginas y formularios del SDK. Ofrece las operaciones de memoria o ROM temporal que anuncie cada motor.
\nCon emulation.game-mod y emulation.input, llama a gameMod.input(session,{buttons:[{code,pressed}]}). Las pulsaciones del módulo se combinan con las del usuario y otros módulos; al desactivarlo se liberan solo las suyas.
Consulta capabilities y usa los códigos admitidos por el core. Studio simula las pulsaciones; este soporte se consulta por separado del acceso a memoria.
\nGBA ofrece el espacio rom desde el offset cero hasta la longitud real del cartucho. Admite lecturas, escrituras comprobadas, valores numéricos, búsquedas, observaciones y reglas. Un lote mixto RAM/ROM se aplica entero o no cambia nada.
Los cambios afectan al código o recursos de esa sesión. Al volver a abrir se lee el original. El bus ROM del espacio cpu sigue siendo de solo lectura.
const original = await host.gameMod.read(session, {ranges:[{space:\"rom\",address:offset,length:1}]});\nawait host.gameMod.write(session, {writes:[{space:\"rom\",address:offset,expected:original.ranges[0].data,data:nuevoByteBase64}]});Solicita emulation.game-mod y emulation.memory.read/write. Ten en cuenta:
await host.gameMod.configureSave({gameId,newGame:true});Llama a configureSave antes de abrir el juego y solicita emulation.game-mod. La llamada registra el módulo y su autor como requisitos del guardado. newGame es opcional y exige empezar una partida nueva.
Los datos se guardan en slots, autoguardado y batería habituales. Si falta el módulo o cambia su autor, la app rechaza la carga y conserva el archivo. Una partida anterior sin marca de nueva no cumple newGame, aunque tenga otra dependencia.
Para exigir una partida nueva consulta capabilities(session).newGame. Los cores incluidos que ofrecen ese contrato lo aplican; un motor sin soporte rechaza la apertura en vez de reutilizar progreso. Studio simula los metadatos, no una batería real.
Un pack sustituye archivos al abrir el juego y conserva el contenido original. Para prepararlo:
resources.packs y consulta host.resourcePacks.capabilities({gameId}).create({gameId,id,label}). Usa list({gameId?}) para consultar packId, revisión, estado y archivos.beginFile({packId,path,size,sha256}), envía bloques con write({id,offset,dataBase64}) y termina con commitFile({id}).readFile({packId,path,offset,length}) lee por bloques. Para quitar un archivo de un pack desactivado, usa removeFile({packId,path}).
enable({packId,enabled,expectedRevision}) y remove({packId,expectedRevision}) requieren la sesión cerrada y la revisión vigente. Para eliminar el pack, desactívalo primero.
El host comprueba rutas, tamaños, hashes y contenido base antes de aplicar las capas.
Al abrir el juego, el host crea una copia privada con las capas habilitadas y conserva el ID y el original. Las ordena por identidad del propietario y después por ID del pack.
Al revocar un módulo, sus capas dejan de aplicarse en la siguiente apertura. La sesión abierta conserva la copia con la que arrancó.
Los packs admiten sustituir una ROM completa o archivos de contenedores de discos de solo lectura. Debes preparar los recursos o la ROM reconstruida y comprobar las capacidades del formato.
RPG Maker no está admitido: sus guardados nativos no deben copiarse junto con los recursos.
Elige el servicio según lo que quieras cambiar:
host.resourcePacks: capas de archivos preparadas al abrir el juego. Cambia su selección con la sesión cerrada.host.graphics: opciones y texturas del core. graphics.textures reemplaza PNG por hash y graphics.options selecciona la resolución.GameCube admite raster host 1×/2×/4×. PS1, PSP y GameCube admiten reemplazos de texturas en Android/Desktop. Son cambios limitados a la sesión y se retiran al revocar el módulo; un pack de archivos no habilita texturas HD en cualquier core.
Consulta Emulación para formatos, límites y correspondencia XFB/VI.
"},{"id":"de520020-2026-4000-8000-000000000015","language":"es","title":"Amigos: cuenta, solicitudes y perfil","path":"/es/sdk-de-nelkano/amigos","content":"Amigos gestiona el acceso a la cuenta, las solicitudes y el perfil. Tu módulo puede abrir sus formularios, añadir acciones junto a los amigos o recibir avisos de cambios.
\n![\"Amigos](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-19-friends.webp\")
Puedes enviar, cancelar, aceptar y rechazar solicitudes, y eliminar amistades con confirmación. El rol no es editable y la foto es simulada. Las cuentas y amistades de Studio se reinician al cerrar el servidor de desarrollo: no se consulta nelkano.com ni se envían correos. Utiliza credenciales de prueba.
\nAbre Amigos desde Biblioteca o Guardados, o pulsa Iniciar sesión en Ajustes → General → CUENTA. Accede con tu cuenta de nelkano.com; si te registras, actívala desde el correo. Una vez dentro puedes gestionar amistades y editar el perfil con foto. El rol lo decide el servidor.
\nconst account = await host.account.snapshot();\nawait host.account.login({email, password});\nawait host.account.register({name, email, password,\n password_confirm: confirmation, terms: true});\nawait host.account.logout();Declara account.session. La identidad pública incluye uid, signedIn, nombre, correo, permiso friends y rol. El módulo define sus formularios y validaciones; los tokens los conserva la app.
\nconst account = await host.account.snapshot();\nconst response = await host.network.request({\n method: \"GET\", path: \"/api/nelkano/friends\",\n accountUid: account.uid\n});Declara network.account. La app comprueba la cuenta de la petición y devuelve status y body. Android realiza la petición autenticada; Studio devuelve datos ficticios. Para un servidor propio utiliza las conexiones externas y sus permisos.
const image = await host.resources.pickImage();\nif (!image.cancelled) {\n // Conserva image.resourceId hasta guardar el perfil.\n}Requiere resources.image. Recibes una referencia del host y, si está disponible, una vista previa. La imagen se publica al guardar el perfil con avatarResource en POST /api/nelkano/profile; elegirla no la publica.
Se admiten PNG, JPEG y WebP de hasta 4 MiB. La referencia pertenece al módulo y a la cuenta que la eligieron y caduca a los diez minutos. Las filas pueden mostrar avatar.url; Android descarga las imágenes de nelkano.com/sites/ y Studio utiliza una foto simulada.
\nAndroid cifra la sesión con Android Keystore, valida los permisos firmados y renueva los tokens. Cerrar sesión elimina la copia local e intenta revocarla en el servidor. Los tokens no llegan al módulo.
\nDeclara modules.hooks y añade a consumes el proveedor nelkano.friends, el nombre del gancho y la versión 1.0.0. Usa optional:false si tu módulo necesita Amigos activo.
\nawait host.hooks.contribute(\"nelkano.friends\", \"friend-actions\", \"invite\", {label: \"Invitar a mi mundo\", scope: \"friends\"});Implementa la acción en tu módulo: el ejemplo solo añade el botón de invitación. Las acciones se retiran al desactivarlo y se rechazan si la cuenta o la lista han cambiado.
\nconst data = await host.hooks.invoke(\"nelkano.friends\", \"friends-data\", \"refresh\", {});refresh consulta el servidor y requiere sesión. snapshot devuelve lo ya cargado: una lista vacía no confirma que se haya consultado el servidor.
La respuesta incluye revision, account y las listas friends, incoming y outgoing. Cada usuario tiene uid, name, statusText, avatarColor y avatarUrl. No se comparten correo, contraseña ni tokens.
\nawait host.hooks.contribute(\"nelkano.friends\", \"friends-events\", \"changes\", {});Amigos llama a onHook con operation changed y un value que incluye el snapshot y type: session-changed, friends-updated o profile-updated. Conserva esos datos; evita llamar de vuelta a Amigos dentro del mismo callback.
Son avisos de las operaciones del módulo, no presencia en tiempo real ni notificaciones push. Se admiten hasta 16 acciones y 8 receptores. El fallo de un receptor no interrumpe la operación principal.
\nEl ejemplo demuestra la llamada, sin crear un mundo ni enviar una invitación real. Se exporta por separado. Para conectar jugadores, consulta el capítulo Multijugador.
\nConsume account-access 1.0.0 de nelkano.friends:
El modal mantiene el contexto de la pantalla de origen. Utiliza kind:panel, layout:form, un ID estable por cuenta y dismissAction:close. Cerrar conserva sesión, búsqueda, pestaña y listas; cambiar de cuenta inicia un borrador nuevo.
\nLa búsqueda es global, por nombre o correo. Espera 350 ms tras escribir y necesita al menos dos caracteres. Las pestañas separan Amigos y Solicitudes; el contador muestra las recibidas pendientes y las enviadas tienen su propia sección. Eliminar amigo está en ⋮ y pide confirmación. La conexión entre jugadores se abre desde el modal de Multijugador.
"},{"id":"de520020-2026-4000-8000-000000000016","language":"es","title":"Mandos y segunda pantalla","path":"/es/sdk-de-nelkano/mandos-segunda-pantalla","content":"Reutiliza los formularios de Nelkano básicos para configurar mandos o conectar una segunda pantalla. Si necesitas una interfaz propia, el SDK también ofrece sus operaciones.
Desde el mismo formulario puedes restaurar las asignaciones del sistema o guardar y cargar perfiles con nombre.
Importar archivo y Exportar archivo abren el selector de documentos de Android o Desktop. El respaldo JSON incluye sistema, asignaciones, perfiles y máscaras PS1, hasta 96 KiB. También puedes usar Copiar / pegar asignaciones. Un respaldo inválido se rechaza sin sustituir la configuración.
Solicita input.gamepad. El puerto ofrece estas operaciones:
host.input.snapshot(): consultar dispositivos.configure(bindings, ps1Bindings?): aplicar asignaciones.capture(device?): esperar un botón durante un máximo de 30 segundos.settings(): abrir los ajustes Bluetooth del host.release(): liberar el control de las asignaciones.host.input.importProfile(): abrir un respaldo; devuelve state o cancelled.exportProfile(state): exportarlo; devuelve saved o cancelled.El usuario elige el documento. El módulo recibe los datos, sin rutas de archivos, y debe validar state antes de aplicarlo. Las asignaciones usan valores como KEY:96 o AXIS:0:POS.
Solo un módulo puede controlar las asignaciones a la vez. Al desactivarlo se liberan las teclas y se cancela cualquier captura pendiente.
Para usar configure y capture directamente, configura primero el mapa y captura después desde el mismo módulo. En la app, Nelkano básicos suele tener ese control: otro módulo recibe input-owner-busy si intenta sustituirlo. En ese caso utiliza su gancho gamepad, descrito más abajo.
settings() solicita los ajustes Bluetooth al sistema. En Linux puede ser necesario abrirlos manualmente.
![\"Asignación](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-13-controller.webp\")
Durante una partida de Nintendo DS o Nintendo 3DS, abre Pantallas → Segunda pantalla. También puedes entrar por Ajustes → General → Apariencia → Segunda pantalla.
Ambas/Superior/Inferior cambia la imagen del dispositivo principal. Al conectar se activa la pantalla completa una vez; puedes salir de ella con Pantalla completa sin desconectar el receptor. Intercambiar pantallas mantiene esa elección.
El formulario separa RECEPTOR, EMISOR y DISPOSITIVOS RECORDADOS. Cerrarlo conserva la conexión.
Cada partida empieza enviando la pantalla superior al receptor y mostrando la inferior en el dispositivo principal. Intercambiar pantallas invierte ese reparto durante la partida; al abrir otra se restablece. La entrada táctil del receptor corresponde a la pantalla inferior. El juego debe producir dos pantallas.
Solicita media.second-screen. El puerto incluye host.secondScreen.snapshot(), discover(), connect(id), disconnect(), receiver(enabled), pair(enabled), swap() y forget(id).
Para conectar utiliza el ID de un receptor descubierto; no se aceptan direcciones arbitrarias.
![\"Opciones](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-14-second-screen.webp\")
En consumes declara el proveedor nelkano.basics, el gancho gamepad o second-screen y la versión 1.0.0.
Invoca las operaciones con host.hooks.invoke(provider, hook, operation, value).
Studio simula el mando y el receptor. Importar un perfil devuelve cancelled; exportarlo simula el guardado sin escribir un archivo. Usa Copiar / pegar asignaciones para revisar el JSON y prueba Bluetooth y segunda pantalla en los dispositivos de destino.
Para emitir una partida desde Básicos, consulta Streaming.
Controles permite asignar botones de PSP y GameCube. El SDK conserva el perfil Switch para simulación y desarrollo; Switch queda excluido de las apps Android y Desktop. PSP separa cruceta y stick; GameCube, cruceta, stick principal y C-stick. Los ejes se asignan por direcciones con umbrales digitales: no hay inclinación proporcional ni presión progresiva de gatillos. Android lee eventos del sistema y Windows/Linux usa SDL.
La app permite navegar con mando en Android, Windows y Linux. Usa un mapa predeterminado o las reasignaciones reconocidas. Nelkano básicos gestiona las asignaciones de juego y los perfiles guardados.
En un campo select, aceptar abre la lista y vuelve a aceptar para elegir. Los selectores con pestañas tienen un botón por opción. Izquierda/derecha cambia los deslizadores de cinco en cinco; aceptar sobre un campo de texto permite editarlo. Los componentes del SDK reciben esta navegación automáticamente.
Solo el diálogo abierto recibe las acciones del mando. La app libera las pulsaciones del juego al abrir menús, pausar o perder el foco, y no transmite un botón mantenido al cerrar la ventana. Durante una captura, la pulsación sirve para asignar el botón.
En pantalla completa, el mando controla la partida. Fuera de ella, navega por la interfaz. CHIP-8 también recibe el mando en su vista normal.
Las plantillas del SDK utilizan el mismo catálogo y resolvedor que la app. Las asignaciones y los archivos de configuración existentes se conservan.
3DS convierte el stick a las direcciones admitidas por su adaptador. El perfil Switch se conserva para simulación y desarrollo del core PC, sin disponibilidad en las apps. Prueba el mando concreto y Steam Input en el dispositivo de destino; el visor de Studio solo utiliza entradas ficticias.
Multijugador viene incluido y ofrece conexiones de GB/GBC, GBA y NDS. La consola compartida PS1 es un prototipo técnico y no aparece en esos menús.
Si vas a usar host.sharedConsole, comprueba capabilities(session).supported. El adaptador real disponible es PS1 Android; Studio simula el contrato. El capítulo Multijugador detalla sus permisos, fragmentos y ganchos.
Mando Bluetooth y Segunda pantalla se abren sobre Ajustes. Cancelar al guardar/cargar un perfil o al cambiar el modo de segunda pantalla vuelve a su formulario principal. La × cierra el formulario sin borrar asignaciones ni interrumpir una conexión activa.
"},{"id":"de520020-2026-4000-8000-000000000017","language":"es","title":"Idioma y temas","path":"/es/sdk-de-nelkano/idioma-temas","content":"Tu módulo puede aportar un tema o un diccionario para la interfaz. Los usuarios los eligen en Ajustes → Idioma y tema, junto a los idiomas español/inglés y los temas Oscuro, Claro, Azul marino, Pizarra y Grafito.
El formulario muestra la selección guardada. Cambiar solo el idioma o el tema conserva la otra opción, tanto en Android como en Studio.
manifest.skins y solicita presentation.appearance.host.appearance.snapshot() y aplica uno con host.appearance.apply(). Ambas llamadas necesitan también appearance.locale.Utiliza un ID devuelto por snapshot(): contiene autor, módulo y nombre del tema. No lo construyas a mano.
Para ofrecer un idioma, solicita appearance.locale y llama a host.appearance.apply({language, skinId, strings}). En strings, cada clave es un texto original en español y cada valor, su traducción.
El proveedor nelkano.appearance publica tres ganchos, versión 1.0.0:
Los datos deben caber en los límites generales de los ganchos. Para un diccionario grande, aplica el idioma desde tu módulo mediante appearance.
Apariencia cambia los colores y textos de los componentes compartidos. Para diseñar la interfaz de tu módulo utiliza los componentes del SDK; un tema no añade vistas Android ni instala un motor nativo V2.
Studio aplica temas e idiomas al visor. En la app, Apariencia es esencial y recupera la elección al iniciar. Un tema de otro módulo está disponible mientras su proveedor siga instalado y activo.
"},{"id":"de520020-2026-4000-8000-000000000018","language":"es","title":"Parches de juegos","path":"/es/sdk-de-nelkano/parches","content":"El módulo Parches está temporalmente excluido de los paquetes cargados en Android y escritorio, pendiente de revisión. La app no muestra Aplicar parche ni registra el proveedor nelkano.patches; tampoco carga paquetes residuales ni admite importar manualmente ese módulo mientras siga excluido. Sus fuentes, el motor y host.patches se conservan: no se elimina la API ni se borran juegos, copias o guardados existentes. Studio conserva un ejemplo simulado; no acredita disponibilidad del módulo en la app.
El servicio del SDK crea una copia modificada de un juego GBA o NDS y conserva la ROM original.
resources.patch.host.patches.pick(). Devuelve resourceId y name, o cancelled.host.patches.apply({resourceId, gameId, title}). title es opcional.resourceId pertenece al módulo que abrió el selector, caduca a los diez minutos y se consume al aplicar el parche correctamente. No es una ruta ni puede utilizarlo otro módulo.
El resultado contiene gameId y title del juego creado. La copia conserva el sistema y la extensión del original; sin otro título, utiliza el original seguido de «(parche)». Repetir el mismo resultado conserva una sola identidad en la biblioteca. Si falla, no se publica un juego. Se comprueba la cabecera del resultado, pero un IPS no garantiza que hayas elegido la ROM correcta: utiliza la versión exacta que pide su autor.
El código del ejemplo Parches conserva el gancho apply-patch de nelkano.patches, versión 1.0.0: formats consulta los formatos y sistemas; apply recibe gameId y title opcional, abre su propio selector y devuelve el juego creado o cancelled. No acepta referencias de otro módulo. Este proveedor no se carga en la app actual: no lo declares como dependencia disponible.
Las operaciones de Android y Desktop aplican el parche al archivo. Studio simula el formulario y la selección. Si tu módulo utiliza este servicio, comprueba el resultado con una ROM y un parche reales en cada plataforma; una copia creada correctamente no acredita jugabilidad.
"},{"id":"de520020-2026-4000-8000-000000000019","language":"es","title":"Streaming de la partida","path":"/es/sdk-de-nelkano/streaming","content":"Streaming permite ver la partida en la web. La cuenta necesita el permiso de streaming del servidor.
Android pide confirmar el envío de vídeo y audio del juego por WebRTC y su respaldo HTTP a https://nelkano.com. El micrófono no se utiliza. Activar o instalar un módulo no inicia una emisión.
![\"Confirmación](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-17-streaming-confirmation.webp\")
El panel también muestra el identificador, PIN y dirección devueltos por el servicio. El visor web actual sigue exigiendo iniciar sesión con tu cuenta.
Actualizar consulta el estado y Detener emisión termina la conexión. La emisión también termina al cerrar/cambiar el juego, cambiar de cuenta o retirar el módulo emisor. Android la detiene al pasar a segundo plano; Desktop tiene su propia gestión del foco.
Básicos propone 854 × 480, 30 fps y 1800 kbps; puedes cambiarlos antes de empezar. En Android, los contadores indican fotogramas y bloques de audio enviados, no si el receptor los ha reproducido.
Solicita media.streaming. Solo puede emitir un módulo a la vez:
const state = await host.streaming.snapshot();\ntry {\n const result = await host.streaming.start({\n width: 854, height: 480, fps: 30, videoBitrateKbps: 1800\n });\n if (result.cancelled) console.log(\"Emisión cancelada\");\n} catch (error) {\n console.log(\"No se inició la emisión:\", error instanceof Error ? error.message : String(error));\n}\n// Más tarde, para terminar una emisión iniciada por este módulo:\nawait host.streaming.stop();Si el usuario cancela, Android devuelve {cancelled:true} y Desktop rechaza la promesa. Contempla ambos casos, además de los errores de inicio, al mostrar el resultado.
El formulario de Básicos admite ancho 160–1920, alto 120–1080, 10–60 fps y 200–12000 kbps. El puerto directo valida los límites del host, que pueden ser distintos.
snapshot() devuelve estado, mensaje, destino y configuración. Una emisión creada incluye sessionId, pin y joinUri; Android puede añadir stats y relay. Las credenciales permanecen en el host.
Declara en consumes el proveedor nelkano.basics, gancho streaming, versión 1.0.0, y solicita modules.hooks. Ofrece snapshot, configure, start y stop:
await host.hooks.invoke('nelkano.basics', 'streaming', 'configure', {\n width: 854, height: 480, fps: 30, videoBitrateKbps: 1800\n});\nawait host.hooks.invoke('nelkano.basics', 'streaming', 'start', {});configure guarda las opciones en Básicos. start solicita igualmente la confirmación del usuario.
Studio simula la cuenta, sesión y receptor para probar el formulario y los ganchos. Comprueba imagen, sonido, cancelación, cortes de red y cambios de sesión con una emisión real en la plataforma de destino. Android y Desktop solicitan confirmación al empezar; aceptar los permisos de instalación no la sustituye.
relay.Android conserva el identificador público de la emisión y la cuenta que la inició, sin PIN ni tokens. Antes de emitir de nuevo con esa cuenta intenta cerrar las emisiones anteriores; si no llega al servidor, guarda el registro para reintentar.
La app no reanuda la emisión automáticamente ni cierra las de otras cuentas. Detener libera la captura y WebRTC; el cierre en el servidor se completa en segundo plano.
"},{"id":"de520020-2026-4000-8000-000000000020","language":"es","title":"Multijugador: GB/GBC, GBA, NDS y módulos custom","path":"/es/sdk-de-nelkano/online-gba","content":"Multijugador y Amigos vienen incluidos con Nelkano. Para conectar jugadores, abre un juego GB/GBC, GBA o NDS y entra en Multijugador desde los ajustes de la partida o su botón de sistema. Cada motor y adaptador determina los modos disponibles.
El Editor de controles permite mover, escalar u ocultar ese botón. Para añadir un modo de conexión, utiliza los ganchos de Multijugador y comprueba primero las capacidades de la sesión.
\nLas acciones de conexión están al pie. Desconectar aparece si hay una conexión o una recuperación pendiente; la cruz superior cierra el panel.
\n![\"Crear](\"/modules/custom/nelkano_home/assets/docs/sdk/20261018/app-18-multiplayer.webp\")
Conectar con cable link requiere dos jugadores con la misma ROM exacta. Conectad primero y entrad después al multijugador del propio juego.
La sesión es temporal: al terminar se recupera la partida anterior y se descarta el progreso de la conexión.
El host negocia WebRTC entre cuentas amigas. La conexión entre redes depende de ICE, NAT y las redes de ambos jugadores. Studio simula el flujo.
\nComprueba que exista host.localLink y que capabilities(session) devuelva supported:true.
capabilities incluye systemId, players, protocol, stateFormat, maxStateBytes y transport:webrtc-friends. host y join por código ya no forman parte del puerto público. JavaScript no recibe rutas privadas, estados completos, credenciales ni handles nativos.
connect devuelve phase:connecting mientras prepara el cable. Consulta status mediante ticks de runtime, incluso con el panel cerrado:
Cada llamada valida propietario, permisos y referencia id/generation. La negociación comprueba cuenta, amistad, roles, ROM, sesión y nonce; cada copia inicial admite hasta 4 MiB. Studio simula el contrato sin conexiones físicas.
Crea un módulo que consuma game-adapters 1.0.0 de nelkano.multiplayer y registre el adaptador:
await host.hooks.contribute(\"nelkano.multiplayer\",\n \"game-adapters\", \"mi-juego\", {label: \"Mi juego\"});Implementa estas operaciones en onHook:
Consume sessions para consultar snapshot, conectar con {friendUid, role}, desconectar o enviar con send y {type, payload, channel?}. Multijugador añade identidad de sesión y secuencia.
channel sustituye mensajes pendientes del mismo canal, útil para posiciones. Omítelo cuando debas conservar cada mensaje.
Contribuye a events para recibir changed con type, state, sessionId, peers y packets. No llames de vuelta al proveedor dentro del callback: crearías un ciclo. Amigos proporciona la cuenta y su lista; el host conserva la conexión autenticada y los tokens.
Contribuye a connection-actions 1.0.0 con strategy:presence, adapterId, systems, minPlayers y maxPlayers. La acción y el adaptador deben pertenecer al mismo módulo y autor.
Las salas de presencia admiten de dos a cuatro participantes, según el adaptador. El anfitrión selecciona a sus amigos y cada invitado elige al anfitrión. Cable link sigue limitado a dos jugadores.
sessions.connect acepta friendUids. Si usas host.online.connect directamente como anfitrión en ONLINE_LAYER, puedes indicar hasta tres destinatarios. send acepta peerUid para elegir uno.
Cada enlace tiene su sessionId. El protocolo de presencia utiliza además el identificador y los miembros de la sala.
En presencia, la partida sigue avanzando desde online.connect hasta desconectar, fallar o retirar el módulo. El host aplica esta regla sin otro permiso. Durante Online se evita el apagado por inactividad; en Android, girar el dispositivo conserva pantalla y sesión.
El panel muestra los errores de red. Los registros de transporte guardan contadores y motivos de cierre, sin contraseñas, tokens ni cuerpos de paquetes. Puedes añadir un motivo corto con online.disconnect({reason: \"local-disconnect\"}).
El estado se muestra al principio del panel para anfitrión e invitado:
Una sesión HTTP abierta no confirma que el otro jugador esté activo.
Multijugador envía una señal de vida cada segundo y medio, también durante transiciones en las que el adaptador no puede leer la presencia. Cada remitente tiene su propia secuencia para que un jugador nuevo no herede la del anterior.
Reconectar capa online cierra la conexión y abre otra; el amigo debe entrar de nuevo. sessions.connect reutiliza una conexión con la misma configuración, por lo que la reconexión explícita se hace desde ese botón.
sessions.snapshot incluye state, transportState, peerActive y peerLastSeenAt. Los avisos events entregan el mismo estado comprobado.
.\\nelkmod.cmd example multiplayer-adapter C:/mis-modulos/mi-adaptadorEl ejemplo usa un CHIP-8 ficticio para enseñar game-adapters, sessions y events. No sincroniza la CPU ni convierte un juego en online por sí solo.
Cada adaptador define su protocolo mediante los ganchos de nelkano.multiplayer. Un gancho no añade soporte de CPU, cable o consola compartida a un core que no lo anuncie.
host.sharedConsole es opcional y no añade un modo al menú. Con emulation.read, consulta capabilities(session): devuelve supported, sistema, tamaño/formato de tarjetas, códigos de entrada y límites.
El adaptador disponible es PS1 Android; Studio lo simula. Comprueba supported antes de usarlo.
Para compartir tarjetas, solicita emulation.handoff:
El adaptador valida el formato antes de montarlo. Tu módulo define el protocolo y los juegos compatibles.
Con emulation.input puedes llamar a input(session,{sequence,keys}), controller(session,{enabled,message}) y controllerEvents(session).
Cada llamada comprueba permisos, propietario y generación.
Esta estrategia admite online.connect con continuous:false, una política local que no se envía al servidor. GBA mantiene continuous:true por defecto. La tarjeta temporal conserva intactos los guardados permanentes de ambos jugadores.
"}]}