diff --git a/OLD.d.gebirge b/OLD.d.gebirge
index 471a0b9..27cddb3 100644
--- a/OLD.d.gebirge
+++ b/OLD.d.gebirge
@@ -11350,3 +11350,16 @@
 
 
 
+Handschuhe (Ogerwald, Minotaurenlabyrinth) (Bambi, 21. Mar 2020, 00:28:17):
+Hi,
+
+die Handschuhe hatten leider einen Fehler, der die Original-Handschadenstypen
+des Spielers ignoriert hat. Getroffen hat das vermutlich nur Felinen,
+vielleicht auch Goblins. Der Fehler sollte nun behoben sein.
+
+Bambi
+
+-----------------------------------------------------------------------------
+
+
+
diff --git a/OLD.diskussion b/OLD.diskussion
index 7735d83..9e6b36a 100644
--- a/OLD.diskussion
+++ b/OLD.diskussion
@@ -130428,3 +130428,160 @@
 
 
 
+GMCP, (MG.)Char und der report (Zesstra, 22. Mai 2020, 10:12:22):
+Huhu,
+
+wenn man GMCP benutzt, kann man eines der Charakter-Module (z.B. MG.Char)
+benutzen, um sich Daten ueber den Charakter senden zu lassen. Wenn man das
+aktiviert, bekommt man einmal am Anfang alle verfuegbaren Daten geschickt
+(inkl. der dann aktuellen LP und KP).
+
+Die Uebertragung von Aenderungen durch den "Report" (s. hilfe report)
+erfordert allerdings, dass bestimmte Quests bestanden wurden - hat man z.B.
+"Hilf den Gnarfen" noch nicht gespielt, werden keine Aenderungen an den KP
+uebertragen.
+
+An mich wurde der Wunsch herangetragen, dass ohne die Vorraussetzungen des
+Reports auch bei der Aktivierung des GMCP-Moduls nicht der aktuelle Wert
+uebertragen werden soll, sondern eine -1.
+
+Ist das allgemein ein Wunsch?
+
+Zesstra
+
+-----------------------------------------------------------------------------
+
+
+
+Re: GMCP, (MG.)Char und der report (Zook, 22. Mai 2020, 10:29:04):
+~#! rn=Zesstra rt=1590135142 rg=diskussion
+~#! tid=1590135142
+Ich haette nur die Frage, ob "-1" so ein geschickter Wert
+fuer "gibt es noch nicht" ist.
+
+Zook
+
+-----------------------------------------------------------------------------
+
+
+
+Re: Re: GMCP, (MG.)Char und der report (Zaphob, 22. Mai 2020, 13:30:55):
+~#! rn=Zook rt=1590136144 rg=diskussion
+~#! tid=1590135142
+Ich denke, ob -1 oder ein anderer Platzhalter, ist nicht entscheidend.
+
+Das GMCP lauft ja grundsaetzlich unter der Oberflaeche und kein Spieler
+bemerkt die Inhalte unmittelbar. Das muss vom Client erst mal interpretiert
+und dargestellt werden. Da entscheidet sich, wie es aussieht.
+
+Aktuell bekommt er vorab keine Info, dass die KP nie aktualisiert werden.
+
+Also wurde ein Client vielleicht ganz naiv die KP vom Einschalten zeigen, und
+dann niemals wieder aktualisieren, selbst wenn sich KP im Spiel veraendern.
+
+Da koennte man jetzt einen Workaround dazu programmieren. Bspw. koennte der
+Client erstmal nichts anzeigen, oder irgendeinen vorlaeufigen Platzhalten
+zeigen. Das dann so lange, bis die erste Aktualisierung empfangen wird. Erst
+dann weiss er sicher, dass tatsaechlich Aktualisierungen kommen werden.
+
+Der Workaround hat auch eigene Probleme. Wenn ein Spieler mit vollen KP
+startet und dann auch erstmal nichts zaubert, wird er lange keine KP
+Aktualisierungen empfangen und den vorlaeufigen Platzhalter lange sehen.
+
+Aber eigentlich sollte GMCP ja hier unterstuetzen, indem solche zentralen
+Infos nochmal direkt per GMCP geschickt werden, damit sie leicht und korrekt
+verarbeitet werden koennen, ohne gross zu basteln oder Vermutungen anstellen
+muss.
+
+Bspw. kommen da Raumausgaenge huebsch aufgelistet heraus, ohne dass der Client
+sie erst muehselig aus der ggf. mehrzeiligen Raumbeschreibung herausgraben
+muss.
+
+Insofern sehe ich wenig, dass gegen eine Info spricht "Achtung, du wirst keine
+KP Aktualisierungen empfangen" - Nur welche Stelle und welcher Wert dafuer
+praktisch waeren? Das koennte man noch diskutieren.
+
+Gruesse,
+Zap*
+
+-----------------------------------------------------------------------------
+
+
+
+Re^3: GMCP, (MG.)Char und der report (Zook, 22. Mai 2020, 14:38:46):
+~#! rn=Zaphob rt=1590147055 rg=diskussion
+~#! tid=1590135142
+Ich sehe gerade nicht, wo ich grundsaetzlich gegen die Erweiterung
+spreche, aber gut.
+
+"
+Ich denke, ob -1 oder ein anderer Platzhalter, ist nicht entscheidend.
+(...) Nur welche Stelle und welcher Wert dafuer
+praktisch waeren? Das koennte man noch diskutieren."
+
+Der Argumentationsstrang leuchtet mir nicht ein; und aus
+meiner bescheidenen Erfahrung kann ich berichten, dass 
+unglueckliche Werte fuer "Da kam nichts" zu sehr nervigen
+Situationen fuehren koennen.
+
+Zook
+
+-----------------------------------------------------------------------------
+
+
+
+Re^4: GMCP, (MG.)Char und der report (Zaphob, 22. Mai 2020, 14:43:19):
+~#! rn=Zook rt=1590151126 rg=diskussion
+~#! tid=1590135142
+Oh, ich hatte nur zufaellig auf deinen Artikel geantwortet.
+
+Sinnvoll waere natuerlich sowas wie "es gibt Updates" = false, aber ich weiss
+nicht, wie aufwaendig das fuers MG umzusetzen waere.
+
+Gruesse,
+Zap*
+
+-----------------------------------------------------------------------------
+
+
+
+Re^5: GMCP, (MG.)Char und der report (Zesstra, 22. Mai 2020, 15:11:05):
+~#! rn=Zaphob rt=1590151399 rg=diskussion
+~#! tid=1590135142
+Ich werfe mal einige Hinweise ein:
+Die Module "Char" und "char" sind nicht von uns spezifiziert. Ich bin
+zurueckhaltend, dort Aenderungen vorzunehmen.
+Das Modul MG.char ist von uns spezifiziert. Bei (nicht-trivialen?) Aenderungen
+der uebertragenen Daten muessten wir eine neue Version davon spezifizieren.
+(Und Client die neue Version anfordern.)
+Aktualisierung von einigen Daten haengt von Aufgaben im Spiel ab. D.h. wir
+muessten ein "Dieses Datum wird aktualisiert"-Flag fuer jedes datum
+einfuehren. Da bin ich spontan keine Freundin von...
+
+Zesstra
+
+-----------------------------------------------------------------------------
+
+
+
+Re^6: GMCP, (MG.)Char und der report (Zaphob, 22. Mai 2020, 20:09:07):
+~#! rn=Zesstra rt=1590153065 rg=diskussion
+~#! tid=1590135142
+Jetzt bin ich verwirrt, worueber die Diskussion gehen soll.
+Ich hatte dafuer argumentiert, diese Information irgendwie mitzugeben.
+Das scheint nun gar niemand in Frage zu stellen. Also findet ich gut.
+Nun geht es wohl noch um die Art der Umsetzung.
+Zook fragt, ob -1 geschickt ist oder sehr nervig werden kann.
+Zesstra mag jedenfalls auch keine neue Variable dafuer einbauen.
+Also mir gehen da spontan die Ideen aus, wenn die gleiche Variable benutzt
+werden soll, aber ein offensichtlicher Quatsch Wert nicht fuer "gibt es noch
+nicht" missbraucht werden soll. Bleiben noch ein paar andere Quatsch Werte?
+Steht sonst noch was zur Diskussion? Oder finden wir keinen Konsens?
+
+Gruesse,
+Zap*
+
+-----------------------------------------------------------------------------
+
+
+
diff --git a/OLD.entwicklung b/OLD.entwicklung
index 0843880..3539f6f 100644
--- a/OLD.entwicklung
+++ b/OLD.entwicklung
@@ -130486,3 +130486,20 @@
 
 
 
+GMCP, Report und Mudlet (Zesstra, 22. Mai 2020, 12:34:27):
+Huhu,
+
+wenn man Mudlet und GMCP benutzt, schaltet Mudlet von selbst ein GMCP-Modul
+ein, was sich den report per GMCP senden laesst, ohne dies jedoch in einer UI
+zu visualisieren. Dies fuehrt zur Verwirrung bei Spielern, die den report dann
+nicht mehr sehen.
+Daher gibt es jetzt einen prominenteren Hinweis in der Hilfeseite und das
+Kommando zum Einschalten des Reports zeigt eine Warnung an, falls ein
+"Char"-Modul von GMCP eingeschaltet ist.
+
+Zesstra
+
+-----------------------------------------------------------------------------
+
+
+
diff --git a/OLD.megaschmarrn b/OLD.megaschmarrn
index 260c0c8..da85776 100644
--- a/OLD.megaschmarrn
+++ b/OLD.megaschmarrn
Binary files differ
diff --git a/OLD.schmarrn b/OLD.schmarrn
index 0e27ef8..c75af4e 100644
--- a/OLD.schmarrn
+++ b/OLD.schmarrn
@@ -411283,3 +411283,12 @@
 
 
 
+Re^17: SOMMERPARTY IN HATTINGEN! (Deaddy, 14. Jun 2020, 11:21:44):
+~#! rn=Croft rt=1592126310 rg=party
+~#! tid=1581278427
+Mir wuerd abwechselnd erstmal reichen...
+
+-----------------------------------------------------------------------------
+
+
+