logo 'GlitterArchiv' by Peperoni :: rmarchiv.de is brought to you with love.
logo 'GlitterArchiv' by Peperoni :: rmarchiv.de is brought to you with love.
Es geht, wie der Titel schon sagt, um Vorbereitungsarbeiten an RPG Maker Spielen, bevor sie dem RMArchiv hinzugefügt werden. Spiele, die über Datenbanken und div. anderen Seiten quer aus dem Internet bezogen werden, kommen ja oftmals nicht als saubere Archive, die keiner weiteren Vorbereitung bedarfen. Möglicherweise gibt es noch weitere Unannehmlichkeiten, aber folgende 5 fallen mir auf Anhieb ein:
Ich bereite die Spiele in jedem Fall immer so auf, dass sich die Spieldateien in genau einem Spielordner befinden, befreit von etwaigen Installer Zeugs, gepatcht und spielbereit. Sollten weitere Dateien wie beigelegte RTPs, Guides oder Readmes außerhalb des eigentlichen Spielordners beiliegen, werden sie dort mit reinverschoben. Entfernt wird wie gesagt nur der lästige und unnötige Datenmüll. Das betrifft auch Savestates, die im Grunde nichts in neu heruntergeladenen Spielen zu suchen haben. Gerade bei mir unbekannten Spielen mache ich vor dem Abschicken oftmals noch einen kurzen Funktionstest. Sobald der Spielordner vorbereitet ist, verpacke ich ihn mit WinRar zu einem Rar-Archiv. Beim Archvnamen vermeide ich Sonderzeichen wie etwa Umlaute, weil das bei manchen Leuten beim Entpacken zu Problemen führen kann.
Q: Und wozu der ganze extra Aufwand?
A: Weil ich Dinge sauber, einheitlich und unkompliziert mag. Und genau so gebe ich sie auch weiter. :)
Ich würde eh sagen, das wir uns auf ein bestimmtes Format einigen. Grund: Ich will die Spiele später auch über eine Desktop Version verfügbar machen. Quasi sowas wie Steam. Nur halt für RPG Maker Spiele =)
Dazu sollte es der Einfachheit halber auch eine einheitliche Struktur geben.
Sorry. Du musst mir mal wieder erklären, was du meinst. ^^' Ich benutze ja kein Steam und weiß von Hörensagen nur so ungefähr was das überhaupt ist. Und Desktop ... joar, ich sitze grade vor 'nem Windows Desktop PC. xD Oder ist damit was anderes gemeint?
Also:
Stell dir eine Applikation vor, die mit der Website verknüpft ist. Im speziellen mit den Kommentaren und Bewertungen zu Spielen, sowie der Liste zu den Spielen selbst.
Man soll sich in dieser Applikation ein Spiel von der WEbsite aussuchen können und auf installieren klicken. Dann wird das benötigte RTP installiert (oder entsprechende abhängigkeiten anderer Engines) und das Spiel heruntergeladen und entpackt. Nun wandelt sich der Button von Installieren auf Spielen. Was selbsterklärend ist, wie ich finde =) Also unterm Strich so etwas wie der AppStore oder Playstore. Nur halt eben für Windows (zumindest anfangs nur für Windows.)
Damit das ganze auch funktionieren kann, habe ich schon eine API implementiert, mit deren Hilfe ich die Benötigten Daten auch ziehen kann. Es fehlt quasi nur noch das Programm dazu =)
Ich habe das Feld hinzugefügt. Über Spiel bearbeiten kann nun auch ein Releasedate eingetragen werden, das NICHT required ist. Es wird auch bevorzugt angezeigt. Allerdings noch nicht überall. Das wird jetzt wieder ein wenig dauern, bis ich das überall angepasst habe. Ich werde übrigens auch dafür sorgen, das die felder ALLER spiele damit befüllt werden. Also automatisch anhand der entsprechenden Spielefiles. Ich habe aktuell sonst keine möglichkeit alles zu sortieren. Aber darum kümmere ich mich dann morgen =)
In diesem Thema wirkt die Nachricht wegen dem Release Date irgendwie aus dem Kontext gerissen. :D
Naja egal. Es wird almählich was mit der Release Date Lösung, bei der dann alle happy sind. Keep it up. :)
Eine wichtige Sache noch, die bei der Spielaufbereitung nicht fehlen sollte:
Achtet bitte darauf, ob Umlaute und Eszett in Dateinamen richtig angezeigt werden oder stattdessen so:
Mir begegnen immer häufiger Spiele (meistens sind diese älter) die Aufgrund dieser Zeichenänderungen ohne Rückbenennung abstürzen würden.
Es kann sein, dass ich früher bereits Spiele hochgeladen habe, die dieses Problem hatten, aber den anfänglichen Funktionstest überstanden, da betroffene Datein erst im späteren Verlauf auftreten würden. Denn erst im Laufe des letzten Monats bin ich durch ein Spiel, das beim Funktionstest dadurch schon abstürzte, auf dieses Problem aufmerksam geworden. Seitdem gehört der Umlautcheck und die etwaige Berichtigung der fehlerhaften Zeichen mit zur Aufbereitungsroutine.
Womit lässt sich das automatisieren?
Mir ist jetzt auch noch aufgefallen, dass das große Ü scheinbar durch einen Unterstrich ersetzt wird und das Ä durch ein Minuszeichen. Allerdings werden Unterstriche und Minus häufig auch ganz normal eingesetzt. Also was auch immer das automatisieren wird, es muss dann unterscheiden können zwischen beabsichtigten Zeichen und solchen unbeabsichtigten Änderungen. (Ich lege bei den Ü <-> _ und Ä <-> - Dateien sicherheitshalber nur Kopien mit Ä bzw. Ü an. Der große Ö Fall ist mir bislang noch nicht bekannt.)
Ich weiß was du meinst. Aber es gibt Bibliotheken, mit denen man die Datenfiles des RPG Makers auslesen kann. So kommt man beispielsweise an die Namen. Aber das ist nix für sofort =)
Hier mal noch einige Sachen die uns bei EasyRPG aufgefallen sind und die Probleme bei der Archivierung machen könnten:
Zumindest bei RPG Maker 2000/2003 fänd ichs noch sinnvoll wenn man bei den Tags inoffiziell Patches taggen würde. Also z.B. PicPointer, Ineluki KeyPatch, DynRPG usw. Wobei das vermutlich manuell wenig Sinn macht, da kann man auch irgendein Tool schreiben das alle RPG_RT.exe nach Patchsignaturen abgrast. Da ihr die Archive standardisiert ist sowas zum Glück problemlos möglich. Mit den Tags könnte man direkt schon mal erkennen, welche Spiele ohne die mitgelieferte RPG_RT.exe nicht funktionieren (EasyRPG emuliert PicPointer und Ineluki MP3 Patch).
Beim neu packen bzw. generall uploaden von ZIP bitte unbedingt aufpassen, dass ihr NICHT die Windows-ZIP-Funktion verwendet. Dieses Programm erstellt ZIPs in der Zeichenkodierung eures Windowssystems (Westeuropa) und nicht mit dem universellen (Unicode). Dadurch kommt für Nicht-ASCII (Umlaute usw.) bei Leuten außerhalb Westeuropas Käse raus (sogenanntes Mojibake).
Bei RAR und 7z tritt das Problem nicht auf. Die "zip"-Archive von 7z verwenden auch korrekt Unicode.
Zum entpacken von ausländischen Archiven empfiehlt sich "unar" https://unarchiver.c3.cx/commandline
Das Programm versucht die Zeichenkodierung zu erraten (super für Osteuropäische und Japanische Spiele). Das Tool verwendet die gleiche Bibliothek zum Kodierung raten wie EasyRPG (RPG_RT.ldb und die anderen Dateien enthalten auch nicht-Unicode-Strings, da zu alt, und darum kann z.B. ein Japaner ohne Extratools deutsche Spiele nicht spielen und umgekehrt).
Und noch eine Anekdote zum RTP:
Totales Chaos ist noch das RTP. Also rein für Deutsch/Englisch jetzt nicht (da gibts nur Offiziell, Don (2k) und RPG Advocate (2k3)), aber andere Länder haben andere RTP-Übersetzungen und daher finden ausländische Spiele dann Dateien nicht.
https://wiki.easyrpg.org/development/rtp-database/2000-rtp https://wiki.easyrpg.org/development/rtp-database/2003-rtp
EasyRPG erkennt die installierten RTPs und erkennt, wenn ein Spiel eine RTP-Resource abfragt, guckt in eine interne Tabelle und biegt den Resourcen-Zugriff auf die Namen des installierten RTPs um. Funktioniert noch nicht 100% zuverlässig, aber besser als nix... :D
Okay. Ich habe das hier schon vorher gesehen gehabt, antworte aber erst jetzt darauf, weil mich mit dem Player ein ähnliches thema geplagt hatte.
Bevor ich ein Spiel über den WebPlayer spielbar machen kann muss ich folgende Dinge tun:
rpg_rt.* und den Pfad dieser Datei als Basis nutzen.Dementsprechend habe ich über die Datenbank und den ZIP Dateien direkten und auch sehr schnellen Zugriff auf alle für patches relevanten Dateien.
Was ich nun bräuchte um die Tags dafür zu generieren: Fingerprints um die patches auch zu erkennen.
Alternative:
Ich hashe alle verfügbaren exe/dll Dateien die relevant sind. Also rpg_rt.exe und harmony.dll.
Das sollten ja nicht milliarden von unterschieden sein.
Die Hashes und der Dateiname werden in eine Datenbank gespeichert.
So stelle ich mir das vor:
hashtable
gamefile-hash-relation
Einzige handarbeit: Das Manuelle Pflegen welche Patches genutzt wurden, die Version des Makers und ob das Spiel unterstützt wird. So wäre es recht schnell machbar, das wenn ein Patch doch unterstützt wird, das man dies dann für alle betroffenen Spiele sofort umsetzen kann.
Wenn du natürlich eine bessere Methode kennst, dann immer her damit =)
Denke mal hashen ist gut genug, ich werde aber auch mal Cherry kontaktieren, ob er mir für seine Patche Signaturen mitteilen kann.
Die harmony.dll kann man übrigens schon an der Dateigröße erkennen. Das Original hat weltweit die Gleiche Größe.
Neben RPGRT und harmony hashen würd auch noch Vorschlagen mindestens RPG_RT.ldb und RPG_RT.lmt zu hashen, weil: Wir wollen für EasyRPG selbst auch irgendwann eine Datenbank direkt einbauen, um Spiele zu erkennen um z.B. die Sprache (Autoerkennung versagt manchmal), Hacks und Patche für diese konfigurieren (manche kann man nicht automatisch erkennen). Und für die Erkennung wollen wir die LDB und LMT verwenden, ist zuverlässiger als die EXE, welche eventuell ausgetauscht oder gelöscht wurde (da nicht nötig für EasyRPG).
Im Prinzip könnt man sogar alle Dateien hashen und z.B. als XML-Download bereitstellen. Das wäre z.B. für "Rom-Manager" sinnvoll (Tools um Roms/ISOs u.ä. zu verwalten). Zumindest haben uns schon mehrere gefragt obs in die Richtung schon Fortschritte gibt. (wobei ich nicht weiß was für ein Dateiformat dafür verwendet wird)
Okay. Wenn du die erkennung mit Hashes machen willst, also so in der Art wie ich das vorgeschlagen habe, dann kann ich dahingehend ja schon mal was basteln.
Ja. Die Originale DLL ist wohl weltweit gleich groß. Aber dort sind doch auch Patches versteckt. Oder?
ldb und lmt zu hashen ist kein Ding. Und dann halt unseren Titeln hier und den IDs zuordnen. Und dir ne API basteln, damit du die immer aktuell speichern und dann in den Player integrieren kannst.
Alle Dateien Hashen? Für Rom-Manager? Hrmm... Da hast du aber Glück! Ich habe mich schon mit dem gedanken auseinandergesetzt. Zwar nicht im Kontext der Rom-Manager oder der Patches, aber für die Assets. Ich archiviere ja auch unterschiedliche Versionen des gleichen Spiels. Bei Wolfenhain beispielsweise sind das jedesmal mehrere hundert MB. Die kann ich mir gröstenteils sparen. Du weißt denke ich, worauf ich hinaus will =)
Bezüglich der Rom Manager: Vor längerer Zeit habe ich ein wenig bei TOSEC bemüht. Weiß also was dies bedeutet. =) Auch sind mir die GoodTools ein Begriff. An sich auch ein Vorbild meiner Datenbank. Titel, Untertitel, Größe, Hash, Version, Releasedate. Und Informationen wie Releasegroup sind da wichtig. Alles also, was ich auch habe =P Aber die nutzen in der Regel nicht Hashes von allen Dateien, sondern von den Ursprungsarchiven. Und die existieren in den seltensten fällen. Vor allem bei alten Schätzen. Irgendwer hatte dann SPiele halt noch auf Platte und die dann gezipt. Inklusive der Savegames. Schon ist da der Hash verkehrt. Dann doch lieber was eigenes aufbauen und nur an TOSEC oder ähnlichem anlehnen. Es sei denn du meintest schon was spezifisches. Dann schaue ich mir das gerne mal an =)
Also heißt es für mich folgendes: Erstellen neuer Tabellen:
Ich würde SHA1 als Hash Vorschlagen. Ist nicht wesentlich langsamer bei der ermittlung, Trotzdem aber "dupe"-Sicherer =)
Wie das später alles für euch in eine JSON oder XML or Whatever verfügbar ist ja egal.
Hast du eventuell Discord oder sowas in der Art? Auch wenn ich hier sehr gerne schreibe, wäre ICQ oder etwas ähnlich modernes bei kleinen fragen schneller =)
Ja. Die Originale DLL ist wohl weltweit gleich groß. Aber dort sind doch auch Patches versteckt. Oder?
Meines Wissens sind alle Harmony.dll Patche sind immer eine Harmony-Ersetzung (darfst mich aber gern korrigierne, wenn du eine findest die das nicht erfüllt guck ichs mir an :) ). Also eine extra-DLL, welche das Harmony-Interface exportiert und dann alles normale an oldharmony.dll weiterleitet. Zumindest Inelukis MP3 patcht ersetzt die harmony komplett. Audioremony auch. Denk mal das kann man sehr leicht durch harmony hashen erkennen.
Aber die nutzen in der Regel nicht Hashes von allen Dateien, sondern von den Ursprungsarchiven. Und die existieren in den seltensten fällen.
Aso, wusste ich nicht. Ich würd aber meinen das einzelne Dateien hashen von Informationsgehalt sinnvoller ist, da man weiß, bei welcher Datei der Hash variiert.
Ich würde SHA1 als Hash Vorschlagen. Ist nicht wesentlich langsamer bei der ermittlung, Trotzdem aber "dupe"-Sicherer =)
Google hat vor paar Monaten eine SHA1-Kollision berechnet ;). Aber joa, ist eher theoretischer Natur und notfalls kann man immer noch ne 2. Spalte einführen und rehashen.
Hast du eventuell Discord oder sowas in der Art? Auch wenn ich hier sehr gerne schreibe, wäre ICQ oder etwas ähnlich modernes bei kleinen fragen schneller =)
IRC und ICQ habe ich, Discord vermeide ich, will nicht noch ein Extratool einsetzen zum chatten.
Das mit der Harmony.dll war eher ne Frage an dich. Also ob da die größe reicht. Aber wenn ich eh alles Hashen will... Macht die Antwort schon fast keinen Sinn mehr.
Klar ist in unserem Fall das Hashen aller Dateien Sinnvoller. Man sollte sich da nur auf ein allgemeingültiges Format einigen =) Aber da es da scheinbar noch nichts gibt gilt für uns das Wunschkonzert =)
Okay. Also SHA1 =)
Ich werde dran werkeln =)
Wenn ich Screens hochlade. Werden die PNGs in die JPEGs umgewandelt oder bleiben die PNGs noch irgendwo liegen? Weil die JPEG-Kompression ist ja schon teilweise echt extrem ^^'
Bei solcher Pixelart sind PNGs übrigens relativ klein wenn man sie noch mit "advpng -z4" optimiert.
z.B. hier: http://rmarchiv.de/games/1404
Wie man sieht ist PNG der klare Bewinner und sieht auch noch besser aus :)
Werden die PNGs in die JPEGs umgewandelt oder bleiben die PNGs noch irgendwo liegen?
Die originalen PNGs bleiben gespeichert und kann man sich mit "originalgröße zeigen" unterhalb der Screenshots anzeigen lassen.
Nochmal zur Verpackungsmethode, mir gerade wieder aufgestoßen während ich am MV WebPlayer gebastelt habe:
RAR/7z und "Setup.exe in ZIP" sind weiterhin problematisch.
RAR/7z:
Prinzipiell kann man auch die RAR/7z als Vorverarbeitungsschritt entpacken und die Dateien liefern, aber da wird rygs Speicherplatz schnell knapp.
Setup.exe in ZIP:
Also ich wäre dafür, einfach alle RAR/7z mit ZIP-Archiven zu ersetzen (neu hochladen zum überschreiben) und bei Setup.exe den Installer auszuführen und den Installationsordner als ZIP hochzuladen (Uninstall.exe löschen falls vorhanden).
Wichtig: WinRAR oder 7zip für ZIP-Erstellung verwenden, nicht Windows Explorer. Encoding-/Zeichensatzprobleme!
Bislang habe ich, nachdem der Webplayer hier ins Gespräch kam, 2k, 2k3 und XP Spiele fortan zu ZIP verpackt. Wobei das mit XP nur vorsorglich war, falls dafür Support gekommen wäre. Aber gut, jetzt wo der MV Player ein Ding ist, werde ich natürlich auch MV Spiele künftig in ZIP packen. Wegen den Installern hast du recht, die finde ich generell lästig, auch unabhängig jetzt von Schwierigkeiten mit dem Player. Normalerweise lade ich Installer auch gar nicht hoch.
Sorry, ich glaube nicht, dass ich sämtliche MV Spiele, die meistens riesig sind, erneut hochladen möchte in ZIP... Das schwankte ja immer zwischen schwierig und unmöglich, je nach Größe und Verbindungsstabilität... (Entfällt)
Das mit dem RAR zu ZIP-Konverter ist echt praktisch, wusste nicht das der existiert, daher hat sich das Problem schonmal wegautomatisiert :)
Ich habe hier >10 MB/s Upload, ich kann problemlos reuppen.