PokéWiki:Allgemeine Diskussionsseite: Unterschied zwischen den Versionen

Aus PokéWiki
Zur Navigation springen Zur Suche springen
Zeile 254: Zeile 254:
:::::::Ich habe nun mal im Testwiki was gebastelt, zu sehen bei [[:test:Bisasam]] und [[:test:Silvarro]]. Im Grunde bleibt [[Vorlage:Atk-Table]] identisch, außer das die Vorlage nun nicht mehr alle Generationen unterstützt sondern nur noch eine, die via Parameter gesetzt wird und dazu führt, das zB die Kategorie nicht immer angezeigt wird. Das sonstige Verhalten mit [[Vorlage:AtkRow]] bleibt identisch. Was ich jetzt mal gebastelt hab war ein sogenannter flex container, der dazu führt, dass die einzelnen Tabellen dynamisch positioniert werden. Jede Tabelle hat dazu einen umschließendes div, in welchem auch die Überschrift und eventuelle Hinweise landen und der eine gewünschte Breite von 300px hat, sodass im Idealfall drei Tabellen nebeneinander passen. Gewünscht heißt hier jedoch, dass der Browser die Elemente auch anpassen kann, wenn Texte zu lang sind oder aus sonstigen Gründen das nicht passt und automatisch weitere Tabellen in die nächste Zeile verschiebt. Hierdurch wird vermieden, dass zu viele Tabellen in einer Zeile landen, gleichzeitig wird jedoch auch whitespace vermieden und die Artikel werden (hoffentlich) nicht überlang. Für die Einbindung in die Pokémon-Artikel hab ich jetzt erstmal die Vorlage [[:test:Vorlage:Attacken]] geschrieben, die kann man jedoch vermutlich auch anders lösen. Da die Attacken je nach Artikel unterschiedliche Hierachieebenen besitzen kann das "Basislevel" über eine Variable gesteuert werden, aktuell ist diese über die Attacken-Vorlage automatisiert. Was mir noch nicht ganz gefällt sind die Zusatzspiele (LGPE bei Bisasam, Überschrift ist natürlich anzupassen), hier müsste man nochmal was schöneres überlegen. Die Geschichte mit dem Togglen der vorherigen Generation hatte ich kurz probiert, scheitert aktuell jedoch an zwei getroffenen Designprinzipien: 1. sind unsere Toggler alle nicht wirklich mit Containern kompatibel, die einen eigenen display wert nutzen (flex in meinem Fall), hier müsste also technisch erstmal jemand ran (oder man nutzt unschöne Lösungen mit zusätzlichen Container außen rum, die dann aber auch wieder zu komischen Dingen führen können) und 2. sind die Überschriften dann komplett durcheinander (ausgeblendete Überschriften werden trotzdem dem Inhaltsverzeichnis hinzugefügt, ergo gibts die Überschriften sofort doppelt). Ich denke jedoch, dass man auch ohne die vorige Generation leben könnte. Ansonsten ist denke ich nicht viel zu den Artikeln zu sagen, die Tabellen sind wie gesagt weiter die bekannten. Dementsprechend ändert sich (wie Robbi auch schon festgestellt hat) die Parserausnutzung auch nicht allzu drastisch, es sieht nur etwas aufgeräumter aus. {{#icon:491}} [[Benutzer:Jones|<span style="color:#000000;text-shadow:0 0 1px #000, 0 0 3px #000, 0 0 5px #000;font-family:Century Gothic;font-size:130%">Jones</span>]] <sup>[[User Talk:Jones|<span style="color:black">Albtraum?</span>]]</sup> 16:30, 31. Mai 2019 (CEST)
:::::::Ich habe nun mal im Testwiki was gebastelt, zu sehen bei [[:test:Bisasam]] und [[:test:Silvarro]]. Im Grunde bleibt [[Vorlage:Atk-Table]] identisch, außer das die Vorlage nun nicht mehr alle Generationen unterstützt sondern nur noch eine, die via Parameter gesetzt wird und dazu führt, das zB die Kategorie nicht immer angezeigt wird. Das sonstige Verhalten mit [[Vorlage:AtkRow]] bleibt identisch. Was ich jetzt mal gebastelt hab war ein sogenannter flex container, der dazu führt, dass die einzelnen Tabellen dynamisch positioniert werden. Jede Tabelle hat dazu einen umschließendes div, in welchem auch die Überschrift und eventuelle Hinweise landen und der eine gewünschte Breite von 300px hat, sodass im Idealfall drei Tabellen nebeneinander passen. Gewünscht heißt hier jedoch, dass der Browser die Elemente auch anpassen kann, wenn Texte zu lang sind oder aus sonstigen Gründen das nicht passt und automatisch weitere Tabellen in die nächste Zeile verschiebt. Hierdurch wird vermieden, dass zu viele Tabellen in einer Zeile landen, gleichzeitig wird jedoch auch whitespace vermieden und die Artikel werden (hoffentlich) nicht überlang. Für die Einbindung in die Pokémon-Artikel hab ich jetzt erstmal die Vorlage [[:test:Vorlage:Attacken]] geschrieben, die kann man jedoch vermutlich auch anders lösen. Da die Attacken je nach Artikel unterschiedliche Hierachieebenen besitzen kann das "Basislevel" über eine Variable gesteuert werden, aktuell ist diese über die Attacken-Vorlage automatisiert. Was mir noch nicht ganz gefällt sind die Zusatzspiele (LGPE bei Bisasam, Überschrift ist natürlich anzupassen), hier müsste man nochmal was schöneres überlegen. Die Geschichte mit dem Togglen der vorherigen Generation hatte ich kurz probiert, scheitert aktuell jedoch an zwei getroffenen Designprinzipien: 1. sind unsere Toggler alle nicht wirklich mit Containern kompatibel, die einen eigenen display wert nutzen (flex in meinem Fall), hier müsste also technisch erstmal jemand ran (oder man nutzt unschöne Lösungen mit zusätzlichen Container außen rum, die dann aber auch wieder zu komischen Dingen führen können) und 2. sind die Überschriften dann komplett durcheinander (ausgeblendete Überschriften werden trotzdem dem Inhaltsverzeichnis hinzugefügt, ergo gibts die Überschriften sofort doppelt). Ich denke jedoch, dass man auch ohne die vorige Generation leben könnte. Ansonsten ist denke ich nicht viel zu den Artikeln zu sagen, die Tabellen sind wie gesagt weiter die bekannten. Dementsprechend ändert sich (wie Robbi auch schon festgestellt hat) die Parserausnutzung auch nicht allzu drastisch, es sieht nur etwas aufgeräumter aus. {{#icon:491}} [[Benutzer:Jones|<span style="color:#000000;text-shadow:0 0 1px #000, 0 0 3px #000, 0 0 5px #000;font-family:Century Gothic;font-size:130%">Jones</span>]] <sup>[[User Talk:Jones|<span style="color:black">Albtraum?</span>]]</sup> 16:30, 31. Mai 2019 (CEST)
:::::::Nachtrag: Auch wenn die grundsätzliche Meinung hier ziemlich einheitlich ist lasse ich shadow noch etwas Zeit zu reagieren bevor ich eine Abstimmung starte. {{#icon:491}} [[Benutzer:Jones|<span style="color:#000000;text-shadow:0 0 1px #000, 0 0 3px #000, 0 0 5px #000;font-family:Century Gothic;font-size:130%">Jones</span>]] <sup>[[User Talk:Jones|<span style="color:black">Albtraum?</span>]]</sup> 16:31, 31. Mai 2019 (CEST)
:::::::Nachtrag: Auch wenn die grundsätzliche Meinung hier ziemlich einheitlich ist lasse ich shadow noch etwas Zeit zu reagieren bevor ich eine Abstimmung starte. {{#icon:491}} [[Benutzer:Jones|<span style="color:#000000;text-shadow:0 0 1px #000, 0 0 3px #000, 0 0 5px #000;font-family:Century Gothic;font-size:130%">Jones</span>]] <sup>[[User Talk:Jones|<span style="color:black">Albtraum?</span>]]</sup> 16:31, 31. Mai 2019 (CEST)
:::::::: Danke für den Entwurf. Wo wir aber einmal an das Auslagern denken hätte ich die Frage ob man nicht auch gleich die vorhandenen Informationen erweitert. Ich denke da so an Gen 3,4,6 mit den Wettbewerbssachen oder zu welcher Z-Attacke inkl. Stärke/Kategorie sich die Attacken in <small>{{sk|So|Mo|US|UM}}</small> aufstufen lassen. Was auch so die Frage wäre ob es notwendig ist die Väter bzw. Eltern in der Unterseite zu toggln oder direkt anzuzeigen vorzugsweise mit dem icon-Parser. Das nebeneinander wirkt soweit bei den Pokémon okay. Allerdings denke ich bei Pokémon mit kurzem Move-Set und langer TM-Liste wirst du zwischen den Tabellen auch viel unschönen Whitespace haben. z.B. Mew (auch wenn dort aktuell keine TMs angezeigt werden, aber da gibts auch noch andere Kandidaten die mir gerade nicht einfallen) Gruß [[Benutzer:Ryuichi|<span style="font-family:Segoe Script;color:#397257;text-shadow:0 0 5px#397257,0 0 10px#397257;font-size:150%">* Ryuichi</span>]] ~ [[Datei:Sugimori_004.png|20px|link=]]<sup>'''[[Pokéwiki:Orte-Projekt|<span style="color:#00cc4f>PL</span>]]'''</sup> ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch [[Benutzer Diskussion:Ryuichi|<sup>Diskussion</sup>]] 17:03, 31. Mai 2019 (CEST)

Version vom 31. Mai 2019, 16:03 Uhr

Vorlage:TOC right

Überarbeitung der Firmen-Artikel

Ich hab mir gerade mal die Artikel angeguckt, die aus Vorlage:Firmen verlinkt werden und finde da muss mal was gemacht werden (ja, nicht nur da, aber irgendwo muss man ja mal anfangen). Da das ganze nach aktuellem Stand keinem Projekt zugeordnet ist (nein, das Spiele-Projekt kann nicht alles machen, auch wenn ich die Diskussion jetzt wieder anstoße), würde ich das ganze mal einfach hier besprechen wollen und dann im Laufe des Jahres da zu nem Ende kommen. Zum Start mal ein Überblick wie es aktuell ist: Kurze Einleitung, komplett unvollständige Liste aller entwickelten Spiele, Wikipedia-Link, wenns gut läuft noch nen Link zur Website der Firma, Vorlage, Ende. Das das nicht ansprechend ist muss ich denk ich keinem erklären. Was ich mir jetzt grob vorgestellt hätte als eine Art "Musterstruktur":

  • Infobox: Damit das Logo nicht komplett lose da rum fliegt wäre eine Infobox ala Wikipedia (natürlich etwas aufgehübscht) nicht ganz schlecht: Logo, Mitarbeiter(?), Gründung, Website, Sitz. Rechtsform oä brauchen wir denk ich nicht.
  • Kurze Einleitung (was hier genau rein sollte müsste man noch diskutieren)
  • Kurze Geschichte (wann aus welcher Firma hervorgegangen oä)
  • Bekannte Spielereihen (fehlt bisher komplett, zB bei Intelligent Systems die gesamte Fire-Emblem-Reihe)
  • Verbindung zu Pokémon (welche Spiele entwickelt, an welchen mitgearbeitet etc)
  • evtl Übersicht über die Verkaufsstärksten Spiele. Auf keinen Fall alle listen, das würde in einem Jahr wieder veraltet sein
  • Weiteres?

Andere Vorschläge, weitere Ideen, evtl fehlende Firmen, sonst was gewünschtes in dem Bereich? Jones Albtraum? 10:39, 17. Mär. 2018 (CET)

Gefällt mir, klingt schon fast nach einem Konzept, dass man so umsetzen könnte ^^ Aber gibt es wirklich genug Inhalt, um sowas auch ansprechend zu gestalten? Bisher haben die Artikel bis auf zwei Sätze in der Einleitung keinen Text und fünf Ein-Satz-Abschnitte schreiben, nur um die Abschnitte zu haben ist definitiv auch nicht die richtige Herangehensweise an das ganze... -- RobbiRobb 16:29, 17. Mär. 2018 (CET)
Finde ich gut so. Ich denke aber, die aufgezählten Punkte für das Konzept reichen. Geht ja eher um eine kurze Vorstellung. -- Liebe Grüße, Moltres 146.gif 16:57, 17. Mär. 2018 (CET)
Ich denke bei den meisten Firmen lässt sich deutlich mehr schreiben als aktuell der Fall. Guckt man bei (en) Wikipedia sieht man ja schon einiges mehr, da würde ich teilweise sogar eher weniger schreiben. Dazu sollen die Artikel ja auch nur grob nen Überblick liefern, was für ne Firma das ist und wie sie mit dem Pokémon-Franchise zu tun haben, bzw generell mit Nintendo.
Dazu noch nen Nachtrag: Abschnitte zu "Wichtigen Personen", wie aktuell bei Game Freak inc. würde ich streichen wollen. Die entsprechenden Personen werden sicherlich im Fließtext erwähnt, alles weitere sollte jedoch in Einzelartikeln (die in dem Fall ja auch alle haben) erläutert werden. Jones Albtraum? 17:09, 17. Mär. 2018 (CET)
Klingt gut --Datei:Sugimori 672.pngMecanno-manMäh 17:14, 17. Mär. 2018 (CET)

Zunächst mal: Das hier soll ne Diskussion werden, kein "Hört sich gut an, hauptsache ich muss nicht mitmachen" :$ Zum zweiten: Ich hatte oben schon angerissen, formulier es aber gerne auch nochmal deutlicher: Welche Firmen qualifizieren sich überhaupt für einen Artikel? Ich habe jetzt mal random geguckt: Der Entwickler von Pokémon Card Game Asobikata DS hat keinen Artikel, Niantic als GO-Entwickler hat keinen, bei einigen Spielen steht TPCi als Entwickler, wo ich mir grad ziemlich unsicher bin, ob sie wirklich selber entwickeln, bei vielen Apps ist Creatures als Entwickler eingetragen, mit Intelligent Systems hat jedoch der Entwickler von Puzzle League und Puzzle Challenge einen Artikel. Jones Albtraum? 23:54, 19. Mär. 2018 (CET)

Da sich SwowoJonny nun bereits die Mühe gemacht und eine entsprechende Infobox erstellt hat, wäre es vielleicht angebracht diese hier nochmals zu begutachten. An eine Strukturierung hat er sich zudem bereits in den Artikeln zu Chunsoft und Niantic gewagt. Insgesamt greift das viele der hier genannten Punkte von Jones auf und versucht sie umzusetzen. Dennoch habe ich das Gefühl, dass noch nicht alle Fragen in voller Gänze geklärt zu sein scheinen, z. B. welche Firmen sich für einen Artikel qualifizieren. Aus diesem Grund halte ich es für sinnvoll, an dieser Stelle nochmals durch ein Feedback an dem Konzept zu arbeiten, sodass wir diesen Punkt im Anschluss guten Gewissens abhaken können und eine Musterstruktur für alle (auch zukünftigen) Firmen-Artikel haben. ~ Taisuke Diskussion 00:11, 5. Jul. 2018 (CEST)
Alle Spiele-Firmen, welche bisher im Wiki vertreten waren, als auch Niantic, sind an sich vervollständigt. Aktuell arbeite ich noch am Artikel für Hudson Soft sowie den Artikel für Nintendo, welchen ich zu Gunsten der VBW gestalte. Jedoch haben wir noch nichts bezüglich den Firmen außerhalb der Spiele. Firmen, welche für den Anime, den Manga oder auch Merchandise oder Karten verantwortlich sind, liegen weit zurück. Mich würde es interessieren, an welchen Firmen Interesse liegt und an welchen nicht. Eure Meinungen? SwowoJonny 13:24, 4. Aug. 2018 (CEST)
Für den Anime schätzungsweise OLM, vom TCG-Bereich her wohl Wizards of the Coast, falls die damals auch in Deutschland zuständig für waren (weiss ich ehrlichgesagt gar nicht), und eventuell Amigo, ist aber imo nicht so wichtig. Aus dem Manga-Bereich hat Shōgakukan schon nen Artikel, den man mal überarbeiten sollte. Ansonsten vielleicht noch Panini? Müsste das Manga-Projekt entscheiden. --Datei:Sugimori 672.pngMecanno-manMäh 12:14, 30. Aug. 2018 (CEST)

Missionen

Hey liebe Menschen,

mir ist gerade mal wieder aufgefallen, dass wir noch diese Missionen haben, von denen die letzte vor über einem Jahr erfüllt wurde... Also wirklich genutzt wird das ja scheinbar nicht. Ich meine, da stehen noch Missionen von Isso als Itemprojektleiter drin. Hättet ihr irgendwelche Ideen, wie man das wiederbeleben könnte, oder sollten wir uns alle einen Ruck geben und einfach wieder mehr Missionen dort einstellen? Ansonsten könnte man den Kram auch einfach abhaken und archivieren. Einen Platz im Hauptmenü hat es so jedenfalls nicht verdient. Lg --Fliegen bis zum Horizont. Killuu https://i.imgur.com/4EZCZEO.png 21:02, 2. Mai 2018 (CET)

Ich würde es sehr begrüßen, wenn die Missionen wiederbelebt werden würden, da ich sie, soweit ich es beurteilen kann, für ziemlich hilfreich halte, um Autoren zu motivieren. Da jedoch weder eine Mission erfüllt noch eine neue erstellt wurde, seitdem ich mich im PokéWiki angemeldet habe, ist diese Annahme eher Spekulation. Vielleicht würde eine Ankündigung von Missionen auf Discord weiterhelfen, um einen Neuanfang zu starten, wenn die Missionen nur auf der Missionsseite stehen würde, würde es wahrscheinlich fast niemand mitbekommen. Ansonsten könnte ich beinahe garantieren, dass das Strategie-Projekt sicherlich mindestens eine Mission pro Monat stellen könnte, aufgrund der monatlichen Tier-Shifts. Luca12379 Diskussion 14:33, 4. Mai 2018 (CEST)
Ich schließe mich Luca da an, auch was den Vorschlag mit Discord betrifft. Außerdem könnte eine Wiederbelebung der Missionen vielleicht auch dazu führen Autoren auf Bereiche aufmerksam zu machen, auf welche sie auf eigene Faust vielleicht auch garnicht gekommen wären. Projekte können für den einen oder anderen vielleicht so aufmerksam gemacht werden. Die Zusammenarbeit zwischen den Autoren wird so sicherlich auch gestärkt. Also ich wäre definitiv dran interessiert. SwowoJonny 14:44, 4. Mai 2018 (CEST)
Der Wunsch der Wiederbelebung ist ja schön und gut, aber gibt es auch wirklich etwas, mit dem man das ganze füllen kann? Es gefällt mir schonmal, dass Luca was hat, aber wie ist das beim Rest? Ich persönlich wüsste spontan nichts, was ich in meinen Bereichen als Mission anbieten könnte, dass sind halt einfach überwiegend routinierte Sachen, bei denen es schwer ist, etwas als Mission darzustellen, die eben auch Anfängerfreundlich ist ka.gif -- RobbiRobb 15:09, 4. Mai 2018 (CEST)
Ich leite auch nicht gerade missionierbare Projekte. Was sagen denn so die anderen Projektleiter dazu? --Kein Dschungel zu dicht... Killuu https://i.imgur.com/acgb9YG.png 20:03, 19. Mai 2018 (CET)
Da ich das Missionsbrett nicht ganz aufgeben möchte, werde ich mal schauen, was ich machen kann. Ein Umstyling? Ein paar leichte Missionen? Vielleicht lockt das. Das Isso 08/15 Konter 12:11, 27. Jun. 2018 (CEST)
Ein Umstyling wäre vielleicht wirklich nicht schlecht emot-rolleyes.gif Auf jeden Fall irgendwas, um das ganze ansprechender zu gestalten - angefangen damit, dass man diesen letzten Abschnitt, der den meisten Leuten egal sein dürfte, mal so einstellen könnte, dass nur PLs/VBs ihn sehen können. Der normale Nutzer hat davon eh nix. Und ein paar einfache Missionen wären glaube ich auch gut, um da mal wieder Leben rein zu bringen, denn um es abzuschaffen wäre es mir auch zu schade, schließlich hätten wir dann abgesehen von Projekthelden und Rängen nahezu keine Auszeichnungen mehr und nahezu nichts, womit man einfach mal Nutzer auszeichnen kann, die nicht unbedingt an einem Projekt mitwirken oder insgesamt nicht so aktiv sind, aber bei einer bestimmten Sache aushelfen. Trotzdem finde ich es schwierig, da irgendwas zu finden, was man gut als einfache Mission nehmen kann, ich habe schon lange die Item-Beschriebungen im Kopf, aber irgendwie finde ich sowas zu einfach, schließlich ist das vermutlich sogar mit einem Bot machbar... -- RobbiRobb 12:20, 27. Jun. 2018 (CEST)
Ich habe jetzt auch nochmal ein paar Missionen eingestellt. Und auch direkt mal auf Discord in dem entsprechenden Projekt darauf aufmerksam gemacht. Vielleicht müssten wir uns das angewöhnen, auf den Projektseiten und Discord die Missionen dann auch anzugeben. Würde sich eventuell auch in Discordchannel dafür lohnen? Ohne Schreibrechte vielleicht, sodass da nur die aktuellen Missionen gepusht werden? Lg --Und dann im Mondschein... Killuu 18:13, 8. Jul. 2018 (CET)
Grüß euch. Ist aus der Wiederbelebungs-Aktion der Missionen jetzt eigentlich etwas geworden? Der Ansatz, eine Person für solche Missionsabschlüsse (die jetzt ja vom Niveau her sehr unterschiedlich sind) zu belohnen ist ja irgendwie ganz nett, aber wie ich finde auch irgendwo nicht zielführend. Wir haben etliche Auszeichnungen, die theoretisch Motivation geben können, praktisch sind sie aber eigentlich egal und nur zur Profilierung gedacht. Wofür denn noch Missionen, wenn wir (äußerst) wertvolle Benutzer, Projekthelden (sogar mit drei Abstufungen!), Edit-Auszeichnungen, die in Vergessenheit geratene Auszeichnung der "Helfenden Hand", die Verbesserungswochen und (wenn man das überhaupt als Auszeichnung sehen kann) die Stimmberechtigung, die Rechte der verlässlichen User sowie die Redakteurs-Rechte haben? Damit sind es eigentlich sehr viele Möglichkeiten, mit denen man den Usern ihre Anerkennung und ihren neu angetriebenen Ansporn geben kann. Diese Missionen wurden ja auch nicht besonders beworben (so kam es mir zumindest vor, korrigiert mich, wenn das falsch ist), und haben deshalb nur mediokren Anklang gefunden. Und zu deinem Punkt, Robbi: Einfache Missionen sind natürlich gut, um vielleicht Leute zu beschaffen, die sonst eher nur gelegentlich mal ins Wiki reinschauen. Aber solche Massenedits, die Bots genauso machen können, müssen wir da nicht unbedingt verteilen. Ließe sich nur irgendwas nettes finden, wofür man nicht unbedingt besonders lange Zeit investieren muss, wäre das Ganze ja schön. Dann ließe sich auch feststellen, ob das Missionsbrett wirklich als Motivation taugt. Denn ich glaube nicht, dass Leute dazu geneigt sind, Missionen zu erfüllen, wenn die Hälfte davon nur nach dem Schema "Erstelle ein XdW zu [...]" ist. Ein XdW kostet nun mal Zeit und muss auch mehrmals korrigiert werden, bevor es auf der Hauptseite vorgestellt werden kann. Fazit: Wenn wir leichte Aufgaben finden, kann man das ja mal als Missionen eintragen und schauen, wie sich das mit den Missionen weiterentwickelt. Ansonsten sehe ich da nicht viel Hoffnung und würde eher eine komplette Archivierung befürworten. Mit liebstem Grüß, --Gala 172.png 06:53, 27. Aug. 2018 (CEST)
Ich meine der einzige Grund warum es das überhaupt noch gibt ist weil shadow mit der PokéWiki:To-do-Liste nicht einverstanden war; wir wollten es abschaffen sobald wir die fertig hatten, das ist aber irgendwie im Sand verlaufen. --Datei:Sugimori 672.pngMecanno-manMäh 23:17, 29. Aug. 2018 (CEST)
Das Thema wurde gestern auf dem Chattreffen besprochen, dessen Zusammenfassung hier nachgelesen werden kann. Das Missionsbrett soll demnach weiterhin bestehen und für einzelne kleine bis größere Bearbeitungen genutzt werden soll (also keine Massenedits). Alle Projektleiter (und gerne auch andere User ab der Stufe Verlässlicher Benutzer) sind angehalten, zu überlegen/prüfen, ob sie hierfür Aufgaben einstellen können. Also selber einfach ein bisschen hinterklemmen. Sollte das nicht laufen, kann man ja immer noch über eine Entfernung nachdenken. Lg --Klein, aber fein. Killuu 15:11, 22. Okt. 2018 (CET)

Neues Design für Komplettlösungen

Während des eben beendeten Chattreffens wurde mehr oder weniger beschlossen, dass die Komplettlösungen in naher Zukunft gemäß eines solchen Vorschlags umstrukturiert werden. Da das Design vielfach auf Anklang stieß und vor allem die ewig andauernde Problematik mit den unvollständigen und falschen Komplettlösungen damit aus der Welt geschaffen würde, möchte ich dieses Design zeitnah umsetzen. Um hier aber allen, auch denen, die nicht am Chattreffen teilnehmen konnten, die Möglichkeit zu geben, sich dazu zu äußern, besteht jetzt die Möglichkeit, bis Sonntag den 04.11.2018 um 23:59:59 sich dagegen auszusprechen oder Verbesserungsvorschläge einzubringen, bevor das ganze dann umgesetzt wird. -- RobbiRobb 22:15, 21. Okt. 2018 (CEST)

Ein Vorschlag: Wäre es nicht sinnvoll, mithilfe von Toggles optional die Möglichkeit zu geben, einen Fließtext zu bestimmten Unterpunkten ausklappen lassen zu können? Auf diese Weise könnten bei Bedarf genauere Informationen zum Spielverlauf eingefügt werden (also in Richtung der "klassischen" Komplettlösungen), ohne dass die neue Übersichtlichkeit verloren ginge.
Am Beispiel "Lili’i":
Unausgeklappt:
  • Kampf gegen Rivalen
Ausgeklappt:
  • Kampf gegen Rivalen
"Ihr begegnet Tali zunächst an Ort xy. Dort fordert er euch nach Erhalt des ersten Pokémon zu einem Kampf heraus. Tali besitzt dabei jeweils das Pokémon, welches eurem unterlegen ist. Hierbei solltet ihr beachten, dass [...] Eine gute Strategie ist [...] Als Belohnung erhaltet ihr [...]"
Allein mit Stichpunkten geht das Wesen einer Komplettlösung in meinen Augen ein wenig verloren. ~ TiMauziDatei:Pokémonsprite 052 Fuß.png 00:07, 22. Okt. 2018 (CEST)
Möglich wäre das schon, aber dann stehen wir wieder vor dem klassischen Problem: Wer will die Texte schreiben? Wenn du dich dazu bereits erklärst, das für alle Komplettlösungen zu machen, können wir diese Idee gerne weiter verfolgen, andernfalls sehe ich aktuell keine Chance, dass das in den nächsten 20 Jahren erledigt wird. Bisher hat sich schließlich auch niemand dazu bereit erklärt, die aktuellen Komplettlösungen zu überarbeiten, wäre dies geschehen, hätten wir überhaupt nichts am System ändern müssen. Ich werde jedoch definitiv keine solche Texte schreiben. Oh und btw, das "du" oder "ihr" will ich da auf keinen Fall sehen, wir sind ein Wiki msnsorry.gif -- RobbiRobb 01:17, 22. Okt. 2018 (CEST)
Daher spreche ich von optional. Also standardmäßig nur Stichpunkte, bei gegebenen Anlässen gern mit Fließtextergänzung (wichtige Storyelemente bspw.). Und mit dem "du" stimme ich dir voll und ganz zu, das stört mich selbst immer, war halt bei den Komplettlösungen bisher so üblich, daher habe ich das im Beispiel übernommen. ~ TiMauziDatei:Pokémonsprite 052 Fuß.png 01:38, 22. Okt. 2018 (CEST)
Einzig was man noch schauen müsste ist ob es alternativen zum Whitespace gäbe. Aber ansonsten befürworte ich die Änderung. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 12:41, 22. Okt. 2018 (CEST)
Kannst du genauer erläutern, was du mit "Whitespace" genau meinst? ~ TiMauziDatei:Pokémonsprite 052 Fuß.png 14:50, 22. Okt. 2018 (CEST)
@TiMauzi, weis jetzt nicht so recht was ich da erklären sollte. Halt die weiße Fläche an der rechten Seite siehe Testwiki Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 14:55, 22. Okt. 2018 (CEST)
Buo hat hierzu was auf Discord geschrieben, was auch meine Meinung widerspiegelt. Ich zitiere ihn einfach mal "Die Idee mit den Flowcharts finde ich ganz gut, so wird es teilweise ja auch in den offiziellen Guides dargestellt – mit Seitenzahlen für die Detailseiten. Dann wäre es auch übersichtlicher und man würde als User die gesuchten Informationen schnell erhalten. Denn irre viel Text mag heutzutage bei Komplettlösungen glaub ich kaum noch jemand lesen. Man sollte bei uns aber trotzdem darauf achten, dass jedes Rätsel/Puzzle im Spiel dann aufgelistet und in den verlinkten Artikeln auch mit Lösung vorhanden ist. *thumbsup-Emoticon*" Gerade natürlich der letzte Satz ist wichtig, dass die verlinkten Artikel vor der Umstellung natürlich alle relevanten Aspekte aufgreifen. Ich finde auch TiMauzis Vorschlag nicht schlecht, würde aber eventuell da nur Stichpunkte schreiben. Also bei einem Kampf nochmal grob das Team angeben (z.B. nur Pokémon mit Level) oder andere wichtige Sachen à la "wird durch Erhalt von xy freigeschaltet" oder sowas. Ich hoffe, ihr versteht, was ich meine. Halt nochmal in Superkurzform das Allerallerwichtigste. Auch wie Ryu finde ich den Whitespace nicht so wirklich hübsch. Ich frage mich, ob man hier kleine Bildchen der Orte einfügen könnte oder halt vielleicht die von Berdl vorgeschlagenen Zusammenfassungen. Lg --Klein, aber fein. Killuu 15:03, 22. Okt. 2018 (CET)
Je länger ich darüber nachdenke, desto schlechter gefällt mir irgendwie die Idee mit den Fließtexten dadrin. Schließlich sollen ja direkt bei dem Link Fließtexte, die die Handlungen an diesem Ort zusammenfassen, stehen, die Vorlage verlinkt ja schon automatisch auf den Abschnitt. Jetzt also nochmal zusätzliche Texte verfassen, für die wir wahrscheinlich keine Ressourcen aufbringen können, finde ich geht irgendwie wieder weg von dem eigentlichen Flowchart, dann kann man nämlich, speziell Texte wie im Beispiel, bei so ziemlich jedem der Punkte listen.
Im Bezug auf die Bilder kann ich im Moment nur sagen, dass es sich technisch wahrscheinlich nicht realiseren lässt, da die ganze Seite eine einzige Tabelle ist, Bilder rutschen unterhalb der Box und zerstören damit den "Fluss" des ganzen, ich fürchte da müssen wir uns also was anderes einfallen lassen... -- RobbiRobb 17:12, 22. Okt. 2018 (CEST)
Fliesstexte und Teams finde ich da jetzt ehrlichgesagt auch nicht so toll, da sich das dann wieder mit den Artikeln doppelt. Ich hätte dafür gerne etwas mehr Stichpunkte, damit das nicht so leer wirkt (à la „Durchquer das Erzelingen-Tor“) - auch wenn das keinen wirklich brauchbaren Inhalt vermittelt, sowie Tipps, z. B. für nützliche Items (iwie TM Donnerblitz oder so), oder besondere Sachen auf die man in Kämpfen aufpassen sollte (Achtung, Garados kann Erdbeben!), die Tipps womöglich per Toggle ausklappbar (wobei man da aufpassen sollte nur einen Toggler aufzuklappen und nicht alle... ) --Datei:Sugimori 672.pngMecanno-manMäh 19:58, 22. Okt. 2018 (CEST)
Im wesentlichen +1, ich finde aber nicht wirklich, dass nicht storybezogene Punkte (Kämpfe, Fundorte) da was zu suchen haben. -- Skelabra2509 (Diskussion | Beiträge) 02:18, 23. Okt. 2018 (CEST)
Hey, ich melde mich mal auch zu Wort. Ich denke ebenfalls wie Ryu, dass der Whitespace igrendwie gefüllt werden sollte (also nicht mit sinnlosen Bilder, die ja, wie Robbi schon sagte, unter die Tabelle rutschen), da er den Artikel, Weiterleitung, was auch immer, leer wirken lässt. Vielleicht reicht ja auch schon ne Zentrierung in die Mitte. Die Fließtexte würde ich tatsächlich auch raus lassen (siehe genannte Gründe oben). Ich denke das die Stichpunkte reichen würden, da sie nur einem einen kleinen Überblick verschaffen sollen. Aber ich bin auf jeden Fall für Flowcharts. ~ noch ein schönen Tag ^^ ~ DarkViper Datei:Sugimori 448m1.png 19:58, 23. Okt. 2018 (CEST)
Ich hab nix dagegen einzuwenden, solange das Wesentliche zu finden ist. Z.B. "Du benötigst die Schiggykanne, um gegen Mogelbaum zu kämpfen." (Ich weiß noch, wie ich die lange gesucht habe.) oder "Zum nächsten Ort kannst du erst, wenn du das und dies getan hast." Das fände ich noch hilfreich, natürlich kurz gefasst. Details kann man immer noch nachschauen (Wo ist diese Kanne...). Gegen den Whitespace habe ich keine wirklich ansprechende Idee, evtl. statt eine weitere Verzweigung nach rechts eine nach unten machen; oder evtl. Lösungsbilder von Labyrinthen statt in den Artikeln in die KL. Nur wenn man das als sinnvoll erachtet. ka.gif Das Isso 08/15 Konter 20:17, 4. Nov. 2018 (CET)

Da es hier im Grunde keine Gegenstimmen gab sondern nur einzelne Wünsche nach Erweiterungen, die man am besten in Fallentscheidungen klären kann, würde ich sagen, dass wir das ganze erstmal so beschließen. Da die Umsetzung jedoch vom Orte-Projekt abhängt, da diese die verlinkten Handlungen verfassen, ist es aktuell leider unmöglich, direkt alle Komplettlösungen zu erneuern, ich denke allerdings, dass dies mit der Zeit möglich sein wird. Zunächst werden wir einfach die umsetzen, bei denen die Handlungen bereits existieren - also SoMo und USUM in Alola - und dann mit der Zeit weitere Seiten erneuern. -- RobbiRobb 20:23, 5. Nov. 2018 (CET)

Mit meinen Stichpunkten meinte ich genau das, was jetzt Isso beschrieben hat. Danke fürs besser beschreiben. Sowas finde ich halt doch extrem wichtig. Lg --Fliegen bis zum Horizont. Killuu 15:32, 7. Nov. 2018 (CET)

Optionales nach der Liga

Ich möchte an dieser Stelle gerne nochmal etwas weiter gehen und das Design der Handlung nach der Hauptstory klären. Dass wir natürlich nichts außen vor lassen wollen, was für die Geschehnisse relevant ist, dürfte klar sein. Bleibt allerdings die Frage, wie wir es angeben wollen. Meine Idee wäre spontan einfach eine Überschrift zu setzen, die Hauptstory und Nebenhandlung voneinander trennt und dann einfach das Flowchart fortführt. Ansonsten müsste ich mir was einfallen lassen, wie man alles optionale nach der Liga optional an die Liga anhängt und da habe ich ehrlich gesagt nicht so unglaublich viel Lust drauf. Abgesehen davon würde mich interessieren, wie ihr dazu steht, bei den Orten anzugeben, dass dort ein Legendäres Pokémon zu fangen ist. Sollten wir das immer machen? Das dürfte die Leser neben der Handlung noch am ehesten interessieren, oder? -- RobbiRobb 22:07, 5. Dez. 2018 (CET)

Gestaltung der Stellenanzeigen/Ausschreibungen

vorrausgegangene Abstimmung

Hallo!
Vor Kurzem ergab die Abstimmung über die Einführung von Stellenanzeigen bzw. Ausschreibungen auf unserer Hauptseite, dass tatsächlich ein Bedarf für solche da zu sein scheint. Deshalb soll es in dieser Diskussionsrunde darum gehen, wie eine solche Box denn ganz konkret gestaltet und ausgeführt werden soll.
Die zu klärenden Fragen sind:

  1. Wie sieht das Layout der Box aus?
  2. Welche Hauptseiten-Position hat die Box?
  3. Wer darf die Vorlage, die zur Box gehört, bearbeiten?
  4. Was darf/muss alles in die Box?

Als Diskussionsbasis möchte ich hier nochmals meine beiden Beispiele einer möglichen Gestaltung anführen: Link zu den Beispielen
Die Antworten meiner Beispiele auf die oberen Fragen sind:

  1. Entwurf 1: Vertikal schmal; horizontal die Seitenbreite ausnutzend // Randfärbung hellrot, im Überschriftenteil mit Gradient // Überschrift: "Gesucht!" am linken Rand; am rechten Rand Links zu Missionsbrett und globaler To-do-Liste // Im Textfeld kursive, gereihte Kurzausschreibungen mit Projektlinks; ganz rechts Großlinse (als visuell-ansprechendes Element)
    Entwurf 2: Vertikal höher; horizontal einer gegenüberliegenden Box angepasst // Randfärbung blau, im Überschriftenteil mit Gradient // Überschrift "Ausschreibungen:" // Im Textfeld rote Überschrift "Gesucht!"; aufgelistete Kurzausschreibungen mit Projektlinks; unten abgesetzt Links zu Missionsbrett und globaler To-do-Liste; rechts ORAS-Ruinenmaniac-Artwork (als visuell-ansprechendes Element)
  2. Entwurf 1: unter "Willkommen im PokéWiki!" oder über "Aktuelles"
    Entwurf 2:Kein Plan drop.gif
  3. Die Vorlage soll ab dem VB-Rang bearbeitbar sein.
  4. Kurzbeschreibungen in Stichpunktform von gesuchten Positionen oder Funktionen. Es soll auch Mitgliederengpässen oder offene Aufgaben in den jew. Projekten aufmerksam gemacht werden, die von Neumitgliedern relativ leicht ausgefüllt/erfüllt werden können.


Nicht nur schriftliche Vorschläge und Einwände, sondern vor allem auch bildlich anschaubare Entwürfe (Testseiten-/Screenshot-Links) sind sehr erwünscht!
-MfG, Kenaz-Hagalaz Disku 18:10, 26. Mär. 2019 (CET)

Ich habe Entwurf 1 von Kenaz ein wenig abgewandelt und hier mal in einer "Testumgebung" dargestellt. Da ich noch unschlüssig bei der Farbe des unteren Teils und dem Standort bin, habe ich ein paar toggler eingebaut, dann könnt ihr, wenn ihr wollt euch das anschauen und beurteilen^^. Meine Antworten auf die Fragen:
  1. Wie Kenaz' erster Entwurf. Meine Änderungen: der untere Teil ist eine Tabelle um bessere Trenner zu ermöglichen und die Großlinse ist im oberen Teil.
  2. Wie bei Kenaz. Die Stellenanzeigen sollten meiner Meinung nach gut sichtbar sein und neben der dominanten Farbe, halte ich es für wichtig, dass man, am PC die Anzeigen ohne runter zu scrollen sehen kann.
  3. Erneut wie Kenaz^^. Auf der Hauptseite und auffällig --> mindestens ab VB.
  4. Wie Kenaz. Zusätzlich bin ich zur Zeit am überlegen wie man so etwas wie {{Tt}} auch "Smartphone-Nutzer-freundlich" umsetzen kann, um bei Bedarf zu den einzelnen Stichpunkten eine Erklärung abgeben zu können, da die angebenen Punkte sich hauptsächlich (klärt mich auf sollte ich die Haupt-Zielgruppe falsch verstanden haben) an neue Nutzer (und an zukünftige Nutzer) richten und einen relativ einfachen Schwierigkeitsgrad haben sollen. Außerdem könnte man damit ermöglichen auch mal ein bisschen anspruchsvollere Aufgaben mit ausreichender Erklärung zu stellen. --DeXter 21:54, 27. Mär. 2019 (CET)
  1. Mir gefällt da jetzt spontan die generelle Richtung von Entwurf 2 besser; finde allerdings dass da zu viel Farbe hervorsticht, hätte mir da einen wesentlich kleineren Rahmen, wenn überhaupt, vorgestellt (das ihr hier schon viel zu früh Farbe in die Diskussion werft, sei mal dahingestellt - so wird sich jetzt nämlich die Hälfte gegen dieses Orange und nicht gegen das Design aussprechen). Oh und um himmels willen, kein tt auf der Hauptseite - ist schon schlimm genug das wir das noch in Artikeln nutzen. Zeitgemäss ist das einfach nicht mehr.
  2. Spontaner Vorschlag - und müsste definitiv noch von Killuu und Isso genehmigt werden: über das schon gewusst und dafür das Zeichenlimit von AdW/PdW erhöhen, damit da kein Leerraum entsteht. Haben wir Kapazität dafür aus dem XdW-Bereich? Ich meine mich nämlich erinnern können das früher sich immer darüber beklagt wurde dass die Zeichenlimite da zu kurz sei.
  3. Es is sinnlos es PLs zu verbieten und SB und alles drunter traue ich dieses Recht nicht zu - ist immerhin die Hauptseite. Folglich Entweder VB+ oder PL+ - was genau hängt vor allem von der Umsetzung von Punkt 4 ab.
  4. ..doppelt sich entweder mit der To Do oder mit dem Missionsbrett, so wie die Diskussion läuft eher mit der To Do. Da deren Darstellung allerdings meine Idee war, sie nicht so wirklich funktioniert hat und ich nicht weiss, wie man sie verbessert, halte ich mich hier glaub besser raus. --Datei:Sugimori 672.pngMecanno-manMäh 18:35, 29. Apr. 2019 (CEST)
Zu dem Thema kann ich eigentlich nicht viel sagen, da ich erstens kein Fan dieser "Stellenausschreibungen" bin (soll jetzt keine weitere Debatte anstoßen, ich akzeptiere die Entscheidung) und zweitens ein furchtbares Gefühl für Design habe. Nur eine Bitte meinerseits: benutzt wenn möglich keine zu grellen roten und ins rote gehende Farben. Das beißt sich furchtbar mit dem Blau, das wir hier hauptsächlich verwenden. Fällt zwar sofort auf, lenkt aber auch vom Rest ab und ist zumindest für mich fast schon unangenehm anzusehen :x -- Datei:Pokémonsprite 359 Pinball2.png Korvel1 Diskussion 10:10, 4. Mai 2019 (CEST)
Ich habe das Design meiner Vorschläge ein wenig geändert (auch etwas mehr nach dem Stil der anderen Boxen auf der Hauptseite). Hoffe, dass das Aussehen euch eher zusagt^^. --DeXter 18:54, 4. Mai 2019 (CEST)
Ich finde Entwurf zwei eigentlich schicker. So schmale Boxen gefallen mir meistens nicht so. Zu Mecs Einwurf: Ja, wir haben teilweise XdWs die gerne eine höhere Zeichenzahl hätten, manchmal krebst man da aber auch am unteren Ende rum. Wenn man aber die XdW-Bix vielleicht etwas quetscht, wird sie auch länger? Wobei man dann schauen müsste, ob das noch schön proportioniert ausschaut. Lg --Und dann im Mondschein... Killuu 22:23, 5. Mai 2019 (CET)

Überarbeitung der Darstellung der Statuswerte

Ich habe mir gedacht, dass man die Statuswerte-Infobox, die in jedem Pokémon-Artikel enthalten ist, mit etwas sinnvolleren Informationen füllen könnte.

Die Basiswerte müssen dort natürlich unbedingt stehen, die Fleißpunkte (die man für das Besiegen des Pokémon bekommt) passen auch gut an diese Stelle, über den Rest kann man aber diskutieren. Meiner Meinung nach können die meisten der anderen Informationen so belassen werden, wie sie aktuell sind: Die Unterteilung in Level 50 und Level 100 ist sinnvoll, da beide im kompetitiven Spiel häufig genutzt werden, und sowohl die Angabe der Maximalwerte bei neutralem als auch die Angabe bei positivem Wesen kann hilfreich sein (wobei man überlegen könnte, einen der beiden Werte zu streichen, da man sich zumindest vom neutralen zum positiven Wesen den Wert sogar im Kopf ausrechnen kann).

Die Angabe der Maximalwerte bei negativem Wesen hilft aber so gut wie niemandem. Für kompetitiv spielende Trainer sind diese Werte uninteressant, da es praktisch nie sinnvoll ist, 252 Fleißpunkte in einen Wert mit negativem Wesen zu stecken, und gewöhnliche Trainer können diese Werte auch nicht gebrauchen, da sie wahrscheinlich nicht zufällig 31 DV auf diesem Wert haben und erst recht kein gezieltes Fleißpunkte-Training durchführen, um 252 Fleißpunkte auf dem Wert zu erreichen.

Stattdessen schlage ich vor, hier die Minimalwerte anzugeben, also die Werte, die bei 0 DV und 0 FP erreicht werden. Das wäre insbesondere beim Initiative-Wert für kompetitive Spieler interessant, aber auch für andere, da man so den gesamten Bereich sieht, in dem sich ein Wert befinden kann. Man kann auch mit den Werten seiner eigenen Pokémon vergleichen, um zu sehen, ob sich der Wert eher im oberen oder im unteren Teil des Bereichs befindet. Außerdem sieht man so direkt, in welchem Ausmaß FP-Training und maximale DV Werte steigern können.

Hier gibt es dann noch zwei Möglichkeiten, man könnte die Minimalwerte entweder bei negativem oder neutralen Wesen angeben. Der Vorteil bei negativem Wesen ist, dass man das wirkliche Minimum hat, ich halte aber die Angabe bei neutralem Wesen für besser, da die Umrechnung von neutralem zu negativem Wesen einfacher und immer eindeutig ist. (Im Gegensatz zur Umrechnung von negativem zu positivem Wesen, z.B. wird ein Wert, der bei neutralem Wesen 110 ist, bei negativem Wesen zu 110 * 0,9 = 99. Ist der Wert bei neutralem Wesen aber 111, kommt bei der Rechnung 111 * 0,9 = 99,9 raus, was ebenfalls zu 99 abgerundet wird.)

(Eine weitere Idee, die ich hatte, war die Angabe von tatsächlichen durchschnittlichen Werten, die mit 15 oder 16 DV, 85 FP und neutralem Wesen erreicht werden. Das wäre vielleicht interessant für Spieler, die sich überhaupt keine Gedanken über DV, FP und Wesen machen wollen, aber trotzdem wissen wollen, welche Werte sie von einem Pokémon ungefähr auf Level 50 bzw. 100 erwarten können. Diese Werte anzugeben, wäre aber meiner Meinung nach aber nur dann sinnvoll, wenn man sich dazu entscheidet, die Maximalwerte bei neutralem oder positivem Wesen zu streichen oder einen vierten Werteblock einzufügen, die Minimalwerte stufe ich jedenfalls als wichtiger ein.)

Also, um das Ganze kurzzufassen: In der Statuswerte-Infobox sollten die wenig sinnvollen Maximalwerte bei negativem Wesen durch die nützlicheren Minimalwerte bei neutralem oder negativem Wesen ersetzt werden. --Lasagne (Diskussion) 17:06, 25. Apr. 2019 (CEST)

Hi Lasagne! Die Darstellung dort ist nun schon soo lange da, dass ich sie noch nie hinterfragt habe... danke für die Anregung! Meine Meinung dazu ist, dass die Spezialwerte wie Maximal- oder Minimalwerte eigentlich in den Spezies-Artikeln nur wenig verloren haben. Wir haben schließlich auch Strategie-Artikel für die Pokémon, und selbst da hat sich das zuständige Projekt dafür entschieden, nur Basiswerte aufzuführen, wie es auch namhafte Strategieseiten wie Smogon machen. Statuswerte-Rechner gibt es an anderer Stelle bessere, und wenn wir sowas brauchen, dann ist es auf der Strategie-Seite oder auf einer eigenen Listenseite sinnvoller für die Leute, die sich für Competitive Play interessieren. Mein Gefühl ist aber, dass eine Liste einen Rechner niemals sinnvoll in der Darstellung ersetzen kann. Mein Plädoyer wäre also eher, alles bis auf die Basiswerte und Fleißpunkte aus den Spezies-Artikeln herauszunehmen. Welche Sonderwerte man sinnvoll braucht, kann ich aus deiner Argumentation nachvollziehen, aber hab dazu keine Meinung, weil ich mich mit Competitive Play nie beschäftigt habe. Mein Eindruck ist, selbst die Strategieler haben sich bei den Strategieseiten dagegen entschieden. Viele Grüße! Pokémon-Icon_674.png Maxmiran 11:45, 17. Mai 2019 (CEST)
Nach etwas weiterführendem Brainstorming auf Discord kam die Idee auf, einen auf alle Bedürfnisse zugeschneiderten interaktiven Rechner bereitzustellen, mit dem jeder bei Angabe des Pokémon, der DV, FP und Level sowie Wesen spezifisch für sein Pokémon die maximalen Werte ausrechnen kann. Da Buo dem gegenüber nicht abgeneigt ist, wäre dies also eine Möglichkeit, die Inhalte der Pokémon-Artikel auf ein Minimum zu reduzieren und dennoch den Besuchern keinen der Werte vorzuenthalten. Inwieweit das jetzt besser oder schlechter als die eingangs von Lasagne vorgeschlagenen Werte sind, müsste allerdings jemand beurteilen, der sich mehr mit sowas auseinandergesetzt hat als ich. -- RobbiRobb 14:47, 17. Mai 2019 (CEST)
Wenn ein direkt in die Pokémon-Artikel eingebetteter interaktiver Statuswerte-Rechner möglich ist, wäre das natürlich großartig und wohl die beste Lösung. Man könnte dann z.B. die Maximalwerte auf Level 100 (31 DV und 252 FP auf jedem Wert, neutrales oder positives Wesen) voreingestellt machen (ich weiß, aufgrund der FP ist ein Pokémon, das all diese Werte hat, nicht möglich, aber das halte ich nicht für problematisch). Außerdem wäre es sehr hilfreich, wenn es zwei Knöpfe gibt, mit denen man sofort alle FP und DV maximieren bzw. minimieren kann, da man sich damit mit nur einem Klick bis zu zwölf Eingaben spart.
Ich würde mich über diese Funktion auf jeden Fall sehr freuen und hoffe, dass die Umsetzung nicht zu viel Arbeit macht. Falls es aber doch zu viele Schwierigkeiten gibt und man bei einer statischen Darstellung bleiben möchte, sollte man meiner Meinung nach nicht nur die Basiswerte anzeigen, wie Maxmiran es vorgeschlagen hat.
Einerseits schadet es nicht, etwas mehr Informationen darzustellen, und die Statuswerte-Infobox wirkt meiner Meinung nach auch noch nicht zu überladen (wenn alle tatsächlichen Werte einfach gestrichen würden, sähe es mir sogar etwas zu karg aus).
Andererseits ist es aber auch so, dass Pokémon-Spieler, die sich nicht mit der Berechnung der Statuswerte auseinandergesetzt haben, mit den Basiswerten alleine nicht besonders viel anfangen können. In den Pokémon-Spielen selbst werden diese Basiswerte nie wirklich behandelt, es werden immer nur die tatsächlichen Werte angezeigt, deshalb sollte meiner Meinung nach auch im PokéWiki weiterhin in irgendeiner Form gezeigt werden, was die Basiswerte für die tatsächlichen Werte bedeuten. Es ist so ähnlich wie bei der Fangrate, wo man kaum was mit dem spielintern verwendeten Wert anfangen kann, ohne sich mit der Formel auseinanderzusetzen, die tatsächliche Chance hilft da oft schon eher.
Und auch für kompetitiv spielende Trainer können die tatsächlichen Werte oft interessant sein, auch wenn man diese auch auf einigen anderen Seiten nachrechnen kann. Auf diesen Seiten findet man dafür nämlich oft andere Informationen nicht, die man vielleicht braucht, z.B. wo man ein Pokémon bekommen kann oder welche Eltern man für bestimmte Zucht-Attacken braucht. Alle wichtigen Informationen auf derselben Seite zu bekommen, ist da schon recht hilfreich. --Lasagne (Diskussion) 20:07, 18. Mai 2019 (CEST)
Ich kann alle vorgeschlagenen Änderungen gut nachvollziehen und befürworte die. Ich sehe aber nachwievor nicht, wieso die berechneten Statuswerte in den Spezies-Artikeln besser aufgehoben sein sollten als in den Strategie-Artikeln, was ist dafür ein Argument? (Außer, dass es vielleicht noch nicht alle gibt, aber das ist schnell gezaubert) Pokémon-Icon_674.png Maxmiran 16:12, 19. Mai 2019 (CEST)
Das ist vielleicht eher eine Geschmacksfrage, meiner Meinung nach gehören die Statuswerte, auch die tatsächlichen, aber eher in die allgemeinen Pokémon-Artikel. Ein paar Gründe dafür:
- Die Strategie-Artikel enthalten bereits die tatsächlichen Statuswerte für die dort vorgestellten Sets, das ist meiner Meinung nach ausreichend.
- Die Strategie-Artikel sind meiner Auffassung nach eher dafür da, die Eigenschaften eines Pokémon zu bewerten, allgemeine Verwendungstipps zu geben und konkrete Spielweisen vorzustellen. Sie sind aber nicht dazu da, Spieldaten zu vermitteln, die so nicht im Pokémon-Artikel selbst stehen. Kurzgesagt: Der Pokémon-Artikel enthält die Daten (und viele weitere Informationen), der Strategie-Artikel die Interpretation dieser Daten.
- Jemand, der kein Pokémon-Profi ist und mit Basiswerten nichts anfangen kann, wird sich wahrscheinlich nicht zum Strategie-Artikel durchklicken, um die tatsächlichen Werte eines Pokémon zu prüfen. Einerseits, weil er sie vermutlich nicht dort erwartet, und andererseits, weil er das Pokémon vielleicht gar nicht strategisch-kompetitiv spielen möchte, sondern einfach nur wissen will, wie stark das Pokémon auf welchen Werten ist. --Lasagne (Diskussion) 22:25, 20. Mai 2019 (CEST)
Das Argument mit den Daten im Pokédex und der Deutung bei der Strategie sehe ich auch so und kann ich gut nachvollziehen. Danke für die Klärung! Ich würde es selbst am besten finden, dann die Spanne des Wertes anzugeben vom Minimal zum Maximalwert, aber ohne die Einflussfaktoren weiter aufzuschlüsseln. Einmal den Wert mit 0 DV, negativem Wesen und 0 FP und einmal das Gegenteil. Das Einordnen auf der Skala stelle ich mir auch für Laien interessant vor, wie du es vorgeschlagen hast. Alle anderen Fälle sehe ich aber dann bei nem Rechner, neutrales Wesen etc. Pokémon-Icon_674.png Maxmiran 07:48, 21. Mai 2019 (CEST)
Ich misch auch mal kurz mit :) Einerseits sagst du „Die Angabe der Maximalwerte bei negativem Wesen hilft aber so gut wie niemandem. Für kompetitiv spielende Trainer sind diese Werte uninteressant“, dann allerdings sagst du, dass sich nicht CP-Spieler garnicht erst zum Strategie-Artikel durcharbeiten. Und eben deswegen sollten die maximalen Werte bei negativem Wesen eben doch bestehen bleiben. Denn: ein nicht CP-Spieler fängt sich einfach ein Pokémon egal welchen Wesens und möchte aber dann vielleichgt trotzdem noch das beste damit rausholen. Also sind eben auch diese Werte für die Casual-Gamer sehr interessant und sollten keineswegs einfach ersetzt werden. Und wie du schon sagst: die, die es wissen und damit eben competitiv agieren wollen wissen entweder, was sie tun, oder suchen nach strategien und landen dann ohnehin auf den Strategie-Artikeln, wo eben bereits die Angaben zur besten Verteilung vorhanden sind. Ich sehe also in der jetzigen Aufmachung tatsächlich kein Probelm, spreche mich aber auch sehr gerne für einen Rechner aus, der sollte aber eine eigene Seite bekommen und legidlich verlinkt werden, das würde sonst Artikel einfach datentechnisch vermutlich sprengen. -- Grüße ShortyBuzz 11:14, 21. Mai 2019 (CEST)

Ich glaub es muss generell noch beschlossen werden wo man so einen Rechner hinplazieren sollte; entweder man bindet ihn in Artikel ein, oder man setzt ihn auf eine Spezialseite. Ich bin definitiv für ersteres, da bisher die Infos die wir bereits haben auch in diesen Artikeln stehen; gerne kann man aber auch noch zusätzlich eine Spezialseite anbieten, diese sollte den Rechner in den Artikeln aber nicht ersetzen. Was das Ladezeitproblem angeht wäre ich dafür das man den Rechner erst einfügt wenn die Attacken mal vernünftig gemacht sind (entweder shadow macht die neue Vorlage fertig oder wir lagern aus, aber eins muss da bald mal geschehen...) --Datei:Sugimori 672.pngMecanno-manMäh 17:09, 21. Mai 2019 (CEST)

Um mal etwas handfestes in diese Diskussion zu bringen, habe ich den gestrigen Abend damit verbracht, einen Prototypen für eine mögliche, in die Pokémon-Artikel integrierte, dynamische Darstellung der Statuswerte programmiert. Damit sich alle mit Interesse ein Bild davon machen können, ist dieser hier einsehbar (Achtung: Externe Seite, die nicht mit dem Wiki in Verbindung steht). Mir ist bewusst, dass wir uns mit dem Rechner von der ursprünglichen Idee, andere und eventuell besser gewählte Statuswerte anzubieten, entfernen, aber ich glaube, dass die zusätzliche Flexibilität durchaus ansprechend sein könnte. Es sei übrigens gesagt, dass es sich bei diesem Prototypen um ein Beispiel für eine integrierte Darstellung handelt, das Design entspricht also weitestgehend dem aktuellen Design der Statuswerte-Vorlage in unseren Artikeln. Abgesehen von einer kleineren technischen Herausforderung ließe sich das also entsprechend in die aktuelle Vorlage einbauen. Sollte der Wunsch bestehen, eine eigene Spezialseite für diesen Rechner anzubieten, müsste der Code noch um die Auswahl eines Pokémon in Verbindung mit einer Sammlung der Statuswerte verbunden werden, diese werden bislang einfach aus der Vorlage gezogen. Im Hinblick auf die Ladezeiten wird diese neue Vorlage keinen bis kaum einen Unterschied machen, statt wie bisher eine statische Berechnung durch den Prozessor durchzuführen, die die Seite verzögert lädt, wird das Laden der Seite durch den neuen Code vermutlich unwesentlich kürzer, diese Zeit wird dann aber für das kompilieren und ausführen des Javascripts, dass die Berechnung durchführt, gebraucht. Die Veränderung wird also vermutlich nicht so groß ausfallen, dass man explizit deswegen jetzt die Attacken auslagern sollte, dies ist etwas, was ohnehin nötig ist.
Da nun aber die technische Machbarkeit und die Grundsätzliche Bereitschaft einer solchen Umsetzung geklärt ist, steht als nächstes die Frage im Raum, ob ein solcher Rechner überhaupt allgemein befürwortet wird und wenn ja, an welcher Stelle dieser platziert werden soll (Pokémon-Artikel vs. Spezialseite). Ich denke die letztendliche Entscheidung wird sich am besten mit einer Abstimmung durchführen lassen, ich möchte diese aber nicht übereilt starten und stattdessen lieber noch etwas Zeit lassen, damit alle Interessierten sich dazu äußern können, vielleicht stellt sich ja heraus, dass es noch eine bessere Möglichkeit als diese gibt oder eine Mehrheit bereits vorweg für die Umsetzung des Vorschlags von Lasagne ist. -- RobbiRobb 12:29, 22. Mai 2019 (CEST)
Danke für die Vorarbeit, RobbiRobb! Die Prototyp-Lösung finde ich schon mal ganz gut. In dieser Form sollte es in den Pokémon-Artikeln umsetzbar sein. Von mir aus kann es aber auch als Spezialseite gemacht werden, auf die dann unter der bisherigen Tabelle verwiesen wird. ~ 418.gif Buoysel 12:46, 22. Mai 2019 (CEST)
Ich danke dir, dass sich aus unserem kleinen Gespräch darüber bereits dieser Prototyp ergeben hat, Robbi! Mir gefällt dieser Ansatz schon sehr, sodass ich mir diese Form der Berechnung auch in den Pokémon-Artikeln vorstellen könnte. Sollte sich bei einer Abstimmung aber für eine Spezialseite ausgesprochen werden, wäre dies ebenfalls für mich in Ordnung. Auf jeden Fall ist dies eine sehr gute Grundlage, um die Überarbeitung der Darstellung der Statuswerte stark voranzutreiben. ~ Taisuke Diskussion 15:48, 22. Mai 2019 (CEST)
Der Rechner gefällt mir auch sehr gut, ich wäre dafür, den Rechner auf eine Spezialseite zu packen und unter den bisherigen Tabellen zu verlinken. Ich denke dass man, vor allem wenn man mobil unterwegs ist, am liebsten direkt die maximalen Statuswerte sehen möchte und nicht erst noch 6 mal 252 FP und 31 DV eintippen will. Deshalb würde ich die Statuswertetabelle so ähnlich belassen, wie sie jetzt ist, man könnte vielleicht die Maximalwerte bei negativem Wesen entfernen. Luca12379 Diskussion 16:30, 22. Mai 2019 (CEST)
Der Prototyp ist zwar vom Design her sehr ansprechend, jedoch gibt es da funktional noch ein paar Problemchen, so kann man zur Zeit Buchstaben oder Zahlen grösser als 252 eingeben, was scheinbar auch nicht einfach so ohne weiteres behoben werden kann, verschiedenen Browsern sei dank. Wären aus diesem Grund eventuell Slider ne Idee, mit nem zusätzlichen um alle Werte gleichzeitig zu erhöhen? (Würde spontan auch den default woanders als Level 1 setzen, da sieht man kaum was) --Datei:Sugimori 672.pngMecanno-manMäh 17:06, 22. Mai 2019 (CEST)
Der Prototyp des Rechners ist meiner Meinung nach sehr gelungen, RobbiRobb! Als ich den Vorschlag zur Überarbeitung der Darstellung der Statuswerte ursprünglich gemacht hatte, dachte ich nicht daran, dass ein eingebetteter Rechner überhaupt eine realistische Option ist. Wie ich weiter oben schon geschrieben habe, halte ich diesen Rechner für eine bessere Lösung als eine statische Tabelle, auch wenn man meinen ursprünglichen Vorschlag umsetzt. Ich finde auch, dass dieser Rechner direkt in die Pokémon-Artikel eingebunden werden sollte, da man so den Statuswerte-Rechner und weitere Pokémon-Informationen auf derselben Seite hätte, was meiner Meinung nach ein großer Vorteil ist. Noch ein paar Verbesserungsvorschläge für die finale Version des Rechners:
- Sinnvolle Voreinstellung (z.B. Level 100, 252 FP und 31 DV auf jedem Wert, neutrales Wesen)
- Zwei Knöpfe, um sofort alle FP und DV zu maximieren bzw. minimieren (spart bis zu 12 Eingaben)
- Neben den Namen der Wesen auch kurz den Effekt in Klammern angeben (z.B. "Froh (+Init., -Sp.A.)")
--Lasagne (Diskussion) 20:45, 22. Mai 2019 (CEST)

Ich habe inzwischen mit einigen Benutzern Rücksprache gehalten und Feedback gesammelt, wo es möglich war und habe daher auf der Grundlage dieser eine etwas erweiterte Version der bisherigen Tabelle gebastelt, die hier zu finden ist. Dabei wurden vor allem folgende Aspekte verändert:

  1. Die Startwerte beim Laden der Seite sind jetzt direkt auf das Maximum gesetzt, dies betrifft sowohl den Level, die DVs, aber auch sämtliche FP, die damit zwar das vom Spiel vorgegebene Maximum übersteigen, dafür allerdings weiterhin das Maximum aller Werte gleichzeitig anzeigen kann. Daneben habe ich ein Wesen eingefügt, was standardmäßig ausgewählt ist und sich auf alle Werte positiv auswirkt. Im gleichen Zug habe ich eine geplante Funktion, die FP zu maximieren, damit sie eben jenes vom Spiel vorgegeben Maximum nicht übersteigen, nicht implementiert, dies hätte hier Konflikte verursacht.
  2. In der Kopfzeile finden sich neben den FP und den DVs Pfeile, die es ermöglichen, alle Werte dieser Spalte zu maximieren. Ich glaube nicht, dass es sich lohnt, einen Knopf einzufügen, der sowohl FP als auch DVs maximiert bzw. minimiert, wenn das von einer Mehrheit gewünscht ist, kann ich diesen aber sicherlich auch nich einfügen. Ansonsten würde ich es dabei belassen, das dürfte die Nutzung schon erheblich beschleunigen und komfortabler machen.
  3. Eine kurze Angabe, was genau die einzelnen Wesen bewirken, habe ich zunächst noch nicht eingefügt, dies lässt sich aber recht einfach nachtragen, wird sich aber vermutlich auf die Breite der Tabelle auswirken. Wenn das aber gewünscht ist, werde ich das selbstverständlich gerne ebenfalls einfügen, um die Verständlichkeit und Benutzerfreundlichkeit zu erhöhen.
  4. Im Hinblick auf die Sicherheit habe ich einige Mechanismen eingebaut, die verhindern, dass die einzelne Werte ihr erlaubtes Maximum über- oder unterschreiten. So kann nun kein Wert mehr unter 0 fallen, das Level kann nicht mal unter 1 fallen, gleichzeitig können die FP 255, die DVs 31 und das Level 100 nicht übersteigen. Gleichzeitig wird auch garantiert, dass es nicht zu merkwürdigen Ergebnissen kommt, wenn ein Feld leer ist. Das sind zwar nur kleinere Änderungen, verhindert aber, dass Benutzer plötzlich übergroße Balken oder einfach gar keine Balken mehr zu sehen bekommen oder sonst welchen Unfug anstellen (das würde uns zwar nicht beeinflussen, weil es Clientseitig ausgeführt wird und weder die Server noch die eigentlichen Seiten davon betroffen sind, es hinterlässt aber keinen allzu guten Eindruck, wenn das so schlampig programmiert wird).

Das sind die bisherigen Änderungen zur ersten Version, gibt es Änderungen, die dabei nicht so gut gefallen, fehlt noch irgendwas bzw. wird die Kurzbeschreibung der Wesen so stark gewünscht, dass ich diese auf jeden Fall übernehmen soll? Ansonsten bin ich auch für alle gefundenen Bugs offen, ich werde dann mein bestes versuchen, diese zu beheben. -- RobbiRobb 23:43, 22. Mai 2019 (CEST)

Ich war ja anfänglich eher skeptisch, ob das gut aussehen könnte, bin aber von dem Rechner mittlerweile ein großer Fan. Optisch "minimalinvasiv". :D Vielen Dank für all eure Beiträge und Robbi, für die Programmierung! Zum Wesen könnte ich mir vorstellen, dass man das wie in den Spielen löst und die erhöhte Werte rötlich färbt und die niedrigeren Werte hellblau... aber dass es irgendwie sichtbar sein sollte, da stimme ich Lasagne zu. Ich frage mich, ob es die Hoch- und Runterpfeile in den Feldern selbst wirklich braucht, die überladen das Layout ein bisschen und ich schätze, dass sie kaum genutzt werden werden, keiner wird z. B. von 31 auf 30 DV runterklicken oder FPs oder Level in Einerschritten durchschalten. Ich gehe davon aus, dass die meisten User das händisch eingeben werden, daher könnte man sie auch weglassen. Gilt nicht für die Minimal- und Maximalpfeile, die finde ich top. Ansonsten alles wunderbar und mir wird jetzt erst bewusst, wie cool ich das finde, dass wir da dynamische Balken drinnehaben. :)) Pokémon-Icon_674.png Maxmiran 10:00, 23. Mai 2019 (CEST)
Danke für die gute Überarbeitung, RobbiRobb! Die kleinen Pfeile neben "FP" und "DV" gefallen mir, einen Knopf zum Maximieren und Minimieren aller Werte braucht es damit meiner Meinung nach nicht mehr.
Beim Vergleich mit dem Smogon-Rechner habe ich aber einen Bug entdeckt: Beim voreingestellten Pokémon (Latias) werden auf Level 85 mit Wesen Scheu mit 252 FP und den DVs auf 31 beim Initiative-Wert 299 angegeben, obwohl es eigentlich 298 sein müssten. Bei negativem Wesen auf Initiative (mit sonst den gleichen Einstellungen) sind es 244 statt 243. Ich vermute, der Grund dafür ist, dass momentan nicht vor Einbezug des Wesens abgerundet wird (laut der Formel kommt vor dem Wesen ein Initiative-Wert von 271,9 raus, ohne Abrundung sind es mit positivem Wesen 299,09). Ich habe nochmal geprüft, ob diese Abrundung in Pokémon-Spielen aktuell tatsächlich noch gemacht wird und bin bei meinem Fuegro auf die Antwort gestoßen, das auf Level 57 mit Wesen Sacht (+Sp.V., -Sp.A.) und einem Spezial-Angriffs-DV von 31 auf einen Spezial-Angriffs-Wert von 101 kommt. Ohne Einbezug des Wesens würde hier 113,87 rauskommen, abgerundet 113. Rechnet man mit dem unabgerundeten Wert weiter, kommt man auf 102,483, also auf 102. Mit dem abgerundeten Wert kommt man auf 101,7, also auf 101, was der richtige Wert ist. Das ist momentan aber auch im Statuswerte-Artikel falsch erklärt, demnach wird diese Abrundung seit der fünften Generation nicht mehr gemacht, was offenbar falsch ist.
Zudem habe ich noch folgende (hauptsächlich kleinere) Verbesserungsvorschläge:
  1. Wird das Level bei der Neueingabe kurzzeitig ganz entfernt, wird momentan NaN ausgegeben, hier sollte man stattdessen die Werte für Level 1 anzeigen.
  2. Die FP-Obergrenze auf 252 statt 255 setzen (gilt seit der sechsten Generation und FP über 252 haben sowieso keine Auswirkungen).
  3. Durch die kleinen Pfeile neben den FP-Feldern die FP jeweils um vier erhöhen bzw. senken (noch besser: auf den nächsthöheren bzw. -niedrigeren durch vier teilbaren Wert setzen).
  4. Wenn man ein Wesen einbaut, das sich auf alle Werte (außer KP) positiv auswirkt, sollte man vielleicht auch eins einbauen, das auf alle Werte negativ wirkt. Man könnte diese "Wesen" dann z.B. "(positives Wesen)" und "(negatives Wesen)" oder "(+alle Werte)" und "(-alle Werte)" nennen.
  5. Vielleicht hast du sowieso schon daran gedacht, RobbiRobb, zur Sicherheit wollte ich es aber trotzdem noch erwähnen: Vor der Einbindung ins PokéWiki sollte der Ninjatom-KP-Spezialfall gesondert behandelt werden.
  6. "Spezifische Werte" sollte meiner Meinung nach irgendwie umbenannt werden, z.B. in "Permanente Werte" (finde ich auch nicht gut, so werden sie aber im Statuswerte-Artikel bezeichnet), "Resultierende Werte" oder nur "Statuswerte".
  7. Zum Thema Kurzbeschreibungen der Wesen können gerne noch ein paar weitere Nutzer ihre Meinung abgeben, die größere Breite der Tabelle sollte aber kein Problem sein, immerhin ist sie sowieso wesentlich schmaler als die aktuell verwendete Tabelle. (So viel schmaler sogar, dass man sich überlegen könnte, zusätzlich zum Rechner eine Doppelspalte (also Lv. 50 und Lv. 100) der bisherigen Tabelle beizubehalten. Muss aber nicht sein, ist nur eine Idee.)
Edit: Und noch ein "Bug": Die meisten Buchstaben kann man in die Felder nicht mehr eingeben, "e" aber schon. Und man kann damit z.B. die Obergrenze bei den FP umgehen, wenn man z.B. 5e5 eingibt (entspricht 500.000), dann sieht man wieder die riesigen Balken. Bei den DV hat das "e" auch eine Bedeutung, wird interessanterweise allerdings nicht so wie bei den FP ausgewertet. --Lasagne (Diskussion) 10:36, 23. Mai 2019 (CEST)
Hallo, ich melde mich jetzt auch mal zu dem Thema. Zu allererst mal, danke Robbi für die Programmierung, der Rechner ist wirklich gut geworden. Wenn es die Seiteladezeit nicht verlängert, dann würde ich es bevorzugen, wenn er im Pokémon-Artikel steht. Wozu so eine schöne Option auf eine Spezialseite bringen, wenn man dann sogar zusätzlich einen Pokémon-Button einprogrammieren müsste? Was die Wesen angeht könnte man überlegen ob man, wie Lasagne meinte, Kurzbeschreibung mit +Ang etc. hinter die Wesen schreibt, damit man noch vor dem Auswählen sieht, was das jeweilige Wesen bewirkt. Zur besseren Unterscheidung und der Hauptspiel-Orientierung könnte man ja das +Ang hinter dem Wesen zusätzlich rot einfärben und den negativen Wert hellblau. Also z. B. Solo (+Angr. -Vert.). Zusätzlich könnte man in diesem Fall den Schriftzug von Angriff rot färben und den von Verteidigung hellblau, das ist aber kein Muss. Bei dieser Methode müsste man dann gucken, wie lang die Tabelle dadurch wird. Zwei Kleinigkeiten, die ich noch etwas unschön finde: 1. die beiden verschieden „Balken-Blöcke“ sind sehr unverhältnismäßig. Z. B. in der Voreinstellung sind beide Spez.-Vert.-Balken gleich lang, obwohl der rechte 3x so groß sein müsste. Es muss nicht genau verhältnismäßig sein, aber die Basiswert-Balken könnten ja ein wenig kürzer und die anderen dafür länger, die nötige Breite ist ja noch vorhanden. Dadurch würden dann die Kurzbeschreibungen hinter den Wesen die Tabelle auch nicht zusätzlich verlängern. Dann stört mich noch optisch diese kleine weiße Spalte als Trennung. Könnte man die nicht ein wenig verändern, vielleicht auch lila einfärben, sprich eine kleine lila „Trennspalte“ daraus machen anstatt zwei? Cliffichen 10:56, 23. Mai 2019 (CEST)
Soweit ich mit Robbi gesprochen habe kommt der "Bug" mit e leider aus dem Browser (konkret aus Chrome) weil dieser e als Zahl akzeptiert (eben weil man 500000 auch als 5e5 schreiben darf) - andere Broswer, z. B. Firefox untersützen aber das "nur Zahlen eifügen" gar nicht, weshalb man da immernoch nach belieben Unsinn eingeben kann; aus diesem Grund wäre ich dagegen das NaN bei leerem Feld abzuändern, dieses wird beispielsweise auch bei Level f angezeigt, was sich nicht wirklich von Level (nichts) unterscheidet.
Ein anderes Ding das mir eigefallen ist: Müsste man diesen Rechner nicht auch noch für andere Generationen brauchbar machen? Es gibt ja genügend Pokémon die im Laufe der Zeit Änderungen an ihren Werten erfahren haben, es gab Änderungen in der Berechnung und es gab sogar andere Mechaniken in Gen 1 und 2. So spontan fällt mir auch noch Lets Go mit den Bonbons ein, die man wahrscheinlich auch noch berücksichtigen müsste...
Ich bin ehrlich, mich stören die Pfeile hier eher; die Idee um genau 4 zu senken gilt doch nur für Pokémon Level 100? Für tiefere Level meine ich sind die "sinnvollen" Unterschiede grösser, weshalb ich auch da davon absehen würde (und stattdessen die individuellen Pfeile einfach wegwerfen würde) --Datei:Sugimori 672.pngMecanno-manMäh 13:21, 23. Mai 2019 (CEST)
Zum e: Okay, trotzdem ist es möglich, bei der Berechnung maximal 252 FP zu nehmen. Man kann es aber natürlich auch so lassen, wie es jetzt ist, das wäre immerhin ein lustiges Easteregg. Ich habe mir noch die JavaScript-Datei zum Rechner angeguckt, um zu prüfen, warum das e bei den DV anders behandelt wird als bei den FP, und gesehen, dass bei den FP die Division durch vier noch im parseInt-Aufruf getätigt wird. Wenn man die Division außerhalb davon tätigt, würde das e wie bei den DV nicht als Exponent interpretiert werden. Dann müsste man aber noch Math.floor anwenden, um wieder auf eine Ganzzahl abzurunden.
Zum NaN: Meiner Meinung nach ist die Anzeige von NaN immer unschön und sollte falls möglich vermieden werden. In diesem Fall könnte man einfach mit einem Standardwert (z.B. Level 1) rechnen, wenn irgendein Unsinn oder nichts eingegeben wurde, genau wie das bei den FP und DVs bereits jetzt gemacht wird (mit 0 als Standardwert).
Zu den anderen Generationen: Meiner Meinung nach ist es nicht notwendig, den Rechner auch für Generation 1 und 2 nutzen zu können. Sie wurden in der bisherigen Tabelle bereits nicht behandelt (zumindest nicht bei den tatsächlichen Werten) und ich schätze mal, dass diese Funktion so selten gebraucht würde, dass es zu vertreten ist, wenn man auf eine externe Seite oder manuelles Rechnen ausweichen muss, um die Statuswerte dafür zu erhalten. Die Awakening values aus Pokémon Let's Go! sind da schon eine andere Sache, da sie zumindest aus einem aktuellen Spiel stammen. Meiner Meinung nach kann man sie aber ebenfalls ignorieren, da ihre Auswirkungen sehr leicht im Kopf zu berechnen sind (pro AV-Punkt ein Statuswerte-Punkt, unabhängig von Level und Wesen) und sie bei den "regulären" Pokémon-Editionen wohl auch in Zukunft nicht vorkommen werden (hoffe ich zumindest, werden wir ja in Schwert und Schild sehen).
Zu den Pfeilen: Ich finde gar nicht, dass die stören. Sie werden ja auch immer nur beim ausgewählten Feld angezeigt, sorgen also auch nicht für eine optische Überladung der Tabelle. Und der Sprung um jeweils vier Punkte ist deswegen sinnvoll, weil die FP immer durch vier geteilt und dann abgerundet werden. Nur auf Level 100 gibt es dabei zwar wirklich einen Statuswerte-Punkt pro vier FP, aber auch auf allen anderen Leveln können sich die Statuswerte nur bei durch vier teilbaren Fleißpunkten erhöhen. (Z.B. gibt es auf Level 80 grundsätzlich einen Statuswerte-Punkt pro fünf FP, wenn man das aber mit geraden DV und neutralem Wesen ausprobiert, sieht man, dass der Statuswert nicht bei 5 FP, 10 FP, 15 FP, usw., sondern bei 8 FP, 12 FP, 16 FP, 20 FP, 28 FP, usw. nach oben springt.) --Lasagne (Diskussion) 19:48, 23. Mai 2019 (CEST)
Wenn wir schon dabei sind sehe ich keinen Grund den Rechner nicht gleich für alte Generationen mitzuprogrammieren; was das NaN angeht: Robbi meinte da das das noch nicht fertig sei, was das verhindern von Unsinnseingaben angeht. Zur Sache mit den Pfeilen: Ich fürchte da müssen wir mal gross drüber wie verschiedene Browser das darstellen. Ich hab das auf Firefox/Ubuntu aufgerufen, das Ergebnis war schrecklich - ich sehe aber jetzt auch in Chrome/Windows 10 das es da schon sehr gut funktioniert. Schlussendlich wird man das wahrscheinlich einfach mal durch eine der Broswervergleichseiten hauen müssen wenns mal fertig ist. --Datei:Sugimori 672.pngMecanno-manMäh 21:35, 23. Mai 2019 (CEST)
Dass die Pfeile in anderen Browsern so schlimm aussehen, hätte ich nicht gedacht. In einigen anderen Browsern (z.B. Edge, Internet Explorer, Chrome für Android) werden sie einfach gar nicht angezeigt.
Ich habe mir übrigens die HTML- und JavaScript-Dateien nochmal genauer angeguckt und ein paar Dinge ausprobiert (habe mit HTML und JavaScript nicht viel Erfahrung):
- Dass die kleinen Pfeile (oder das Drücken der Pfeiltasten auf der Tastatur) bei den FP-Feldern den Wert auf den nächsthöheren bzw. -niedrigeren durch vier teilbaren Wert setzen, ist recht leicht umzusetzen, indem man das Attribut step="4" hinzufügt.
- Momentan werden die Werte alle 10 Millisekunden neu berechnet, unabhängig von den Eingaben. Das sorgt bei mir dafür, dass diese Seite alleine immer etwa 3 bis 6 % CPU-Leistung verbraucht, wenn ich sie anschaue, ohne Eingaben zu machen. Wenn ich die Methode setInterval() entferne und stattdessen das Attribut oninput="updateStatuswerte()" bei allen Feldern und onchange="updateStatuswerte()" bei der Auswahl des Wesens hinzufüge und in den Methoden minimizeFP() und Co. auch die Methode updateStatuswerte() aufrufe, kann ich den CPU-Verbrauch der Seite auf 0 bis 0,5 % senken, ohne die Funktionalität zu ändern.
Außerdem habe ich noch einen Bug entdeckt: Die Wesen Kühn und Mäßig funktionieren aufgrund der Sonderzeichen aktuell nicht.
--Lasagne (Diskussion) 23:11, 23. Mai 2019 (CEST)
Um den eigentlichen Code brauchst du dir keine Sorgen zu machen, im Moment sind wir in der Aufbauphase, optimiert wird, wenn alles korrekt ausgeführt wird zwinker3.gif -- RobbiRobb 23:24, 23. Mai 2019 (CEST)
Ich bitte nur darum, nicht nur zu berücksichtigen, was technisch alles möglich ist, sondern auch was aus Anwendersicht Sinn macht. So n Rechner sollte so viele Funktionen wie nötig und so wenige wie möglich enthalten. Daher sind, wie gesagt, die Einzelpfeile einfach nicht sinnvoll, weil es keinen sinnvollen Anwendungsfall gibt, wo Werte in Einerschritten durchgeschaltet anstatt manuell eingegeben werden. Lasst die Pfeile einfach weg, dann spart man sich das optimieren. ^^ Pokémon-Icon_674.png Maxmiran 10:17, 24. Mai 2019 (CEST)

Zeit für die nächsten Änderungen: Version 3 ist online. Im Vergleich zum letzten Mal sind die Änderungen allerdings um einiges kleiner ausgefallen, ich habe noch einmal die "Sicherheit" der Eingaben überarbeitet, ansonsten sind die meisten Vorschläge recht kleiner Natur gewesen. Hier noch einmal in Kürze die Änderungen:

  1. Das FP-Maximum ist auf 252 begrenzt, da alle Werte darüber ohnehin keine Auswirkungen haben. Den step auf 4 zu setzen ist jetzt allerdings leider nicht mehr möglich, da ich die Art der Eingabe geändert habe, dazu aber gleich mehr.
  2. Alle Eingaben haben jetzt ein Default, wird das Feld also leer gelassen, werden die Werte intern maximiert. So umgehen wir die unschönen NaN an dieser Stelle.
  3. Der Rechen-Fehler aufgrund der fehlenden Rundung ist jetzt auch eingefügt. Da ich gerade zum ersten Mal mit Statuswerten rechne, war mir das nicht bekannt und da unsere Formel im Hinblick darauf scheinbar falsch ist, habe ich das logischerweise falsch übernommen. Jetzt sollte dieser Fehler aber nicht mehr auftreten.
  4. Für eine zusätzliche Nutzerfreundlichkeit habe ich ein weiteres, negativstes Wesen eingefügt. Dies steht nun ebenfalls im dropdown zur Auswahl.
  5. Die Überschrift der Werte wurde geändert, 100 % zufrieden bin ich immer noch nicht, das zu ändern wird aber so einfach, dass man es selbst im bereits laufenden Betrieb noch erledigen könnte. Daher mache ich mir da keinen großen Gedanken, wenn wir da nicht direkt etwas perfektes haben.
  6. Aufgrund der scheinbar recht hohehn Unzufriedenheit mit den Pfeilen an den Eingabefeldern aufgrund vom Browser abhängiger Designs und scheinbarer Nutzlosigkeit, habe ich diese kurzerhand entfernt. Das ging aber nur, indem ich den Typ der Eingabefelder geändert habe, diese sind jetzt Textfelder, die alle Zeichen rausfiltern und lediglich die Eingabe von Zahlen sowie das Verwenden von Steuerungstasten erlauben. Somit ist es nun nahezu unmöglich, irgendwas unvernünftiges in die Felder einzugeben - und wenn es doch jemand macht, dann hat der halt einfach pech gehabt, in nen Taschenrechner gibt man auch keine Buchstaben ein und wundert sich dann, warum es merkwürdige Ergebnisse gibt. Was es noch zu testen gilt ist, ob das auch mobil funktioniert, da wäre es schön, wenn der eine oder andere das mal testen und mir mitteilen könnte ^^

Abschließend noch ein paar Hinweise so am Rande:

  1. Ja, der Spezialfall Ninjatom ist mir bekannt, bislang aber noch nicht implementiert. Wenn das ganze ins Wiki überführt wird, werde ich mich darum aber kümmern ^^
  2. Die unproportionale Länge der Balken wurde zur Kenntnis genommen, beim Übersetzen der Vorlage in Wiki-Code werde ich dafür sorgen, dass diese Diskrepanz nicht mehr auftritt.
  3. Da die Kennzeichnung der Auswirkungen der Wesen scheinbar noch für einiges an Gesprächsstoff sorgt, werde ich dort zunächst nichts machen, ich denke das muss auch nicht sofort entschieden werden, da können wir auch einfach erst mal noch ein paar Meinungen zu sammeln.
  4. Da ich ohnehin einen großteil der Inputs überarbeitet habe, habe ich auch die vorgeschlagenen Syntax-Änderungen zur Verringerung der Systemlast durchgeführt. Ich weiß auf jeden Fall noch das eine oder andere, was sich optimieren lässt, darum können wir uns wie gesagt aber auch noch kümmern, wenn wir mit Design und Funktionen zufrieden sind.

Das ist dann zunächst auch schon alles von mir. Ich denke, dass wir dann also zeitnah eine Abstimmung starten können, um darüber zu entscheiden, wohin das ganze soll. Wenn es also noch etwas gravierendes zu besprechen gibt, bevor wir diese Abstimmung durchführen, teilt mir das bitte jetzt mit, ansonsten werde ich die vermutlich im Laufe des morgigen Tages (Samstag) starten. -- RobbiRobb 11:58, 24. Mai 2019 (CEST)

Danke für die erneute Überarbeitung und die vielen Veresserungen, RobbiRobb! Mobil (zumindest in Chrome für Android) kann man jetzt jeglichen Unsinn in die Felder eingeben, dabei kommt dann auch NaN raus, zumindest bei den FP-Feldern.
Nochmal zur angeblichen Nutzlosigkeit der Zahlenfelder, mit denen die kleinen Pfeile daherkommen: Bei mobilen Browsern, die das unterstützen (z.B. Chrome), sorgen sie auch dafür, dass man eine Bildschirmtastaur angezeigt bekommt, mit der nur Zahlen eingegeben werden können, was ziemlich praktisch ist. Bei PCs kann man in unterstützen Browsern mit den Pfeiltasten der Tastatur den Wert erhöhen oder senken (nicht nur in Chrome, sondern z.B. auch in Edge), auch das ist oft praktischer, als den Wert immer manuell eingeben zu müssen. Und sie werden z.B. bei den EV-Feldern (bzw. FP-Feldern) im Damage Calculator (Schaden-Rechner) von Pokémon Showdown (gehört zu Smogon) verwendet, so nutzlos können sie also nicht sein. Dass sie in einigen Browsern unschön dargestellt werden, ist natürlich ein Problem, aber sie haben auch einige Vorteile.--Lasagne (Diskussion) 13:33, 24. Mai 2019 (CEST)

Abstimmung: Darstellung der Statuswerte

Da wir inzwischen eine recht gute Grundlage haben, auf deren Basis wir darüber abstimmen können, wie wir weiter mit einem eventuellen Statuswerterechner verfahren wollen, werde ich das hier jetzt einfach zur Abstimmung stellen. Damit alles weitere keine vergebene Mühe ist, werde ich bis auf weiteres auch keine Weiteren Änderungen mehr an dem Rechner vornehmen, oben verlinkte Version drei ist also die aktuellste, auf deren Basis abgestimmt wird, wobei sowas wie Eingabefelder natürlich noch verändert werden können. Ich bitte daher alle SBs, sich ein Bild davon zu machen, die Vor- und Nachteile abzuwägen und darüber abzustimmen, ob und wenn ja wie sowas hier gewünscht ist ^^ -- RobbiRobb 20:38, 25. Mai 2019 (CEST)

Vorlage:Celer1

Option 1: Status quo, bisherige automatische Berechnung für festgelegte Wertebereiche

Option 2: In die Pokémon-Artikel implementierter Statuswerterechner, Überarbeitung der bisherigen Vorlage

  1. Doppelte Inhalte (wie bei Option 4) finde ich eher unschön und wenn man sich für eine Variante entscheiden muss, dann wäre ich doch das Gewohnheitstier und würde die Infos auf der Pokémon-Seite direkt erwarten. ~ TiMauziDatei:Pokémonsprite 052 Fuß.png 01:02, 28. Mai 2019 (CEST)

Option 3: Eigene Spezialseite, Verlinkung aus der aktuellen Vorlage

Option 4: Option 2 und Version 3

  1. Ich hätte den Rechner gerne in den jeweiligen Pokémon-Artikeln integriert, womit eine Veränderung der aktuellen Vorlage einhergehen würde. Des Weiteren erachte ich aber auch eine eigene Spezialseite als sinnvoll, da man dort sehr viel schneller mehrere verschiedene Pokémon durchgehen kann und dort somit eine zentrale Anlaufstelle für das Berechnen der Werte jeglicher Pokémon hätte. ~ Taisuke Diskussion 13:24, 26. Mai 2019 (CEST)
  2. Ich bin zwar auch jemand, der die Basiswerte und Werte mit FP und DV nur für Strategien anschaut und dass dann ja auf den entsprechenden Strategie-Artikeln, da es beim Durchspielen, zumindest mir, unwichtig erscheint. Aber generell finde ich es doch soweit interessant, dass ich nicht abgeneigt bin, diese Möglichkeit anzunehmen, da auch der Informationsgehalt in gewisserweise gesteigert wird. Und wie Tai schon sagte, ist es tatsächlich hilfreich, auch eine eigene Spezialseite zu haben, wenn es mal um mehrere Pokémon gehen sollte, sodass man nicht jeden Artikel einzeln aufrufen müsste. -- Grüße ShortyBuzz 14:15, 26. Mai 2019 (CEST)
  3. Wie in der Diskussion schon erwähnt, bevorzuge ich auch den Einbau in die Pokémon-Artikel, solange die Ladezeit dadurch nicht verlängert wird. Ansonsten kann ich mich meinen Vorrednern nur anschließen – eine Spezialseite für mehrere Pokémon ist ebenfalls praktisch. -- Cliffichen 15:26, 26. Mai 2019 (CEST)
  4. Ich finde diese Lösung auch am praktikabelsten. So hat man immer gleich Zugriff auf den Rechner. Ich denke auch, dass diese Option unser Strategie-Profil stärkt. -MfG, Kenaz-Hagalaz Disku 17:17, 26. Mai 2019 (CEST)
  5. Ich kann mich auch nur anschließen, auch ich sehe in den Umsetzungen sowohl in den Pokémon-Artikeln als auch auf einer Spezialseite jeweils sinnvolle Anwendungsfälle und denke somit, dass beide vorhanden sein sollten. --  TM Master  17:34, 26. Mai 2019 (CEST)
  6. Ich sehe den Rechner auch als weitaus sinnvoller als die aktuellen statischen Tabellen. Aber auch eine Spezialseite sollte man meiner Meinung nach anlegen, da dadurch das Vergleichen verschiedener Pokémon einfacher wird Luca12379 Diskussion 17:44, 26. Mai 2019 (CEST)
  7. Ich denke, dass das Einbinden eines Rechners in die Artikel die beste Möglichkeit ist. Den Nutzen einer Spezialseite kann ich gut nachvollziehen, auch wenn sie mir persönlich nichts bringen würde. Dennoch tendiere ich zu einem „Dafür“. ~ 418.gif Buoysel 18:01, 26. Mai 2019 (CEST)
  8. Siehe bereits genannte Argumente. Eine Spezialseite fände ich nur sinnvoll, wenn man (mind.) zwei Rechner auf der Seite gleichzeitig haben könnte. Mit nur einem Rechner auf der Spezialseite könnte man genauso gut die einzelnen Pokémon-Artikel in verschiedenen Tabs öffnen um die Werte zu vergleichen. --DeXter 19:17, 26. Mai 2019 (CEST)
  9. Was soll ich jetzt noch sagen? Der Rechner kann gerne in die Artikel integriert werden und ihn auf einer Spezialseite zu haben ist auch nicht verkehrt. Wie viele Rechner jetzt auf die Seite kommen ist mir egal, das könnt ihr selbst ausmachen. GrollenKette951 19:45, 26. Mai 2019 (CEST)
  10. Weil ich davon ausgehe das Robbi das hinbekommt :P ansonsten wär mir das in den Artikel wichtiger als die Spezialseite. --Datei:Sugimori 672.pngMecanno-manMäh 21:29, 26. Mai 2019 (CEST)
  11. Also dass die aktuelle Darstellung wenig hilfreich ist, muss ich hier denk ich niemandem erklären. Und die Integration von Rechnern, mit denen man sich Werte errechnen kann, kann ich nur unterstützen, da man sich so viel flexibler informieren kann, vorausgesetzt, die Performance des Wikis leidet nicht darunter. Die Basiswerte würde ich aber weiterhin noch irgendwo aufführen, da die doch - zumindest für einige CP-Spieler - ein wichtiger Richtwert sind. --Shin no tatakai wa, korekara da. The true fight is yet to come. JustRotty 21:35, 26. Mai 2019 (CEST)
  12. Pokémon-Icon_674.png Maxmiran 10:22, 27. Mai 2019 (CEST)
  13. ~ ~ Simonsees ~ 17:39, 28. Mai 2019 (CEST)
  14. Auf Basis von Diskussionen mit Robbi via Discord wäre eine Mehrfachauswahl wohl umzusetzen, insofern würde auch die Spezialseite einen Mehrwert bieten. Jones Albtraum? 16:13, 31. Mai 2019 (CEST)

Enthaltung

  1. Habe den Punkt in den Artikeln bisher nie beachtet und kann da mit allem vorgeschlagenen Leben ka.gif Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 23:05, 25. Mai 2019 (CEST)

Kommentare

@Buoysel, Cliffichen, CLina, GoPika, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Killuu, Korvel1, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Pk-fan, RobbiRobb, Ryuichi, shadowtweaker, ShortyBuzz, Simonsees, Snackhound, Taisuke, AAWiki, Der Sternendiamantritter, DeXter, Dusk, GrollenKette951, Hydrokyu, JustRotty, Lord Racer, Mario-WL, Mega Glurak Y, Nescientist, PokéSpe, SwowoJonny, TiMauzi, TM Master, Yrel: -- RobbiRobb 20:38, 25. Mai 2019 (CEST)

Wie genau wertest du das hier aus mit den Stimmen für Option 4? Zählen die erstmal sowohl zu 2 und 3? Weil spontan scheint mir das Leute die für Option 4 stimmen lieber 2 oder 3 umgesetzt hätten als 1 - dasselbe dürfte jedoch auch andersrum gelten und Leute die für 2 oder 3 stimmen würden wohl lieber Option 4 umgesetzt haben als 1, wobei das dann nicht mehr ganz so klar ist. --Datei:Sugimori 672.pngMecanno-manMäh 23:59, 25. Mai 2019 (CEST)
Selbes Verfahren wie beim letzten mal. -- RobbiRobb 00:06, 26. Mai 2019 (CEST)
Vielleicht bin ich noch nicht ganz wach, aber irgendwie erkenne ich keinen Unterschied zwischen Option 2 und 4 :ka: -- Grüße ShortyBuzz 09:40, 26. Mai 2019 (CEST)
Option 4 bedeutet, dass der Rechner sowohl in den einzelnen Pokémon-Artikeln zu finden ist als auch auf einer eigenen Spezialseite. Option 2 würde den Rechner nur in die Pokémon-Artikel integrieren. Klingt das nachvollziehbar, Shorty? ~ Taisuke Diskussion 13:24, 26. Mai 2019 (CEST)
Jau, danke. Das ergibt Sinn für mich :D -- Grüße ShortyBuzz 14:15, 26. Mai 2019 (CEST)
Bevor ich abstimme hätte ich noch ne Frage, die DeXter indirekt schon gestellt hat: Wie sähe die Spezialseite denn aus? Wenn es nur der Rechner mit einer vorgeschalteten Pokémon-Auswahl wäre, sehe ich da nämlich keinen Mehrwert drin, böte der Rechner jedoch die Möglichkeit mehr als ein Pokémon auszuwählen (in welcher Form auch immer) böte er hingegen einen entsprechenden Mehrwert.
Ansonsten eben zum Thema Eingabevalidierung, da das ja in der Diskussion nen paar Mal aufkam: Hier wäre die einfachste Variante die Eingabe zunächst als String zu interpretieren und das ganze durch nen Validierer zu jagen (for(let i = 0; i < string.length; i++) { if(!["0","1","2",...,"9"].includes(string[i])) { return false; } } return true;) und schon hätte man auch Browserspezifisches wie das "e" rausgefiltert. Insofern sehe ich da keine Probleme sobald man an solche Punkte dran geht. Jones Albtraum? 13:43, 30. Mai 2019 (CEST)
Bislang war das, was ich vorgesehen hatte, eine Box mit nem Dropdown. Der Ansatz, den ich verfolgt habe, war der Wunsch, nicht für jedes Pokémon einen anderen Artikel aufzurufen, sondern auch einfach direkt auf einer Seite auswählen zu können. Wenn wir jetzt plötzlich mehrere Pokémon vergleichen wollen, kann das ganze schon wieder schwieriger werden, einfach zwei Boxen hardcoden sollte noch relativ unproblematisch sein, dafür brauchen wir ohnehin eine Lösung, weil es schließlich auch Pokémon mit mehr als nur einem Set von Statuswerten gibt. Eine dynamische Lösung für den Vergleich beliebig vieler Pokémon ist zwar technisch möglich, da bin ich mir allerdings nicht sicher, ob das im Moment innerhalb meiner Möglichkeiten liegt, das vollständig umzusetzen. -- RobbiRobb 14:32, 30. Mai 2019 (CEST)
Ich weiß jetzt nicht wie genau deine Lösung aussieht, wäre es theoretisch denkbar über irgendeine Form von Multiselect-Box (wie auch immer die dann aussieht) Instanzen der Box zu generieren? Also nicht die Anzahl direkt vorgeben sondern wirklich dynamisch zu erstellen? Sofern deine Box das hergibt könnte ich mich darum kümmern das dynamische drumherum umzusetzen. Jones Albtraum? 16:42, 30. Mai 2019 (CEST)

Attacken-Abschnitte

Da Mecanno-man das ganze weiter oben schonmal kurz angesprochen hat: Es wird dringend Zeit, dass wir was mit den Attacken-Tabellen in den Pokémon-Artikeln machen, zum einen schlagen sie auf die Ladezeiten (Seemon im Editfenster zu öffnen dauert 5-10 Sekunden), zum anderen sind einige Funktionen absolut nicht zu gebrauchen (schonmal probiert alle Generationen nebeneinander anzuzeigen?). Logischerweise wird das Problem von Spiel zu Spiel auch eher größer als kleiner. Ich habe mal testweise Seemon im Testwiki ne achte Generation verpasst: Die Parserausnutzung steigt zwar, allerdings sogar noch im Rahmen, die Benutzbarkeit ist aber aus oben genannten Gründen weiterhin Schrott. Insofern würde ich gerne noch vor den neuen Spielen hier was entscheiden. Wie schon mehrfach diskutiert wurde, gibt es primär zwei Lösungen:

  1. Neue Vorlage. Hier hat shadowtweaker vor Jahren angefangen, eine Fertigstellung ist jedoch nicht in Sichtweite und bisherigen Tests nach dürfte die akutell eingeschlagene Richtugn auch nur so semi die Last reduzieren.
  2. Auslagern: Hierbei würde die aktuelle (oder die zwei letzten, je nachdem wie man will) im eigentlichen Artikel stehen, weitere Generationen bekämen einen (gemeinsamen) Unterartikel. Dies ist die Lösung, die bereits für die Sprites genutzt wurde und die auf Dauer mit Sicherheit die besten Möglichkeiten bietet. Wie genau die Unterartikel aussehen sollen könnte man sicher auch noch besprechen (eigene Abschnitte, mit flex das ganze dynamisch machen usw usf).

Ich persönlich wäre eindeutig für die zweite Lösung und würde diese gerne möglichst vor der achten Generation umgesetzt sehen. Wie sind die sonstigen Meinungen zu dem Thema? Jones Albtraum? 14:23, 30. Mai 2019 (CEST)

Mir persönlich sind beide Lösungen recht, wobei es imo. idealerweise alles in einem Artikel bleibt; für mich ist es in dieser Situation allerdings wichtiger das wir das zeitnah (vor Gen 8) umsetzen, wenn wir die neue Vorlage also nicht in diesem Rahmen hinbekommen (sprich: shadow weiterhin nix dran macht und sich sonst niemand dessen annimmt), dann sollte man einfach auslagern. --Datei:Sugimori 672.pngMecanno-manMäh 14:39, 30. Mai 2019 (CEST)
Es stimmt zwar schon, dass alles auf einer Seite angenehmer ist, insgesamt wird aber auch Shadows neue Vorlage die Ladezeiten nicht so ewig verkürzen, schlicht weil es immer noch alles da ist. Hab im Testwiki bei genanntem Artikel aber grad mal kurz den gesamten Abschnitt entfernt und zum Vergleich die Vorschau geladen, die Ladezeiten scheinen sich gar nicht so wahnsinnig zu verkürzen, nur die Einbindungsgröße ist drastisch gefallen (-700k). Nichtsdestotrotz halte ich eine Auslagerung für die solidere Idee, selbst wenn Shadow sich jetzt darum kümmert, die neue Vorlage fertig zu schreiben, geraten wir in Probleme, wenn er nicht mehr da ist und eine neue Generation erscheint. Ich denke also, auslagern ist hier das mit unseren aktuellen Ressourcen vertretbarere, zumal sich auf einer eigenen Seite auch in Zukunft mehr Attacken eintragen lassen, als Shadows Vorlage im Hauptartikel jemals erreichen könnte. -- RobbiRobb 15:00, 30. Mai 2019 (CEST)
Ich spreche mich ebenfalls für eine Auslagerung aus. Sollte wirklich in der Zukunft mal eine gangbare Lösung für die Artikel gefunden werden, ist das ja auch fein, aber man sollte nicht auf etwas warten und bis dahin einen unschönen Status-Quo akzeptieren, wenn es auch anders geht. Ich würde es bevorzugen, wenn die aktuelle und die jeweils davor kommende Generation in den Artikeln auffindbar wären, die vorletzte kann ja weiterhin getoggelt werden. Ich finde die Lösung auch sehr attraktiv, weil dann der Quelltext entschlankt wird. In dem machen momentan schätzungsweise die Hälfte die Attackentabellen aus. Pokémon-Icon_674.png Maxmiran 15:15, 30. Mai 2019 (CEST)
Ich bin fürs Auslagern und nur die aktuelle Anzuzeigen auch würde ich gerne wissen wie die Auslagerung dann gestaltet werden soll, hat jemand Lust ein Beispiel zu kreieren? Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 09:53, 31. Mai 2019 (CEST)
Ich wollt im Laufe des Tages was basteln und hier verlinken Jones Albtraum? 10:46, 31. Mai 2019 (CEST)
Um es kurz zu halten: Ich würde eine Auslagerung der vorherigen Generationen ebenfalls unterstützen, da es für mich utopisch klingt anzunehmen, dass wir auf ewig alle Attacken jeglicher Generationen im Pokémon-Artikel bereitstellen könnten. ~ Taisuke Diskussion 14:59, 31. Mai 2019 (CEST)
Ich habe nun mal im Testwiki was gebastelt, zu sehen bei test:Bisasam und test:Silvarro. Im Grunde bleibt Vorlage:Atk-Table identisch, außer das die Vorlage nun nicht mehr alle Generationen unterstützt sondern nur noch eine, die via Parameter gesetzt wird und dazu führt, das zB die Kategorie nicht immer angezeigt wird. Das sonstige Verhalten mit Vorlage:AtkRow bleibt identisch. Was ich jetzt mal gebastelt hab war ein sogenannter flex container, der dazu führt, dass die einzelnen Tabellen dynamisch positioniert werden. Jede Tabelle hat dazu einen umschließendes div, in welchem auch die Überschrift und eventuelle Hinweise landen und der eine gewünschte Breite von 300px hat, sodass im Idealfall drei Tabellen nebeneinander passen. Gewünscht heißt hier jedoch, dass der Browser die Elemente auch anpassen kann, wenn Texte zu lang sind oder aus sonstigen Gründen das nicht passt und automatisch weitere Tabellen in die nächste Zeile verschiebt. Hierdurch wird vermieden, dass zu viele Tabellen in einer Zeile landen, gleichzeitig wird jedoch auch whitespace vermieden und die Artikel werden (hoffentlich) nicht überlang. Für die Einbindung in die Pokémon-Artikel hab ich jetzt erstmal die Vorlage test:Vorlage:Attacken geschrieben, die kann man jedoch vermutlich auch anders lösen. Da die Attacken je nach Artikel unterschiedliche Hierachieebenen besitzen kann das "Basislevel" über eine Variable gesteuert werden, aktuell ist diese über die Attacken-Vorlage automatisiert. Was mir noch nicht ganz gefällt sind die Zusatzspiele (LGPE bei Bisasam, Überschrift ist natürlich anzupassen), hier müsste man nochmal was schöneres überlegen. Die Geschichte mit dem Togglen der vorherigen Generation hatte ich kurz probiert, scheitert aktuell jedoch an zwei getroffenen Designprinzipien: 1. sind unsere Toggler alle nicht wirklich mit Containern kompatibel, die einen eigenen display wert nutzen (flex in meinem Fall), hier müsste also technisch erstmal jemand ran (oder man nutzt unschöne Lösungen mit zusätzlichen Container außen rum, die dann aber auch wieder zu komischen Dingen führen können) und 2. sind die Überschriften dann komplett durcheinander (ausgeblendete Überschriften werden trotzdem dem Inhaltsverzeichnis hinzugefügt, ergo gibts die Überschriften sofort doppelt). Ich denke jedoch, dass man auch ohne die vorige Generation leben könnte. Ansonsten ist denke ich nicht viel zu den Artikeln zu sagen, die Tabellen sind wie gesagt weiter die bekannten. Dementsprechend ändert sich (wie Robbi auch schon festgestellt hat) die Parserausnutzung auch nicht allzu drastisch, es sieht nur etwas aufgeräumter aus. Jones Albtraum? 16:30, 31. Mai 2019 (CEST)
Nachtrag: Auch wenn die grundsätzliche Meinung hier ziemlich einheitlich ist lasse ich shadow noch etwas Zeit zu reagieren bevor ich eine Abstimmung starte. Jones Albtraum? 16:31, 31. Mai 2019 (CEST)
Danke für den Entwurf. Wo wir aber einmal an das Auslagern denken hätte ich die Frage ob man nicht auch gleich die vorhandenen Informationen erweitert. Ich denke da so an Gen 3,4,6 mit den Wettbewerbssachen oder zu welcher Z-Attacke inkl. Stärke/Kategorie sich die Attacken in SMUSUM aufstufen lassen. Was auch so die Frage wäre ob es notwendig ist die Väter bzw. Eltern in der Unterseite zu toggln oder direkt anzuzeigen vorzugsweise mit dem icon-Parser. Das nebeneinander wirkt soweit bei den Pokémon okay. Allerdings denke ich bei Pokémon mit kurzem Move-Set und langer TM-Liste wirst du zwischen den Tabellen auch viel unschönen Whitespace haben. z.B. Mew (auch wenn dort aktuell keine TMs angezeigt werden, aber da gibts auch noch andere Kandidaten die mir gerade nicht einfallen) Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 17:03, 31. Mai 2019 (CEST)