Menu
▾
▴
tf-macros-devel — tf-macro development list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
(10) |
Apr
(18) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(5) |
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ingo D. <Ing...@SP...> - 2002-04-11 15:33:13
|
Hallo!=20 =20 Ich bin der Neue und soll hier singen. :o) Nein, ganz so schlimm kommts nicht. Ich wollte eigentlich nur mal die Mailinglist testen und gleich ein paar Kleinigkeiten vorschlagen, die mir aufgefallen sind. =20 1) Zauberer-Statuszeile: W=E4re es m=F6glich, dass man die Stabmagiepunkte etwa so anzeigt: =20 Normal:=20 ______L:210_K:226:150_ Das geht gut bis:=20 ______L:210_K:226:999_ Dann kommt schon:=20 ______L:210_K:226:+++_ Man k=F6nnte doch bei 1000+ SMPs folgendes zeigen: f=FCr ca. 1200 SMPs: ______L:210_K:226:1k2_=20 f=FCr ca. 9900 SMPs ______L:210_K:226:9k9_=20 und sogar f=FCr ca. 23000 SMPs. ______L:210_K:226:23k_=20 Erst dann k=E4me=20 ______L:210_K:226:+++_ =20 Ich weiss nicht, ob jemand regelm=E4=DFig mit so vielen Punkten = rumrennt, aber 999 schlage ich andauernd und weiss dann nicht mehr, wie weit ich dar=FCber liege. Nach o.g. Methode w=FCrde man kein einziges Zeichen einb=FC=DFen. =20 2) CVS Tutorial Gibt es irgendwo eine Kurzeinf=FChrung f=FCr Leute, die sich nicht die = ganze Hilfeseite reinziehen m=F6chten? :-) =20 3) Symbolic links Kann man Verkn=FCpfungen (oh! Windows-Sprache) auch per CVS einchecken = und w=FCrden die mit TF zusammen arbeiten? Dann k=F6nnte man recht = wartungsarm die meisten Skripte f=FCr epacris.mud.de =FCbernehmen und br=E4uchte = ggf. nur wenige anpassen. =20 So long... =20 Ingo aka Shaky. =20 |
|
From: Stefan H. <hu...@pc...> - 2002-04-03 14:07:10
|
Hallo, kann ich auch ganz kurz was zu sagen... ich bin wohl der Hauptuebeltaeter, da ich in der letzten Zeit wie wild an den Statuszeilen und -files gebastelt habe... ich habe mit Mesirii folgendes besprochen: in den .tf files werden in Zukunf alle config-variablen mit /set_var auf Default-Werte konfiguriert. /set_var setzt die Variablen nur, wenn sie noch nicht definiert sind, wenn die Variable also vorher an beliebiger anderer Stelle gesetzt wurde, dann wird dieser Wert nicht ueberschrieben. Damit ist es in Zukunft dann auch egal, ob die .cfg vor oder nach den jeweiligen .tf geladen werden (wenn die user in den .cfg die Variablen brav wie bisher mit /set setzen). Ich werde die von mir in letzter Zeit oefter bearbeiteten Files so schnell wie moeglich umarbeiten. Wenn das geschehen ist, muss man noch einmal in den sauren Apfel beissen und die .cfg entsprechen anpassen. Danach allerdings werd ich die .cfgs nicht mehr anfassen! Versprochen. s'Zauberzwerch Thufhir aka thufhnik |
|
From: Michael H. <mh...@in...> - 2002-04-03 09:23:57
|
Ich stimme Dennis zu muss aber anmerken, dass 1. die *.def eigentlich verschwinden sollten und in die Config Sektion der *.tf einfliessen sollten (weniger Files). Dort sollten alle wichtigen Sachen fuer das Paket konfiguriert werden. In den *.cfg sollen die Benutzer die Moeglichkeit haben, die vorkonfigurierten Sachen mit eigenen Einstellungen zu ueberschreiben. Probleme gibts z.b. beim Laden von Files da die ja nicht so ohne weiteres rueckgaengig gemacht werden koennen. Das im CVS die *.cfg sich auch veraendern, ist normal. Fuer Updates von EndUsern gibts ja die Buildfiles (TinyMacros_UPDATE_*.zip) Wer sich das Update ausm CVS holen will, kann das update.pl nutzen, was ich geschrieben hab und dann gleich mal einchecken werde. (Laeuft imho aber leider nur unter UNIX-Systemen, Dennis moege es sich vielleicht mal anschauen und debuggen :)) Alternativ kann man dafuer auch mal install.tf probieren Das sollte auch ein Update hinbekommen. tf -n -fpath/install.tf dann nur das richtige Zielverzeichnis angeben und U fuer Update :) Natuerlich vorher nen Backup machen falls es buggt :)) Bei mir funzt es ganz gut aber das will nix heissen.. Gruss Mesi On Tue, 2 Apr 2002, Dennis Hammer wrote: > > KA> Falls ich da jetzt was Grundlegendes > KA> falsch verstehe, kl=E4r mich mal einer auf... ;-) > > na, ich denke, das Problem liegt darin, dass alles, was zZ im CVS > liegt ein Developmentsystem ist, an dem an allen Ecken gearbeitet > wird. Das Problem koennte mit 2 Release-Baeumen geloest werden (siehe > Posting von mir von vor ein paar Tagen). > > lg, > Dennis > > -- > dennis hammer > mailto:den...@we... > > > _______________________________________________ > TF-macros-devel mailing list > TF-...@li... > https://lists.sourceforge.net/lists/listinfo/tf-macros-devel > > |
|
From: Michael H. <mh...@in...> - 2002-04-03 09:19:16
|
Ja mit Olli zusammen sind wir auf den Grund des Problems gedrungen :) Ich hatte die help.tf noch nicht eingecheckt weil ich da noch ein paar andere Sachen dran geaendert hatte. Aber in der alten Help.tf war noch die Abfrage auf IDLE_TIME drin, wie Du ja auch rausgefunden hattest. Die Variable heiss jetzt aber CFG_CONNECT_IDLE_TIME :) Ich hab die neue help.tf eingecheckt mit der gibts keine Probleme mehr :) Gruss Mesi On Tue, 2 Apr 2002, Kaeptn Ahab wrote: > Hiho schon wieder ;-) > > @Mesirii: Ich hab noch ein Problem mit der Laufschrift. Wenn die einmal > angesprungen ist, f=E4ngt die innerhalb von Sekunden wieder an zu laufen, > wenn man kurzzeitig keine Taste dr=FCckt. Das h=F6rt erst auf, wenn > IDLE_TIME auf einen brauchbaren Wert gesetzt wird. Dann macht die nach > Ende der Aktivit=E4t eine entsprechende Pause. W=E4re es nicht sinnvoll, = f=FCr > IDLE_TIME direkt einen Wert von sagen wir 120 s vorzugeben? > > Ahoi, > Ahab. > > _______________________________________________ > TF-macros-devel mailing list > TF-...@li... > https://lists.sourceforge.net/lists/listinfo/tf-macros-devel > > |
|
From: Dennis H. <den...@we...> - 2002-04-02 13:40:08
|
KA> Falls ich da jetzt was Grundlegendes KA> falsch verstehe, klär mich mal einer auf... ;-) na, ich denke, das Problem liegt darin, dass alles, was zZ im CVS liegt ein Developmentsystem ist, an dem an allen Ecken gearbeitet wird. Das Problem koennte mit 2 Release-Baeumen geloest werden (siehe Posting von mir von vor ein paar Tagen). lg, Dennis -- dennis hammer mailto:den...@we... |
|
From: Kaeptn A. <kae...@gm...> - 2002-04-02 13:25:11
|
Hiho schon wieder ;-) @Mesirii: Ich hab noch ein Problem mit der Laufschrift. Wenn die einmal angesprungen ist, f=E4ngt die innerhalb von Sekunden wieder an zu laufen, wenn man kurzzeitig keine Taste dr=FCckt. Das h=F6rt erst auf, wenn IDLE_TIME auf einen brauchbaren Wert gesetzt wird. Dann macht die nach Ende der Aktivit=E4t eine entsprechende Pause. W=E4re es nicht sinnvoll, f= =FCr IDLE_TIME direkt einen Wert von sagen wir 120 s vorzugeben? Ahoi, Ahab. |
|
From: Kaeptn A. <kae...@gm...> - 2002-04-02 13:02:43
|
<body> <div align=3D"left"><font face=3D"Arial"><span style=3D"font-size:10pt">On= 1 Apr 2002 at 20:49, Oliver Meyer wrote:</span></font></div> <div align=3D"left"><br> </div> <div align=3D"left"><font face=3D"Arial"><span style=3D"font-size:10pt">Hi= Ihrs,</span></font></div> <div align=3D"left"><br> </div> <div align=3D"left"><font face=3D"Arial"><span style=3D"font-size:10pt">ic= h würde ganz gerne, obwohl ich kaum Ahnung von TF-Programmierung habe und eigentlich nur zum Mitlesen auf der Liste bin, doch mal kurz was nachfrage= n bzw. kommentieren...</span></font></div> <div align=3D"left"><br> </div> <div align=3D"left"><font face=3D"Arial"><span style=3D"font-size:10pt">[s= nip...]</span></font></div> <div align=3D"left"><br></div> <div align=3D"left"><font face=3D"Arial"><span style=3D"font-size:10pt">&g= t; Mach ich das von Hand, isses nervig, mach ich in meiner Installation ein</span></font></div> <div align=3D"left"><font face=3D"Arial" color=3D"#7f0000"><span style=3D"= font-size:10pt">> cvs update, zerschiessts mir meine user_config.cfg *g*</span></font></div> <div align=3D"left"><br> </div> <div align=3D"left"><font face=3D"Arial"><span style=3D"font-size:10pt">[s= nip...]</span></font></div> <div align=3D"left"><br> </div> <div align=3D"left"><font face=3D"Arial"><span style=3D"font-size:10pt">Ge= nau _das_ verstehe ich an der ganzen Geschichte nicht. Ich hatte eigentlich die Einführung der .cfg-Files für ziemlich komfortabel gehalten, wei= l da nach Aussage der Entwickler die userspezifischen Sachen definiert werden können, und d= ie auch bei Update der zugehörigen .tf-Files nicht angetastet werden.</span></fon= t></div> <div align=3D"left"><br> </div> <div align=3D"left"><font face=3D"Arial"><span style=3D"font-size:10pt">Nu= n haben wir aber .cfg und .def-Files, auch in den gildenspezifischen Verzeichnissen, und bei sehr vielen der letzten CVS-Updates wurden diese F= iles geändert. Ich versteh das vor allem deshalb nicht, weil z.B. user_con= fig.def und user_config.cfg nicht wirklich verschieden sind, in der ersten wird ein ni= chtbenutzter Trigger definiert und mg_properties.tf geladen, in der .cfg die anderen Ma= kros aus /kampf etc. Kann man nicht das Laden der Pakete komplett in die user_confi= g.def verlegen und stattdessen die user_config.cfg unangetastet lassen? Gleiches= für z.B. die status_zauberer.cfg. Das wäre wirklich eine Hilfe. So muß m= an immer wieder einzelne Files kontrollieren und zusammenführen...</span></font></div= > <div align=3D"left"><br> </div> <div align=3D"left"><font face=3D"Arial"><span style=3D"font-size:10pt">Fa= lls ich da jetzt was Grundlegendes falsch verstehe, klär mich mal einer auf... ;-)</span></font></div> <div align=3D"left"><br> </div> <div align=3D"left"><font face=3D"Arial"><span style=3D"font-size:10pt">Ah= oi,</span></font></div> <div align=3D"left"><font face=3D"Arial"><span style=3D"font-size:10pt">Ah= ab.</span></font></div> </body> |
|
From: Oliver M. <ol...@un...> - 2002-04-01 19:24:43
|
Hiho, ich bin leider ne absolute Perl-Niete (und mit nem Shellscript will ich mir das nicht antun *g*), sonst wuerd ich das selber machen: koennte nicht jemand ein Script schreiben, was sich aus der ~/.tfrc den Pfad der Installation raussucht (aus der /require base_files.tf-Zeile), und die Dateien aus build_UPDATE.list in das Verzeichnis kopiert? Mach ich das von Hand, isses nervig, mach ich in meiner Installation ein cvs update, zerschiessts mir meine user_config.cfg *g* Mit dem Script koennt ich dann aus meiner CVS-Arbeitskopie, die ich eh hab, einfach die aktuellen Files rueberkopieren... -- Oliver Meyer ol...@un... "DOS" Denial Of Service PGP Certificate: 8CE2 F792 9604 4706 FB72 EBAF EEDC D0DE C23D 794D PGP Comm.Key 02: C06D 8E86 5C74 B34E F746 A99F 7616 8421 D566 DEAB |
|
From: Michael H. <mh...@in...> - 2002-04-01 09:07:46
|
Wieder mal ein paar Aenderungen,
heute mal die geringsten zuerst:
in reduce.tf:
wenn RE_ECHO_STATUS_USER auf einen
makronamen gesetzt ist, wird dieses Makro mit den Parameter Status
(in %) und NPC-Name aufgerufen, wenn der Status angezeigt werden
soll
Bsp: /set RE_ECHO_STATUS_USER=/my_reduce_echo_status
die install.tf sollte jetzt schon ganz gut gehen, probiert es mal bitte auf Euren System aus
diverse Files haben Optimierungen erfahren:
* zum einen purge_vars in util.vfunc.tf
* in lists.tf sind einige Sachen schneller geworden, z.b. forEach um Faktor 10, makesub,unmakesub,haddtolist und haddtolist auch etwas
* util.tf mkdir nutzt jetzt mkdir_all zum Rekursiven Anlegen von Verzeichnissen
Profiling:
ich habe in util.timer.tf ein paar Makros zum Profiling reingetan, hat mir beim Optimieren von lists.tf maechtig geholfen:
* /profile count tf-code, laesst den angegebenen Code oder das angebene Makro (is ja auch nur Code) count mal laufen und zeigt Gesamtzeit und Durchschnitt an (Millisekunden)
z.B. /profile 1000 /addtolist test aaa bbb
oder /profile 10 /test replace("aaa","bbb",teststring)%;/test testring:=default_teststring
* /profile_wrap makroname packt ein Makro in Zeitmesscode ein, so dass es ganz normal aufgerufen werden kann (auch in anderen Makros) und liefert auf Wunsch die Profiling Informationen, wie oft das Makro aufgerufen wurde, wie lange das insgesamt und durchschnittlich gedauert hat
Bsp:
/profile_wrap foreach
/testway
/shownode *
...
/profile_info foreach (Zeigt Infos an)
/profile_unwrap foreach (stellt das Originalmakro wieder her)
Jeweils in Millisekunden, hilft ziemlich beim Optimieren von Code da man so genau rausbekommen kann, wie lange was dauert (d.h. die Hotspots finden)
|
|
From: Michael H. <mh...@in...> - 2002-04-01 08:59:14
|
Noch ein paar aeltere Aenderungen dokumentieren :)
way.tf
ich habe die Dimensionsverwaltung komplett umgestellt, d.h. es sind jetzt die Dimensionen 0 bis 9 moeglich, wobei 0 Normalwelt (n) und 1 die normale Parawelte (p) ist
dazu gibt es jetzt ein Makro dimension das den Zahlenwert fuer die aktuelle Dimension oder fuer den Parameter zurueckgibt
z.B.
/set dimension=p%;/result dimension() -> 1
/result dimension('n') -> 0
/result dimension(3) -> 3
ausserdem noch ein same_dimension dass den uebergebenen Parameter mit der aktullen Dimension vergleich, wenn der Parameter b (war mal 'both') dann gibt es immer true zurueck
Diese 2 Makros werden jetzt ueberall dort genutzt, wo ein Check auf die Dimension notwendig ist (addway,Weg berechnen,Cache usw.)
Ich habe bei der Eingabe auch ergaenzt dass man jetzt u.a. 0-9 statt der Buchstaben 'n' und 'p' angeben kann
Setzen der Dimension geht jetzt per /wpara [np0-9] das wird auch von /nopara genutzt. Die Ausgabe sollte man vielleicht noch Konfigurierbar machen.
Der Cache sollte die Dimensionen auch richtig beruecksichtigen.
Falls es irgendwo Probleme gibt, sagt Bescheid.
-------------------------------------------------------------------------
Trips:
Wer kenn das nicht ich hab zwar nen Knoten in der Naehe aber der NPC der gerade was auf die Muetze kriegt, ist immer noch 10 Schritte vom Knoten entfernt und ich bin ja soooo faul :).
Dafuer gibts jetzt ne Loesung:
Wenn man von nem Knoten aus bis zum NPC (oder einen Raum davor) geht und dort /add_trip macht, wird der Weg vom/zum Knoten temporaer in ner Liste gespeichert. So man dann zu dem Knoten /tgo macht, laeuft er die Schritte bis zu dem Raum noch, wenn er am Knoten angekommen ist.
In der Gegenrichtung laeuft er erst bis zum Knoten und dann weiter wohin man will.
Beispiel:
/go uw_fluss
n n n
/add_trip
krieche in wurzel
toete niddhoeg ... raus
/tgo Kimbiss (macht s s s /go Kimbiss)
tanke
/tgo uw_fluss (macht /go uw_fluss und dort n n n)
-------------------------------------------------------------------------
lists.tf
Arrays koennen jetzt auch gespeichert und geladen werden.
Das passiert wie bei /loadlist, /savelist mit
/loadarray [mload-optionen] arrayname
/savearray [mload-optionen] arrayname
Dabei sind die Eintraege des Arrays in dem File zeilenweise abgelegt
Wenn man selbstgeschriebene Arrayfiles hat, kann man mit ; Kommentarzeilen markieren, damit laesst sich sowas leserfreundlicher gestalten
|
|
From: Michael H. <mh...@in...> - 2002-04-01 08:57:16
|
Wieder was neues: :)
util.tf
wie schon angekuendigt, gibts jetzt /ifdef zum bedingten Definieren von Makros, ihr koennt das gerne in euren Files einsetzen um z.b. gildenabhaengige (subgilden?) makros zu definieren (oder halt nicht). Man kann auch Makros definieren, abhaengig davon, ob schon ein anderes File geladen worden ist.
Syntax: /ifdef expression Makrodefinition
Bsp:
/ifdef (p_sub_guild=~"abwehr") \
-t"bla ZSchild bla" t_zaubi_zschild = \
....
/ifdef (is_file_loaded("status.tf")) sl_lp = \
/init_var p_lp ...
-----------------------------------------------------------------------
Eine andere Sache, die schon vielen TF-Entwickler den Verstand geraubt hat, sind verschachtelte Makrodefinitionen, um dem Abhilfe zu verschaffen (und auch andere nette Dinge zu tun) hab ich /region geschrieben, dass einen Bereich eines Makros vor der Substitution schuetzt
Wer aus Shellscripten cat <<EOF ... EOF kennt wird sich schnell damit anfreunden koennen
Syntax: /return /return region('%0','MARKER')%;....Makrotext....MARKER
Beispiel:
/def x = \
/purge y%;\
/purge z%;\
/return region('%0','EOF')%;\
/def -msimple -t"Das ist ein Test" y = \
/echo def%;\
/return region('%0','YYY')%;\
/def z = /echo zzz%;/echo zzz2%;YYY\
/echo def2%;\
EOF\
/echo abc2%;\
/trigger Das ist ein Test
An dem Beispiel kann man folgendes sehen:
* die Definition von y und z muss nicht durch %%; bzw. %%%; beschuetzt werden!
* /region kann man verschachteln
* es ist einfach anzuwenden
Was passiert:
1. Makros y,z geloescht
2. Region fuehrt alles bis EOF aus, d.h. definition von y
3. x wird weiter ausgefuehrt d.h. /echo abc2 und y wird per /trigger aktiviert (nur zur Demonstration)
4. dadurch wird y ausgefuehrt, es gibt /echo def aus und das darin enthaltene /region fuehrt die Region bis YYY aus und definiert damit z mit /def z=/echo zzz%;/echo zzz2%;
5. dann wird das zweite /echo von y -> /echo def2 ausgefuehrt
nach Ablauf des Makros x und Aktivierung von y gibt es x y z
-------------------------------------------------------------------------
das mkdir in util.tf
kann jetzt auch rekursiv Verzeichnisse anlegen, falls sie noch nicht existierten und mit dem Parameter -a fragt es vorher nach, ob es das angegebene Verzeichnis anlegen soll
*************************************************************************
util.vfunc.tf
Damit mehrere Variablen auf einen Statuszeilenplatz abgebildet werden koennen (und vielleicht auch noch zu anderen Zwecken) kann man jetzt Variablenabhaengigkeiten angeben, wenn die Variable von der die anderen abhaengig sind, gesetzt wird, werden die anderen auch aktualisiert (zur Zeit nur per /self_update wieder auf den Wert gesetzt um eine Statuszeilenaktualisierung hervorzurufen, denkbar ist aber auch die Angabe einer Funktion, die die Aktualisierung ausfuehrt)
Syntax: /dep_var varname depending_var1 depending_var2
/undep_var varname depending_var
/dset varname[=[Wert]] (wie bei /set)
Beispiel:
/set a=5 /set b=2
/set status_var_b=a+b
/set status_fields=b (Statuszeile zeigt 7)
/dep_var a b
/dset a=2 (Statuszeile zeigt 4)
/dset a=10 (Statuszeile zeigt 12)
Damit koennen z.b. alle Krankheitsflags auf ein Feld der Statuszeile abgebildet werden:
/dep_var p_blind p_arzt
/dep_var p_deaf p_arzt
/dep_var p_frog p_arzt
/def sl_arzt = \
/init_var p_arzt%;\
/set status_func_p_arzt=(p_blind ? "B" : "*")%;\
/set status_attr_p_arzt=strcat(p_frog ? "Cgreen" : "", p_deaf ? "r" : "")
bei /dset p_frog=1 wir p_arzt auch aktualisiert und damit die Statuszeile Gruen
--------------------------------------------------------------------------
/random_param liefert einen zufaellig ausgewaehlten Parameter zurueck
z.b.
/def wuerfel = \
/random_param 1 2 3 4 5 6
oder
/def random_color = \
/random_param Cbgblack Cbgred Cbggreen Cbgyellow Cbgblue Cbgmagenta Cbgcyan Cbgwhite Cblack Cred Cgreen Cyellow Cblue Cmagenta Ccyan Cwhite B r u
--------------------------------------------------------------------------
ich moechte bei der Gelegenheit auch noch einmal auf get_param hinweisen:
Falls man einen Space-separierten String hat und auf einen Wert zugreifen will kann man das mit get_param tun
/get_param 1 a b c -> a
/get_param L a b c -> c
/get_param -L a b c -> a b
/get_param -1 a b c -> b c
/get_param 3 a b c -> c
|
|
From: Michael H. <mh...@in...> - 2002-03-30 19:13:42
|
lists.tf Ich hab hier nur was kleines gemacht und zwar sind jetzt auch Arrays speicher-/ und ladtbar Usage: /loadarray -c bla und /savearray -c -dkampf bla Hab ich fuer de/help_tips.ary gebraucht, das eine Sammlung von Tips&Tricks werden soll, naja schreib ich das gleich als naechstes :) worldconnect.tf Am 30 Sekunden Hook (hook beat_30) haengt jetzt auch ein /check_idle, das schaut, ob man laenge als IDLE_TIME keine Eingabe gemacht hat. Wenn ja und man vorher noch nicht idle war, wird der Hook user_got_idle aufgerufen und user_is_idle auf 1 gesetzt. Wenn man wieder aktiv wird wird user_got_active aufgerufen und user_is_idle auf 0 gesetzt help.tf an den Hook user_got_idle wurde ein /help_show_tips gehaengt, das per /lauf (aus status.tf) Laufschriften aus de/help_tips.ary (Arrayfile) anzeigt, das soll dazu gut sein, Nutzer auf Dinge hinzuweisen, die wichtig sind, die oft gefragt werden oder die man sonst nicht findet Config Variable CFG_HELP_SHOW_TIPS zum Ein/Ausschalten der helptips Ich bin am ueberlegen ob man das konfigurierbar alternativ als Message of the Day (Hour) macht? Vorschlaege ? status.tf /lauf zeigt in der Statuszeile eine Laufschrift mit dem uebergebenen Text an, die Farben sind zur Zeit noch bunt gewuerfelt (ist etwas frueh/spaet inner Nacht entstanden), sollte man aber konfigurierbar machen. Die vorhergehende Statuszeile wird gespeichert, und beim Ende von /lauf wieder restauriert, ausserdem auch dann wenn der Nutzer wieder aktiv wird. wichtige Variablen: lauf_status_fields: alte Statuszeile CFG_STATUS_LAUF_STEP: Schrittweite fuers Vorruecken CFG_STATUS_LAUF_COLOR: Farbe fuer Laufschrift wenn CFG_STATUS_LAUF_COLOR nicht gesetzt ist wird zufaellig eine aus CFG_ALL_COLORS auswaehlt |
|
From: Dennis H. <den...@we...> - 2002-03-29 15:44:20
|
MH> Was haltet ihr davon? hervorragende Idee. Bzgl. mehrstufiges Release-System haette ich auch einen Vorschlag, der zwar unseren Aufwand erhoeht, aber das ganze etwas transparenter machen wuerde: Wir orientieren uns am Linux-Kernel, das heisst, wir machen 2 Release-Branches. Branches mit gerader Releasenummer (0.x,2.x,...) sind stable, die mit ungerader Nummer sind unstable. Das heisst, wir koennen am unstable-System herumbasteln wie wir wollen, wenn ein User sich den unstable-Branch holt, ist er selbst schuld ;) Wenn wir auf der Liste hier der Meinung sind, dass gewisse Aenderungen in die Stable-Version reinsollen, dann baut der Autor die Aenderungen in eine pre-release Version, die wird dann ordentlich getestet und erst dann als stable release freigegeben. Also gibts dann ein 0.50-pre und dann in Folge ein 0.50-stable (i.e.). In der Readme/HP steht halt, dass die -pre Versionen mit Vorsicht zu geniessen sind. lg, Mua -- dennis hammer mailto:den...@we... |
|
From: Dennis H. <den...@we...> - 2002-03-29 15:30:02
|
MH> In an das Hilfesystem angelehnte? Konfigurationslisten sollte zu jeder MH> Konfigurationsmoeglichkeit folgendes drinstehen: MH> Welche Kategorie (paketauswahl, spezielles paket intern,generell) MH> Typ (Makro,Variable,Hook) MH> Name MH> Datentyp (Zahl,String,Flag,Liste,...), ggf. Grenzen, Einschraenkungen MH> TF-Code, der die Auswirkung der aktuellen Einstellung demonstriert MH> Defaultwerte zur Auswahl MH> ...? wichtig faende ich noch dependencies (ala rpms) - falls dependencies beim konfigurieren gefunden werden, koennte man die dazu gehoerigen, notwendigen Einstellungen entweder gleich vornehmen oder hinten anhaengen. Vermutlich ist es Benutzerfreundlicher, wenn man es hinten anhaengt. Jemand da, der in Mensch-Maschine-Schnittstellen VL nicht geschlafen hat? :) lg, Mua -- dennis hammer mailto:den...@we... |
|
From: Michael H. <mh...@in...> - 2002-03-29 13:41:38
|
Bin heute mal in Schreiblaune, daher wieder mal ne Mail :)
Ich will hier mal kurz darstellen, was ich in letzter Zeit so an der
Statuszeilengeschichte gebastelt hab.
Zuerst einen riesigen Dank an alle, die es schon aktiv eingesetzt haben
vor allem natuerlich an Thufhir.
Hier eine ganz kurze Darstellung was diese Statuszeile ausmacht:
* automatisch Aktualisierung von Text und Attribut bei
Variablenwertaenderung! (Text und Attribute als Funktion)
* Module als Makro oder Variable
* Einfache Konfiguration mit Modulnamen, z.b.
/config_status {node}_{zaubi}_{arzt}_{lp}_{mp}_{vorsicht}:{flucht}_{kampf}_{world}_{modes}_{clock}
* Module koennen andere Module zusammenfassen (Bsp: arzt, zaubi)
* Abhaengige Variablen (NEU) n Variablen haben bei Aktualisierung (per
/dset) Auswirkung auf 1 Statuszeilenmodul (Platz inner Statuszeile)
------------------------------------------------------------------------
1. Konfiguration der Farben und Texte der Module, kann und sollte ueber
entsprechende Variablen erfolgen, Namenschema:
CFG_STATUS_COLOR_* und CFG_STATUS_TEXT_*, wobei der * den Modulnamen
enthalten sollte und ggf. noch einen Suffix (z.b. nix oder nen Zaehler,
oder ...)
Genutzt wird dies schon in diversen Vereinfachungsmakros die
Statuszeilenmodule mit einem Makroaufruf erzeugen koennen.
Und in der Doku zur Statuszeile (wers noch nicht kennt /status_help fuer
alle moeglichen und /status_line fuer die aktuell eingestellten Module),
koennen diese Configs in der eingestellten Konfiguration (bunt + ggf.
Text) per $[status_doc_attr("SUFFIX")] angezeigt werden
Bsp:
/set CFG_STATUS_COLOR_BLIND_1=Cbgmagenta
/set CFG_STATUS_TEXT_BLIND_1=B
/set_status_var_flag p_blind 0 1
/set sl_blind_doc=Blindheitsanzeige, wenn blind: $[status_doc_attr("BLIND_1")]
Definiert ein Modul fuer Blindheit mit der angegebenen Konfiguration
Nutzung per: /config_status __{blind}__
Geht aber auch ganz normal in nem Modul:
/set CFG_STATUS_COLOR_EP=n
/set CFG_STATUS_COLOR_EP_M=Cblue
/set CFG_STATUS_COLOR_EP_k=Cyellow
/set sl_ep_doc=Erfahrungspunkte $[status_doc_attr("EP_M",">1 Mio: xxxM","EP_k", ">1000: xxxk", "EP", "sonst")]
/def sl_ep = \
/init_var p_ep%;\
/set status_func_p_ep=format_number(p_ep)%;\
/set status_attr_p_ep=p_ep>=1000000? CFG_STATUS_COLOR_EP_M : p_ep>=1000
? CFG_STATUS_COLOR_EP_k : CFG_STATUS_COLOR_EP%;\
/return status_var("p_ep",4)
-------------------------------------------------------------------------
2. Da die Statuszeilenmoduldefinition oft aehnlich aussieht, habe ich ein
paar Vereinfachungsmakros geschrieben:
Ich zaehle diese hier mal auf, jeweils mit einem Beispiel (aus mg_properties.tf)
Generelles: Wenn fuer die Standardwerte nix angegeben wird (d.h. die fuer
die kein Vergleichswert angegeben ist) dann wird dort als Attribut "n" und
als Text "" gesetzt, die Configs dafuer sind jeweils ohne Suffix!
.........................................................................
/set_status_var_string varname default|varname breite string1 .. stringX
/set sl_align_doc=Alignment von heilig: +++,rot bis satanisch: ---,blau
/set CFG_STATUS_COLOR_ALIGN=n
/set CFG_STATUS_COLOR_ALIGN_1=BCred
/set CFG_STATUS_TEXT_ALIGN_1=+++
/set CFG_STATUS_COLOR_ALIGN_2=BCyellow
/set CFG_STATUS_TEXT_ALIGN_2=++
/set CFG_STATUS_COLOR_ALIGN_3=Cyellow
/set CFG_STATUS_TEXT_ALIGN_3=+
/set CFG_STATUS_COLOR_ALIGN_4=BCgreen
/set CFG_STATUS_TEXT_ALIGN_4=*
/set CFG_STATUS_COLOR_ALIGN_5=Cgreen
/set CFG_STATUS_TEXT_ALIGN_5=-
/set CFG_STATUS_COLOR_ALIGN_6=Cblue
/set CFG_STATUS_TEXT_ALIGN_6=--
/set CFG_STATUS_COLOR_ALIGN_7=BCblue
/set CFG_STATUS_TEXT_ALIGN_7=---
/set_status_var_string p_align p_align 3 heilig gut nett neutral frech
boese satanisch
Die Konfiguration wird in Reihenfolge der Strings benutzt.
Ggf. koennte man sich auch vorstellen die Konfigvariablen mit den Strings
als Suffix enden zu lassen, wenn Bedarf besteht, Bescheid sagen.
.........................................................................
Erzeugt Modul fuer ein Flag:
/set_status_var_flag varname varname|default breite
/set CFG_STATUS_COLOR_FROG_1=Cbggreen
/set CFG_STATUS_TEXT_FROG_1=F
/set_status_var_flag p_frog 0 1
/set sl_frog_doc=Froschanzeige, wenn Frosch: $[status_doc_attr("FROG_1")]
.........................................................................
Erzeugt Modul fuer einen numerisch aufsteigenden Wert (0..n):
/set_staus_var_count varname varname|default breite maxwert
/set CFG_STATUS_COLOR_TANJIAN_KOKORO_1=Cyellow
/set CFG_STATUS_TEXT_TANJIAN_KOKORO_1=k
/set CFG_STATUS_COLOR_TANJIAN_KOKORO_2=Cred
/set CFG_STATUS_TEXT_TANJIAN_KOKORO_2=K
/set CFG_STATUS_COLOR_TANJIAN_KOKORO_3=Cred,B
/set CFG_STATUS_TEXT_TANJIAN_KOKORO_3=K
/set sl_tanjian_kokoro_doc=Kokoro aktiv (K)
/set_status_var_count tanjian_kokoro tanjian_kokoro 1 3
.........................................................................
Intern nutzen diese
/status_config_attr
z.B:
/status_config_attr t p_align =~ ' gut neutral boese
erzeugt (habs zur besseren Lesbarkeit umformatiert):
p_align=~'gut'?CFG_STATUS_TEXT_ALIGN_1 :
p_align=~'neutral' ? CFG_STATUS_TEXT_ALIGN_2 :
p_align=~'boese' ? CFG_STATUS_TEXT_ALIGN_3 :
CFG_STATUS_TEXT_ALIGN
wenn CFG_STATUS_TEXT_ALIGN nicht gesetzt ist steht da ein ""
bzw.
/status_set_config_att
das macht dasselbe wie vorher nur dass es die Attribute gleich setzt:
/status_config_attr t p_align =~ ' gut + neutral * boese -
liefert dasselbe wie oben, setzt aber noch:
/set CONFIG_STATUS_TEXT_ALIGN_1=+
/set CONFIG_STATUS_TEXT_ALIGN_2=*
/set CONFIG_STATUS_TEXT_ALIGN_3=-
dasselbe fuer Attribute dann halt statt t als ersten Parameter ein c
Syntax:
/status_config_attr [c|t] varname operator ['".] vergleichswert1 ... vergleichswertN
und
/addh syn /status_config_set_attr [c|t] varname operator ['".] vergleichswert1
Configwert1 vergleichswert2 Configwert2 ... [DefaultConfigWert]
|
|
From: Michael H. <mh...@in...> - 2002-03-29 13:09:48
|
Falls euch die vielen einzelnen Mails nerven, tut es mir leid, aber verschiedene Topics in eine Riesenmail zu packen find ich auch nicht so optimal :) Liebe TM-Entwickler, ich hab mir mal einige anfaengliche Gedanken ueber das leidige Konfigurationsproblem gemacht. Prinzipiell soll Nutzerkonfiguration ja ueber die *.cfg erfolgen. Dass das nicht so trivial ist, liegt z.b. daran, dass niemand weiss, wo er was konfigurieren kann. Es gibt zwar den CONFIG Abschnitt in den *.tf aber der wird wohl eher selten gelesen. Daher mein Vorschlag. Es sollte ein /config(ure) Makro geben dass den armen Nutzer mittels einer Art Menuestruktur (vielleicht auch Suchfunktion) dorthin leitet wo er sein Problem loesen kann. Die ganze Konfigurationsgeschichte wuerde ich hierarchisch aufbauen. D.h. generelle Einstellungen (Sprache,Standardwelt,Debugmodus (Verbose), ???). Dann welche Pakete man nutzen moechte (ggf. mit Abhaengigkeitsberuecksichtigigung). Und fuer die genutzten Pakete jeweils einen eigenen Konfigurationspunkt, der dann vom Paket strukturiert werden kann. Insgesamt wuerde ich auf eine listenbasierte Konfiguration zuarbeiten. D.h. aus dem Hilfesystem sollte pro Konfigurationsmoeglichkeit folgende Sachen kommen: Defaultwerte, Beispiele, Doku, Syntax In an das Hilfesystem angelehnte? Konfigurationslisten sollte zu jeder Konfigurationsmoeglichkeit folgendes drinstehen: Welche Kategorie (paketauswahl, spezielles paket intern,generell) Typ (Makro,Variable,Hook) Name Datentyp (Zahl,String,Flag,Liste,...), ggf. Grenzen, Einschraenkungen TF-Code, der die Auswirkung der aktuellen Einstellung demonstriert Defaultwerte zur Auswahl ...? Das /config sollte dann diese beiden Informationsquellen nutzen, um den Benutzer zur richtigen Stelle zu fuehren, ihn dort das richtige editieren/auswaehlen/eingeben lassen und das Ergebnis aber als reale Variable/Makro in die korrekte *.cfg schreiben. Bei der ganzen Konfigurationsgeschichte koennte die von Muaddib angesprochenen Nutzerlevel mit beruecksichtigen. Als Namensschema wuerde ich folgendes vorschlagen: CFG_kategorie_* z.b. CFG_STATUS_COLOR_BLIND=Cbgmangenta oder CFG_WAY_NODE_STYLE=long oder CFG_ALL_LANG=de CFG_ALL_VERBOSE=3 oder CFG_USE_WAY=1 ... fuer Makros sollte das aehnlich aussehen Zur Unterstuetzung der Konfiguration schlage ich diverse bedingte Kommandos vor (die mit + gibts schon) /mload -ECFG_USE_WAY way.tf + /ifdef p_subguild=~"Abwehr" -t"* Zauberschild *" ... + /ifecho CFG_ALL_VERBOSE>2 Warnung: Max Playerlevel reached /ifset ? ... macht mal Vorschlaege damit sollten sich konfigurationsspezifische Entscheidungen leichter umsetzen lassen (auch ohne Auskommentieren per ';' ) Schreibt mal Eure Meinung dazu. Und wer Lust hat, welchen Teil umzusetzen. Gruss Mesi |
|
From: Michael H. <mh...@in...> - 2002-03-29 12:47:15
|
Hello again, ich will mich nur mal kurz zu Konzepten und Doku aeussern. Ich wuerde vorschlagen, dass es Sinn macht Konzepte u.a. hier in der Liste zu diskutieren. Diese aber im doc/ Verzeichnis des CVS-Tree's zu pflegen. D.h. es muesste sich jemand finden der pro Konzept ein bisschen den Hut aufhat, und schaut, dass die diskutierten Aenderungen auch ihren Weg in die Konzeptionsfiles finden. Btw. ich hab nen TODO eingecheckt das gerne von Euch allen gefuellt werden kann. Ausserdem natuerlich de/help_tips.ary fuer die Statuszeilenlauftexte (kann man natuerlich auch fuer nen Message of the Day/Hour verwenden. Dieses Files sollte auf solche Sachen hinweisen, die fuer Otto Normalnutzer nicht so einfach zu finden sind, bzw. solche, die Ihr schon zu oft gefragt wurdet. Die LIESMICH ist eine absolut minimale Einstiegsdoku fuer die verschiedenen Sachen und sollte dann ergaenzt werden wenn sich was an den fuer Einsteiger wichtigen Dingen aendert. So long Mesi |
|
From: Michael H. <mh...@in...> - 2002-03-29 12:40:07
|
Hallo Ihrs, da es letztens etwas Aerger wegen der Laufschrift gab hab ich mir mal nen Kopf gemacht, wie man das besser machen kann (Asche auf mein Haupt). Ich schlage folgendes Verfahren vor. Wer was wichtiges (d.h. nicht nur minimales Bugfixing) aendert, schreibt eine Mail an die Liste, in der kurz erklaert wird was geaendert wurde, warum, wie es konfigurierbar ist usw. Aktiviert sollte diese Aenderung noch nicht werden, nur zu Testzwecken lokal oder in einer *.test. Dann _kann_ jeder der da Probleme sieht oder Ergaenzungs/Alternativvorschlaege hat, ueber die Liste was dazu schreiben und der Autor kann es einarbeiten bis es so funzt dass (fast) alle zufrieden sind. Dann kann die Sache aktiviert werden bzw. in der Konfiguration vorgesehen werden. Was haltet ihr davon? Ausserdem ist dann jeder der die Liste liest immer auf dem neuesten Stand was die Aenderungen betrifft (das Changelog zu lesen ist nicht so prickelnd, vor allem da da Erlaeuterungen, Beispiele fehlen). Ich mach dann mal den Anfang und schreib mal was zu den Sachen, die ich in den letzten Tagen gemacht hab. Gruss Mesi |
|
From: Michael H. <mh...@in...> - 2002-03-28 20:34:45
|
On Thu, 28 Mar 2002, Dennis Hammer wrote: > Hallo Leute, > > ich weiss, dass wir alle nur mehr oder weniger Zeit haben - ich gehe > da ja immer als gutes Beispiel fuer vollen Terminkalender voran :) - > dennoch: wir entwickeln hier Software, die offen zugaenglich ist und > von allen irgendwann mal sinnvoll genutzt werden koennen soll. Daher > meine Bitte: Lasst uns mal ein ordentliches Konzept machen, wie wir Gern :) > a) verschiedene Nutzerlevel integrieren koennen (Anfaenger, > Profi, Developer, Tester, ...) hmm gute Frage, da gibts bis jetzt noch kein Konzept fuer, wer braucht was, wer soll was sehen usw. das einzige was bisher darauf ruecksicht nimmt ist das + bei /hilfe > b) das Setup sinnvoll hinbekommen, so dass die Leute > auch die alpha/beta/... Versionen ohne grobe Probleme zum > Laufen bekommen. (Vielleicht beim ersten Login ein paar > Fragen direkt im tf, und auf Grund der Antworten das > Playerfile schreiben?) hmm 1. schreibe ich grad an install.tf das das installieren/updaten ausm web ermoeglichen soll 2. Einen Anfang macht ja: addplayer > c) ein Config-Interface machen koennen, wo User jederzeit alle > relevanten Konfigurationen machen koennen - ohne das Mud zu > verlassen - mit Reload der veaenderten Optionen etc. hmm klingt gut dafuer braucht man ein bennenungsschema, doku, datentypen?, standardwerte, > d) die Modularisierung so nutzen koennen, dass man > Funktionalitaet abwaehlen kann (ctm brauch ich, window > ausgabe nicht, Scrolltext auch nicht, ...) > > Wenn wir das Konzept haben, dann sollten wir es auch asap umsetzen - > das wuerden dem Projekt imho einen etwas professionelleren Touch > geben, momentan hat das Ganze was von halbkontrolliertem Wildwuchs. > Also fuer alles Listen :)) > lg, > Dennis/Mua > > -- > dennis hammer > mailto: dh...@ac... > > > _______________________________________________ > TF-macros-devel mailing list > TF-...@li... > https://lists.sourceforge.net/lists/listinfo/tf-macros-devel > > |
|
From: Dennis H. <dh...@ac...> - 2002-03-28 09:53:48
|
Hallo, ich hab dann mal die Liste upgedatet. lg, Dennis -- dennis hammer mailto: dh...@ac... |
|
From: Dennis H. <dh...@ac...> - 2002-03-28 09:37:56
|
Hallo Leute,
ich weiss, dass wir alle nur mehr oder weniger Zeit haben - ich gehe
da ja immer als gutes Beispiel fuer vollen Terminkalender voran :) -
dennoch: wir entwickeln hier Software, die offen zugaenglich ist und
von allen irgendwann mal sinnvoll genutzt werden koennen soll. Daher
meine Bitte: Lasst uns mal ein ordentliches Konzept machen, wie wir
a) verschiedene Nutzerlevel integrieren koennen (Anfaenger,
Profi, Developer, Tester, ...)
b) das Setup sinnvoll hinbekommen, so dass die Leute
auch die alpha/beta/... Versionen ohne grobe Probleme zum
Laufen bekommen. (Vielleicht beim ersten Login ein paar
Fragen direkt im tf, und auf Grund der Antworten das
Playerfile schreiben?)
c) ein Config-Interface machen koennen, wo User jederzeit alle
relevanten Konfigurationen machen koennen - ohne das Mud zu
verlassen - mit Reload der veaenderten Optionen etc.
d) die Modularisierung so nutzen koennen, dass man
Funktionalitaet abwaehlen kann (ctm brauch ich, window
ausgabe nicht, Scrolltext auch nicht, ...)
Wenn wir das Konzept haben, dann sollten wir es auch asap umsetzen -
das wuerden dem Projekt imho einen etwas professionelleren Touch
geben, momentan hat das Ganze was von halbkontrolliertem Wildwuchs.
lg,
Dennis/Mua
--
dennis hammer
mailto: dh...@ac...
|
|
From: Michael H. <mh...@in...> - 2001-09-17 08:40:32
|
2001-09-17 04:38 mh14 =09* status.test, status.tf: Einfache Statuszeilendefinition nach =09Ollis Konzept, Beispiele in status.test 2001-09-17 02:36 mh14 =09* untroom.def: ein paar mehr Highlightworde von Foobar 2001-09-17 00:15 mh14 =09* untroom.def, untroom.tf: hervorheben interessanter worte (z.b. =09fuer aktionen) 2001-09-16 23:20 mh14 =09* untroom.def, untroom.tf: unterdrueckung der mudausgabe eingebaut 2001-09-16 21:53 mh14 =09* util.vfunc.tf: find_usages zum Auflisten aller Makros die ein =09Makro/eine Variable benutzen 2001-09-16 21:52 mh14 =09* doc/config: gedanken zum konfiguration der pakete 2001-09-16 14:38 mh14 =09* untroom.def, untroom.tf: default_details (z.b. himmel, boden, =09wand, decke) hinzugefuegt 2001-09-15 21:51 mh14 =09* lists.tf: scrollverringerung beim listenladen 2001-09-15 21:50 mh14 =09* build.sh: zum release bauen build.sh versionsnr 2001-09-15 21:50 mh14 =09* loading.cfg: histsize im connect hook 2001-09-15 21:49 mh14 =09* tf.sh: Startscript fuer Normalnutzer 2001-09-15 21:48 mh14 =09* loading.tf: custom um -d erweitert, histsize jetzt im =E7onnect =09hook 2001-09-15 21:47 mh14 =09* properties.tf: updateplayer per default verzoegtert 2001-09-15 21:45 mh14 =09* base_files.def: i18n,util.vfunc wegen custom mit vorgezoegen 2001-09-15 00:38 mh14 =09* help_de.list, helpindex_de.list: neu generiert 2001-09-15 00:30 mh14 =09* help.tf: Indexseite aller Makros bei HTML-Hilfe Generierung 2001-09-15 00:22 mh14 =09* lists.test: error durch not_found ersetzt um runtest.sh nicht zu =09verwirren 2001-09-15 00:21 mh14 =09* lists.tf: hsortForEach mit forEach_key,_value 2001-09-15 00:19 mh14 =09* util.vfunc.tf: inner_var fuer Aufloesung verschachtelter =09Variablenreferenzen 2001-09-15 00:18 mh14 =09* loading.tf: neue parameter (-vvarname, -l, -p) fuer custom und =09damit /mload,/loadlist,/savelist 2001-09-14 20:41 olm =09* mg.mud.de/mg_properties.tf: /tf_prompt statt manueller Definition =09des Alias-Triggers 2001-09-14 20:23 olm =09* mg.mud.de/mg_properties.tf: Subguild eingefuehrt (Clans, =09Zweige...) (p_subguild). Muss aus den Gildenfiles per =09/get_subguild aktualisiert werden. 2001-09-14 18:27 mh14 =09* lists.test: error -> not_found, damit runtest.sh nicht verwirrt =09wird 2001-09-14 16:33 nieten =09* help_de.list, helpindex_de.list: /getidxofkey, /getidxofvalue in =09lists.tf hinzugefuegt 2001-09-14 15:51 mh14 =09* htdocs/index.html: Startseite Projekt 2001-09-14 00:06 nieten =09* lists.test: Test fuer /getidxofkey, /getidxofvalue 2001-09-14 00:06 nieten =09* lists.tf: /getidxofkey, /getidxofvalue 2001-09-13 17:30 nieten =09* tools/tf.el: regexps ueberarbeitet, '\C-xc' mit tf-checkfile =09belegt 2001-09-13 15:35 mh14 =09* tools/cvs2cl.pl: aus projektverz aufrufen, erzeugt, prima =09change-log datei 2001-09-13 11:25 mh14 =09* tftags.sh: Tag file Generator fuer vi und emacs (mit Tags kann =09man in allen files defs suchen, ueber alle files search und replace =09machen usw.) 2001-09-13 03:47 nieten =09* doc/statuszeile.aussehen: Was muss/kann rein? 2001-09-13 01:36 mh14 =09* tools/tf.el:=09missing \ 2001-09-13 01:32 mh14 =09* mg.mud.de/customize.cfg: mud-specifig user config 2001-09-13 01:27 mh14 =09* keys.def: Konfig fuer keys.tf 2001-09-13 01:27 mh14 =09* doc/statuszeile: Ideen 2001-09-13 01:08 mh14 =09* mg.mud.de/customize.tf: keys.tf 2001-09-13 01:07 olm =09* doc/: statuszeile, statuszeile: Allgemeine Gedanken 2001-09-13 00:30 mh14 =09* help_de.list, helpindex_de.list: neue Hilfe (keys.tf) 2001-09-13 00:27 mh14 =09* keys.tf: Refaktoriert, mehrfaches Neubinden der Funktionstasten =09ist raus Konfiguration in keys.def keys.cfg und customize.cfg /line =09in util.echo.tf verschoben etwas Doku geschrieben 2001-09-13 00:25 mh14 =09* util.echo.tf: /line aus keys.tf verschoben 2001-09-13 00:25 mh14 =09* loading.tf: customize.cfg wird zusaetzlich geladen 2001-09-13 00:25 mh14 =09* base_files.cfg: keys.tf eingefuegt 2001-09-12 14:04 olm =09* keys.tf: Warnungen beim Belegungswechsel beseitigt 2001-09-12 13:38 olm =09* keys.tf: Mehrfach-Tastenbelegung 2001-09-12 11:25 mh14 =09* tools/tf.el: tf Mode fuer Emacs 2001-09-12 10:06 mh14 =09* base_files.def: i18n eingebunden 2001-09-12 10:05 mh14 =09* util.timer.tf: /timer bereinigt 2001-09-12 10:05 mh14 =09* runtest.sh: erweiterter Fehlertest 2001-09-12 10:03 mh14 =09* i18n.def, i18n.tf: Internationalisierung 2001-09-12 02:43 mh14 =09* lists.test: Zeittests fuer forEach/hforEach 2001-09-12 02:00 mh14 =09* help_de.list, helpindex_de.list: neugenerierte Hilfe 2001-09-12 01:51 mh14 =09* util.tf: Funktion vlines sichtbare Zeilen 2001-09-12 01:49 mh14 =09* mg.mud.de/most.list: bereinigt 2001-09-12 01:49 mh14 =09* help.tf, help_keywords_de.list, help_keywords_en.list: 2 neue =09Hilfeparameter opt: Optionen param: Parameter 2001-09-12 01:39 mh14 =09* lists.tf: showlist,hshowlist erweitert fuer bedingtes anzeigen =09von Sublisten, seitenweises Anzeigen forEach hat jetzt die lokalen =09Variablen forEach_key und forEach_value, die in den aufgerufenen =09eigenen Makros genutzt werden koennen (statt der Parameter - Fehler =09bei Leerzeichen in Schluesseln) editlist kann schon ein wenig was =09:) 2001-09-11 22:56 mh14 =09* way.tf: erweitertes read eingebaut 2001-09-11 22:53 mh14 =09* util.prompts.tf: Versuch einer Zusatzfunktion von /prompt 2001-09-11 22:52 mh14 =09* util.echo.tf: Erweiteres Read (ext_read) mit Eingabeprompt und =09Defaultwert in Eingabezeile simple_menu ein Menue mit =09Kommandodarstellung und Auswahl per Zahl 2001-09-10 21:48 mh14 =09* util.prompts.tf: h_action_prompt generalisiert 2001-09-10 20:29 mh14 =09* help.tf: slash bug entfernt 2001-09-10 01:07 mh14 =09* doc/News: gesammelte Mail 2001-09-10 00:29 mh14 =09* help.def, help.tf: Hilfegenerierung/HTML 2001-09-10 00:21 mh14 =09* untroom.tf, util.repeat.tf: Bug in Doku 2001-09-09 21:16 mh14 =09* lists.tf, util.abbrev.tf, util.hooks.tf, util.prompts.tf, =09util.repeat.tf, mg.mud.de/customize.tf, mg.mud.de/user.tf: requires =09bereinigt 2001-09-09 21:07 mh14 =09* helpindex_de.list, help_de.list, loading.def, status.tf, =09util.abbrev.tf, util.completion.tf, util.debug.tf, util.def, =09util.echo.tf, util.hooks.tf, util.prompts.tf, util.quote.tf, =09util.repeat.tf, util.sfunc.tf, util.stack.tf, util.timer.tf, =09util.trigger.tf, util.vfunc.tf, util.windows.tf, =09mg.mud.de/allg_status.tf, mg.mud.de/mg_properties.tf, =09mg.mud.de/user.list: help_de.list 2001-09-09 21:06 mh14 =09* loading.tf: remove_cvs verschoben, bug in list_required 2001-09-09 21:05 mh14 =09* help.tf: fuer File Eintrag reicht ein /addh_fileinfo 2001-09-09 21:05 mh14 =09* base_files.def: loading.tf per mload geladen 2001-09-07 02:55 mh14 =09* loading.tf: Versionscheck beim Laden 2001-09-07 02:55 mh14 =09* loading.def:=09Farbe fuer Versionskonflikt 2001-09-07 02:54 mh14 =09* doc/files: Versionscheck beschrieben 2001-09-07 02:06 mh14 =09* loading.tf: /load_config generell als /load_depend fuer =09zugeordnete Dateien 2001-09-07 02:06 mh14 =09* loading.def:=09loaded hook fuer Unit Testing erweitert 2001-09-07 02:05 mh14 =09* base_files.def: util.debug.tf wegen Testen als Basis vorladen 2001-09-07 02:04 mh14 =09* doc/: files, literatur, testen: [no log message] 2001-09-07 02:04 mh14 =09* util.debug.tf: test_result fuer Unit Testing 2001-09-07 02:01 nieten =09* util.tf: wecho_hook sollte jetzt funktionieren 2001-09-07 02:01 mh14 =09* runtest.sh: TF_TEST_RUN fuer Unit Test eingebaut 2001-09-07 02:00 mh14 =09* util.sfunc.test: erster Unit Test 2001-09-07 01:09 mh14 =09* doc/: concept, files: Infos zu den Files 2001-09-07 01:08 mh14 =09* base_files.cfg, base_files.def: properties.tf in base_files.def 2001-09-07 00:57 nieten =09* util.tf, util.def: wecho_attr statt wecho_color 2001-09-07 00:44 mh14 =09* util.cfg, util.def, util.tf:=09wecho generalisiert 2001-09-07 00:34 mh14 =09* runtest.sh, runtf.sh: Log 2001-09-07 00:32 mh14 =09* loading.tf: etwas andere Fehlermeldung beim Laden 2001-09-07 00:28 mh14 =09* runtf.sh: Anzeige der Parameter 2001-09-07 00:28 mh14 =09* runtest.sh: test ohne checkout 2001-09-07 00:22 nieten =09* help.tf: Hilfetexte ueberarbeitet. 2001-09-07 00:15 mh14 =09* runtf.sh: wieder die lokale .tfrc 2001-09-07 00:14 mh14 =09* runtest.sh: Bug entfernt 2001-09-07 00:13 mh14 =09* loading.tf: wieder ganz 2001-09-07 00:12 mh14 =09* runtest.sh: Testprogramm fuer Laden der Files 2001-09-07 00:02 mh14 =09* loading.tf: kuenstlicher Fehler 2001-09-06 23:47 mh14 =09* runtf.sh: Umgebungsvariable TF_TESTUSER wird genutzt wenn nicht =09gesetzt, dann kein login 2001-09-06 23:19 mh14 =09* .tfrc, runtf.sh: aktuelles Verzeichnis als Makroverz. 2001-09-06 23:14 mh14 =09* mg.mud.de/most.list.tf: neue Endung list 2001-09-06 23:11 mh14 =09* .tfrc, base_files.cfg, base_files.def, base_init.tf, help.tf, =09lists.tf, loading.def, loading.tf, properties.tf, status.tf, =09untroom.def, untroom.tf, user_config.cfg, util.abbrev.tf, =09util.completion.tf, util.debug.tf, util.def, util.echo.tf, =09util.hooks.tf, util.prompts.tf, util.quote.tf, util.repeat.tf, =09util.sfunc.tf, util.stack.tf, util.tf, util.timer.tf, =09util.trigger.tf, util.vfunc.tf, util.windows.def, util.windows.tf, =09way.def, way.tf, mg.mud.de/allg_status.tf, mg.mud.de/customize.tf, =09mg.mud.de/mg_properties.tf, mg.mud.de/most.list.tf, =09mg.mud.de/uselists.tf, mg.mud.de/user.tf: Log eingefuegt 2001-09-06 22:56 mh14 =09* loading.def: Entfernen unnoetiger cvs tags 2001-09-06 22:40 mh14 =09* help_de.list.tf, help_keywords_de.list.tf, =09help_keywords_en.list.tf, helpindex.list.tf, helpindex_de.list.tf: =09neue Endung list 2001-09-06 22:35 mh14 =09* mg.mud.de/most.list, help_de.list, help_keywords_de.list, =09help_keywords_en.list, helpindex.list, helpindex_de.list: Endung =09list 2001-09-06 22:32 mh14 =09* help.tf, lists.tf, loading.tf, properties.tf, status.tf, =09untroom.tf, util.abbrev.tf, util.completion.tf, util.debug.tf, =09util.echo.tf, util.hooks.tf, util.prompts.tf, util.quote.tf, =09util.repeat.tf, util.sfunc.tf, util.stack.tf, util.tf, =09util.timer.tf, util.trigger.tf, util.vfunc.tf, util.windows.tf, =09way.tf, mg.mud.de/allg_status.tf, mg.mud.de/customize.tf, =09mg.mud.de/mg_properties.tf, mg.mud.de/uselists.tf, =09mg.mud.de/user.tf: $ eingefuegt 2001-09-06 22:05 nieten =09* mg.mud.de/uselists.tf: Hilfetexte ueberarbeitet. 2001-09-06 21:58 nieten =09* mg.mud.de/mg_properties.tf: Hilfetexte ueberarbeitet. 2001-09-06 21:58 mh14 =09* loading.tf: Nochmal Id test 2001-09-06 21:55 nieten =09* mg.mud.de/: customize.tf, allg_status.tf: Hilfetexte =09ueberarbeitet. 2001-09-06 21:52 mh14 =09* loading.tf: Test von $id$ 2001-09-06 21:43 nieten =09* util.def: Defaulteinstellungen fuer /wecho. 2001-09-06 21:35 nieten =09* way.tf: Hilfetexte ueberarbeitet. 2001-09-06 20:18 nieten =09* util.windows.tf: Hilfetexte ueberarbeitet. 2001-09-06 20:15 nieten =09* util.trigger.tf, util.vfunc.tf: Hilfetexte ueberarbeitet. 2001-09-06 20:09 nieten =09* util.timer.tf: Hilfetexte ueberarbeitet. 2001-09-06 20:06 nieten =09* util.tf: Hilfetexte ueberarbeitet. /wecho etwas erweitert =09(Ein/Aus-Schalter, Farbe) 2001-09-06 19:41 nieten =09* util.repeat.tf, util.sfunc.tf, util.stack.tf: Hilfetexte =09ueberarbeitet. 2001-09-06 19:36 nieten =09* util.prompts.tf, util.quote.tf: Hilfetexte ueberarbeitet. 2001-09-06 19:32 nieten =09* util.echo.tf, util.hooks.tf: Hilfetexte ueberarbeitet. 2001-09-06 19:28 nieten =09* util.abbrev.tf, util.debug.tf: Hilfetexte ueberarbeitet. 2001-09-06 19:25 nieten =09* untroom.tf: Hilfetexte ueberarbeitet. 2001-09-06 19:12 nieten =09* properties.tf: Hilfetexte ueberarbeitet. 2001-09-06 19:06 nieten =09* lists.tf: Hilfetexte ueberarbeitet. 2001-09-06 18:33 nieten =09* loading.tf: Hilfstexte ueberarbeitet. . 2001-09-06 14:55 mh14 =09* cvstf: cvs script 2001-09-06 14:49 mh14 =09* .tfrc: Aenderung von Standardmakroverzeichnis 2001-09-06 14:28 mh14 =09* runtf.sh: Startscript fuer Developer 2001-09-06 14:04 mh14 =09* base_init.tf, help.tf, .tfrc, base_files.cfg, base_files.def, =09help_de.list.tf, help_keywords_de.list.tf, =09help_keywords_en.list.tf, helpindex.list.tf, helpindex_de.list.tf, =09lists.tf, loading.def, loading.tf, properties.tf, status.tf, =09tfread, untroom.def, untroom.tf, user_config.cfg, util.abbrev.tf, =09util.completion.tf, util.debug.tf, util.def, util.echo.tf, =09util.hooks.tf, util.prompts.tf, util.quote.tf, util.repeat.tf, =09util.sfunc.tf, util.stack.tf, util.tf, util.timer.tf, =09util.trigger.tf, util.vfunc.tf, util.windows.def, util.windows.tf, =09way.def, way.tf, mg.mud.de/customize.tf, mg.mud.de/most.list.tf, =09mg.mud.de/user.tf, mg.mud.de/allg_status.tf, =09mg.mud.de/mg_properties.tf, mg.mud.de/uselists.tf, =09mg.mud.de/user.list: Initial revision 2001-09-06 14:04 mh14 =09* base_init.tf, help.tf, .tfrc, base_files.cfg, base_files.def, =09help_de.list.tf, help_keywords_de.list.tf, =09help_keywords_en.list.tf, helpindex.list.tf, helpindex_de.list.tf, =09lists.tf, loading.def, loading.tf, properties.tf, status.tf, =09tfread, untroom.def, untroom.tf, user_config.cfg, util.abbrev.tf, =09util.completion.tf, util.debug.tf, util.def, util.echo.tf, =09util.hooks.tf, util.prompts.tf, util.quote.tf, util.repeat.tf, =09util.sfunc.tf, util.stack.tf, util.tf, util.timer.tf, =09util.trigger.tf, util.vfunc.tf, util.windows.def, util.windows.tf, =09way.def, way.tf, mg.mud.de/customize.tf, mg.mud.de/most.list.tf, =09mg.mud.de/user.tf, mg.mud.de/allg_status.tf, =09mg.mud.de/mg_properties.tf, mg.mud.de/uselists.tf, =09mg.mud.de/user.list: Basic |
|
From: Michael H. <mh...@in...> - 2001-09-10 08:54:30
|
> Ich denke mal, es wird darauf hinauslaufen, dass wir mehr oder weniger > alles machen - sowohl die Basis, als auch die aufbauenden Dinge. > > Wichtig waere wohl, dass wir uns mal ueberlegen, welche > Funktionalitaet wir in der Basis haben wollen. SQL, C/S-Kommunikation, > ...? > > Installationsprogramm und Adminprogramm sehe ich als wichtig an, wenn > wir das Paket unter die Leute bringen wollen. TF-Portal: Hattest Du da > nicht ein Angebot, bzw. eine Anfrage, wie man das machen koennte? Mein > Angebot, das Teil bei uns zu hosten, steht immer noch. > Hmm hosten koennen wir das ja problemlos mit auf sourceforge ? oder irre ich mich da? Ich wuerde mir demnaechst mal das interaktive editlist vornehmen, damit kann man dann ne ganze Menge von Sachen halt als Listen bereitstellen und von den Leuten bei Bedarf editieren lassen. Installprog. ist zur zeit ja noch cvs update -d && runtf.sh :) Hmm ich schau mal wie wir das mit den mudspezifischen Sachen noch machen koennen, zur Zeit isses halt sehr MG-spezifisch. Mesi |
|
From: Dennis H. <den...@wa...> - 2001-09-10 07:42:21
|
MH> Bisher war es ja etwas ruhig, was die Vorschlaege betraf. MH> Wir koennen folgendes tun: MH> + weiter an der Basis basteln diese erweitern (Crypt, keys, SQL, ...) MH> + spezifische Sachen, die auf der Basis aufbauen, einpflegen, debuggen, MH> erweitern (Statuszeilen, Kampfmakros) MH> + neue Dinge hinzunehmen (wollten wir nichtmal kampfmeldungen.tf MH> umstrukturieren bzw. zu 90% neuschreiben :), muesste man mal mit Tiamak MH> reden MH> + apropos: sollten wir vielleicht lieber den Kreis der Entwickler MH> erweitern? MH> * Morgengrauen Leute (wer?, oder offen) MH> * Leute von der tf Mailingliste (offen?) MH> * Installationsprog, Adminprog (z.b. Nutzer anlegen) MH> * Internationalisierung MH> * Noch nette Ideen was man mit dem TF noch erleichtern koennte (btw. ich MH> nehm auf Arbeit TF auch als Debug-Filter/Highlighter) MH> * Editlist (Interaktiv) MH> * TF-Portal? (hab ich ja nur traurige Anfaenge von, Dennis vor) MH> * ... Ich denke mal, es wird darauf hinauslaufen, dass wir mehr oder weniger alles machen - sowohl die Basis, als auch die aufbauenden Dinge. Wichtig waere wohl, dass wir uns mal ueberlegen, welche Funktionalitaet wir in der Basis haben wollen. SQL, C/S-Kommunikation, ...? Installationsprogramm und Adminprogramm sehe ich als wichtig an, wenn wir das Paket unter die Leute bringen wollen. TF-Portal: Hattest Du da nicht ein Angebot, bzw. eine Anfrage, wie man das machen koennte? Mein Angebot, das Teil bei uns zu hosten, steht immer noch. -- * Dipl.-Ing. (FH) Dennis Hammer * Director of Technology * wap.at Internetservices GmbH * Schillerstr. 30 A-5020 Salzburg |
|
From: Michael H. <mh...@in...> - 2001-09-10 07:08:53
|
Moin, Ich hab mal nen kleinen Digest meiner letzten Mails ins CVS und auf die Webseite getan. Noch eine Frage an Euch. Wie verfahren wir weiter? Bisher war es ja etwas ruhig, was die Vorschlaege betraf. Wir koennen folgendes tun: + weiter an der Basis basteln diese erweitern (Crypt, keys, SQL, ...) + spezifische Sachen, die auf der Basis aufbauen, einpflegen, debuggen, erweitern (Statuszeilen, Kampfmakros) + neue Dinge hinzunehmen (wollten wir nichtmal kampfmeldungen.tf umstrukturieren bzw. zu 90% neuschreiben :), muesste man mal mit Tiamak reden + apropos: sollten wir vielleicht lieber den Kreis der Entwickler erweitern? * Morgengrauen Leute (wer?, oder offen) * Leute von der tf Mailingliste (offen?) * Installationsprog, Adminprog (z.b. Nutzer anlegen) * Internationalisierung * Noch nette Ideen was man mit dem TF noch erleichtern koennte (btw. ich nehm auf Arbeit TF auch als Debug-Filter/Highlighter) * Editlist (Interaktiv) * TF-Portal? (hab ich ja nur traurige Anfaenge von, Dennis vor) * ... Schreibt mal irgendwas, sonst komme ich mir so allein vor :) Micha |
