ポケモンスリープ攻略・検証Wiki
編集相談板 / 340
1411
コメント
views
1
フォロー
1
枠なしのアイコンで上書きしました。
埋め込んでいるページには影響が出ていないようです。
アイコンを使った表を作ってみました。個人的には見やすいと思います。
フィールド名が右端だと分かりにくいのでランクの左側に列を作りました。
4桁の番号、色などいろいろ反映していないですが、
ポケモン名6文字対応/カッコ全角5文字対応、nobrありなし、アコーディオン（インデントあり）などの比較を作りました。
サンドボックス/出現ポケモン一覧2
そういえばフィールド名を入れたら、検証：料理の大成功の時と同じくAutoAliasNameですごく重くなるので、対策が必要です。
色々おかしかったのでこちらで修正しておきました。
重くなりそうだったので、ワカクサ本島の「ワカクサ」と「本島」の間に空白文字を挟んでいます。
フィールドの列がスマホで見ると改行されてしまっているのが気になるところですが、ラピスラズリ湖畔のことを考えるとフルネームで書く限りは対応が難しそうです。
>> 340
ワカクサ本島×300、その他×150で検証しましたが、そこまで差がありませんでした。
しかし全部にリンクが付くのはいやですし、幅を取られるのでやはり略称を使うべきだと思います。
ゲゲッ、AutoAliasNameの存在があったのか…
今は大丈夫でも、料理の時みたいに後で別の問題が発覚すると嫌ですし
いちいち空白文字を挟むのもメンテナンス性が気になりますし、そう考えると略称を使わざるを得ない気がします
略称にしたものも比較用に作りました。
一応イシツブテの行をラピスラズリにしてみました
個人的にはこの方が良さそうな気がします
たぶん最終的には「フィールド」の横にソートボタンが追加されると思いますが、
それを考えるとフィールド名のマスは6文字までなら横に伸びることはない、という解釈で良いですかね
もちろんできれば正式名称を使いたいのは山々ですけど、これでも十分に通じますし、文字数を削る分にはメンテナンス性も問題ないかと
「ラピスラズリ湖畔」だと8文字も横幅を取られてしまいますから
全フィールド分作っておきました。
あと、本家の出現ポケモン一覧の表を編集した際に問題が生じないか確認するためにトープ洞窟だけ新しい案の表に差し替えてみています。問題なさそうなので戻しました。
私はこれで良いと思います。
>> 377
デザインとは関係のない話ですみません。
この「出現ポケモン一覧（略称版）」ですが、HTMLデータ量が多いことが気になります。
現行の「出現ポケモン一覧」の時点でも、ポケモン数が増えてきたためか1MBをやや超過しており、警告文（『変換後の HTML が 1MB を超えています。通信量節約のためページ構成の見直しをお願い致します。』）が出ています。
略称版ではさらにデータ量が増えています。
今後もポケモンとフィールドは増えるため、このまま1ページに全てまとめ続けることは厳しそうです。
いい機会ですので、新しい表を実際に運用する際には、ページを分割することを提案します。
（たとえばフィールドごとに分けるなど）
軽量版作ってみましたが、まだ重いですね。
>> 386
言われてみればその通りですね。
ポケモン側からの引用を考えると睡眠タイプ別もあり…なのですが、睡眠タイプ別ですと、今度はフィールドでの引用ができなくなる気がします。
現状で、各フィールドページのポケモン一覧は、たとえばワカクサの場合、
出現ポケモン一覧（元データ）→出現ポケモン一覧/フィールド別/ワカクサ本島→ワカクサ本島
という引用関係になっています。
ともあれ私が言いたいことは、「このまま全てのデータを1ページ（出現ポケモン一覧）に収め続けることは、そのうち限界が来ますよ（なんなら現状が既に限界ですよ）」ということです。これは処理時間だけの問題ではなく、HTMLデータ量の問題であり、プラグインなどの工夫で軽減できるとはいえ、ポケモンとフィールドの数（ページの根幹のデータそのもの）が増えればそれに応じて必ず増えるものです。
ただし、どのように分割するかなどは、もっとよい案があるならそれでよいです。
現行の出現ポケモン一覧もそうですが、基本的にこれらのページを直接閲覧することはないはずです。
ページを分割すると管理や引用が難しくなりそうです。
>> 388
「直接閲覧しない」はその通りで、アクセスが極端に少ないならいいよねって、負荷の観点から言えばそうなんですが…
ある日突然行数オーバー（または容量オーバー）になって新ポケモンを追記できません！という日は必ず来ます。そうなってから対処してもいいんですが、その際には一覧表を引用しているあらゆるページの引用部分に対し、書き換えが必要になると予想されること、そして今ちょうどポケモンページのフォーマットに手を入れている最中なので、やるなら今では？というのが私の考えでした。
「実際に容量オーバーで追記不能になってから対処すればよい」が多数派なら、別にそれでもいいです。
元のデータ構造はフィールドごとなので、本来なら分割はフィールド別一択ですが、
複数フィールドの引用（たとえばポケモン詳細）の際、フィールドの数だけincludexが必要なので、
フィールドが増えると編集が必要になってしまいます。
やはり睡眠タイプごとになりますかね…
とはいえ3分割しても相当なデータ量のはずなので、もう少し細かく分ける必要があるかと思います。
データ量の問題なら、極端な話独自のプラグインを作るしかないかと思います。1.出現ポケモン一覧側（
:config/の下層になるかもしれない）はテキストベースの最小限の内容（ここではヘッダー行を省略）
2.引用の際は独自のプラグインを使用
3.整形されたテーブルが出力される
（ここではヘッダー行を省略）
>> 389
あ、すみません、ソースを読み違えていたようです。
ワカクサ本島のページでは出現ポケモン一覧にリンクを貼っているだけで引用はしていませんでしたね。
ところで何でこんなに容量が大きくなってしまったんでしょう？
画像データが原因ですかね？
文字データだけにすれば容量は抑えられると思いますが
同じことが寝顔図鑑一覧の方でも言えるかと思いましたが、あちらはまだ500kBくらいなんですね。
複数の睡眠タイプを持つポケモンが追加されたりすると面倒くさいですが、当分は起こらないでしょうし睡眠タイプでページを分割するのが妥当でしょうね。
流石にもう面倒くさいのでこの仕事は他の誰かにパスします笑
>> 395
作れると勝手に思っていましたが、wikiwikiは自作プラグインを利用できない仕様でした…
自分で言い出しておいてなんですが、これ以上は別件として別の木でやったほうがいいですね。
もうちょっと自分の考えを整理してから、また提案したいと思います。
結局この議論が収束しないとポケモンページのフォーマットも完成しないので、優先度高めな議題ではあります。
あと、新フィールド実装を見越してページ分割するなら「限定」の列は管理が難しくなるので削除しても良い気がします。
遅レスで恐縮ですが自分も出現ポケモン一覧表のデザインは>> 377のものが良いと思います。ランクのアイコンがわかりやすいです。
サンドボックスではランクのアイコン画像にnolinkのオプションがついておらずリンク画像になっていたようなので、nolinkにすれば少しマシになるかも…？と思い軽量版のページに勝手ながらnolinkのオプションを追加してみたところ、約560ms→約470msに軽減されて右上のメーターが赤からオレンジになりました。
しかしこの微量な軽減は1ページあたりの容量オーバーの問題とは別の話ですので、自分もデータベースのページ分割は必要だと思います。
(噂では1600行or約15万文字、ファイルシステムのデータ量350KBくらいが限界らしいです)