LDMud 3.6.0 veroeffentlicht
Gnomi@Uni
Das LDMud-Team ist wirklich stolz, die Veroeffentlichung von LDMud 3.6.0
verkuenden zu duerfen.
LDMud 3.6.0 ist wieder ein grosses Update mit entsprechenden Auswirkungen
auf LPC-Code. Jede Mudlib wird sicherlich einige Anpassungen benoetigen,
um mit LDMud 3.6 zu laufen. Das liegt daran, dass LDMud 3.6 Unterstuetzung
fuer Unicode in Strings mitbringt. Daher wird es aber nicht mehr moeglich
sein, Binaerdaten in Strings abzuspeichern. Stattdessen gibt es einen
neuen Typ 'bytes', welcher aehnliche Funktionalitaet fuer der Typ 'string'
jedoch fuer Binaerdaten bietet, aber nicht mit Unicode-Strings vermischt
werden darf.
Eine Beschreibung der Unicode-Unterstuetzung ist in /doc/concepts/unicode
enthalten, ein Leitfaden zur Umstellung ist in /doc/3.5vs3.6 im Quellcode
des Drivers enthalten.
Abgesehen davon gibt es Aktualisierungen bei den Anforderungen:
* JSON-C 0.12 oder neuer wird fuer die JSON-Efuns benoetigt.
* LDMud 3.6.0 unterstuetzt OpenSSL 1.1 und GnuTLS 3.6.
Wir empfehlen die Umstellung auf 3.6 in Angriff zu nehmen, denn weitere
Entwicklung wird sich auf den 3.6er Branch konzentrieren.
LDMud 3.6.0 ist hier erhaeltlich:
* http://www.ldmud.eu/download.html
* https://github.com/ldmud/ldmud/tree/3.6.0
Eine Liste der Aenderungen gibt es in der Datei HISTORY in den Quellen.
Falls Ihr auf weitere Probleme mit LDMud stosst, berichtet uns bitte
darueber in unserem Bugtracker: https://mantis.ldmud.eu/mantis/
Und falls Ihr Fragen habt, stehen wir Euch auf der Mailingliste
ldmud...@googlegroups.com oder unter ldmu...@UNItopia.de zur Verfuegung.
Wir schaetzen auch sehr Euer Feedback - vorzugsweise Lobeshymnen, aber wir
nehmen auch konstruktive Kritik entgegen.
Viel Spass!
Das LDMud-Team
Stephan Weinberger
Eine Frage zu IC_ENCODING mit /TRANSLIT. Nachdem das ja offenbar direkt
bei der Netzwerkverbindung geschieht: wie kann man die Stringlänge
ermitteln, die tatsächlich an den Spieler gesendet wird (z.B. für
formatierte Ausgaben)? Wird die tatsächliche Länge in z.B. sprintf()
berücksichtigt?
lg
Invisible@BL
Gnomi@Uni
die Kodierung geschieht direkt kurz vor dem Absenden. Es gibt keine
Moeglichkeit, die dadurch entstehenden Binaerdaten nochmal abzufangen
und zu veraendern. Will man hier nochmal eine Bearbeitung durchfuehren,
so bietet es sich an, die Ausgaben mit catch_tell() abzufangen, selbst
mit to_bytes() zu konvertieren, anschliessend die gewuenschte Bearbeitung
durchzufuehren und mit binary_message() abzuschicken.
Gruss
Gnomi
Stephan Weinberger
Ich denke to_bytes() würde nicht das tun was ich möchte. Mich
interessiert ja nicht die Länge der Bytesequenz, sondern die Länge in
druckbaren Characters im jeweiligen Encoding. //TRANSLIT verändert diese
Länge.
Beispiel: ich möchte einen Text mit Umlauten formatiert ausgeben, z.B.
eine Preisliste im Laden:
sprintf('* %16s : %3d Taler', gegenstand, preis)
* Hut : 70 Taler
* Geldbörse : 50 Taler
* grüne Füße : 998 Taler
Im einfachsten Fall versteht der Spieler UTF8, d.h. "grüne Füße" ist für
ihn 10 Zeichen lang. Zum Formatieren muss ich also mit diesen 10 Zeichen
rechnen, und *nicht* mit der Länge der Bytesequenz (hier 13), die mir
to_bytes() ausspucken würde.
Das Problem taucht auf, sobald //TRANSLIT ins Spiel kommt:
Wenn der Spieler z.B. nur ASCII versteht und Umlaute mit //TRANSLIT
konvertiert haben will. Dann wären es "gruene Fuesse", womit sowohl
String (wie auch Bytesequenz) plötzlich 13 lang sind.
Für ein korrektes Ergebnis muss die Transliteration also bereits *vor*
der Formatierung durchgeführt werden.
Was wir also bräuchten wäre ein sizeof(), das die Textlänge ausspuckt,
die der Spieler tatsächlich zu sehen bekommt.
Ein ähnliches Problem gibt es übrigens, wenn der Text nicht druckbare
Zeichen oder Steuersequenzen (z.B. Farbe) enthält, die für die
Längenberechnung ignoriert werden müssen. Im BL haben wir das derzeit
über einen Haufen simul_efuns gelöst, was so irgendwie funktioniert,
weil wir uns bis jetzt darauf verlassen können, dass sich die Textlänge
bei der Ausgabe an den Spieler nicht mehr verändert.
Also wenn ich mir was wünschen könnte, wäre das eine sizeof(), die auf
Wunsch die Stringlänge in druckbaren Zeichen für den jeweiligen Spieler
ausgibt. Also a) //TRANSLIT berücksichtigt und b) eine konfigurierbare
Liste von Zeichenfolgen ignoriert.
Die müsste dann auch in allen efuns verwendet werden, wo Textlängen
berechnet werden - dann würde das Formatieren "einfach funktionieren".
lg
Invisible @BL
Stephan Weinberger
u.U. wäre es sauberer diese beiden Varianten von sizeof() zu trennen -
in vielen Sprachen gibts ja genau deshalb sizeof() und strlen().
Also eine efun "int strlen( string [,object] )", die die dem übergebenen
Objekt (bzw. default halt this_player) angezeigte Stringlänge berechnet,
während "int sizeof( string )" sich wie bisher verhält und die 'lokale'
Stringlänge zurückgibt.
Die Frage wäre dann, ob man nicht auch noch eine Variante von sprintf()
(und etwaigen anderen efuns, die Strings formatieren) haben sollte, der
man eben explizit das Spielerobjekt übergeben muss damit sie strlen()
statt sizeof() verwendet. Oder ob sprintf() das einfach immer machen
soll (oder per #pragma oder Compileroption konfigurierbar).
Gnomi@Uni
ich sehe das Problem, allerdings ist mir bisher keine wirklich elegante
Loesung dazu eingefallen.
Der Driver hat selbst keine Idee, wie breit die Texte bei der Ausgabe
werden. Das //TRANSLIT wird von den Iconv-Routinen beim Uebersetzen in
das jeweilige Encoding ausgewertet. In dem jeweiligen Encoding entspricht
aber ein Byte nicht mehr einem Zeichen auf dem Bildschirm (bei ASCII
und ISO8859-X schon, bei anderen mag das anders aussehen).
Um also eine angepasste Formatierung zu ermoeglichen, muesste der Driver
die Transliteration selbst vornehmen. Allerdings haben wir selbst keine
Liste aller notwendigen Transliterationen fuer alle unterstuetzten
Encodings. Auch muessten wir fuer Efuns wie sprintf(), terminal_colour()
zusaetzliche Varianten einbauen, die spielerabhaengig reagieren, was
nicht sonderlich schoen waere.
Also wenn jemand Ideen hat, wie man das elegant umsetzen kann, wuerde
ich mich freuen, diese zu hoeren.
Gruss
Gnomi
Sin@Uni
aber fuer Ascii waer nicht schlecht, ggf. auch ersetzen bestimmter Zeichen.
Teiweise sind glaub die Ersetzungen Englisch, bei einem Versuch hier,
wurde z.B. das gotische o nicht ersetzt.
Und gerade fuer blinde Spieler interessant waeren vielleicht die ganzen Emojis.
Stephan Weinberger
ja, dass das umständlich und performancetechnisch nicht ganz optimal ist
ist mir schon klar.
Im Grunde führt ja tatsächlich kein Weg daran vorbei, den Text in jedem
sprintf() u.dgl. zuerst durch die iconv zu jagen, nicht druckbare
Zeichen herauszufiltern und die daraus ermittelte Länge dann für die
Formatierung des Originalstrings zu verwenden. Und nicht mal das ist so
einfach, weil ja u.U. Zeilenumbrüche an anderen Stellen gemacht werden
müssen, wenn sich die Textlänge durch die Transliteration verändert. Man
muss den ganzen Spaß also de facto wortweise machen :-(
Zusätzlich erfordert das auch von den Codern einiges an Disziplin, den
so gewonnenen String dann auch nur für exakt diesen Spieler zu verwenden
(also nicht z.B. die Preisliste im Shop in einen Cache zu legen, um sie
nicht jedes Mal neu erstellen zu müssen). Das könnte man aber ein wenig
abmildern bzw. bewusst machen, wenn man explizit das Spielerobjekt
übergeben muss, für das formatiert werden soll.
Performace sollte inzwischen wirklich kein Problem mehr sein, selbst
wenn Strings mehrfach oder gar umsonst konvertiert werden müssen. Selbst
sehr gut besuchte MUDs spucken ja kaum mehr als ein paar Kilobytes Text
pro Sekunde aus.
Wie gesagt: im Beutelland haben wir die ganzen String-Formatierungen und
auch das Einfärben/Umbrechen komplett in simul_efuns gelöst und es war
selbst zu unseren bestbesuchten Zeiten auf Hardware aus dem letzten
Jahrhundert nie ein Problem (selbst mit unserem vergleichsweise
moderaten LIMIT_EVAL).
Aber insgesamt verstehe ich natürlich, dass das wirklich nicht die
höchste Priorität hat. Trotzdem wäre zumindest eine efun::strlen(string,
object) schön, dann könnten wir wenigstens unsere eigenen simul_efuns
zum Formatieren entsprechend anpassen.
Apropos einfärben: Was unabhängig von der Längenproblematik sehr fein
wäre, wäre eine Möglichkeit die Pre- und Postfixe der Farbcodes in
terminal_colour() zu konfigurieren. Im BL verwenden wir historisch Codes
à la "^Rrot^Ggrün^Bblau^^accent" statt "%^CODE%^".
lg
Invis
Michael
> Das LDMud-Team ist wirklich stolz, die Veroeffentlichung von LDMud 3.6.0
> verkuenden zu duerfen.
Wie fange ich mit einem Driver und einer "leeren" MudLib an bzw. was ist
das absolut notwendige Grundgerüst an MudLib, um damit "from scratch"
anzufangen?
Ich habe schon ein paar mal nach Infos dazu gesucht, bin aber immer in
die Richtung geschubst worden, eine "fertige" MudLib zu benutzen. Was
aber, wenn ich keine Rassen, Klassen, Kontinente, Städte, Häuser usw.
bereits vorgefertigt haben möchte?
Ich stelle mir vor: a) ein Raum b) ein Gegenstand c) ein NPC d) ein
Spieler - alles ohne weitere Eigenschaften zunächst, dienen nur als
"master" für Clones. Und dann eine Beschreibung, wie man aus dem Player
einen Admin / Programmierer macht, aus dem Raum einen ganzen Kontinent
(Weltkarte) und Übergang in eine Stadt baut, einen NPC als "Monster" und
einen NPC für Dialoge platziert und einen Spieler einloggen kann. Gibt
es so ein Mini-MUD überhaupt (noch)?
Btw: Das ganze würde ich gerne auf einem Win7 oder Win10 laufen lassen,
hab aber auch schon mal diesen Linux-Emulator benutzt (komme gerade
nicht auf den Namen) und hätte auch noch den einen oder anderen RasPi
frei dafür.
Zu abgedreht der Gedanke? Alternative? Kann ich eine fertige MudLib auf
das notwendigste zusammenstauchen? Wenn ja: wie? (Habe bislang ein
bisschen mit der Unitopia-MudLib herumexperimentiert.)
Gruß, Michael
Gnomi@Uni
> Wie fange ich mit einem Driver und einer "leeren" MudLib an bzw. was ist
> das absolut notwendige Grundgerüst an MudLib, um damit "from scratch"
> anzufangen?
Also die minimale Lib besteht nur aus einem Master-Objekt. In der Testsuite
vom Driver befindet sich solch ein minimaler Master:
https://github.com/ldmud/ldmud/blob/master/test/inc/base.inc
Bis auf die dortige Funktion runtime_warning() muessten das alles
Funktionen sein, deren Implementierung Pflicht fuer den Master ist.
Das ist ausreichend, damit der Driver startet.
Die naechsten Schritte waeren dann eine Funktion im Master, die Verbindungen
entgegennimmt, namens connect(). Ueblicherweise hat man dafuer ein anderes
Objekt, an welches man die Verbindung weitergibt. Denn ein Objekt kann immer
nur eine Verbindung halten und wenn der Master bereits eine hat, kann keine
zweite Verbindung aufgebaut werden. Die Mudlibs, die ich kenne, haben dafuer
dann eigens ein Login-Objekt, welches nach erfolgreichem Login die Verbindung
an ein weiteres Objekt, das Player-Objekt weitergibt.
Wenn es einen Player gibt, moechtest Du sicherlich auch eine Umgebung fuer
den Player erschaffen, einen Raum. Das waer ein weiteres Objekt, und ab
da wird's richtig komplex, denn der Raum will ausgetattet werden...
Eine kleine, funktionierende Mudlib stellt LP 2.4.5 dar, welches mit dem
Driver mitgeliefert wird:
https://github.com/ldmud/ldmud/tree/master/mud/lp-245
Von dieser Mudlib stammt uebrigens auch UNItopia ab.
Generell ist so eine kleine Mudlib schoen, um mal mit den Grundlagen
rumzuspielen, aber in die modernen Mudlibs ist inzwischen viel Energie
geflossen, um das Programmieren einfacher und die Welt schoener zu machen.
Fuer richtige Projekte waer es schade, darauf zu verzichten.
Gruss
Gnomi