GW2Wiki Diskussion:Formatierung/Eigenschaften
Klasse muss immer ausgefüllt werden.[Bearbeiten]
Steht in der Erklärung. Sogar mit „Wichtig!“. Warum? -- 08:51, 13. Aug. 2012 (CEST)
- Ich würde mal sagen, weil die Listen sonst überflüssig lang sind, und einen Haufen Fertigkeiten aufzählen, die man sowieso nicht benutzen kann. --Think 08:55, 13. Aug. 2012 (CEST)
- Dass man die richtigen Filter nehmen soll scheint mir eigentlich klar. Ich habe beim Anlegen von Seiten eben einige Male „klasse“ nicht ausgefüllt, wenn es sowieso ein klassenspezifischer Fertigkeitstyp war, daher stolperte ich jetzt über die Formulierung. -- 09:00, 13. Aug. 2012 (CEST)
- Ja gut, macht wenig Sinn bei klassenspezifischen Fertigkeitstypen. Als Formatierungsvorlage ist es allerdings sinnvoller als zu sagen "Wenn da so ein Fertigkeitstyp ist, dann so, sonst so". Nachdem du die Listenvorlage vervollständigt hast (warum ist mir das nie aufgefallen), ist das Endergebnis jetzt ja sowieso dasselbe. --Think 09:02, 13. Aug. 2012 (CEST)
- Ich hab das jetzt umformuliert, ohne deine Antwort gelesen zu haben, war also nicht bewusst entgegen dem Kommentar. Ich finde es für Wikiverständnis tatsächlich sinnvoller, solche „auf jeden Fall“ bzw. „muss“ Anweisungen nur dort zu geben, wo sie wirklich definitiv gelten. Denn auch ohne die Angabe liefert es in etlichen Fällen das richtige Ergebnis, ohne genug Überblick kommt man dann in die seltsame Situation, sich zwischen „ich finde keinen Fehler“ und „ich glaube dennoch stumpf der Richtlinie“ entscheiden zu müssen. Gerade wenn bei der Vorlage selbst dann „klasse“ als optionaler Parameter steht, macht es das nicht besser. Mir ist es lieber die Leute verstehen was sie tun, als einen halben Satz einzusparen. -- 09:15, 13. Aug. 2012 (CEST)
- Ja gut, macht wenig Sinn bei klassenspezifischen Fertigkeitstypen. Als Formatierungsvorlage ist es allerdings sinnvoller als zu sagen "Wenn da so ein Fertigkeitstyp ist, dann so, sonst so". Nachdem du die Listenvorlage vervollständigt hast (warum ist mir das nie aufgefallen), ist das Endergebnis jetzt ja sowieso dasselbe. --Think 09:02, 13. Aug. 2012 (CEST)
- Dass man die richtigen Filter nehmen soll scheint mir eigentlich klar. Ich habe beim Anlegen von Seiten eben einige Male „klasse“ nicht ausgefüllt, wenn es sowieso ein klassenspezifischer Fertigkeitstyp war, daher stolperte ich jetzt über die Formulierung. -- 09:00, 13. Aug. 2012 (CEST)
Elementarmagier: Effekte abhängig von Einstimmung[Bearbeiten]
Beim Elementarmagier gibt es einige Eigenschaften, die je nach aktueller Einstimmung einen anderen Effekt hervorrufen. Beispiel: Inschrift (Eigenschaft). Schön wäre es, wenn man das so formartieren könnte, wie im Spiel - also:
- Macht (20s)
Das könnte man für die betroffenen Fertigkeiten zwar manuell machen, schöner wäre es aber über die Effekt-Vorlage, da sie an entsprechenden Stellen auch Attribute setzt. Leider setzt die Vorlage immer einen Zeilenumbruch bei Verwendung, sodass ich ohne größere Änderung der Vorlage keine "schnelle Lösung" gefunden habe. Wie wollen wir das bei den betroffenen Eigenschaften machen? Manuell? Vorlage umschreiben? Oder sieht jemand eine andere schöne Alternative? -- 10:37, 10. Nov. 2013 (CET)
- Hm, wir könnten der Vorlage einfach noch einen Parameter "einstimmung" geben, und die setzt dann halt ein zusätzliches Icon davor, wenn der gesetzt ist. --Think 10:40, 10. Nov. 2013 (CET)
- Das war mein erster Gedanke, aber dann gibts nen Zeilenumbruch (bei derzeitiger Gestaltung der Vorlage) -- 10:47, 10. Nov. 2013 (CET)
- Jo, ich mach das gleich mal, da muss nur der Doppelpunkt für die Einrückung nach ganz vorne vor den #switch geschoben werden. Wenn davon nichts kaputt geht, sollte das dann alles in einer Zeile sein. --Think 11:07, 10. Nov. 2013 (CET)
- Das wäre auch mein Lösungsansatz gewesen, wollte das vorab aber angesprochen haben, bevor ich an der Vorlage rumdoktor. -- 11:13, 10. Nov. 2013 (CET)
- Ok. :) Viele andere schöne Möglichkeiten gibt es auch nicht. Ich denke, es funktioniert jetzt. --Think 11:18, 10. Nov. 2013 (CET)
- Das wäre auch mein Lösungsansatz gewesen, wollte das vorab aber angesprochen haben, bevor ich an der Vorlage rumdoktor. -- 11:13, 10. Nov. 2013 (CET)
- Jo, ich mach das gleich mal, da muss nur der Doppelpunkt für die Einrückung nach ganz vorne vor den #switch geschoben werden. Wenn davon nichts kaputt geht, sollte das dann alles in einer Zeile sein. --Think 11:07, 10. Nov. 2013 (CET)
- Das war mein erster Gedanke, aber dann gibts nen Zeilenumbruch (bei derzeitiger Gestaltung der Vorlage) -- 10:47, 10. Nov. 2013 (CET)
Beschaffung[Bearbeiten]
Seit dem letzten Patch muss ja für jede Eigenschaft auch eine Beschaffung mit eingetragen werden. Und zwar würde ich dafür gerne eine Vereinfachung haben, ähnlich wie bei den Champion-Kisten und den Exotischen Waffen.
- Experten Eigenschaften kosten immer 10 + 2
- Meister Eigenschaften kosten immer 50 + 5
- Großmeister Eigenschaften XI und XII kosten immer 1 50 + 10
- Großmeister Eigenschaften XIII kosten immer 3 + 20
Dan gibt es noch die Beschaffung durch Events. Da dürfte es immer so sein, dass die Eigenschaftslinie 1 (Also die, die ganz oben steht), und die Eigenschaftsnummer zusammengehört. Also das Feuermagie XIII und Beherrschung XIII das gleiche Event benötigen. Wäre es damit möglich, eine Vorlage zu erstellen, um nicht immer riesen copy-paste-Texte zu erstellen, wo man bei einer Änderung massenweise hinterherarbeiten müsste, und evtl vielleicht was übersieht/vergisst usw.
Die zweite Sache wären dann diese "Eigenschaftsbücher". Wollen wir für jedes Kompendium eine eigene Seite anlegen? Die Informationen der Seiten wären ja immer nur: Eigenschaftsname, Kosten, Klassentrainer. Und das wäre dann bei allen 30 Experten-Eigenschaften einer Klasse immer die selbe Information, nur das die Überschrift ändert. Ich persönlich würde die Information dann einfach mit im BEschaffungsartikel der Eigenschaft einpflegen. -- 14:29, 16. Apr. 2014 (CEST)
- Die Freischaltung ist tatsächlich für jede Eigenschaftsreihe von oben nach unten identisch. Da wäre es kein Problem eine Vorlage z.B. "Eigenschaftsfreischaltung" oder so zu erstellen, die das dann übernimmt. Bei den Büchern würde ich das auch eher reduzieren. Mehr als "Buch [Eigenschaft] schaltet [Eigenschaft] frei" wäre da ja nicht zu bieten. Man kann ja notfalls z.B. auch Weiterleitungen machen. --Think 18:15, 16. Apr. 2014 (CEST)
- Stimme zu. Bei den Büchern reicht ein Artikel "Eigenschaftsanleitung", in dem dann unterteilt nach Klassen die verschiedenen Bücher in einer Tabelle stehen. Ggf.nochmal mit Spalten für Kosten und Link auf die freigeschaltete Eigenschaft. Da jetzt 13x5x8 (=520) Artikel zu erstellen, wäre Quatsch. -- 21:35, 16. Apr. 2014 (CEST)
Icons[Bearbeiten]
Ich hab jetzt mal probehalber die Icons von Macht des Schnitters und Boshafter Talisman hochgeladen. Wollen wir die so nehmen, oder lieber wie bei den Fertigkeiten noch etwas gegen den schwarzen Rand machen? --Hraun (Diskussion) 22:08, 23. Jun. 2015 (CEST)
- Sieht im Artikel echt nicht so gut aus.... Ne Schablone wäre wohl nötig. --Drake 22:13, 23. Jun. 2015 (CEST)
- Ich habe eben auch im Spiel mal geschaut wegen den Icons. Dort findet sich auch die Maske, die über alle Icons gelegt ist. Habe auf meiner Benutzerseite mal nur das Icon für die Nebeneigenschaft gebaut. (in 32x32) -- 22:18, 23. Jun. 2015 (CEST)
- Wunderbar :) Gekauft! --Drake 22:24, 23. Jun. 2015 (CEST)
- Prima, dann lade ich sie einfach so hoch, und die Vorlagen können den Rest erledigen. --Hraun (Diskussion) 22:24, 23. Jun. 2015 (CEST)
- Auch eben nochmal für die Haupteigenschaft eingebaut, die haben eine eigene Maske im Spiel. -- 22:26, 23. Jun. 2015 (CEST)
- Wir haben eine ZIP-Datei von Stéphane mit allen Icons bekommen, allerdings auch mit Rand, also bevor ihr jetzt den Aufwand betreibt, die alle rauszusuchen, könnte ich die auch hochladen, sind 4MB. Ich könnte die auch einmal durch Photoshop jagen, um die Maske direkt anzuwenden, dann müssten wir nicht mehrere Vorlagen anpassen, um die Maske zu unterstützen. Das hatten wir ja bisher bei den Icons auch so gemacht. --Think 22:55, 23. Jun. 2015 (CEST)
- Muss ja nur die Vorlage Eigenschaft Icon angepasst werden. Die kann ja überall eingebunden werden, wo man das Icon braucht. Natürlich wäre es schneller für uns, wenn du das durch Photoshop jagst, aber für nachträgliche Anpassungen ist die Schablone besser, denke ich... --Drake 23:10, 23. Jun. 2015 (CEST)
- Ja, so gesehen schon. Effekt-Vorlage fällt mir noch ein. Könnte man auch geregelt kriegen. Hier sind die Dateien (mit Rand), könnt ihr also schon hochladen. Dateinamen sind wohl teilweise nicht korrekt, aber die Nummerierung sollte stimmen. --Think 23:12, 23. Jun. 2015 (CEST)
- Der Effekt hat doch wahrscheinlich ein Icon mit Rand, oder? Dann sollten wir das auch so machen. --Drake 23:50, 23. Jun. 2015 (CEST)
- Wir haben das mal grade ausprobiert. Ist mit so einer Schablone ziemlich umständlich, weil es Darstellungsprobleme wegen der alternierenden Farben gibt, wenn man die Alphamaske nach ganz oben legt. Die Maske entfernt dann auch die Hintergrundfarbe der Zellen. Chiubi ist grade dabei, die Icons durch das Photoshop-Skript zu werfen und wird dann die Icons direkt mit Alphakanal hochladen. --Think 12:59, 24. Jun. 2015 (CEST)
- So, nochmal anders. Wir haben jetzt alle Neben-Eigenschaften direkt mit Alphakanal erledigt und ich werde die jetzt hochladen. Die Haupt-Eigenschaften lassen wir mit Ausnahme der Anzeige in der Infobox mit Rand, weil das sonst wie oben schonmal angesprochen sehr unschöne Kanten in der Effekt-Vorlage gibt. In der verkleinerten Darstellung sieht man das sowieso nicht und durch die Schablone gehen unter anderem gefärbten Tabellen nicht ordentlich. Die Haupt-Eigenschaften-Icons können also weiterhin hochgeladen werden - Hraun ist ja da dran. :) --Think 17:00, 24. Jun. 2015 (CEST)
- Ich habe leider keinen Mesmer oder Dieb, und würde die Dateien nur ungern auf Verdacht hochladen. Das könnte bitte jemand anderes übernehmen. --Hraun (Diskussion) 21:26, 24. Jun. 2015 (CEST)
- Dieb mache ich nach Löwenstein. --Drake 21:36, 24. Jun. 2015 (CEST)
- Okay, ich nehme die Bilder und lade sie einfach hoch und sie haben Meta-Daten. Liegt wohl irgendwie an mir. Schön ist das nicht... Das hatten wir doch schon mal irgendwo, oder? --Drake 22:21, 26. Jun. 2015 (CEST)
- Nö, manche Metadaten werden z.B. bei Photoshop trotz deaktivierter Einstellung reingespeichert. Ganz weg gehen die nur, wenn du die dann nochmal durch z.B. pngcrush wirfst, das hatte ich bei den Neben-Eigenschaften gemacht. --Think 22:56, 26. Jun. 2015 (CEST)
- Habt ihr die "Mit Rand"-Icons aus der ZIP-Datei direkt von Stéphane oder nochmal nachbearbeitet?--Dusk (Diskussion) 12:33, 27. Jun. 2015 (CEST)
- Nö, manche Metadaten werden z.B. bei Photoshop trotz deaktivierter Einstellung reingespeichert. Ganz weg gehen die nur, wenn du die dann nochmal durch z.B. pngcrush wirfst, das hatte ich bei den Neben-Eigenschaften gemacht. --Think 22:56, 26. Jun. 2015 (CEST)
- Okay, ich nehme die Bilder und lade sie einfach hoch und sie haben Meta-Daten. Liegt wohl irgendwie an mir. Schön ist das nicht... Das hatten wir doch schon mal irgendwo, oder? --Drake 22:21, 26. Jun. 2015 (CEST)
- Dieb mache ich nach Löwenstein. --Drake 21:36, 24. Jun. 2015 (CEST)
- Ich habe leider keinen Mesmer oder Dieb, und würde die Dateien nur ungern auf Verdacht hochladen. Das könnte bitte jemand anderes übernehmen. --Hraun (Diskussion) 21:26, 24. Jun. 2015 (CEST)
- So, nochmal anders. Wir haben jetzt alle Neben-Eigenschaften direkt mit Alphakanal erledigt und ich werde die jetzt hochladen. Die Haupt-Eigenschaften lassen wir mit Ausnahme der Anzeige in der Infobox mit Rand, weil das sonst wie oben schonmal angesprochen sehr unschöne Kanten in der Effekt-Vorlage gibt. In der verkleinerten Darstellung sieht man das sowieso nicht und durch die Schablone gehen unter anderem gefärbten Tabellen nicht ordentlich. Die Haupt-Eigenschaften-Icons können also weiterhin hochgeladen werden - Hraun ist ja da dran. :) --Think 17:00, 24. Jun. 2015 (CEST)
- Wir haben das mal grade ausprobiert. Ist mit so einer Schablone ziemlich umständlich, weil es Darstellungsprobleme wegen der alternierenden Farben gibt, wenn man die Alphamaske nach ganz oben legt. Die Maske entfernt dann auch die Hintergrundfarbe der Zellen. Chiubi ist grade dabei, die Icons durch das Photoshop-Skript zu werfen und wird dann die Icons direkt mit Alphakanal hochladen. --Think 12:59, 24. Jun. 2015 (CEST)
- Der Effekt hat doch wahrscheinlich ein Icon mit Rand, oder? Dann sollten wir das auch so machen. --Drake 23:50, 23. Jun. 2015 (CEST)
- Ja, so gesehen schon. Effekt-Vorlage fällt mir noch ein. Könnte man auch geregelt kriegen. Hier sind die Dateien (mit Rand), könnt ihr also schon hochladen. Dateinamen sind wohl teilweise nicht korrekt, aber die Nummerierung sollte stimmen. --Think 23:12, 23. Jun. 2015 (CEST)
- Muss ja nur die Vorlage Eigenschaft Icon angepasst werden. Die kann ja überall eingebunden werden, wo man das Icon braucht. Natürlich wäre es schneller für uns, wenn du das durch Photoshop jagst, aber für nachträgliche Anpassungen ist die Schablone besser, denke ich... --Drake 23:10, 23. Jun. 2015 (CEST)
- Wir haben eine ZIP-Datei von Stéphane mit allen Icons bekommen, allerdings auch mit Rand, also bevor ihr jetzt den Aufwand betreibt, die alle rauszusuchen, könnte ich die auch hochladen, sind 4MB. Ich könnte die auch einmal durch Photoshop jagen, um die Maske direkt anzuwenden, dann müssten wir nicht mehrere Vorlagen anpassen, um die Maske zu unterstützen. Das hatten wir ja bisher bei den Icons auch so gemacht. --Think 22:55, 23. Jun. 2015 (CEST)
- Auch eben nochmal für die Haupteigenschaft eingebaut, die haben eine eigene Maske im Spiel. -- 22:26, 23. Jun. 2015 (CEST)
- Prima, dann lade ich sie einfach so hoch, und die Vorlagen können den Rest erledigen. --Hraun (Diskussion) 22:24, 23. Jun. 2015 (CEST)
- Wunderbar :) Gekauft! --Drake 22:24, 23. Jun. 2015 (CEST)
- Ich habe eben auch im Spiel mal geschaut wegen den Icons. Dort findet sich auch die Maske, die über alle Icons gelegt ist. Habe auf meiner Benutzerseite mal nur das Icon für die Nebeneigenschaft gebaut. (in 32x32) -- 22:18, 23. Jun. 2015 (CEST)
(Einrückung zurückgesetzt) Den entfernten Eigenschaften könnten wir ebenfalls Icons verpassen (und zwar die, die sie vor der Umstellung verwendet hatten), damit sie aus der Fehlende-Dateien-Kategorie rausfallen. Wäre nur die Frage ob man da für jede Eigenschaft das Icon nochmal hochlädt, oder die Infobox entsprechend anpasst, um andere Icons verwenden zu können. --Hraun (Diskussion) 19:31, 27. Jun. 2015 (CEST)
- @Dusk: Direkt aus der Datei. --Drake 19:35, 27. Jun. 2015 (CEST)
- Bessere Idee: die entfernten Eigenschaften einfach löschen... wofür sollten wir die aufbewahren? Gibt es da irgendeine Relevanz? --Think 19:37, 27. Jun. 2015 (CEST)
- Manchmal ist es doch ganz nett sich ansehen zu können, was da entfernt wurde. Vor allem, wenn man ungefähr wieder dort ankommen möchte, wo man vor dem Update war. --Hraun (Diskussion) 20:10, 27. Jun. 2015 (CEST)
- Die Icons hochzuladen hatte ich übrigens deswegen in Betracht gezogen, weil wir dann die Vorlagen nicht an irgendwelche Sonderfälle anpassen müssten. Jetzt zeigt zwar die Infobox das alte Icon an, in den Updatenotizen wird aber natürlich kein Icon angezeigt, da Eigenschaft Icon das nicht unterstützt, und ebenfalls auf etwas angepasst werden muss, was längst nicht mehr im Spiel ist. Dazu kommt noch, dass in Zukunft entfernte Eigenschaften dann das falsche Icon anzeigen würden, weil „entfernt=altes Icon“ dann nicht mehr zutrifft. Daher wollte ich ursprünglich erst mal diskutieren wie man am sinnvollsten vorgeht, und nicht direkt an den Vorlagen rumbasteln. Zumal alles zu behalten ja auch nicht in Stein gemeißelt ist. --Hraun (Diskussion) 13:52, 28. Jun. 2015 (CEST)
- Hätte ich auch bevorzugt. Die Vorlage habe ich dann nur bearbeitet, damit es wenigstens dort keine komplett halbe Sache ist. Grundsätzlich macht es denke ich, wenn wir sie behalten wollen, nur Sinn, die Bilder als Duplikate neu hochzuladen unter dem Namen der Eigenschaft, weil wir sonst wie du schon sagst Mehraufwand betreiben müssen, nur um "veraltete" Informationen vorzuhalten. Wenn wir die Eigenschaften behalten, kann man dann auch optional noch reinschreiben, zu was sie geändert wurden oder z.B. dass die Funktion direkt in die Klasse übergegangen ist. --Think 14:34, 28. Jun. 2015 (CEST)
- Möchte sonst noch jemand zu dem Thema etwas beitragen? --Hraun (Diskussion) 10:39, 22. Jul. 2015 (CEST)
- Am "wartungsfreundlichsten" wäre es natürlich alles zu löschen was nicht mehr im Spiel ist. Persönlich find ich das aber nicht so prall. Zwecks der Doku und dem "Wie war es mal?" und dem "War das nicht schon mal da?" ists natürlich schön wenn man das behalten würde. Man muss halt nur gucken wie man das mit dem geringsten Gefummel bei zukünftigen Änderungen an Vorlagen etc. hinbekommt. Also irgendwas wie ne spezielle Vorlage nur für historisches mit eigenen Atrributen etc die nix durcheinanderbringen bei aktuellen Zeugs und den "normalen" Vorlagen, falls sowas sinvoll und möglich ist.--Dusk (Diskussion) 19:03, 22. Jul. 2015 (CEST)
- Das gewünschte Verhalten bieten unsere aktuellen Vorlagen doch schon, wenn man
entfernt=ja
setzt, das Problem ist nur, dass die Eigenschafts-Infobox jetzt (nach Drakes Änderung) für alle Eigenschaften bei Setzen dieses Parameters die alte Benennung der Icons erzwingt (die nur mit der Nummer drauf). Wenn wir aber jetzt eine neue Eigenschaft mitentfernt
markieren, hätte diese dann ebenfalls das alte Benennungs-Icon, obwohl sie ja ein eigenes hätte. Darum war der Vorschlag, diese Funktion wieder zu entfernen (weil sie unter anderem auch Probleme mit der Icon-Vorlage macht), und stattdessen bei entfernten Eigenschaften (die wir nicht einfach löschen/verschieben) manuell das alte Nummer-Icon unter dem Namen der Eigenschaft hochzuladen, und damit auch keine weiteren Probleme mit der Eigenschafts-Iconvorlage zu bekommen. --Think 19:22, 22. Jul. 2015 (CEST)- Ah, so langsam dämmerts um was es euch geht, so richtig bin ich da vorher nicht durchgstiegen was genau gemeint war ;) Aber es sollte ja noch jmd was zum Thema schreiben, was wohl dann doch etwas daneben ging :P --Dusk (Diskussion) 20:00, 22. Jul. 2015 (CEST)
- Eine weitere Meinung zu „behalten oder löschen“ ist doch auch schon viel wert. ;-) --Hraun (Diskussion) 17:04, 23. Jul. 2015 (CEST)
- Meinung zu letzterem: behalten. Meinung zu den Icons: Ja, dass neue Eigenschaften ja auch mal gelöscht werden könnten, habe ich nicht bedacht. Die alten Icons mehrfach hochzuladen halte ich für zu umständlich. Der Parameter "icon" sollte es regeln, oder? --Drake 20:04, 23. Jul. 2015 (CEST)
- Ja, das war es was ich mit „die Infobox entsprechend anpasst“ eigentlich meinte. Da gibt es aber zu bedenken, dass dann alle Eigenschaften-Vorlagen zusätzlich immer das Icon abfragen müssen, obwohl es keine Eigenschaften im laufenden Betrieb gibt, die ein anders benanntes Icon verwenden. Macht die Sache dann nicht unbedingt schneller. Auf der anderen Seite wären wir damit auch schon dafür gerüstet, dass es ja auch irgendwann mal Eigenschaften mit Doppelpunkt o.ä. im Namen geben könnte, deren Icon dann ja anders benannt werden muss.
- Mir geht es jetzt auch nicht darum die Icons unbedingt hochzuladen. Das wäre aber halt eine einmalige Angelegenheit, durch die man bei den Vorlagen nichts weiter berücksichtigen muss. --Hraun (Diskussion) 12:44, 24. Jul. 2015 (CEST)
- Morgen hätte ich Zeit, um das in Angriff zu nehmen. Meinungen? --Drake 18:35, 24. Jul. 2015 (CEST)
- Letzlich wäre die Variante mit icon-Parameter eher konsistent mit unseren anderen Vorlagen. --Think 19:51, 24. Jul. 2015 (CEST)
- Dann machen wir es wohl am sinnvollsten einfach so. --Hraun (Diskussion) 10:02, 1. Aug. 2015 (CEST)
- Letzlich wäre die Variante mit icon-Parameter eher konsistent mit unseren anderen Vorlagen. --Think 19:51, 24. Jul. 2015 (CEST)
- Morgen hätte ich Zeit, um das in Angriff zu nehmen. Meinungen? --Drake 18:35, 24. Jul. 2015 (CEST)
- Meinung zu letzterem: behalten. Meinung zu den Icons: Ja, dass neue Eigenschaften ja auch mal gelöscht werden könnten, habe ich nicht bedacht. Die alten Icons mehrfach hochzuladen halte ich für zu umständlich. Der Parameter "icon" sollte es regeln, oder? --Drake 20:04, 23. Jul. 2015 (CEST)
- Eine weitere Meinung zu „behalten oder löschen“ ist doch auch schon viel wert. ;-) --Hraun (Diskussion) 17:04, 23. Jul. 2015 (CEST)
- Ah, so langsam dämmerts um was es euch geht, so richtig bin ich da vorher nicht durchgstiegen was genau gemeint war ;) Aber es sollte ja noch jmd was zum Thema schreiben, was wohl dann doch etwas daneben ging :P --Dusk (Diskussion) 20:00, 22. Jul. 2015 (CEST)
- Das gewünschte Verhalten bieten unsere aktuellen Vorlagen doch schon, wenn man
- Am "wartungsfreundlichsten" wäre es natürlich alles zu löschen was nicht mehr im Spiel ist. Persönlich find ich das aber nicht so prall. Zwecks der Doku und dem "Wie war es mal?" und dem "War das nicht schon mal da?" ists natürlich schön wenn man das behalten würde. Man muss halt nur gucken wie man das mit dem geringsten Gefummel bei zukünftigen Änderungen an Vorlagen etc. hinbekommt. Also irgendwas wie ne spezielle Vorlage nur für historisches mit eigenen Atrributen etc die nix durcheinanderbringen bei aktuellen Zeugs und den "normalen" Vorlagen, falls sowas sinvoll und möglich ist.--Dusk (Diskussion) 19:03, 22. Jul. 2015 (CEST)
- Möchte sonst noch jemand zu dem Thema etwas beitragen? --Hraun (Diskussion) 10:39, 22. Jul. 2015 (CEST)
- Hätte ich auch bevorzugt. Die Vorlage habe ich dann nur bearbeitet, damit es wenigstens dort keine komplett halbe Sache ist. Grundsätzlich macht es denke ich, wenn wir sie behalten wollen, nur Sinn, die Bilder als Duplikate neu hochzuladen unter dem Namen der Eigenschaft, weil wir sonst wie du schon sagst Mehraufwand betreiben müssen, nur um "veraltete" Informationen vorzuhalten. Wenn wir die Eigenschaften behalten, kann man dann auch optional noch reinschreiben, zu was sie geändert wurden oder z.B. dass die Funktion direkt in die Klasse übergegangen ist. --Think 14:34, 28. Jun. 2015 (CEST)
- Die Icons hochzuladen hatte ich übrigens deswegen in Betracht gezogen, weil wir dann die Vorlagen nicht an irgendwelche Sonderfälle anpassen müssten. Jetzt zeigt zwar die Infobox das alte Icon an, in den Updatenotizen wird aber natürlich kein Icon angezeigt, da Eigenschaft Icon das nicht unterstützt, und ebenfalls auf etwas angepasst werden muss, was längst nicht mehr im Spiel ist. Dazu kommt noch, dass in Zukunft entfernte Eigenschaften dann das falsche Icon anzeigen würden, weil „entfernt=altes Icon“ dann nicht mehr zutrifft. Daher wollte ich ursprünglich erst mal diskutieren wie man am sinnvollsten vorgeht, und nicht direkt an den Vorlagen rumbasteln. Zumal alles zu behalten ja auch nicht in Stein gemeißelt ist. --Hraun (Diskussion) 13:52, 28. Jun. 2015 (CEST)
- Manchmal ist es doch ganz nett sich ansehen zu können, was da entfernt wurde. Vor allem, wenn man ungefähr wieder dort ankommen möchte, wo man vor dem Update war. --Hraun (Diskussion) 20:10, 27. Jun. 2015 (CEST)
- Bessere Idee: die entfernten Eigenschaften einfach löschen... wofür sollten wir die aufbewahren? Gibt es da irgendeine Relevanz? --Think 19:37, 27. Jun. 2015 (CEST)
Fertigkeit mit in Artikel[Bearbeiten]
Verschoben von Diskussion:Nicht zu fassen#Fertigkeit mit in Artikel.
Hey, ich wollte mal fragen, was Ihr davon haltet, die Fertigkeit, die von einer Eigenschaft ausgelöst wird, mit in den Artikel über die Infobox Fertigkeit einzubinden? Man müsste da zwar noch ein paar Anpassungen (speziell bei Attribut:Hat Fertigkeitsstatus, Attribut:Hat Nummer, Attribut:Hat Position und Attribut:Hat Positionsicon) machen, aber ich finde das eigentlich ganz schön so. --Drake 15:22, 11. Jul. 2015 (CEST)
- Die Infobox Fertigkeit ist jetzt schon viel zu viel zu sperrig. Welchen Vorteil hätte das im Vergleich zu unserer aktuellen Methode, die Fertigkeit linksbündig zu unterordnen? Dazu kommt, dass die Eigenschafts-Fertigkeiten z.B. kein Icon haben, und das mit der Infobox überhaupt nicht ordentlich aussehen würde. Mal von den unterschiedlichen Breiten abgesehen... Wenn, müsste man eine eigene Infobox machen, die nur für verknüpfte Fertigkeiten benutzt wird, und deren Layout man dann auch sinnvoll anpassen kann, z.B. an die Eigenschafts-Infobox. Daran hängen ja auch noch diverse Fertigkeitslisten, die mit den Eigenschafts-Fertigkeiten überhaupt nicht ordentlich umgehen können. Und natürlich die Tatsache, dass einige Sachen in der aktuellen Fertigkeits-Infobox und -Listenvorlage ziemlich unordentlich sind. --Think 15:29, 11. Jul. 2015 (CEST)
- Ja, an eine eigene Vorlage hatte ich auch gedacht. Die jetzige Methode sagt mir einfach nicht so zu. --Drake 15:31, 11. Jul. 2015 (CEST)
- Prinzipiell kann man die verknüpften Fertigkeiten mit sehr viel weniger Parametern beschreiben, als die Infobox Fertigkeit hat. Name, Beschreibung, Effekte, Aufladezeit. Wozu sie gehört ist sowieso klar anhand der Seite, wo sie sich befindet. Und dann bist du fertig. Übrigens gehört diese Diskussion auf eine der Portal-Seiten. --Think 15:34, 11. Jul. 2015 (CEST)
- Die Aufladezeit braucht man nicht einmal, oder? --Drake 15:38, 11. Jul. 2015 (CEST)
- Natürlich gibt es verknüpfte Fertigkeiten mit Aufladezeiten. Manchmal identisch zur Eigenschaft, manchmal hat die Eigenschaft aber auch keine und die verknüpfte Fertigkeit schon. --Think 15:39, 11. Jul. 2015 (CEST)
- Oh ja, sehe ich gerade bei In Schatten gehüllt. Damit der Stuzschaden nicht nur alle 40 Sekunden reduziert wird :P --Drake 15:42, 11. Jul. 2015 (CEST)
- Ich setz das hier jetzt mal fort. Ich habe mich eben mal an eine Infobox für diese Fertigkeiten gesetzt. Heraus kam in etwa sowas. Meinungen zum Layout oder andere Anmerkungen? --Saphir (Diskussion) 23:30, 4. Feb. 2016 (CET)
- Das würde ja nicht zu einer Eigenschaftsseite passen, wenn es dabei bleibt, dass wir Fertigkeiten die von Eigenschaften kommen, auch auf der Seite der Eigenschaft belassen. Sinnvollerweise würde man die "Verknüpfte Fertigkeit" also eher linksbündig wie z.B. die Vorlage:Rezept anordnen. --Think 17:33, 5. Feb. 2016 (CET)
- Es bestünde aber auch die Möglichkeit die Fertigkeiten in einen eigenen Artikel zu verschieben. Ausserdem: Was meinst du mit linksbündig? Die Infobox nach links und rechts davon die BEschreibung und Effektliste? --Saphir (Diskussion) 17:46, 5. Feb. 2016 (CET)
- Klar, Möglichkeiten bestehen immer. Aber macht das Sinn? Wir haben ja auch Kettenfertigkeiten auf der Hauptfertigkeitsseite zusammengefasst und nicht aufgeteilt. Es ist ja oft eine 1:1-Zuordnung von Eigenschaft zu Fertigkeit. Dazu kommt natürlich, dass fast alle unsere Eigenschaften mit verknüpften Fertigkeiten die Fertigkeit auf der Eigenschaftsseite schon haben. So würden auch diverse Parameter wegfallen, die man sonst duplizieren müsste (siehe oben in dieser Diskussion). --Think 19:38, 5. Feb. 2016 (CET)
- Ok ich hab nochmal ein wenig rumgeschoben. Das ganze ist jetzt auf der rechten Seite. Die Parameter Klasse und Spezialisierug muss man bisher noch setzen, allerdings lässt sich das sicher automatisch ergänzen. Wie genau muss ich aber noch schauen. Ich hatte da evtl an eine SMW-Abfrage gedacht, aber bin mir nicht sicher, ob das dann Probleme beim Kompilieren gibt. --Saphir (Diskussion) 12:57, 14. Feb. 2016 (CET)
- Bei Ausweichende Arkana sind 4 Fertigkeiten mit einer Eigenschaft verknüpft. An Stellen wie dieser würde ich es der Ordnung halber vorziehen die Fertigkeiten mithilfe von Infoboxen ordentlich untereinander zu schreiben oder sogar auf eigene Seiten zu verschieben. --Saphir (Diskussion) 15:35, 14. Feb. 2016 (CET)
- Ich muss ganz ehrlich sagen, dass ich das Layout nicht wirklich sinnvoll finde, und eher die sehr einfache Darstellung, wie sie bei Ausweichende Arkana und dem Großteil aller Fertigkeiten von Eigenschaften schon jetzt (manuell) umgesetzt wird, übernehmen würde. Das Hauptproblem ist ja nur, dass diese Fertigkeiten, wenn man sie manuell hinschreibt, nicht mit SMW-Attributen ausgestattet werden können, und nicht ordentlich gekapselt sind. --Think 16:14, 14. Feb. 2016 (CET)
- An sich gefällt mir das Layout bisher nicht so gut, aber man könnte es fürs Erste so umsetzen wie bisher. Ich bau das eben um... --Saphir (Diskussion) 16:59, 14. Feb. 2016 (CET)
- Ok auf ein neues. Mit einer Sache bin ich mir noch unschlüssig: Wohin mit dem Chatcode? An sich sollte das jetzt aber ungefähr dem Aktuellen Layout entsprechen. --Saphir (Diskussion) 17:23, 14. Feb. 2016 (CET)
- An sich gefällt mir das Layout bisher nicht so gut, aber man könnte es fürs Erste so umsetzen wie bisher. Ich bau das eben um... --Saphir (Diskussion) 16:59, 14. Feb. 2016 (CET)
- Ich muss ganz ehrlich sagen, dass ich das Layout nicht wirklich sinnvoll finde, und eher die sehr einfache Darstellung, wie sie bei Ausweichende Arkana und dem Großteil aller Fertigkeiten von Eigenschaften schon jetzt (manuell) umgesetzt wird, übernehmen würde. Das Hauptproblem ist ja nur, dass diese Fertigkeiten, wenn man sie manuell hinschreibt, nicht mit SMW-Attributen ausgestattet werden können, und nicht ordentlich gekapselt sind. --Think 16:14, 14. Feb. 2016 (CET)
- Klar, Möglichkeiten bestehen immer. Aber macht das Sinn? Wir haben ja auch Kettenfertigkeiten auf der Hauptfertigkeitsseite zusammengefasst und nicht aufgeteilt. Es ist ja oft eine 1:1-Zuordnung von Eigenschaft zu Fertigkeit. Dazu kommt natürlich, dass fast alle unsere Eigenschaften mit verknüpften Fertigkeiten die Fertigkeit auf der Eigenschaftsseite schon haben. So würden auch diverse Parameter wegfallen, die man sonst duplizieren müsste (siehe oben in dieser Diskussion). --Think 19:38, 5. Feb. 2016 (CET)
- Es bestünde aber auch die Möglichkeit die Fertigkeiten in einen eigenen Artikel zu verschieben. Ausserdem: Was meinst du mit linksbündig? Die Infobox nach links und rechts davon die BEschreibung und Effektliste? --Saphir (Diskussion) 17:46, 5. Feb. 2016 (CET)
- Das würde ja nicht zu einer Eigenschaftsseite passen, wenn es dabei bleibt, dass wir Fertigkeiten die von Eigenschaften kommen, auch auf der Seite der Eigenschaft belassen. Sinnvollerweise würde man die "Verknüpfte Fertigkeit" also eher linksbündig wie z.B. die Vorlage:Rezept anordnen. --Think 17:33, 5. Feb. 2016 (CET)
- Ich setz das hier jetzt mal fort. Ich habe mich eben mal an eine Infobox für diese Fertigkeiten gesetzt. Heraus kam in etwa sowas. Meinungen zum Layout oder andere Anmerkungen? --Saphir (Diskussion) 23:30, 4. Feb. 2016 (CET)
- Oh ja, sehe ich gerade bei In Schatten gehüllt. Damit der Stuzschaden nicht nur alle 40 Sekunden reduziert wird :P --Drake 15:42, 11. Jul. 2015 (CEST)
- Natürlich gibt es verknüpfte Fertigkeiten mit Aufladezeiten. Manchmal identisch zur Eigenschaft, manchmal hat die Eigenschaft aber auch keine und die verknüpfte Fertigkeit schon. --Think 15:39, 11. Jul. 2015 (CEST)
- Die Aufladezeit braucht man nicht einmal, oder? --Drake 15:38, 11. Jul. 2015 (CEST)
- Prinzipiell kann man die verknüpften Fertigkeiten mit sehr viel weniger Parametern beschreiben, als die Infobox Fertigkeit hat. Name, Beschreibung, Effekte, Aufladezeit. Wozu sie gehört ist sowieso klar anhand der Seite, wo sie sich befindet. Und dann bist du fertig. Übrigens gehört diese Diskussion auf eine der Portal-Seiten. --Think 15:34, 11. Jul. 2015 (CEST)
- Ja, an eine eigene Vorlage hatte ich auch gedacht. Die jetzige Methode sagt mir einfach nicht so zu. --Drake 15:31, 11. Jul. 2015 (CEST)
- (Einrückung zurückgesetzt) Mal ein Vorschlag inklusive "Rahmen", der sich an die Vorlage:Rezept anlehnt.
- Blutung (3s): 66 + 0,18 × Zustandsschaden Schaden
- Macht (20s): 30 Kraft, 30 Zustandsschaden
- Die Effekte wären dann ganz normal unter der Beschreibung, das ist aktuell noch aufgrund des CSS hässlich, aber behebbar. Alle restlichen Angaben würden dann ja schon auf der Seite der Eigenschaft weiter oben stehen. Für die SMW-Attribute kann die verknüpfte Fertigkeit diese Informationen dann auch per #var auslesen. --Think 12:32, 15. Feb. 2016 (CET)
- Das sieht in der Tat sehr viel ordentlicher aus. Inwiefern ist da etwas aufgrund von CSS hässlich? Meinst du die Effektliste? --Saphir (Diskussion) 13:35, 15. Feb. 2016 (CET)
- Ok auf ein neues. Ich weiß jetzt auf jeden Fall was du damit meintest, dass die Effekte hässlich aussehen. Wie mir scheint begrenzt die Infobox sie auf eine feste Breite, was wiederum für sehr unschöne Zeilenumbrüche sorgt. Was das übertragen der Werte aus der Infobox Eigenschaft angeht, muss ich da vermutlich nochmal ein paar variablen setzen, aber das sollte nicht problematisch sein. Was mich mehr stört ist der Balken links neben den Effekten (und die festgesetzte Breite). Ich habe auch schon überlegt, ob es vlt. möglich ist bei sehr breiten Effekten eine minimalistische Darstellung umzusetzen, denn Effekte wie Pein sind recht ausladend.--Saphir (Diskussion) 12:13, 9. Mär. 2016 (CET)
- Oha, ist bei mir irgendwie untergegangen. Im Prinzip kannst du die Box so benutzen (ich bearbeite das mal oben), es muss nur MediaWiki:Common.css angepasst werden, um das korrekt darzustellen. Letztlich sollte es genauso aussehen wie als würdest du die Effektliste in der Infobox Fertigkeit einfügen. --Think 12:51, 9. Mär. 2016 (CET)
- Ok, ich hab das CSS mal angepasst, hoffentlich ist nix kaputt :S Was die Breite angeht, evtl. kann man für diese Vorlage die "Details" der Effekt-Vorlage ausblenden und nur beim Überfahren oder so anzeigen. --Think 13:28, 9. Mär. 2016 (CET)
- Ok auf ein neues. Ich weiß jetzt auf jeden Fall was du damit meintest, dass die Effekte hässlich aussehen. Wie mir scheint begrenzt die Infobox sie auf eine feste Breite, was wiederum für sehr unschöne Zeilenumbrüche sorgt. Was das übertragen der Werte aus der Infobox Eigenschaft angeht, muss ich da vermutlich nochmal ein paar variablen setzen, aber das sollte nicht problematisch sein. Was mich mehr stört ist der Balken links neben den Effekten (und die festgesetzte Breite). Ich habe auch schon überlegt, ob es vlt. möglich ist bei sehr breiten Effekten eine minimalistische Darstellung umzusetzen, denn Effekte wie Pein sind recht ausladend.--Saphir (Diskussion) 12:13, 9. Mär. 2016 (CET)
- Das sieht in der Tat sehr viel ordentlicher aus. Inwiefern ist da etwas aufgrund von CSS hässlich? Meinst du die Effektliste? --Saphir (Diskussion) 13:35, 15. Feb. 2016 (CET)