NRF SDK 0.9

Lire et agir

Créer des signaux avec un ticket de construction

Préparer une action confirmée, conserver son ticket et inspecter un résultat en cours ou partiel.

Préparer, soumettre une fois, puis inspecter

La construction JVM est expérimentale et nécessite la fonctionnalité de construction du SDK. Votre application calcule son plan, le présente puis reçoit une confirmation explicite avant de créer. Contrairement à l’API d’outil Native, Game.Construction ne fournit pas de méthode de prévisualisation : elle expose prepare, create, poll et undo.

  • Obtenez le signal source et les voies dans la partie courante. Après un changement de partie ou de plan, abandonnez le ticket et faites confirmer un nouveau plan.
  • Le lot contient de 1 à 64 positions distinctes. Chaque fraction est finie et strictement entre 0 et 1 ; chaque sens vaut +1 ou −1.
  • prepare fournit un ticket lié à cette partie et à son éditeur. Conservez tout token non nul avant de soumettre create ; attendez READY.
  • Après la soumission, poll observe le résultat. Ne rappelez pas create pour attendre la fin.
Classe JVM : un plan déjà validé et confirmé, sans boucle d’attente bloquante
package wiki.constructiontickets

import fr.nimby.sdk.ConstructionResult
import fr.nimby.sdk.ConstructionState
import fr.nimby.sdk.Game
import fr.nimby.sdk.Position

class ConfirmedPlacement(
    private val game: Game,
    private val sourceSignal: Long,
    confirmedPositions: List<Position>,
) {
    private val positions = confirmedPositions.toList()
    var ticket: Long? = null
        private set
    private var prepareSubmitted = false
    private var submitted = false
    private var undoSubmitted = false

    fun prepare(): ConstructionResult {
        check(!prepareSubmitted)
        prepareSubmitted = true
        val result = game.construction.prepare(sourceSignal)
        if (result.token != 0L) ticket = result.token
        return result
    }

    fun createOnce(): ConstructionResult {
        val token = checkNotNull(ticket)
        check(!submitted)
        val current = game.construction.poll(token)
        if (current.state != ConstructionState.READY) return current
        submitted = true
        return game.construction.create(token, sourceSignal, positions)
    }

    fun inspect(): ConstructionResult = game.construction.poll(checkNotNull(ticket))

    fun undoIfAvailable(): ConstructionResult {
        val token = checkNotNull(ticket)
        check(!undoSubmitted)
        val current = game.construction.poll(token)
        if (!current.canUndo) return current
        undoSubmitted = true
        return game.construction.undo(token)
    }
}

Appelez prepare une fois ; votre interface peut ensuite inspecter le ticket à une cadence modérée. Lorsque l’état devient READY, createOnce soumet le lot une seule fois. Le marqueur submitted est posé avant l’écriture : si celle-ci lève une exception, inspect reste disponible et une nouvelle création est refusée localement. L’objet reste attaché au Game qui l’a créé.

ÉtatDécision de l’application
READYTicket prêt ; le lot confirmé peut être soumis.
PENDINGOpération en cours. Inspecter si un token non nul est disponible.
APPLIEDCréation appliquée ; lire createdIds et canUndo.
PARTIALUne partie seulement a été créée. Conserver les IDs et expliquer le résultat avant toute suite.
REJECTEDDemande refusée ; présenter reason et vérifier l’état avant un nouveau plan.
UNDONEAnnulation terminée pour ce ticket.

Respecter la disponibilité de l’annulation

canUndo décrit l’état observé du ticket. Une commande d’édition intervenue ensuite peut invalider l’annulation ; relisez le résultat avant de proposer undo et vérifiez aussi sa réponse. Ne déduisez pas la possibilité d’annuler de la seule présence de createdIds. L’exemple pose undoSubmitted avant l’écriture et refuse un second appel, même après une exception : inspecter le ticket reste possible sans rejouer l’annulation.