とにかくものすごい勢いでコードを削除しまくってる
とにかくものすごい勢いでコードを削除しまくってる
なんかうちで試した限りでは
エンバグ野郎版のほうが安定している
というギャグみたいな展開になってるけれど、一応これは開発版です
SSPエンバグ野郎版(2.7.00 Pre1)
- 半透明ウインドウ設定を固定、リージョンを使った不定形ウインドウを全廃
- カレンダースキンを半透明対応
フルセットの差分として上書きしてください。
@kanade_lab もっと長距離走れるようになってもっと流行ってほしい
※BL = battery locomotive
※BEMU = battery electric multiple unit
これはもはやただのBLの枠組みには収まらない、普遍的な作品だ
https://ja.wikipedia.org/wiki/JR%E4%B9%9D%E5%B7%9EBEC819%E7%B3%BB%E9%9B%BB%E8%BB%8A
もっと変更点山盛りにしたやつを用意してるから…飽きさせないよ…
@netai98 差分だからフルセットに上書きして～
滑走路周辺の建築物の高さは厳密に制限されてるので、どこの空港でも近くに雷雲ができたら、雷が落ちるのは直近で一番高いターミナルビル、ということなのでは。
管制塔立ってたらそこに落ちるんだろうけど、地方空港みたいに管制にそこまで高い塔が必要なければどうなるか…という。
このアカウントは、notestockで公開設定になっていません。
⛏️←つるはし
まあヨソの商売邪魔するからダメだろうなあ…（遠い目）
12800円/年でコードサイニング証明書がもらえるのなら大喜びで加入するので、MSさんも似たようなことはよはじめてください。
WindowsでもApple Developer Programみたいに12800円で無限に証明書を発行させて💔
本当にゴースト（を模したLLM Bot）が投票しはじめたら面白いので、誰か作ってください。まるなげ！
ウチはSSPの大改修を詰め込んでるので、しばらくはやらんかと…
ものすごく困る、が2人も居るんだけど、どういうことなの…(Xのほう)
純正IP MessengerにSSTPプラグインをつけるとかでごまかせないかな…（無茶振り）
カレンダーは廃止しません、スマン！
でも、さすがにIM/IP Messengerは捨てていいよね…？
@nikolat いっそカレンダーごと廃止しよう（おい）
SSP 2.7.00のCHANGELOGが、まさかの機能消去の羅列になりそうな予感がする…
SSP 2.7系では、この先に備えて大幅な近代化改修を行う予定です。
現在の決定事項は
・APIの完全Unicode化：Win9x/Meのサポートはすでに終了していますが、2.7から完全に動かなくなります
・半透明ウインドウ設定の固定化：将来的な仕様拡張に備えて、半透明ウインドウ機能を切れなくなります
ですが、それに加えて IM/IP Messenger の完全撤去を予定しています。
そろそろさすがに使っている人はほぼ皆無だと思うので、撤去の方向で進めるつもりですが、念のためアンケートを置いておきます。
半透明ウインドウが操作不能になった（そのうち撤去するか…）
@yune_kotomi 一応実験できる環境だっていうのはわかってるのです！
めんどっちいだけで（おいこら）
このアカウントは、notestockで公開設定になっていません。
正直Largeじゃないモデルもたくさんあるし、Languageじゃないマルチモーダルモデルもあるし、LLMって呼び方自体がそろそろ合わなくなってきてる
@yune_kotomi GPUは必要経費だから実質無料とか、PCの電気代は以下略とかいうんじゃろ？
マジレス：どっちかというと時間配分制約かなあ…
なんかローカルLLMとかまで手を出したら、ガチで際限なく時間とお金を食うので封印してる
Claude 3.5 Sonnetに、ものすごいマイナーなWin32 APIの質問をいくつかしたら、だいたいあってる答えが返ってきて、割とびっくりしてる。GPT-4oはちょっとすっとぼけた答えだったのに…
いらないコードをぽんぽん捨てて、あとLayered WIndow (半透明ウインドウ) 固定にしてリージョン用コードを全部捨てて、ありったけ身軽にしたい
SSP近代化その1の、Unicode API化だけで、かなりの勢いでソースコードを捨てて削りまくっている
libvipsを有効にしてみたけど、メモリ消費量とかが改善してるといいなあ（ImageMagickは大食いなので）
Q.なんでテスト版をわざわざ？
A.手元で何の問題もなく動いちゃって逆に怖いの…
完全Unicode対応のSSPテスト版を置いておきます。
Diff取ったら60MBのテキストファイルができあがった時点で何が起こったのかは察してください。
たぶん動くからテストしてね！
フィードバックなかったらそのまま見切り発車よ！
ホット（辛い）ストレージサービスでWasabiと聞いて
Wasabiが激辛（げきつら）と聞いて
@ntumikanhn 64bit時代になっても、俗称としてWin32 APIって呼ばれてますね（蛇足）
まあ今はそんな化石APIなんて直接叩かないので…
@kmy_myun 嘘は言うてないで。
ほらぼくのこの純真な目を見て…
@ntumikanhn ちなみにどちらも、組むためにはガチのプログラミング(C++/Win32がメイン)が要るので、基本的には誰かが作ったやつを使わせてもらう形になります。
@ntumikanhn プラグインはSSPの機能拡張用プラグイン機能、SAORIは里々用の機能拡張プラグイン的なものと考えれば理解しやすいかと。
ただ、ぶっちゃけキャラクターを動かすのにはどちらも必須ではなくて、オプションです。
しばらくは辞書書きに専念した上で、どうしても要るようになるまで見なかったことにしているぐらいでちょうどいいかもしれません。
@kmy_myun これの最後に正しいマシュマロの焼き方を実演しているぞ（ほんまかいな）
@pocket_wanko うん、うちの場合は正直THREAD系は使わなくて、いつも無視してる。
だけどマルチスレッド対応のDLL組む時はむしろ積極的に活用できるらしい。実例：OpenSSL
DLL_THREAD_ATTACH / DLL_THREAD_DETACHは、里々のせいでもSSPのせいでもなくて、なんかOSが裏でごにょごにょやってる時にスレッドが起動したり停まったりしてるっぽい
https://ukadon.shillest.net/@tukinami_seika/112635547499394461
の投稿
tukinami_seika@ukadon.shillest.net
このアカウントは、notestockで公開設定になっていません。
あの貧乏で苦しむことで有名な銚子電鉄が、まさかの完全新製形式、ヌレ4343を導入…！
IPAはイソプロピルアルコールのことで、IT試験っぽいことや脆弱性のとりまとめとかやってる総本山のことでも、なんかよくわからないビールの種類のことでもないのだ…
このアカウントは、notestockで公開設定になっていません。
@sxi_k 「ChatGPTのエラー率上昇：調査中です」
正直なんもわからんということがわかった 
@Zichqec I had never considered the sort order of elements before, because I had not thought about the demands of complex combinations of elements.
I'm working on a very complex bug fix right now, and will work on it with the other requirements as soon as I'm done.
@netai98 できればどうにかしたい…
@netai98 どっちも環境依存のにおいがする…
@Zichqec It is easier to understand if you change your mindset.
Elements are processed (drawn) in order from the top, and the image written on the bottom overwrites the image written on the top, so what is written on the top becomes the lower layer in terms of appearance.
Collisions are also processed in order from the top, and if the conditions for a hit decision written above are met, the process ends there, and if not, the hit decisions below are checked in turn, so what is written on top becomes the upper layer.
_WIN32_WINNTを変えたときだけVerifier Stopとかやめてくれませんかね…？
一日格闘して完全にメゲた。
（ここに「なんの成果も得られませんでした！！」を貼る）
おーっと、ぽな選手、さっそくメゲた～！
コンパイルエラーが300か所ぐらい出てるので、そもそも完全Unicode化だけでもそう簡単には終わらんぞワハハ
64bit化しようと思ったら、SHIORIやらPLUGINやらを全部別プロセス分離だね…
凶悪な互換性地獄の釜の蓋が…
まあそこまではしばらくはやらんかなあ。
終わったら次は64bit化だろうけど…これは山のようにDLLがあるからなあ…さらに地獄を見ることに…
でもULW系(半透明ウインドウ)に一本化できれば、縮小だの回転だのやりほうだいなんだよなあ…
重い腰を上げて、ついに全面Unicode化とregion系コードの完全削減に手をつけてしまった。
きっとSSP 2.7.00は地獄を見ることになるだろう…
