Ignorieren von Autopilot-Fahrfehlern

[Johannes]

(Originaltitel: "[kein Fehler] Autopilot missachtet Pfeiftafel")

Da dachte ich, dass der Autopilot ein ganz vorbildhafter Fahrer sei ... trotzdem pfeift er an den beiden Tunnels der Demostrecke nicht und bekommt dementsprechend einen Eintrag in der Bewertung. Zeitraffer war an den betreffenden Abschnitten aus.

Der schoene rote Punkt bei den Fehlern im Fahrtenschreiber gefaellt mir dagegen ziemlich gut

Gruesse
Johannes

[Carsten Hölscher]

Der Autopilot hat die Aufgabe, die Züge am laufen zu halten, mehr nicht.

Carsten

[Johannes]

Also wird man auf absehbare Zeit kein Pfeifen von entgegenkommenden Zuegen hoeren, etwa vor Tunnels? Schade

Dann wuerde ich aber den Bewertungsabzug rausnehmen. Fuers Aktivieren des Autopiloten bekommt man ja eh schon Abzug.

Gruesse
Johannes

[Carsten Hölscher]

Pfeife wäre im Moment ja eh nur 2D-Sound.
Carsten

[Michael_Poschmann]

Dann wuerde ich aber den Bewertungsabzug rausnehmen. Fuers Aktivieren des Autopiloten bekommt man ja eh schon Abzug.

So wirst Du eben doppelt bestraft, das Schienennetz ist nun mal kein Pony-Express, oder wie heißt das so schön? Ein Grund mehr, die böse Autopilot-Taste zu meiden und selbst um Punkte zu kämpfen - wir wollen doch allesamt nicht den Autopiloten und seinen Fahrstil bewertet sehen, oder?

Gruß
Michael

[AndiS]

Auf die Gefahr hin, nie wieder zu den vollwertigen Menschen gerechnet zu werden, muß ich folgende Erstinteraktion mit der Demo gestehen, weil ich sicher bin, daß dieses Verhaltensmuster nach der Release oft zu beobachten sein wird.

Demo gestartet in der Absicht, einfach mal nur zu schauen. Irgendeinen Zug geladen, Hinweis auf den Zeitsprung befolgt, Autopilot gefunden. Herumfliegen gibt's nicht in Zusi, also läßt man sich einmal vom Autopiloten durch die Gegen kutschieren, einfach um einmal zu schauen, was es so zu sehen gibt.

Nach dem Beenden kommt automatisch diese Auswertung, und in der ist ein roter Fleck, der ins Auge springt. Dann denkt man sich "hihi".

Vorher ist mir schon aufgefallen, daß der Zug ziemlich dahinschleicht. Die Auswertung hat das auch bestätigt. Es war die Annäherung an Vr0, vermutlich wußte der Autopilot, daß das Hp0 danach nicht so schnell weggeht.

Aus diesen Beobachtungen leite ich folgende Empfehlungen ab:

• Großer fetter Hinweis, daß der Autopilot kein Fahrlehrer ist. Das würde man sich nämlich als "Casual Gamer" wünschen. Und zum Erwerb der Streckenkundigkeit ist ein Mitfahren mit einem erfahrenen Fahrer doch durchaus vorbildgerecht, oder? Aber natürlich wird der Autopilot jetzt nicht umgekrempelt/upgraded, eh klar. Wo es ja auch die Fahrschule gibt.
• Großer fetter Hinweis, daß der Autopilot nur dazu da ist, die Züge am laufen zu halten. Das ist nicht dasselbe wie oben, weil es auch impliziert, daß KI-Züge alles mögliche nicht machen, was in der strengen Welt der Profisimulanten geringschätzig als Special Effects bezeichnet wird. Abgase ausstoßen, Fernlicht abblenden, und alles, was nur Dampfloks tun, und daher derzeit kein Thema ist.
• Entfernung der diversen Regelverstöße des Autopiloten aus der Auswertung. Schön, daß man sie trotz Autopilot überhaupt zu sehen bekommt, man schaltet ihn ja eventuell öfter ein und aus. Man könnte statt der Einzelfehler einen grauen Balken oder ähnliches über die ganze Länge der Autopilotiererei zeigen. Hauptsache, man sieht die verschiedenen Geschwindigkeitskurven.

[Mr. X]

•Entfernung der diversen Regelverstöße des Autopiloten aus der Auswertung. Schön, daß man sie trotz Autopilot überhaupt zu sehen bekommt, man schaltet ihn ja eventuell öfter ein und aus. Man könnte statt der Einzelfehler einen grauen Balken oder ähnliches über die ganze Länge der Autopilotiererei zeigen. Hauptsache, man sieht die verschiedenen Geschwindigkeitskurven.

Ich wäre dafür, dass mitgeloggt wird, wann der Autopilot aktiv war. Dann
a) muss man nicht mehr pauschal 50% abziehen, sondern kann das flexibilisieren. Dann haut einem ein einmaliges, versehentliches anschalten für wenige Sekunden auch nicht mehr voll in die Bewertung und
b) kann dann problemlos Fahrfehler aus der Bewertung nehmen, die vom Autopiloten begangen wurden.

[Michael_Poschmann]

Andis Hinweise auf die Eigenheiten - besser: Funktionalitäten - des Autopiloten*) sind in der Tat eine überlegenswerte Ergänzung. Das sollte mit ein paar Textzeilen und damit mit überschaubarem Aufwand zu erledigen sein.

Aber ein Umkrempeln der Bewertung macht vermutlich "ein Fass auf". Löst Euch doch bitte davon, daß 100% erreichbar - und womöglich sogar noch gerechtfertigt - sind, wenn der dienstbare Geist eingeschaltet ist. Mit dieser Einstellung und Erwartungshaltung betrügt man sich doch nur selbst. Durchs Leben Schummeln geht nun mal auch in Zusi nicht, irgendwann fliegt's auf. Klare Ansage, wenn ich die Leistung nicht zu 100% selbst erbracht habe, bekomme ich nun mal keine 10,0 von den Kampfrichtern gezeigt - das geht den Eiskunstläufern, die unauffällig einen Kran für ihren doppelten Rittberger nutzen, vermutlich genauso.

Gruß
Michael




*) Der AP "weiß" auch nicht im voraus, wann ein Signal auf Fahrt gehen wird. Er trödelt, wie andernorts erwähnt, sofern der Zug deutlich vor Plan unterwegs ist. Dieses Verhalten kann je Zug durch den Fahrplanbauer deaktiviert werden, so gewünscht. Holger Lürkens nutzt jedoch diesen Effekt, um die Fahrplanstabilität weiter zu verbessern - er konstruiert als Fachmann die Soll-Trassen konfliktfrei, davon gehe ich mal ganz stark aus.

[Thomas U.]

100% mit Autopilot möchte wahrscheinlich auch niemand. Mir fallen aber mindestens zwei Situationen ein, in denen der Autopilotabzug wesentlich geringer als 50% bzw. eben gar nicht vorhanden sein sollte:
1) versehentliches Betätigen (schaffe ich bei Zusi2 schon manchmal, wenn ich gedanklich bei der Tastenbelegung eines anderen Spiels bin (in OMSI ist F3 nämlich Außenperspektive))
2) Zug will nicht fahren, warum auch immer (ebenfalls in Zusi2 schon gehabt) -> einmal kurz den Autopilot an, Zug fährt wieder, Autopilot wieder aus. Gründe für's Nicht-fahren habe ich keine gefunden, es ging einfach nicht mehr, dementsprechend auch keine manuelle Behebung möglich und AP der einzige Ausweg neben Alt+F4.


Vielleicht also eher eine prozentuale Berechnung Gesamtfahrzeit/davon Zeit mit Autopilot.

[Michael_Poschmann]

Ich bin weiterhin ernsthaft irritiert darüber, wie stark diese Fixierung auf die Prozentzahl ist.

Vielleicht hilft es auch schon, sich selbst die 48,75% zu 100% zu erklären. Faktor ausrechnen mit Dreisatz sollte doch für alle hier aktiven, technisch-mathematisch Interessierten möglich sein. Und Carsten erspart das gleichzeitig einen vermutlich nennenswerten Implementierungsaufwand.

Gruß
Michael

[Mr. X]

Aber ein Umkrempeln der Bewertung macht vermutlich "ein Fass auf". Löst Euch doch bitte davon, daß 100% erreichbar - und womöglich sogar noch gerechtfertigt - sind, wenn der dienstbare Geist eingeschaltet ist.

Du gehst von falschen Voraussetzungen aus. Zumindest ich rede nicht davon, dass man mit AP 100% kriegen sollte. Ich redete von zwei Dingen:
- Benutzung des AP sollte Punktabzug geben. Möglichst aber nach Dauer der Benutzung gewichtet.
- Fehler, die der AP macht, sollen _keinen_ Punktabzug geben.

Beides halte ich für technisch vollkommen umsetzbar.

[Johannes]

Ich wäre dafür, dass mitgeloggt wird, wann der Autopilot aktiv war.

Wird es sogar, schau dir mal die gespeicherten XML-Dateien an (Attribut FahrtAutopilot).

Gruesse
Johannes

[Michael_Poschmann]

Hallo Philipp,

Kompromissvorschlag, ohne natürlich in Carstens Entscheidungshoheit eingreifen zu wollen: Was hältst Du davon, das auf die Feature-Wunschliste zu setzen und zu gegebener Zeit anzugehen? Ich fände es schade, wenn derartige Anforderungen die Publikation des Programms verzögern würden.

Gruß
Michael

[Mr. X]

Von nichts anderem war ich ausgegangen. Es sind halt Vorschläge und natürlich fände ich es schön, wenn sie eines Tages umgesetzt werden (über die Machbarkeit (bei vertretbarem Aufwand) brauchen wir nicht zu diskutieren, die ist hier gegeben). Das kostet aber Zeit, selbst wenn jeder einzelne derartige Wunsch für sich genommen Kleinkram ist. Die Zusi-Vollversion sollte es nicht aufhalten, da stimme ich dir vollkommen zu. Es ist eigentlich ein Paradebeispiel für ein Feature, das problemlos als Update nachgeliefert werden kann, weil es eigentlich keine bestehende Funktionalität verändert (von der Punktezahl mal abgesehen), von nichts abhängt und nichts davon abhängt. Sollte halt nur nicht vergessen werden, darum könnte man sowas ja in euer Bugtracking-System einfüllen (das ihr höchstwahrscheinlich intern habt. Schade, dass es nicht öffentlich ist, da das uns Nutzern sicherlich einige Bugreports ersparen würde, und Carsten und den anderen Eingeweihten einige Antworten).

[Alwin Meschede]

Schade, dass es nicht öffentlich ist, da das uns Nutzern sicherlich einige Bugreports ersparen würde, und Carsten und den anderen Eingeweihten einige Antworten).

Da kann ich Dich beruhigen. Ich habe in den letzten Tagen gestaunt, auf welche Arten und Weisen Zusi bei anderen Leuten genutzt wird, und was ihr als Demo-Anwender alles für Sachen gefunden habt, auf die man als Tester gar nicht käme. Also, dass ich mit "ist ein bekannter Bug, danke" hätte antworten müssen, kam praktisch nicht vor.

Wenn man sich die letzten zwei Tage im Forum anschaut, dann fragt man sich als Tester allerdings natürlich auch, wie man denn eigentlich den Release der Zusi3-Vollversion überleben soll angesichts einer zu erwartenden Sintflut von Meldungen... Einige Bugmeldungen binden im Hintergrund nennenswert Zeit für Diagnose, und zwar schwerpunktmäßig bei immer den selben zwei, drei Hilfswilligen, die den Überblick über das betreffende Fachgebiet haben, zur Problem-Einreisung in der Lage sind, und es einer möglichen Ursache zuweisen können (und dazu z.B. die letzten relevanten Änderungen an der Software im Kopf haben).

Carsten nutzt sehr pragmatisch das Forum als improvisierten öffentlichen Bugtracker. Natürlich gibt es daneben auch einen internen Bugtracker. Ich selber betreibe für mich einen eigenen Tracker, um meine Schaffenskraft mittels ToDo-Listen in sinnvolle Bahnen zu kanalisieren (mehr als 30 Feature-Wünsche, mit denen ich Carsten noch gar nicht zu belasten gewagt habe, sind da übrigens auch drin... ). Diese Tracker sind allerdings voller Interna. Daraus irgendetwas öffentlich zu machen, so lange die Vollversion noch nicht veröffentlicht ist, ist wohl auf keinen Fall sinnvoll (würde nämlich garantiert zu zahlreichen Rückfragen führen, zu Dingen die ihr noch nicht verstehen könnt). Erst wenn ihr als Kunden die selbe Software wie wir Tester vorliegen habt, ist ein (dann allerdings bei Null anfangender) öffentlicher Tracker sinnvoll. Nur mal so ins Blaue von mir gedacht...

[Mr. X]

Wenn man sich die letzten zwei Tage im Forum anschaut, dann fragt man sich als Tester allerdings natürlich auch, wie man denn eigentlich den Release der Zusi3-Vollversion überleben soll angesichts einer zu erwartenden Sintflut von Meldungen...

Da kann ich euch nicht beruhigen, diese Sintflut wird kommen. Vielleicht weniger zum Simulator, da der durch die Demos schon einigermaßen gründlich getestet ist, aber zu den dazukommenden Strecken und den Editoren. Dass da eine große Menge an Fehler drinsteckt ist allerdings völlig normal. Ihr solltet nur zusehen, dass es sich ganz gut über das Forum verteilt und nicht mit den alten Demo-Fehlerberichten vermengt. Ich würde die alten Threads alle in ein Subforum wegsperren und eine Palette von neuen Foren aufmachen, ähnlich wie wir sie jetzt zu Zusi 2 haben. Aber ich denke, darüber habt ihr auch schon nachgedacht.

Was öffentliche Bugtracker anbelangt: Bei cppcheck haben wir sehr gute Erfahrungen mit einem öffentlichen Bugtracker, der nicht nur öffentlich lesbar sondern auch editierbar ist. Natürlich sind dort aber die Voraussetzungen anders, da es sich um Open-Source-Software handelt.

[AndiS]

Wenn man sich die letzten zwei Tage im Forum anschaut, dann fragt man sich als Tester allerdings natürlich auch, wie man denn eigentlich den Release der Zusi3-Vollversion überleben soll angesichts einer zu erwartenden Sintflut von Meldungen...

Das ist ja der ganze Sinn von so Demos, daß die Geisteswelten von Entwicklern und Nutzern schrittweise zusammenfinden. Jenseits der Zusi2-Gemeinde gibt es ein weites Feld von Vorstellungen, was eine Eisenbahnsimulation tun soll, und die werden alle auf Zusi3 hereinprasseln, weil es die einzige neue Hoffnung in den nächsten beiden Jahren ist. Vieles davon ist Feature Request, nicht Bug Report. Aber dieses Thema hier ist ein wunderbares Beispiel dafür, wie schwierig die Grenzziehung ist.

Viele gute Tester zu finden und motiviert zu halten ist der gordische Knoten der Spieleentwicklung. Nicht ohne Grund erscheint Railworks immer wieder ziemlich ungetestet, auch wenn es ein Beta-Programme gibt. Die Leute, die sich auskennen, arbeiten lieber an irgendwelchen Projekten. Die Leute, die gerne die neueste Release ausprobieren wollen, haben oft nicht den systematischen Zugang und die Disziplin, Dinge auszuprobieren und zu wiederholen, die sie impulsiv gar nicht so interessieren.

Das Auswertungsfeature von Zusi hat das Potential, zumindest einmal festzuhalten, wer welche Testfahrt absolviert hat (wenn diese Files eingeschickt werden). Keine Ahnung, welche Hardware Details da mitgeschickt werden, Carsten hat sowas sicher schon einmal angedacht. Mit beiden Informationen zusammen kann man dann die Info "Um 12:35 tritt folgendes auf: ..." schon besser nutzen.

[Michael_Poschmann]

Hallo Andi,

ich glaube, Alwin treibt - zu Recht - die Sorge um, daß die schiere Menge an Kundenrückmeldungen durch die überschaubare Anzahl der Aktiven nur schwer zu bewältigen sein könnte. Wir sind selbstverständlich dankbar für jede konstruktive Rückmeldung, und wie vielleicht zu erkennen war, arbeitet im Hintergrund ein Team die Fehlermeldungen sowie die als "leistbar" eingestuften Optimierungswünsche ab. Es bleibt dennoch eine herausfordernde Aufgabe, diesen Dialog zwischen Anwendern und Erstellern, der bereits in den zurückliegenden Jahren Zusi ausgezeichnet hat, mit Leben zu füllen. Die Ressourcen sind leider endlich.

Von öffentlichen Bugtrackern rate ich ab. Auch im beruflichen Umfeld hat sich gezeigt, dass ein Filtern der Kundenrückmeldungen unerlässlich ist, um Nutzinformationen von Grundrauschen (z.B. Bedien- und Verständnisfehlern) zu trennen. Der redaktionelle Aufwand ist nicht zu unterschätzen. Ich vertraue hier auf die seh angenehme Diskussionskultur im Zusi-Forum, wo erfahrenere Mitstreitern den Einsteigern bei den allerersten Schritten aufs Pferd helfen. Dadurch verteilt sich die Betreuungslast auf viele Schultern - und setzt bei Carsten Möglichkeiten frei, sich um die eigentliche Programmentwicklung zu kümmern.

Grüße
Michael

[AndiS]

Hallo Michael, genauso hab ich es gemeint. Noch etwas globaler betrachtet, wird man die Benutzerreaktionen so filtern müssen: (So wie ich es persönlich abschätze)

1. Unerfüllte Träume.
2. Derzeit noch nicht implementierte Features.
3. Informationsdefizite.
4. Bugs unterschiedlicher Schwierigkeitsgrade.

Im Detail seh ich das wie folgt. (Betrifft das Pfeifen des Autopiloten nur sehr tangentiell, aber einen eigenen Philosophie-Thread wollte ich nicht aufmachen.)

1. Ein bis zehn Prozent der Railworks User werden Zusi 3 probieren, in der Hoffnung auf die Erfüllung ihrer Wünsche. Gebremst wird das nur durch das ausschließlich deutsche Rollmaterial und die erste Welle der Enttäuschten, die u.a. Folgendes publik machen:
   • Zusi 3 hat keinen dynamischen Schatten, keine Particle Effects, keinen Regen auf der Windschutzscheibe und auch keinen in der Luft, nicht einmal vorbeiziehende Wolken, außerdem eingeschränkten Sound und kein freies Herumfliegen.
   • Die Standardstrecken erinnern mehr an MSTS als an RW.
   • Es gibt gar keine Dampfloks und auch keine Drehscheiben.
   • Man kann nicht Rangieren.
   • Es gibt keine 3D-Passagiere, keinen Straßenverkehr, keine Ladetätigkeit und natürlich auch keine Gimmicks wie Feuerwerke.
   • Die Tastaturbelegung ist anders als in MSTS und RW (kann und wird man mit einem stark nachgefragten Config File ändern können).
   Für diese Menschen braucht man keinen Bug Tracker, sondern ein Rudel gutmütiger Forumsonkeln, die die Gebetsmühlen zum Glühen bringen.
2. Der Großteil der obigen Menschen wird mit der Situation konfrontiert, daß die Benutzerführung im Programm selbst zwar in englisch verfügbar ist, nicht aber die Doku. Da sollte man eine Prioritätsliste machen bzw. eine Reihe von Tutorials ins Leben rufen ("Wie fahre ich die Lok X", "Wie lese ich Ebula", "Wie starte und beende ich Zusi, inkl. Zeitraffer, Zugauswahl und so", "örtliche Besonderheiten in X (für Fahrplanersteller)"). Die Fahrschule hab ich vor Jahren einmal übersetzt und bin natürlich update-willig, wo notwendig.
3. Die angedeuteten Tutorials dürften teilweise auf deutsch noch nicht vorliegen, was natürlich auch nachholenswert erscheint. In beiden Fällen könnte man irgendwo eine Todo-Liste publizieren und schauen, was für Freiwilligenmeldungen kommen. Auch wenn so etwas später vielleicht versandet, ist es als Impuls immer wieder nützlich.
4. Viele der sichtbaren Defizite können von Content Entwicklern behoben werden. Da ist eine Liste der Dinge, die jetzt schon möglich sind sehr nützlich, zusammen mit einer Perspektive von Carsten, was er vielleicht im nächsten Jahr unterbringt.
   • Ambient Occlusion ist so ein Thema. Wenn das in absehbarer Zeit automatisch kommt, wunderbar. Ansonsten nimmt man die Anleitung von YPOC und schaut, ob man mit Python nicht noch was automatisieren oder unterstützen kann.
   • Dynamischer Schattenwurf ist eine andere Frage. Scheint irgendwie theoretisch möglich (vermute ich), praktisch ist es immer eine Frage des Maßhaltens wegen der Performance. Irgendetwas schattenartiges unter den Fahrzeugen wäre jedenfalls einmal ein schöner Schritt nach vorne.
   • Bodentexturen, die zum Gebüsch passen, sind nur eine Frage des Landschaftsbaus (und der wiederum eine Frage der Freiwilligenrekrutierung).
   • Animierte "Landschaftsmöbel" in Form von herumfahrenden Gabelstaplern und dergleichen sind vielleicht schon möglich. Möglicherweise auch Straßenverkehr in irgendeiner Form. Auch hier braucht man wieder die Info, wie grundsätzlich vorzugehen wäre plus Leute, die es tun.
5. Neben dem Informationsdefizit wird sich ein emotionales Defizit auftun, wenn die Leute merken, was Zusi 3 ist und was es nicht ist. Das wir das Forum schwer belasten und die informelle und sachliche Gemütlichkeit einer handvoll ernsthafter Spezialisten brutal beenden. Das muß einmal offen ausgesprochen werden. Im Railworks-Bereich haben sich zwei Entwicklungen als notwendig erwiesen:
   • Die Deklaration von Foren oder Forumsbereichen als pro und kontra, und der Verweis der Missionare in die jeweilige Ecke, wo sie nur ihresgleichen vorfinden, und daher nicht ständig neuen/alten Streit stiften.
   • Entwicklerforen, die leider teilweise völlig im Untergrund leben und dann nur ganz wenigen helfen, in denen man aber jedenfalls nur auf Einladung oder sonst sehr restriktiv schreibberechtigtes Mitglied wird.
   Im Fall von Zusi tritt verschärfend ein, daß es keine klare Trennung zwischen dem Supportforum, in dem der Hersteller zum König Kunden lieb ist und zugleich sein Produkt gut aussehen läßt, und dem Entwickler- oder Benutzerforum, in dem unter Gleichen Klartext geredet wird, was Sache ist und was nicht. Offene Supportforen haben sich meiner Meinung nach eher nicht bewährt. Daß die Entwickler von Railworks auf UKTS nicht mitlesen und/oder Wünsche entgegennehmen hat dort ein bißchen mitgeholfen, die Lust rauszulassen. Wer einen Wunsch hat, mailt ihn an die Firma und kriegt eine automatische Antwort, die ihm bestätigt, daß die Nachricht im Nichts angekommen ist. Letzteres kann man ja modifizieren, wenn man genug intelligente Menschen in der Kundenabteilung hat.
6. Carsten wird sicher jemand abstellen, der die Fehlerdatenbank aufgrund von Forumsposts füttert. Am Besten bleibt die Identität dieser Person geheim, sonst ist sie Cyberstalking ausgesetzt. Wieviel von der Datenbank öffentlich lesbar sein soll, ist eine schwierige Frage. Interessant wäre eventuell, öffentlich zu machen, welche Beobachtungen auf Bestätigung warten. Damit könnte man vielleicht das unsichtbare Testerteam entlasten, das ja auf jeden Fall alles bestätigen und eingrenzen muß, bevor Carsten sich irgendetwas überhaupt anschaut.
7. Ein eigenes Unterforum für Fehlerberichte ist schon eingerichtet.
8. Eine fette FAQ, die entsprechend wiederholter Beschwerden und Anregungen gewartet wird finde ich viel produktiver als einen Bug Tracker, der den Input nicht lesbar aufbereitet. In dieser FAQ würde dann darauf hingewiesen, was geht (und wie), was noch nicht allgemein üblich, aber möglich ist (und wie man es macht, wenn man will), was nicht geht (und wie absolut dieser Befund ist). Natürlich sollte das auch eine Liste der Fehlermeldungen, die die Leute so kriegen, enthalten - mit leicht verständlicher Erklärung, was das Problem sein könnte.

[Mr. X]

Das meiste von dem klingt ziemlich übertrieben.

3.Die angedeuteten Tutorials dürften teilweise auf deutsch noch nicht vorliegen, was natürlich auch nachholenswert erscheint. In beiden Fällen könnte man irgendwo eine Todo-Liste publizieren und schauen, was für Freiwilligenmeldungen kommen. Auch wenn so etwas später vielleicht versandet, ist es als Impuls immer wieder nützlich.

Zu diesem Zwecke könnte man ja ein Wiki ins Leben rufen.