Datenbanken halt.
Man kann die Daten schon sichern, aber dafür braucht es schon bisschen mehr wissen (Token, Hash, Crypt uvm.)

Der Post von meinem Vorposter ist leider nicht zutreffend.
ElementDatas werden als flüchtiger Speicher (d.h. Speicher, der spätestens nach dem Neustart des Servers/Clients weg ist) benutzt, während Datenbanken einen permanenten Speicher darstellen, der auch nach dem Neustart noch vorhanden ist. Datenbanken sind aber langsam und daher nur geeignet, um ab und zu wichtige Spielerdaten zurückzuschreiben. Für alles andere und den "laufenden Betrieb" wird flüchtiger Speicher (Variablen, ElementDatas etc.) verwendet.

Wenn davon die Rede ist, dass ElementDatas unsicher wären, ist damit nicht gemeint, dass sie nicht verschlüsselt sind o.ä., sondern, dass sie u.U. durch den Client manipuliert werden könenn - selbst wenn sie serverseitig gesetzt wurden. Das liegt daran, dass MTA versucht die Werte zwischen Server und Client immer synchron, also gleich, zu halten. Dieses Verhalten kann abgestellt werden, indem die Änderung in dem Event onElementDataChange serverseitig rückgängig gemacht wird (prüfen, ob die Variable client gesetzt ist und dann setElementData mit dem alten Wert aufrufen).

Eine bessere Lösung ist für Fälle, in denen dieses Verhalten nicht explizit erwünscht ist, jedoch gänzlich auf ElementDatas zu verzichten und stattdessen eine eigene Lösung zu entwickeln. Über die Suchfunktion findest du verschiedene mehr und weniger gute Lösung.

Eine einfache Lösung ist folgende:

Diese Lösung lässt sich genau wie ElementDatas benutzen, tauscht die Werte zwischen Server und Client aber nicht aus. Schickere Lösungen wären Lösungen, die in Richtung Objektorientierung gehen. Die simd dann aber wirklich ein bisschen komplizierter in der Realisierung.

Der Beispielcode funktioniert sowohl auf dem Server als auch Client. Nur, dass Werte, die du serverseitig setzt, nicht auf dem Client verfügbar sind (und andersherum).

Man kann doch überprüfen ob der Wert von dem Server gesetzt wurde, mit der Hilfe eines Tokens.
Verstehe nicht was daran falsch ist..

Die faule Variante wäre, zusätzlich ein ElementData zu setzen, das du serverseitig nur setzt, aber nicht verwendest.

Heißt du kannst clientseitig per getElementData darauf zugreifen, serverseitig benutzt du aber ausschließlich getData. Eine längere, aber eigentlich schönere Alternative wäre, statt setElementData aufzurufen, ein Event an den Client zu triggern, das den Wert dort speichert (z.B. mit der clientseitigen setData Implementierung).

Davon abgesehen ist es oft aber auch so, dass du den Wert clientseitig gar nicht brauchst. Um außerdem dem Leitsatz "Never trust a client" zu folgen, sollte Spiellogik grundsätzlich auf dem Server implementiert werden.


Ich sehe nicht wie Token das Problem hier lösen. Wenn der Wert vom Server gesetzt wird, ist kein Token nötig, da der Server schon vertrauenswürdig ist und wenn der Client den Wert setzt, stimmt etwas am Konzept nicht.
Ich lasse mich da aber gerne eines Besseren belehren. Dazu müsstest du jedoch ausführen, wie du dir das im Detail vorstellst.