ところで皆さんはSexLabで最大何人までの同時エッチが可能か、ご存知ですか？
ちなみに「同時エッチ」というのは、3Pとか4Pのグループセックスの人数のことではありません。
同時に稼動している個々のセックスアニメーションに、全部でどれだけの人数が同時に参加可能か……ということなんですが、果たしてこんな言い方で伝わりますかどうか。
ちなみにSexLabでは１つのアニメーションを再生するのに、1つのクエストを消費してスクリプトを回しておりまして、それを「1スレッド（Thread）」という単位で呼んでいます。
この「1スレッド」のセックスシーンに参加できるのは最大5名様までなんですが、実はこのスレッド、SexLabのバージョン1.59cでも1.60でも最大15スレッドまでの同時稼動が可能なのです。
つまり条件さえ整えば、５名×15スレッド＝総勢75名による同時多発セックスが可能なんですよ！
まあ、普通にプレイしてたら、そもそもエッチ可能な75人のNPCやクリーチャーが一箇所に待機しているという場面自体がないので、なかなかお目にかかれる代物ではないとは思うんですけど。
SexLabのセックスシーンはクエストによって管理されており、それらがマルチスレッド化して
最大15スレッドまで同時に稼動できるような構造になっています。
各スレッドには５人分のエイリアスが用意されています。
つまりSexLabの各アニメーションの参加者は５人まで……最大5Pまでということです。
さてさて、そんなわけで、75人が参加する大運動会（笑）をちょっとこの目で見てみたくなりましたので、試験用のModを作ってテストしてみることにしました。最大15スレッドまで同時に稼動できるような構造になっています。
各スレッドには５人分のエイリアスが用意されています。
つまりSexLabの各アニメーションの参加者は５人まで……最大5Pまでということです。
まずは大乱交パーティーの会場と参加者を用意してっと……場所はできるだけ広くて、明るいところがいいなあと思ったので、ソブンガルデの「勇者の間」をお借りすることにしました。
中央のグリルは撤去させてもらいました。
参加者は75人も個別に作るのは面倒だったので、ロキール1号～75号を適当にコピペしました。そしてパーティ会場には15個のレバーを配置して（上記SSの赤い線で囲ったとこ）、レバーを引くとそれぞれ５人ずつロキール君をグループにしてセックスを始めるようなスクリプトを設置しました。
同時といっても、15スレッドが一気に発動したらさすがにフリーズしちゃいそうなので、一つずつレバーを倒すくらいの間隔はあけて、15スレッドを順番に稼動させていこうと思います。
また、レバーを引いている途中で最初に稼動したスレッドが終了したりしないように、SexLabの各ステージの時間制限の秒数は最大の300秒をセットしておきました。
ちなみに再生するアニメーションは、人間用のものだとデフォルトでは４Pまでしかないので、4Pアニメの「ZynFourWay」に男マスターベーションの「ArrokMaleMasturbation」のアニメーションを合成して、5P用のアニメーションを作りました。
まあ、5Pといっても最後の一人はずっと自分のモノを扱いてるだけなんですが……そもそも全員ロキール君なんだし、何人いようが所詮自慰してるようなもんなんだから、アブれてても別に構わんでしょう。
私のPCはファルスカールの男祭り戦争くらいの人数でもカクカクしちゃってたくらいなので、そもそも75人ものNPCがいる部屋を無事にロードできるのかどうか、心配だったんですよね。
ちなみに私のPCはCore i5-3470、メモリ8GB、グラボはGTX660Ti 2GBというスペックです。
正直、今のPCではもうFallout4はキツイのではないか…と思っていましたが、今回のテストで改めてベセスダ様ならなんとかしてくれる……バニラならなんとかついていける……と思ったりしました。
75人いても全然平気でした。むしろいつもより軽いような。カクカクは全部Modのせいだったのか……
テストはまず始めにSexLab1.60で行ったのですが……結論から言うと、現在のSexLab1.60のhotfix2では15スレッド全部を稼動させることはできませんでした。調子の良い時は10スレッド目くらいまでは稼動するのですが、4、5スレッド目、ひどい場合は1スレッド目からフリーズしてしまうんですよね。
ちなみにこれはCTDではなく、画面が動かなくなって操作を一切受け付けなくなるという、文字通りのフリーズ状態です。バージョン1.59cの時代からSexLabではCTDすることはしょっちゅうありましたが、フリーズする、というのはちょっと珍しい。
最初はフリーズするのはやっぱりPCの限界なのかしら……と思ったりしたのですが、ログを見てみると、どうもフリーズする時は毎回同じ処理の最中につまづいているみたいなんですよね。
ちなみにそのネックになっている箇所は、sslActorStats.pscというスクリプトが担当している「SeedActor」という処理です。
この「SeedActor」という処理は、NPCにヴァギナやアナルなどのセックスのスキルや、ゲイかストレートか、といった嗜好などのステータスを植えつける関数でして、バージョン1.59cの時代からある処理なのですが、バージョン1.60ではPapyrusスクリプト上ではなくSKSEのプラグインで処理を行うという、内部的な変更がありました。
私はSKSEのプラグインのことは全然わからないし、そもそもSexLabのdllのソースは公開されてませんので、この「SeedActor」の処理にフリーズする要因があるのかどうかを調査することはできないのですが、ためしにこの「SeedActor」の処理を、1.59cで使われていたPapyrusスクリプトのコードに全部書き換えてやったら……途中でフリーズすることなく、15スレッドがすべて稼動しました。
だからやっぱり、1.60の「SeedActor」の処理の中には、フリーズを引き起こす何かしらの要因があることは確かなのだと思います。
まあ、フリーズするといっても100％の発生率ではないので、この処理に問題があるとは一概には言い切れないのですが。
たまたま、何かの状況が揃うとイレギュラーが発生するという類の問題なのかもしれないですしね。
…というわけで、お次はSexLab1.59cでテストしてみたんですが……さすがは安定版の1.59c！
危なげなく、一度もコケることなく15スレッドを難なく完走してくれちゃいました。
いやー、こういうのを見ちゃうと、1.59cに戻りたくなっちゃいますねえ。
ちなみにGitの方で公開されている開発版の最新のSexLab1.60では、「Path to Location at Start」という機能が試験的に追加されておりまして、セックスシーンが始まる前に参加者がスタート地点までやってくるという動作があるんですが、この処理がもう笑っちゃうくらい遅い！んですよ。
1.60はただでさえスレッドの開始がもたつくのに、これ以上時間のかかる処理は、どんなに素晴らしい機能でもいただけないなって思います。まあトグル式なんで使わなきゃいいだけですが。
セックス前の不自然なワープは、馬車のファストトラベルシーンのように、画面をブラックアウトさせてアニメーション開始とともにフェードインするとか、演出の工夫でカバーできないものですかね。
それにしても75人同時のくんずほぐれつ……凄いです。
なんかこう……エロというより、ギリシャの神殿のレリーフみたいな「アート」に見えてきます。
実は私、SexLabのボイスには前々から不満がありまして……SexLabのデフォルトのボイスは「Mild」「Midium」「Hot」の３種類があるんですが、私はそれだけじゃ全然足りない！って思うんです。
だからボイスを拡張するModを作ろうと思ってるんですが……こいつはSexLabの仕様に合わせてマルチスレッド化する必要があるんですよね。
字幕Modみたいにプレイヤーのシーン限定にするなら、シングル版でもいいんですが。
で、それを作ってる最中にふと思ったんですよ……そもそもSexLab自体、ちゃんと動くのかなって。
SexLabが動くだけでギリギリの状態なんじゃ、Modでさらにそれを拡張するなんて無理ですからね。
まずはSexLab単体でテストしてみて、15スレッドがフル稼働した時にどのくらいの負荷がかかるのか、確かめないと。
これから75人の連続絶頂シーンが始まるのかと思うと……ショール様の天罰が下りそうです。
結果は15スレッドがフル稼働していても、まだまだ全然余裕がありそうな感じで……ホっとしました。これなら他のModをてんこもりにしてても、ひとまずは大丈夫そう。まあ、1.60はちょっと不安なところがありますが……皆が使ってりゃ、そのうちFixされるでしょう。
……されるよね？？
そういえば1.60では、なんだか強姦（Aggressive）の判定もおかしいような気がするんですが、他の皆様は問題なく稼動していらっしゃいますでしょうか？
1.59cでは強姦の被害者を指定することで「IsAggressive」という強姦のフラグが立ってたんですが、1.60ではVictimの枠にアクターを放り込んでも、「強姦」のフラグが立たないんですよね。
これは仕様が変わったとか、そういうことじゃなくて、単に強姦の被害者をセットする関数で、親スレッドの「IsAggressive」をtrueにし忘れてるだけなんじゃなかろうかと思ってるんですが……
しかしこんな重要な部分が誰からもフィードバックされずにいつまでも放置されてるなんてことは、ない、ですよねえ……？
何はともあれ、もう1.59cは公式ではダウンロードできなくなってるわけですから、1.60は新機能の追加より、まずは既存の機能の安定を最優先していただきたいものです。
