Zone über Table-Einträge aktivieren

[wendenzo]

Hallo,

kann mir vielleicht jemand kurz erklären warum folgender Code nicht funktioniert? Ich habe eine Zone erstellt mit dem Namen z2, die nicht aktiv ist. über folgenden Code möchte ich diese auf aktiv schalten:

test{}
test[1] = {z2, z3}
test[1][1].Active = true

leider klappt das nicht, und ich weiß nicht warum.

Grüße
wendenzo

 

[Charlenni]

Code sieht soweit korrekt aus. Heißt die Zone mit Lua-Namen wirklich z2?

 

[wendenzo]

Komisch, das kleine Testbeispiel funktioniert nun auch bei mir ohne Fehlermeldung, da habe ich mit copy/paste wohl etwas "Fehlerhaftes" überschrieben. Allerdings besteht ein Problem in diesem Zusammenhang immer noch, dafür muss ich aber etwas weiter ausholen:

ZoneIdentifier = {}
pos = {}

pos[1] = {2,4,32,29}
pos[2] = {5,1,6}
pos[3] = {6,4,32,17,21}
-- usw.

local ii=1
repeat
local jj=1
ZoneIdentifier[ii] = {}   
   repeat
   table.insert(ZoneIdentifier[ii], jj, "z"..pos[ii][jj])
   jj=jj+1
   if pos[ii][jj] == nil
       then jj=nil
       end
   until jj==nil
ii=ii+1
if pos[ii]==nil
   then ii=nil
end
until ii==nil

ZoneIdentifier[1][1].Active = true

Dieser Code funktioniert leider nicht, obwohl:

print(ZoneIdentifier[1][1])

das Ergebnis: z2 liefert!


Auf dein Frage: Ja die Zone wurde im Identifier als z2 benannt.

 

[Charlenni]

Ist klar, Zoneidentifier[1][1] enthält den String z2, aber nicht das Zonenobjekt z2. Das sind zweierlei Stiefel. Genauso wie 1 und "1" zwei unterschiedliche Dinge sind.

 

[wendenzo]

Ach, klar doch !!

Könntest du mir bitte einen kleinen Hinweis geben, wie ich dann Folgendes umsetzen kann?

ausgehend von

pos[1] = {2,4,32,29}
pos[2] = {5,1,6}
pos[3] = {6,4,32,17,21}

möchte ich eine table erzeugen, die folgende "Zoneobjekte" enthält:

Zoneidentifier[1] = {z2,z4,z32,z29}
Zoneidentifier[2] = {z5,z1,z6}
Zoneidentifier[3] = {z6,z4,z32,z17,z21}

 

[satanklaus]

Iteriere über pos und füge das jeweils aktuelle Element mit table.insert in zoneIdentifier ein.

 

[Charlenni]

Es war mir klar, dass diese Frage kommt , allerdings war der Computer schon aus oder ich zu müde . Also hier die Antwort (getestet auf iPhone, WhereYouGo und Emulator):

Ersetze die Zeile

   table.insert(ZoneIdentifier[ii], jj, "z"..pos[ii][jj])

durch

   table.insert(ZoneIdentifier[ii], jj, _G["z"..pos[ii][jj]])

Der Vorschlag von satanklaus ist hier nicht zielführend, da Du ja nur Zahlen und keine Zonen-Objekte in der Tabelle pos hast.

 

[satanklaus]

Der Vorschlag von satanklaus ist hier nicht zielführend, da Du ja nur Zahlen und keine Zonen-Objekte in der Tabelle pos hast.

Du hast völlig recht. In pos stehen ja nicht die Zonen-Objekte selber sondern nur die Indizes/Suffixe.
Vielleicht sollte ich das zum Anlass nehmen, Tapatalk auf dem Telefon künftig nur mit Brille zu nutzen

Dieser Dreher hat immerhin den Nebeneffekt, dass er vllt. einen alternativen Lösungsweg zeigt.
Wenn ich den aktuellen Code richtig verstehe, ist der dazu da, ein Array von Zonen-Elementen zu füllen. Dazu enthält die Table pos die Zonen-Indizes, die dann mittels String-Konkatenation zu Zonen-Namen umgewandelt werden. Und diese Namen werden dann als Key verwendet, um in der globalen Table _G die eigentlichen Zonen-Objekte rauszusuchen, welche anschließend in ZoneIdentifier eingefügt werden.

Nur: wenn ich den Zonen ohnehin spezifische anstelle der autogenerierten Namen gebe (z.B. "z2"), dann kann ich die Zonen-Objekte in Lua auch über diese Namen referenzieren.
Könnte ich dann nicht auch über diese Namen die Zonenobjekte gleich direkt in der passenden Reihenfolge in pos einfügen und mir den ganzen Aufwand mit dem globalen Lookup sparen?

Konkret:

pos[1] = {2,4,32,29} --> pos[1] = {z2,z4,z32,z29}

... und dann halt wie vorgeschlagen einfach über pos iterieren.

 

[Charlenni]

@Satanklaus: Klar, würde das gehen und wäre einfacher. Allerdings ist es dann z.B. Nicht möglich, die Tabelle pos mit zufälligen Werten zu füllen.

 

[satanklaus]

Getreu dem alten Support-Motto "Gib den Leuten was sie brauchen, nicht was sie wollen" sollte der Thread-Starter vllt. mal etwas näher erklären, wie das Ganze verwendet werden soll. Sonst kann ich mir zu jeder Lösung einen Grenzfall überlegen, wo sie nicht funktioniert.

 

[wendenzo]

Danke Charlenni! Das funktioniert bis auf weiteres wunderbar.

Nur: wenn ich den Zonen ohnehin spezifische anstelle der autogenerierten Namen gebe (z.B. "z2"), dann kann ich die Zonen-Objekte in Lua auch über diese Namen referenzieren.
Könnte ich dann nicht auch über diese Namen die Zonenobjekte gleich direkt in der passenden Reihenfolge in pos einfügen und mir den ganzen Aufwand mit dem globalen Lookup sparen?

Ja klar, das würde natürlich gehen, und das war auch mein ursprünglicher Plan. Allerdings kann ich auf die pos-Arrays nicht verzichten, deshalb hätte ich eine neue table erstellen müssen, und dabei aufpassen müssen exakt die gleichen Werte einzutragen. So dachte ich mir, warum soll ich das machen, wenn es eine Routine alleine machen kann? Und wie schon Charlenni erwähnte, wenn sich in einem pos-Array etwas ändert, so wird automatisch auch die Table der Zonenobjekte geändert. Letztendlich ist es etwas Sturheit meinerseits, und Neugierde wie ein Problem gelöst werden kann; deshalb möchte ich das genau so haben ...

 

[satanklaus]

... wenn sich in einem pos-Array etwas ändert, so wird automatisch auch die Table der Zonenobjekte geändert

Wie kommst du darauf, dass das automatisch passieren sollte?
So wie der Code oben da steht läuft er genau ein mal.
Klar kann man ihn in eine Funktion packen, die bei jeder Änderung der pos Table aufgerufen wird. Aber dann würde er in der jetzigen Form die Table der Zonen-Objekte immer länger machen. Ich denke, du erwartest aber eher, dass beides konsistent gehalten wird. Dazu darf aber nicht nur ein insert laufen, sondern der aktuelle Inhalt muss erst mal gelöscht werden.

 

[wendenzo]

Innerhalb des Programmablaufes sind die pos-Arrays natürlich konstant und werden nicht geändert. Ganz zuviel will ich hier öffentlich auch nicht verraten aber mit Änderung meinte ich eine eventuelle "manuelle" Änderungen zu einem späteren Zeitpunkt, da vielleicht Punkte hinzukommen, wegkommen, oder abgeändert werden müssen. ... Demnach wird das Tabelinsert automatisch angepasst; so war das gemeint. Das Tableinsert läuft hier natürlich global, da ich es beim Testen bequemlicherweise noch nicht in eine Funktion gepackt habe. Auch wenn das vom Programmablauf nicht zwingend notwendig ist, ist es wohl besser eine Funktion daraus zu basteln.

Aber mit den Änderungen von Charlenni klappt das erstmal sehr gut, und ich danke euch für die Hilfe und die rege Diskussion.