PythonでSteamworks.NETの必要な部分だけ刈り取ってくる意味不明なスクリプトの隣にPythonで謎のde/serializeするC#コードを生成するスクリプトが発生するともはや誰にも手を付けられない気はするがまあ誰も手付けないだろうしいいか

あ〜まあなんかコード生成するやつ自分で書いたらええというのはそうかもな

.NET 3.5 対応してないのまあそりゃそう感あるけど Unity IL2CPP BepInEx 環境 (.NET 6.0) と .NET Framework 向けってDLL共有できないよなあということを考えている https://github.com/protocolbuffers/protobuf/tree/main/csharp#supported-platforms

これくらいだったら oneof 祭りしたほうがたぶん楽だな……

WebApplication.CreateBuilder でアッ……となった (それはそうなんだが)

gRPC over 変な転送手段 (aka パイプ) ってどれくらい簡単なんだろう

まあなんかprotobufでoneof書きまくりとかが書くコード減って楽かなあ

> Server-side
> MagicOnion server requires .NET 8+.

アッ、ハイ…… (.NET Framework をターゲットにしている)

UnityのゲームのMOD (明らかに本体のほうがリソースをバカ食いする) だしIPCは毎秒1回も呼ばれないので明らかにそこまで頑張るもんじゃないという文脈がありました

そういえばMagicOnionとかいうやつがあったな 試してみるか いやこの環境だと導入が逆に面倒な気もするが……

いやまあそりゃ他の人が書いたプログラムと通信するとかそういうアレなら真面目に設計するかもしれないけど今回はそういうアレじゃないんで…… (他所のexeに読み込むdllと独立したexeで通信したいだけ)

例えばRustだったら何も考えずに値付きenumをserdeにserializeさせて流すとかでいいじゃないですか (Swiftも似たような感じで行ける) でもそれをC#でやろうとするとまず値付きenumなんてものはなく……

コミュニケーション手段はどうにでもなってその上で流すものを用意するのがだるい

C#同士でIPCやろうとして3秒でだる、、、って気持ちになって来た

これで解決した！！！！！！！

なんか正直あんまりうまく行く気はしない (Steam Recording のイベントはオーバーレイが出ているpidと1:1対応とかでもおかしくない) が、まあ PoC 書いてみるというのはアリかもしれない

ふと気づいたが、サブプロセスを生やしてそいつだけ最新の steam_api.dll を使ったらどうなるのだろうか？

ValveSoftware/ToGL: Direct3D to OpenGL abstraction layer
https://github.com/ValveSoftware/ToGL

こんなんあるんだ……

@rinsuki 生き方を間違えるとこのようになってしまうので、皆さんも気をつけてくださいね

@rinsuki
願望: Steam Recording にMODでイベントを追加したい
・ゲーム内蔵 Steamworks.NET はバージョンが古くて非対応
・→ MOD側に最新の Steamworks.NET を入れる
・→ 最新の Steamworks.NET は最新の steam_api.dll を要求する
・→ 最新の steam_api.dll を入れる
・→ ゲーム側の Steamworks.NET が壊れる
・→ ゲーム側の Steamworks.NET 呼び出しを全部フックしてMODの Steamworks.NET 呼び出しに置換するもなんか不完全で落ちる ← イマココ

なんかちょっとしたMODを作ろうとしただけなのに酷い目にあっている

このアカウントは、notestockで公開設定になっていません。

LINEスタンプってオタク版スマブラみたいなところあるなと思った