2025年4月23日水曜日

Simutrans Extendedフォーラムのくそフィードバック三銃士

Simutrans Extendedのこれまでの歴史を振り返る意味で記録として書き残すことにする。

かつて くそフィードバックを繰り返す3人がExtendedフォーラムに居ついていた


1:Pystam(ふぃすたむ)=糖質かつ無能な働き者。日本人

空気を読まず突然酷い横槍を入れてくる。

例えばらんらんがフォーラムに最初にクラッシュするバグを投稿した際に、そのパッチを彼の知り合いと思われる日本人が作ったので、手順を書いているのに調べもせずそれはバグでありませんなどと意味不明の擁護レスの横やりを入れてきた。しかしそれはすぐJamesによって否定されバグと認定される。「クラッシュを再現できません」などと言ってきたが、どんなOS使っててもクラッシュするのは明白だった。身内だからってバグ隠しの擁護をして一体何のメリットあるんだろうね?はたまたちゃんと読まずに脊椎レスをしたか。なので第一印象がかなり悪かった。その後も同様に上から目線レスが多かったがパッチ投稿を重ねるにつれ態度が変わった印象。

またスレッドで議論に突然途中から参加してくることがあるが、これまでのスレッド内の議論を一切読まずに、直前のレスだけ見て横やりを入れてくることがある。5chだと当然御法度の行為。

らんらんも最初増解決スレで質問したら↑みたいなことを注意された。いやちゃんと読んで質問したんだけどね(´・ω・`)

A.Carlotti氏が進めていたIncorporating from standardプロジェクトの進捗が鈍ると、突然Pystamがその作業をやりだす。しかしスキルがないので実装はめちゃくちゃ・・・。取得するコミットは適当だし、変更内容を自分の判断でスキップしたり、おまけに謎のtypoがやたら多い。そのあたりA.Carlotti氏に直接指摘されたが本人は理解できていないよう。なんでそのスキルでやろうと思ったんだ・・・。

2019年夏ころにひめしが多くの先輩プログラマのアドバイスを無視してExtendedのコードをぐちゃぐちゃにした直後にA.Carlotti氏は完全に姿を消し、Incorporating from standardプロジェクトは完全にストップする。そうしたらPystamが志願してその作業の続きをやりだしたのだが、A.Carlotti氏に指摘されたように本当にひどいもので、RGB関連の大きな変更で行き詰って、ほとんど関係ないのにらんらんのUIの変更がどうとか言い出して自分で問題を解決できずに匙を投げたので、こっちだってそんな大仕事できるか分からないけど、そのコードのチェックと修正をやってみるしかなかった。Pystamの途中までの作業を確認したらA.Carlotti氏の言ってることが正しいことが素人目で見ても分かった。2024年にneroden氏がPystamの作業を見返すことになったが評価は同じだった。コピペするだけでいいのになんでそんなにそこらじゅうにtypoや行の抜けが存在するのか・・・。2つのコードを見比べて間違い探しをする作業に頭がおかしくなりそうだった。コミットの中から無意味にスキップされた行を探すのがどれほど面倒だったか。Incorporating from standardプロジェクトはUIの改修のために必要なことだったが、Pystamがそのまま続けたら酷いことになるのは明白だったので、こっちもそんな大仕事を遂行するにはスキルが足りないことは重々承知だが、可能な限りIncorporating from standardプロジェクトを進行するしかなかった。目的はUIの改修だったので、ゲーム中核機能になるべく影響与えないようにUIに関連する変更のみを取得していった。そのような経緯でらんらんがIncorporating from standardプロジェクトを引き継ぐことになったわけ(´・ω・`)

pak.256というpakセットをフォーラムで発表するが、pak.256という名前は相応しくない、日本の世界観ということが分かる名前を付けたほうがいいというレスが一杯つくが、256サイズは一番乗りだからpak.256が相応しいと押し通す。賛成するものはフォーラムに誰も居なかった。後日、同じようにpak.256という名前は日本の世界観であることが分からないので名称を変えたほうがいいという投稿があると「フォーラムの人たちはpak.256という名称を認めました」と発言。いや誰一人として賛同していませんでしたが・・・。

2019年に「はろはろ~。Extendedは経済シミュレーターだからインフレ機能が必要。だかららんらんが実装して>< やり方はこうこうこう・・・」 のような超絶長いダイレクトメッセージを送ってきた。

ExtendedにおいてもOTRP機能は全力で肯定するが、彼の持論Extendedは経済シミュレーターであるということとOTRPは大きく矛盾しており、笑うしかない。

まず最初の投稿へのレスといい、最初はやたら上から目線だったに、別に仲良くなったわけでもないのに急に馴れ馴れしくしてきた。「はろはろ~><」から始める文章が他人に者を頼む態度ではない。上述のようにこっちはずっと迷惑しかかけられてない。UIとか表面的なことしかしてないらんらんがそれを実装できると思ったのか、それをするのが自分だと思ったのかも謎だし、なぜか実装する前提ですでに自分が考える方法まで細かく書かれていた。だったら自分で実装しろ。呆れて返信せずにこの時点でブロックした。しかしフォーラムは親切なことでブロックした人から返信があっても通知メールを送ってくるし、ワンクリックで返信内容が見える。意味ねーだろ・・・。



2:Freahk=ただの熱心なアンチ、ドイツ人

とにかく全てのパッチを全力で否定してくるだけの存在。ただアイデアを否定したいだけなので、論理が破綻していたりひっどい対案を出してくる場合がチラホラ。すぐに相手にするだけ無駄だと悟る。こいつはPystamより先にブロックしたと思う。

機能の議論の最中に突然彼女マウント取ってくるのが意味不明。当時高校生という印象だったが実際はもっと年上のようだった。実は結構前からフォーラムに居たようだった。コーディングスキルはあるようだった。文句ばかり言うのでそんなにずっと口を動かす暇あったらコード書いたらいいだろって思うことが多かった。それについては後述のMatthewにも言えることだが。

議論が終わった後にちゃぶ台返しをしたりして注意されるシーンもあった。


3:Matthew=無能な働き者+++、イギリス人

こいつのウザさは半端ない。前述の2人は消えたがMatthewはずっと居座っていてやる気を削いでくる。

バグ報告する際にいちいち自分の幼稚な予想を記述してくる。または誰かが報告したバグに横やりを入れてこれが原因だと思うとか言ってくる。それが尽く間違っている。しかも長い。読むだけ時間の無駄。スキルも知識もないのにそういうことをやってくる。役に立つどころか邪魔。

かつてのPystamがそうであったように、初心者から見ればそういう古参ぽい人が上から目線で言ってくることはだいたい正しいのだと思い込んでしまう。しかし彼の内容はデタラメばっかり。

最悪なのが他人のせいにしてくることだ。

Matthew「これはらんらんの最近の変更が原因だと思います」→調べる→ずっと昔からあるバグだった

Matthew「これこういう複雑な問題だと思います」→(こんなの複雑すぎてわからん・・・どうしよう)→Ters「これは単に型指定のミスだろう」

知識もないくせに長文で複雑そうに書くので惑わされることもあった。

予想が"予想"であって、コードや検証に基づいた論理的なものではない。だから間違えるのだけど。ほぼあてずっぽに直近にそのファイルやUIを弄ったからという理由で犯人と決めつけてくる。これが『短絡的』でなくてなんなのだろうか。これが何度も繰り返されるのがあまりに鬱陶しい。なぜならそれが違うと反論するにはそれを調べなければならず、調べて証明できるということはつまり問題を解決できるということである。しかし反論しなければ、こっちがひめしのようにバグを押し付けて放置する人間だという印象だけが残る。少なくともMatthewが原因だと言ってる事象は全然関係ないことが分かっていてもちゃんと調べなければ説明も反論もできない。つまり反論するにはバグを解消するしかなく、バグ解消の奔走させられる羽目になった。

またよく分からないことは彼の予想した内容が本当か検証や確認する必要があり、これでどれだけ無駄足を踏まされたことか。

そもそも彼のバグ報告を見れば分かるが無駄に長い。そしてそれを読んで得られる情報は本当に役に立たない。指摘箇所がそもそも間違っていることが多い。明らかに無関係な内容を指しているということはコードを知ってるからこそ分かる。そうでなくともバグ報告から自分でコードの該当部分を探して履歴を手繰るだけでいい。長い文章を読んだ時間が無駄。

あまりにウザいんで「あてずっぽうの予想を書く場所ではない、論理的に書け」「それができないなら単にバグ報告だけを書いてくれ」と言うと、Jamesから注意されてしまう(´・ω・`)

それからは当てつけのように、誰かがバグ報告をすると「Extendedフォーラムの開発者は推論と書くことを好みません」と横やりを入れたり、自分のバグ報告には「推論を書くことが好まれないことは知っていますが」という断り書きを入れるようになった。

推論だの予想だのの英訳はもはや時間の浪費なので気にしなくなっていたが、こちらが言いたいのは、根拠に基づいて、論理立てて、原因の可能性について述べろ、ということを言っているのだが、全く理解された様子はない(´・ω・`)


「3行で十分な内容を100行書く傾向にある。」何も間違ったことは言っていないし、これが個人攻撃?

フォーラムに文章を書く場合は英語力が無くほぼ機械翻訳頼みなので、意図がちゃんと伝わるようにするために長い文章になっていたことは分かっている。そうしたらwlindley氏に「文章が長いので短くしたほうが分かりやすい」と指摘された。それと一体何が違うだろうね?

それと自分が気に入らないパッチに執拗に文句を言ってくるのだが、その際に説明しても全く理解しないし、論理的反論をせず「自分はコーディングの勉強をしているのでいつか自分で修正するだろう」とか煽ってくる。これが煽りでなくてなんのか。それを繰り返して結局4年以上は経っただろうか(笑) だから「口だけじゃなくさっさと初めの一歩を踏み出したら?」って言ってやったのだけど、こんなの普通だろっていう(´・ω・`)

輸送単位の説明なんか何度説明したのか。

旅行単位:

大阪のAから京阪~JR西~JR東海~JR東を利用して東京のBに移動した場合。当然このルートだと大半はJR東海を利用することになるが・・・

古い仕様:JR東が1人運びました。(JR東の利用距離は1kmであっても最後に運んだ会社の総取り)
らんらんの変更後の仕様:各社がx人km運びました。(すべての利用会社毎に乗車距離分カウントする)

旧仕様ではさらに悪いことに、これを輸送種別の統計では、最後に使った種別でカウントされる。
つまり鉄道で500km移動して最後にバスで1km移動して目的地についたらすべてのこの旅程はバスによって行われたとみなされる。この無意味なチャートは削除したが、好みだのなんだの言って残せと言ってくる始末。そして将来自分で復活させるんだと・・・。もう相手してられんって思うのは当然だけどフォーラムの性質上無視すると、発言している側が正しいような状態で終了する。そいつがコーディング能力できないから状況はまだマシだけどね。こんなの「頼むからもう黙れよ」って思うのが当然でしょ。

-------------------

輸送量:

AからXまで1回で100km移動した場合。

古い仕様:1人輸送しました。
らんらんの仕様:100人km輸送しました。

AからXまで100回乗り継いで100km移動した場合。

古い仕様:100人輸送しました。
らんらんの仕様:100人km輸送しました。


この違い、この変更が分かる?

「自分は前の仕様が好きだった」←お前の好みなんて聞いてねーんだよ

「どっちのほうがいいかについてを論理的に書け」「もしくはもっとよいアイデアを出せ」って何度言えば分かるんだよ。どういう理由でそっちが好きなのか、納得行く説明をしないで煽ってくるだけなんだが?(´・ω・`)

議論をする場所ですって。議論になんてなってませんが?(´・ω・`)

とにかくしつこい上に進歩がない。なのにやたらとアクティブ。無能な働き者を極めしもの。これに何年も付き合わされてどれだけ時間無駄にさせられたか分かって欲しい。

2024年2月20日火曜日

路線の「各駅待機状況表示」の改良について考える #その4

 フォーラムに新たに報告されたバグに対応したり
色々平行作業したり躓いたりあったけど、とりあえず進捗状況(´・ω・`)

本当はExtendedに提出しないでおこうと思っていた機能を、ある程度は提出することにした。
理由は
(1) Extended バージョン15.0のために、UIコードの特にテーブル関係で綺麗にデザインできるようになんとか書き換えたくて、そうすると色んな部分で競合発生しまくるので面倒。
しばらくぶりにSimutransのUIを見ると古臭ささと見にくさが非常に気になったのと、Ex15と私家版との差で14.0には実装されてない変更点がかなり多く、これがコードの競合の原因になっている。
例えば編成詳細、車庫画面、工場系ダイアログ。
Simutrans GLでのUIの機能拡張が進んでて、それをExtendedへの取り込めるなら取り込みたいとか難しい問題も出てきている。

(2) ひめしに(先輩方の忠言を無視して)コードをOTRP/MTICBの実験台にされ、スパゲティ化されて、プロジェクトのメンテもバグ修正も大変な状態にされたExtendedがあまりに可哀そうで不憫すぎる。
バグ修正投稿したら普通にすぐに対応されたのでそういう気持ちがより強くなった。

(3) 休止してる数か月とここ最近の海外の人達からの応援メッセージに励まされた


なのでこれらの変更点は、Extendedに組み込まれる
というか結構な進捗があって既にいくつか組み込まれました。


  1. 貨物をクラス別に分ける表示オプションを追加
  2. 表示待機数をその路線を待っている貨物だけに絞り込む
この2つは既に1年半くらい前に私家版のほうでほぼ同様の機能が実装されていたのを
忘れていたみたい(´・ω・`)
そこから必要な関数を引っ張ってきて、あとはUIにオプション追加ですぐに実装完了。

2. はかなり有用なオプションで、私家版はむしろこれに固定されてたのを忘れた(´・ω・`)
Ex15対応が忙しくなったタイミングだったみたい

例えば、これまではどの路線のデータからこの情報にアクセスしても
(a)「大阪駅で電車を待っている乗客は何人ですか?」というのを表示していた。
つまりあるカテゴリのその駅の待機量全部を拾っている。
実際にその路線に乗るかは関係ない。
それを(b)「大阪駅で"新快速"を待っている乗客は何人ですか?」というもうちょっと便利に使える値を拾うオプションが追加された。

しかし新快速は東西を往復しているので、2回大阪駅を通り、東へ向かう客と西へ向かう客が居る。
同じ路線でもどっち向きに走っている編成に乗りたいかが異なる。
(c)「大阪駅で(上り/下り)方面の"新快速"を待っている乗客は何人ですか?」
これを区別できて満点(´・ω・`)
とは言え、現状が(a)なのだから、それが(b)にアップデートされるだけでも
前進していることは間違いないよね。


このあたりの改良はまだまだ続くよ(´・ω・`)

2024年2月4日日曜日

路線の「各駅待機状況表示」の改良について考える #その3

じゃあ機能拡張をやっていこうかしら(´・ω・`)


思いついている改良案

  1. 貨物をクラス別に分ける表示オプションを追加
  2. 表示待機数をその路線を待っている貨物だけに絞り込む
  3. その路線の駅間に何編成が移動中かのリアルタイム表示を追加する
これ以外でちょっと微妙かなと思っているアイデアが、
待機量に応じた横棒を表示して待機量の多さを見た目で補完できるようなもの。
路線の最大積み込み可能量を100%にすると編成が多すぎるとバーが全体的に短くなるし
駅の最大容量の場合でも駅によって容量も違えば、
貨物は各カテゴリで共用だし、クラス含めても同じカテゴリ内に複数の貨物種類があるので
どのようにバーを表示させるか、というところでいい実装案がない(´・ω・`)

それとこの表示の既存の問題として同じ駅を何度も経由する場合に
同じ駅が何度も表示されてリストが混乱している、という問題があるのだけど
上記3の機能を実装するなら、この問題は相反する。
加えて乗客の行きたい方向によっても区別される必要もあると思っている。
シミュトランス(≠ジムトランス)のコード知識から言えば、路線絞り込みは間違いなくできるのだけど
同じ駅で路線内の運行の向きを考慮して待機数を出すのは、ちょっと手間がかかりすぎるかもしれない。


とりま、この3つは上から簡単そうな順に並べたので、
次回以降それを掘り下げていきますか。  (´・ω・`)つづく

路線の「各駅待機状況表示」の改良について考える #その2

 前回の続きで進捗状況...


弄っているとバグが見つかって、表示がオーバーラップする場合があった。

どうしてこういうことが起こるかというと、
例えば「0」という表示が「旅客 10」という表示になると表示サイズが変化するわけで
その際に(エクセルで言うところの)セルの最小サイズがちゃんと切り替わっていなくて、
表全体の最小サイズも正しく処理されない
みたいな感じで、こういうところも考えながら、正しくプログラム組んでいかないといけないし
そういうバグが見つかったら、正しく書き直さなければならないわけ(´・ω・`)




とりあえず何が原因か手探りで色々弄って
結局、ほぼほぼコード書き直すことに(´・ω・`)
直っただけ良かった。
ついでだから枠組デザインに変わってちょびっと見やすくなったと思う。

アプデを繰り返していくゲームでは、日々のメンテナンスが重要なんす(´・ω・`)

そういうのを全部丸投げして、
『バグが見つかっても自分じゃなおしません(だって取り込んだ人の責任でしょ)
ってスタンスなのがひめしというクズ日本人。しかも小さなバグどころのレベルではない。
奴らの尻拭いにらんらんや海外のコーダー達がこれまで一体何十時間費やしたか。
それでも問題はほとんど除去されていない。
もちろんらんらんだってじぇーむ寿司や他の人たちに一杯助けてもらっているけど、
シムトラ学会などというイベント開いてそこで堂々とコードメンテナンスを海外の人らに丸投げ宣言して、有言実行してるのがひめしという奴。まさに反面教師の鑑。

しかもそのクズ行為を参加者に薦めている・・・。
シムトラ学会とやらは、
やってはいけないことを拡散する勉強会なの?(´・ω・`)

そういう自分が起こした問題の責任を一切取る気が無いニンゲンは、
他人様のプロジェクトにパッチなんか提出するな、と教えるべき(´・ω・`)

今後そこらへんの事実を分かりやすくまとめていくので。
それがらんらんに与えられた役目(´・ω・`)

とにかく機能を拡張する前段階で、コードの修正をしたよ(´・ω・`)
次はこれをどう味付けしていくか考えよう。 つづく

2024年2月2日金曜日

路線の「各駅待機状況表示」の改良について考える #その1

いつもはパッチが完成してから、フォーラムに投稿するという工程を踏んでいたけど、
今回はアイデアを練って実装作業を進めるところからやっていく。

Simutrans Extendedでは路線一覧にStandardには無いタブが追加されてて
そこから路線管理に便利な情報にアクセスできる。

その中でこの「待機状況」タブは、
路線の各駅にどれだけ乗客や貨物が溜まっているかを一目でチェックできる。

これはらんらんが以前に追加したものだけど、正直詳細を忘れてしまっている(´・ω・`)
まぁたくさんUI改変したものね。
久しぶりに見てみると便利ではあるけど正直イマイチで、
(最近力を入れているテーブル表示形式がいいとかそういう話ではなくて)
明らかに表示機能や内容的にまだまだ改善の余地がある(´・ω・`)

Extended ver15が進むかどうか分からないけど、
それについてはじぇーむ寿司次第なので今はそっち側はあまりやれることがないし、
今の段階でExpert(仮)向けの追加機能を作っても、Ex15の進捗があった場合にまた競合の解消に苦しむことになるので、影響の少ないUIの改良を進めることにする。

だって久しぶりにUIを見たら本当にSimutransのUIは古臭いというか、
特に枠線だのテーブルだの背景だのがあまり無くてので、
テキストが浮いたように配置されてることが多くて
一般的なUIと比べて全体的に情報の見やすさに対する工夫がされていないと感じる(´・ω・`)

その一例がこの各駅待機状況表示なのだけど、まだヘッダとメインデータの間に線が引いてあるだけでもSimutransの中ではマシな部類(´・ω・`)
もっと言えば駅番号貨物の種類を表すの色の箱が配置されてるだけでもかなりグラフィカルになっている部類...

とにかくSimutransは昔からウィンドウの見やすさが酷い。
ほんまにゴミレベル(´・ω・`)
「フォントのサイズ」とか「文字の太さ」とか「斜字」とか
そういう根本的な部分を弄るのは現実的ではなく無理なので、
できることをやっていくしかないのだけど。

そりゃあ前世紀から続いていて、その開発も非常にゆっくりだから仕方ない。
世界的に見ても超ドマイナーなので貢献者も少ない。


とにかく今回はこの「各駅待機状況表示」を改造できるかどうか分からないけど
(Ex15の作業と並行して)進めてみようと思う。 つづく


追記
このUIテストしてたら文字が重なって表示される場合がある等、現状でも色々問題があることが判明(´・ω・`)
ほんとバグ報告してくれる人ってレアよね...(´・ω・`)

2024年1月31日水曜日

Simutrans Extended ver15のスケジュールUIを弄る


ひめしやふぃすたむと、ひめしの影響を受けた日本人達に自分の趣味プロジェクトを荒らされて、
らんらんまでやりかけで退場したら、じぇーむ寿司があまりにも気の毒すぎ(´・ω・`)

なので、色々実装してみたいアイデアが溜まっていたところだったのだけど、中断して
やりかけのEx15のUIの作業を進めてみる。

ネロデンというExtended開発に大きく携わってた人が2023年に色々機能追加をやってたみたいで、その影響でビルドが通らなくなってるので修正(´・ω・`)

マスターで大丈夫なのにex15ブランチではコンパイル失敗する理由がよくわからない。
明らかにオーバーライドのエラーなのに(´・ω・`)


作業中の新スケジュールUI。



デバッグモード?でUI上の各コンポーネントの枠線が表示される。
これを参考にしつつUIのパーツを並べたり組み替えたりしていく。

スケジュールUIのデザインもこんな感じに一新されるので、やっぱりver15はちゃんと実装されて欲しい(´・ω・`)

あのゴミ日本人どもが足引っ張らなければと思うと怒りがこみあげてくる(´・ω・`)
1年間完全に停滞したし、将来のstandardからの組み込みや将来渡るコードの保守、都市回りの機能追加、道路回りの機能追加、こういった部分に甚大なダメージを与えた。
それでもらんらんは奴らの尻拭いに何十時間も費やしたし、もちろん他のコーダーも。
それでもまだ甚大な被害が残ってる。(´・ω・`)はあまじ

シムトラ学会だのアドベントカレンダーだのやっておいて、その成果がこの惨状よ?
そういう連中が本国(日本)では偉そうにしてるの見たら腹が立って当然でしょ?

2024年1月29日月曜日

Simutrans Extendedで路線の輸送断面表示UIを作る #その1

Simutrans Expert(仮)向けの改造案件


以前からアイデア自体はあったのだけど、とりまバグ修正の提出も終わったので
コーディングのリハビリ兼ねて、新しい統計表示を追加してみる。

輸送断面?っていうの?駅間輸送密度表示を追加してみよう。
なんちゃら線が赤字で廃線の危機、とかいう話題になるとこういう特定区間の輸送密度だのって話はでてくるからね。



昨日の記事で書いたみたいに、結局これも別のUIを参考にして、あれができるならこれもできるんじゃないのっていう着想。
部品をバラしてそれを集めて再構成し、別のUIを作りあげる。パクりの集大成。

コーディング初心者はこの手法でどんどん小さなパッチを作って、
コードに触れて理解を深めて着実にステップアップしていくのが大事。

具体的にはシミュトランスではスケジュール管理ウィンドウや編成ウィンドウにある「運転時分履歴」タブで駅間の移動時間を計測できるから、じゃあ輸送量も同じように計測できるよねっていう理屈。

正直「運転時分履歴」って、明らかに異常な遅延や迂回が発生しているかどうかの探知に使える程度で、らんらん的にあんまし要らない機能だったんだけど、今回は大変役に立ちました。ありがとう(´・ω・`)


輸送密度っていうのは

https://www.jrhokkaido.co.jp/corporate/region/pdf/koumoku/01_01.pdf

こういう統計で、路線の各駅間でどれくらい利用されているのかっていう統計データ。

路線全体の輸送密度なら、シミュトランス側は以前のらんらんのパッチで計測するようになりました。路線の総輸送キロ営業キロで割るだけだからね。

各駅間の輸送密度は路線を運営・管理していくにはめっちゃ重要な統計なんだけど、残念ながらこんな有用な統計がジムトランスにもシミュトランスにもない!!!

これがないと路線が全体赤字なら人が一杯乗ってる区間も含めて全区間が廃止されちゃうかも?

はっきし言って、

輸送ゲーなのにこの統計がないって、
このげえむ作ったのは
馬と鹿のハーフ
なんですかね?(´・ω・`)はぁまじくそげ


路線の末端だけガラガラなんてことはよくあるし、そういうデータをプレイヤーがはっきり見れるに越したことないよね。むしろこれが見れない理由がない。プログラマーの手抜き!


冗談よ(´・ω・`)

駅間のデータを全部記録してたらセーブデータがどれくらい大きくなるか、ちょっと分からないんだよね。らんらんは計算苦手なので。

でも「運転時分履歴」で各駅間で計測時間を3回分保存してるくらいだから大丈夫よねっていう、これもほぼ他UIのパクりコピーだからいけるよね理論。


計測で記録がちゃんとできていれば、記録したデータを使える形にして見やすく表示してやればいい。


制作進捗...



(´・ω・`)おほーっ!!

なんと、各路線で各貨物カテゴリ各運賃クラス、分けて記録されます。
駅も路線も編成も統計(チャート)はクラス毎に分けて記録されないのに、
らんらん製駅間輸送密度計測ではグリーン車各駅間利用率までしっかり確認できちゃう優れもの!!

路線輸送密度と平均混雑(利用)率は駅間のデータを用いてちゃんと計測する必要があります。
混雑(利用)率を計測する場合に、
A駅 ─ 99km ─ B駅 ─ 1km  C駅
こういう路線があったとする。

AB間の乗車率が100%BC間の乗車率が5%だった場合。
AB間の乗車率が5%BC間の乗車率が100%だった場合。

距離を考慮しないで考えた場合①と②は同じ混雑(利用)率に見えてしまう。
これに距離を掛け合わせることでこの路線がどれくらいの割合で埋まっているか、というのが分かるわけ。
特定の区間だけ混んでるというのも明確に。
ちなみに駅間混雑率が100%超えるとバーが紫色になるよ。

Extendedプレイヤーならすぐ分かるだろうけど、バーとかは全部他のUIでも使ってるもの。
つまり全て既存のものの組み合わせ。

あとはこの統計データのセーブデータへの読み書き処理と、画面の更新フラグと更新処理を実装するだけです。
意外とあっさり完成しそうなのだけど?(´・ω・`)

本当になんでこれが無かったの。
そして今までやらなかったの(´・ω・`)はあまじはあ
(´・ω・`)優先度?


果たしてこの機能は完成するのか?

つづく(´・ω・`)

おまけ
今回スクショにあるダークテーマは2/1まで公開

Simutrans Extendedフォーラムのくそフィードバック三銃士

Simutrans Extendedのこれまでの歴史を振り返る意味で記録として書き残すことにする。 かつて くそフィードバックを繰り返す3人がExtendedフォーラムに居ついていた 1:Pystam(ふぃすたむ)=糖質かつ無能な働き者。日本人 空気を読まず突然酷い横槍を入れてく...