FrontPage

  • 基礎表現ルールページがなんかTipsの基礎と統合すべきかなー、旧里々Wikiもメニューがわかり辛かった(現状でも改善されてますが) -- HiLa? 2011-01-13 (木) 09:35:32
  • 紛らわしくならないようにTIPSページにも同リンクを揃えて張ってみました。 -- eyelaser? 2011-01-13 (木) 22:44:08
  • ご要望がありましたので、WikiName の自動リンクを無効にしました。 -- ナルサワ? 2011-09-20 (火) 12:00:10
  • 「独自イベント」項の「*○△なでなで」についてですが、里々バージョンMc148-1の場合「*○△なでられ」でないと動作しないような気がします。 -- 2011-12-26 (月) 00:19:52
  • なでなでの件修正しました -- 2011-12-26 (月) 09:15:53
  • ページ削除できないな・・・リンクもないしただの荒らし? -- 2012-01-27 (金) 08:25:54
  • 栞としての里々ページはむしろ"上級者向け"じゃない?ファイル構成・特殊記号を"資料"にしたのは良いけど読ませる順番を意識したのかと思ってた -- 2012-07-11 (水) 17:59:13
  • 他の栞からの乗り換えや伺かの仕様から入った「初心者」を上級者扱いするかどうかは頭の痛いところです。ただ、確かに初心者向けメニューからは独立させた方がいいですね -- 2012-07-11 (水) 18:54:04
  • なんか編集できない、うちの環境だけかなぁ -- 2015-05-02 (土) 19:15:13
  • 編集できました、てへぺろ -- 2015-05-03 (日) 20:43:33
  • デフォルトサーフェスの説明の所に赤字で「サーフェス加算値と同時使用する場合、必ずサーフェス加算値より後に書いてください。」とありますが、逆ではないでしょうか。そのとおりに書くとデフォルトのサーフェスだけ加算値を無視するようです。 -- 2015-05-13 (水) 21:52:35
  • サーフェス加算値は(数字)でのサーフェス変更に対して効果のあるものなので、そもそもデフォルトサーフェスには影響しません。ただ、現行ではサーフェス加算値が設定されると同じ値がデフォルトサーフェスにも代入される仕様になっているので、両方を同時に用いる場合はサーフェス加算値を先に書く必要があります。 -- 2015-05-15 (金) 21:20:51
  • 横からですが、同じ値が代入される→両方に別々の値を入れたい場合はサーフェス加算値を先にして両方書き、同じ値にしたい場合はサーフェス加算値だけを書けばいい、ということですか -- 2015-05-29 (金) 00:25:17
  • vncallって定数渡す時とか定数と同じ変数名あったらどうなるんだろう -- 2015-06-22 (月) 06:33:18
  • カッコの中の言葉を取り出すのと同じ優先順位です。なので里々的には、しないでね、という感じ。 -- ななっち? 2015-06-22 (月) 07:56:12
  • サーフェスがうまく変化しない。 -- 一夜? 2015-11-23 (月) 11:13:15
  • サーフェスまわりは里々ではないので…別の所でもっと詳しく聞いた方が -- 2015-11-27 (金) 10:33:33
  • 伺的フォーラム http://www.ghost.sakura.tv/fluxbb/ おすすめしときますね -- 2015-11-27 (金) 13:29:00
  • 「初めての人へ」の「ページ案内」が、回りくどくてわかりづらいです。 -- 2016-06-02 (木) 02:03:10
  • ↑どの情報をお探しで? -- 2016-06-02 (木) 06:57:39
  • 独自にですが修正してみました -- 2016-06-02 (木) 07:42:47
  • 「特殊変数」の「$教わること」の項を始めて読んだ時、teachboxが何なのかわからなかったため、軽い説明を入れたり、UkadocのSHIORI Eventリストにリンクをはるなどしてくださるといいなと思います -- 2016-06-02 (木) 12:12:24
  • 「$教わること」加筆しました。ついでに、OnTeachのサンプルが無かったので追加しました。「初めての人へ」は↑↑の方のものを基準に、外部サイトなどを追加しました。 -- 2016-06-02 (木) 20:10:12
  • 引き続き、分かりづらい部分や解説が必要な部分を募集しています。いくつかのページは情報が古くなってしまっていますが、その全てに対応する時間的な余裕がないため、要望のあった部分を優先して書いています。 -- 2016-06-03 (金) 07:16:41
  • あのう・・・里々を使おうと最新版をダウンロードしたのですが、どうしても、ssuとsaoriフォルダ内部がノートンにウィルス扱いされて削除されてしまいます。一つ前も駄目でした。ノートンに例外指示を出してもいいのですが、いずれにせよ、ゴーストに入れた時、ゴースト利用者も同じ問題に当たるかと思い、ためらっています -- さんり? 2016-07-19 (火) 08:31:11
  • 訂正。ssu.dllとsatori.dllが削除されます。155-2版は、ssuはOKで、satoriだけが削除されました。 -- さんり? 2016-07-19 (火) 08:36:51
  • 伺かに関連した様々なファイルはしばしば誤検出されます(以前は良かったのに定義の更新でまた誤検出されたりといった事が起きています)。これは避けようがありませんし、例外として登録する以外にないかと思われます。 -- 2016-07-20 (水) 17:20:03
  • そうですか・・・分かりました。ありがとうございました -- さんり? 2016-07-21 (木) 20:56:29
  • 管理者様へ。申し訳ないのですが、「\0と\1を一体化させる」というページを作ったところ、編集が出来なくなってしまいました。お手数ですが、削除をお願いいたします。 -- 2016-08-16 (火) 20:38:24
  • 削除しました(履歴には残っていますがページ自体は削除成功しています -- 2016-08-17 (水) 05:56:03
  • ありがとうございます。お手間をお掛けして申し訳ないです。 -- 2016-08-17 (水) 17:57:43
  • 里々本体がssuを吸収したこともあり、「内部関数」と「外部関数/ssu」と分かれているのは現状ただ不便なだけである気がします。例えば、ifやcompareが外部関数で、whenやequalが内部関数であり、似た機能なのに違うページにあることは分かりづらいと感じます。「困った時の対処法」でも里々最新への入れ替えを推奨していますし、内部関数とssu.dllを区別する必要はないと感じます。合体して1つのページにした方が良いと思うのですが(ssu関数へのwiki内リンクは徐々に張り替えていくとして)、問題はありますか?(1ページの容量制限など) -- 2017-03-09 (木) 10:52:44
  • 追記:古い里々のゴーストを改造したいといったユーザへの対応には、各々の関数説明に、元ssu関数であることを示す文言をつけるなどすれば良いと思います。 -- 2017-03-09 (木) 10:58:45
  • 問題ありません -- 2017-03-09 (木) 21:20:33
  • 「内部関数」のページに「外部関数/ssu」の内容を全てまとめたため、「外部関数/ssu」は不要となりました。しかし、外部ページからリンクされている例があり、デッドリンクを回避するためにページ自体は残しておいてください。「外部関数/ssu」の内容は、「内部関数」へのリンクページにしてあります。 -- 2017-03-18 (土) 14:41:13
  • 新たに追加された「ネットワーク更新に対応する」の記事を元々存在していた「ネットワーク更新」の記事に統合しました。またメニューバーからは削除しています。これはゴースト制作の重要点を逐次メニューバーに追加すると膨大な量になるためです。これらは「TIPS総合」内の「基礎系ページ」サブカテゴリに追加するようにして下さい。 -- 2017-05-15 (月) 06:22:26
  • 了解しました。「初めての人へ」にある「編集される方へ」の項は里々ユーザに向けたものではないため、独立したページにしてメニューバーに追加するのがベターと感じます。また、「初めての人へ」内に「派生版の里々」「里々CK」についての説明をお願いします。内容を理解していないため、これらが伺か本体仕様(=SSP仕様)である理由が分かりません。 -- 2017-05-15 (月) 23:39:21
  • ひとまず暫定処置として名称をwiki利用ガイドに変更し、初めての方と編集される方を両立する形にしました。独立したページにするかどうかは引き続き検討中です。里々CKについては保留・様子見でしたが(作者が不明で連絡先がない事と、整備班ver里々とは少々離れたマニュアルですので管理しきれない理由から)、TIPS総合への移動という形を採りました。 -- 2017-05-16 (火) 14:59:17
  • ありがとうございます。編集お疲れ様です。現状、ページ名・内容ともに里々ユーザと編集者で明確に分離されているため、独立ページは必要なくなったように思います。里々CKはこのwikiに載せるなら解説およびサンプルスクリプトなどが必要なのでしょうが、整備班verと両立すると混乱の元にもなりえるので扱いが難しいですね。 -- 2017-05-16 (火) 20:08:07
  • 里々CKについてですが、作者の方と連絡がつき、懸念だった作者名やサポート先など重要な連絡先が明記されましたので復旧します。MenuBarの編集はお控え下さい。 -- 2017-05-21 (日) 18:00:40
  • 今後、編集方針において差異があるとよくないため、1編集者としての編集方針を書いておきます(と言っても、ここ数年では自分以外に継続的に編集してくれる編集者はほぼいないのですが……)。構文解説やスクリプト解説においては砕けた口調の文体は読む限りでは理解の妨げにしかなっていないため、丁寧語で書いています。前身のような、里々に関するネタを語り合う場所でなく、ゴースト作成における資料となることを目指しています。このwikiで基本的なゴースト作成が全て完結することを目指しており、外部リンクは全てリンク先を確認し、リンク切れや情報が適しているかなどの判断をしました。一度書かれた記事が改定されることが少ないため、デッドリンクがそのままとなっている例がいくつか見られました。そのような点から、解説では基本的な事象は全てwiki内に書き、その上で参考としてリンクを追加する形をとっています。例外はSSP配布サイトなどアクセスできなくなると伺か界隈が消失するサイト群です。整備班にあるものがその最たるもので、存在することを前提としてリンクを貼っています。(ゴースト配布系自動化システムなど) -- 2017-05-28 (日) 10:47:17
  • メニューバーは、重要項目であっても乱立を防ぐために追加不可とのことですが、このwikiでは扱わないはずの里々CKがメニューバーに追加されたことは編集方針の揺らぎを感じます。出来ることが増える里々CKは可能性の高いSHIORIではありますが、整備班verを基本解説としている以上、始めて見る方には混乱を与えます。TIPSと関連リンク内の項目に留めるべきではないでしょうか。 -- 2017-05-28 (日) 10:47:28
  • ここ最近(数年?)の編集方針について意見させてください。里々の機能について所々でみられた「このバージョンから実装」の表記がなくなったことが残念に感じています。 里々CKのような派生版の里々から見た場合にどのバージョンの里々(整備班ver)をベースに作っているかで整備班verのどの機能が使えるかが以前は里々wikiである程度確認できる状態でありましたが、今はリンクされているgithubの更新履歴にまで行かなければ確認できない状態です。 里々(整備班verも含め)が誰でも改造することができることを表明している一方で、その公式的な解説の里々wikiでそれに対して配慮のあったバージョン表記の削除が行われたことがありましたので 基本方針となる整備班verが表明する改造可能という点について里々wikiがそれに対して排外的になり・妨げ・隠すことが無いようにしてほしいです。 -- 2017-05-28 (日) 11:59:01
  • 上記の編集者ですが、なるほど確かにありそうです。ただ、整備班verでは「最新版を使う」ことを前提としているため、バージョン表記を省きました。派生版里々の中に、それぞれの関数・変数が追加されたバージョンをまとめたページを作る、というのはどうでしょうか? -- 2017-05-28 (日) 13:27:14
  • 追記:里々wikiは公式ではなく、あくまで個人サイトの1つであり、「本家及び整備班verの里々について勝手にまとめたページ」であったはずです。公式として運営しているのか否かは管理人さんの判断を待ちましょう。 -- 2017-05-28 (日) 13:30:54
  • 派生版の里々の内部に、たたき台としてかつてwiki内記述されていたバージョン情報を全て記述しました。 -- 2017-05-28 (日) 14:19:31
  • 公式というのはUkadocあたりと混同していました。失礼しました。ただ里々のことならほぼここしかない状態ではあるので先述のご配慮をお願いしたいというものです。バージョン情報の記載についてはありがとうございました。 -- 2017-05-28 (日) 18:02:40
  • 1.まず公式かどうかの質問ですが、このwikiは里々公式wikiではありません(前身も散逸する「里々のTipsの集積」がメインで、本wikiもその側面を引き継いでいます)。 2.整備班verのバージョン表記について、重要度は高くないと考えます。元の里々も含め初心者向けの側面の強いwikiであるため、バージョン毎の摺り合わせの必要性が薄い事、そして困ったときの対処法にあるように「とりあえず最新版を使う」事を推奨しているからです。 3.バージョンをまとめたページについては是です。バージョンアップで新たに追加されたものがすぐ分かるのは助けになると思います。もちろん情報としては整備班本家を参照した方が正確なので、注意書きは必要と思いますが…。 4.派生版里々については改めて協議していますが、「左メニューにあってもいいと考えるが、本wikiに置く内容としては紹介や大まかな情報に留め、公式としての配布や文書を置かれるのは否」に落ち着きそうです。 -- 管理? 2017-05-28 (日) 22:35:26
  • 里々CKの記事作成を行った者です。別所で本wikiの管理人の方にお話しを伺い里々CKのような派生系の里々を本wikiで詳しく扱うべきでないとのご見解をいただきましたので、近いうちに現在置いてある里々CKの記事を引き上げ、別途里々CKの特徴点のみもしくは本wikiのように里々全般の解説をする場所を用意するなどした上で、里々CKに関する記述を移転する対応を行う予定です。 -- 2017-05-29 (月) 20:25:22
  • できればなぜそのような議論になったのかログをください。本体をここに置き、里々の関数の実装バージョンのページを作る話だったような気がするのですが、飛躍しすぎてよく分かりません。 -- 2017-05-31 (水) 19:28:43
  • そのまま載せるのは控えさせて頂きますが、要約を記載します。まず最初に里々CKに関する懸念がこの連絡板に書き込まれていましたので管理人の方に連絡を取り「メニューバーの方針と異なる変更」「里々CKのサポート先が不明確」という2点懸念が有ると伺いましたので、記事の修正等を行いました。次に↑x3の投稿で「派生版里々については大まかな情報について留めるべき」とありましたので先の修正で問題なかったのでは、とお尋ねしました。「反対意見等あり再調整した結果投稿のとおりになった」「里々CKに関する記述が公式でも非公式でも『何故里々wikiにあるのか?』という点が解消できていない」との見解を頂き、里々CKからの意見として「1サイトで情報の参照が完結できるメリットが大きい」という点を申し上げた所、判断を下すならばNGとのことでした。大まかな流れは(私の理解が正しいのならば)この通りです。 -- 2017-05-31 (水) 21:13:47
  • このご見解を頂いてからの対応として、「里々CKの詳細を公式・非公式に関わらず掲載を諦める」「最低でも今までの記載をどこかに移転、最高なら整備班verに対する本wikiのような、派生版里々を含めての里々全般の情報をまとめるところを用意する」とする予定でいます。バージョンの違いをまとめてくださった方、ご迷惑をおかけいたしました。ありがとうございました。 -- 2017-05-31 (水) 21:18:11
  • 話を聞く限り、さとりすと等の外部ツールも記載されていることから、ここに情報があることに問題があるとは思えません。配布ページや解説ページを切り分けて里々wikiには紹介ページを用意して相互にリンクするという形式で良いのではないでしょうか。里々の基本文法などがここにまとまっている状態で、別の情報源を更に用意するのは情報散逸に見えます。リンクにはsaoriの紹介ページもあり、今ひとつ理由が見えてきません。まとめたバージョン情報が役立たないのは残念ですが、必要か否かもわからなくなってしまったため、コメントアウトして見えないようにして残しておくことにします。 -- 2017-05-31 (水) 22:02:55
  • ご提案は仰る通りです。別途のまとめについてはやってみたい気持ちからとりあえずやってみようというもので、若干里々wikiと意見が異なることから自分なりに非公式にまとめてみたいのです。結果うまくできなければご提案のようにさせていただきますね。 -- 2017-05-31 (水) 22:34:12
  • それは自由だと思うので意見は控えますが、そもそもリンクを貼ることや紹介さえしないことには問題があるのでしょうか?言葉を借りるなら、里々wikiが「議論に対して排外的になり・妨げ・隠すことが無いようにしてほしい」のです。 -- 2017-06-01 (木) 18:42:18
  • 特に問題はありませんし、そのように排外的にするつもりもないです、管理人さんがおっしゃるように紹介に留める、というものまで排除するつもりはなく、仕様の説明等詳細に書いた部分についてはこのwikiにそぐわないものですから移転します、というつもりでした。言葉足らずであればすみません。 -- 2017-06-01 (木) 19:05:44
  • 少々すれ違いがあるようです。こちらから提案や資料の提供をしたことで分かると思いますが、どういった方向性を定めるのか話に参加したいと考えていたのです。それに対して「個人的に管理人と話をして決めました」というのは、こちらの意見が完全に無視された形となり、あまり愉快なものではありません。単なる言葉足らずであると認識しているのであれば間違いです。しかし、決まったことを覆すことはしたくなかったため、せめて議論の経過だけでも知りたかったので訪ねたという次第です。恐らくこれ以上は感情的で無意味なレスとなってしまうでしょうから、返事が必要なもの以外は最小限にします。 -- 2017-06-01 (木) 19:36:32
  • 察せませんでしたのでごめんなさい。先ほどの書き込みで言えば紹介等を載せることを希望されていて、そうであれば対応しますよ、とのつもりでいました。さて、管理人さんとの間の話ですが主な内容としては方針を伺ってそれに従ったというものでどんな方針にするか具体的に話あったつもりではありませんでした。これに参加したかったということであれば謝るほかありませんが、里々ckの解説を載せることについての方針が変わったことについて話に参加したかったのは同感です。 -- 2017-06-01 (木) 20:29:37
  • TIPSに埋もれていた、里々に付属するログビューア「れしば」についてまとめられていた「れしばの使い方」をメニューバーに追加しました。 -- 管理? 2017-06-04 (日) 21:14:00
  • 2017.3.21 版の「SWポストと狛犬」内のdic09_ExEvent.txt内で「_」を使った選択肢の中にタブを2つ続けている箇所がありますが、こちらは記述上のミスでしょうか? -- 2017-06-06 (火) 23:05:40
  • これはRポスト時代からある古いスクリプトを残しておいたものなので、詳細は不明ですね……。管理人さんに聞いた方が早いかもしれません。 -- 2017-06-07 (水) 20:43:40
  • 詳細が分かりました。指摘されているイベントに限って、「ジャンプ先のない選択肢」を用意する必要があります(昔からの仕様)。そのために、タブを2つ続けることで、里々のジャンプ先を自動補完する機能を無効にしていると考えられます。里々スクリプトでは、あの書き方をしないとヘッドラインセンスがうまく動きません。 -- 2017-06-09 (金) 21:24:26
  • ありがとうございます。「ジャンプ先のない選択肢」が必要だということはわかりました。しかしこちらで試した所では「読み上げフェーズFirst」のタブ2つのジャンプ先のない選択肢をタブ1つにしても正常にジャンプ先のない選択肢が出力され動作しました。里々の書き方的にもタブ1つのほうが正しいように思います。また、ジャンプ先のない選択肢以外にも付近の選択肢にはタブが2つ使われている部分がありますがこちらはそもそもジャンプ先つきの選択肢なのと、1つにしても正常に動作しました。もしかしたらどこかで修正されたのかもしれませんが、この動きをみるに今現在の里々ではタブ2つは意味のない記述もしくは間違った記述になるのでしょうか…。古いままとのことで間違いかの真偽はわかりませんが宜しければ説明ができる方向で修正を見当して頂けると有り難いな、と思いました。 -- 2017-06-09 (金) 23:51:37
  • 確かにこれは分かりづらいですね……。検討したいところですが、Rポストと狛犬との互換部分でもあるため、悩んでいます。最小構成のRポストと狛犬、解説に特化したSWポストと狛犬とこれらは傾向の異なる2つのサンプルとしているため、共通部分は同じようにしておきたいのです。さらにSSPの動作が怪しい部分もあり、修正するにしてもSSPでの動作が確定するまでは動けない状態にあります。申し訳ないですがしばらくお待ちください……。文法的な部分についてですが、もう少し動作確認を取ってみた結果、里々の選択肢にかぎらず、条件式、採用条件などでは、半角スペースやタブ文字は無視されます。タブが1個あることが条件で、その後ろのタブなどを無視するため、文法上は正しいことになります。(when,【改行】【タブ】条件式,【改行】【タブ】結果【改行】)のような書き方が出来るのはこのためで、「>トーク名【タブ】【タブ】【タブ】1」という記述も正しく動作してジャンプします。指摘の「_トーク先【タブ】【タブ】条件式」も正しく動きます。件の「_続きを読む【タブ】【タブ】」という部分は、実際にはタブが何個であっても変わりません。1個でも3個でも「ジャンプ先のない選択肢」として動作します。 -- 編集? 2017-06-10 (土) 09:51:22
  • なるほど。では今は旧ポストの互換でそうしているのであって、実際タブ1個でも2個でも動くので、2個である必要はない&何個でもいい、ということですね。SSPの動作が怪しいとも書いてありますがその点については選択肢部分のタブの数によって里々の出力に違いは無いため、タブが1個以上使われることが正しいか否かについてはSSPは関係しない認識でいます。 -- 2017-06-10 (土) 18:25:40
  • その通りです。サンプルゴーストとして分かりやすさを重視するなら1個に統一した方が良いと思っています。SSP云々は言葉足らずでした。「選択肢のID部分が空欄なら続きを通知する」という動作はmateria(初代ベースウェア)からあるものですが、SSPでは現状動作しません。今後、互換がどうなるのか、もっと分かりやすい記述法が追加されるのか、それによってスクリプトの記述が変わります。現状、SWポストと狛犬に加え、自分が書いている全てのページはベースウェアがSSPであることを前提として記述していることもあり、その点no。 -- 2017-06-11 (日) 12:14:50
  • の仕様が確定するまで保留したい、といったところです。 -- 2017-06-11 (日) 12:15:29
  • 前回の方針の話から2ヶ月近くが経ったので、そろそろ編集方針をまとめていただきたいです。そうでないと編集作業においても何を指針として良いのかが分かりません。とりあえず、「ネットワーク更新」をメニューに追加するのはNG、「れしばの使い方」はOK、といったあたりの線引がよく分かりません。 -- 2017-07-28 (金) 23:49:14
  • また、「ネットワーク更新自体に対応する方法」と「ネットワーク更新でトークする方法」は似た内容として統合されましたが、「名前を覚えさせる」「ユーザ名に敬称を付ける」のような似た内容のページは統合されずに残っています。これらの統合ルールも明確にしていただきたいです。 -- 2017-07-29 (土) 15:29:22
  • 現在、管理人の方の動きが2ヶ月以上無く、「編集される方へ」も未完成の状態のままの状態です。忙しいなどで編集作業が不能な状態にあるとして、復帰までの暫定ルールを設けて編集作業を続けます。 -- 2017-08-05 (土) 16:43:08
  • 里々wiki利用ガイドに追記しました。矛盾点がいくつかあるため、あとは編集者が個々で判断するしかないでしょう。 -- 2017-08-05 (土) 17:02:46
  • 「ネットワーク更新」はベースウェアから発信されるイベントで、「れしば」は里々に同梱されたツールですのでそもそも種別が違います。似た内容のページの統廃合は編集者が統合した方がいいと判断すれば統合、いやいや分離した方が分かりやすいだろ、と思ったら分離。意見が割れたら議論。そのぐらいでいいかと。 -- 2017-08-11 (金) 07:43:10
  • ベースウェアから発信されるイベントに関しては、「プロパティシステム」がメニューバーにはありますね。種別が同じでもOK/NGを個々に判定するルールがあるようですが、編集者視点からでは分からない状態にあります。 -- 2017-08-11 (金) 12:23:34
  • プロパティシステムはさくらスクリプトから環境変数まで跨って策定されたもので、しかもその由来もCROWの仕様書という特殊なものだと思うのですが。 -- 2017-08-11 (金) 20:51:44
  • つまり、里々と関係はないがCROW由来だからメニューバーにあって良い、ということになるのでしょうか。編集する上で何のルールが必要なのかは「里々wiki利用ガイド」の下の方に要点をまとめていますので、目を通していただけると幸いです。 -- 2017-08-11 (金) 23:15:16
  • 今必要なのは由来ではないです。管理人からNGを出された項目があるが、方針に不明瞭な部分があるので、NG範囲をしっかり定めて欲しい」 -- 2017-08-11 (金) 23:18:01
  • という点です。 -- 2017-08-11 (金) 23:19:25
  • ガイドに書かれた要点と仰られたものはどこが要点なのかさっぱり分かりません。貴方が知りたいと思しき事柄も散逸し、かつ複数の項に跨っていて複雑怪奇です。質問は簡潔に。そうできないのであれば一つずつ。今こちらから言えるのは、wikiは例えばメニューバーに関して新しく何かを追加する、或いはこれは消してもいいのではないか…という「提案」でフレキシブルに変わっていくという事だけです。その結果仕方なく認められなかったものを「NG範囲」と称するのは自由ですが、現状それらをルール化に繋げられるほど議題や提案の数がありません。 -- 2017-08-12 (土) 00:11:32
  • なるほど。ひとまず、短く何が必要なのかを「里々wiki利用ガイド」の下部に追加しました。「提案」で変わっていくという点も納得しました。「ネットワーク更新」や「れしばの使い方」については、どのような「提案」があったのでしょうか?wiki外の話し合いは見えないので、要点をまとめてくださると幸いです。 -- 2017-08-12 (土) 11:21:27
  • 提案:「派生版の里々」「れしばの使い方」は現状のメニューバーの5分類ではどこにも当てはまらないように感じます。6個目に「制作ツール」などの項目を作り、有用性のあるツール等をまとめていくというのはどうでしょうか? -- 2017-08-12 (土) 11:32:44
  • 良いと思います。 -- 2017-08-12 (土) 12:21:31
  • とりあえず、1つだけ確認をしたい部分があります。提案があり、それを認めるという議論はどこで行われているのでしょうか?少なくとも、この伝言板ではないようです。上記で上げた2項目はここには提案も議論も見当たりません。必要だと思って作ったものの、見えない部分での議論で不要と判断されたとなると、どのように編集作業をしてよいのか分からないのです。 -- 2017-08-13 (日) 07:01:54
  • 提案がないものは独断です。そこに「待った、それよりこっちの方が良くない?」となれば再考。ネットワーク更新・れしばの使い方・プロパティシステム、いずれも理由を回答している筈ですが…。しかしそちらからは話が飛躍してNG範囲や編集作業の要求しかなく、結局これらの個別の意見や代案を貰っていないため、「結局これらの位置には現状で問題はない?特に変更する必要もない?」と判断するわけです。 -- 2017-08-13 (日) 17:33:08
  • 恐らくwikiの捉え方に違いがあるのでしょうが、後から上書きされる事が日常茶飯事のwikiで、それが荒らしでない限りは追加や編集作業にいきなりNGルールを課す事は不可能ですし、TIPSを集積するwikiである以上、どのようなものが新規作成されるかさえ分かりません。最初にガイドに記述したルールとて、「お願い」に留める形です。なので、基本的には行われた作業に対して見直しを図っていく事…つまり、貴方がどのような編集も(それが削除やメニューバーの編集であっても)可能とも言えるわけです。そこを悩む必要はありません。行われた編集に対し、管理人含め誰かが「待った」するかどうか。里々CKは待ったがかけられ、管理人としても削除に賛同しました。ネットワーク更新にしろプロパティシステムにしろ、現段階でそこに在るべきだと固執している訳ではなく、単に具体的な異論がないからこのままでいいのでは?となっている単純な話なのです。 -- 2017-08-13 (日) 17:33:19
  • こちらは「判断基準がある」という前提でいたので噛み合わなくなってしまったようです。wikipediaのように厳密な編集ルールがあるものと考えていたため、まずは編集ルールを示して欲しいと書いていました。それぞれの理由についてですが、編集者向けの部分に書いた通り、解釈が難しいものがいくつかあります。例えば、「れしば」に関しては理由が「TIPSに埋もれていた」であり、「TIPSに書くと人目につく」という記述と反していると疑問に感じている、などです。考えを提示してくださって良かったです。以前からどうにも考えが分からないと感じていた部分がありましたが、やっと理解が出来ました。その考え方にそって編集作業を進めます。 -- 2017-08-13 (日) 22:48:14
  • 一応、こちらの編集方針を明記しておきます。「初めてゴーストを作る人に十分な情報を提供すること」という考えで書いています。wikiの記述とサンプルゴーストのみで簡単な機能を作れるくらいの内容を目指しています。初めて作る人がゴースト公開まで持っていけることを基準として書いるため、制作方法だけでなく公開方法も必要だろうとメニューバーに追加しました。それに対して、一歩踏み込んだ制作ツールやデバッグ方法などはまず制作が一段落ついてから必要になるものであり、TIPS総合の下部にあった方が良いだろう、という考えです。 -- 2017-08-13 (日) 22:58:16
  • 里々CKの記事移転から2ヶ月が経過しましたので移転先リンク等以外の記事内容をコメント化という形で削除をおこないました。 -- 2017-08-13 (日) 23:26:53
  • ここは(一応)里々に関するTIPSがメインなので、完全なゴースト制作マニュアルは二の次にしたい気持ちはあります。しかし同時に「ゴースト3分クッキング」などは先人の功績とはいえ現状に合うか若干疑問もありますし、実際補強する為に作成したはずの「少し詳しい調理方法」も情報が足りていない感がありました。とはいえ説明が簡素な事は確実に分かりやすさに繋がります。バランスが難しいですね。或いは「初めてゴーストを作る人に十分な情報を提供すること」を目的としたページを作るのも手だと思います。そのサブカテゴリならば公開方法などのページを随時追加しても更に利便性が良いかと思います。 -- 2017-08-14 (月) 16:42:35
  • 試験的にsandboxの凍結を解除しました。SPAMの標的になった場合は再凍結する予定ですが、主にメニューバーなどで大きな入れ替えがある場合など、表示のイメージの刷り合わせに利用できるかもしれません。 -- 2017-08-14 (月) 17:00:18
  • なるほど、その点でもこちらの編集方針とは噛み合っていない部分があったのですね。3点提案します。イメージ図をsandboxに追加。1.「TIPS総合」と同様、「制作マニュアル」などのハブページを作り、それのみメニューバーに表示するというのはどうでしょうか。メニューバーもすっきりしますし、ハブページを都度編集すれば、情報が必要な人にもわかりやすくなるかと思います。2.リンク集は現状3つありますが、内容としてもそこまで長いわけでもなく、見出しを使って区切って1ページに纏めてよいと考えるのですがどうでしょうか。3.メニューバー「伺か本体関連仕様」カテゴリは現状資料としての側面が強く、恐らく毎回アクセスしたいというユーザは少ないのではないかと考えます。このページもハブページを作って格納するのはどうでしょうか。 -- 2017-08-19 (土) 15:57:27
  • 良いと思います。この案で編集なさって下さい。 -- 2017-08-19 (土) 23:25:42
  • 一部メニューの復旧しました(資料系は畳まれるとワンクリックで飛べないのが不便でした)。特にファイルや記号は当座使わずとも後で参照する機会が割とあります。 -- 2017-10-27 (金) 07:44:54
  • 現在の編集は、「各種関数や特殊変数に関して、例は個別のTIPSページを作って記述する」という方針で行われているのでしょうか。編集方針をあわせたいので、「里々wiki利用ガイド」ページの「編集される方へ」に編集方針を記述していただけると助かります。 -- 2017-10-29 (日) 10:00:06
  • 例の中で「多い・長い・他の要素と絡み合う高度なもの」は肥大化するほど要点や概要が分散してライトユーザーに優しくないです。編集方針に書くとしたら「できるだけ見やすく・分かりやすく」ですかね。複雑化が止むを得ない解説も多いので明確に基準は作りづらいので。 -- 2017-10-29 (日) 11:42:41
  • 他に、今のところざっと見て例示や解説を独立させて表向きの解説を簡略化したいのはバイト値、vncall、ifとwhen(iflistとwhenlist)、forあたりですかね。sprintfは…これも解説自体まるごと独立させていいような気が。call関数を使うぐらいのヘビーユーザーでないと使えません。 -- 2017-10-29 (日) 12:02:51
  • なるほど。そうするとsyncあたりも別にしたいところですね。基本的な関数の使い方を理解していないとそもそも使えないものですし。ifとiflistは、正直メリットが少なすぎるため、いっそ説明なくして(whenを使いましょうくらいに)しまっても良い気がしますがどうでしょうか。 -- 2017-10-29 (日) 14:31:55
  • ifとwhenは使用目的が同じですし項目自体を一緒にしてしまおうと考えています。現状whenを推奨していますし、動作の違いを補足するだけで良いかなと。 -- 2017-10-29 (日) 16:41:46
  • 2つ混ぜてしまうと、説明する量が増えるためにわかりづらくなってしまう気がします。違いを説明するサンプルも割と複雑です。最も簡単なものでも、whenとsetを同時に使います。「他の要素と絡み合う高度なもの」になってしまわないでしょうか。何がベターなのかは難しいですが、1個1個説明があった方が初めての方には親切ではないか、と個人的に思います。と言っても、これは理由に裏付けがない感情的な意見なのでお任せしたいところです。 -- 2017-10-29 (日) 17:23:31
  • 編集に関する齟齬が多いため、そろそろ方針だけでもまとめて共有したいところです。「多い・長い・他の要素と絡み合う高度なもの」に関しても、自分の意識では「簡単な例から始めてステップアップして、その関数で出来る実践的な例を載せる」ことで初めての方の理解を助ける、という感じでした。今回のように目指す方向性があるのであれば、共有しておくことで切り分け作業も今後は発生せず、効率よく情報を充実させられると思います。編集者向けの段にあればなるべくそれに合わせるようにします。 -- 2017-10-29 (日) 17:28:29
  • 個人的にYAYAや華和梨を利用し公式解説サイトと比較した感想として、内部関数などの一覧系ページにおいて初めての方に親切なのは、機能の動作解説を最優したシンプルな例示または個別ページでの解説と考えます。ステップアップを促す目的ならばなおの事、独立したページの方が分量を気にする必要なく、さらには派生的な解説や高度な活用にも言及できるかと思います。ステップアップ自体を促した作りの良さは否定しませんが、それは理解を優先する事が最善と考えるヘビーユーザー寄りの視点であり、手軽にゴーストを作るために里々を求めるユーザーの目的とあまり合致しません。より詳しい解説は、より詳しく知りたくなった時に参照するようになれば良いのです。TIPS総合にある各種ページのほとんどが、そうした活用例なのですから。 -- 2017-10-29 (日) 18:12:57
  • なるほど、そういった考え方もありますね。その方針で今後作業します。何が分かりやすいか、という考え自体も人それぞれですね。個人的に初めてゴーストを作った時にYAYAと華和梨の情報では痒いところに手が届かず里々に辿り着いた経緯があり、その里々でも細かい動作に苦戦し、TIPSでも自分の作りたい機能に相当するのがどれなのかが分からず、検索するワードに詰まるという状態になっていました。結果として、あまり完成度を上げられませんでした。あちこちにリンクを踏ませるよりまとめて1箇所に情報があった方が良いと考えたのはこのためで、主に自分のような無駄な苦労をする人を増やしたくなかったのです。 -- 2017-10-29 (日) 18:38:46
  • バイト値を独立したTIPSページにしました。元は「そもそもバイト値とはなんなのか」という疑問に答えるために書いたものなので、説明部分が主です。 -- 2017-10-30 (月) 06:44:55
  • sprintfを独立し、vncallをcall関数内に移設しました。 -- 2017-10-30 (月) 07:56:40
  • $BalloonOffset○は解説を主として書いたものだったため、独立させました。 -- 2017-10-31 (火) 06:35:58
  • ここでのやりとりを元に、里々wiki利用ガイドに編集方針を追加しました。修正があればお願いします。今回「どうすれば分かりやすいか -- 2017-10-31 (火) 07:19:08
  • が平行線の状態になってしまったため、管理人さんの方式で記述しますが、できれば修正が必要になる前に方針を記述しておいていただけると、大変助かります。 -- 2017-10-31 (火) 07:20:08
  • 1ヶ月ほど経ちましたが、ifとwhenなど、編集例として示していただきたく思います。編集はしたいところですが、自由に編集するとまた後々「これは分かりづらい」と再編集が必要になってしまうでしょう。 -- 2017-12-03 (日) 23:30:21
  • バイト値など一部の項目は概念の説明のようなことが必要になることがあり、以前のバイト値の修正では概念の解説が削除され、わかりづらくなってしまっていました。「短いほど分かりやすい」のは、わかっている人に限ります。それに対してwhenによる分岐構造には「難易度が跳ね上がる」など、どのレベルで、誰に向けたページなのかがやや不明瞭です。これは恐らく文章で示さない限りは管理人さんの頭の中にしかなく、編集者からは見えません。編集方針が必要と都度書いているのはそのためです。 -- 2017-12-03 (日) 23:38:58
  • 貴方が「わかりづらくなってしまっていました」というのは貴方の基準ですし、それは貴方の頭の中にしかなく、他の誰にも見えません。こちらも貴方が「どのレベルで、誰に向けた解説にしたいのか」は想像するしかありませんが、所詮、わかりやすいかどうかを判断するのは最終的には不特定多数の第三者ですから、貴方と私以外の誰かが「ここわかりづらい」と言えば、その都度再編集の検討の余地があります。手間を厭う気持ちは分からなくはないですが、再編集が必要な事は悪ではありません。回避する事は不可能です。そして、このサイトはどんな風なものが理想か、という話を編集方針と呼んでいいならば、「『解説部分は』初心者にも『それなりに』分かりやすいレベル」。前身を引き継いでいるというのは以前お話した気がしますが、前身は恐ろしく極端にシンプルな解説だったので、それは行き過ぎている、しかし空気自体はあまり崩したくはない、といった所です。これで納得して貰えないのであれば、詳細に、ステップアップを促した構造によって一新したサイトを立ち上げる事が最善かと思います。 -- 2017-12-07 (木) 23:35:45
  • 意見が伝わっていないようです。こちらの書き方が悪かったですね。失礼しました。少し長くなりますが記述します。その1。まず、編集者が書きたいことは編集者の頭にしかありません。これは当然のことで、それを他の人に伝えるために記述をしています。ただし、好き勝手に書けば収集がつかなくなるでしょう。その書き方と内容については、サイト管理者がある程度の方針や記述方法などを定めて統一することがほとんどです。このwikiでは編集方針に値するものがないので自由に書いたところ、何度か大きな修正があったので、その基準を記して欲しいと書いた次第です。また、手間に関して、毎回好き勝手に記述して毎回整形するのと、必要に応じて内容を更新するのは別物です。例えば、書類の提出時にはフォーマットやテンプレートが必ずあるものです。毎回手書きやメールなどでバラバラに出されれば入力や整形するコストがかかるからです。これを管理の手間を嫌っているとは思わないでしょう。同様に、このフォーマットにあたるものがルール、方針、基準です。もし、書き方に関わらず、管理人さんがその都度修正するというのであれば別ですが、前述の通り編集者の頭にしかないものを適切に編集するのは難しいでしょう。その2。分かりづらさに関して、考えを説明します。本屋でプログラムの入門書を見たことがあるでしょうか。大抵が、大きくそれなりに厚いものです。これは初学者にはそれだけの情報が必要であるからです。少ない説明で分かるならポケットリファレンス(書ける人向けの関数逆引き辞典)のように小型のものが主流になるでしょう。上記の初学者向けの学習書の中身は、概念の説明、例え、サンプルプログラムなどです。特にサンプルプログラムは新たな説明が出る度に毎回乗っていることが多いです。里々の記述はプログラムに近い部分があります。これらの初学者向けの学習書に習うのであれば、初心者に向けるのなら概念的な解説はかなり詳しく書いた方が良いでしょう。概念を削るのであれば、それはある程度書ける方向けの説明であり、サンプルに関しても踏み込んだ難しい内容で問題はないはずです。ここに乖離が見られたため、「どのレベルで、誰に向けた解説」かわからないと書きました。その3。記述に関しては「管理人さんの方式に合わせる」と以前書いたとおりです。その合わせるべき方式が記述されていないため、「編集方針が必要」と書いています。また、以前「1サイトで完結することが望ましい」と書いたとおり、このサイトで初心者向けの説明も完結させたいと思っており、これに関しては以前の話し合いの結果、「初心者向けゴースト制作のハブページを作り、そのページからリンクを張る」という方法を妥協点としたはずです。このwikiは多くのゴーストからリンクが張られており、事実上の標準ページと化しています。仮に、新たにwikiなどのサービスを使ってサイトを公開したところで、上記の流入経路の関係上、ほとんど見られることはないでしょう。自分がやりたいのは、ゴーストを作る人に出来るだけ詳しい情報を渡すことです。新たなサイトを公開することはやりたいこととはマッチしていません。最後に。いちいちこの伝言板に書き込んでいるのは、「意見が別れたら議論して決める」という管理人さんのレスがあったためです。ルールが定められていればそれに従って黙々と編集するのみで済みます。 -- 2017-12-08 (金) 18:54:32
  • 回答は変わりません。既に互いが互いを理解できてない事は明白ですから、目指したい新たなサイトを立ち上げる事を重ねて推奨します。やりたい事ではないと仰られようが、続けても互いに不満が解消される事はありません。貴方が理想を外部に実現するには共感が必要ですが、私には共感できません。やはり新たなサイトを立ち上げる所から始める以外にないでしょう。 -- 2017-12-08 (金) 21:38:47
  • 互いが互いを理解できてないために、議論をして不満が最小になる妥協点を探しています。議論とはそういうものではないでしょうか。こちらは不満として「編集方針が曖昧」とし、「理想とするwikiの形に近づけることには賛同、その上でより充実を図りたいので、その理想の形を具体的な形で共有して編集しやすくしましょう」という提案をしています。例えば「関数の説明・サンプルはおよそ500文字程度を目安に、それを超えるのなら別ページを作る」などがありえます。管理側としての不満はそもそも何なのですか。伝言板でそれが明かされていない以上、こちらは理解すら出来ません。 -- 2017-12-09 (土) 11:09:07
  • 一連の流れを見ていますが、編集基準が不明瞭に思います。ページ全体で文字数はいくつで、プログラミング関係の専門用語を避け、平易な表現を行う、といった方針があるなら、それを明記することを提案します。もしくは、既存のページで編集基準・方針に合致するものを例として紹介する、といった方法もよいと思います。より良いWikiとして発展することを祈ってます。 -- 通りすがりの姫? 2017-12-10 (日) 00:06:03
  • 「『解説部分は』初心者にも『それなりに』分かりやすい」が編集基準じゃいかんのですかね…? 仰る通り「プログラミング関係の専門用語を避け、平易な表現を行う」…そんな感じで間違いないですが、多分これでも彼は納得しないでしょう。何にせよ、理想の共有もこちらはゆるい方が理想に合うので、永遠に折り合う事はないです。一人が納得しても、新たに別の考えを持つ人が出てきたら我の押し付け合いになるのみ。もっとも、ゆるい方が良い事を理想とする根拠は「騒ぎ立てるまでそんなものがなくても上手く回っていたから」なので、変えねばならない時期なのかも知れませんが… -- 2017-12-10 (日) 08:02:23
  • では、指示に従い別の場所に記述することとします。それに伴い、過去に記述した内容は全て元に戻します。ソースが同じものを複数で管理することは混乱に繋がります。元に戻さないでください。もし必要な場合、一から書き直してください。許可できないという場合、公衆送信権、同一性保持権を理由とします。現行法が理由であれば反対する理由もないでしょう。 -- 2018-02-03 (土) 14:30:59
  • 貴方が編集した部分はそれで良かったのですが、これまで他者が編集した部分まで丸ごと削除した行為については対応の参考にさせて頂きます。適宜サルベージを行いますので以後は触れないで下さい。 -- 2018-02-24 (土) 23:31:05
  • 一部差し戻しに誤りがあったようで、それに関しては申し訳ありません。ただ、「ランダムに選んだ単語を再利用する」は元のページから分離されたものですが、自分が1から書いたものですので、再度削除をお願いいたします。 -- 2018-02-25 (日) 20:25:11
  • 誤解のありそうな点を補足しておきます。「フォーマット出力」に関しては、元の内容に手を加えたものが別ページに分離されたものであったため、オリジナルを「外部関数/ssu」に残し削除しました。また「少し詳しい調理方法」は大幅な改稿を加えましたが、別人にチェックと修正をお願いしたため、このページに関しては差し戻していません。このページはこのまま使用してかまいません。 -- 2018-02-25 (日) 20:58:24
  • 少し確認してみると、現状でも自分が書いた節などがいくつも残ってしまっているようです。差し戻し作業が不完全であったことは謝罪いたします。申し訳ありません。ただ、文体の癖などから自分が書いたか否かは判別出来るのですが、記述部分を完全に把握しているわけではありません。したがって、現状残ってしまっている部分に関しては削除でも残したままでもかまいません。 -- 2018-02-25 (日) 21:36:58
  • 削除対応ありがとうございます。ページの削除に関しては元が完全に自分が書いたものに限定し慎重に行ったつもりですが、「他者が編集した部分まで丸ごと削除した行為」については余計なトラブルを避けるため、明記してください。お願いいたします。 -- 2018-02-26 (月) 20:50:05
  • 無用です。先の削除で貴方がここに関わる理由はなくなったはずですし、こちらから深く追求する事もありません。 -- 2018-02-27 (火) 07:54:03
  • 分かりました。ただし、まだ記述が残っている部分に関して、同様の誤解を受けるのは本意ではないため、自分が書いた部分の削除は続けます。 -- 2018-02-28 (水) 00:10:12
  • 里々CKの作者です。昨年12月からの投稿や2月の記事削除などの一連の流れについて、以前のやり取りで記事の引き上げや里々の情報を別に纏めることについて触れていましたが、今回の記事削除とは無関係です。見返す際に誤解とトラブルの無いよう念のため書き残しておきます。 -- 里々CK開発? 2018-02-28 (水) 00:27:57
  • 失礼しました。「ある1編集者と管理側との折り合いがつかなかったため、該当編集者の過去の記述を全て差し戻す」作業をしています。この1編集者が大本である記述内容が保守・改変されている部分についてのみ、差し戻しを行っています。里々CK作者様とは一切関係ありません。また、前の発言で「少し詳しい調理方法のページについて管理側に任せる」旨を発言しましたが、これに関して撤回して差し戻します。これは無用なトラブルを防止するためです。 -- 編集? 2018-02-28 (水) 00:57:12
  • 無用です。貴方には「以後触れないで下さい」と申し上げたはずです。トラブルを避けるも何も、先の削除によるトラブルは覆りません。強めの言葉を使いますが、トラブルを避ける最善の方法は貴方が以後触れない事です。 -- 2018-02-28 (水) 05:17:21
  • 無用もなにも、勝手に問題を捏造されることは困るわけです。そもそも「削除によるトラブル」が何を指すのかすら名言されていません。差し戻しはともかくページの削除は慎重に行い、自身が1から書いた内容をベースにしたページのみを削除しています。これにも関わらずトラブルであると言われるのであれば、このwikiに書いた全ての文章を撤回し今後一切のトラブルが起きないようにするという対応はまっとうなものでしょう。 -- 2018-02-28 (水) 18:51:15
  • 貴方が今月始めにご自身と関係ない部分まで丸ごと削除を行った事の復旧作業は先日こちらで行いましたが。明言されていないと言うのは勝手ですが、この有様で貴方にトラブル回避の能力がある等と信用されると思っているのですか。三度目です。「以後触れないで下さい」。 -- 2018-02-28 (水) 21:22:01
  • 「ご自身と関係ない部分まで丸ごと削除を行った」という行為に覚えがないため、対応が必要でした。勝手に問題を捏造する行為は困ります。記述に関わったもののうち、オリジナルが存在するものは過去の版への差し戻しか該当節の削除のみ、ページを削除したのは文章を1からもので構成された書いたページのみです。本来なら触る気は無かったのですが、管理側の発言で触らざるを得なかったわけです。 -- 2018-03-01 (木) 03:51:24
  • そもそも丸ごと削除した行為の段階で既に荒らし同然と認識して対応していますが。その後、貴方の発言で謝罪は表面上のもので、実際はこれをトラブルと認識すらしていなかった事が分かりましたから、段階として確信に変わったに過ぎません。もはや貴方の理屈に意味はありませんし、暫定ながら処置を終えた2/25分まではともかく、以後は管理の強権をもって粛々と対処するのみです。以上。 -- 2018-03-01 (木) 06:05:01
  • 何度も説明しているつもりですが、ページ削除と差し戻しを行ったのは、「自分が1から書いたもの」及び「自分が書いたものに修正が加えられたもの」のみです。他人が1から書いたものまで削除したという部分があったという点を謝罪しました。その内容がどれであるのかを明記して欲しいと依頼しています。荒らし同然と言いますが、自分が書いたものの削除は問題がないはずです。wiki自体の規約でも著作人格権を行使できないとする規約はないため、有効と考えます。ルールがないwikiであるとのことですが、日本国の法は適用されると考えます。 -- 2018-03-02 (金) 03:30:49
  • (導入済みゴースト「〜」の存在)という情報取得用の変数がある、ということは知っているのだが、どこでこれを知ったのか思い出せないのが少しもんやりする……。どなたかご存知だろうか。 -- 2018-04-21 (土) 08:18:10
  • 情報の集積中ですので暫くはこちらを。→ https://github.com/ponapalt/satoriya-shiori/wiki/ChangeLog 当該の機能は更新履歴の「Mc155-1」に使用方法があります。 -- 2018-04-22 (日) 18:38:45
  • なるほど、ここだったか……。情報に感謝です。 -- 2018-04-23 (月) 00:15:39
  • すみません「コミュニケートの処理」という項目はどこでしょうか? -- 2018-05-13 (日) 18:42:43
  • コミュニケートのページにあるもの?はリンク切れです。内容も「コミュニケートの回数をカウントする」ものとは無関係でした。 -- 2018-05-13 (日) 20:20:04
  • そうですか…ありがとうざいました。 -- 2018-05-17 (木) 18:01:43

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-05-17 (木) 18:01:44 (33d)