Benutzer Diskussion:Draco Ellmano

aus FreewarWiki, der Referenz für Freewar
Zur Navigation springen Zur Suche springen
Archiv 40px-TK_archive_icon.svg.png
2006
2007
2008
2010
2012
2014
2015
2016
2017

parameterverschiebung

hat das einen anderen grund außer kosmetik? oder hast du was größeres geplant? bin etwas neugierig^^--sniGG why so serious? 00:41, 8. Jan. 2015 (CET)

siehe hier. mein plan ist, diese liste per bot einmal pro woche mit allen awaffen aktuell zu halten und dann endlich mal diese ganzen artikel die unterschiedliche verweise oder doppelte bzw evtl falsche Werte enthalten (Nav Bars und so) alle per vorlagen davon aufbauen lassen. Die Parameterverschiebung ist ehrlich gesagt meiner Faulheit geschuldet, mein Pattern in dem Script trifft, wenn im Artikel die |Mindeststärke= vor dem |Stärke= steht eben das und ich fand es einfacher die paar Artikel zu korrigieren als mir jetzt noch mehr Muster auszudenken oder noch mehr Überprüfungen reinzuhauen^^ (sieht man in der History der Liste ganz schön, in der letzten Version stehn die Weltenwandlerkralle und der Zweihänder noch merkwürdig weit vorne, da sie mit der Mindeststärke 1.XXX vor dem StärkeParameter aufgetrumpft haben und das Regex so nur die Zahl genommen hat, was in dem Fall nur ne 1 war. Wenn wir irgendwann in den Bereich kommen, dass die Waffen über 1k Angriff haben muss das script dann eben nachgebessert werden und auch den Punkt akzeptieren^^) Draco Ellmánò oh?! 01:08, 8. Jan. 2015 (CET)

Elixier der Bewegung

Die Falschschreibung sollte eigentlich selbsterklärend gewesen sein. Ganz offensichtlich wurde das in der Zwischenzeit gefixt. --Sphinx ΔpΔx≥ℎ 09:30, 9. Feb. 2015 (CET)

ach da stand wirklich im elixir selbst was von lebenspunkten? das ist witzig. dachte es wäre hier nur in den falschen artikel gerutscht :D Draco Ellmánò oh?! 10:51, 9. Feb. 2015 (CET)

Artikellöschungen

Tag, hab hier: Benutzer:Draco Ellmano/Projekte/NavBars ein bischen was entlinkt, da die Hauptartikel gelöscht wurden. --schönen März, Zabu aφ(n)≡ 1(mod n) 14:29, 22. Mär. 2015 (CET)

jupp, sorry und danke, hätt ich noch gemacht, wurde aber von meinem leben außerhalb des bildschirms mitten in der arbeit eingeholt^^ Draco Ellmánò oh?! 15:59, 22. Mär. 2015 (CET)

Kategorie:Seiten, in denen die maximale Größe eingebundener Vorlagen überschritten ist

Jo, das passiert, wenn Vorlagen zu oft eingebunden werden. Eine mögliche Lösung wäre eventuell bei PflanzenZeile das msgnw in ein #vardefine zu klatschen und dann die #var zu lesen, statt jedes mal neu einzubinden. --Bwoebi Hier diskutieren bitte 19:36, 25. Mär. 2015 (CET)

jupps, hab mir eh schon überlegt, dass das für den server vermutlich nich ganz so prickelnd ist da zig mal die seite komplett einzulesen für jedes regex, irgendwann nimmt das unangenehme maßstäbe an^^ aber ich habs heut mittag ja nur kurz versucht (daher auch extra mit dem alten regex) weil ich mit dem vwaffen bzw awaffen datensatz mal schnell überprüfen wollte ob da alle itembilder vom w1 server sind da mir aufgefallen ist, dass so manches item bilder von anderen servern nimmt. Draco Ellmánò oh?! 19:59, 25. Mär. 2015 (CET)

artikelbereinigung

moin! sinn? leute wie ich müssen jetzt bei jeder änderung in die doku der vorlagen gucken um neue parameter auszufüllen. oder beim copy-pasten aufpassen, dass nix vergessen wird. :(--sniGG why so serious? 22:23, 1. Apr. 2015 (CEST)

huhu, naja 1. ist ne doku doch genau für sowas da und 2. (hauptsächlich^^) betrifft das meinen aktuellen versuch die pflanzen auch durch einen parser zu schicken um die völling unaktuelle, unvollständige und teils falsche liste bei den pflanzen auszumerzen. sowas passiert eben wenn sämtliche daten an 10 stellen gespeichert werden, jeder vergisst mal irgendwo was zu aktualisieren, daher ist eigentlich die einzig vernünftige lösung das ganze aus den einzelnen pflanzeartikeln aufzubauen, dort geht nämlich jeder hin der irgendwas verändern will. und weil ich zugegebenermaßen nicht unbedingt fließend regex spreche und eine einfache lösung an der stelle für mich auch eigentlich mehr wiegt als ein wenig bequem-sein beim aktualisieren des artikels selbst hab ich jetzt hier mal alle pflanzen glatt gezogen, hauptgrund war eigentlich nur die anordnung der unterschiedlichen funktionsvariablen (ZutatChaoslabor etc), aber zb solche zusätze wie KatzegorieZusatz hab ich mit freude gelöscht, die variable mag ich scho seit 8 jahren nicht :D
tl;dr: ich will n parser für die pflanzen aufbauen, dafür hab ich die artikel jetzt in ne schön saubere form gebracht (Was auch sonst eigentlich ja nicht störend ist) damit das so klappt, aber es ist natürlich jeder willkommen das ganze selbst zu machen und dafür andere bzw verquerere artikelstrukturen zu nutzen^^ Draco Ellmánò oh?! 23:02, 1. Apr. 2015 (CEST)
die sache is, sowas is extrem fehleranfällig. es braucht ja nur jemand kommen und nen parameter an der falschen stelle einfügen und schwupps, machts keinen sinn mehr, richtig? da wäre es *denke ich* besser gewesen, die reihenfolge der parameter zu ändern, statt sie zu löschen. und naja, die werte "none", "keine" etc gibts nicht umsonst. ich weiß nicht, an wie vielen stellen die infos aus den pflanzenartikeln genutzt werden, aber so grob geschätzt.. an 1 einzigen?--sniGG why so serious? 23:28, 1. Apr. 2015 (CEST)
die parameter die es betrifft hab ich ja geändert, das war der hauptgrund für die änderungen, das löschen von |quest und so bei none hatte ehrlich gesagt nur optischen grund^^ ja aktuell weiss ich auch nur von der Pflanzenliste hier, aber wenn ich mir die checklisten anschaue wächst sowas ja auch gern ma schnell an, dann muss es irgendwann noch dort in ner navbar aktualisiert werden, dort in ner übersicht und hier die werte. daher ja damals das auslagern der v und awaffe, dort muss jetzt jeweils einfach nur ein script laufen und dann ein artikel geändert werden (und das muss auch nur geschehen wenn wirklich neue waffen dazu kommen, wenn sich nur werte ändern muss nichts geschehn und gerade da seh ich n problem bei den pflanzen, da steht bei einigen min und max wert von stufen noch gar nich fest (bzw eig sogar eher falsch da sie mal alle fälschlicherweise auf 5er schritte angepasst wurden) und daher find ich es eigentlich nicht schlecht sowas automatisch laufen zu lassen). sprich: ja es wird nur an einer stelle eingetragen, aber wenn ich jetzt nur irgendwo ne pflanze ernte und bemerke dass die stufe höher/ tiefer ist als die im wiki, dann kann ich einfach im artikel die stufe ändern und muss mich nicht noch um irgendwelche listen kümmern Draco Ellmánò oh?! 23:51, 1. Apr. 2015 (CEST)
da würde es sich eher anbieten, es wie bei NPCs (Liste) zu machen. sprich die listen halbautomatisch erzeugen. weil wie gesagt, so gut deine idee auch sein mag, wenn der regex nicht flexibel ist, haben wir, die das wiki warten, das problem, dass wir dauerhaft auf die anordnung der parameter achten müssen. und das ist etwas viel verlangt^^ ist das bei waffen denn derzeit auch so, dass die reihenfolge der parameter ne rolle spielt? wobei sehe grad ja. habe das damals schon angemerkt, aber nicht weiter kommentiert. schade eigentlich. und wenn man bei waffen und pflanzen sowieso 1 script laufen lassen muss, dann ändert sich am (derzeitigen) aufwand im vergleich zu einer fehlerresistenten lösung eigentlich nichts. just my 2 cts. du solltest den fokus auf rohdatenerfassung per user opt-in (siehe npcs-liste beispiel) legen und dann deine automatisierten dinger auf die rohdaten draufhauen. regex mit einer beliebigen sprache deiner wahl sollte dir dann auch eher helfen als der wikisyntax.--sniGG why so serious? 01:10, 2. Apr. 2015 (CEST)

mit dem weg sind aber änderungen, die gerade bei pflanzen und stufen relativ häufig kommen dürften, immer wieder mit dem "aufwand" verbunden scripte laufen zu lassen und das kann nicht jeder normal-nutzer, einfach eine zahl im artikel ändern kann jeder. ich versteh aber worauf du hinauswillst und seh es ja selbst auch als problem, wenn jemand besser oder genauer regex kann darf er ja auch gerne helfen (so wie bwoebi von zeit zu zeit)^^. was die reihenfolge der parameter bei den waffen angeht: dort war das problem nur bei stärke und mindeststärke, zwei einträge die von anfang an bei einem artikel bzw nach erzeugen durch die vorlage drin sind (in der richtigen reihenfolge) und ich kann mir nur schwer vorstellen, dass sotrax irgendwann ne stärke anforderung aus ner waffe nimmt oder sie später hinzufügt. und was die reihenfolge hier bei den pflanzen (bisher) betrifft: es geht nur um die verwundungsmöglichkeiten, die ist in der aktuellen tabelle auch alles andere als vollständig und ich hab jetzt nur mal die bestehenden pflanzen nach dem aufbau aus der vorlage geordnet, sprich wenn es mehrere verwendungen (chaoslabor, zauberlabor, handwerk, stätte, sonstiges) gibt, dann greift er (mit der aktuellen suche) nur das jeweils erste ab, daher hab ich die alle so umsortiert, dass zb chaoslabor ganz hinten steht, sprich wenn die pflanze für irgendwas anderes gebraucht wird steht das als verwendung und chaoslabor steht eben nur da wenn die pflanze eben für nix anderes gut ist. (bsp Dunkelgrottenmoos). wenn jetzt irgendwann eine funktion eingeführt wird und sie jemand nachträglich ergänzt gibt es zwei möglichkeiten: entweder er schreibt es vor das aktuell getroffene muster, dann wird das neue als wichtiger erachtet und er zeigt das an. oder er schreibt es danach, dann steht weiterhin das alte als wichtigstes und er zeigt weiterhin das an. das finde ich noch um klassen besser als das aktuelle, wo die liste teilweise "falsch" ist (bsp Goldsonnen-Blümchen) denn diese pflanze hat offensichtlich irgendwann an funktion gewonnen. also wenn in meinem system eine pflanze eingebaut wird die noch keine funktion hat, dann zeigt er an keine funktion. wenn sie dann aber iwann eine bekommt, dann zeigt er sie auch an. wenn es vorher schon eine gab kommt es auf die reihenfolge an. man könnte vll die vorlage für eine neue blume, item, waffe etc sowieso mal um einen auskommentierten hinweis über alle möglichen zutatenparameter ergänzen, da gibt es inzwischen so absurd viele, da ist man quasi sowieso gezwungen in die dokumentation zu schauen. so wall of text zu meinem vorhaben, aber wie gesagt, ich bin ja nicht beratungsresistent oder will hier alles alleine machen, hilfe bzw änderungsvorschläge sind natürlich willkommen und an der stelle kann ich offen sagen: 1. das switch für die unterschiedlichen verwendungen ist eh noch lang nich final und 2. wird es verdammt komplex wenn reihenfolge egal sein soll (oder sogar alle möglichen verwendungen eingetragen werden sollten) daher bin ich hilfe absolut nicht abgeneigt^^ Draco Ellmánò oh?! 01:49, 2. Apr. 2015 (CEST)

Ohne jetzt die Romane gelesen zu haben: Die Funktionsweise der Vorlage etc sollte in keinster Weise von der Reihenfolge der Parameter abhängen. Zudem ein regulärer Ausdruck nie Wiki-Vorlage lesen können wird. Ist bei mir schon etwas her aber Chomsky könnte dir das besser erklären ;)
PS: Du kannst dich an der Funktionsweise von Feldern und Karten orientieren. Diese Vorlagen machen, glaub ich, genau das, was du versuchst zu erreichen. --Sphinx ΔpΔx≥ℎ 11:32, 2. Apr. 2015 (CEST)
ja stimmt, die funktionsweise sollte eigentlich nich davon abhängen aber irgendwie muss ich halt eine priorisierung der verschiedenen verwendungen bekommen. also entweder les ich immer komplett und mach intern ne reihenfolge um das "wichtigste" rauszusortieren oder ich geh halt (so wie aktuell) einfach nach der reihenfolge. ich schau ma ob bzw inwiefern ne hierarchie in der Parse-Vorlage selbst möglich bzw machbar ist, ne idee hätt ich schonma. der ganze aufbau ist schon sehr an den karten orientiert, das klappt auch alles schon (siehe Angriffswaffe), hier bei den Pflanzen ist allerdings bei der Verwendungspalte halt doch größerer suchaufwand im artikel selbst^^Draco Ellmánò oh?! 11:50, 2. Apr. 2015 (CEST)
Ja aber ganz ehrlich das hast du nicht allein zu entscheiden. Ich bin definitiv dagegen auch nur bei einer Vorlage die Reihenfolge der Parameter vorzuschreiben. Bisher haben wir uns auch auf Skripte verlassen und wenn wir das Vorgehen ändern, dann überall. Aber nicht einfach bei Pflanzen anders Vorgehen nur weil du einen "Parser" schreiben willst. --Sphinx ΔpΔx≥ℎ 13:30, 2. Apr. 2015 (CEST)