[Tiptoi] Wiederholen / Spiel programmieren

[Jonas Bähr]

Hallo zusammen,

> Am 17.10.2020 um 11:41 schrieb Joachim Breitner via tiptoi <tiptoi at lists.nomeata.de>:
> 
> Hallo,
> 
> Am Samstag, den 17.10.2020, 00:08 +0200 schrieb Ulrich Sibiller via
> tiptoi:
>> On Fri, Oct 16, 2020 at 11:53 PM Thomas Schäfer via tiptoi
>> <tiptoi at lists.nomeata.de> wrote:
>>>> Spannender finde ich eher die Frage wie man sowohl den Benutzer
>>>> bedient, der sich OIDs vom Tool zuweisen lässt (also Namen im scripts:-
>>>> Bereich benutzt), als auch den, der die OIDs selber setzen will.
>>> 
>>> Ich finde den Vorschlag, dass IDs automatisch gesetzt und wie START
>>> herausgegeben werden, charmant.
>> 
>> Ich weiß nicht genau, wie tttool das mit START macht, aber ich sehe da
>> ein Problem!
>> Dann musst du nämlich sicherstellen, dass tttool da zuverlässig immer
>> die gleichen generiert, denn wenn du einmal eine Vorlage zum Drucken
>> gemacht hast, willst du ja keine anderen OIDs mehr haben, oder?
>> Aber was macht man dann, wenn der User das yaml erweitert und die
>> zufällig ausgewählte Wiederholen-ID mit einem Playscript ausstattet?
> 
> Bei benamten Scripts schreibt tttool ja eine `.codes.yaml` datei raus,
> um sich das zu merken. Diese würde dann auch die zugewiesenen Codes für
> replay und stop merken.

Wie sähe das beim dump eines bestehendes GME-files aus? Dafür müssten wir die OIDs dieser build-in functions doch irgendwie im regulären yaml haben, oder?

Das STOP und REPLAY, analog zu START, immer für mit in die OID-Tables generiert wird finde ich gut! Und wenn man explizit bestimmte OIDs benötigt (z.B. bei `tttool dump`), könnte ich mir für das yml folgendes vorstellen:

build_in:
  STOP: 5004
  REPLAY: 5003

Ungünstig finde ich hingegen diese build-in (control, special, you name it) Funktionalität genau wie `scripts` darzustellen. Das würde z.B. nahe legen, dass diese auch ein gültiges Sprungziel wären.


Gruß,
Jonas