Wherigo Builder: Kommas zerschießen LUA

[48xor48]

Hi,

fragt bitte nicht, aus welchem Grund und wie ich auf diesen schwerwiegenden Bug im Wherigo Builder gestoßen bin, aber er könnte eine Erklärung für zahlreiche LUAs sein, die der Builder nicht mehr öffnen mag.

Im Builder erstellte Dialoge finden sich im abgespeicherten LUA wieder, wobei den einzelnen Dialogteilen noch Bilder beigefügt werden können. Ein Dialog aus 3 Teilen wird im LUA so abgespeichert -- die dabei meist herauskommende eine lange Zeile habe ich mal strukturiert auseinandergezogen.

Builder:
1) Dies ist ein Text. (+Bild)
2) Der zweite Text.
3) Letzter Text.

LUA:
Wherigo.Dialog
{
  {
    Text=[[Dies ist ein Text.]],
    Media=zmediabBild
  },
  {
    Text=[[Der zweite Text.]],
  },
  {
    Text=[[Letzter Text.]],
  },
}

Die doppelten eckigen Klammern sind in LUA erweiterte Textdelimiter. Um im Dialog auch weitere Parameter wie z.B. den CompletionCode des Wherigo auszugeben, kann man diese Delimiter auch direkt im Builder verwenden und mehrere Texte mit dem entsprechenden LUA-Operator .. verbinden.

Builder:
1) Dies ist ein Text.
2) [[Der zweite Text:]] .. Player.CompletionCode
3) Letzter Text.

LUA:
Wherigo.Dialog
{
  {
    Text=[[Dies ist ein Text.]],
  },
  {
    Text=[[Der zweite Text:]]..Player.CompletionCode,
  },
  {
    Text=[[Letzter Text.]],
  },
}

Beim Wiedereinlesen des LUAs werden dabei alle Dialogteile mit entsprechenden Delimitern versehen:

1) [[Dies ist ein Text.]]
2) [[Der zweite Text:]]..Player.CompletionCode
3) [[Letzter Text.]]

Außer Textteile mit Kommas. Bei einem Komma stolpert der Builder beim Einlesen und schneidet den entsprechenden Text am Komma ab, auch die beiden anderen, die keine Textzusammenfügung enthalten:

LUA:
Wherigo.Dialog
{
  {
    Text=[[Dies ist ein Text, nicht wahr.]],
  },
  {
    Text=[[Der zweite Text:]]..Player.CompletionCode,
  },
  {
    Text=[[Letzter Text.]],
  },
}

Eingelesen in den Builder:
1) [[Dies ist ein Text
2) [[Der zweite Text:]]..Player.CompletionCode
3) [[Letzter Text.]]

Der Builder scheint sich dabei nur am öffnenden Delimiter zu orientieren, er führt keine Ergänzung des schließenden Delimiters durch. Diese Datei kann also in den Builder eingelesen, aber nicht mehr compiliert werden. Wird der Delimiter im Dialog wieder ergänzt, funktioniert es wieder.

Aber noch schlimmer, beim Abspeichern wird ebenfalls keine Ergänzung durchgeführt, sondern es kommt dies dabei heraus:

LUA:
Wherigo.Dialog
{
  {
    Text=[[Dies ist ein Text,
  },
  {
    Text=[[Der zweite Text:]]..Player.CompletionCode,
  },
  {
    Text=[[Letzter Text.]],
  },
}

Dies ist keine korrekte LUA-Datei mehr und der Builder kann sie nicht mehr einlesen. Eine Reparatur ist nur noch in der LUA-Datei möglich.

Der Workaround ist unschön, aber simpel: Dialoge mit Textzusammenfügungen .. dürfen keine Kommas enthalten.

48xor48

 

[sTeamTraen]

Die verschiedene "Einschränkungen" des Groundspeak-Builders beim einlesen der Lua-Datei, war für mich der Hauptgrund, mein eigene Builder (Earwigo) zu schreiben.

Die gleiche Datei zum "source" und "object" nutzen ist ein Verbrechen gegen die Informatik, oder auf gut Englisch "An accident waiting to happen".

Bei Earwigo sind alle Cartridgedaten in einem SQL-Datenbank gespeichert; die Lua-Datei werd nur im letzten Moment geschrieben. Man kann jede willkürliche Lua-statement schreiben ohne sein Arbeit in Gefahr zu brengen. (Der Cartridge-Compiler ist ein "wirkliche" Lua-Implementation, hat kein doofe Syntaxproblemen.)