|
|||||
|
|
|||||
|
Eingeloggt als Gast
Mud |
|
Habe mal die Vorschläge, Psyc als Intermud4 zu verwenden, hierher
zusammengefasst... damit das nicht untergeht und einigermassen
zusammenliegt.
-- ChristianWelzel - 17 Jul 2004
In de.alt.mud lief übrigens auch ne Diskussion dazu, siehe http://tinyurl.com/499nj
Irgendwie hat das scheinbar damals nicht alle hier erreicht... und wir haben vergessen, den Vorschlag selbst reinzufriemeln.
CvL schlug vor, statt Jabber PSYC (http://psyc.pages.de) zu benutzen:
NachrichtenbeispieleEine private Nachricht von archmage@deinmud.de an wizard1@meinmud.de:_target psyc://meinmud.de/~wizard1 :_source psyc://deinmud.de/~archmage :_nick Gandalf _message Wir brauchen echt ein neues Intermud .Anzeige könnte dann a la Gandalf (psyc://deinmud.de/~archmage) sagt Dir: Wir brauchen ein neues IntermudEine Nachricht an eine Gruppe von Leuten: :_context psyc://meinmud.de/@intermud-diskussion :_source psyc://deinmud.de/~archmage :_nick Gandalf :_action murmelt _message Mir gehen schon die Beispiele aus. .Anzeige dann zum Beispiel Gandalf (psyc://deinmud.de/~archmage) murmelt: Mir gehen schon die Beispiel aus.Eine Statusänderung an alle befreundeten MUDs: :_context psyc://meinmud.de/@intermud-systems :_nick Nemesis _warning_server_restart [_nick] will be back in a minute. .Die Übertragung der Spieldaten eines Players an ein remote MUD zwecks Questsolving: :_target psyc://nemesis.de :_source psyc://meinmud.de/~lynX :_nick lynX _request_store_game_data <z.B. der output von save_object()> .Zur Übertragung eines Icons würde man dann sowas verwenden: :_target psyc://nemesis.de :_source psyc://meinmud.de/~lynX :_length <hier kommt die file_size(png-datei) hin> :_type_file PNG _request_store_profile_icon <png-datei direkt per binary_message(read_file(xxx))> .Zwei Beispiel für Multiline-Daten, das erste mag man sich wie eine Mail vorstellen :_target psyc://nemesis.de/~lynX :_source psyc://meinmud.de/~fippo :_subject Bewerbung als Wizard _message Hallo lynX, würde mich gerne als Wizard in Nemesis betätigen blablabla .Der wahrscheinlich eher seltene Fall, dass man ein newline im vars-Mapping hat... im Beispiel _motto_action = "jabber\ndelenda est"
:_target psyc://nemesis.de/~lynX
:_source psyc://meinmud.de/~fippo
:_nick fippo
:_motto_action jabber
delenda est
_status_description_person
Description data of [_nick]
.
Also replacen wir \n durch \n\t. Wirklich gebraucht haben wir es noch nicht
Und noch ein Beispiel wie man Listen (Arrays) überträgt (c&p aus real-life Beispiel):
:_source psyc://ve.symlynx.com/@PSYC :_target psyc://ve.symlynx.com/~psycer :_nick_place PSYC :_list_members psyc://ve.symlynx.com/~danny : psyc://ve.symlynx.com/~marder : psyc://ve.symlynx.com/~noonee : psyc://ve.symlynx.com/~psycer : psyc://ve.symlynx.com/~fippo :_list_members_nicks Danny : marder : noonee : psycer : fippo _status_place_members In [_nick_place]: [_list_members_nicks]. .Wenn auf den Modifier (meistens : ) direkt ein Tab folgt haben wir eine Liste (die als Variablenname üblicherweise ein _list hat) und müssen anhängen. Der Parser kann das zum Glück schon ;) Sobald wir PSYC 1.0 verabschieden, werden die häufigst benutzten Variablen und Methodennamen auf Buchstaben gekürzt, also _source wird zu "s", _nick zu "n" und _message zu "m". Damit wird PSYC wohl das mit Abstand kompakteste beliebig erweiterbare generische Daten- und Nachrichtenprotokoll sein. Fragen und Antworten zu PSYCEin anonymer Gast schrieb: > PSYC scheint eher ein chat protokoll zu sein.Durch neue Beispiele oben widerlegt. Es ist ein Chat-Protokoll nur in der Hinsicht, dass es bereits definierte Methoden gibt für alle Chat, Presence und Messaging Bedürfnisse, die ja Intermud letztlich auch hat. Ist doch schön wenn dann demnächst dastehen kann "Dein Freund Belzebub von Munterland hat das Universum betreten." Sowas ist in der PSYCMUVE LPC library schon gecoded, es muss nur für Mudlibs unterschiedlich angepasst werden. Eventuell muss noch ein driver_hook her, mit dem man festlegen kann, dass alle Objekte in /net nicht von unpriviligierten Klassen angecallothert werden dürfen. Gibt es dafür bereits was? Ist jedenfalls kein Beinbruch. Wir haben die MUD driver schon um wildere Dinge erweitert. > übrigens kann man bei jabber auch gifs übertragen.. (siehe avatars) Meines Wissens gibt es keinen offiziellen Jabber-Standard für Binärdaten, und es gibt auch keinen für Binärdaten in XML eingebettet. Die einzige XML-kompatible Rangehensweise ist es wohl in den Binärdaten alle XML Sonderzeichen wie & < > und das Nullbyte zu escapen durch entsprechende & < > etc. Wer hat für sowas CPU-Zeit zu verschenken? Das ist doch bekloppt. Selbst wenn man beliebige XML Daten in Jabber übertragen will, müssen die alle escaped werden, weil Jabber ja selbst XML ist. Stellt euch vor HTTP wäre in XML, dann müsste jede Webseite escaped übertragen werden!! Höre gerade die Avatare werden derzeitig base64 encoded übertragen.. als wenn das Internet auf 7 bits beschränkt wäre. Man stelle sich also zusätzlich vor HTTP würde alle Bilder und Downloads base64 encoden.. Hallo Steinzeit! Jabber ist Encodingtechnisch ein echter Rückschritt! > nachrichten nur einmal an eine gruppe sollte mit jabber auch kein problem sein, Jabber kann keine mehreren Empfänger adressieren, nicht einmal wenn sie auf demselben remote Server sind. Jede Nachricht wird in Kopie dorthin ausgeliefert. Man kann zwar MUCs aufsetzen damit wenigstens vom Client zum Server die Nachricht nur einmal geht, aber zwischen den Servern geht der blanke Wahnsinn ab. Wir haben bei der Standardisierung von XMPP darauf hingewiesen, dass dies ein massives Scalability-Manko ist, da aber über Jabber kaum gechattet wird, sind die Jabber-Entwickler noch nicht auf dieses Problem gestoßen und unterschätzen es. Zudem mögen Firmen keine Verzögerung wenn es um marketingsteigernde Maßnahmen wie RFCs geht... > desweiteren bietet jabber pubsub was sehr praktisch für mudlisten wäre > (http://www.jabber.org/jeps/jep-0060.html) Da gibt es bei uns mehrere Varianten von (wir haben das schon länger als Jabber, schon um 1999 herum hatten wir einen abonnierbaren dpa-Nachrichtenticker. Und zwar kann man Gruppen einmalig "betreten", automatisch betreten bei jedem Login (gilt auch für News) oder einmalig subscriben und dann nur noch per presence-Änderung steuern wieviele Daten man von dort bekommt (also wenn keine News verloren gehen dürfen, warten sie halt in der mailbox auf einen). Dies ist generisch für alle Räume oder Multiempfängergruppen gelöst, egal ob man darin frei chatten kann, moderiert oder gar nicht, weil sie nur der Datenübertragung dienen. Mal abgesehen davon, dass auf den jabber-Listen gerade gejammert wird dass pubsub.com bereits Performanceprobleme hat die News alle auszuliefern - bei Jabber bedeutet das ja für jeden Empfänger einzeln - und das obwohl der größte Teil der Jabber-Nutzer Karteileichen sind (weil deren Multiprotokollclient sie halt anmeldet). Letzteres kann man behaupten wenn man die Statistik betrachtet wonach ein Durchschnitts- Jabber-User nur zehn Leute kennt und nur 2 Bytes pro Minute versendet. Beides vollkommen unrealistisch kleine Werte. > Ich versteh auch nicht warum nachrichtentypen besser zu erweitern sind.. > bei jabber kann man einfach beliebige xml tags hinzufügen. Wenn Jabber-Server tatsächlich beliebige zusätzliche Attribute und Tags erlauben in bereits definierten Nachrichtentypen, Einspruch angenommen. Aber meines Wissens ist es bereits verboten zusätzliche Daten in <presence>-Pakete zu stecken, was Blödsinn ist, da nicht nur MUDs Presence mit spezifischen Erweiterungen benötigen. Jedenfalls haben sie gesagt sie würden das verbieten wollen, damit presence-Pakete nicht zu groß werden können um das Jabber-Netz zu überlasten. Also als Ersatz dafür, dass sie das Routingproblem nicht gelöst haben. In PSYC könnte man stattdessen sogar mp3s multicasten (Radiobetrieb), wenn alle Empfänger einverstanden sind. Eigentlich will ich nicht an den Bemühungen anderer rumnörgeln, aber so stehen die Dinge nunmal.. Jabber wurde ohne die Erfahrungen im IRC und MUD-Bereich entwickelt, so ziemlich drauf los, und das merkt man dem jetzt an. Nur in Marketing sind sie zweifellos gut. -- CvL - 17 Jul 2004 PSYC und InterMUD?Wie sehen denn die Anforderungen an das Mud aus, wenn man Psyc als Intermud4 benutzen will ? Wieviele Ports muss man öffnen können, wie sieht es mit der Firewall aus ? Braucht man Multicast im Kernel ? Braucht man irgendwelche Erweiterungen der Mudlib (ausser dem Parser von euch) oder am Driver ? Wie ist die Infrastruktur des Psyc-Netzes ? Fragen über Fragen... :) -- ChristianWelzel - 18 Jul 2004 > Wie sehen denn die Anforderungen an das Mud aus, wenn man Psyc als> Intermud4 benutzen will ? Die Userobjekte und die Chaträume sollten eine Methode
msg(string source, string method, string data, mapping vars) {
... have fun ...
}
implementieren.
Zum versenden von Nachrichten benutzen wir eine simul efun
sendmsg("psyc://anderesmud/~player", "_mud_quest_data",
einstringmitdeinendaten,
optionaleinmappingmitweiterendaten);
Hinzu kommen noch ein oder zwei Lambda-Closures für asynchrones DNS-Zeug ( http://muve.pages.de/dist/world/net/library/dns.c )
und net_connect (ist ja zum Glück mittlerweise Standard-ldmud). Alles schon fertig.
> Wieviele Ports muss man öffnen können, wie sieht es mit der Firewall > aus ? Ein Port, üblicherweise die 4404. Die Beschränkung kann man entweder durch eine Art statische Routing-Tables innerhalb von sendmsg() eliminiert werden... oder wenn man nen erq hätte der SRV-Records kann. > Braucht man Multicast im Kernel ? Nein, IP Multicast ist ja leider tot. Wir beschränken uns auf Multicast on top of IP in der Art, wie Kalt es im neuen IRC-Architektur-RFC (2810) oder ihr das was ihr nebenan (wo war es nur...) auch beschreibt. Die Räume/Kanäle verteilen die Sachen weiter an ihre lokalen User / andere Räume die an sie angeschlossen sind. Die Idee ist aber extremst unjabberig :) > Braucht man irgendwelche Erweiterungen der Mudlib (ausser dem Parser > von euch) Idealerweise kannst Du net/ komplett reinhängen. Will man das nicht unbedingt (auch wenn man dadurch nette Goodies kriegt):
net_connect. Ist aber mittlerweile Standard. Man kann aber auch vereinbaren, dass selbst die Verbindung zu anderen Muds aufbaut, die sowas nicht können. > Wie ist die Infrastruktur des Psyc-Netzes ? Generell ein dezentrales Netz genau wie Jabber. Man kann innerhalb einzelner Räume/Gruppen baumartige Netze aufbauen ( siehe http://muve.pages.de/dist/world/net/place/junction.c ) -- PhilippHancke - 18 Jul 2004 Anmerkungen.. zu Ports, ja man kann PSYC multiplexen mit HTTP und dem telnet-Zugang alle auf dem Standardport des MUDs, aber sowas finde ich hässlich und ineffizient. LPMUD kann nun wirklich seit 1991 multiple ports allozieren, oder sowas um den Dreh. Ausserdem will man ja frei im Universum kommunizieren können, und nicht auf die MUDs beschränkt sein, die einen connected haben - ergo will man einen neuen Treiber mit net_connect-Fähigkeit. Aber im Prinzip könnte man auch ohne alles das Existieren. Um so mehr ich darüber nachdenke, um so charmanter finde ich die Vorstellung einer MUVE/MUDLIB-Integration. Stell Dir vor Mudder sind automatisch auch in PSYC und Jabber eingeloggt ohne einen Client zu benötigen, sie können Newsfeeds wie die tagesschau in das Game einbauen, oder eigene Newsfeeds aus dem Game heraus erzeugen, welche von irgendwem irgendwo empfangen werden. Und umgekehrt können inaktive Mudder mit einem einfachen IRC- oder Jabber-Client im MUD eingeloggt sein, immerhin zu Kommunikationszwecken, auch wenn sie dann halt nicht zu einem in den Workroom kommen können. Dafür müssen sie nach wie vor den traditionellen Zugang verwenden. Naja, wenn man lustig ist, kann man sogar die PSYC-Befehlsebene mit der MUD-Befehlsebene koppeln. Also PSYC oder IRC-Protokoll verwenden zum mudden, als Alternative zum herkömmlichen aufgebrezelten telnet. Sind halt lustige Nebeneffekte, sofern man sie nicht unterbindet. Das geht natürlich auch. Zu Multicast: Es gab mal eine Zeit, da wurde dieser Begriff nicht gleichgesetzt mit einer spezifischen Implementation des Konzeptes. Wir sprechen nicht von "IP Multicast" im Konkreten. Aber da es ausser IP Multicast und IRC kaum weitere multicasting-Technologien gibt (ATM? WWCP?), hat dieser Synonymisierungseffekt stattgefunden.. -- CvL - 18 Jul 2004 PortierungsstatusDie Portierung der Referenzimplementation von psyc im Gueldenland: PSYCimMUD... -- DanielFischer -- 22 Jul 2004Scheint interessant zu sein. Nur der Gedanke, daß da irgendwann alles umbenannt wird, um kompakter zu werden, stört mich ein wenig - das klingt so nach Arbeit und Kompatibilitätsproblemen. PSYC scheint es ja schon länger zu geben, ist aber bisher an mir vorbeigelaufen. Das Design der Psyc-Homepage ist eher abschreckend. Linken wir für den Anfang doch lieber mal gleich auf http://psyc.pages.de/whitepaper/white.de.html, die einzige Seite die ich gefunden hab, bei der der Text nicht grellgrün ist. -- AndreasKlauer - 19 Jul 2004 Die Variablennamen- und Methoden-Kompaktisierung wird alleine aus Kompabilitätsgründen ein 'may have'-Feature sein, das verhandelt werden kann. Intern will man alleine der Übersichtlichkeit halber weiter die vollen Methoden- und Variablennamen verwenden. Das wäre dann eine reine Optimierung des Transports. -- PhilippHancke - 19 Jul 2004 Mir ist PSYC schon laenger ein Begriff. Ich habe ausserdem guten Grund davon auszugehen dass CvL? weiss was er tut. Es waer interessant, einfach mal PSYC in ein paar MUDs direkt zu implementieren. Ein Interface fuer die Spieler das den Ebenen aehnelt kann man dann ja immernoch drauf setzen. Hat das mal wer versucht? -- DanielFischer - 19 Jul 2004 > kompakter als jabber Naja, den Punkt sehe ich nicht wirklich, da ihr ja auch deskriptive Namen für die Elemente verwendet. Nur eben keine schliessenden Tags eben. was passiert bei euch, wenn man im Text nen Newline mitsenden will? Muss man doch auch escapen... und ob ich nun \n escape oder < ist doch letztendlich egal. > kann besser routen als jabber (Nachrichten nur einmal an eine Gruppe) Nach meinem Vorschlag wäre es auch so. Wir verwenden ja bei ProtokollVersion1 nicht das XMPP-IM, sondern nur XMPP-Core sozusagen als Transport-Layer. Der eigentliche XMPP-Empfänger ist das Mud, und wo es dann hin soll (Spieler, Channel, Service) ist im Paket extra angegeben. So würde eine Message an einen Channel auch nur einmal an ein Mud gesendet, welches das dann auf die eingeschriebenen Spieler verteilt... nix anderes macht ja der Psycd in Zusammenarbeit mit eueren Räumen. > man kann auch mal ein gif damit übertragen, bei jabber nicht Soweit ich weiss, gibt es auch eine JAP für Binary Streams. Genaueres weiss ich allerdings nicht. > nachrichtentypen selbstverständlich frei erweiterbar, dank typen-inheritance sogar besser als bei jabber erweiterbar ist das Jabber auch, Inheritance dürfte mit der richtigen DTD auch kein Problem sein. > einfacher zu parsen (linemode statt charmode, etc, funktioniert mit ldmuds mindestens 3.2.8 out-of-the-box) ok. das ist ein Argument, XMPP geht eben nur mit nem XML-Parser. Der ist allerdings auch nicht so schwer selbst zu schreiben in LPC. Eventl. gibt es sogar bald nen XML-Parser im LDMud integriert. > intern verwendet die API Mappings statt XML-Nodes Der Parser im Driver bildet die XMPP-Stanzas auch in Mappings ab. Eigene Parser können es ja frei behandeln, was sie generieren. Das einzige, wo ich z.z. Vorteile für Psyc sehe, ist, dass es schon eine Implementierung in LPC gibt. Vorteil der XMPP-Lösung ist aber, dass nur ein einziger Port zum Router gebraucht wird, und es keine Unterscheidung gibt, ob ein Mud nun Server oder Client ist. Wenn man nen Proxy schreiben würde, der auf ein UDP-Paket hin, auf das Mud connektiert, braucht man noch nicht einmal net_connect(). -- ChristianWelzel - 19 Jul 2004 > was passiert bei euch, wenn man im Text nen Newline mitsenden will? Entweder packt man das in den Datenpart, dann braucht man nicht zu escapen oder man fummelt es in die vars, dort muss man \n durch \n\t ersetzen. Beispiel füge ich gleich oben hinzu. > Der ist allerdings auch nicht so schwer selbst zu schreiben in LPC Das dachte ich auch bis ich es gemacht hab. Stolperfallen:
> eine Implementierung in LPC gibt. Deine Lösung ist äquivalent... nur willst Du streng genommen nicht mal xmpp-core verwenden sondern über das Component-Protokoll gehen (hihi.. ohne sha1-efun wär das auch eklig... sha1-cgi übern erq mit callbacks ist eklig), das Dir deutlich mehr Freiheiten bietet. Du implementierst eine Relay-Semantik. Wir haben eine Semantik und eine Implementierung für sowas. Du brauchst Dir quasi keine Gedanken mehr zu machen (bist aber herzlich eingeladen, da ist nichts in Stein gegossen und wir denken wenigstens gründlich über Einwände nach) Wir transformieren die Ausgabe von unserem Chatserver auch mal in jabber. Die können sogar untereinander jabbern, auch wenn das relativ sinnfrei ist. Das zeigt eigentlich, dass es vollkommen egal ist, wie das Zeug auf dem Transportweg aussieht... Wenn man auf der einen Seite der Verbindung eine Datenstruktur reinstopft muss die auf der anderen Seite wieder rauskommen. Nicht mehr, nicht weniger. XML erledigt den Job... aber halt nicht sehr effizient. > > intern verwendet die API Mappings statt XML-Nodes > Der Parser im Driver bildet die XMPP-Stanzas auch in Mappings ab. Ja? Was macht er mit nicht-flachen Strukturen? Ich bezweifle, dass man bei einer Beschränkung auf die kommunikativen Elemente irgendwelche stark verschachtelten Strukturen abbilden muss (das ist eine der Stärken von xml) Egal. Schauen wir wie sich die Implementierung von Daniel gestaltet. Ein running system ist immer noch das bei weitem beste Argument :) -- PhilippHancke - 20 Jul 2004 > Egal. Schauen wir wie sich die Implementierung von Daniel gestaltet. Ein running system ist immer noch das bei weitem beste Argument :) Jepp :) Ich wollte nur darauf hinweisem, dass sich unsere Lösungen gar nicht so unterscheiden :) Und ich bin durchaus bereit, Psyc einzusetzen, wenn es mir Arbeit spart... Auch wenn ich es für ne schöne Übung gehalten hätte, sowas mal von Grund auf neu zu implementieren :) -- ChristianWelzel - 20 Jul 2004 Ja... im Grunde ist es auch egal wie man das Zeug auf Netzebene darstellt... solang man auf der Empfängerseite das rauskriegt was der Sender reinsteckt. Ob mans über Jabber, PSYC oder was binäres wie COAL ( http://open-steam.org ) macht... die Semantik zählt. -- PhilippHancke - 20 Jul 2004 Ich habe mir das Psyc-Paket jetzt mal runtergeladen und den Code überflogen. Erstmal ist zu sagen, daß es deutlich umfangreicher ist als erwartet (an sich ja nichts schlechtes). Aber ich sehe auch viele Probleme. Psyc scheint sehr stark auf Standalone ausgelegt zu sein. Es gibt zwar Glue-Code, um mit verschiedenen Drivern kompatibel zu sein; aber der Rest geht meist davon aus, daß der Driver komplett auf Psyc läuft. Psyc als Teil einer bestehenden Mudlib scheint im Design nicht wirklich vorgesehen worden zu sein. So hat Psyc ein eigenes Simul-EFun-Objekt, das sich mit bestehenden Simul-EFuns des MUDs nicht unbedingt verträgt, einen eigenen Auto-Include String, der Perlisms [until,unless,chop,chomp] für "Leserlichkeit" enthält, ein eigenes Master-Objekt... Alles in allem scheint mir Psyc eine eigenständige Mudlib zu sein - inkompatibel zu anderen Mudlibs. Um es im eigenen MUD zum Laufen zu bekommen, muß man für Psyc eine eigene Umgebung schaffen, mit eigenem Auto-Include String, eigenen Simul-EFuns, und so weiter... Man kann also entweder die eigene Mudlib umkrempeln, um die für Psyc gewohnte Umgebung zu schaffen; oder man kann Psyc umkrempeln, um mit der eigenen Mudlib zusammenzuarbeiten. Ersteres kommt für viele Muds schlichtweg nicht in Frage (ich will keine komischen Sachen in meiner Simul-Efun haben, nur weil Psyc sie braucht), bei letzterem steht man dann bei jeder neuen Psyc-Version wieder dumm da. Wenn Psyc sich in MUDs durchsetzen will, muss nicht nur die Portabilität zu verschiedenen Drivern gewährleistet sein, sondern auch zu den Mudlibs. Und das sehe ich im Moment nicht gegeben. Was ich mir wünschen würde: Ein Psyc, das sich nicht auf Simul-Efuns, gesetzte Pragmas, sonstige Auto-Includes, sonstige Mudlibsachen verläßt. Stattdessen bringt es ein einzelnes zentrales Objekt, mit einer festen API, das zwischen (unbekannter) Mudlib und Psyc kommuniziert. Dort können dann (die Mudlib-spezifischen!) SEfuns rein wie z.B. log_file (sollte man anders nennen) und die Funktionen, die den rohen Verbindungsaufbau, und was immer Psyc sonst noch von der Mudlib braucht, übernehmen. Ziel: Um Psyc in die bestehende Mudlib zu integrieren, braucht man nur noch eine Datei ausfüllen, die man auch in neueren Psyc-Versionen weiterverwenden kann. Aenderungen am Simul-Efun und am Master Objekt der Mudlib sollten unnötig sein (bis auf die einmalige Vergabe der benötigten Privilegien). -- AndreasKlauer - 21 Jul 2004 Jemand kann ja psyc portabel implementieren. Psycmuve ist u.a. deshalb so umfangreich, weil es auch Jabber und den ganzen anderen Schrott kann den ein MUD nicht braucht. Ein reiner psyc-Client waere viel viel einfacher. Dann koennte man ein paar psycmuves aufsetzen und die als Server verwenden, aehnlich wie die Router bei i3. Der Grund aus dem ich es gern einbinden wuerde ist einfach, dass es ein Team von Leuten gibt die den Code weiterentwickeln... wenn man psycmuve mit moeglichst wenig Aenderungen in ein MUD einbaut heisst das auch, dass man sich regelmaessig die Updates vom cvs ziehen kann (kurz nachdenken wird man aber noch muessen.) Letztlich ist es (was mich angeht) nur mal ein Versuch, endlich was zu tun anstatt nur rumzudiskutieren. Psyc waere mir aus technischen Gruenden sehr willkommen, da ich die Idee fuer recht ausgereift halte und keinen Grund sehe was separates zu erfinden, was das selbe macht, zumal schon eine LPC-Referenzimplementation existiert. -- Main.guest - 21 Jul 2004 Siehe auch PSYCimMUD -- Main.guest - 23 Jul 2004 Besonders das Uebertragen von Quest-Daten gefällt mir SEHR gut :-) Get ready 4 Intermud-Quests... -- InvisibleBeutelland - 26 Jul 2004 |