Not logged inCSS-Forum
Forum CSS-Online Help Search Login
CSS-Shop Impressum Datenschutz
Up Topic Hauptforen / CSS-Forum / komodo13 ist erschienen
- - By Peter Martan Date 2019-05-07 07:51 Upvotes 4
http://talkchess.com/forum3/viewtopic.php?p=798117#p798117
Parent - - By Guenter Stertenbrink Date 2019-05-07 08:43
besser als StockFish fuer multipv > 6 ?
is it confirmed
Parent - - By Peter Martan Date 2019-05-07 09:08 Edited 2019-05-07 09:59
Das glaub ich persönlich nur bedingt, nämlich höchsten für kurze TCs, werd's aber auch nicht wirklich ausprobieren, weil würde ich komodoMCTS gegen SF jeweils im 6MV- Mode spielen lassen, müsste ich, damit SF durch den Multivariant Mode nicht zu sehr geschwächt würde, viel Hardware- TC geben, so kriege ich keine Partienzahl zusammen, und bei langer TC hinge das auch wieder noch mehr von der Eröffnungsvorgabe ab, als bei kurzer.

Machbar wäre das in Arena leicht, da kann man jeder Engine als UCI- Option eine beliebige MV- Zahl eingeben, die sie dann auch im game playing verwendet, mache ich hin und wieder, aber nur für einzelne Partien.

Aber dass der MV bei komodoMCTS viel weniger time to depth kostet als bei reinen A-B- Engines, das kann ich bestätigen. Leider bringt er halt auch nicht gleich viel, was time to solution angeht.

Was aber mein Vorgehen bei komodoMCTS jetzt manchmal ist: Forward-Backward () mit komodo default, Hash speichern, MCTS einschalten, (löscht den Hash, leider tut das auch schon das Verändern der Anzahl an MV- Lines, also zuerst Optionen ändern, dann erst hash reload) Zahl an MV- Lines wählen, Hash mit dem entsprechenden Befehl löschen (sonst funktioniert das Reload auch nicht, es sei denn, man hat die Engine ohnehin gerade erst neu geladen), gespeicherten Hash im MCTS- MV- Mode wieder laden, dann wird der vom default komodo gespeicherte vom MCTS- komodo weiter verwendet.

Merke dazu auch noch: Hash- Speichern mit komodo in chessbase- GUIs funktioniert prinzipell nicht, (beim 13er hab ich's noch nicht wieder probiert, bei allen seit dem 10er, ich glaube, bei dem ist's als Option erschienen, ist's aber so, ich hatte darüber schon vor langer Zeit einige Mails mit Mark Lefler, er gibt dem GUI die Schuld, was ich verstehe, weil's mit anderen ja schon funktoniert) die Datenmenge wird im entsprechenden File angezeigt, aber die Einträge, wenn es wirklich welche gibt, sind nutzlos. Laden geht auch in Fritz, Speichern nicht, wohl aber in Shredder und Arena.

Alles klar?


Edit: noch was zum Thema MCTS und Hash- Größe. Bei komodo gibt's ja für den entsprechenden Modus einen eigenen MCTS- Hash. Der ist default nur 128 Mb groß, in der neuen Readme steht dazu jetzt das:
Zitat:

If you wish to analyze for long periods of time on a many core machine, you can increase the size of the Monte Carlo tree in memory by raising the MCTS Hash value. A rough estimate on current (2019) processors is each core can expand about 30 Monte Carlo nodes a second, but can vary a lot when the tree has many draws or mates and climb higher to perhaps 1000. Each node is 40 bytes. So it you wanted to analyze with say 8 cores for 5 hours, you should set MCTS Hash to 1000 x 40 x 8 x 3600 x 5 (secs in an hour)/ 1000000 or about 576 megs. The sum of MCTS Hash plus regular Hash should not exceed the maximum value you have found to work well for regular Hash in normal mode.

Mein bisheriger Richtwert für die 12er Serie nach deren Readme- Files war für 12 cores einfach ca. 1Gb pro Stunde, was ich für die obige Formel ohnehin auch noch passend finde, wenn es sicher nicht zuviel werden soll. Dass bei der Rechnung jetzt eigentlich nur die Hälfte des Erwarteten ("or about 576 megs") heraus kommt, hängt vielleicht auch damit zusammen, dass Larry Kaufman für die beste Performance, was den Gesamthash angeht, rät, im Bereich der ca. Hash halbvoll- Anzeige der Engine zu sein beim game playing je nach TC.

Also so ein Hash- Fresser wie LC0 dürfte komodo- MCTS nicht sein, aber wenn man schon am Rand dessen ist, was Windows nicht braucht, muss man es schon auch einrechnen zusätzlich zum normalen Hash.
Parent - - By Klaus S. Date 2019-05-07 12:34
Hmm, >1000 x 40 x 8 x 3600 x 5 (secs in an hour)/ 1000000 or about 576 megs.

ergibt bei mir 5760. Was auch immer 
Parent - - By Peter Martan Date 2019-05-07 13:38 Edited 2019-05-07 13:48
Uups, du hast recht, vor dem schon gebrachten Zitat kommt noch:

Zitat:

A rough estimate on current (2019) processors is each core can expand about 30 Monte Carlo nodes a second, but can vary a lot when the tree has many draws or mates and climb higher to perhaps 1000. Each node is 40 bytes.


Also, wenn er jetzt dann in bytes weiterrechnet, und das Dividieren durch 1000000 zum Schluss zum Umrechnen in megabytes macht, hat er eigentlich 5760 meg(abyte)s, nicht 576. Aber unklar ist mir inzwischen vor allem auch noch, dass 40 (bytes/nodes) ja eigentlich nicht das ist, womit die Sekunden zu multiplizieren wären, wenn zwischen 30 und 100 nodes pro Sekunde von einem Kern berechnet werden. Da müsste ja dann noch einmal mit 30 bis 100 mulitpliziert werden, nein?
Parent - - By Tom Paul Date 2019-05-07 22:57
Peter Martan schrieb:

Uups, du hast recht, vor dem schon gebrachten Zitat kommt noch:

Zitat:

A rough estimate on current (2019) processors is each core can expand about 30 Monte Carlo nodes a second, but can vary a lot when the tree has many draws or mates and climb higher to perhaps 1000. Each node is 40 bytes.


Also, wenn er jetzt dann in bytes weiterrechnet, und das Dividieren durch 1000000 zum Schluss zum Umrechnen in megabytes macht, hat er eigentlich 5760 meg(abyte)s, nicht 576. Aber unklar ist mir inzwischen vor allem auch noch, dass 40 (bytes/nodes) ja eigentlich nicht das ist, womit die Sekunden zu multiplizieren wären, wenn zwischen 30 und 100 nodes pro Sekunde von einem Kern berechnet werden. Da müsste ja dann noch einmal mit 30 bis 100 mulitpliziert werden, nein?


Ja und wie viel haben wir dann?
Parent - By Peter Martan Date 2019-05-08 15:21
So wie's Klaus richtig ausgerechnet hat, ich hab's zwar seit dem Erscheinen beim 12er auch immer richtig eingestellt, aber nur, weil ich den fehlenden Nuller auch übersehen habe, also zufällig richtig.


Mark Lefler hat's mir im CCC bestätigt, das ist in der Readme um einen Nuller falsch:

http://talkchess.com/forum3/viewtopic.php?p=798256#p798256

Ich hatte immer mit ca. 1Gb MCTS- Hash/Stunde für 12 Kerne gerechnet, und als Faustregel stimmt das schon auch so, wenn man's wirklich genau wissen will, muss man schauen, wieveil n/s die MCTS- Version auf der eigenen Hardware macht.
Parent - - By Guenter Stertenbrink Date 2019-05-20 10:50
z.B. fuer breite Eroeffnungsanalysen, ist da Komodo MCTS jetzt das beste ?
Cerebellum-Buch erstellen.

1.e4 multipv=10
oder 1.e4 c5 2.Nf3 d6 3.d4 cxd4 4.Nxd4 Nf6 5.Nc3 a6 , multipv=12

sowas hab ich ja mehrmals gemacht, auf Tablets unter Droidfish , 512MB Hash,
und dann ein paar Wochen rechnen lassen ...

Ich hatte ja nie verstanden, warum multipv soviel mehr Zeit kostet,
wenigstens ein Teil der Information zu anderen Zuegen sollte
abrufbar sein bei multipv=1 , die Zuege werden ja auch regelmaessig
irgendwie sortiert.

Das war ja auch meine erste Frage im Computerschach in 2016 ... erst an Mark Leffler
im TCEC-chat und als das nichts brachte hier im Forum und im Rybka Forum
Parent - - By Stefan Pohl Date 2019-05-20 11:47 Edited 2019-05-20 11:49
Guenter Stertenbrink schrieb:


Ich hatte ja nie verstanden, warum multipv soviel mehr Zeit kostet,
wenigstens ein Teil der Information zu anderen Zuegen sollte
abrufbar sein bei multipv=1 , die Zuege werden ja auch regelmaessig
irgendwie sortiert.

Das war ja auch meine erste Frage im Computerschach in 2016 ... erst an Mark Leffler
im TCEC-chat und als das nichts brachte hier im Forum und im Rybka Forum


Das ist doch eigentlich simpel. Der Alpha-Beta Algorithmus schneidet Varianten ab. Und zwar je mehr, desto enger die Alpha/Beta-Grenzen sind. Das ist für die Geschwindigkeit entscheidend. Im normalen PV=1 Modus kann man die AlphaBeta-Grenzen an denen der Hauptvariante orientieren. Gibt es jetzt aber mehrere Varianten, muß man die Grenzen so aufweiten, daß auch für die schlechteste dieser Varianten die Grenzen noch korrekt sind. Hat man also PV=5 und die 5.Variante ist ungefähr einen Bauern schlechter als die beste Variante (was durchaus praxisnah ist), müssen die AlphaBeta-Grenzen viel weiter gesetzt werden, um auch für diese Variante noch Widerlegungen bzw. Verbesserungen zu finden, ohne diese fälschlicherweise abzuschneiden. Daher müssen dann viel mehr Züge durchgerechnet werden und die Suche bleibt in gleicher Zeit viel flacher. Logisch. Und die Suche wird umso flacher bleiben, je schlechter die letzte Variante der PV-Varianten im Vergleich zur besten PV-Variante ist. Auch logisch. Das Gute ist aber, daß die modernen Engines so auch in der Hauptvariante mehr sehen und weniger "Löcher" in der Suche haben, eben weil auch dort die AlphaBeta-Grenzen weiter gesteckt sind (sein müssen). Daher wird im MultiPV-Modus auch bei insgesamt flacherer Suche mehr gefunden, oft mehr, als in gleicher Zeit bei viel höherer Suchtiefe ohne MultiPV-Modus, wenn es irgendeinen exotischen Gewinnzug gibt. Auch logisch.
Parent - By Stefan Pohl Date 2019-05-20 13:05
Stefan Pohl schrieb:
Das Gute ist aber, daß die modernen Engines so auch in der Hauptvariante mehr sehen und weniger "Löcher" in der Suche haben, eben weil auch dort die AlphaBeta-Grenzen weiter gesteckt sind (sein müssen). Daher wird im MultiPV-Modus auch bei insgesamt flacherer Suche mehr gefunden, oft mehr, als in gleicher Zeit bei viel höherer Suchtiefe ohne MultiPV-Modus, wenn es irgendeinen exotischen Gewinnzug gibt. Auch logisch.


Das war jetzt zu schnell getippt. Der AlphaBeta-Algorithmus übersieht innerhalb des Suchhorizontes nichts. Aber die modernen Engines nutzen natürlich viele weitergehende Pruningmethoden. Und die übersehen schon Dinge. Und das erläuterte Prinzip gilt eben auch für diese  Prunings: man muß den schlechtesten Zug im Multi PV-Modus und seine Bewertung als Pruninggrenze nehmen, wodurch eben viel weniger Pruning möglich wird, was die Suchtiefe reduziert.
Parent - - By Guenter Stertenbrink Date 2019-05-20 13:05
voellig klar, aber fuer die anderen Zuege koennten ja die Bewertungen mit minderer Qualitaet (bounds) 
trotzdem angezeigt werden , als Option. Sie werden ja alle bei jeder Tiefe untersucht und dann sortiert
Es geht viel Information verloren.
Parent - By Stefan Pohl Date 2019-05-20 13:07 Edited 2019-05-20 13:12
Das stimmt, ist aber ein anderes Thema. Generell wird die Zugsortierung aber insgesamt besser, wenn weniger abgeschnitten wird. Das wirkt dem Bremseffekt bei MultiPV etwas entgegen, weil der AlphaBeta Algorithmus umso mehr abchneiden kann, je besser die Zugsortierung ist.
Bei 5-PV ist die Suche also nicht 5x langsamer, sondern schon weniger. Wieviel weniger schwankt aber stark. Zwischen etwas über 1x und etwas unter 5x ist alles möglich. Dafür wird aber eben auch mehr gefunden (bei gleicher Suchtiefe)
Parent - - By Peter Martan Date 2019-05-20 11:49 Edited 2019-05-20 11:59
Guenter Stertenbrink schrieb:

z.B. fuer breite Eroeffnungsanalysen, ist da Komodo MCTS jetzt das beste ?
Cerebellum-Buch erstellen.

1.e4 multipv=10
oder 1.e4 c5 2.Nf3 d6 3.d4 cxd4 4.Nxd4 Nf6 5.Nc3 a6 , multipv=12

sowas hab ich ja mehrmals gemacht, auf Tablets unter Droidfish , 512MB Hash,
und dann ein paar Wochen rechnen lassen ...

Ich hatte ja nie verstanden, warum multipv soviel mehr Zeit kostet,


Primary lines haben viel weniger Pruning als non primaries, es differiert natürlich von Engine zu Engine, aber dass die meisten taktische Hotshots, die im single variant mode überrechnet werden (irgendeiner Form von Pruning und Reductions zum Opfer fallen) im MV- Mode schneller gefunden werden, je nach Zahl der Varianten, das ist bei A-B altbekannt.

Dass das bei "positionellen" Stellungen nicht erst recht so ist, aber natürlich viel weniger leicht "beweisbar", liegt einfach daran, dass taktische Stellungen Dynamik haben, die sich in Evalsprüngen zeigt, positionelle aber viel weniger.

Je mehr Lines du willkürlich zu Primaries erhebst, um so mehr solche müssen mit den weniger selektiven Parametern durchgerechnet werden.

Für MCTS gilt das anscheinend weniger, aber wenn schon in die Breite suchen, würde ich da heutzutage dann schon eher LC0 als komodoMCTS nehmen, natürlich in Kombination mit einer guten A-B-Engine.

Es gibt übrigens auch ein Leela- Cerebellum auf der Brainfish- Site, Güter, falls du an LC0- Analysen zur Eröffnungstheorie interessiert bist, wie sie Thomas Zipproth in seine Bücher einspeist.

Wie ich dir auch schon mal per Mail versucht habe zu beweisen, bringt Forward- Backward in der Analyse von Eröffnungsstellungen mehr als Standrechnen allein, egal mit welcher Engine und mit welcher Hardware und ob im MV- oder im Single Variant Mode.
Einschränkend muss ich hinzusagen, dass ich bei dem schlicht schleißigen Hashlernen von LC0 (im Vergleich zu SF oder komodo oder Houdini) nicht so sicher wäre, dass das Forward- Backward soviel bringt wie bei A-B-Engines über längere Zeit und mit vielen Verzweigungen, und außerdem mag es schon sein, dass der MV-Moder LC0 weniger kostet an Zeit, als es Erkenntnisse bringt, das kann ich alles nur aus Vergleichen mit schwacher Hardware- Installation von LC0 sagen, aber meiner Meinung nach bringt auch gute Hardware (und mehr Zeit, mit der müsste man es ja gerade auf schwacher Hardware merken) sowieso viel weniger Time to Depth- Einsparung (also Zeitgewinn) als bei SF und komodo und Houdini.

Kürzer formuliert, wenn du LC0 auch auf guter Hardware (was ich so höre von Anderen) über ein bestimmtes Maß an Zeit hinaus rechnen lässt, ändert sich früher nix ("nicht viel", das ist der springende Punkt bei dem, worüber wir per Mail diskutiiert haben, naja, eigentlich habe ich mit mir selbst diskutiert ) mehr an der Eval und den ersten Zügen, als bei A-B. Warum das im MV wesentlich anders sein sollte, gerade, wenn MV vielleicht wirklich weniger Unterschied zwischen den einzelnen MV- Lines macht, wüsste ich nicht.

Machte MCTS genau so viel Unterschied zwischen den Lines im Single- und im -MV- Mode wie A-B, müsste der Time- to- Depth- Verlust derselbe sein.

Wäre das mit Standrechnen und Forward- Backward im Vergleich zueinander nicht so, wie von mir im Mail geschildert, hätte sich Thomas Zipproth den eigenen Cerebellum- Algorithmus (der ja an sich Engine- unabhängig ist oder in der Vollversion dann jedenfalls sein soll) gar nicht antun müssen.

Bin wirklich neugierig, ob und wann da jemals was für den User adaptierbar herauskommen wird an Vollversion von Cerebellum.

Auch frage ich mich, warum das unbedingt mit einem kompletten neuen GUI (Sirius) kombiniert werden muss, automatische Forward- Backward- Optionen mit oder ohne Wechsel zwischen MV und single variant gibt's ja eh schon lange in den verschiedensten GUIs, ich persönlich finde diesbezüglich, von dem was ich kenne (IdEA ist mir zu kompliziert) die Fritz- Stellungsanalyse immer noch am besten.

Bei IdEA kannst du zwar auch Stellungen eingeben, die in der Analyse von Ausgangsstellungen zusätzlich berücksichtigt werden müssen, aber einen ganzen Baum, den du aus einem eigenen Buch schon vorsortiert hast, der Engine vorzusetzen, damit sie es im automatischen Forward- Backward und im Wechsel von MV und single variant eine bestimmte Zeit oder Tiefe lang durchforstet und mit eigenen zusätzlichen Lines ergänzt und das Ganze dann auch noch den Endevals sortiert, da ist Fritz meiner Meinung nach immer noch der Goldstandard an Automatismen, unerreicht ist aber natürlich jeder Automatismus auch da nach wie vor für mich, relativ zu "händisch interaktiv", aber das ist eh klar und kein fairer Vergleich, weil Letzteres Manpower und -Zeit vor dem Rechner braucht.
Parent - - By Guenter Stertenbrink Date 2019-05-20 13:12
Lc0 braucht aber GPU, Komodo MCTS nur CPU.

Forward Backward erscheint nuetzlich, keine Frage. Das sollte irgendwann irgendwie
implementiert, automatisiert werden.

Idea geht auf Android ? (command line ~ Linux)
Parent - By Peter Martan Date 2019-05-20 13:32 Edited 2019-05-20 13:34
Guenter Stertenbrink schrieb:

Lc0 braucht aber GPU, Komodo MCTS nur CPU.


Du willst damit sagen, dass du das eine hast, und das andere nicht, nehme ich an, das ist für dich natürlich ein großer Unterschied, in der Sache selbst sehen ich sonst keinen.

Guenter Stertenbrink schrieb:

Forward Backward erscheint nuetzlich, keine Frage. Das sollte irgendwann irgendwie
implementiert, automatisiert werden.


Ich glaube nicht, dass es mit kürzeren Sätzen getan ist, damit du liest, was ich schreibe, ich glaube, ich sollte immer wieder aus einem Mail und einem Posting mehrere machen.

Es gibt, wie du unten aber doch auch im Zusammenhang erwähnst, IdEA und dergleichen zum Saufüttern, Cerebellum wird durch einen eigenen Algorithmus erstellt, der genau das besonders zeitsparend automatisiert aus großen Datenmengen an Partien und Varianten macht.
Noch dazu, wenn's denn dann wirklich so sein wird, noch dazu auch Engine- unabhängig. Es handelt sich hier wie anderswo (höre, was Erfahrung spricht...) um ein GUI- Feature, wozu willst du das in jede einzelne Engine of your personal interest eigens einbauen?

Guenter Stertenbrink schrieb:

Idea geht auf Android ? (command line ~ Linux)


Vermuten würde ich nein, habe aber keine Ahnung und werde dir nicht die Arbeit abnehmen, auf der Convekta- site selber nachzuschauen.
Parent - - By Benno Hartwig Date 2019-05-20 14:40 Edited 2019-05-20 14:46

> Ich hatte ja nie verstanden, warum multipv soviel mehr Zeit kostet,...


Beim normalen alpha-beta bricht die Engine die Analyse eines Knotens sofort ab, sobald ein widerlegender Zug gefunden wird

Bei multipv=2 wird sie aber weiteranalysieren müssen, da das ja für den zweitbesten Zug wichtig sein kann. Schneiden kann sie erst, wenn ein Widerlegungszug gegenüber 2 besseren Lösungen gefunden wurde.
Das ist unabhängig davon, was ggf. im Hash gefunden wird.

Und bei multipv=3 kommen solche Cuts noch später/seltener.

Je höher multipv ist, um so dichter ist der Baum, und ich würde ihn dann irgendwann schon lieber "Busch" nennen wollen als "Baum".
Und diese größere Dichte des "Busches" hat zu Folge, dass er bei limitierter Zeit nicht besonders hoch wachsen kann.

Was mich aber viel mehr irritierte ist, dass bei verschiedenen multipv-Werten reproduzierbar verschiedene Bewertungen für den besten(!!!) Zug herauskommen können. (Stockfish, vor ca. 2 Jahren mal so untersucht, bei gleichen komplett durchanalysierten Tiefen!)
Und ich glaube, dies kann sogar auch in verschiedenen besten Zügen resultieren, je nach multipv-Wert.
Und das hatte ich zunächst mal so überhaupt nicht erwartet gehabt!

Benno
Parent - By Michael Scheidl Date 2019-05-20 14:54
In Arena kann man im MultiPV-Modus Enginepartien spielen lassen. Da wäre beispielsweise interessant wieviele Elo K.MTCS mit mpv(3) verliert - oder gar gewinnt?!

( Wobei ich momentan nicht beschwören kann, daß Arena bei dieser etwas exotischen Anwendung dann tatsächlich den bestbewerteten Zug nimmt und nicht etwa den drittbesten...? )
Parent - - By Tommy Tulpe Date 2019-05-17 18:03
Kann man Komodo (sofern man nicht die Chessbase-Version möchte, sondern die Original UCI-Version) eigentlich ausschließlich per Paypal bezahlen?
Kreditkarte oder ähnliches wäre mir persönlich wesentlich lieber.
Gruß,
Ulrich
Parent - - By Klaus Wlotzka Date 2019-05-17 18:11
Tommy Tulpe schrieb:

Kann man Komodo (sofern man nicht die Chessbase-Version möchte, sondern die Original UCI-Version) eigentlich ausschließlich per Paypal bezahlen?
Kreditkarte oder ähnliches wäre mir persönlich wesentlich lieber.
Gruß,
Ulrich

Hallo Tommy,

nun auf der Webseite sind alle möglichen Zahlungsarten aufgeführt, wie VISA, Mastercard, etc.

Grüße

Klaus
Parent - By Tommy Tulpe Date 2019-05-17 18:55
Klaus Wlotzka schrieb:


Hallo Tommy,

nun auf der Webseite sind alle möglichen Zahlungsarten aufgeführt, wie VISA, Mastercard, etc.

Grüße

Klaus


Danke für die Antwort, Klaus.
Die Symbole für alle möglichen Kreditkarten sehe ich ebenfalls unten auf der Komodo-Website. Wenn ich aber "Buy now" anklicke, lande ich bei PayPal und kann das nicht ändern.
Merkwürdig.
Hat ein Anderer die Engine per Kreditkarte oder Lastschrift bezahlen können?

Grüße

Ulrich
Parent - - By Heiko Krauß Date 2019-05-21 14:36
Bei der MCTS Version gibt es merkwürdige Anzeigen
konstant 0 kn/s
und bei der Tiefe z.B 21/11 (die 2e Zahl ist niedriger)
Ist das normal ?
Parent - - By Peter Martan Date 2019-05-21 14:46
Ja.
Parent - By Heiko Krauß Date 2019-05-21 15:09
Danke
Parent - - By Tom Paul Date 2019-05-21 18:58
Heiko Krauß schrieb:

Bei der MCTS Version gibt es merkwürdige Anzeigen
konstant 0 kn/s
und bei der Tiefe z.B 21/11 (die 2e Zahl ist niedriger)
Ist das normal ?


Ja das ist halt Komodo.
Parent - By Horst Sikorsky Date 2019-05-21 19:24 Edited 2019-05-21 19:33
Ja das ist halt sooo Tom.

bei mir aber nicht mit 12.1.1 (5kN/s Tiefe 32/36) jedenfalls Heute.

STOCKFISH ist Insolvent
GET FAST INVOLVED: CLICK MY NAME 
Up Topic Hauptforen / CSS-Forum / komodo13 ist erschienen

Powered by mwForum 2.29.3 © 1999-2014 Markus Wichitill