Tag Archives: Runes of Magic

Runes of Magic – Easter Egg gefunden

Posted on by

Ok, wir haben zwar nicht Ostern, aber es wurde trotzdem ein Osterei gefunden… in Runes of Magic.

Runes of Magic – Der Tempel der Raksha

Tarkina findet den Muffin Man – Leider nicht als Erste 🙁

Es gab schon immer Zweifel daran, daß der Tempel der Raksha ungewollt so geräumig ist. Man kann die ganze Ini umlaufen, wenn man erstmal den Einstieg gefunden hat und sehr viel Zeit investiert 😉

Ungewollt ist sicherlich, daß man den ersten Boss auch umlaufen kann. Allerdings kommt das mit einem Pferdefuß daher: Die Init läuft dann auf dem maximalen Härtegrade Diamant, was solo trotz Level 60 als Stoffi nicht so prickelnd ist 🙂

Was auch die wenigsten wissen werden, die Ini hat einen geheimen LP/Ausdauer Buff, der aber schwierig, weil unzuverlässig, zu reproduzieren ist. Dazu müssen die richtigen sprechenden Säulen in einem bestimmten Zeitfenster aktiviert werden.

Im übrigen, werde ich Euch nicht verraten, wie Ihr hinkommt. Wo das Ei ist,  seht Ihr ja, aber der Weg ist das Ziel 😉

 

Runes of Magic, Linux und der Performance Bug

Posted on by

Ihr könnte Euch gaaaaaaaaaaaaaaanz sicher an die Intel CPU Bugs erinnern und wie die im Linux Kernel abgewehrt wurden, so in etwa. Der Nebeneffekt war, u.a., daß bspw. Runes of Magic als WineApp mit DX9 Teil auf meinem  Achtkerner von im Durchschnitt 150% CPU Last pro Instanz auf 250% hochgeschnellt war. Die Kernels 4.19.9+ > 4.20.latest waren allesamt davon betroffen.

66% mehr CPU Last

Das Phänomen war besonders nervig, weil zwar im Regelbetrieb nur eine leichte Erhöhung von 150% auf 180% vorhanden war, aber sporadisch brach die Lasthölle los, mit den erwähnten Peeks auf 250%, die dann für einige Minuten blieben um dann wieder zu verschwinden. Ein Spielen war so natürlich nicht mehr mit mehreren Instanzen möglich.

Seit Kernel 5.0.6 und vermutlich auch eher, ist die Last wieder zurück auf den Normalwert von 150% im normalen Spielbetrieb. Die Reaktion vom Kernel bzw. Wine Maintainer auf diesen Bugreport war übrigens „Damit können wir nichts anfangen“ mit anderen Worten, sie konnten nicht mal glauben, daß es den Effekt überhaupt gab.

top – 13:11:29 up 1 day, 3:52, 1 user, load average: 4,09, 4,31, 4,87
PID   USER   PR NI VIRT   RES    SHR   S %CPU %MEM TIME+ COMMAND
3542  marius 20 0 2240024 1,238g 76976 S 155,8 7,9 1159:15 H:\Programme\GameforgeLive\Games\DEU_deu\Runes Of Magic\Client.exe NoCheckVersion20398 marius 20 0 2378776 1,291g 78152 R 142,2 8,3 1369:03 H:\Programme\GameforgeLive\Games\DEU_deu\Runes Of Magic\Client.exe NoCheckVersion

Da die Last seit einiger Zeit wieder konstant im grünen Bereich ist, kann man das Problem wohl als gelöst betrachten. Falls jemand von Euch mit einem Programm unter Linux ähnliche Erfahrungen gemacht hat oder derzeit macht, wisst Ihr was die Lösung ist => Kernel Updaten.

Bevor Klagen von Lesern reinkommen: klar hatte ich überprüft, ob sich Wine oder die Grafikkartentreiber geändert hatten, hatten sie nicht.

Datenausleitung bei Gameforge

Posted on by

Guckt ma :

„Liebe Community,

…Es gab ein Sicherheitsproblem, das schnell und umfänglich behoben werden musste, weswegen alle betroffenen Systeme vorübergehend komplett zugangsgesperrt werden mussten. …

Leider wurden einige Daten durch diesen Zugangspunkt geschleust, jedoch ausschließlich auf Ogame.us und Ogame Origin. Die zugänglichen Daten umfassten E-Mail-Adressen von Benutzern als auch ihre Nicknamen und einige Forensektionen, die nicht öffentlich zugänglich sein sollten.“

Quelle: https://forum.runesofmagic.gameforge.com/forum/thread/2543-stellungnahme-zur-foren-downtime/

Kommentar:

Die EU DS GVO läßt grüßen. Emailadressen sind Personenbezogene Daten. Das wird ein Heidenspaß. Da paßt es natürlich ins Bild, daß die Mailserver von Gameforge nicht mal TLS können(hoffentlich „konnten“, aber dafür gibt es noch keinen Beweis).

2018-08-27 XX:XX:XX H=smxgen.gfsrv.net [79.110.86.37] F=<bounce@gfsrv.net> rejected RCPT <xxxxxxxx@xxxxxxxxxxxxxxxxxx>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</xxxxxxxx@xxxxxxxxxxxxxxxxxx></bounce@gfsrv.net>

Unsere Server unterscheiden zwischen „Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.“ und „Sender did not use TLSv1.2 secured connection. Absender benutzte keine TLSv1.2 gesicherte Verbindung.“

Das kann richtig teurer werden, denn wenn Ihr ein Unternehmen seid, seid Ihr zum Datenschutz verpflichtet und das bedeutet, daß Ihr dem Stand der Technik entsprechend Daten schützen müßt (EU DS GVO Art. 32 Abs. 1a). TLSv1.2 ist damit zwingend notwendig im Mailserver.

Der Art. 32 Abs 1 schränkt zwar ein, daß der Aufwand zumutbar sein und in einem sinnvollen Kosten/Nutzenfaktor stehen soll, aber da man einem aktuellen Mailserversystem aktiv verbieten muß zu verschlüsseln, sind die Implementierungskosten => 0, wenn man aktuelle Software benutzt. ich denke, da happerts bei vielen Firmen gewaltig. „Wieso? Geht doch“ zieht seit der GVO nicht mehr.