機械翻訳版

AMS2 専用サーバーは現在ベータ版ですが、このガイドの情報は WIPと見なされ、変更される可能性があります。現在、専用サーバーの Windows バージョンのみ使用可能です。

サーバーのダウンロードと更新

専用サーバーは、ゲームの所有者だけでなく、すべてのユーザーがSteamで利用できます。 したがって 、サーバーをどこからでもダウンロードして実行できます。WindowsとLinux(64ビットのみ)バージョンが利用可能です、 Steamは自動的に現在のプラットフォームに適したビルドをダウンロードします。
サーバーのコマンドライン バージョンのみを使用でき、構成に使用するテキスト ファイルが単純です。実行可能ファイルは、(Windows 上で)または専用サーバーcmd.elf (Linux 上) .exe と呼ばれます。Steam クライアントからダウンロードする サーバーは Steam のライブラリからダウンロードできます。ライブラリに移動し、ゲームからツールに切り替えて、オートモビリスタ2 – 専用サーバーを検索します。その後、それをインストールします。サーバーはコマンドラインアプリケーションなので、ライブラリから実行できますが、素敵な設定ウィンドウは表示されません。だから、最初に私はそれを設定することをお勧めします。また、サーバーが更新されるたびに構成を確認することを強くお勧めします。
Steam クライアントからダウンロードした場合、Steam UI で自動更新を無効にしていない限り、クライアントは自動的にサーバーを最新の状態に保ちます。他の Steam ライブラリアプリケーションと同じように動作します。

スチームCMD経由でのダウンロード

サーバーをダウンロードして実行するために、Steam クライアントをインストールする必要はありません。本格的なスチームクライアントの代わりに、SteamCMD ユーティリティがあります。完全な SteamCMDドキュメントとダウンロード リンクはこちらから入手できますdeveloper.valvesoftware.com https://。
SteamCMDによるインストールは、お使いのプラットフォームと OS の正確なバージョンによって若干異なります。今のところ SteamCMDは32 ビットのみなので、64 ビット Linux プラットフォームでは追加のステップを実行する必要があるかもしれません。たとえば、64 ビット Ubuntu ベースのテスト サーバーにインストールしたときの手順は次のとおりです。

その後、Steamユーザーとして実行している間にSteamCMD経由で専用サーバーをインストールします。

• cd スチームcmd
steamcmd.sh
• ログイン STEAM_USERNAME
• force_install_. /ams2
• app_update 413770 検証
• 終了

または、単一のコマンドですべてを実行することもできます

• ./steamcmd.sh + ログイン STEAM_USERNAME +force_install_dir ./ams2 +app_update 413770 検証 +終了 もちろん”force_install_dir”ディレクトリは完全にあなた次第です。

サーバーを更新する同じコマンドを実行し、それ自体で自動的に更新されません。
「ログイン」ステップには、プロジェクトCARS 2ゲームライセンスを受ける有効なSteamアカウント情報が必要です。パスワードとSteamガードコードを要求します。64 ビット Linux バイナリのみが提供されます。

サーバー構成

サーバーをインストールした後、サーバーを実行する前に、サーバーの構成をカスタマイズすることを強くお勧めします。構成は、サーバーの起動時に現在の作業ディレクトリからファイル ” server.cfg ” から読み取られます。コマンド ラインで、”-c” (または “–conf” または “–config”) オプションを使用して、構成ファイルの別の場所を指定できます。コマンド ライン引数の詳細については、”-h” または “-help” 引数を指定してサーバーを実行してください。

サンプル構成ファイル

既定では、その場所に構成ファイルはありません。サブディレクトリ “config_sample” には2 つの例があります。それらから始めることを強くお勧めします。通常は、まずconfig_sample/server.cfg” を “./server.cfgにコピーしてから編集します。
より高度な設定サンプルも用意されています。
“config_sample/server_with_lists.cfg”, “config_sample/ブラックリスト.cfg”
“config_sample/ホワイトリスト.cfg”。サーバーでブラックリストまたはホワイトリストを使用する場合は、これらのファイルを使用します。”server_with_lists.cfg” の名前を “サーバー.cfg” に変更することを忘れないでください。また、その構成のホワイトリストを編集してください – ホワイトリストセットがある場合、そのリストのユーザーのみがサーバーに接続でき、サンプル構成はリストに自分のIDだけを持っています。
サンプルのオプションは、通常、実行可能ファイルに組み込まれた既定のオプションと一致します。 そのため、 カスタマイズしない場合は、設定から完全に削除してください。唯一の例外はサンプルのブラックリストとホワイトリストで、それらはデフォルトでは空ですが、例を提供するために空でないリストに設定されています。
構成ファイル形式
config のフォーマットは JSON に基づいていますが、もう少し自由な形式で、個々のオプション間でカンマを省略することができ、構成全体をトップレベルの { }ブロックで囲む必要はありません。ファイル内でコメントを使用することもできますが、”//” に続くテキストは無視されます。
オプションの値を設定する構文は次のとおりです。
OPTION_NAME : OPTION_VALUE
オプション名は大文字と小文字を区別します。
文字列 (たとえば、すべてのオプション名) は二重引用符で囲む必要があります。 場合によっては、値をリストまたはオブジェクトにすることもできます。リスト オプション値の構文は次のとおりです。
OPTION_NAME : [ OPTION_VALUE_1 , OPTION_VALUE_2.] を選択し、オブジェクト オプション値の構文は次のとおりです。
OPTION_NAME : { KEY_1 : VALUE_1 , KEY_2 : VALUE_2 .. }

便利な設定オプション

次に、次のような便利なオプションを変更します。

より多くのオプションが利用可能 で、 サポートされているすべてのオプションがサンプル構成に含まれています(短いドキュメントを含む)。

HTTP API の構成

サーバーは、サーバーに関する情報、サーバー上で実行されているマルチプレイヤー セッション、サーバーでアクティブなプレイヤーと車両の詳細、およびゲームのセットアップを制御するサードパーティのツールを有効にする HTTP API を提供します。
デフォルトの構成では、HTTP API は無効になっています。この API を使用する場合は、”enableHttpApi”オプションの値を true に変更して APIを有効にします。次の追加オプションは、API の組み込みHTTP サーバーを制御します。
• “httpApiLogLevel” : HTTP APIロギングの詳細 – このレベル以上のメッセージのみがログに記録されます。グローバルな “logLevel” は引き続き適用されるため、一般的にサーバーよりも詳細に使用できます。デフォルトは “警告”です。
• “httpApiInterface” : サーバーがリスニング ソケットをバインドするインターフェイス。これは、文字列形式の IP アドレス、またはインターフェイスの OS 固有の名前のいずれかです。デフォルトは “127.0.01”で、http API はサーバーがローカルで実行されているコンピューターからのみアクセス可能になります( http://127.0.0.1..API をパブリックにする場合は、これを変更する必要があります (空の文字列は API をパブリック インターフェイスにバインドする必要があります)。
• “httpApiPort” : サーバーがリッスンするポート。デフォルトは 9000で、デフォルトではサーバーはローカルでのみアクセス可能http://127.0.0.1:9000。 9000がサーバー上で実行されている他のサービスと競合する場合は、これを変更する必要があります。
• “httpApiExtraHeaders”: サーバーの応答に出力する余分なヘッダー。 通常 、あなたはそれをそのままにしておくことができます。
サーバーは HTTP API アクセス レベルも実装します。各 HTTP API エンドポイントにはアクセス レベルが関連付けられており、このアクセス レベルにはフィルタリング ルールが定義されています。クライアントが特定の HTTP API エンドポイントにアクセスしようとすると、フィルターが処理され、受け入れフィルターがクライアントの資格情報と一致した場合、エンドポイントへのアクセスが許可されます。
各エンドポイントには、デフォルトのアクセスレベルが定義されており、「パブリック」、「プライベート」、「admin」のいずれかです。車両リストなどの既知の情報を返すエンドポイントは「パブリック」であり、現在のセッションに関する潜在的に機密性の高い情報を返すエンドポイントは「プライベート」であり、サーバーの状態を変更するエンドポイントは「admin」です。

ビルド 72 では、次の既定値が使用されています。
• パブリック: /api/ヘルプ, /api/バージョン, /api/リスト*
• プライベート: /ステータス、 /api/ログ、 /api/セッション/ステータス • 管理者: /api/セッション/キック, /api/セッション/set_attributes、 /api/セッション/set_next_attributes、/api/セッション/send_chat これらのデフォルトのアクセスレベルは、config オプションで上書きできます。 “httpApi アクセスレベル”これは、ワイルドカード パターンからアクセス レベル名へのマップであり、クエリのエンドポイントに一致する最初のパターンが使用されます。パターンには、通常の “?” と “” のワイルドカードを含めることができ、任意の文字またはゼロ以上の文字のシーケンスにそれぞれ一致します。”*” に似ていますが、スラッシュ文字と一致しない特殊な “%” ワイルドカードもあります。
HTTP API アクセス フィルター ルールを制御する次の構成オプション:
• “httpApiAccessFilters” :マスタマップは、アクセス レベル名からレベルのルールの一覧に割り当てられます。サンプル構成では、標準アクセス レベルの “public”、”private” 、および “admin”の規則を定義しますが、他のアクセス レベル名とルールを追加することもできます。

デフォルトの「パブリック」ルールは、すべて受け入れ、デフォルトの「プライベート」ルールは127.0.0.1または「プライベート」グループ内の任意のユーザーからのアクセスを受け入れ、デフォルトの「admin」ルールは127.0.0.1または「admin」グループ内の任意のユーザーからのアクセスを受け入れます。
• “httpApiUsers”: HTTP API ユーザー リストを定義します。パスワードはサーバ設定にプレーンテキストで保存されるため、ファイル自体が外部アクセスから適切に保護されていることを確認してください。
“httpApiGroups” : HTTP API グループを定義します。
サーバーは、2 種類の基本的なフィルタを実装します。IP フィルタを使用すると、特定の IP アドレスまたは範囲からの要求へのアクセスを制限したり、特定の IP 範囲からのアクセスを拒否したりできます。これは、ルールの種類”ip -accept “および “ip-reject” で使用されます。
サーバーは、基本 HTTP アクセス認証もサポートしています。これは、ルールタイプ「ユーザー」と「グループ」によって使用されます – 特定のユーザーとして認証されるクライアント、または特定のグループに属するユーザーのみがアクセスを許可されます。選択したツールから特定のユーザーとして認証する方法を理解するには、上記のウィキペディアのリンクを参照してください。ブラウザからHTTP APIを使用する場合、通常はユーザー名とパスワードの入力を求められます。または、URL にユーザとパスワードを指定することもできます (たとえば、このアドレスはデフォルトの設定で(コメントアウトされた) dave ユーザとして認証されます http://dave:letmein@127.0.0.1:9000/api/session/set_attributes?…。
基本アクセス認証を使用する場合、ユーザー名とパスワードはプレーンテキストで送信されますのでご注意ください。

リスト内の各フィルタールールは、次のプロパティを持つ JSON オブジェクトです。
• “type”: ルールの種類を定義する唯一の必須プロパティ。次のいずれかになります。
o “accept”:この要求を受け入れ、追加のチェックは行いません。o “拒否”: この要求を拒否し、追加のチェックはありません。
o “パスワード拒否”: この要求を拒否し、パスワードが必要であり、追加のチェックが行われず、クライアントに知らせます。
o “ip-accept ” : CIDR 表記の “ip” マスクと一致する場合は、この要求を受け入れます(たとえば、”192.168.1.0/24″ など)。
o “ip-reject” : CIDR 表記の “ip” マスクと一致する場合は、この要求を拒否します
(例: “192.168.1.0/24”)o “user”: 指定された「ユーザー」として認証された場合、この要求を受け入れます。
o “group”: 指定された”グループ”として認証された場合、この要求を受け入れます。
• “ip”: IP-accept およびip-reject ルールの IPアドレス マスク。
• “ユーザー”:ユーザー ルールのユーザー名。
• “グループ”: グループ ルールのグループ名。

サーバーの実行

サーバーを起動する最も簡単な方法は、単に専用のサーバーCmd実行可能ファイルを実行することです。Steam クライアントからの実行は、Steam での専用サーバーアプリケーションのセットアップ方法によりサポートされていません。
専用のサーバー マシン上で、より制御可能な方法で実行することが望ましいと思われます。いくつかのオプションは、ここに記載されています。

Linux でのバックグラウンドでのサーバーの実行、画面を使用する

Linux 環境で専用サーバーを実行する方法は多数あります。init.dスクリプトを作成し、通常のサーバ/デーモン コマンドを使用してスクリプトを制御できます。現時点では、OSによって若干異なる傾向があるため、このようなスクリプトは提供していません。
リモートで永久にログインしたままで SSH 経由でサーバーを実行する簡単な方法の 1 つは、”screen” を使用することです。Debian/Ubuntu ベースの OS では、インストールに “apt-get インストール画面” を使用します。
サーバーを初めて実行するには、次の手順を実行します。
• サーバーへの SSH
• スド とス チーム
• スクリプト /開発/null
• 画面(最初の画面を確認するためにEnterキーを押し、必要に応じて読み上げたい)
• 次のコマンドは、画面 o cd o cd steamcmd/ams2 o ./ DedicatedServerCmd 2>&1 | ティーサーバー.log  ctrl キーを押し、続いて d を押して画面からデタッチします。
• ctrl+d キーを押して画面を離れ、スクリプト/sudo/logout を残すためにもう少し時間を押します。

後でサーバーに再接続するには、次の手順を実行します。
• サーバーへの SSH
• スドと – 蒸気
• サーバー.log /ホーム/スチーム/steamcmd/ams2で確認できます。サーバーに再アタッチするには、次の手順に従ってください。
“スクリプト /dev/null” コマンドは、sudoセッションで画面を動作させる、やや醜いトリックであることに注意してください。

サーバーアドオン

サーバーには、いくつかの Lua アドオンが付属しています。これらのサーバーはコミュニティ開発者向けのサンプルとして使用されますが、基本的なサーバー スクリプトにも使用できます。特定のアドオンを有効または無効にするには、サーバー構成ファイルの”luaApiAddons” リストに名前を入力します。サンプル構成には、 “sms_motd” sms_rotate” アドオンが有効になっている状態と、 “sms_statsアドオンが存在するが無効になっています。
アドオンは、構成オプション”luaAddonRoot”によって設定されたディレクトリから読み取られます。
各アドオンは、その構成ファイルを”lua_config/ADDON_NAME_config.json”に格納します。
“lua_config”ディレクトリは、構成オプション “luaConfigRoot “によって他の何かに変更できます。最初はこのディレクトリは空です。各アドオンにはデフォルトの設定ファイルが付属しており、サーバが初めて有効な新しいアドオンで起動すると、デフォルトの設定ファイルがこの場所に自動的にコピーされます。そこで、新しいアドオンをカスタマイズするには、まずそのアドオンを “luaApiAddons”に追加し、サーバーを 1 回実行して停止し、次に構成ファイルを編集します。
各構成ファイルには、次の 2 つのエントリが含まれます。
• “version: 1” – この行を変更することはなく、アドオンが構成ファイルのフォーマットを大幅に変更したときにサーバーが気付くことを可能にします。その場合、サーバはカスタマイズされた設定をバックアップし、新しいデフォルト設定をコピーします。起動時に通知されます。
• “config : .” – 実際の構成で、アドオンの作成者が記述したドキュメントコメントを含みます。自由に編集してください。
ゲームに付属のアドオンは次のとおりです。

メッセージ・オブ・ザ・デイ :sms_motd

このアドオンはセッションを監視し、サーバーに参加したプレイヤーにメッセージを送信し、必要に応じてレースが終了したときにロビーに戻った後、すべてのプレイヤーにメッセージを送信します。このアドオン (または類似したもの) を常に有効にして、サーバーに参加しているプレイヤーが基本的な情報を知るようにしておくと便利です。
addon の構成はデフォルトで “lua_config/sms_motd_config.json” に格納され、次のフィールドを含めることができます。
• “motd” : 最初に印刷するメッセージ。デフォルトは空の文字列で、この場合、アドオンはサーバの構成からサーバ名を読み込む「SERVER NAMEへようこそ」を使用します。
• “send_setup” : アドオンは、サーバーのセットアップに関する情報を送信します。このリストは、セットアップのどの部分を送信するかを制御します。何も送信しない場合は空のままにするか、または設定の個々の部分を無効/有効にします。
o “コントロール” : これは、セッションのセットアップのどの部分がサーバーによって制御されているかをプレイヤーに伝えます
o “形式” : レース形式 (有効になっている場合、および練習/予選/レースラウンドの期間)
o “制限” : セットアップによって課されるさまざまな制限に関する情報をダンプします (ABS が許可されているかどうかなど、かなり長いので、この制限を無効にしておく必要があります)
o 「天気」:天気設定o “日付”に関する情報:開始日と時間の進行速度
• “send_when_returning_to_lobby” : true (既定値) に設定すると、アドオンは、レースが終了してロビーに戻ったときに、上記のメッセージをすべてのセッション メンバーに送信します。false に設定すると、新しい参加プレイヤーにのみ情報が送信されます。

セッションセットアップコントロールと設定回転: sms_rotate

このアドオンサーバーは、マスターサーバー構成の ” sessionAttributes”フィールドの上に改善されています。属性を設定する、より使いやすい方法を提供し、セッションの設定の固定ローテーションを構成することもできます。
これは、次のように動作します。
• デフォルトのセットアップ: これは、ローテーション内のすべてのセットアップの基礎として、”sessionAttributes”セットアップとサーバーの基本をアドオンに伝えます。
• ローテーション設定 (オプション): ローテーションが有効な場合、サーバは最初のセットアップで開始されます。その後、レースが終了し、全員がロビーに戻ったり、全員がサーバーを離れたりすると、次のセットアップに進みます。サーバーが一覧の最後のセットアップを行うと、最初のセットアップからもう一度開始されます。
ゲームに適用される設定は、アクティブな個別のローテーション設定で上書きされたデフォルト設定の組み合わせとして作成されます。
addon の構成は、デフォルトで”lua_config/sms_rotate_config.json”に格納され、次のフィールドを含めることができます。
• “persist_index” : true (既定値) に設定すると、サーバーはローテーション インデックスを定期的に保存し、サーバーがシャットダウンしたときに次のセットアップから続行します。false に設定すると、サーバーは再起動するたびにローテーションの最初のセットアップから開始します。既定では、 “lua_config/sms_rotate_data.json” に保存されているアドオンの永続データを削除することで、サーバーを最初のセットアップにリセットすることもできます。
• “default” : 既定のサーバーセットアップです。セットアップの形式は、以下に示す”サーバー.cfg”の “セッション属性” と似ています。
• “回転” : 回転設定の配列。空でない場合、サーバーはこれらの設定をローテーションし、それぞれを “既定の”設定を行い、その上に個別のローテーション設定を適用します。 「デフォルト」設定で設定された属性のみ、トラックID、VehicleModelId、VehicleClassIdを除く回転設定でも使用できます(すなわち、回転の各設定は、セットアップの異なる部分を制御することができます)

セットアップ形式

デフォルト設定とローテーション設定の形式は、「セッション属性 」に非常に似ています。具体的には、TrackId、VehicleModelId および VehicleClassId 属性では、数値識別子の代わりにトラック/車両/クラス名を使用でき、同じことが”enum”または”flag”属性にも当てはまります。
それに加えて：
• TrackId が指定されている場合: 強制するトラック。自動的に設定
1 にトラックを実行する場合、それ以外の場合は 0 に設定されます。
• 車両モデル ID が指定されている場合: 強制する車両。自動的に設定
[サーバーコントロール] 車両属性を 1 に設定し、FORCE_IDENTICAL_VEHICLESをフラグに設定します。それ以外の場合、アドオンは ServerControlsVehicleを 0 に設定し、FORCE_IDENTICAL_VEHICLES フラグをクリアします。
• VehicleClassId が指定されている場合: 強制するクラス。自動的に設定
サーバーコントロール車両クラスを 1 に設定し、FORCE_SAME_VEHICLE_CLASSをフラグに設定し、それ以外の場合はそれらをクリアします。つまり、設定属性TrackId、VehicleModelId または VehicleClassId 属性は、サーバー設定でそのトラック/モデル/クラスを自動的に強制します。対応する”ServerControlsXXX” 属性または関連する “フラグ” を直接設定しないでください。
これは最初は少し混乱しているように聞こえるかもしれませんが、デフォルトの設定を見直して少し試してみると、すべて非常に簡単です。要するに:
• デフォルト設定から「デフォルト」設定を取り、お好みのデフォルトサーバー設定に合わせて調整します。
• 回転する必要があるトラックを設定するには、個々の「ローテーション」設定を使用してください -最も簡単な設定では、実際には”TrackId”属性だけで設定の配列に過ぎず、サーバーはすべてのセッションの「デフォルト」設定を使用してトラックを回転させます。次に、もう少し実験を開始し、回転の一部のトラックに対して天候のオーバーライドなどを追加したり、クラスや特定の車両制限をそれらの一部に追加したりできます。
したがって 、最初に始めるべき基本的な設定は、同じデフォルト設定で4つのトラックをすべて回転させると、次のようになります。
“persist_index” : 真、
“デフォルト” : { ..デフォルトは…とそのままにし、
“回転” : [
{ “TrackId” : “ブランドハッチインディ” }
{ “TrackId” : “インターラゴス”}
{ “TrackId” : “ロンドリーナ ロング” }
{ “TrackId” : “キャドウェル パーク” }
]

セットアップ処理ライブラリ: lib_rotate

コミュニティアドオン開発者のサイドノートと同様に、セッションのセットアップを組み合わせてトラック/車両/クラスの制限を自動的に有効にするロジックは、sms_rotate”lib_rotate”と呼ばれるアドオンで利用できます。このアドオンが提供するこのクラスLibRotateを独自のアドオンで自由に使用するか、それを読んで Lua から属性を操作する方法を理解してください。次に、 “sms_rotate” アドオンはローテーション ロジックを追加し、適切なサーバー イベントを処理して、次のセットアップをいつ適用するかを知ります。

永続統計量: sms_stats

このアドオンは、サーバーとセッションの統計情報を追跡して保存します。統計はアドオンの永続ストレージに定期的に保存され、
/sms_stats_data.json.将来的には、アドオンは統計にアクセスするためのHTTP APIエンドポイントを証明しますが、現時点ではJSONデータを読み取ることは統計にアクセスする唯一の方法です。
このアドオンは、次の 3 つのフィールドを持つ簡単な構成を持っています。
• “history_length” : 履歴の長さの制限。最も古いセッションは履歴から削除されます。セッション履歴の追跡を完全に無効にするには、0 を使用します。無限の履歴には負の数を使用します。デフォルトは 50 です。
• “track_events” : 履歴はセッション イベントを追跡する必要がありますか?イベントリストは非常に長くなる可能性があるため、デフォルトでは無効になっています。追加の統計追跡の詳細のためにこれを有効にします。  ” “track_results:履歴トラックセッションの結果は必要ですか?既定で有効になっています。
データは 4 つのセクションに分かれています。
• “サーバー”: サーバー自体に関する情報。
• “セッション”: 各種セッション関連カウンタ。
• 「プレイヤー」: サーバーでプレイした個々のプレイヤーの統計が追跡されます。
• 「履歴」: サーバー上で再生されたすべてのセッションの履歴。

サーバー統計

サーバ統計サブテーブルには、次のフィールドが含まれます。
• “name”: 現在のサーバー名。
• 「稼働時間」: 現在のサーバの稼働時間(秒単位)。サーバーが再起動すると、ゼロにリセットされます。
• “” total_uptime” : サーバーの総稼働時間 (秒単位)。
• “” steam_disconnects” : サーバーが Steam から切断された時間。
• “steam_downtime” : Steamから切断された秒数。サーバーが再起動すると、ゼロにリセットされます。
• “total_steam_downtime” : Steamから切断された間の合計秒数。

セッション統計

セッションサブテーブルには、別のサブテーブルカウントが含まれ、それ以外は何も含みません。カウント サブテーブルは、サーバー上で実行されたセッションに関連するさまざまな集計カウンタを追跡します。
• “セッション”: サーバーで開始されたセッションの数。
• “ロビー”:サーバーで開始されたロビーの数。セッションとは異なり、レース後に戻ることは別のロビーとしてカウントされます。
• “stage_counts” : サーバー上で各ステージが開始された回数。これは、各ステージの種類に対して 1 つの数値フィールドを持つサブテーブルです。
• “stage_durations” :ステージカウント テーブルと同様ですが、再生時間の合計を個々のステージの秒単位で格納します。これはステージで実際にプレイに費やされた時間なので、ステージでレースが設定されているのに、ステージに到達する前にセッションが終了した場合、そのステージはここでカウントされません。ステージが早く終了した場合、そのステージに費やされた時間だけがカウントされます。
• “race_loads” : ロビーの数 ->移行の読み込み。
• “race_loads_done” : 積み込み回数 >競合遷移。
• “race_finishes”: 完全に終了したレースの数。レースが完全に終了する前にすべてのセッションメンバーが去った場合、そのセッションはここでカウントされません。
• “player_loads” : ロビー中のプレイヤー数 ->移行の読み込み。
• “player_loads_done” : ロード中のプレイヤー数 ->レース遷移。
• “player_finishes” : レースが完全に終了したときのプレイヤーの数。
• 「トラック」: トラックIDからロード中にトラックがアクティブだった回数にマップします。
• “track_distances” :トラック ID から に移動したメーター数 (すべてのプレイヤー参加者に対する集計) をマップします。
• 「車両」:車両IDから、積載中に車両が使用された回数にマッピングします。注:まだレースにJIPを持つプレイヤーをカウントしていません。
• “vehicle_distances”:車両IDから車両内を走行したメートル数までの地図(各ラップを更新)

プレイヤーの統計

「プレイヤー」サブテーブルは、プレイヤーのSteam IDから、プレイヤーに関する情報を含む構造へのマップです。各プレイヤーの構造は、次の要素で構成されます。
• 「名前」: プレイヤーの最後に知られている Steam プロファイル名。
• “last_joined” : プレイヤーが最後にサーバーに参加した時刻の秒数で、Unix の UTC 時間。
• “カウント”: 集計カウンタの統計を含むサブテーブル。
カウント テーブルには、次の情報が含まれます。
• “race_joins” : プレイヤーがサーバー上でレースに参加した回数。
• “race_loads” : ロビーの数 ->移行の読み込み。
• “race_loads_done” : 積み込み回数 > レース遷移。
• “” race_finishes”: 完全に終了したレースの数。
• 「トラック」:トラックIDから、プレイヤーがこのトラックにロードされた回数にマップします。注: JIPをカウントしていません。
• “track_distances” : トラック ID から、プレイヤーがこのトラックを移動したメーター数にマップします。
• 「車両」:車両IDから、プレイヤーがこの車両にロードされた回数にマップします。注: JIPをカウントしていません。
• “vehicle_distances” : 車両 ID からプレイヤーが車両を走行したメーター数にマップします。
• 「資格」:プレイヤーの資格の結果のためのカウンターとサブテーブル:
o 「状態」: 条件の最後にある状態名を、その状態に対するカウンターにマップします。したがって、このサブテーブルには、プレイヤーが予選ステージを適切に終了した回数と、プレイヤーが失格となった回数などが示されます。 o “ポジション”: 適格ポジションからそのポジションのカウンター、すなわち資格フィニッシュポジションヒストグラムに対するマッピング。
o “positions_per_size” : 資格の最後のプレイヤー数をマップし、予選位置からカウンターにマップします。 すなわち、 いくつかの資格仕上げポジションヒストグラム、各セッションサイズに対して1人が参加しました。
• 「レース」:プレイヤーのレース結果のためのカウンターを持つサブテーブル。予選テーブルと同じレイアウトですが、予選ステージではなくレースステージの統計があります。

歴史

履歴サブテーブルは配列で、ロビーからロード、ロードからロードバックまで、サーバーでプレイされるレースごとに1つのエントリがあります。最初のエントリーは最も古いレースです。エントリは、次の内容の構造です。
• “index”:レースに割り当てられた一意のインデックス。サーバー上で発生する最初の競合には、1 のインデックスが割り当てられ、連続する各競合が増加します。構成で履歴のクリーンアップが有効になっており、古いレースが履歴から削除された場合、レースはインデックスを再作成されません。
• “start_time” : レースのロビーが作成されたときの UNIX UTC タイムスタンプ。
• “end_time” : ゲームが終了すると、UNIX UTC タイムスタンプが表示されます。
• 「終了」: ゲームが完全に終了し、ロビーにロードされた場合(次のレースを開始する)、すべてのプレイヤーが前にサーバーを離れたためにゲームが途中で終了した場合はfalse。
• “setup”: ゲームの設定属性は、読み込みを開始したときに記録されます。すべての書き込み可能な属性はここに格納されます。
• “メンバー”:セッションのメンバーは、refidから次の値にマップされます。
o “index” “”、”steamid”、”name”:基本メンバーの詳細 o” join_time “: メンバーがセッションに参加した時間。 o ” leave_time” : メンバーがセッションを終了した時刻。 o “参加者 ID”: メンバーのプレイヤー参加者の ID。
o “セットアップ”:メンバーの属性VehicleId、リバリーId、レーススタットフラグ。
• “参加者”:このセッション中に出席した参加者は、参加者 ID からこれらの属性を持つ構造にマップします: RefId、名前、IsPlayer、VehicleId 、LiveryId。
• 「ステージ」:ステージ名から構造に、ステージの詳細をマップします: ○ o “start_time”,”end_time”:このステージの開始時刻と終了時間。
o 「イベント」:ステージに関連する参加者イベントの配列。各イベントには、イベントの詳細を含むフィールド、時間、参加者 id、およびフィールド名、refid、および有用な参加者情報を含むis_player event_nameフィールドがあります。ここに記録されるイベントは、ラップ、状態、インパクト、カットトラックスタート、カットトラックエンドです。既定の構成ではイベント track_events追跡が有効になっていません。 o “結果”:結果イベントのみが格納された”イベント”テーブルと同様です。各イベントには、時間、参加者 ID、イベント詳細を含む属性、および追加の参加者情報を含む名前、refid およびis_playerフィールドがあります。この情報に関心がない場合は、既定の構成で結果の追跡を有効にtrack_resultsします。

セッション設定属性

サーバー構成のいくつかの場所で、”セッション属性” について説明しました。具体的には、サーバー構成ファイル(“sessionAttributes”エントリ) に含まれ、”sms_rotate”アドオンの構成で使用されます。
セッション属性は、一般に、セッションのセットアップと状態に関する情報を含むデータの集まりです。プレイヤー属性と参加者(車両)属性もあります。
ここでは、サーバー設定に関連するセッション属性のみを文書化します – それらはゲームの設定を制御します。これらの属性は、ゲームのロビー UI で使用可能な設定を、標準ピア ツー ピア マルチプレイヤー セッションのホスト プレイヤーに密接に反映しています。
サンプル構成で使用できるセッション設定属性とデフォルト値 は次のとおりです。
• “ServerControlsTrack” :ホストプレイヤーは、0 に設定されている場合、トラックの選択を制御できます。1 に設定すると、ゲーム内のトラック選択が無効になり、サーバーがトラック選択を制御します。「トラック ID」も参照してください。
• “ServerControlsVehicleClass”:ホストプレイヤーは、ロビー車両選択画面を通過して車両クラスを変更できます(0に設定されている場合)。クラスを変更するプレイヤーを禁止するには、1 に設定します。「車両クラスID」および「フラグ」も参照してください。
(FORCE_SAME_VEHICLE_CLASS,1024)
• “ServerControlsVehicle”:プレイヤーは 0 に設定すると車両を変更できます。プレイヤーが車両を変更することを禁止するには、1 に設定します。 「車両モデルId」と「フラグ」(FORCE_IDENTICAL_VEHICLES,2)も参照してください。
• GridSize:グリッドのサイズは、セッション内の車両の最大数を指定します。ゲームでは、十分なグリッド位置がないトラックを選択することはできません。サーバー上で十分なグリッド位置を持たないトラックを強制する場合、動作は未定義であるため、この動作は定義されません。
• “MaxPlayers” : セッションに参加できるプレイヤーの最大数。これは、”GridSize” (車両数を制限する) とメイン サーバーの構成フィールド”maxPlayerCount”以下である必要があります。この数値が GridSizeより小さい場合は、AI車両によっては”Flags” に応じて、追加のグリッド位置が埋められます。
• “練習長”適格な長さ”,レースの長さ” : 個々のレースセッションの長さ。練習と予選は数分で、”RaceLengths”はラップです。
• “Flags” : これは最も難しい設定であり、数学を行う場合を除き、フラグを設定するには”sms_rotate”アドオンを使用することを強くお勧めします。ゲームの設定を制御するさまざまなフラグに対応する値を加算することで、フラグ番号が計算されます。これらのフラグは、カスタム車両のセットアップを可能にし、現実的なアシストを可能にし、同じ車両クラスを強制する場合
“ServerControlsVehicleClass”も1 に設定され、”GridSize”が”MaxPlayers”より大きい場合は AI 車とのセッションをフィルし、自動エンジンの開始を許可します。有効なフラグ値のリストは、api ルート/api/list/flagsを介して行われます。
• “破損タイプ” “タイヤウェアタイプ”燃料用途タイプ”, “ペナルティタイプ”, “AllowedViews”: “列挙型”属性。数値は、/api /list/enums/エンドポイントに記載されているさまざまな意味に対応します。この場合、値は意味する – 視覚的な唯一の損傷、タイヤの摩耗なし、燃料の使用オフ、罰則、任意のカメラビューが許可されています
• “TrackId” : サーバーによって設定されたトラックの数値 ID。 “ServerControlsTrack”が 1 に設定されている場合、プレイヤーはこの値から離れた場所でトラックを変更できません。リスト
すべてのトラックの/api/リスト/トラックエンドポイントで利用可能です、例えば-572148012は「ブランドハッチインディ」を意味します
• “VehicleClassId” : サーバーによって設定された車両クラスの数値 ID。 “ServerControlsVehicleClass”が 1 に設定され、FORCE_SAME_VEHICLE_CLASS フラグが設定されている場合、プレイヤーはこのクラスの車両のみを選択できます。すべてのクラスのリストは、 /api/ list/vehicle_classes/ で入手できます。
• “VehicleModelId” : サーバーによって設定された車両の数値 ID。場合
“ServerControlsVehicle”が 1 に設定され、FORCE_IDENTICAL_VEHICLES フラグが設定されると、プレイヤーは別の車を選択できません。すべての車両のリストは、/api/リスト/車両/エンドポイントで入手できます。
• “レースデイトアワー” :イベントセッションの開始時刻
• “レースウェザースロット” : ” レースウェザースロット1″, ” レースウェザースロット2″,
“RaceWeatherSlot3″ RaceWeatherSlot4”: 最大 4 つの気象スロット、および気象速度進行乗数。 すべての天気タイプのリストは、 /api/リスト/enums/天気で入手できます。
“ServerControls..”属性のどれでも、グローバル サーバー設定の”controlGameSetup”を true に設定する必要があります。

拡張セッション属性

Lua アドオンのコンテキストで使用する場合、セットアップ構造は拡張形式を使用できます。これは、 “sms_rotate” 構成にも関連しています。拡張フォーマットでは、これらの属性に対して数値識別子の代わりに名前を使用できます。
• Trackid
• 車両クラスID
• 車両モデルID
• すべての “列挙 “属性 – ダメージタイプ、 タイヤウェアタイプ、燃料用途タイプ、ペナルティタイプ、許可されたビュー、ウェザースロット1.ウェザースロット4
• すべての「フラグ」属性 – フラグ
たとえば、sms_rotate構成では、トラックをブランド ハッチに設定できます。
このようなインディ:
{ “TrackId” : “ブランドハッチインディ” }
サーバ設定ファイルで必要な数値を使用する代わりに、次の手順に従います。
{ “TrackId” : 1988984740 }

クラス、モデル、 列挙 型の属性は同様の方法で動作します – id/valueの代わりに名前を使用するだけです。 文字列 は多くの異なるフラグを 1 つの値に結合できるため、Flags 属性は少し複雑です。これを表す文字列は、単に個々のフラグの名前をコンマで区切った名前です。フラグ名とコンマの間にスペースを入れることはできません。 たとえば 、次の例を使用します。
{ “フラグ ” : FILL_SESSION_WITH_AI,ABS_ALLOWED,SC_ALLOWED,TCS_ALLOWED}
数値と文字列フラグ名をコンマで結合することもでき、数値を単独で使用する場合と同じように、個々のフラグを結合することもできます。

セッション属性リスト

多くの属性は、値に対して奇妙な数字を使用します。これらの数値は、コンテキストに応じて個々のトラック、車両などを表します。前述のように、拡張属性形式では、値の代わりに対応する名前を使用できます。
これらのリストについては、実行中のサーバーに対してクエリを実行できます。まず、config で HTTP API を有効にしてから、アドレスとポートをデフォルト値のままにする場合は、次の手順に従います。
• サーバーを起動します。
• 同じコンピューターで、任意の Web ブラウザーを開きます。
• このアドレスに移動します: http://127.0.0.1:9000/api/list/ ; このアドレスは、サーバー構成でhttpApiInterfaceまたはhttpApiPortを変更した場合に異なります。