[Blog] Binary-Tools 2.0 Entwicklung

Guten Nachmittag,

ein paar vereinzelte Leute wissen, dass wir im Moment dabei sind, unsere Toolseite Binary-Tools etwas aufzupäppeln, aka komplett neu schreiben. Da mir beim Programmieren manchmal etwas öde wird, und ich mir nicht vorstellen kann, dass alleine in meinem meist dunklen Kämmerchen vor mich hinzucoden die beste Variante ist, um eine Toolseite zu schreiben, habe ich mich dazu entschieden, eine Art Entwicklerblog zu schreiben. Hier.

Bitte hier keine Antworten posten, sonst wird das etwas unübersichtlich.

Eure Antworten, Kommentare, and so on, könnt ihr gerne hier posten: [Feedbackthread] Binary-Tools 2.0 Entwicklungsblog

Edit 27.06.2020: Ihr könnt sie seit neuestem auch hier im Discord posten: https://discord.com/invite/hbEEyb3

Eine Warnung vorweg: Ich programmiere nicht regelmäßig an Binary-Tools. Jenachdem, wie ich Zeit und Lust habe. Es kann gut passieren, dass ich hier wochenlang nichts schreibe. Das heißt dann nicht, dass ich die Entwicklung eingestellt habe, sondern, dass ich im Moment keine Lust oder Zeit dafür habe.

Einige Screenshots, die ich hier im Verlauf des Threads eventuell poste, sind übrigens eher nie finale Versionen. Nicht wundern, wenn ab und zu ein Platzhalter ins Bild rutscht und alles hin und wieder "etwas" unfertig aussieht. Ist ja ein Blog, keine Toolvorstellung.

FAQ:

Q: Kann man im Moment sehen und nutzen, was aktuell vorhanden ist, so eine Art Open Alpha?

A: Nein, nur ggf. ein paar Screenshots. Vielleicht irgendwann später.

Q: Warum macht ihr alles von neu?

A: Kurzfassung: Das aktuelle BT ist über 6 Jahre alt und enthält Codezeilen, die ich geschrieben habe, als ich gerade gelernt habe, was ein Array und ein Objekt ist. Auf gut Deutsch, inperformanter Spaghetticode ohne Ende. War anfangs auch nie als öffentliche Toolseite geplant. Ich hab großteils keinen Plan, wo ich was ändern müsste, um zu bewirken was ich will, ohne alles kaputt zu machen.

Außerdem: PHP 5.x, MySQL 5.5 - habe ich beides nicht mehr auf meinem Rechner.

Q: Quellcodeverwaltung?

A: Jep.

Q: Wer ist wir?

A: Unity und ich. Ich habe zwar das meiste inhaltliche an Binary-Tools gemacht, aber er das meiste äußerliche (Layout & Design). Außerdem kommen ein paar Tools von ihm (Karte und Dorfplaner, z.B.). Der Name sagt euch nix, er spielt ewig nicht mehr, und hat nie wirklich aktiv gespielt. Ist einfach ein Kindheitsfreund von mir.

Q: Wann ist es fertig?

A: Keine Ahnung. Wirklich nicht. Wahrscheinlich 2020 oder so. Ich weiß auch noch nicht, ob wir alle Tools neu schreiben, manche sind echt unnütz. Aktuell stehen 28 Tools auf meiner Todo, vier davon nahe an final, zwei InDev, 22 nicht mal angefangen. Und die Tools sind ja nicht das einzige, das anfällt.

Nochmal:

Bitte hier keine Antworten posten, sonst wird das etwas unübersichtlich.

Eure Antworten, Kommentare, and so on, könnt ihr gerne hier posten: [Feedbackthread] Binary-Tools 2.0 Entwicklungsblog

mfg,

Be2-e4

Guten Nachmittag,

erst einmal ein kurzes Resumée, was wir mittlerweile fertiggestellt haben. Wir arbeiten da schon seit 27. Mai dran, ein bisschen was ist da schon zustande gekommen.

Für die etwas Bewanderteren: Wir nutzen Spectre.css & TypeScript. Ok, theoretisch haben wir TypeScript Support, ich habe bis jetzt noch alles in pure JS geschrieben, sonst machen wir alles selbst. Hat keine wirklichen Gründe, ich hab einfach nur Spaß daran. Und das ist immerhin mit das wichtigste, oder?

Bisherige, grundsätzliche (nicht-codeinterne) Unterschiede zur alten Version sind:

1) BT2.0 hat die Möglichkeit, auch Tools für andere Spiele als die Travianserie zu hosten.

2) BT2.0 unterstützt Mehrsprachigkeit, d.h. die Toolseite wird es bei Release auf englisch & deutsch geben, wenn sich Übersetzer aus anderssprachigen Communities finden, auch in anderen Sprachen.

3) BT2.0 hat eine bessere Integration von Anleitungen für die Tools und ich habe mir fest vorgenommen, für jedes Tool eine zu schreiben.

4) Die Tools sollten einheitlicher aussehen.

Aktuell haben wir 6 Tools, von denen vier schon gut nutzbar sind. Zwei davon stelle ich heute kurz vor, die anderen beiden im nächsten Post, die letzten beiden im übernächsten und dann geht es mit den eigentlichen aktuellen Blogs los.

Ausbildungsrechner

Detaillierte Anleitung bereits verfügbar.

Eine verbesserte Version des alten Ausbildungsrechners von Binary-Tools. Grundsätzlich tut er noch das gleiche und berechnet die Anzahl der Truppen, die man in einer bestimmten Zeit ausbilden kann. Es gibt allerdings ein paar Änderungen:

- Das neue Design ist ... kleiner. Und wie ich finde deutlich übersichtlicher. Und nutzt nicht mehr die alten T3(.6) Grafiken.

- Die neue Version kann auch Späheroffs berechnen, statt nur Off & Deff.

- Man kann die Schmiedestufe jetzt genau einstellen, statt nur 0 oder 20.

- Es gibt einige Statistiken mehr, die angezeigt werden: Ressourcen, Offkraft, Deffkraft und Kornverbrauch jeweils insgesamt, pro Stunde, pro Tag, pro Ressource und pro Kornverbrauch.

- Anstatt der Zeitspanne lässt sich auch die Truppenmenge eingeben - es wird dann berechnet, wie lange es dauert, diese auszubilden.

- Man kann mehrere Intervalle mit unterschiedlichen Konfigurationen zusammen addieren. Wenn ihr zum Beispiel an Tag 50 wissen wollt, wie groß eure WW Off noch wird, könnt ihr einfach zwei Intervalle nutzen: Eins für die 30 Tage bis die Tier 3 Items erscheinen und eins für danach (um den Anstieg des Helmbonus korrekt miteinzuberechnen). Als Nebeneffekt lassen sich damit auch zwei Offs desselben Volkes ziemlich übersichtlich miteinander vergleichen.

Screenshots:

Ressourcenausbaurechner

Detaillierte Anleitung bereits verfügbar.

Eine verallgemeinerte und verbesserte Version des Getreideausbaurechners von Binary-Tools. Wie in der alten Version berechnet es die optimale Reihenfolge, in der man die Infrastruktur eines (Haupt-)Dorfes ausbaut, also, wann man Veredler und Botschaft baut. Der Unterschied ist, dass man jetzt auch für Nicht-15er-HDs brauchbare Ergebnisse bekommt (9er, 7er und 6er HDs haben schließlich signifikante HLE Felder, die im alten Tool nicht berücksichtigt worden sind).

Wesentliche Neuerungen:

- Design überarbeitet

- Berücksichtigt nun Holz-, Lehm- und Eisenfelder

- Hat sowohl schön kompakte Ansicht der Baureihenfolge als auch detaillierte Ansicht mit jedem Schritt

- Man kann HLE Veredler deaktivieren, dann werden sie nicht in die Berechnung einbezogen

Screenshots:

mfg,

Be2-e4

Guten Nachmittag,

die beiden nächsten Tools in der Sammlung sind der Katapultrechner und Special Achievements.

Vorher noch ein kurzes "Übrigens": Alle Tools haben im Moment nur Travian Kingdoms Support. Das werde ich bis zur finalen Version aber natürlich noch anpassen und das sollte auch nicht allzu lange dauern. Ich plane T:L Support bei der Programmierung der Tools mit ein: Truppen- und Gebäudestatistiken werden zentral an einer Stelle geladen, Formeln in eine zentrale Formelsammlung ausgelagert und die Icons zentral über eine scss Datei eingebunden. Das bedeutet, dass ich im Optimalfall nur diese drei zentralen Stellen abhängig von der aktuell ausgewählten Spielwelt machen muss, damit alle Tools automatisch bei Bedarf an T:L angepasst sind.

Support für Ägypter und Hunnen bei Truppenberechnungen ist ein minimal anderes Thema - an einigen Stellen (z.B. Ausbildungsrechner) war ich bisher etwas faul und habe die Völkerauswahl hardcodiert in den Templates stehen. Aber das anzupassen wird auch nur eine Sache von einer halben Stunde für alle Tools oder so - denn sobald die Völker ausgewählt sind, werden die Truppendaten über die zentrale Stelle geladen und stehen damit zur Verfügung.

Lediglich Support für die Midgame Artefakte aus T:L ist ein etwas aufwändigeres Thema - aber sollte auch nicht allzu viel Zeit in Anspruch nehmen.

Katapultrechner

Anleitung ist im Moment noch Todo

Auch der Katapultrechner ist eine verbesserte Version der BT1.8 Version davon. Bei dem Layout bin ich mir noch nicht sicher, ob ich es so lasse. Ich finde es nicht unbedingt super übersichtlich ... aber bislang ist mir keine wirklich brilliante Idee gekommen, wie ich das besser lösen könnte, also bleibt es erstmal so. Wenn ihr eine habt, hier ist nochmal der Feedbackthread verlinkt: [Feedbackthread] Binary-Tools 2.0 Entwicklungsblog

Die wesentlichen Änderungen sind:

- Die neue Version zeigt die Details zur Berechnung an. Das bedeutet erstens, welche Komponente wie viel ausmacht und zweitens, die Formeln für die einzelnen Komponenten. Diese Änderung habe ich eingeführt in der Hoffnung, dass die Wichtigkeit erkannt wird, die Einwohner korrekt einzugeben. Und natürlich einfach so, als Information, weil der Platz noch frei war.

- Der alte Katapultrechner hatte eine Tabelle, die im Grunde anzeigt "jo, für Gebäudestufe 20 brauchst du 53 Katapulte, das bräuchtest du an Katapulten, wenn die Gebäudestufe nicht 20 ist: (Tabelle)". Der neue Katapultrechner hat eine ähnliche Tabelle, allerdings in erweiterter Form: Die neue Tabelle zeigt nicht nur an, wie es für andere Gebäudestufen aussähe, sondern auch, wie es für andere Katapultlevel aussähe (bei derselben Konfiguration, d.h. unter Berücksichtigung der Moral und des Steinmetzes). Die eigentliche Zeile und Spalte ist wie in der alten Version farblich hervorgehoben. Ziel dieser Änderung ist, dass den Schmiedefaulen die Wichtigkeit der Truppenupgrades bewusst wird, und dass man sich überlegen kann, ob es sich lohnt noch fix ein paar Kattalevel zu golden.

Die alte Funktion, dass man eingeben kann, wie viele Katapulte man hat, und rausbekommt, auf welcher Stufe das Gebäude anschließend ist, gibt es natürlich immernoch.

Und wie gesagt: Im Moment nur TK Support - Baumeisterartefakt ist derzeit also noch nicht verfügbar.

Screenshots:

Special Achievements

Angeregt von zwei Threads im englischsprachigen Forum, habe ich ein "Tool" geschrieben, das kurz und übersichtlich alle Special Achievements anzeigt und kurz erklärt, wie man sie bekommt. Wer nicht weiß, was Special Achievements sind - es gibt versteckte Achievements, deren Fortschritt man nicht sieht, die man für manche Aktionen bekommt. Sie haben großteils eher Easter Eggs Charakter, als dass sie einen wirklichen Erfolg darstellen und sind einfach nur just for fun im Spiel.

Achtung: Die Screenshots von dem Tool zeigen alle derzeit verfügbaren Special Achievements und wie man sie bekommt. Wer das nicht gespoilert bekommen möchte, schaut sich die Screenshots bitte nicht an. Das Tool verfügt übrigens ebenfalls über eine Spoilerwarnung.

Screenshots:

mfg,

Be2-e4

Guten Nachmittag,

die letzten beiden Tools, die zumindest angefangen wurden, sind ein Timer/FL Timer und ein Adelungsrechner.

Timer & Farmlistentimer

Ich habe irgendwann mal angefangen, einen eigenen Timer zu bauen für Farmlisten. Das hat einen ziemlich speziellen Grund: Ich hatte vorher einen akustischen Onlinetimer genutzt und mich wirklich alle fünf Minuten erschrocken, als das blöde Ding gefiept hat, weil es so laut war. Und trotz der Lautstärke habe ich es manchmal einfach überhört, wenn ich Serie geguckt habe oder etwas gespielt habe. Und naja, wenn man drei Sekunden Headset ablegt ist auch Schluss mit dem Ton. Also wollte ich weg von akustischen Signalen und habe einen Timer gebaut, der blinkt, anstatt zu klingeln - und das Timerfenster dann so positioniert, dass ich mit der Maus drüber fahren muss, wenn ich die Farmlisten abschicken will (vielleicht zur Erläuterung: Um Farmlisten zu schicken mach ich mir kleine 150 x 150 Pixel Browserfenster auf, in denen man quasi nur den Abschicken Button sieht und pack die Fenster auf einen Bildschirm, den ich selten ganz brauche, weil da auch mein Skype und TS ist - d.h. da ist eh bisschen Platz frei) und resette den Timer wenn man mit der Maus drüber fährt - perfekt für mich.

Ein ähnliches Konzept hat dieses Tool.

Man kann wählen zwischen einmaligen Timern und Farmlistentimern. Letztere starten automatisch neu, sobald sie abgelaufen sind, erstere nicht. Und der Plural ist durchaus bewusst: Man kann unbegrenzt viele Timer auf einmal aktiv haben, z.B. einmal für 10 Minuten Farmlistentakt für Liste A, B und C und einmal für 20 Minuten Takt für Liste D und E - so ähnlich haben wir in der letzten de4 gefarmt. Nebenbei gehen natürlich auch noch andere Timer, z.B. eine Erinnerung, dass man in 25 Minuten einen Stammi abschicken muss.

Außerdem kann man auswählen, ob der Timer blinken, klingeln, beides oder gar nichts soll, sobald er abgelaufen ist. Das akustische Klingeln muss ich allerdings noch implementieren. Wie gesagt, DevBlog, keine Toolvorstellung. :p

Im Moment sieht das Tool so aus:

Sieht man im Screenshot zwar nicht, aber als Startzeit Eingabeformat kann man hh:mm:ss, mm:ss oder einfach die Sekundenanzahl benutzen. Statt 3000 ginge also auch 50:00 oder 0:50:00.

Im Moment wird die aktuelle Konfiguration wie sie ist im LocalStorage gespeichert, sobald man einen Timer hinzufügt oder löscht (und natürlich neu geladen, sobald man F5 drückt oder so). Die Timer laufen im Hintergrund allerdings nicht weiter.

Wenn ein Timer abläuft und blinken aktiviert ist, blinkt seine Zeile. Fährt man mit der Maus über die Zeile, endet das Blinken.

Geplant ist noch:

- Eine Möglichkeit, Kommentare zu den Timern zu schreiben

- Eine Möglichkeit, die Timer mit dem Server zu synchronisieren (damit man die aktuelle Konfiguration auf allen Geräten hat, sofern man eingeloggt ist)

- Timer im Hintergrund weiterlaufen lassen

- Konfiguration als Link exportieren, um sie teilen zu können

- Konfiguration speichern/laden mittels Buttons machen, anstatt automatisch

Adelungsrechner

Hm. Bei diesem Tool zu sagen, dass es eine Verbesserung des alten Tools ist, wäre nicht ganz zutreffend.

Der alte Adelungsrechner hat ausgespuckt, mit welcher Stammikombination man als einzelner Account ein Dorf seines Gegners im Idealfall adelt, ohne sich selbst zu überadeln.

Der neue Adelungsrechner fasst drei Tools (zwei neue + den alten Adelungsrechner) in einem Tool zusammen. Die drei "Untertools" sind dann über Tabs auswählbar (so ähnlich wie Abfang-/Speed-/Wegerechner im alten BT1.8). Eines davon ist fertig, bei dem zweiten bin ich gerade dabei und das dritte noch nicht angefangen.

Erstens, der Adeligenvergleich.

Der Adeligenvergleich ist eine einfach gehaltene Tabelle, mit der man die Adeligen der drei (fünf) Völker simpel vergleichen kann. Man kann alle relevanten Daten angeben: Große Feste auf beiden Seiten, Brauereifest beim Angreifer und die Einwohner von Angreifer und Verteidiger. Anschließend sieht man in einer übersichtlichen Tabelle, wie viel Zustimmung die Stammesführer der jeweiligen Völker mindestens, höchstens und im Durchschnitt senken.

Screenshot:

Zweitens, die Adelwahrscheinlichkeit.

Hier wird man einen Verteidiger und beliebig viele Angreifer angeben können. Das Tool berechnet dann (von oben nach unten), wie hoch die Wahrscheinlichkeit ist, das Dorf oder die Stadt in diesem Angriff zu adeln. Anwendungsgebiet soll sein, dass man abschätzen kann, ob die Stammis reichen und wie hoch die Gefahr auf einen Selbstüberadel ist. Eventuell auch, um zu entscheiden, ob man es sich leisten kann, wenn der Cleaner mit Brauerei läuft, ob wirklich alle Stammis aus allen NDs ein großes Fest brauchen, and so on. Man könnte sagen, man soll mit diesem Tool abschätzen können, ob eine Adelung gut geplant ist oder ggf. die Planung verbessern können.

Dieser Tab ist wie gesagt im Moment InDev und noch nicht fertig.

Im Moment sieht es so aus:

Geplant sind noch:

- Möglichkeit zwei Angreifer zu vertauschen, bspw. um versehentliche Selbstüberadelungen zu vermeiden

- Anzeige der minimal und maximal notwendigen Angriffe in dieser Konstellation um das Dorf sicher zu adeln, z.B. für die Planung von Nacht und Nebel Aktionen, bei denen man wegen kurzer Laufzeiten mehrmals laufen könnte

- Eventuell ersetze ich das Dropdown für die Völker noch durch klickbare Völkericons, so wie im Ausbildungsrechner:

Falls es jemanden interessiert, wie die Wahrscheinlichkeit für den Adel berechnet wird, sei dies kurz erläutert.

Die Adelmechaniken habe ich von T:L übernommen, ich habe leider bisher noch keine Möglichkeit gehabt, die für TK zu verifizieren - ich gehe aber nicht davon aus, dass da groß Änderungen durchgeführt wurden.

Grundsätzlich funktioniert das adeln so:

1. Je nach Volk wird eine Zufallszahl zwischen 20 und 25 (Gallier, Germane) oder 20 und 30 (Römer) generiert.

2. Bonus/Malus für großes Fest wird addiert/subtrahiert: +5 für Angreifer gF, -5 für Verteidiger gF

3. Die Zahl wird mit der Anzahl der Stammis in dem Angriff multipliziert.

4. Das Ergebnis wird mit dem Moralmalus verrechnet: (Verteidiger EW / Angreifer EW)^0,2, Werte unter 0,667 und über 1,000 werden auf die jeweilige Grenze gesetzt.

5. Das wird dann bei aktivem Brauereifest des Angreifes noch durch zwei geteilt.

6. Zum Schluss wird das Ganze noch gerundet.

Heraus kommt die gesenkte Zustimmung.

Um die Wahrscheinlichkeit auszurechnen, berechnen wir für jede denkbare Gesamtzustimmungssenkung die Anzahl der Kombinationen, die sie ergeben. Die Summe der Kombinationen, die mindestens 100 (bzw. so viel, wie man konfiguriert) abziehen geteilt durch die Summe aller Kombinationen ist dann die gesuchte Wahrscheinlichkeit. Und die Anzahl der Kombinationen zu berechnen ist relativ einfach mit dem folgenden Algorithmus:

- Rest folgt im Folgepost, 10.000 Zeichenlimit überschritten -

Achtung - mathematischer Teil. Wer das überspringen möchte kann gefahrlos nach dem Spoiler weiterlesen. Wenn es euch interessiert, freut es mich aber, wenn ihr es lest:

Drittens, Adelplaner.

Das entspricht im Grunde dem ursprünglichen Adelrechner aus BT1.8. Man gibt Einwohner, Volk, Feste beider Spieler und Anzahl der verfügbaren 3er Stammis ein und bekommt eine Stammireihenfolge zurück, die das Dorf sicher adelt und dabei das Selbstüberadeln minimiert - sofern eben möglich. Keine Screenshots, weil noch nicht angefangen. Das ist wahrscheinlich Gegenstand der nächsten Posts, zusammen mit dem Rest vom zweiten Tab, weil ich da gerade dabei bin, es zu programmieren. :p

Übrigens: Erwartet bitte nicht, dass der Blog täglich neue Einträge bekommt. So viel habe ich dann auch wieder nicht zu berichten über die Entwicklung. Ist jetzt nur die ersten Tage, weil da eben schon sieben Monate Entwicklung drin stecken. Außerdem wird nicht jeder Post neue Tools beinhalten. Manche (einige) Posts werden sich auch mit etwas langweiligeren Themen befassen, manche (viele) Tools werden mehr als nur einen Post bekommen, weil die Entwicklung eben manchmal etwas dauert, und die Posts werden wahrscheinlich grundsätzlich etwas kürzer. Im nächsten Post wird es wahrscheinlich um den letzten Tab im Adelungsrechner gehen und noch um Kleinigkeiten im zweiten.

mfg,

Be2-e4

Guten Abend,

die letzten paar Tage habe ich an dem Adelungsrechner weitergeschraubt und eine Kleinigkeit im Ressourcenausbaurechner verbessert. Weil es wirklich eine Kleinigkeit ist, die zuerst: Die Berechnungen unterstützen jetzt die Angabe der Serverspeed. Eine UI dafür gibt es zwar nicht, wird es aber auch nicht geben - die Serverspeed wird durch die ausgewählte Welt definiert. Also, sobald es implementiert ist, die Spielweltauswahl ist zurzeit nur Dekoration.

Am Adelungsrechner gibt es auch noch nicht viel neues zu sehen, dafür etwas neues Gedankengut. Zu sehen sind zwei Knöpfe, die die Angriffe im Wahrscheinlichkeitenrechner hoch und runter verschieben können:

Ich hoffe inständig, dass ich noch eine schönere Position dafür finde, als dort, wo sie gerade sind.

Dafür habe ich mir ein paar Gedanken gemacht, wie ich die Stammireihenfolge berechnen möchte und wie genau man die Eingaben spezifizeren können soll. Das grundsätzliche Problem ist, dass der triviale Ansatz, um die beste Reihenfolge zu finden exponentiell mit der Anzahl der möglichen Stammidörfer ansteigt. Das heißt, ein trivialer Ansatz ist unbrauchbar.

Eine Möglichkeit wäre zu berechnen, wie viele Stammis man maximal schicken darf, damit das Dorf garantiert nicht geadelt wird. Das funktioniert relativ gut und wird vom alten Adelungsrechner so umgesetzt:

1) Ermittle wie viele Stammis maximal geschickt werden können, um das Dorf garantiert nicht zu adeln

2) Ermittle, wie viele davon großes Fest feiern dürfen, ohne dass das Dorf geadelt werden kann

Dadurch erhält man z.B. so etwas wie "5 Stammis, davon 2 mit großem Fest, die senken minimal 75 und maximal 99 Zustimmung" (zufällige Beispielzahlen) und weiß dadurch, dass man um das Dorf jetzt sicher zu adeln mindestens 25 Zustimmung senken muss - und kann dafür die minimal notwendige Stammizahl mit Festen ermitteln. Die optimale Reihenfolge der letzten Stammis ist trivial: 1er zuerst, dann 2er, dann 3er und in der jeweiligen Gruppe zuerst ohne Fest und dann mit Fest.

Bei dieser Methode gibt es allerdings ein fieses Problem namens Rundungsfehler. 2 Stammis senken nicht notwendigerweise genau doppelt so viel wie einer. Einer könnte 17-21 Prozent senken, zwei dafür 33-43 Prozent - zum Beispiel wenn es eigentlich keine 17-21, sondern 16,5-21,4 Prozent sind, die bei einem Stammi gerundet werden, bei zwei Stammis aber erst nach dem Verdoppeln gerundet werden.

Dadurch wird die Aussage "man bräuchte zuerst 5 Stammis mit 2 großen Festen und dann einen 2er mit gr. Fest" recht schwammig: 5 Stammis können 5x 1, 2 + 3x 1, 2x 2 + 1, 3 + 2x 1 oder 3 + 2 sein. Alle mit potentiell anderen Ergebnissen und Wahrscheinlichkeiten.

Ein Beispiel für einen solchen Fall wäre ein 1.000 EW Römer, der ein 590 EW Opfer adeln möchte, das 125% Zustimmung hat: Die Berechnung würde ergeben, dass er 4 Stammis mit gr. Fest schicken muss um die Zustimmung zu senken und anschließend einen 2er mit großen Fest zum Adeln schicken muss. 4x 1 Stammi gefolgt von einem 2er würde auch perfekt funktionieren. Schickt er aber einen 1er, einen 3er und einen 2er, so besteht die Chance, dass der zweite Angriff schon adelt - wegen Rundungen (die Chance ist übrigens 1,65%):

Nach etwas darüber nachdenken, habe ich mich aber dazu entschlossen, den Algorithmus obwohl er nicht exakt ist so zu benutzen. Der Grund dafür (außer dass der Fehler minimal und selten ist) ist derselbe, aus dem ich entschieden habe, dass man nur einen Angreifer konfigurieren kann (anstatt mehrere) - das Problem eine Stammikombination zu finden, die die Zustimmung so weit es geht senkt, ohne das Dorf zu adeln, ist eine Variante des Rucksackproblems, genauer gesagt des Teilsummenproblems - beide sind nicht in Polynomialzeit exakt lösbar.

Der Spezialfall eines Angreifers mit der vereinfachten Annahme, dass es keine Rundungsfehler geben könnte ist eine Vereinfachung des Rucksackproblems auf nur ein mögliches Item in unbegrenzter Anzahl - und das bricht das Problem auf ein paar simple Grundrechenaufgaben runter. Das ist eine Vereinfachung, die ich für Berücksichtigung von Rundungsproblemen nicht finden konnte und die für eine Einbeziehung anderer Moralmali nicht existiert.

Eventuell teste ich irgendwann ein paar Annäherungsversuche oder probiere aus, wie gut und schnell es mit dem Rucksackproblemsalgorithmus in Pseudopolynomialzeit funktioniert, aber vorerst belasse ich es dabei. Andere Bereiche wollen auch meine Aufmerksamkeit und ganz ehrlich - die paar Prozent in den wenigen Fällen in einem Tooltab, der vermutlich eh nicht der meistgenutzteste sein wird, sind den Aufwand nicht wert.

Die Implementierung und hoffentlich das User Interface folgen im nächsten Post. Apropos - ich habe vorhin festgestellt, dass noch ein Angriff löschen Button fehlt.

mfg,

Be2-e4

Guten Abend,

eine Kleinigkeit habe ich nun doch noch an dem Algorithmus (siehe oben) optimiert:

Die Adelung wird in zwei Abschnitte geteilt:

1) Zustimmung senken, ohne dass geadelt wird

2) Eigentliches Adeln

Wie oben wird also zuerst eine Stammireihenfolge berechnet, die die Zustimmung soweit wie möglich senkt, ohne zu adeln und anschließend geadelt.

Anstatt mich mit den Rundungsfehlern von letztens zu ärgern, fügt der Algorithmus jetzt 3er Stammis hinzu, bis kein weiterer 3er Stammi mehr passt (ohne Gefahr auf Adel). Anschließend 2er und dann 1er Stammis. Damit sind für den Moment Rundungsfehler ausgeschlossen, weil die maximale Senkung jedesmal exakt für diese Stammizahl berechnet wird und vorher keine Rundungen passieren. Nachdem die Stammis eingeplant wurden, wird die Planungsliste durchgegangen und geprüft, ob jeweils ein großes Fest aktiviert werden kann, ohne Gefahr auf Adel. Das geschieht auch noch Rundungsfehlerfrei.

Zuletzt wird geprüft, ob ein 3er oder 2er in 1er + 2er aufgebrochen werden kann um nur 1 (bzw. 2) große(s) Fest(e) zu feiern. Dabei können sich eventuell Rundungsfehler einschleichen - diese sollten aber Auftretwahrscheinlichkeiten von < 1% haben und damit ziemlich insignifikant sein.

Nun haben wir eine Menge von Stammis, die x bis y Zustimmung senken, wobei y < Startzustimmung. Nun müssen wir noch mindestens (Startzustimmung - x) Zustimmung senken, um das Dorf sicher zu adeln. Dafür gehen wir ähnlich vor: Es werden solange Stammis hinzugefügt, bis das Dorf sicher geadelt werden kann, indem nur noch große Feste aktiviert werden. Dabei werden solange 3er hinzugefügt, bis ein 2er reicht. Dann entweder ein 2er oder ein 1er hinzugefügt und zuletzt noch große Feste gefeiert, dabei werden 3er zuerst mit gF versehen, dann 2er, dann 1er. Anschließend werden die Stammis in ihrer Reihenfolge optimiert, nämlich 1er -> 1er gF -> 2er -> 2er gF -> 3er -> 3er gF, damit die Chance sich selbst zu überadeln minimal bleibt. (Nur die Stammis des zweiten Schritts werden sortiert).

Anschließend ist das Ergebnis fertig.

Beispiel:

Ich will ein (fiktives) Dorf mit 300 Zustimmung adeln, 2.000 Einwohner vs. 1.000 Einwohner, als Römer, ohne Brauerei.

1. 3x 3er hinzufügen - ein weiterer 3er würde nun eine Adelung riskieren

2. 2er hinzufügen - mehr Stammis würden eine Adelung riskieren

3. Einen 3er mit gF laufen lassen - mehr gF würden eine Adelung riskieren

4. Zum Adeln werden nun zwei 3er eingeplant, einer mit gF

Das Resultat ist also: 3er gF -> 3er -> 3er -> 2er -> 3er -> 3er gF

Der Algorithmus sollte Rundungsprobleme bis zur Insignifikanz minimieren (wird sie aber wahrscheinlich nicht komplett beheben).

Ich plane übrigens, nach der Berechnung das Resultat einfach in den Adelwahrscheinlichkeitentab zu übertragen, damit man direkt die Wahrscheinlichkeitsberechnung sehen kann (und somit auch validieren kann, ob der Vorschlag passt oder selbst daran feilen).

Ein User Interface gibt es auch schon, allerdings ist es noch nicht funktionsfähig und tut einfach nichts. Außerdem fehlt der Berechnen Button:

ToDos:

- Limitierte 3er in den Algorithmus einbauen

- UI beleben

Außerdem habe ich ein paar Kleinigkeiten im Wahrscheinlichkeitentab geändert:

• Die hoch/runter Buttons sind nun links von der Volkauswahl, dafür die EW Spalte zweizeilig
• Das Dropdownmenü für die Völkerwahl habe ich wie im Ausbildungsrechner durch die Stammiicons ersetzt, außerdem bei den Icons deutlicher gemacht, welcher aktiv ist (betrifft auch den Ausbildungsrechner)
• Die Reihenfolge der Angriffe kann jetzt auch - auf Vorschlag von iTob - mittels Drag & Drop verschoben werden, dafür hab ich aber keine klare UI. Der Cursor wird zu einem Verschieben-Cursor, wenn man in die Nähe der Pfeiltasten kommt. Ich hoffe das + Anleitung (ToDo) sind genug Hinweise auf dieses Feature. Draggen kann man übrigens an der ganzen Zeile.

ToDos:

• Löschenfunktion für eine Zeile - wird wahrscheinlich zwischen die Pfeile kommen

Screen"shot" (ist ein GIF wegen Drag & Drop Funktion):

mfg,

Be2-e4

Guten Nachmittag,

nachdem ich gerade etwas nebenbei auf einer T:L Welt klicke, habe ich angefangen, T:L Support jetzt schon zu implementieren, damit ich die Tools direkt nutzen kann.

Implementiert habe ich bisher Truppenicons für T:L. Diese werden automatisch für alle Tools abhängig vom ausgewählten Server genutzt - TK Icons bei einem TK Server und T:L Icons bei einem T:L Server. Dieses Prinzip werde ich auch für Gebäudeicons übernehmen, für andere Icons (wie z.B. das "+" Zeichen im Ausbildungsrechner, oder das Angriffsschwert, Verteidigungsschild und Spähfernglas) behalte ich TK Icons bei. Einerseits habe ich keine Lust die T:L Icons zusammenzusuchen, andererseits finde ich die TK Icons einfach hübscher. Damit sind jetzt übrigens auch Icons für Ägypter und Hunnen vorhanden.

Außerdem habe ich mittlerweile die Truppendaten für T:L hinterlegt, sodass der Ausbildungsrechner jetzt auch für die beiden neuen Völker und T:L allgemein genutzt werden kann. Ich musste lediglich die Völkerauswahl anpassen. Ägypter und Hunnen sind in TK natürlich nicht auswählbar.

Hauptsächlich betroffen von den Änderungen ist der Ausbildungsrechner:

Aber auch der Adelungsrechner hat die T:L Icons (so wie alle anderen Tools, die Truppenicons nutzen werden - ganz automatisch):

Der Adelungsrechner funktioniert übrigens auch direkt mit den beiden neuen T:L Völkern.

Intern habe ich ein paar Dateien und Ordner verschoben:

• Ich habe ein paar CSS Dateien von Travian aus dem Browser kopiert um es mit mit den Truppenicons für TK leichter zu machen und einige "Rohdaten" von irgendwelchen Datentabellen (z.B. Truppen TSV Dateien). Die haben im Tool keine Verwendung, wurden aber von mir genutzt, um die eigentlich genutzten Dateien zu erstellen. Den Ordner habe ich vom Hauptverzeichnis in das dbg Verzeichnis geschoben. Das dbg Verzeichnis wird nicht hochgeladen bei Release, d.h. die Dateien sind nur in der Quellcodeverwaltung und nicht live.
• Ich habe die (bisherigen) versionsspezifischen Icons in einen extra Ordner gelegt, namentlich die Icons für Truppen und Achievements, damit da etwas mehr Ordnung herrscht.

mfg,

Be2-e4

Guten Morgen,

über das Wochenende habe ich eigentlich nicht viel gemacht, muss ich gestehen. Dafür eine Sache, die mal dringend nötig war. Vorwarnung: Technischer Hintergrund, aber ich habe mich bemüht es laienfreundlich zu schreiben.

Wir nutzen in Binary-Tools für alle Tool UIs eine von mir geschriebene JavaScript UI. Basically ist das eine JS "Klasse", die eine Tabelle darstellt. Muss halt nicht zwingend eine HTML Tabelle sein, wir können auch HTML Code als Template hinterlegen, der dann als eine "Zeile" interpretiert wird, und von dem mehrere nacheinander in einen Container gepackt werden, wenn es mehrere Tabellenzeilen gibt. Die meisten Tools (wie z.B. der Ausbildungsrechner) nutzen diese Variante (HTML Code übergeben als Template) in Kombination mit genau einer Tabellenzeile, um die Einstellungen anzuzeigen. Die einzelnen Intervalle im Ausbildungsrechner, Angriffe im Adelungsrechner, Timer im Timertool, and so on, sind auch alle mit dieser UI realisiert. Die wird basically überall genutzt und bietet uns einige praktische Funktionen, um uns kaum noch um die UI kümmern zu müssen:

• Änderungen an den Werten werden sofort erkannt und angezeigt
• Inline-Editierung funktioniert automatisch, sofern für die Spalte aktiviert (z.B. Kaserne, gr. Kaserne, and so on im Ausbildungsrechner): Auf den Wert klicken ermöglicht Bearbeitung.
• Validierung von Usereingaben funktioniert automatisch, indem wir nur einen Validator hinterlegen
• Nutzereingaben werden automatisch geparst, ggf. über hinterlegten Parser
• Formatierung funktioniert automatisch, indem wir einen Formatter hinterlegen
• Bedingte Formatierung ist möglich
• Sortierung ist möglich (wenn als echte HTML Tabelle genutzt, können die Überschriften angeklickt werden um zu sortieren, falls für diese Spalte aktiviert, z.B. in der Weltenübersicht)
• Hinterlegen einer Berechnungsvorschrift für Spalten ist möglich (d.h. eine Spalte automatisch aus dem Wert der anderen Spalten zu berechnen)
• Wenn ein Tool für alle Zeilen Berechnungen durchführt (z.B. wenn man das große Fest beim Verteidiger aus/einschaltet im Adelungsrechner), kann im Quellcode die UI Synchronisation de- und wieder reaktiviert werden, damit nicht jedes mal unnötigerweise neu gerendert wird, wenn durch Quellcode ein Wert geändert wird.

Soweit so gut, als ich sie geschrieben und erweitert habe, habe ich allerdings (mehr oder weniger bewusst) nie so wirklich Wert auf Performance gelegt, weil ich die im Nachhinein immernoch problemlos verbessern kann - und sich das dann auch direkt auf alle Tools auswirkt. Und genau darum habe ich mich am Wochenende endlich etwas gekümmert:

• Wird eine Zeile aus der Tabelle gelöscht, wird nun nicht mehr alle Folgezeilen neu gerendert um die Indexverschiebung auszugleichen, sondern die Zeile aus dem HTML Code gelöscht:
  Bei jedem UI Update wird geprüft, ob die Anzahl der HTML "Zeilen" mit der Anzahl an Datensätzen übereinstimmt. Wenn es zu viele HTML Zeilen sind, werden die überschüssigen von hinten an gelöscht und anschließend alle Zeilen neu gerendert. Das war von Anfang an nur als Fehlerprävention implementiert und sollte später dadurch abgelöst werden, dass die eigentlich betroffene HTML Zeile gelöscht wird - was jetzt der Fall ist.
• Wird ein einzelner Wert einer Zeile editiert, wird nicht mehr die gesamte Zeile neu gerendert, sondern nur noch das Element, welches den Wert der Zelle beinhaltet hat.
• Wenn die UI Synchronisation wiederaufgenommen wird, wurden bisher alle Zeilen neu gerendert, um sicherzugehen, dass alles aktuell ist. Jetzt werden nur noch die in der pausierten Zeit geänderten Zeilen neu gerendert.
• Es werden einige Sachen jetzt gecacht

Insgesamt ist die Performance für einzelne Änderungen um (bei nur vier Spalten, bei mehr Spalten signifikant stärker) um einen Faktor von durchschnittlich ~400 angestiegen und das Hinzufügen neuer Datensätze geht jetzt ~25x schneller. Da ginge zwar vielleicht noch etwas mehr, aber die Performance reicht denke ich für die praktische Anwendung.

Geplant sind für die UI übrigens noch:

• Anzeige von nur einem bestimmten Ausschnitt der Daten (sei es Filterung oder Aufteilung in mehrere Seiten)
• Stapelverarbeitung ermöglichen (wird z.B. vom Einsatzplaneditor zwangsweise benötigt werden)

Übrigens: Ich weiß, dass es wohl bereits fertige JS Bibliotheken dafür gibt. Und die haben wahrscheinlich einige Vorzüge (z.B. performancetechnisch). Ich habe mich dennoch bewusst dafür entschieden, das selbst zu schreiben - und zwar weil ich sehr Spaß daran habe, solche Sachen zu programmieren und dann auch selbst zu nutzen. Es mag wohl sinnvoller sein, Fertiges zu benutzen, aber ich möchte mir den Spaß daran definitiv nicht nehmen lassen. Solange meine Version funktioniert, kann was ich brauche und performant genug für den alltäglichen Gebrauch ist, hat es selbst zu programmieren auch keine nennenswerten Nachteile, die am Ende beim Nutzer zu sehen oder zu spüren sind.

In den nächsten paar Wochen wird übrigens wahrscheinlich etwas weniger hier im Blog kommen. Erstens Job (= Programmieren für Arbeit = keine Lust danach noch an Binary zu programmieren), zweitens Klausur. Wahrscheinlich werde ich daher die nächsten Wochen hauptsächlich nachts am Wochenende an BT programmieren.

mfg,

Be2-e4

Guten Abend,

heute habe ich mir ein genaueres Konzept für die Verwaltung der unterschiedlichen Travianversionen überlegt. Das Grundsätzliche Problem bisher war, dass es einige Features gibt, die auf manchen Welten aktiv sind und auf manchen nicht. Bei TK sind das Nachtfrieden & Cropdiet (frühere Beispiele sind KAM, Menhire und die alte Umsiedlung, die sind aber mittlerweile auf allen Servern aktiv / inaktiv). Bei T:L sind das eben deutlich mehr, z.B. Das 2019er Balancing Update, neue Völker, neues Bündnis System, Ancient Europe Map, Ancient Powers oder Artefakte, ...

Um das in den Griff zu kriegen, benutze ich keine einzelne Versions-ID mehr für einen Server, sondern habe 16 Flags, die ich aus- und einschalten kann, in Kombination mit der Versionsnummer & Speed. Damit werde ich BT bequem sagen können, welche Features aktiv sind und welche nicht.

Außerdem habe ich mir noch eine Änderung überlegt. Bislang war es so, dass Binary die Spielversion und damit z.B. alle Gebäudedaten abhängig von der Spielwelt macht. Wenn man Berechnungen für einen TK 3x Speedserver durchführen möchte, muss man einen auswählen. Gibt es keinen hat man eben Pech. Das System habe ich jetzt überarbeitet. Die Version, Speed und aktivierte Features sind standardmäßig die der Spielwelt. Allerdings kann man diese Parameter jetzt permanent ändern. So kann man z.B. T:L Berechnungen durchführen, während man gerade eine TK Welt ausgewählt hat oder Berechnungen für eine 8x Speed durchführen, auch wenn es gerade keine davon in BT gibt. In Zukunft soll diese Änderung auch zum BT Server übertragen werden, damit sie nach einem Reload der Seite (oder dem Aufruf eines anderen Tools) erhalten bleibt. Sobald man die aktive Spielwelt wechselt, werden die Änderungen verworfen und die Standardwerte für die Spielwelt genutzt.

Der Dialog für den Versionswechsel sieht derzeit so aus:

• Man kann einen der Standardwelttypen auswählen, das sollte für die meisten Fälle ausreichend sein.
• Ist eine Konfiguration nicht von den Standards abgedecke, kann man einzelne Features ein- und ausschalten. Für den aktuellen NYS Server von T:L könnte man also z.B. das neue Bündnissystem und die neuen Völker auswählen, obwohl es keine PTP Welt ist.
• Wird die Basisversion geändert (T:L/TK), werden die Standardhaken gesetzt.
• Bei der Servergeschwindigkeit steht in Klammern dazu, wo man auf diese Speed in der Regel antrifft

8x Speed gab es mal für eine T3.6 Welt, deswegen ist die hier mit drin.
Gebt hier gerne euer Feedback im Feedbackthread, ob ich 4x, 6x, 7x, 9x und 10x noch einfügen sollte, oder nur tatsächlich vorkommende Faktoren auflisten soll. Bin da etwas unentschlossen.

mfg,

Be2-e4

Guten Abend,

heute habe ich mir ncoh ein paar Gedanken dazu gemacht, wie ich Parser in Zukunft realisieren möchte. Bisher lief es für beide Versionen unterschiedlich und die TK Parser waren extrem unzuverlässig und haben wenn nur in Chrome (und darauf basierenden Browsern) funktioniert. Für T:L habe ich den Quellcode der Seite kopieren und einfügen lassen. Das war die simpelste Methode, weil ich dadurch Zugriff auf den angezeigten HTML Quellcode hatte und dort nunmal alle Informationen stehen, die man sieht. Der Quellcode wurde dann zum Server geschickt und serverseitig geparst. Den Parser dann zu bauen war eine reine "suche das hier, die Zeichen bis zum nächsten Anführungszeichen sind dann der Wert, den du willst"-Sache. Nachdem das die alte Variante war, die ich Parser implementiert habe, habe ich die für TK versucht zu übernehmen. Quellcode copy & pasten ging aber nicht, da man die Seite nur einmalig lädt und alles danach dynamisch nachgeladen wird. Also habe ich ein div-Element genommen, das HTML Attribut contenteditable auf true gesetzt und den Nutzer da etwas reinparsen lassen. Dann habe ich mittels div.innerHTML den Quellcode davon ausgelesen und zum Server schicken lassen, um ihn zu parsen.

Folgende Probleme ergeben sich bei der alten Lösung:

• Quellcode copy & pasten für T:L ist aufwändiger für die Nutzer, als einfach die Seite zu copy & pasten
• Copy & paste in ein contenteditable div Element hat bei unterschiedlichen Browserrenderengines unterschiedliche Ergebnisse erzeugt, ich hätte also für jeden Browser einen eigenen Parser schreiben müssen (oder nur Chrome unterstützen - was ich getan habe)
• Die Quellcodes zum suchen & auslesen sind extrem unübersichtlich und für große Parser (z.B. KB Parser) extrem lang und noch viel unübersichtlicher
• Serverseitige Berechnung - kein großer Kontrapunkt, aber einer
• Die Parser zu entwickeln war extrem Zeitaufwändig und ehrlich gesagt unglaublich nervtötend, die zu debuggen noch 100x schlimmer

Also habe ich mir für BT2.0 etwas mehr Wissen dazu angelesen und habe folgende Variante gerade eben erfolgreich in Firefox & Chrome getestet:

Es gibt ein div mit contenteditable true, wie bei den früheren T:L Parsern auch schon. Allerdings greife ich die Daten nicht nach dem paste via div.innerHTML ab, sondern fange die Daten im onpaste Event ab - zu dem Zeitpunkt sind die Daten in beiden Browsern gleich. Als kleiner Bonus, kann ich relativ simpel auch die alte Variante für T:L mit Quellcode kopieren möglich machen, indem ich im kopierten Text (event.clipboardData.getData("text"), statt .getData("text/html")) nach <!DOCTYPE suche. Vorhanden bedeutet, dass ein Quellcode kopiert wurde; nicht vorhanden, dass die Seite kopiert wurde. Jenachdem nutze ich jQuerys parseHTML Methode auf getData("text") oder getData("text/html"), um den HTML Code zu parsen und ihn anschließend mit jQuery extrem effizient (im Sinne von wenig Quellcode schreiben) zu durchsuchen.

Beispielhaft mein proof-of-concept Quellcode für das Parsen der Travian: Legends Kulturpunkteübersicht, der für jedes Dorf die newdid und verbleibende Festdauer zurückgibt, funktioniert in Chrome und Firefox jeweils mit Seite copy & paste oder Quellcode copy & paste:

function pasted(e) { // Event Handler fuer das onpaste Event
    var isSourceCode = e.clipboardData.getData('text').indexOf("<!DOCTYPE") >= 0;
    
    var elem;
    if(isSourceCode) 
        elem = $.parseHTML(e.clipboardData.getData("text"));
    else
        elem = $.parseHTML(e.clipboardData.getData("text/html"));
    elem = $(elem);

    // Ab hier beginnt der Code, der die eigentlichen Daten ausliest. Der Code darueber ist fuer alle Parser gleich und bereitet die Daten auf die Verarbeitung vor.

    console.log(elem.find("#culture_points tbody").find("tr.hl, tr.hover").map((i, x) => ({ village: $(x).find(".vil a").attr("href").split("=")[1], celebration: $(x).find(".timer").attr("value") })));
}

Einen (kleinen) Drawback gibt es für T:L allerdings. Die Mouseovertexte werden beim Laden der Seite aus den HTML Elementen gelöscht und sind daher nur auslesbar, wenn man den Quellcode parst. Das betrifft allerdings nur sehr wenige Parser, nämlich nur den Kulturpunkteparser (den dafür an zwei Stellen). Das ist allerdings kein großes Problem - denn wie gesagt, parst man den Quellcode, klappt es.

Ja, der Quellcode hat keine Fehlerbehandlung. Ja, die letzte Zeile ist recht unübersichtlich. Wie gesagt. Proof of concept. Das bedeutet, ich wollte gucken, ob ich das überhaupt so machen kann. Es klappt, das weiß ich nun, also kann ich dieses Konzept in gut programmiert in Binary-Tools 2.0 implementieren.

mfg,

Be2-e4

Der letzte Blogpost ist nun eine Weile her, das liegt allerdings nicht nur an meiner Schreibfaulheit, sondern auch daran, dass ich nicht wirklich viel am Stück programmiert habe in den letzten wenigen Wochen. Aber auch Kleinigkeiten summieren sich auf, und diesen ist dieser Post gewidmet.

Nummer 1: Ich habe ein paar der Vorschläge von iTob implementiert: Erstens, die Option die Servergeschwindigkeit benutzerdefiniert festzulegen und zweitens, dass das Mischen von T:L und TK Features/Versionen erst mittels Schalter aktiviert werden muss, bevor es möglich ist:

Radiobuttons in die UI zu implementieren steht noch auf der ToDo, by the way.

Nummer 2: Ich habe das Parser Konzept vom vorherigen Post in Binary-Tools implementiert. Es wird eine Parser-Box geben, in die man wahlweise die Seite oder den Quellcode (bei T:L) einfügen kann. Diese färbt sich grün, wenn alles geklappt hat und rot, wenn etwas nicht funktioniert hat. Das entsprechende Tool gibt dann (im Soll-Zustand jedenfalls) eine entsprechende Meldung aus, was falsch gelaufen ist.

Ein Nebeneffekt davon, dass ich die Daten beim paste-Event abfange ist, dass man keinen Button benötigt, um das Parsen zu triggern. Es wird sofort geparst, sobald man auf einfügen drückt. Ich könnte das ändern, wäre allerdings ein bisschen aufwändig, weil ich die Daten erst zwischenspeichern müsste, bevor ich sie parse (oder nach dem Parsen zwischenspeichern bevor ich sie verarbeite/anzeige). Meinungen, am besten mit Begründung, gerne in den Feedbackthread.

Nummer 3: Ich habe Chart.js eingebunden. Das steht hier nur zur Vollständigkeit und für Nummer 4, das war ein Aufwand von 2 Minuten.

Nummer 4: Mit den beiden neuen Sachen habe ich hauptsächlich zum ausprobieren einen Kulturpunkteparser implementiert:

https://i.gyazo.com/4e3a73c762947bf2346b548d9a4784fa.png

• Die Rathausstufen sind frei editierbar (das ist in TK auch notwendig, weil die dort nicht in der KP Übersicht stehen - in T:L stehen sie dort im Mouseover)
• Es fehlt derzeit noch eine UI, um die aktuellen KP einzutragen. Das ist für TK notwendig, in T:L kann man die aktuellen KP aus der Fortschrittsleiste auslesen:
  

• Die Festart soll später eine Dropdown werden
• Die benötigten Ressourcen pro Stunde sollen noch angezeigt werden
• Die 0 Einträge bei KP Passiv sind kein Bug, sondern Dörfer im grauen Gebiet in T:L, die produzieren nichts passiv: https://i.gyazo.com/e59fc3dc89b79204221e0227e5791ecd.png
• Das Diagramm soll später auch Kunstwerke und Helme berücksichtigen, dazu fehlt im Moment allerdings die Eingabemöglichkeit
• Die roten Linien in der Kulturpunkteprognose repräsentieren die benötigten Kulturpunkte für die nächsten paar Dörfer
• Die Prognose erhält noch eine Tabelle, die die nächsten Dörfer konkret angibt
• Die Prognose erhält eventuell noch jeweils eine Prognoselinie für "keine Feste", "nur kleine Feste", "immer große Feste", die man an/aus schalten kann, damit man den Effekt von Festen besser wahrnimmt
• Die ganzen Informationen sollen später in einzelnen Tabs ausgelagert werden: Übersicht (die Tabelle links und das Kuchendiagramm), Rohstoffkosten (eine Tabelle mit den Kosten pro Stunde, eventuell Ressourcen pro Kulturpunkt, je Dorf eine Zeile), Prognose (das Prognosediagramm mit den erwähnten Erweiterungen + die oben erwähnte genaue Tabelle)

Um die Prognose sinnvoll berechnen zu können, muss das Tool natürlich wissen, wie viele Kulturpunkte man für das wie vielte Dorf benötigt. Die Formel dafür habe ich mittlerweile herausgefunden, sodass ich nicht mehr gefühlt hundert konstante Datenarrays habe:

• Travian: Legends 1x Speed: 1600 * (Dorf - 1) ^ 2,3 + 400 * (Dorf - 1) ^ (-1,8), gerundet auf volle Tausender
• Travian: Legends alle anderen: 1600 * (Dorf - 1) ^ 2,3 / Serverspeed, gerundet auf Hunderter
• Travian Kingdoms habe ich leider noch keine Formel. ((Dorf - 4) * (Dorf - 3) / 2 + 1) * 10.000 ist ab Dorf 4 die beste Näherung bisher, allerdings ab dem 9. Dorf etwas daneben. Wenn da jemand Lust hat, sich Gedanken drüber zu machen, ist er herzlich dazu und mir die Formel per PN oder im Feedbackthread zu posten eingeladen.
  KP pro Dorf: 1.000 5.000 10.000 20.000 40.000 70.000 110.000 150.000 210.000 270.000 350.000 430.000 530.000 640.000 750.000 880.000 1.030.000 1.180.000 1.350.000 1.530.000 1.720.000 1.930.000 2.150.000 2.390.000 2.640.000 2.900.000 3.170.000 3.470.000 3.770.000 für Dorf 2 3 4 ... 30.

Sonstige Kleinigkeiten:

• Der Ausbildungsrechner berücksichtigt jetzt die Servergeschwindigkeit korrekt. Das war eigentlich eie Aufräumarbeit, denn die Formel stand noch im Toolquellcode, anstatt in der früher mal erwähnten zentralen Stelle für Formeln. Das ist jetzt behoben.
• Der Ressourcenausbaurechner berücksichtigt jetzt den "T:L 40% Produktionsbonus"-Flag

mfg,

Be2-e4

Guten Morgen,

meine Klausur am Montag ist vorbei, nice. Das bedeutet für Binary-Tools allerdings, dass ich wahrscheinlich nur am Wochenende daran arbeiten kann, unter der Woche bin ich auf Arbeit eingespannt. Da ich featuretechnisch im Moment also keine wirklichen Neuigkeiten habe, poste ich jetzt und, wenn es zumindest bei ein paar Leuten gut ankommt, auch hin und wieder in Zukunft ein paar meiner Gedanken und Pläne für Binary-Tools 2.0. Realistisch gesehen werde ich wahrscheinlich nicht dazu kommen alle zu implementieren, erst recht nicht, wenn ich sie im Release dabei haben möchte. Freut euch daher lieber nicht zu früh, wenn ihr ein paar der Ideen cool findet. Lasst aber sehr gerne im Feedbackthread eure Meinung dazu da: [Feedbackthread] Binary-Tools 2.0 Entwicklungsblog

Binary-Tools Gruppen

Fangen wir mit dem ersten Konzept an. Einige von euch, die mit mir mal eine Runde gespielt haben, wissen sicherlich, wie oft ich über Getters Einsatzplaneditor fluche, weil der etwas buggy ist. Wahrscheinlich ist es daher keine große Überraschung, dass ich Getter auf diesem Gebiet Konkurrenz machen will und werde und eine eigene Truppentoolsammlung veröffentliche.

Zunächst hat jeder Nutzer sein eigenes Profil auf der Spielwelt. Dort kann er seine Truppendaten eintragen und seinen Avatarnamen hinterlegen und mit Hilfe des TK Login Mechanismus verifizieren.

Dann wird man auf Binary-Tools Gruppen anlegen können. Mittels Joinlink oder Einladung mittels Binary-Tools Accountnamen können andere Spieler in die Gruppe eingeladen werden. Member teilen ihre Truppeninformationen, KP Angaben, Turnierplätze, Truppendörfer, etc., mit der Gruppe. Member, die entsprechende Rechte haben (also, im Grunde die Allyleader) können diese Informationen einsehen und damit planen.

Einsatzpläne

Einsatzpläne wird es natürlich auch geben. Innerhalb einer Gruppe kann man einen neuen Einsatzplan anlegen. Dieser ist dann völlig frisch und unabhängig von eventuell früheren Einsatzplänen oder anderen Einsatzplänen, die parallel gelaufen werden. Man kommt sich also nicht in die Quere, wenn zwei Leute für zwei Tage zwei EPs planen. Der Ersteller des Einsatzplans kann (muss jedoch nicht) manuell festlegen, welcher Binary-Tools Account welche Einsätze sieht. Beispiele: Der Planer kann einen verdächtigen Dual von dem EP ausschließen, oder er kann einem Sitter Sichtungsrechte für Späh- oder Deffpläne geben. Standardmäßíg sieht jeder Binary-Tools Account die Einsätze des Avatars, den er zum Zeitpunkt des Planens hinterlegt hat - ändert ein Spion seinen Avatarnamen 50x nachdem der EP gespeichert ist, sieht er also nichts. Das bedeutet, man muss diese detailierten Anwendungsmöglichkeiten nicht kennen und kann ganz normal Einsatzpläne planen, wie man es von Getter gewohnt ist.

Außerdem werden Einsatzpläne nicht gruppengebunden sein. Das bedeutet, man kann auch Einsatzpläne erstellen, ohne dafür eine eigene Gruppe anlegen zu müssen. So kann man beispielsweise Adelungen für seinen eigenen Account problemlos planen. Man wird andere Binary-Tools Accounts zu Einsatzplänen hinzufügen können, sodass man die privaten Einsatzplänen mit seinen Duals teilen kann, oder zum Beispiel zu zweit auf Adeltour gehen kann, ebenfalls ohne dafür eine Gruppe anlegen zu müssen. Zu guter Letzt kann man Gruppen zu dem Einsatzplan hinzufügen, das ist dann im Grunde das gleiche, als würde man alle Mitglieder der Gruppe zum Plan hinzufügen. Beachte, dass die Truppenzahlen nicht geteilt werden, wenn Spieler zum EP hinzugefügt werden. Einen "privaten" Einsatzplan zu erstellen und anschließend eine Gruppe hinzuzufügen, ist das gleiche, wie einen Einsatzplan für eine Gruppe zu erstellen.

Es wird auch möglich sein, mehr als eine Gruppe zu einem Einsatzplan hinzuzufügen. So können zum Beispiel gemeinsame Einsatzpläne in einem Bündnis erstellt werden, ohne, dass alle Mitglieder beider Königreiche in eine Gruppe joinen müssen. Rechtemäßig wird es so sein, dass der Ersteller des Einsatzplans EP-Rechte in der Gruppe haben muss, um die Gruppe zu dem Einsatzplan hinzuzufügen.

Ranking

Vielen Spielern gefällt das Ranking. Viele Leader mögen es nicht, weil es Spys die Möglichkeit gibt, die Truppen der Ally auszuspähen. Getters Methode die Truppenzahlen zu verbergen, ist da nur seminützlich, als Spion kann man seine Truppen einfach 50x ändern, bei sagen wir 5k anfangen und in 5k Schritten hochgehen und jedes mal gucken, was sich geändert hat. Ich habe vor, das Ranking mit folgenden Vorkehrungen zu implementieren:

• Jeder Member benötigt das Ranking I Recht, um auf das Ranking zuzugreifen
• Ändert ein Member seine Truppendaten "zu oft zu stark", wird ihm das Ranking I Recht automatisch entzogen und die Gruppenadmins benachrichtigt
• Ist ein Member truppenzahlmäßig sehr nahe bei dem Spieler vor ihm (z.B. < 10% Abstand), wird ihm die Differenz angezeigt. Das ist standardmäßig aktiviert, kann jedoch deaktiviert werden.
• Ebenfalls können die Admins konfigurieren, ob man mit dem Ranking I Recht die Truppenzahlen sehen soll (Standard: Nein)
• Member, die entweder das Recht alle Truppenzahlen zu sehen oder das Ranking II Recht haben, sehen das Ranking mit Truppenzahlen

Das bedeutet: Entweder man weist Membern standardmäßig das Ranking I Recht zu (dann ist das Ranking mitsamt allen Konfigurationsoptionen aktiviert) - oder eben nicht, dann ist das Ranking für die Member deaktiviert. Die "Exploits" über das Ranking die Truppenzahlen der Ally zu erspähen sollten eliminiert sein, und dennoch haben die Member mit der 10%-Regel einen Ansporn, mehr Truppen zu bauen, um den Spieler vor ihnen einzuholen.

Außerdem wird das Ranking nicht wie in Getter mittels Getreideverbrauch laufen, sondern mittels Kampfkraft, eventuell optional Getreideverbrauch. Die Kampfkraft spiegelt die eigentliche Off- und Deffmenge viel genauer wieder, als ihr Getreideverbrauch - insbesondere bei Römeraccounts, die in Deffrankings mit Spähern regelrecht cheaten können und in Offrankings einfach nur gelitten haben.

Feedback und Ideen hierzu sind sehr gerne erwünscht.

Das war es jetzt erstmal für heute, Konzepte und Ideen habe ich zwar noch einige, aber mein Installer für die Arbeit ist gerade fertig geworden. :p

Feedback wie immer sehr gerne im Feedbackthread, siehe oben, erwünscht!

mfg,

Be2-e4

Guten Nachmittag,

Wochenende. Zwei Tage ohne Verpflichtungen und ohne schlechtes Gewissen, wenn ich etwas anderes tue als im HomeOffice zu arbeiten oder zu lernen. Die perfekte Zeit um über ein weiteres Konzept zu sprechen, welches ich gerne in Binary-Tools implementieren möchte. Nochmal: Im Gegensatz zu den ersten Blogposts unterscheidet es sich in dem Sinne, dass diese Konzepte Ideen und Gedanken von mir sind, die ich auf Binary-Tools gerne implementieren möchte. Ich habe noch nicht angefangen, sie zu implementieren, und kann auch nicht mit Sicherheit sagen, ob sie es in den ersten Release schaffen. Nachdem das geklärt ist, können wir anfangen.

Nachdem ich vor ein paar Wochen mein Trainingslagerbuch verschickt habe, das ich zuvor einige Monate geschrieben und daran gearbeitet hatte, ist mir ein gewisser Lehrgedanke auch bei der Entwicklung von Binary-Tools geblieben. Meine Vision ist, dass nicht nur fortgeschrittene Spieler meine Tools nutzen können, sondern auch auch zahlreiche neue Spieler und Anfänger auf Binary-Tools einfinden, um etwas über das Spiel zu lernen und sich etwas über das Spiel lehren zu lassen. Deswegen möchte ich damit anfangen, Lehrmodule in manche Tools zu implementieren. Darunter verstehe ich, dass man die Lehrkomponente, welche ich Basi nennen werde, in Anlehnung an Basiflow*, als eigenes Tool hat und dort aktivieren kann. Sobald Basi aktiv ist, fängt sie an, Informationen über den Account des Spielers einzuholen:

• Anzahl der Dörfer und Städte (aus der offiziellen API)
• Anzahl und Level der Truppen (aus den Truppentools)
• Anzahl und Stufe der Rathäuser und Art der Feste (aus dem Kulturpunkterechner)
• Accountproduktion (aus dem Accountproduktionsrechner)
• Eventuell noch andere Informationen, die sie beim Spieler einfach anfragt

Darauf basierend soll sie zwei Sachen tun:

1. Den Spieler über grobe (ich nenne es mal) Fehler aufklären.
   Beispiele: Aufklärung über die Wichtigkeit von Festen, Levelung von Truppen im Mid- & Lategame, Vor- und Nachteile von Städten, Vor- und Nachteile von Äxte/EI/Blitzeoffs, ...
2. Dem Spieler bei Bedarf Quests geben, die er erfüllen kann, wenn er nicht weiß, was er gerade mit seinem Account anfangen soll.
   Beispiele: HD Felder auf Stufe 15 bauen, eine zweite Oase annektieren, ein weiteres Deffdorf errichten, Werkstatt auf 20 bauen, ...

Die Hilfeartikel, die Basi vorschlägt und anzeigt, werden natürlich auch ganz normal verfügbar sein. Aber Karten auf den Tisch, nicht viele Spieler sind mehr oder weniger neu in einem Spiel und fangen schon an sich durch sämtliche Hilfeseiten auf einer Drittseite zu schlagen und überlegen sich bei jeder, inwieweit sie die Informationen auf ihren Account beziehen können. Ich denke, wenn Basi solche Artikel als Hintergrundwissen und Zusatzinformation zu ihren Vorschlägen anzeigt, wird ein neuer Spieler viel mehr Informationen daraus mitnehmen können.

Lasst mich gerne im Feedbackthread wissen, was ihr von diesem Konzept haltet. Ich bin gespannt auf eure Gedanken dazu.

mfg,

Be2-e4

* Basiflow steht für Binary (wegen Binary92, einem Nicknamen von mir) Artifical Super Intelligence (als Referenz zu Person Of Interest, dort werden Samaritan und die Maschine desöfteren als ASI bezeichnet) Flow (im Sinne, dass etwas wie am Schnürchen läuft, vgl. Workflow). Basiflow war als vollständig autonome Kampfmaschine geplant, die abhängig von Onlinezeiten unserer Member autonom bis zu 4 EPs pro Tag selbstständig schreibt und ins Getter einpflegt. Sie ist nie fertig geworden, hat allerdings einige Einsatzpläne bis auf minimale menschliche Hilfe autonom geplant.

Guten Abend,

die letzten Tage habe ich an einem neuen Tool gearbeitet, das mir sehr wichtig ist. Eine brauchbare Karte für Travian. Über diese Karte und ein Konzept von Binary-Tools Gruppen, das damit irgendwie verbunden ist, möchte ich heute sprechen schreiben.

Zuerst die Karte. Von der Optik her habe ich mich an der Original Travian Kingdoms Karte orientiert. Screenshot von der aktuellen InDev Version:

Was sie bisher kann:

Sie kann mit der Maus verschoben werden, sogar recht performant, und man kann (fast) nach Belieben zoomen. Ein Kartenfeld ist 1 : 1 genausogroß wie auf der Originalkarte, nämlich 126 Pixel breit und 68 Pixel hoch. Der Zoom ist stufenlos (d.h. man hat im Gegensatz zu dem Original mehr als drei Zoomstufen). Auf der nähesten Zoomstufe ist ein Feld 315 x 170 Pixel groß, auf der weitesten nur noch 8.4 x 4.5 PIxel. Die Drehung der Karte habe ich aus Travian übernommen, d.h. wenn man sich auf der Originalkarte in etwa auskennt, findet man sich auf der Binary-Tools Karte problemlos zurecht.

Geplant sind ... viele Sachen.

Ich möchte die Karte nicht nur als eigenständiges Tool anbieten, sondern die Karte in den verschiedenen anderen Tools als eine Art Fenster in Fenster benutzen. Abhängig von dem aktuellen Tool, soll die Karte unterschiedliche Funktionen haben. Beispielsweise möchte ich, dass im Einsatzplaneditor die aktuellen Einsätze mit Pfeilen markiert werden und Start- & Zieldörfer mit Klick auf die Karte ausgewählt werden können. Diese toolspezifischen Features nenne ich Widgets.

Als eigenständiges Tool wird die Karte mindestens folgende Features haben - diese Features werden auch in den anderen Tools, die die Karte nutzen, verfügbar sein:

• Anzeige von Detailinformationen zu dem Dorf bei Mouseover (ähnlich wie in der Originalkarte von Travian)
• Suchfunktion für Dörfer
• Eigene Markierungen, die in allen Tools angezeigt werden
• Anzeige der Königreichsgebiete

Geplant sind außerdem folgende Widgets, die überall verfügbar sind:

• Wegerechner: Ein Startdorf ist auswählbar. Sobald man dann über ein Feld fährt, wird die Distanz zu diesem Dorf angezeigt. Außerdem wird direkt eine Laufzeitberechnung für alle möglichen Truppentypen des Startdorfes durchgeführt, einmal mit TP 0, einmal mit TP 20 und einmal mit dem zuletzt bekannten TP - siehe unten.
• Getreidefeldfinder: 9er und 15er, die den Suchkriterien entsprechen, werden hevorgehoben und ihr Bonus wird (als Text) auf der Karte, auf dem Feld angezeigt. In etwa so (Paintskills):
  
  Display Spoiler

  
• Schatzkammerplaner: Man kann eine Schatzkammergröße (z.B. 500 Einwohner) auswählen und wenn man mit der Maus über die Karte fährt, wird der Einflussradius der Schatzkammer hevorgehoben. Bei Klick wird eine Schatzkammer gesetzt und man kann eine weitere setzen. In etwa so stelle ich mir das vor, again, Paintskills:
  
  Display Spoiler

  
  Orange in der Mitte: Mausposition, Dorf auf dem die Schatzkammer stehen soll. Hellgrün: Einflussradius.

Wenn ihr gute Ideen für Widgets und Features habt, schreibt sie mir in den Feedbackthread: [Feedbackthread] Binary-Tools 2.0 Entwicklungsblog

Das zweite, über das ich heute schreiben möchte, ist ein weiteres Konzept für die Gruppen. Ich möchte, dass Binary-Tools nicht nur für Offplanung oder dergleichen eingesetzt wird, sondern, dass die Königreiche in Binary-Tools ihr Wissen eintragen können. Alles, was man irgendwie verwerten kann, soll auf Binary-Tools verewigt werden können. Dazu gehören zum Beispiel:

• Truppenzahlen der Feinde: Offdörfer, Offgrößen, Deffdörfer, Späherdörfer, Standdeffmengen
• Ausrichtung der Feinde (Off/Deff)
• Positionen der Schatzkammern und deren Größe in Schätzen (ja, das sieht man auf der Originalkarte, steht aber nicht in der offiziellen API)
• Alle Arten von Kampfberichten
• Turnierplätze der Gegner (die man über Deffanalyse rausgefunden hat)

Alle diese Daten sollen einer Gruppe zugeordnet sein. Das heißt, Spieler können die Gruppe mit Informationen füttern. Genau diese Informationen sollen dann von verschiedenen Tools - als prominentestes Beispiel sei die Karte genannt - genutzt werden. Zum Beispiel könnte man sich auf der Karte die Offdörfer der Feinde mit der Offgröße hevorheben lassen, oder die Laufzeitberechnung in der Karte könnte den zuletzt bekannten Turnierplatz nutzen, um die Laufzeit anzuzeigen. Außerdem sollen diese Daten zentral für die KR Führung (und ggf. normale Member, jenachdem) einsehbar sein.

Um Trolle zu stoppen, wird das Eintragen der Daten an das Rechtesystem gekoppelt sein, die Gruppenadmins können einem Spieler die Rechte zum Eintragen von Truppenzahlen, Kampfberichten, etc., also auch einfach entziehen. Und wenn ich schon dabei bin, wird man die Einsichtsrechte auch entziehen können. Standardmäßig soll aber jeder alles eintragen und einsehen können - die Wissensdatenbank soll eine Gemeinschaftsarbeit sein, bei der sich auch Statthalter beteiligen können.

So, das wars für heute.

mfg,

Be2-e4

Guten Morgen,

Miniupdate zum Wegerechnerwidget der Karte (siehe letzter Post):

GIF (Gyazo macht die Qualität bisschen kaputt tho): https://i.gyazo.com/135093404ab009ffe8a6c0526c607f9d.mp4

Linksklick = Dorf als Startdorf auswählen

Mouseover = Weg- & Laufzeitberechnung für das überfahrene Feld

mfg,

Be2-e4

Guten Abend,

nochmal ein kleines Update zur Karte:

1) Ich habe einen Schatzkammerplaner implementiert. Man kann die gewünschte Schatzkammergröße auswählen, anschließend folgt ein Schatzkammergebiet dem Mauszeiger. Mittels Linksklick kann auf das aktuelle Feld eine Schatzkammer gesetzt werden, die dann dort bleibt. Wählt man "keine/löschen" aus, wird bei Linksklick die Schatzkammer auf dem geklickten Feld gelöscht, falls vorhanden. Geplant ist noch eine Auswahlmöglichkeit für die Hervorhebungsfarbe, damit man in der Planung zum Beispiel unterschiedliche Spieler unterschiedlich markieren kann.

Sieht derzeit so aus, in blau das Einflussgebiet und in Orange die Schatzkammer selbst.

2) Es gibt jetzt eine Schnellinfo bei Mouseover über ein Feld. Diese ist an das Original von Kingdoms angelehnt, jedoch um ein paar Informationen erweitert. Links Binary-Tools und rechts Original:

In der Kopfzeile stehen die Koordinaten "( -68 | -1 )", der Dorfname ("village -68|-1") und die Einwohnerzahl (359). Städte und Hauptdörfer werden durch ein entsprechendes Icon vor dem Einwohnericon symbolisiert, links HD, rechts Stadt: pasted-from-clipboard.png

• Bei besiedelbaren Feldern, Dekofeldern und Oasen steht dort "Freies Feld", "Dekofeld" und "Oase"
• Die Einwohnerzahl bei Nicht-Dörfern ist 0 und [ToDo] wird für Oasen durch deren Bonus ersetzt

Nach der Trennlinie steht in der ersten Zeile der Besitzer des Dorfes und danach ggf. in Klammern der Name seines Königreichs. Diese Zeile wird für Nicht-Dörfer ausgeblendet.

In der zweiten Zeile steht, in wessen Einflussgebiet dieses Feld liegt. Sozusagen, in wessen Grenzen es ist. Für Dörfer ist das das Königreich, an das Tribute gezahlt wird.

In der dritten Zeile steht die Feldverteilung des Dorfes, also ob es sich zum Beispiel um ein 9er oder 15er handelt. Diese Zeile wird für Dekofelder und Oasen ausgeblendet.

Ich bin mir noch nicht sicher, wo genau ich dieses Mouseoverfeld platzieren möchte. Im Spiel ist das Feld oben in der Mitte. Die ein oder andere Stimme meinte zu mir aber, dass das dort etwas stört, wenn man sich in der Nachbarschaft umschauen möchte. Im Moment ist es bei in der linken oberen Ecke, das wiederum hat den Nachteil, dass dadurch Wegerechner und Schatzkammerplaner (bzw. Widgets allgemein) etwas nach unten verdrängt werden. Auf die rechte Seite der Map möchte ich später noch Einstellungen und sowas hinpacken, die Option ist also auch eher nur semigut.

Meinungen? Feedbackthread: [Feedbackthread] Binary-Tools 2.0 Entwicklungsblog

Im Moment ist es am realistischsten, dass ich es standardmäßig in die Mitte setze und mittels Einstellungen nach links oder rechts versetzen lasse.

3) Man sieht es schon im Screenshot oben: Oasen werden jetzt ebenfalls angezeigt. Aber nach wie vor alles zufallsgeneriert, BT2.0 hat derzeit noch keine Möglichkeit an die Ingame Daten zu kommen.

mfg,
Be2-e4

Guten Abend,

heute geht es um die (Ingame) Datenspeicherung und die Aktualisierung der Ingamedaten. Für diejenigen, die nicht wissen, wie das funktioniert:

Kingdoms hat eine offizielle Schnittstelle, über die Toolseiten wie Binary-Tools verschiedene Ingame Informationen erhalten können. Diese wird täglich aktualisiert, ich denke so gegen Mitternacht. Das bedeutet, dass Binary-Tools jeden Tag nach Mitternacht - bei Binary-Tools 1.x war das um 2:30 für TK - die Ingame Daten abholen und in die eigene Datenbank einpflegen muss. In BT1 hatte ich dafür ursprünglich einen PHP Cronjob, aus vielen Gründen dann später auf ein eigenständiges C# Programm umgestellt. Gespeichert wurden die Daten ursprünglich in fünf Tabellen (Felder, Oasen, Dörfer, Spieler, Allianzen).

Mit dem alten Speicherformat ergaben sich ein paar Probleme, denn alle historischen Daten waren in einer Tabelle gespeichert. Auf volleren Welten, wie zum Beispiel dem Finalserver von dem Travian: Legends Turnier 2018, waren es Millionen von Zeilen für die Dorftabellen. Einige Tools haben damit nicht mehr so wirklich umgehen können, zum Beispiel die Inaktivensuche, weil die hat im Grunde einen Join auf sich selbst durchgeführt, halt mit zwei unterschiedlichen Teilmengen der Tabelle. Trotzdem nicht sonderlich performant, daher gibt es seit einiger Zeit auf BT1 einen Inaktivencache. Aus ähnlichen Gründen kam dann noch ein Dorfbesitzänderungscache hinzu, in dem alle Neugründungen, Eroberungen und Zerstörungen von Dörfern gecached worden sind.

In Binary-Tools 2.0 werden die Daten nun in 13 Tabellen pro Welt abgespeichert:

• Je eine Tabelle für die historischen Daten von Dörfern, Spielern, Allianzen und Königreichen (letztere wurden in BT1 nicht so wirklich erfasst)
  Wenn ein Tool mit Daten arbeitet, die nicht von dem hier und jetzt sind (beispielsweise Entwicklungsdiagramme, Inaktivensuche, ...), greifen sie hierauf zurück
• Aktuelle Daten von Dörfern, Spielern, Allianzen, Königreichen, Oasen und Feldern
  Im Grunde eine Untermenge der historischen Daten, jedoch nur für den heutigen Tag. Oasen und Felder haben keine historischen Daten, weil ihre Werte ohnehin konstant sind, bis auf Gebietsänderungen, dazu unten mehr.
• Cache für Einwohnerverlauf von Spielern über die letzten 7 Tage ("Inaktivencache")
• Cache für Dorfbesitzänderungen (siehe oben)
• Cache für Getreidefelder und deren Boni für den Getreidefeldfinder

Felder haben nur eine Sache, die sich mit der Zeit verändert, nämlich das Gebiet, zu dem sie gehören. Alle anderen Informationen (Koordinaten, welche Art von Feld, Ressourcenverteilung) sind konstant.

Im Moment werden Felder nur einmal in die Datenbank geladen und diese Tabelle wird nur aktualisiert, wenn es mehr Felder werten (also eine automatische Kartenerweiterung passiert ist).

Das hat den Vorteil, dass die Updater schneller fertig sind, weil sie nicht für jede Welt 10-20k Felder beinahe redundant in die Datenbank eintragen müssen. Außerdem speichere ich für sie logischerweise keine historischen Daten, d.h. der Datenmüll hält sich in Grenzen.

Das hat jedoch zwei Nachteile. Die "lazy update"-Methode sorgt dafür, dass ich die aktuellen Königreichsgebiete nicht kenne und die "keine History"-Methode sorgt dafür, dass ich den Verlauf der KR Gebiete nicht kenne (zum Beispiel könnte ich mir ein Tool vorstellen, dass in einer Art Diashow die Ausbreitung eines KR darstellt).

Ich denke, ich werde irgendwann auf das "lazy update" verzichten, sodass ich z.B. in der Karte Zugriff auf die aktuellen Königreichsgebiete habe. Die "keine History"-Methode werde ich aber höchstwahrscheinlich beibehalten, solange mir kein wirklich cooles Tool dazu einfällt.

Ich bin übrigens kein Profi in Sachen Datenbanken. Wie man sicherlich merkt. Ich könnte mir vorstellen, dass MySQL 8 - die Version, die ich benutze - bequemere und elegantere Möglichkeiten liefert um einen Teil einer Tabelle zu "cachen", als die Daten tatsächlich in einzelne Tabellen auszulagern. Wenn jemand sich damit auskennt und Tipps hat, gerne her damit, entweder im Feedbackthread oder per PN.

Die Datenbank liegt auf dem Live-Server übrigens auf einer SSD. Eine RAM-Disk als Alternative geht auf dem Server leider nicht, das habe ich schon probiert und mit dem Support darüber gesprochen. Kompliziertere Lösungen, wie z.B. ein eigenes Programm zu schreiben, das die Daten im RAM hält und mit dem PHP kommuniziert, kommen für mich nicht infrage.

mfg,

Be2-e4

Guten Abend,

ich habe mittlerweile eine Möglichkeit erstellt, auf die Ingame Daten von den Tools aus zuzugreifen. Damit habe ich die Karte aktualisiert:

• Benutzt jetzt richtige Ingame Daten, aktuell statisch einer hardkodierten Welt, später natürlich die Daten der aktuell ausgewählten Welt. Es gibt im Moment aber noch keine ausgewählte Welt in dem Sinne.
• Zeigt nun auch die Landschaften auf der Karte an
• Koordinatenlinien sind weniger herausstechend
• Im Grunde sieht die Karte jetzt ziemlich 1 : 1 wie die Ingame Karte aus, bis auf kleine Abweichungen in Tooltips

Bis auf ein paar Feinschliffe (z.B. leere Klammern bei KR losen Spielern) ist das Grundgerüst soweit also schonmal ganz akzeptabel:

mfg,

Be2-e4

Guten Abend,

heute habe ich ein bisschen an der neuen Spielweltübersicht gearbeitet. Wie in Binary-Tools 1.8 wird BT2 über eine Liste aller unterstützten Spielwelten verfügen. Das ist im Grunde eine Liste von möglichen Spielwelt-URLs. Es wird stündlich geprüft, ob die Liste der Welten online (erreichbar) ist, falls ja wird sie aktiviert, ihre Ingame Daten eingepflegt und auf Binary-Tools zur Verfügung gestellt. Falls nein, wird sie auf BT deaktiviert und ihre Ingame Daten gelöscht, wenn sie länger als 5 Tage offline ist.

In der Spielweltübersicht können die Spieler auf einen Blick sehen, welche Server gerade laufen und auf einen zweiten Blick sehen, welche Server von Binary-Tools unterstützt werden. Das ganze sieht so aus:

Wie ihr seht, werden neustartende Welten durch den Mechanismus ein paar Tage vor ihrem Start erkannt und als "bald startend" markiert. Welten, die zwar eigentlich laufen, aber nicht erreichbar sind (bspw. wegen eines Serverausfalls während der Runde) werden rot markiert und Server, die inaktiv sind ausgegraut.

Kurze Erklärung zu den Spalten:

• Stand von ist der Zeitpunkt, von dem die Ingame Daten sind. Da die offizielle API die Daten täglich auf den Stand von gestern aktualisiert, ist der in der Regel älter als 24 Stunden.
• Update am ist der Zeitpunkt, an dem die Ingame Daten eingepflegt wurden.
• Prüfung ist der Zeitpunkt, an dem zuletzt geprüft wurde, ob die Welt erreichbar ist

Der Rest sollte selbsterklärend sein.

Welche Informationen würdet ihr euch noch wünschen? Lasst es mich wissen: [Feedbackthread] Binary-Tools 2.0 Entwicklungsblog

mfg,

Be2-e4