新しいものを表示

NTFSの圧縮、ドライブやでかいフォルダ単位で一気にやると大変なことになるので、オレンジはのんびりちまちま圧縮できるアプリ自作して使ってたような記憶ある><

orange さんがブースト

今日の教訓
安易にCドライブに「圧縮」属性を適用してはいけない

マインクラフト単線閉塞システム、スタフ式なら超単純化できる?><(スタフ式は当然ながら交互にしか走らせられないけど><)

orange さんがブースト

南古谷駅第2?場内(川越センターへの分岐と駅構内の分岐の間の信号機)に入換信号機がついてないから、軌道回路踏んづけたままで進路取り直しができなくて、退行のための踏切保安要員置いて線路閉鎖して関連する分岐器にキー差し込んで強制鎖錠して…というフルコースやらないといけなかったんじゃないかなと。

mstdn.nere9.help/@orange_in_sp

マインクラフト、トロッコ単線閉塞システム回路案>< 

○進入したい列車(トロッコ)が来たら「自駅リクエストトークン」を流す
○相手駅から「相手駅タブレット」が届いたらタブレットを列車に載せて進行させる

○「相手駅リクエストトークン」が届いたら、
・自駅がリクエスト送信してなければ「自駅タブレット」を流す
・自駅がリクエスト送信済みの時は、
・・・自駅が優先駅の場合には「相手駅リクエストトークン」をそのまま返送する
・・・相手駅が優先駅の場合には「自駅タブレット」を流す

○「相手駅タブレット」は、列車到着時にホッパーで回収してただちに返送する

ていうか、南古谷側の列車をすぐに後退させる事が出来なかったっぽい点が謎><
構内なんだから操車さん呼んできて後退させられたんじゃね?><

orange さんがブースト

あるいは開き直って客乗せたまま川越車両センター横断ツアー(やめなさい)

スレッドを表示
orange さんがブースト

根本的にデッドロック回避するためには、指扇側からの川越車両セへの入庫線に渡り線1本増設して、最悪やらかしても行き違いできるようにするぐらいしか…

スレッドを表示
orange さんがブースト

状況わからんけど、たとえPRC/ATOSを生かしたまんまどうにかしていたとしても、営業列車を勘違いして指扇から川越車両センターへの入庫と指定してしまった時点でどうにもならないヒューマンエラーなんだろうなあと。

mstdn.nere9.help/@orange_in_sp

アイテム水流2本(信号線)を長距離作るよりも線路2本並べる方が圧倒的に楽だから、完全にロマンだけど><;
ていうか、無人でトロッコ動かしたい場面ってだいたいアイテム輸送なんだから、水流作ったなら水流でアイテム運べばいいじゃんってなるし><;

マインクラフトで単線の閉塞システム、レッドストーンリピーターで繋ぐんじゃなく、水流でリクエストトークン(物体)を流す仕組みで、許可待ち中に相手からのリクエストが届いたらコンフリクトしてるって認識してあらかじめ設定した優先度が高い方を優先するって方式で作ればうまくいくのかな?><

マインクラフトのトロッコで単線の閉塞システム作るのは、何回かチャレンジしたけど、レッドストーン回路の遅延が大きすぎてうまくいかなかったけど、どうにか単線で事故らない閉塞システムをコマンドブロックやMODを使わずに作る方法あるのかな?><

さらにもうひとつ思いついたけど、手動運転時のATSはFactorioで作れないって思ってたけど、ゲートで物理的に塞ぐ物理的阻止ATSなら作れる?><;

いま思いついたけど、Factorioで赤信号が2連になったか検出する回路を作れば、ATS-Sxモドキごっこ出来る?><;
スピーカー(音符ブロックっぽい部品)の音色に「ジリリリ」って音のベルもあるし、たしか鉄琴っぽい音色もあった気がするし><;

あと、こういう場面で脱線ポイントが無いのは微妙に怖いと思ったFactorio手動運転正面衝突常習者><(?)
(Factorioで手動運転自動運転で線路共有させる場合は、直進側(キー操作無し側)が脱線(せずに停まるけど)になる脱線ポイントつけようね!><;)

手動で間違えたの?>< それともATOSのバグ?><;

JR川越線 単線に上下線の電車が進入 約3時間乗客が閉じ込め | NHK | 埼玉県 www3.nhk.or.jp/news/html/20230

orange さんがブースト

川越線のインシデントはこれで原因判明ってことでいいようです。
システム的には正常動作の範疇なので、あわや衝突ってのは言い過ぎだなあ。やらかしたのは確かなんだけど。

twitter.com/2_VIEVV/status/163

orange さんがブースト

今回のダウン、実はキャパオーバーではなく、ユーザー急増のタイミングでDDoSが行われていました

つまりDDoSだと気付かずにサーバーを拡張し続けた結果、キャパオーバーと勘違いしてしまい、必要のないDBの構造を変更すると言う極めて無駄な作業が発生していました。

古いものを表示
:realtek:

思考の /dev/null