• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Player übergreifende Unterstützung von currentZone?

satanklaus

Geomaster
Ich habe eine gemeinsame Lua Funktion, die beim onEnter-Callback mehrer Zonen aufgerufen werden soll.
Ich kann den jeweiligen Zonen-Kontext natürlich mit
Code:
myFunc(<zoneName>)
übergeben.

Eleganter wäre es natürlich, wenn die Funktion das selber ermitteln könnte.
Nun gibt es im WIG Handbuch ja diesen Artikel. Der legt nahe, dass in Urwigo der currentObjects-Container immer aktuelle Werte enthält. Mir ist aber nicht ganz klar, was das mit dem WIG Builder zu tun hat. Letzlich muss doch der WIG Playerdafür sorgen, dass da das richtige drin steht. :???:
Wenn das in allen Playern verlässlich der Fall wäre, könnte ich direkt in Lua auf
Code:
objCurrentObjects.CurrentZone
zugreifen.

Mir ist klar, dass ich auch damit das Problem habe, dass ich durch GPS Schwankungen evtl. beim Aufruf schon wieder aus der Zone rausgeflogen bin.
Oder dass sich bei komplizierten Zonen-Layouts (z.B. geschachtelt) gar nicht genau sagen lässt, welche denn die aktuelle Zone sein soll. Aber das Problem kann ich ja angehen (z.B. mit den selbst-vergrößernden Zonen), wenn klar ist, dass currentXXX überhaupt auf allen Playern läuft.

Gibt es da Erfahrungen?

Danke.
 

Charlenni

Geomaster
CurrentZone ist eine Funktion, die Urwigo selbst mitbringt. Wenn du dir den erzeugten Lua-Code anschaust, dann wirst du sie dort finden. Mit dieser Funktion wird dann die aktuelle Zone (vermutlich die erste gefundene) zurückgegeben.

Habe leider gerade kein Urwigo im Zugriff, sonst würde ich dir die Funktion rauskopieren.
 
OP
satanklaus

satanklaus

Geomaster
Hmmm, wenn ich mir den Code ansehe, finde ich keine explizite Funktion dieses Namens, sondern lediglich so was:
Code:
function objZ0:OnExit()
	currentZone = "objZ0"
	...

Urwigo scheint also einfach stumpf der globalen Variablen den Zonen-Namen zuzuweisen. Ergibt auch Sinn: wenn Urwigo eine eigene Funktion erzeugen würde, müsste der Player ja immer noch wissen, dass diese Funktion exisitert, um sie an geegigneter Stelle aufzurufen.

Es sei denn, es ist ein vordefinierter Callback aus dem Wherigo Package, den nicht jeder Builder implementiert und der initial leer ist. (Hat Lua objektorientierte Konzepte wie virtuelle Funktionen und Function-Oveloading?)
 

Charlenni

Geomaster
Gut, dann macht es Urwigo auf düse Art. Hätte es aber eher im OnEnter erwartet.

Der Player bringt nichts mit. OO ist möglich, wird ja schon gemacht.
 

Charlenni

Geomaster
Die Funktion hieße dann CurrentZone, du würdest sie aufrufen und der Player hätte außer mit der Abarbeitung nichts zu tun.
 

Charlenni

Geomaster
Das Problem ist doch immer, welche Zone die CurrentZone ist. Wenn du eine große Zone (GZ) hast, die kleinere (KZ) enthält, dann betritts du zuerst die GZ. Diese ist dann CurrentZone. Wenn du nun in die KZ betritts, welche Zone ist dann die CurrentZone? Die GZ oder die KZ?

Wenn ich es noch richtig weiß (ist schon ein Weilchen her), dann gibt es ein Funktion Player.InsideOf(), welche alle Zonen liefert, in denen sich der Spieler befindet.
 
OP
satanklaus

satanklaus

Geomaster
Danke erst mal für die Anregung, einfach mal selber in _cartridge.lua zu schauen.

Die Zuweisung ist in allen OnXXX Callbacks drin, die ich belege. Also im OnEnter, OnExit, OnProximity etc.
 
OP
satanklaus

satanklaus

Geomaster
Charlenni schrieb:
Das Problem ist doch immer, welche Zone die CurrentZone ist. Wenn du eine große Zone (GZ) hast, die kleinere (KZ) enthält, dann betritts du zuerst die GZ. Diese ist dann CurrentZone. Wenn du nun in die KZ betritts, welche Zone ist dann die CurrentZone? Die GZ oder die KZ?

Wenn ich es noch richtig weiß (ist schon ein Weilchen her), dann gibt es ein Funktion Player.InsideOf(), welche alle Zonen liefert, in denen sich der Spieler befindet.

Ja, dessen bin ich mir bewusst, habe ich ja oben geschrieben. Ist bei dem konkreten Zonen-Layout aber kein Problem.
 

Charlenni

Geomaster
Ja, jetzt dämmert mir es wieder. Urwigo macht das händisch. Die OnEnter usw. werden ja erst beim Erzeugen der _cartridge.lua erzeugt. Und dann kann Urwigo das mit reinschreiben. Ist also gar nicht so "magic" 😉
 
OP
satanklaus

satanklaus

Geomaster
Und zudem scheint es halbherzig umgesetzt zu sein.
Auch in einem komplexeren Kontext, wo z.B. auch Items und Charakters beim Betreten sichtbar werden oder Tasks aktiv, wird im OnEnter lediglich die currentZone aktualisiert. Das verstehe ich ja noch, currentItem kann man da ja nicht sinnvoll belegen. Aber dann würde ich es wenigstens im Oncmd eines Item-Commands erwarten, denn da ist es eindeutig. Dort wiederum wird es nicht gesetzt.

Insofern scheinen die Aussagen aus dem Handbuch bzgl. aller currentXXX Variablen in Urwigo mit Vorsicht zu genießen sein.
Edit: Steht so nicht ausdrücklich drin. Genau genommen wird das nur für Zonen erwähnt. Habe ich vllt. zu viel "rausgelesen".
 

SammysHP

Moderator
Teammitglied
satanklaus schrieb:
(Hat Lua objektorientierte Konzepte wie virtuelle Funktionen und Function-Oveloading?)

Lua hat Metatables, das ist sowas Ähnliches. Wenn ein Bezeichner in einer Tabelle nicht gefunden wird, kann das mit Gettern/Settern behandelt werden und ansonsten wird es an eine andere Tabelle (sozusagen eine geerbte Klasse) weitergeleitet.
 

Charlenni

Geomaster
Das ist richtig, aber ...

Das iPhone benutzt eine selbst gebastelte Version von Lua und auch die von WhereYouGo ist nicht die offizielle Version. Deshalb kann es dabei zu Problemen kommen. Also, wie immer, schön auf allen Platformen testen 😉
 

SammysHP

Moderator
Teammitglied
Autsch. Ich hatte mich noch nie intensiver mit Wherigo beschäftigt und dachte, dass die Lua komplett unterstützen…
 
Oben