約 1,636,954 件
https://w.atwiki.jp/swgstring/pages/122.html
タグ 翻訳待ち 175 no_survey_instance You cannot survey in an instance. 174 prop_not_in_combat You cannot equip this item while in combat. 176 survey_on_terrain_only The structure on which you are standing is interfering with your surveying results.
https://w.atwiki.jp/warband/pages/78.html
Prophesy of Pendor WB Mount Blade WBのMOD「Prophesy of Pendor」のページです。 無印版WikiのPOPのページより記事を移植中・・・。 #contehttps //i.imgur.com/JfP3jAM.jpg あらすじと紹介 ペンドールの建国より354年― 幾世代もの長きにわたり、この荒廃した地ペンドールを統べる王はない。 かつて人が成し得た偉大な業績は、今や神話として唄われ子守のお伽話で聞かされるのみ。 しかしその伝説は希望に満ちた予言のなかに生きている。 それは遥か岸の彼方より来て、一人の統治者の下にペンドールの諸侯を束ね、 この戦火に疲弊した地に再び平和と繁栄をもたらす英雄の物語。 志に相応しい力を持つ者は多くはない。 壮大な戦いが今まさに幕を開けようとしている。 剣を帯びよ、その想いとともに。 このペンドールの地に降り立ち、予言に挑め―君にその覚悟があるなら。 マップ、国家、コンパニオンを全て一新。新アイテム多数追加。 国家に属しない18種小派閥と大軍団。独立した騎士団。新しいクエストetc. Download Prophesy of Pendor WB Ver.3.9.5(Full) (2020,Mar,13) Prophesy of Pendor WB Ver.3.9.5 WARBAND Prophesy of Pendor WB Ver.3.9.4(Full) (2019,Jun) Prophesy of Pendor WB Ver.3.9.4 WARBAND Prophesy of Pendor WB Ver.3.9.4 Hotfix3差分ファイル Prophesy of Pendor WB Ver.3.9.3(Full) (2018,Dec) Prophesy of Pendor WB Ver.3.9.3 WARBAND Prophesy of Pendor WB Ver.3.8.4(Full) (2017,Jan) Prophesy of Pendor WB Ver.3.8.4 WARBAND Taleworlds該当記事 WARBAND - Prophesy of Pendor 日本語化プロジェクト Mount Blade日本語化Wiki Prophesy of Pendor WB 現在ver.3.9.5(2020/3/13リリース版) ほぼ完了！ https //www21.atwiki.jp/warband/pages/214.html 注：ver.3.9.5は2020年3月6日にリリースされた後、3月13日に更新されましたが、バージョン名が3.9.5.6(MODDB)だったり、3.9.5.1(PoP Wiki)だったり、3.9.5のまま(フォーラムなど)だったりとバージョンのナンバリングがまちまちなので、日本語化ファイル作成にあたっては3.9.5(2020/3/13リリース版)としています。 なお、現状のver.3.9.5をダウンロードすると必ず2020/3/13リリース版がダウンロードされますので、ver.3.9.5をリリース直後に導入した方以外は気にしないでください。 暫定日本語化ファイル(ver.3.9.5(2020/3/13リリース版)) https //ux.getuploader.com/MnB2/download/629 FAQ MODに日本語化ファイルを当てて言語を「Nihongo」にしたら文字がすべて透明になるんだけど Prophesy of Pendor WB データ類 ○ Prophesy of Pendor 3 Wiki - Wikia（外部サイトへ飛びます） google翻訳直通 ○ Prophesy of Pendor公式フォーラム（外部サイトへ飛びます） 注：以下のデータはやや古いので最新データを知りたい場合は上記の英語wikiを参照してください。 ○ ペンドールへはじめて来た方へヒント→ 別ページへ ○ キャラメイクの選択肢速見表→ 別ページへ ○ 国別兵士、傭兵ツリー→ 別ページへ ○ その他小派閥の紹介、兵科ツリー→ 別ページへ ○ コンパニオン紹介→ 別ページへ ○ 騎士団紹介→ 別ページへ ○ 射撃武器→ 別ページへ Ver.3.9特徴と変更点等 対応Warbandバージョン：1.165以降 セーブデータの互換性について 3.8 →3.9 なし 3.9 →3.91 なし 3.9.1 →3.92 なし 3.9.2 →3.9.3 なし 3.9.3 →3.9.4 なし 3.9.4 →3.9.5 なし + PoP Ver.3.9 変更点表示 以下英wikiへのリンク v3.9.0変更履歴 v3.9.1変更履歴 v3.9.2変更履歴 v3.9.3変更履歴 Ver.3.8特徴と変更点等 セーブデータの互換性について 3.7 →3.8 なし 3.8 →3.81 あり 3.81→3.82 あり 3.82→3.83 あり + PoP Ver.3.8 変更点表示 ソース https //forums.taleworlds.com/index.php/topic,126952.0.html バトルサイズの拡大、３つの新騎士団の追加。 色々と全面的に改良 デシャル軍、鎧・兜・服、武器、馬、宿屋、マップ、舞台、旗、メニューのイラスト、派閥・アイテム・兵種のバランス、闘技場、女性主人公でのプレイング、サウンドマスタリング、新サウンド。 その他多くの最適化・強化・バグ修正。 ゲームプレイ より大きく適応した戦場サイズ。 バトルサイズを100～450までに。 増援回数をより多く デシャル軍隊の改訂 派閥の再調整 多数の兵種のバランス調整 Phoenix order、不死鳥騎士団追加（2兵種） Shadow Wolves order、幻狼騎士団追加（2兵種） Scorpion Assassins order、蠍暗殺教団追加（2兵種） 以下のLeonion氏のTweakを採用 (1, 3.1, 3.2, 4, 5, 11, 20, 25, 26, 28, 29, 30, 32, 33, 35, 38, 40, 42, 43, 44) K0nr@d氏のアルゴリズムに基づき、全ての商品価格を正規化 新しい兜、ブーツ、ボルト、弓、矢、馬を追加 殆どのユニットを再作成、再調整。 ドラゴン・ドレイクがレイヴンスタン従歩兵からアップデートできる 非常に希少なアイテムがもっと贈られる 攻城戦の防御側のAIとプレイヤーの弾薬は補給される 商人たちが金を得るための新システム 村や隊商を襲うと名誉が下がるように キルカメラを更新 新たなオプションや勢力図システムを追加 コンパニオンが異性用の鎧を戦利品にしなくなった 弓騎兵の給料を騎兵より低く 傭兵の給料を200％→166％に 略奪品が満杯でもコンパニオンが自動装備可能に 背景関連 適応型の戦場(外観等倍、5倍、12倍) ※訳注：参加人数によって変化するっぽい エラクライの内装、外装、闘技場と訓練を新しく 14の街や城の攻城戦マップを刷新(Floris氏のを再加工) 地平線の背景とマップ境界を更新 より生き生きとした宿屋に。最大15人のランダム客、楽士、ラッシュアワー、そして文化に則した様々な衣装。 サーレオンの宿屋を新しく 宿屋や闘技場の出現位置を調整 街の背景を編集（トーバーの河、サーレオンの塔、ナルタルの灯台、帝国の町のテクスチャ、などなど） ナルタルの背景はサランのドロクバのに置き換え 空の背景を更新 宴にもっと多くの諸侯が入れるように 闘技場に女性 ビジュアル 鎧の追加、再加工 兜の追加、再加工 武器の追加、再加工 馬の追加、再加工 ブーツの追加、再加工 一般的な服を追加 トーナメントのアイテム見直し ※訳注：報酬か試合に使うアイテムのことかは不明 一部例外を除いた全ての鎧に男女それぞれのバージョンがある 全ての旗を刷新 さらに42の旗を追加 多くの兜のスキニング。首部分が滑らかに変形する 本の装丁、クオリス石、金の延べ棒、リュート、リラ、宝箱、普通のアイテム、家具、体、髪などなど更新 ゾンビの動的顔生成システムと新テクスチャ 血がいっぱい manu item用のバンプマップや反射マップ ※訳注：Manuってなんだ？ 背の高い草 画面転換時のフェードイン処理（切り替え可） マップ 個別の街アイコン 個別の城アイコン(Floris氏作) 正規化された旗 修正済みの橋 訓練場とウルフボウドの新マップアイコン マップテクスチャと形状を修正 顔の改良 男性の頭部形状を新しく 全NPCを再加工 より多くの良いテクスチャ 年寄りがよりしわくちゃに デシャルをより色黒に ノルドールの顔 ランダムな顔をより良く 顔と体の色を合わせる デシャル人が色黒に 闘技場のマッスルバディ ゾンビの動的顔生成 ゾンビのテクスチャを刷新 女性モデルを改善 UI 150以上のメニューイラスト(街や派閥、イベントやメニューの個別のイラスト) インターフェイス微調整 キルカウンター追加 一部メニュー修正 サウンド 女性の唸り声を追加 悪魔の断末魔追加 サウンド見直し・リマスター 宿の楽士 女性も命令を叫ぶ 最適化 サウンド最適化(使用に応じてOGGとFLACに分ける) メッシュ簡略化 節約のためテクスチャを書き換え ほぼすべてのアイテムのLODを作成 全ての古い未最適化素材を削除 品質向上のために全てのテクスチャのミップマップ追加 不要な時のアルファレイヤーを除去 内部の再加工(.brfファイルとアイテム順のソート) バグ修正 多くの文法、句読点、記述エラー 「すべてを変えた手紙（a letter that changed everything）」シナリオでの商人の選択は常に医師になった。 ※訳注：詳細不明 捕虜から雇用可能なカスタム騎士を造った。 ウルルベトルの弓を使ったバグ技 岩塩坑の出口 透明な岩塩坑 アイテムの複製 位置のあってないサーレオンの旗 位置のあってないメッテンハイムクロスボウ 城にグールの顔 解脱者の顔 頭に合わない兜 操作不可能な幾つかのドア 髪のテクスチャ 頭上の旗印のズレ 闘技場とトーナメント出場者がオリジナルのブーツを保持しない問題 パーティの名前バグ NPCパーティ内の下女を削除 美人顔の修正 賊の略奪の抑制問題 多くのアイテムのシェーダを修正 紋章付き鎧の裏の色を修正 v3.8.1 貴族の爵位名が戻ってた問題 デシャル女性の顔の修正 戦利品画面のデバッグメッセージと、ごちゃ混ぜの戦利品 光る馬 宿の酔っぱらいのバグった会話 ヴァイパーサーベルの幅 (K0nr@dによる修正) 切れた兜 ヴァイパーサーベル、蠍暗殺教団の剣、幻狼軍団の剣の鞘 店にトナメ賞品 FLCのランスのテクスチャ Crassusはもう帝国の絹の衣服を持たない※訳注 ヤノスの執事クラッシウスのことか？ リゼルディランは「彼女」と呼ばれるのを避けるため、男に戻せていなかった。 イモータルから兜を削除 増援回数微調整 Put back inventory chest in 550 maps. 不死鳥と幻狼の騎士団は一つの城にのみ与えられる。 v3.8.2 脱獄問題を修正 商人クエの間、参加している傭兵が自分を売り込むのを修正 諸侯になってないコンパニオンが戦闘後に関係がアップするのを修正 ミストマウンテンの侵略者としてカウントされるミストマウンテン族の修正 「befriending ミストマウンテン」についての勝利条件を削除 村内戦闘の戦利品バグ(Native由来)を修正 村内戦闘でのキルカウントを修正 イシュコマンの門外出撃を修正 兵士0人の部隊を修正 戦闘から離れていたり統治権を獲得しにでているのに再出現するコンパニオンの修正 新騎士団のバランス再調整 間違った場面で出る領地交換の会話を削除 宿のライティングとシェーダを作り直し（特にちらつく光） 闘技場とトーナメントの音楽をNativeのものに変更 宿のサウンド変更 略奪された村の音楽、及び同じように曲の最後まで流してしまうものの修正 エラクライに追加の戦利品 デシャルの闘技場以外から色黒の女性を削除 三賢者の巡視兵をマッチョ化 幾つかの剣の鞘を修正 暗殺者の覆面兜から生えるヒゲを修正 フィアーズベインの族長の兜を修正 誘拐された少女のハゲを修正 ベッカヴィア女王親衛隊の乗馬スキルを上げた 亡霊軍から青のすね当てを削除 tweak 44を入れ直し (派閥情報画面の元帥に関する項) 幾つかのテクスチャを改善 ２種の貴族服に代わるモデルを追加 一部の街の収納箱の戦利品を修正 アップグレード割引を33%ではなく90%に。(カスタム騎士装備の段階的アップグレードを促進するために、現在の装備にかけた費用と時間の90%を新たな装備に適用する) v3.8.3 増援回数の設定（攻城戦と通常戦は別々）を追加 しゃがんで槍を突き刺すための、頭上突き刺し攻撃（Hoboistice氏のsubmodより）を追加 二倍の妻のバグを修正 下女の解放時に関係が向上するのを修正 クイッグフェンの店を修正 音楽が正しくループするように 宿の雰囲気づくりは音楽ではなく音になった。 チート変更 アルアジズの狂った会話を修正 諸侯の基本収入を750→1000に クインの村近くで部隊が立ち往生する可能性を修正 転移する訓練場を修正 男性の体を改善 沢山の斧のテクスチャを改善 幾つかのドアや服のテクスチャを修正 不死鳥騎士団と蠍暗殺教団に新たなモデルの剣 城の床のシェーダを修正 闘技場に出るババアを削除 ヴァイパーサーベルと不死鳥騎士団の長剣の性能を変更 Leonion氏のtweak 3.2を修正 棒の防御動作を修正 矢やボルトの自動装備では、数より攻撃力が優先されるように 旅人の文章エラーを修正 会話中の金額エラーを修正 下馬命令のエラーを修正 スキニングを改良し、あれこれ最適化 守護帝国騎士の板金鎧(マント付き)の重量を修正 牢屋／宴にでる訓練所長／奴隷商を修正（できてたらいいな） 勝利後に時々全コンパニオンの関係が上がる「tweak 38」の修正 文法修正 Ver.3.7特徴と変更点等 セーブデータの互換性について 3.6xx→3.7xx なし 3.7→3.701 なし 3.701→3.702 なし 3.702→3.705 あり 3.705→3.706 なし + PoP Ver.3.7 変更点表示 ○!! NEW FEATURE Updated map and town/castle/village locations [新要素] 街、城、村の配置を刷新 ○!! NEW FEATURE added lady in waiting troop/events (talk to this troop type if they are in your party). [新要素] 女官（侍女）を部隊やイベントに追加（パーティにいれば話しかけることができる） ○!! NEW FEATURE Vastly Improved starting options with story arc that has game reprocussions. [新要素] ゲーム開始時のストーリーの選択肢を大きく改善、そのストーリーがゲームに影響する Rumor refresh rate 噂の更新頻度 jobs for bards and healers 吟遊詩人とヒーラー background NPC's that spawn based upon character choices. キャラの選択に基づいて関係NPCが生成 ○!! NEW graphical interface 新グラフィカルインターフェース ○!! NEW artwork for armors and weapons 装備・武器の新アートワーク ○!! NEW Troops and weapons 新しい部隊と武器 ○!! NEW Healer jobs from Travelers - income and renown 旅人から新ヒーラー職・・・収入と名声 ○!! New Bard Jobs from Innkeepers - income and party Morale for Bards (keep that lute in your possessions). 宿屋の主人から新吟遊詩人職・・・収入と吟遊詩人による部隊士気（リュートを所有しておくこと） ○!! NEW major spawn - ( - Spawn of Azi Dahaka) 新しい大規模スポーン （Azi Dahakaが登場） ○!! NEW Renegade Specialty spawns - added 25+ personality spawns that fit into the lore.. 新しい反逆者・・・物語に合わせて25以上の人物追加 ○!! NEW Two dozen Map Icons added that better reflects the type of NPC party. 20数個のマップアイコンを追加、NPC部隊のタイプをより正しく反映 ○!! NEW Additional Music Tracks 新ミュージックトラックを追加 ○!! NEW Change custom Knighthood Order can be changed to be all Female. 騎士団カスタマイズを刷新、全員女性にもできる ○!! NEW Creating Knighthood orders can cause negative relations with other orders. The lore matters.. 騎士団創設により他の騎士団と関係が険悪化することがある。物語との関係上。 ○Improved pendor line of troops ペンドール部隊ツリーの改善 ○Improved Mercenary line of troops.. top tier is Mercenary Sergeant. 傭兵部隊のツリー改善、最上位は傭兵軍曹 ○Modified fierdsvain berserker troops - visually and their abilities. フィアーズベインバーサーカーの修正・・・見た目と能力 ○Modified empire line of troops 帝国の部隊ツリー修正 ○Modified bandit spawns to provide more variance 追いはぎの生成を修正、より多様な生成 ○Modified vanskery spawns to provide more variance and challenge (not harder.. just different..ok. .a few are harder) ヴァンスケリーの生成を修正、より多様で挑戦的に（若干難易度も上昇） ○Modified many spawns and troops to increase variance and challenge (Bloodsword Witches, Iron Circle Knights, Red Fletchers, Northgard Rangers, Possessed Doomgards) 多くの生成部隊を修正、より多様で挑戦的に（血塗られた剣の魔女隊、鉄盟騎士、レッドフレッチャー、ノースガードレンジャー、悪霊憑きの破滅兵） ○Balanced out faction spawn rates for greater variation 勢力の生成頻度を調整しよりバリエーション豊かに ○Updated stats on weapons and armors 武器防具のステータスをアップデート ○Updated factional relations 勢力との関係性をアップデート ○Created new Jatu Troops and implemented upgrade path with Jatu mercs ヤツ族部隊を新しく作成、ヤツ族射手へのアップグレードパスを実装 ○Modified and increased the types of troops you can obtain from Red Brotherood Tavern Slavers. 宿屋のレッドブラザーフッドの奴隷商から入手できる部隊のタイプを修正・追加 ○Deity events now have both benefits and consequences ..depending. 神様のお告げイベントはメリットだけでなく、それに伴う事柄もある ○Implemented procedural system to create a few established knighthood orders in towns and castles. 街や城でいくつかの騎士団について設立する手続きを改善 ○Knighthood order Knights skills and equipment modified 騎士団の騎士のスキルと装備を修正 ○CKO sergeants prestige cost lowered 騎士団の従士の消費する名誉とコストを低減 ○CKO sergeants training made slightly less efficient. 騎士団の重視の訓練効果をわずかに低減 ○Modified the easter egg qualis gem gambling results. クオリス石ギャンブルの結果を修正 ○Reduced amount of troops for Knighthood renown quest 騎士団名声クエストの部隊数を低減 ○new face codes for many companions. 多くのコンパニオンのための新しい顔 Ver.3.6特徴と変更点等 以前のバージョンとセーブデータの互換性無し + PoP Ver.3.6 変更点表示 ○ Player Knighthood Order プレイヤーによる騎士団の新設ができるよ(wiki内騎士団解説を参照) ○ Player king mercenary parties from different factions 王様になると傭兵団を雇えるよ（大臣との会話に項目追加） ○ The Melitine Empire a new minor faction メリティネ帝国が部隊を率いてウロウロするよ（バークレーやメッテンヘイムと同様に） ○ New unique spawns from foreign factions (Mettenheim, Veccavia, Barclay, Melitine) メッテンへイム、ベッカヴィア、バークレー、メリティネの新しいユニットが登場するよ ○ Order ranks and stronghold 騎士団（既存）に加入すると、階級を与えられて頑張ると昇進するよ。あと騎士団の砦もあるよ（団長昇進クエストにて） ○ New Order quests (tournament, challenge, rivalry, GM quest) 騎士団のクエストを追加したよ（トーナメントで勝って来い、騎士団兵を率いて名を挙げろ、ライバル騎士団をぶちのめせ、団長昇進） ○ Randomly generated minor knighthood Orders; sometimes created by lords NPC諸侯が小規模騎士団を設立することもあるよ(wiki内騎士団解説を参照) ○ Numerous new Order, Noldor and other map dialogs ○ Prettier female faces (corprus OSP) 美人顔を追加したよ、女だけだよ ○ Large minor faction spawns sometimes siege and sack nearby towns. 大軍団はたまに街を襲撃するよ、占領はしないけど守備兵をもっさり殺されるよ ○ Order war parties of the main kingdom Orders sometimes spawn and actively assist their kingdom 派閥のメイン騎士団は、その派閥の援助をする為に150人くらいの戦団を率いて参戦するよ、とってもうざいよ ○ Kings sometimes found Orders if they don't have a chapterhouse yet もしまだ会所を持ってなければ、王はたまに騎士団を設立するよ（未確認） ○ Recruiting Order Sergeants similar to recruiting Order Knights 騎士団の従士格は騎士と同様に、特定の一般兵から名誉を消費して任命できるよ ○ Liege lord troops culture switchable to the player's kingdom culture through a dialog. 配下の諸侯との会話で、諸侯の文化をプレイヤーの文化へ変更させることができるよ（率いる兵の文化のことだよ、でも文句言われて友好度さがるよ） ○ Can give troops to your kingdom or your village militias (if they have 100 troops) 自国の、もしくは自分の村のパトロール隊に兵を与えることが出来るよ、但し100人以下の場合のみ ○ Traveler NPCs in taverns give locations of the two booksellers. 酒場の旅人から本屋の居場所を教えてもらえるよ、有料で ○ Sell all prisoners dialog 酒場の奴隷商の会話で、全ての捕虜を売るダイアログを追加したよ、便利だね ○ Ramun gives locations of random unhired companions if you sell him slaves ラムンはまだ雇っていないコンパニオンの場所を教えてくれるよ（未確認） ○ Talk to Guildmaster menu option for towns 街のメニューにギルドマスターに会うというダイアログを追加したよ、もっと早くしてほしかったね ○ Order and minor factions relations report within the faction relation report 騎士団と小派閥の関係を一覧にしてレポートから確認できるようにしたよ ○ Ability to rename your party and Order (Camp- Take action) 自分の部隊に名前をつけることができるよ、厨二心をくすぐられるね ○ Heretics and Snakes drop books that are useful to Orders (membership required) 異教徒とスネーク教は戦利品として本を落とすようになったよ（所属騎士団にあげるとお金とか貢献度とかもらえるよ） ○ Siege defense inventory chest at defender spawn point (to refill ammo and change gear) 防衛戦でも荷物にアクセスできるようになったよ、リスポンポイントに箱があるよ（場所が分かり難いので使い辛いけどね） ○ Camp menu review and drill your troops キャンプメニューに、兵を並ばせて閲兵する、訓練するを追加したよ（訓練する drill ってのは未確認というか無い） ○ Renown costs for Order knights increased a lot and depend on relations as well as honor 騎士団の設立時の名誉コストを増やしたよ、関係は名声によって変わるよ ○ Updated Order factions hostility matrix 騎士団派閥の敵愾心のベースをアップデートしたよ（よくわかんねぇけど、関係の初期値を変更したんじゃない？） ○ No more instaloss with Scorpion Assassin ambushes. Only one or two spawned. 蠍暗殺兵の待ち伏せ襲撃で5対1とか無いわ～減らしとくわ（3人になっている） ○ Valkyries' axes were too short, they got a better weapon. ヴァルキリーの竜の背骨の斧って短過ぎて当たらなくない？マシなのに変えるわ（レディヴァルキリーはまだ持ってるけどね） ○ Get -2 RTR if attacking during a truce 休戦中のに攻撃すると統治権を-2するよ。（未確認） ○ Removed horses from D'Shar Bowmen and Dervishes デシャル射手と弓兵から馬を取り上げるよ（熟練弓は馬持ってる） ○ Changed Elixirs to give half the stats bonuses from the 4th use onwards エリクサーの効果を4回目から半減させたよ ○ Order bounty quest quota tweaked down 騎士団の賞金首クエストの対象人数を下げたよ ○ Spawn small Noldor patrols more frequently (now in line with other minor factions, every 33 hours) ノルド-ルのパトロール隊の出現頻度をマシマシにしたよ、4～5部隊出てくるよ ○ Tweaked up the endgame low spawning rates of Mysts and Heretics ゲーム終盤のミストマウンテンと異教徒の発生率を下げたよ ○ Limited generated Order knights and sergeants in garrisons to about 30 and 50 - there were too many in the end game 守備兵として勝手に追加される騎士団の騎士と従士格の増加を、各自30、50に制限したよ（ゲーム終盤には増えすぎて城落とせなくなるからね） ○ Leth doesn't let you see his equipment until you are level 30 リゼルディランの装備はあなたがLv.30にならないと触れないよ、弓を奪ってポイは出来ないよ ○ Get less payment as a kingdom merc, it was too exploitable. 傭兵契約時の給金を減らしたよ、取り過ぎてたよ ○ Nerfed a notch the Fierds party sizes フィアーズベインのパーティーサイズの段階を弱めたよ（兵の増加率のことだと思う） ○ Small increase to rare spawn spawning rates (since they get mobbed by kingdoms too often) レアな大軍団の発生を少し増やしたよ（度々、NPCの軍隊に集団でボコられてプレイヤーが倒す間もないからね） ○ Bugfix Order sergeants had autocalc values of 0 ○ Bugfix (Native bug) Companion missions lasted half the time advertised ○ Bugfix (Native bug) Loaned companions (quest) disappeared if the lender lord disappeared ○ Bugfix The trading villagers (quest) would rarely turn into an ordinary villager party ○ Bugfix (Native bug) Gained 3x3 RTR instead of 3 for peace, and 0 RTR instead of 15 for marriage ○ Bugfix Fixed Notes and other headings positions ○ Bugfix Wolfbode now counts towards Myst supression クラッシュ問題と対応方法 快適な動作のためにの一番下参照。また、スレの過去ログにもいろいろな解決策が出ています。 ATIカード問題についてはこちら TaleworldsのPOPWB Forums Prophesy of Pendor(Moderators saxondragon,sairtar,MitchyMatt) 以下は非公式のクラッシュ問題解決スレ Fix for some crashes (32 bit OS)... NOT A BUG THREAD - READ 1st POST Known things that will cause you to CTD or Lag heavily! Prophesy of Pendor 4 61 名前：名無しさんの野望[sage] 投稿日：2011/01/18(火) 12 03 58 ID xjtT53eV Prophesy of Pendor4.0プロジェクトが始動 http //forums.taleworlds.com/index.php/topic,154493.0.html 物語の舞台はペンドール統一後20～25年後、蛇神教団らが跋扈する南方への征伐軍派遣が主軸。 新しいマップ、勢力、賊、コンパの子供達や新しいコンパ、騎士団が登場。 Prophesy of Pendor 4.0 ≪ on January 16, 2011, 04 26 15 PM ≫ Hello everyone, First, thank you for your support and love of this very interesting project that has been growing every month since November 2008. It has been your posts, PM's, and overall positive feedback that has fueled us to do what we have done to create this offering. I am pleased to announce that Prophesy of Pendor 4.0 is moving forward. I wanted to give everyone some insight on what is happening. The next version of this collaborative effort will mark a significant change. The setting will be some 20-25 years AFTER the unification of Pendor, where the "King/Queen" of Pendor in an alliance with the Noldor, sends an invasion force south to the lands of the old Empire to defeat the abomination known as the Snake Goddess once and for all. There will be a new map, new factions, new and old spawns, children of the companions you have come to love and hate, new companions, new knighthood orders, and twists and turns that will both surprise and entertain. We are combining the many developers, artists and coders who have contributed to this effort so far with a classroom of game design students to bring forth a conclusion to this long saga. Stay tuned for more stories, detailed histories, artwork, concept work, and status updates. Kindest regards, Saxondragon ■上記スレ内での開発スタッフらによる続報のまとめ プレイヤーはペンドールを統一した王の息子/娘となる。はじめにプレイヤーは、どのように統一がなされたかを選択する。 開発期間は数ヶ月で、年単位ではない。最初のものを除けばどれもだいたい５～７ヶ月サイクルだった。 POP３とは異なり、悪党キャラとしてプレイできる可能性はない。プレイヤーの役割は善玉の聖騎士であって悪党ではない。 ペンドールのサーガはこれで完結する予定。細かな調整変更はあるだろうが、SaxonDragon氏が許可しない限りはその先の開発予定はない。 まだプランニング段階なので細かい質問には答えられない。 今のところPOP3.2に取り組んでいるのでPOP4はまだごく初期段階に過ぎない。 POP4リリース後もPOP3の開発を続けるかは不明。必要だと思えばするかもしれない。 (2013,May)New!! 「うん、今のところは保留中だよ、だから、のんびりリラックスしてVer.3.6を楽しんでいってね」MitchyMatt氏 コメント ちょっと質問です。 兵力の少なくなった諸侯が城に引きこもって出てきません。 かなり時間を経たせても兵力は回復せず、ずっとそのままです。 色んなキーワードでググってみたけど該当無し。 ペンドールもしくはネイティブの仕様・バグなのかも分かりません。 なにか知っている人がいたらご教授お願いします。 -- (名無しさん) 2020-05-10 18 55 30 傭兵隊長時代は儲かりすぎて濡れ手に粟なのに、領地持ちになった瞬間からどんどん赤字が増えていくのは何故なのか -- (名無しさん) 2020-05-18 07 07 13 2でもこのmod出ないかな -- (名無しさん) 2020-06-22 23 16 24 1https //forums.taleworlds.com/index.php?threads/pop-planned-for-bannerlord.407392/page-2#post-9633952 計画はあるみたいよ -- (名無しさん) 2021-02-08 17 01 12 初期から好感度マイナスの黒檀篭手とか黎明騎士とかは地道に巡回部隊に加勢したりして好感度稼ぐしかないですかね？ 他に何か手段無いでしょうか？ -- (名無しさん) 2021-04-04 15 05 23 確か夕暮騎士団は名前は忘れたけど特殊な本を門番にあげることで 少し友好度が上がった記憶はあるけどその方法しか知らないかな。 友好度がマイナスからプラスになれば城内にいる門番からクエストを 受けられてそこから友好度上げは出来るんだけどもね -- (名無しさん) 2021-04-05 14 51 21 初期からマイナスの所との仲改善クエストとかもほしいところですね。 -- (名無しさん) 2021-04-12 17 18 45 ctaにあるような同行機能と初期陣形機能が追加されてないんですけどなんとかならないですかね -- (名無しさん) 2021-04-19 20 24 57 NPCの捕虜採用はかなり変だね 大群と戦うと最後の方がシンガリア兵だけになる -- (名無しさん) 2022-03-19 23 59 27 日本語化ファイルで、某掲示板でいくつかご指摘のあった箇所を修正しました。 -- (名無しさん) 2022-03-21 14 34 39 アップデートしたいけど、互換性なしかな？今まで育ててきたキャラ、装備をリスタートするのは厳しい・・・。 -- (名無しさん) 2022-05-05 17 06 07 PoPの紹介ページにバージョン間の互換情報が載っていますが、セーブデータの互換は期待しない方がいいですよ。 -- (名無しさん) 2022-05-05 21 16 32 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/nmrih/pages/70.html
マッピング：キーパッド まずprop_dynamicでmodels/props_lab/keypad.mdlを配置する。 そしてそのモデルを囲むようにテクスチャtools/tooltriggerでブラシを作成し、trigger_keypadにTie to Entityする。 これに正解のパスワードを設定し、後は 正解 OnTrigger 失敗 OnIncorrectCode の出力をさせればいいだけ。 注意 正解のパスワードが同一のキーパッドを複数配置すると、バグにより1個が正解した時に全てが成功した扱いになってしまう。 Tips models/props_lab/keypad.mdlのスキンは、0がディスプレイ空白、1が「ACCESS」、2が「ERROR」。効果音と共に利用することで、よりプレイヤーに優しいキーパッドになる。
https://w.atwiki.jp/nmrih/pages/74.html
マッピング：ビジュアル強化Tips このページでは、マップの見た目を強化する様々なエンティティや方法を紹介します。 軽く知ったかぶりして書いた部分もあるので絶対正しいとは思わないでおいてください。 説明が長くて細かい項目ほどその傾向が強いです。 [ポ]＝ポイントエンティティ、[ブ]＝ブラシエンティティ マッピング：ビジュアル強化Tips 全般[ポ] env_cubemap - キューブマップを撮影するポイント [ポ] color_correction - 画面全体の色調を調整する [ブ] func_reflective_glass - リアルタイム反射の鏡 [ブ] func_precipitation - 雨・雪を降らせる [ポ] env_fire - 炎 [ポ] env_spark - 火花 [ポ] env_explosion - 爆発 [ポ] info_particle_system - パーティクル [ポ] env_wind - マップ全体の風を設定する [ポ] env_tonemap_controller ライティング・ライトの表現[ポ] light_environment - 屋外の環境光を設定する [ポ] light - 全方位を照らすライト [ポ] light_spot - ある一点を照らすライト [ポ] light_dynamic - ダイナミックライト [ポ] point_spotlight - サーチライトのような光の道筋 [ポ] env_sprite - 常にこっちを向いているテクスチャ [ポ] env_sun - 太陽（たまに月） [ポ] env_lightglow - トンネルの出口とかで眩しくなるやつ [ポ] env_projectedtexture - プロジェクターのようなもの [ポ] shadow_control - マップ全体のダイナミックシャドウを設定する [ポ] info_lighting - prop_staticへの光の当たり方を決めるポイントを調整する 煙・霧・埃などの表現[ポ] env_fog_controller - マップ全体のフォグを設定する [ブ] func_dustcloud - もやっとした霧・砂埃（砂嵐）を発生させる [ポ] env_dustpuff - もやっとした霧・砂埃を発生させる（？） [ポ] env_steam - もくもくと上がる煙・陽炎を発生させる [ブ] func_smokevolume - もくもくとした煙を発生させる [ポ] env_smokestack - もくもくと上がる煙を発生させる（？） [ブ] func_dustmotes - ぱらぱらと舞う埃を発生させる ロープ[ポ] move_rope [ポ] keyframe_rope 効果音・環境音・BGMなど[ポ] ambient_generic [ポ] env_soundscape エンティティ以外の話ライティング関係のコンパイルオプション ライトマップスケール マップの最適化 カスタムコンテンツ 円柱や球体などの曲面を滑らかに見せる マップに草を生やす 「点」でなく「面」で照らすライト スカイボックスの回転 スカイボックスや環境光などの調和 prop_staticのVertex Lightingについて 3Dスカイボックス 全般 [ポ] env_cubemap - キューブマップを撮影するポイント https //developer.valvesoftware.com/wiki/Env_cubemap テクスチャに風景が映り込む時、その風景として使用されるのが全方位を6枚の画像で表したキューブマップ。 これは予めゲーム内で（マップ作者が）撮影するもので、自動的にbspに埋め込まれる。撮影方法は後述。 つまりその反射する風景は、周りの環境が変化（壁の破壊や、ライトのオン/オフなど）しても変わらないことに注意が必要。 ブラシの反射に使用されるenv_cubemapはコンパイル時に確定され、例えそのブラシが移動しても推移はしない。 モデルの反射には、常に最短距離にあるenv_cubemapが使用される。 フェードなどはせず、モデルが2つのenv_cubemapの中間地点を通過した時点で瞬時に切り替わる。 Sourceエンジンでは、水面のテクスチャと、鏡（func_reflective_glass）以外の反射は全てキューブマップ反射である。 つまり、表面の「反射≒光沢感」の表現にはほぼ必ずキューブマップが使われるということ。 このエンティティをいくつ・どこに配置するかだが、明確なルールというのは存在しない。 よっぽど変な配置にしない限り不自然にはならないので、そこまで神経質になる必要はない。 ちなみにマップを作りながら置いていくより、ほぼ作り終わってから最後に置くほうが良い。 屋外では適当に置いてしまえばOK。特に理由が無ければプレイヤーのアイレベルである地上64ユニットがおすすめ。 屋内では、1部屋につき1つというのが定番。部屋の構造やサイズに応じて増やそう。 天井がプレイヤー2人が縦に入らないぐらいの高さの部屋では、アイレベルに配置するより、 地面と天井のちょうど中心に配置するほうがより自然に見えるだろう。 また単一/複数のブラシの面をpickすることができる。pickされた面の反射にはそのenv_cubemapのキューブマップが使用される。 窓は一般的に反射した風景が目立ちやすいので、すぐ前にenv_cubemapを配置してpickしておくといいだろう。 pickされていない面は、コンパイル時に最短距離のenv_cubemapを使用する。基本的にpickするのは窓と水面（下記）だけで良いが、 同一面（ここでは高さが同じという意味）を複数のブラシが構成している場合に、 使用されるenv_cubemapが異なっている「境界」が出来て目立ってしまうことがある。 この場合は付近のenv_cubemapを削除し1個に絞るか、もしくは手作業で面をpickしていくしかない。（前者はあまりお勧めしない） またその面の裏側にあるenv_cubemapが使われてしまっている場合にも手動でpickしてやる必要がある。 また水面も、設定やテクスチャによってはキューブマップ反射が使われることがあるので、 必ず水面上（最適な高さは場合によって異なるのでなんとも言えない）の中心近くにenv_cubemapを配置してpickすること。 複数のブラシを繋げて単一の水面を表現するときは、それぞれにenv_cubemapを配置するよりも、 単一のenv_cubemapで複数pickしたほうが自然に見える場合が多い。これは上記の「境界」が目立ってしまうことが多いから。 逆に、それぞれにenv_cubemapを配置したほうが良いのは、 「地下水路・洞窟など単一水面上で場所によって（反射すべき）景色が大きく変わる場合」である。 ちなみにそれぞれのenv_cubemapで解像度を変更できる。 大きくすればするほど反射する風景が精細になるが、その分ファイルサイズが大きくなるので注意しよう。多少は負荷も上がる。 また解像度が高いということは細かい部分まで見えてしまうということなので、逆に不自然になってしまうこともある。 デフォルトの解像度は多くの状況においてバランスが取れている。悩むようならば変更しなくて良い。 言葉で説明すると非常に難しく感じられるが、一度理解してしまえば単純な話である。 いまいち理解できないという人は、公式マップでSako85を持って歩き回ってみるといい。スコープの反射に注目。 ※キューブマップはコンパイル毎に、HDR用とLDR（非HDR）用のものをゲーム内で撮影しなければいけない。 https //developer.valvesoftware.com/wiki/Cubemaps [ポ] color_correction - 画面全体の色調を調整する https //developer.valvesoftware.com/wiki/Color_correction_%28entity%29 カラーコレクション略してカラコレ ゲーム内で実際に試しながら調整できるので非常にお手軽。 ただし実際の効果が作った時（調整した時）より強くなってしまうことがあるらしい。 （その場合の対処法も下のリンクに書いてある） 仕上げの際は是非試してみよう。ちょっと色調を変えたいけど、ライトを弄るのは面倒くさいなんて時にも使える。 これを使っても希望の色調にできないというときは手間はかかるがライトの設定を見直していこう。 ただし設定で色調整をオフにしているプレイヤーには効果が無いので注意。 https //developer.valvesoftware.com/wiki/Color_correction ブラシエンティティはcolor_collection_volume。面倒なので別項目作りません。 https //developer.valvesoftware.com/wiki/Color_correction_volume [ブ] func_reflective_glass - リアルタイム反射の鏡 https //developer.valvesoftware.com/wiki/Func_reflective_glass あまり安定したエンティティでは無いので、配置によっては鏡が乱れてしまうことがある。 それと言うまでもないかもしれないが、映り込むオブジェクトが多い場合はその分負荷もかかる。 [ブ] func_precipitation - 雨・雪を降らせる https //developer.valvesoftware.com/wiki/Func_precipitation Precipitation Type：Snowは謎の雨っぽい何かなので雪はSnowfallのほうを使おう。 Density最大でも物足りない時は、ブラシを複製して重ねてみよう。 [ポ] env_fire - 炎 https //developer.valvesoftware.com/wiki/Env_fire 説明不要。lightと一緒に置くと良い。 [ポ] env_spark - 火花 https //developer.valvesoftware.com/wiki/Env_spark 説明不要。 [ポ] env_explosion - 爆発 https //developer.valvesoftware.com/wiki/Env_explosion どっかーん [ポ] info_particle_system - パーティクル https //developer.valvesoftware.com/wiki/Info_particle_system パーティクルというのは、ある地点から振ってくる枯れ葉であったり、ある地点から空に向かう炎だったりする。 もう少し詳しく説明すると。これは、パーティクルエディターで、素材の画像を「どんな風に出現させる（頻度や位置など）」 「どんな風に消滅させる（消滅までの時間やフェードアウトなど）」「どんな風に動かす（速度や方向など）」 「重力の影響を受ける/受けない」「地面やプレイヤー等と接触する/しない」などの設定をしてやることで、 動くパーティクルになる。素材の画像と、様々な「挙動の設定」が組み合わさって1つの動くパーティクルになっているのである。 やはりと言うか、パーティクルディターは非常に複雑で難しいが、希望であれば自分でパーティクルを作成することもできる。 とりあえず自分に作れるか判断したい場合はこの動画を見ると良い。 https //www.youtube.com/watch?v=70GhO6z5aKM 40分あるが、これを見れば使いこなせるようになるというようなものでもない。 env_fireやenv_steamなどもパーティクルの一種だが、使用頻度が高く、ハンマーエディタ内で 色々パラメーターを弄れたほうが便利なので独立したエンティティになっているというわけ。 NMRiHでよく見かけるinfo_particle_systemとしてはパトカーの回転灯がある。 [ポ] env_wind - マップ全体の風を設定する https //developer.valvesoftware.com/wiki/Env_wind 詳細不明。主にロープを揺らす用？ [ポ] env_tonemap_controller https //developer.valvesoftware.com/wiki/Env_tonemap_controller HDRについて定義するエンティティだが私はまだ使ったことがないので詳しいことはよく分からない。 どうやら光彩の開け閉め（のシミュレーション）のしきい値を設定するらしい。 そもそも普通は皆デフォルトのHDRに合わせてライティングを組んでいると思うので、基本的には使う必要は無いだろう。 どうしてもHDRの挙動が鼻についた時は使ってみると良いかと。下のページも参考に。 https //developer.valvesoftware.com/wiki/HDR_Lighting_Settings HDRというよりマップ全体の色調が気に入らない？ならばcolor_correctionへGO ライティング・ライトの表現 [ポ] light_environment - 屋外の環境光を設定する https //developer.valvesoftware.com/wiki/Light_environment 日中ならば太陽光、夜中ならば月明かりの色調や角度を設定する。ライトマップに焼きこまれる。このエンティティによって設定されるライトは、スカイボックステクスチャを貼った場所全てが光源になる。 屋外中心のマップなら全体の雰囲気を決める大切なエンティティ。このエンティティの設定によって時間帯だけでなく、（雰囲気的な）気温や湿度の表現もできる。ただし、やはりスカイボックスのテクスチャと調和するように設定しなければならない。透き通った青空なのに屋外が真っ暗では怖いし、逆も然り。また、「スカイボックスに見える太陽/月の方向に影が伸びている」等といった事態も避けるようにしたい。 なお初心者が良くやりがちな手抜きとして、「Pitch Yaw Roll,PitchとBrightnessしか弄らない」というのが挙げられる。確かにBrightnessだけで光の色や明るさは一応設定できるのだが、よりリアルで美しい自然な環境光の表現には 他のKeyvalueでの調整が不可欠である。詳しくは下で説明するが、重要なのはBrightnessよりもAmbientである。 + 太陽の角度の設定 太陽の角度の設定 まずPitch Yaw Roll (Y Z X)のYaw(Z)で太陽の方角を指定する。これのPitch(Y)は無視されるし、Roll(X)も普通は使わないので0で良い。次にPitchで太陽の高度を指定する。マイナスの値で上からの光、プラスの値で下からの光になる。後者の使い道はあまり無い。 方角はスカイボックスの太陽に合わせてしっかり合わせよう。多少ずらすぐらいならバレにくい。高度は方角より自由度がある。 + SunSpreadAngleについて SunSpreadAngleについて 言葉で説明するよりこのリンクの画像を見てもらったほうが早いだろう。 http //www.nodraw.net/2011/01/sunspreadangle/ 太陽が出ている時間帯のマップでは3～5あたりが使いやすい値だが、もっと数値を下げたほうがいい場合もあるし、逆もある。太陽がかんかんと照りつける昼間を表現したければ思い切って0にしてしまう手もある。 夜のマップでBrightnessを1以上にするなら数値を大きめにしたほうが良い。（Brightnessが0だと方向のある陰影はつかない） + Ambientについて Ambientについて スカイボックスの全方向からマップ全体を包み込むように照らしてくる光。 + Brightnessについて Brightnessについて 上で説明した、指定した方角・高度からのみ平行に照らしてくる光。基本的に太陽または月明かりを表現するのに使う。 曇り・霧の日や、夜のマップでは小さい数値またはゼロでもよい。 + その他の設定項目について その他の設定項目について http //www.youtube.com/watch?v=ot8Wjvx7b6A を見れば分かるはず。一応以下に言葉でも書いておく。 BrightnessHDR, AmbientHDR HDR有効時のみそれぞれBrightness,Ambientの値をこれで置き換える。デフォルトの[-1 -1 -1 1]のままで良い。 AmbientScaleHDR 値を上げると影が薄くなっていくが、光が当たっている部分も少しずつ明るくなっていく。あまりこの項目は弄らずにBrightness,Ambientのほうで調整したほうが良いだろう。（HDR無効時とのギャップを小さくするためにも） BrightnessScaleHDR 値を上げると光が当たっている部分がHDRでもっとギラギラする。要はHDRのコントラスト調整みたいなもの。もっと画にメリハリをつけたければ上げて、目に優しくするには下げる。 これらは他のライト（light, light_spot）には影響しないことに注意しよう。 またビジュアルにこだわる以上当たり前のことであるが、マップを作るときはHDR有効時を基準にしよう。 満足の行く設定を見つけるには試行錯誤が必要になるのでゆっくり時間をかけて調整しよう。 せっかく造形はよく出来ているのにライティングが残念なせいで全体的に安っぽくなってしまっているマップも見かける。 逆にライティングによってある程度手抜きっぽさを軽減することだってできる。（特に夜のマップ） 屋内オンリーのマップで、外の景色を作る労力が割に合わない場合は よくtools/toolsblackやtools/toolswhiteテクスチャが使われる。 （必要に応じて単色のテクスチャを自作するのも良い） テクスチャライト（発光テクスチャ）を使うことで、窓から差し込む日光などを擬似的に表現することもできる。 http //simonbarsky.com/blog/?page_id=29 ただしこれは光が差し込む角度まで再現することはできない。（ この画像 のようにすれば可能） もちろんこの発光テクスチャには他にも色々な使い道がある。 lightやlight_spotと違い到達距離（Constant/Linear/Quadratic及びfallof distance）が設定できないのは辛いが、 それらの「点」と違って「面」として照らすことができるからだ。（正確には、点を一定の密度で敷き詰めているようだが） 発光テクスチャを貼ったブラシをfunc_brush化して、Don't Renderにすると光源単体で使えることも覚えておこう。 [ポ] light - 全方位を照らすライト https //developer.valvesoftware.com/wiki/Light 主に室内のライトに使う。ライトマップに焼きこまれる。 light_spot（+light_environment）と合わせて、ライトマップに焼きこまれるライトを「Static Light」と言う。 あまり壁に近づけるとそこが明るくなりすぎるので、いろいろ試しながら最適な位置・到達距離を見極めよう。 + 以下はlight_spotにも当てはまる注意点。 以下はlight_spotにも当てはまる注意点。 コンパイル時にライトマップに焼きこまれるものなので移動させることはできない。 入力によってライトをオン・オフできるが、コンパイル時に起こりうる全てのパターンを計算する必要があるため限界がある。こればかりは古いエンジンなので仕方が無い。例えば、2個の独立した名前を持つ（≒オン・オフ可能な）ライトがあれば「ABオン」「AオンBオフ」「AオフBオフ」「ABオフ」という4パターン全てのライトマップが焼きこまなければならない。独立した名前を持つライトが更に増えればパターンは増えて行き、すぐに限界（32パターン）にぶち当たってしまうだろう。（※限界に達しなければ良いという訳ではない。パターンが多いほどライトは不自然になる）ライトに名前を付けるだけでコンパイラーは「このライトはオン・オフする可能性があるんだ」と判断してしまう。そのためオン・オフしないライトでも、名前を付けるだけでコンパイル時間・ファイルサイズが増加してしまうことに注意。そして、同時にオン・オフするライトには全て同じ名前をつけること。そうすれば名前1つで複数のライトに入力できる。ということで、少しずつ部屋のライトをつけていくようなマップを作ろうとしているなら今すぐ白紙に戻そう。 Appearanceによって点滅させることができるが、かなりクライアントに負荷が掛かるので乱用は絶対にNG。単純にフレームレートが落ちるだけでなくカクつくようになってしまう。出来ることなら点滅するlightがプレイヤーの視界に同時に複数入ることがないようにしよう。（1つだけでも割と重い） [ポ] light_spot - ある一点を照らすライト https //developer.valvesoftware.com/wiki/Light_spot ライトマップに焼きこまれる。下向きの街灯や、車のヘッドライトなどに使う。 室内の天井に付いているライトはlightで無いといけないと思い込んでいる人が多いが、実は下向きのlight_spotでも良い。 しかし普通に下向きのlight_spotを置くだけだと天井が真っ暗になってしまう可能性が高い。 これは、床（直接光が当たっている場所）から照り返す光が少なすぎるからである。この照り返しのことを「Bounce」と言う。 このBounceする量（強さ）は、デフォルトではテクスチャのvtfファイルに埋め込まれているが、 vmtファイルの$reflectivityパラメータで上書きすることができる。 https //developer.valvesoftware.com/wiki/$reflectivity http //www.nodraw.net/2011/02/reflectivity/ 通常、既存のテクスチャのvmtファイルのパラメータを編集したい場合、 （例として、パラメータを編集するvmtは「example.vmt」とする。） 「example.vmt」を複製し、「example_edit」等と命名する。（名前は自分が分かればなんでも良い） 「example_edit.vmt」をテキストエディタで開き、パラメータの追加や引数の変更を行う。 ハンマーエディタでブラシの面に貼り付けてあるexampleを、example_editに置き換える。 ハンマーディタでマップをコンパイルする。 コンパイルして出来たbspファイルに、Pakratを使用して「example_edit.vmt」を埋め込む。（重要） といった手順を踏む必要があるが、$reflectivityパラメータのみ編集する場合は、単に （不安な場合、「example.vmt」を複製し、「example.bak.vmt」等と命名しておけば後で簡単に元に戻せる） 「example.vmt」をテキストエディタで開き、$reflectivityパラメータの追加、または引数の変更を行う。 ハンマーエディタでマップをコンパイルする。 だけで良い。これは、$reflectivityパラメータはマップのコンパイル時のみに参照されるため。 念のため逆の言い方もしておくと、コンパイル後に$reflectivityを編集しても効果は無い。 [ポ] light_dynamic - ダイナミックライト https //developer.valvesoftware.com/wiki/Light_dynamic ライトマップに焼きこまれない、ゲーム側でリアルタイムで計算されるダイナミックライト。 ライトの光の形はlight_spotと同じスポットライト型で、lightのような無指向性のダイナミックライトは作れないらしい。 light_spotとの違いは、「Parentingして動かせる」「色を変えられる」「オン・オフに制限が無い」 「ゲーム側の負荷が高い」「見た目はlight_spotに比べてかなり簡易的」といったところ。 このエンティティは調整がとても難しいらしい。とりあえず上記ページに書いてある注意点だけ転載。 実はこのエンティティのライトは、「モデルのみを照らすライト」と、「ワールド（ブラシ）のみを照らすライト」の2つが合わさって出来ている。そのうちの片方に影響するが、もう片方には影響しないKeyvalueがある。 distanceは照らさせたい物までの距離より大きい数値に設定する必要がある。 brightnessは6か8のどちらかでなくてはならない。他のライト系エンティティで使われるbrightnessはこのエンティティには関係無い。 角度はKeyvalueで手動で設定する必要がある。（point atツールは使ってはいけない。ハンマーエディタの2Dビューで回転させるのは良いのか悪いのか不明） [ポ] point_spotlight - サーチライトのような光の道筋 https //developer.valvesoftware.com/wiki/Point_spotlight これは「横から見ると光の道筋が見える」「正面から見るとまぶしい」というだけで、ライトマップには焼きこまれない。 そのため、基本的にlight_spotと併せて置くもの。 但し、lightやlight_spotと違ってこのエンティティは動かすことができるため、 動く乗り物などについているライトを疑似的に表現する時は単体で使うこともある。 あとは高い場所に設置されている上向き（空向き）のサーチライトなんかも、わざわざlight_spotを置いたところで 照らされるオブジェクトが何も無いのでpoint_spotlight単体でもよい。ただしヘリとか通るなら話は別である。 [ポ] env_sprite - 常にこっちを向いているテクスチャ https //developer.valvesoftware.com/wiki/Env_sprite 例えば現実的なライトを配置するとき、プロップとlightだけではいまいちライト自体が光っているように見えないことがある。 そんな時に使うのがこのエンティティで、これの設置ポイントがプレイヤーの視界内にあって、 何かに遮られないかぎり、設定したテクスチャが正面を向いて主張してくる。 lightの色と近くすれば、まるでプロップがその色に光っているように見えるというわけ。 多少無理はあるが、白のプロップを別の色に光っているように見せることもできる。 また、プロップやlightを設置するほどでもない小さい光源を表現する時にも使う。（イルミネーションなど） 使うRender Modeは基本的にGlowとWorld Space Glowのみ。 Glowは距離に関わらず同じサイズで表示される。主に遠景に使う。近づくとフェードアウトするようにして、 「遠くからみると眩しかったが、近づいたら目が慣れた」という表現をしたい場合にも使える。 World Space Glowは近づけば大きく、離れれば小さくなる。こっちのほうが使う機会は多いんじゃないかな。 なおこちらはStatic Lightと違い、好きなだけAppearanceで点滅させて大丈夫。ほとんど負荷にならない。 「だったらStatic Lightはつけっぱなしでenv_spriteだけ点滅させればいんじゃね？」「やめたほうがいいかと」 [ポ] env_sun - 太陽（たまに月） マップ内の何処にプレイヤーがいても、視界に入っている場合は同じ方角・角度に表示されるenv_spriteのようなもの。 スカイボックスの中にあるように見えるenv_spriteと言ったほうが伝わりやすいだろうか。 このエンティティは必須では無い。使う場合はligh_environmentと同じく、スカイボックスのテクスチャに対して 自然に見える色・角度を設定しなければならない。（必ずしも全く同じPitch Yaw Rollで無ければいけない訳では無い） 使用するスカイボックスに太陽が描き込まれていない場合、描き込まれているが大げさに表現したい場合などが主な用途。 特に後者の場合は角度合わせに細心の注意を払う必要がある。 [ポ] env_lightglow - トンネルの出口とかで眩しくなるやつ https //developer.valvesoftware.com/wiki/Env_lightglow 元々HDRの効果で、暗いところから明るいところを見ると眩しく見えるが、それをより大げさに演出したいときに使う。 別にトンネル出口に限ったことではないが、主に使われるのはトンネルや洞窟だろう。 用途としてはenv_spriteに似ているがこちらはテクスチャを使わず、Keyvaluesで形を設定する。 [ポ] env_projectedtexture - プロジェクターのようなもの https //developer.valvesoftware.com/wiki/Env_projectedtexture 一応使えるが、影の解像度が低くノイズのような不気味なザラザラが乗るので使用に値しない。 + 旧解説 ポイントエンティティで、明るさや角度を設定できるという点ではlight_spotに似ているが、本質的には全くの別物。 このエンティティは、プレイヤーのフラッシュライトと同じ原理でテクスチャを投射する。ライトマップには焼きこまれない。 light_spotで無くこちらを選択する意味は「オン/オフしてもライトマップを増やさない」「移動ができる」 「遮られた部分が影になるので、動的・精細な影を作れる」の3つ。 ちなみにshadow_controlでダイナミックシャドウをオンにしている場合は影が不自然になってしまう可能性があるので注意しよう。 また光が直接当たっていないところも反射して柔らかく明るくするlight_spotなどと違い、遮られた部分は全く明るくされない。 env_projectedテクスチャを使うエリアの元々の明るさをしっかり調整しておく必要がある。 $bumpmapが指定されていないモデルはこのエンティティによって照らされず、不自然に暗くなってしまう。 Portal2ではこのエンティティがこれでもかというほど多用されているので、イマイチ使いどころが分からないという人はプレイしてみると良い。 [ポ] shadow_control - マップ全体のダイナミックシャドウを設定する https //developer.valvesoftware.com/wiki/Shadow_control ダイナミックシャドウとは、マップ内で動くオブジェクト（prop_physic,prop_dynamicなど）が落とす影のこと。 「動くオブジェクト」とは、prop_dynamic, prop_physics, func_physboxに加えてプレイヤーやNPCなども該当する。 屋外オンリーのマップであれば、light_environmentに調和するように設定すればとりあえずそれだけでも良い。 [設定例] light_environment shadow_control Pitch Yaw Roll (Y Z X) 0 108 0 45 108 0 Pitch -45 （なし） しかし不便なことにダイナミックシャドウはマップ全体で同じ角度・色で落とされてしまうので、 屋外と屋内が混在するマップなどでは非常に厄介なことになる。 （例えば夕方の人から伸びる影はとても長いが、屋内に入っても影の長さが同じだったら不気味なのは想像に難くないだろう） そういうマップでは「角度を直角（直下）に近づける」「彩度を下げる」「ダイナミックシャドウをオフにする」などの妥協が必要になってくるだろう。 ただし角度を完全な直角にするのはやめたほうがいい。人の影の形がかなり不自然に見えちゃうの。最低5度ぐらい？はずらしましょう。 あと最大距離も大きくしすぎると上の階の影が貫通して見えてしまったりする（ダイナミックシャドウには「遮られる」という概念が無い）ので小さ目に。 Shadow Colorについては少しずつ値を変えて試してみるしかないが、あまり濃い色（暗い色）にすると、 ライトマップの影と重なった時に非常に濃い影になってしまうので気を付けよう。 屋内オンリーのマップでも、光源が多く存在場合する場合はオフのほうが自然に見えるということもありうる。 何にせよ最終的に、メリットとデメリットを天秤にかけて決めるしかない。 特定のオブジェクトのダイナミックシャドウだけが邪魔な場合は、個別にそのエンティティの方で影を消せばいい。 但しこの方法は残念ながらキャラクターやゾンビ、武器などには使えない。 またライトマップの影と重なる以外にも、ダイナミックシャドウ同士で重なってしまうことに気をつける必要がある。 現実世界であれば、人の影を人が遮っても影の濃さは変わらない。机の上にある時計の形が影でわかることも無い。 だがこのエンジンではそうはいかないのだ。ダイナミックシャドウには「遮られる」という概念が無いため、影同士が重なってしまう。 ゲーム内でゾンビの影同士が重なっているのを見て不自然に感じた人は多いだろう。 また、壁や床などのブラシに遮られることも無いため、最大距離を大きくしすぎると「上の階の影が下の階に貫通」してしまう。 とにかくこのダイナミックシャドウ全般に言えることは、「無くても不自然に感じることは無いが、あると不自然に感じてしまう場合がある」 ということ。使わないほうがいいという事では無く、状況を選んで上手に使わなければならないということ。 ゾンビ同士の影が重なる不自然さを軽減したい場合は、Pitchを直下に近づければ重なる頻度を下げられる。例えlight_environmentが夕方の長い影をライトマップに落としていても、ダイナミックシャドウはそこまで長くなくても結構しっくり来るものである。 夜のマップ。早い話がオフで良い。夜に町を歩いている人を想像してみよう。街灯や店、車などの光源によって色んな方向に影が出たり消えたりしているはずだが、これはSourceエンジンでは再現できない。また、現実世界において、肉眼でくっきりと人の影が見えるほど強烈な月明かりは滅多に無い。ただし月明かり以外のライトが少ないようなマップ、つまり自然豊かなマップな場合は薄めにつけてみるのも良い。。この場合、月明かりに指向性を持たせるためlight_environmentのBrightnessは0以外に設定する必要がある。 屋内マップ。これも正直言ってオフで良い。やはり屋内でも、現実世界では光源との位置関係によって様々な影ができるが、これを再現することはできない。どうしてもダイナミックシャドウが欲しいという場合は、影の形がよく分からないほど薄い色にしよう。もちろん角度はほぼ直下に。 [ポ] info_lighting - prop_staticへの光の当たり方を決めるポイントを調整する https //developer.valvesoftware.com/wiki/Info_lighting prop_staticを壁にめり込ませて配置した場合、光の当たり方がおかしくなってしまう（大抵の場合、真っ暗）ことがある。 そんな時にprop_staicのLighting Originで、配置したinfo_lightingの名前を指定すると、 そのprop_staticの「ライティングを決める場所」を、このエンティティの場所で上書きすることができる。 また、めり込んだプロップ以外でも、少しだけ光源に近づけたり離したりして、微調整に使うこともできる。 と言ってもよく分からないと思うのでこの チュートリアル動画 を見ると良い。 普通、対象のprop_staticの近くに配置するものだが、全く別の場所に配置することもできる。 （暗い部屋の真ん中にあるテーブルに、明るい部屋に置いたinfo_lightingを指定させれば、 そのテーブルだけ不気味に明るくできる） staticproplightingオプションを付けている場合、$bumpmapを使用していないプロップモデルには使用できなくなる。 （$bumpmapを使用していないプロップモデルはVertex Lightingされる） なおこのエンティティと同様の効果をprop_dynamicで得たい場合はinfo_targetを使う。 prop_physicsにはLighting Originを設定できないので同様の効果を得ることは不可能。 煙・霧・埃などの表現 [ポ] env_fog_controller - マップ全体のフォグを設定する https //developer.valvesoftware.com/wiki/Env_fog_controller まず聞かれる前に書いておくが、マップの特定の場所にのみフォグを発生させるエンティティは残念ながら無い。 いわゆる霧であるが、サイレントヒルでも作らない限り濃霧など滅多に必要無いので、 実際にはFar Z（最大描画距離）の設定による負荷軽減が目的で使われることが多い。 もちろん、これに頼る前にできる限りの最適化をしたほうが絵的に映えるのは言うまでもない。 本来霧や負荷軽減が必要ないマップでも、弱めに（遠めに）フォグをかけてやると雰囲気を高めることができるかも。 フォグは、Fog Startの距離からかかり始め、Fog Endの距離以降の全てのオブジェクトは完全にフォグの色に覆われる。 Far Zを設定した場合は、その距離以降のオブジェクトは描画されない。（大抵の場合、スカイボックスが透けて見える） そのためFar ZはFog Endより大きな値にするのが普通であるが、Far Z≦Fog Endで不自然さが無いマップもあるので一概には言えない。 Far Z設定の如何に関わらず、フォグの色は覆われたオブジェクトの裏に見えるスカイボックスの色に近づけたほうがよい。 通常スカイボックスのテクスチャはvmtで$nofog 1とされているため、スカイボックスは絶対にフォグに覆われないが、 スカイボックスのテクスチャを自作する場合はその記述を削除することによってフォグに覆われるようにすることができる。 どんなときにこれをする意味があるかというと、空も見えないような濃い霧を表現する場合である。 ただし、「どうせフォグに覆われるからスカイボックスのテクスチャ（vtf）は何でもいい」と考えるのは間違い。 何故ならば、プレイヤーがスカイボックステクスチャの貼られた面に近づいた際は見えてしまうから。 つまり、この場合はスカイボックスのテクスチャはフォグと同一色の単色テクスチャにすれば良いということ。 この方法を採った場合、Far Zを（Fog Endより遠い距離に）設定するデメリットが全く無いので、忘れず設定しよう。 3Dスカイボックス内のフォグは、別途sky_camera内の設定項目で設定する必要があるので注意。（多くの場合、env_fog_controllerと同一の設定で良い） [ブ] func_dustcloud - もやっとした霧・砂埃（砂嵐）を発生させる https //developer.valvesoftware.com/wiki/Func_dustcloud でもなんだかテクスチャの境界が目立ってるような気がする・・・ func_smokevolumeのほうを選んだ方が良いような。 [ポ] env_dustpuff - もやっとした霧・砂埃を発生させる（？） https //developer.valvesoftware.com/wiki/Env_dustpuff 詳細不明。 試しに置いてみたら何も起こらなかった。機能してないのかも。使わなくていいでしょう。 [ポ] env_steam - もくもくと上がる煙・陽炎を発生させる https //developer.valvesoftware.com/wiki/Env_steam 煙突から上がる煙、車の排気ガスなどに使う。 陽炎（炎の上で奥が歪んで見えたりするアレ）を発生させることもできる。 [ブ] func_smokevolume - もくもくとした煙を発生させる https //developer.valvesoftware.com/wiki/Func_smokevolume 「ブラシエンティティ版env_steam」とでも言うべきか・・・ 非常に薄い霧っぽいものを作る時はfunc_dustcloudよりこちらのほうが良い気がする。 スモークグレネードの煙用のテクスチャがデフォルトだが、これが案外バカにできない。 速度や透明度を弄ることで様々な用途に使える。 [ポ] env_smokestack - もくもくと上がる煙を発生させる（？） https //developer.valvesoftware.com/wiki/Env_smokestack 「低速・風の影響を受ける版env_steam」らしい。詳細不明。使わなくてよろしいかと。 [ブ] func_dustmotes - ぱらぱらと舞う埃を発生させる https //developer.valvesoftware.com/wiki/Func_dustmotes 地下室でライトに照らされながら舞ってそうな感じのあれ。 もしくは窓から差し込む光に照らされながら舞ってそうな感じのあれ。 工夫次第ではライトに群がる虫を再現できるかも？（若干くどいが） ロープ https //developer.valvesoftware.com/wiki/Cables_and_Ropes 電線・ケーブルなどに。下記2つのエンティティを使って作れる。 [ポ] move_rope https //developer.valvesoftware.com/wiki/Move_rope [ポ] keyframe_rope https //developer.valvesoftware.com/wiki/Keyframe_rope 効果音・環境音・BGMなど [ポ] ambient_generic https //developer.valvesoftware.com/wiki/Ambient_generic 単純に簡単に効果音や音楽を流すのはこっち。 wavと違って「ハンマーエディタ内で試聴できない」「ループできない」という制約がある(?)が、普通にmp3も使える。 [ポ] env_soundscape https //developer.valvesoftware.com/wiki/Env_soundscape 単純じゃないのはこっち。いろんな音のセットをランダムに流したりする。 スクリプトを書かないといけないので面倒くさい。でも書式は簡単。 エンティティ以外の話 ライティング関係のコンパイルオプション https //developer.valvesoftware.com/wiki/VRAD http //www.nodraw.net/2010/12/lighting-compile-options/ Expertコンパイルで、必要に応じて$light_exeのパラメーターにこれらのオプション（コマンド）を追加することで コンパイルしたマップの用途に適した結果・コンパイル所要時間を得ることができる。 目的がギミック等の動作確認で、ライティングは必要無い場合は$light_exeのチェックを外せば、 ライティングの焼きこみ自体をスキップできる。（ライトのオン/オフをテストしたい場合等はやはり焼きこむ必要がある。） 簡易的なライティングのテストによく使われるオプション -fast -luxeldensity * -hdr/-ldr 完成したマップ、最終的なライティングのテストに使われるオプション -final -textureshadows -staticproppolys -both/-hdr/-ldr -staticproplighting -fast 品質を犠牲に、ライティングの焼きこみをより短い時間で済ませる。基本的に大まかな雰囲気を見るにはこれで十分だが、場合によっては間接光のライティングが破綻してしまうことがある。その場合は外すこと。 -final ライティングの焼きこみにより長く時間をかけて綺麗にする。-fastと見比べても違いがほとんど分からないようなケースがあるが、完成したマップをコンパイルする時は必ずこれを使うこと。細かいところではあるが、間接光によって柔らかく照らされている場所が、-fastや標準モードだと黒く潰れてしまったりする。 -luxeldensity * ライトマップが引数より小さい値に設定されている面を、引数の値に置き換えてコンパイルする。例えば「細かいライトマップを使っている面があるが今回はその点をチェックするわけではない」という場合は-luxeldensity 16が最適だろう。「本当にぱっと見の雰囲気を確かめるだけで良い」という場合は32や64にすれば更に時間は短縮される。 -both HDRとLDR両方のライトマップを焼きこむ。-hdr, -ldrと併用不可。 -hdr HDRのライトマップのみを焼きこむ。LDRのライトマップ焼きこみが省かれ、LDR用のキューブマップを撮影する必要も無くなるのでファイルサイズの削減になる。ただし（具体的にどうなるのかは試していないので分からないが）HDRを無効にしている環境では不都合が出るはず。-both, -ldrと併用不可。 -ldr LDRのライトマップのみを焼きこむ。普通はHDR前提で作るのでテスト目的でもあまり使う機会は無いだろう。完成したマップに使う機会があるとすれば、「HDRが無い時代のクラシックゲーム調」「アニメ調（誤解防止：『アニメ調ならLDR』ではなく『アニメ調ならLDRにする手もあり』ということ。TF2は普通にHDRを使っている）」に作る場合。-both, -hdrと併用不可。 -textureshadows アルファチャンネルを持つ、すなわち透けている部分があるテクスチャ（格子状など）の透明部分を光が通り抜けるようになる。ただしこのオプションを追加するだけだとprop_staticに効果が無い。prop_staticにも効果を及ぼさせるには、まず-staticproppolysと併用することが必要。そして"nmrih\light.rad"をテキストエディタで開き、一番上に新たな行を作成し（行を追加する場所はどこでもいいのだが、一番上にしておけば、後で自分が追加した行を見つけやすいだろう）forcetextureshadow #と書く。#には、「"nmrih\models\"以下の、効果を適用させたいモデル（mdl）のパス」を入れる。例：forcetextureshadow props_foliage/tree_dead01.mdl効果を適用させたいモデルが複数ある場合は、全てそれぞれ記述しなければならない。 -staticproppolys 全てのprop_staticが落とす影が、実際のpropに基づいた形になる。このオプションを使わない場合、影の形はバウンディングボックス（簡易的な衝突判定に使われる大雑把な形の箱）のものになってしまうので、ほぼ必須のオプション。 -staticproplighting prop_static自体のライティング（prop_static自体が受ける影）がより現実的になる。このオプションを使わない場合の、prop_static自体のライティングについては、このページの項「prop_staticのVertex Lightingについて」を参照すること。基本的にデメリットが無い-textureshadows, -staticproppolysと違って、このオプションを使うとbspのファイルサイズがかなり増加する。とは言え基本的にファイルサイズに関してそこまで神経質になる必要は無いので、特に理由が無ければとりあえずこのオプションも付けておこう。 ライトマップスケール https //developer.valvesoftware.com/wiki/Lightmap テクスチャツールでブラシの面ごとにライトマップスケールを設定できる。 ライトマップスケールを細かく（小さい数値に）すればするほどその面のライティングがシャープになる。 これはグラデーションの表現力が失われる訳ではない。本来シャープになるべき場所がシャープになるだけ。 （正確にはグラデーションについても階調数が上がるためより綺麗になるが、見比べないと分からないレベル） ライトマップスケールを細かくすることによるデメリットは、コンパイル時間やファイルサイズが倍増すること。 （※コンパイル時間はライティング計算にかかる時間、ファイルサイズはライトマップのサイズである） 単純にある面のライトマップスケールを16→1に変更すれば、その面のライティングに必要な時間とファイルサイズは16倍になる。 またライトマップが細かくコンパイルされたマップほど一度に多くの情報を描画するためゲーム側での負荷も上がるが、 これは極わずかであり一般的に体感できないレベル。 そして一番注意すべきデメリットは、1つのマップに存在できるライトマップのグリッド数には限界があるということ。 「リークなどのコンパイルエラーが発生していないのに、コンパイルのライティング計算が一瞬で終わり、 出来たマップをロードしてみるとmat_fullbright 1状態」であったらおそらく限界を超えてしまっている。 全ての面のライトマップスケールをデフォルトの16で作っている限りは、よほど巨大なマップでない限り限界には達しない。 しかし部分的にでも（デフォルトより）細かいスケールを使った場合案外簡単に達してしまう。 なおひとつの面に存在できるライトマップのグリッド数にも限度があり、 これを超えた場合はコンパイル時に自動でブラシが分割される。 これは基本的に特に気にする必要は無いが、切断された部分の線がゲーム内で見えてしまうことがある。 しかしそうなってしまったところで対処法は（スケールを大きい数値にする以外には）無いので、やはり気にしなくてよい。 まとめ： デフォルトの16はシャープさとコスト（コンパイル時間・ファイルサイズ）のバランスが一番とれた数値である。 基本的には16のままにしておき、細かいライティングが必要な面のみ小さい数値にするようにすると良い。上述の通り、16より大きい数値にすることによるコストの削減は効果が薄い。（製作段階のマップのコンパイルを早く済ませたい場合はvradコンパイルオプションの-luxeldensityを使うべき） プレイヤーから見えない面をNodrawテクスチャにすることは、ライトマップのコスト削減にも繋がる。Nodrawの面にはライティングの計算が必要無いため。地面の裏側のテクスチャをそのままにしている人などは大損をしている。 最良の結果を得る方法は、「限界に達しない範囲で」「あなたが許容できるコンパイル時間内で」「シャープにしたい面のスケールを細かくする」ことである。ファイルサイズに関しては確かに倍増するのだが、そもそも上述の限界によって自動的にこれも制限されるため、マップ単体では100MBに達することすら不可能なのでほとんど気にする必要はない。（100MBと聞くと大きく聞こえるかもしれないが、カスタムコンテンツを使えばテクスチャだけで100MBを超えるのは容易である） マップの最適化 シンプルで小規模なアリーナ型マップ（どこにいてもマップの全体が見渡せるようなマップ）を作っているうちは あまり意識する必要は無いが、現実的で大規模なマップを作るとなると「いかにコンパイル時間を短縮するか」 「いかにクライアントのフレームレートを稼ぐか」ということが割と重要になってくる。 そんな時はこれらのリンクを参考にしよう。（丸投げ） Souce SDK wiki： コンパイルの高速化とパフォーマンスのアップ方法 https //developer.valvesoftware.com/wiki/Tool_textures https //developer.valvesoftware.com/wiki/Func_detail https //developer.valvesoftware.com/wiki/Func_brush https //developer.valvesoftware.com/wiki/Visibility_optimization https //developer.valvesoftware.com/wiki/Areaportal https //developer.valvesoftware.com/wiki/Func_areaportal https //developer.valvesoftware.com/wiki/Func_areaportalwindow https //developer.valvesoftware.com/wiki/Func_occluder https //developer.valvesoftware.com/wiki/Hint_brush 色々な手段があるが、大体は「プレイヤーから見えない部分のポリゴンやテクスチャを描画させないようにする」ということ。 難しいことは良くわからなくても、プレイヤーから見えない部分のテクスチャをNodrawにする、 細かい装飾ブラシ（プレイヤーの視界を塞ぐだけの大きさが無いブラシ）をfunc_detailにするぐらいはやっておこう。 しかし最適な最適化を出来るということは、その軽減された負荷の分複雑なマップを作れるということなので、 もしかすると一番最初に習得しておいたほうが良いのかもしれない・・・ まあ時間も手間も掛かるのだが、どこで区切るかを考えたりするのはパズル的で結構楽しかったりする。 Nodrawテクスチャにはライトマップも焼きこまれないので、コンパイル時間の短縮にも一役買う。 prop_staticのフェード距離や、env_fog_controllerのFar Zを設定するのも効果的。（詳しくはそれぞれのページで） カスタムコンテンツ デフォルトで入っているテクスチャなどでは物足りないと思ったら、自分で作った（或いはどこかから取ってきた） カスタムコンテンツを入れるしかない。 しかしこれはとても面倒な作業で、何より面倒くさいのがコンパイル後のbspにそれらを埋め込む作業である。 埋め込む方法については「BSPZIP」や「Pakrat」と検索すると良い。 （Pakratは大抵のカスタムコンテンツを自動で埋め込んでくれるが、一部モデルのテクスチャなど、 自動では埋め込んでくれないものもある。そういう時は手動で探して埋め込む） カスタムテクスチャのvmtファイルの書き方について日本語で解説しているサイト。 http //www.schuzak.jp/cs-s/tutCustomTex.html 円柱や球体などの曲面を滑らかに見せる https //developer.valvesoftware.com/wiki/Smoothing_groups https //developer.valvesoftware.com/wiki/Hammer_Smoothing_Groups_Dialog 滑らかに見せたい面を全部選択してSmoothing Groupに入れるだけ。簡単だね。 ライトマップスケール16ではあまり滑らかに見えないが、細かくすればするほど滑らかに見えようになる。 マップに草を生やす https //developer.valvesoftware.com/wiki/Detail_prop https //www.youtube.com/watch?v=mkZuSVgQFFo マップに生やす草を（func_detailと紛らわしいが）detail props、もしくは単にdetailと言う。 これらを単独で配置する場合はprop_detailというエンティティ。 https //developer.valvesoftware.com/wiki/Prop_detail 「点」でなく「面」で照らすライト light_environmentのとこに書いてあります。 スカイボックスの回転 スカイボックス自体は回転できない。マップをある程度作ったあとに、気になってしまうこともあるだろう。 そんな時にどうするかというと単にマップ全体を選択して90度単位で回転させる。おしまい。 スカイボックスや環境光などの調和 それぞれのパートで散々言ってきたが、つまりはこういうこと。 まずlight_environmentをスカイボックスの明るい方角から、それっぽい色の光が差し込むように設定する。 そしてenv_sunをスカイボックスの明るい部分の方角・角度で、その部分に近い色に設定する。 最後shadow_controlを、ブラシが落とす影に近い色合いになるように調整する。 （別に自分が好きな順番でやっていいです） 左はfunc_physboxなのでダイナミックシャドウ、右は普通のブラシなのでライトマップに焼きこまれた影。 意識すると気づくと思うけど、プレイ中にぱっと見た分には気づかないレベルではなかろうか。 SunSpreadAngle：0にして、ライトマップスケール：1にするともっと区別がつきにくくなる。 もちろん、あくまでライトマップの影がメインなので何もダイナミックシャドウの方に合わせる必要は無いのだが。 でもここまでダイナミックシャドウを濃くて彩度が高いものにすると、影同士が重なったときに非常に気持ち悪いことになるので、 実際に遊ぶマップを作るときはもう少し大人しい色にするのが普通。 prop_staticのVertex Lightingについて Disable Vertex LightingというKeyvalueがあるが、これは基本的にNo（＝Vertex Lightingを使用する）で良い。 Vertex Lightingとは何かという話だが、これは雑に言えばライトマップのprop_static版みたいなものである。 Disable Vertex LightingがNoの状態では、プロップモデルのそれぞれの面が、ワールドブラシのようにある程度精細にライティングされる。（正確に言うと、それぞれの頂点ごとに光の色が焼き込まれる） なおVertex Lightingは、$bumpmapと$phongを（片方でも）使用しているプロップモデルには対応していないらしい。 Disable Vertex LightingがYesの状態では、そのプロップモデルが受けるライティングは、そのprop_staticのモデルの「場所（光源に対する距離や角度）」の1点のみで決定される。（それぞれの頂点の位置は関係ない） ちなみに、prop_static以外のプロップエンティティにはDisable Vertex LightingのKeyvalueが無い事から分かる通り、prop_dynamicやprop_physics、武器やプレイヤーキャラクター等はVertex Lightingされず、Ambient lightと呼ばれる全く別の方法でライティングされる。 https //developer.valvesoftware.com/wiki/Ambient_light 3Dスカイボックス http //wikiwiki.jp/sourcesdk/?Skybox 「プレイヤーが歩きまわるマップ本体」と完全に独立した場所に、「ミニチュアサイズの遠景（3Dスカイボックス）」を作り、 実際のゲーム内ではそのミニチュア遠景を拡大して、本体の背景にピッタリ当てはめるというもの。 「え、なんでわざわざそんな面倒臭いことする必要があるの？本体に全部作っちゃえばいいじゃん」と思うかもしれない。 しかし、3Dスカイボックスはミニチュアサイズという特性上「等倍（本土）では再現できないほどの広さを再現できる」 「テクスチャが小さくなる分負荷を減らせる」という特徴がある。 sky_camera内で本体に対する3Dスカイボックスの縮尺率を変更できるが、これはデフォルトの1/16のままにしておくのが吉。 理由は3Dスカイボックス用に作られた1/16サイズのモデルを配置できるのは、1/16の3Dスカイボックスだけだからである。 モデルを拡大・縮小することが出来ないSourceエンジンでは、3Dスカイボックス用のモデルを本土に使うことも、その逆もできない。 位置合わせについては少しでもズレているとおかしなことになるので、しっかりと行うことをお勧めする。 あくまで遠景なので、本体に接続された（ように見える）3Dスカイボックス領域に、そのままプレイヤー等が立ち入ることは出来ない。 テレポーターを使えばプレイヤーが入ることが出来るが、ネタ以外でやる意味は無い。 この3Dスカイボックスを作成する際に見落とされがちなのが、「本体と3Dスカイボックスは、お互いライティングに影響しない」ということ。 「本体のブラシの影が3Dスカイボックスに出来ない」という問題は、本体から3Dスカイボックス領域に持っていった （本来位置合わせ用としてのみ使う）ブラシを削除せずにBlock Lightテクスチャを貼ることで回避できる。
https://w.atwiki.jp/hatoyagiproxy/pages/10.html
YUKI YouTube 随時更新 4月最後の更新 https //ysta-yukimath-nc.onrender.com/ IN 随時更新 4月23日(火)追加 https //quarterpounder.mrlewburger.com/ https //production.mechtronics.net/ https //lenses.proheroeyewear.com/ GreatSword https //7fkhkg-8080.csb.app/
https://w.atwiki.jp/hypixeljp/pages/269.html
かくれんぼです。Prop HuntとParty Pooperの二種類があります。 Prop Hunt Party PooperHider（隠れる側） Seeker（ハンター側） バグ マップWarehouse House Party Pool Party Prop Hunt Farm Huntに似ているゲーム。こっちは動物ではなく道具（ツルハシ、クワ、剣など）に変装し、制限時間までハンターから隠れきれば勝利。ステージは1ヶ所のみ。 左クリックで触れることで道具を変更できる。隠れる側はクワになるのがおすめ。ブロックにめりこむように隠れると、ほとんど見えなくなる。 ハンターに見つかった場合、ハンターに対して右クリックで3秒間ほどスタンをかけられるので、そのスキに逃げよう（クールダウンがあるため、連続使用はできない）。 弓などの武器がないので、ハンターへの反撃は実質スタンのみ。倒されると、ハンター側になって復活する。 ハンター側は、近くに隠れている人がいると心臓の鼓動音がするので、探すときの手がかりにしよう（近いほど音が大きくなる）。 序盤の展開でどっちが勝つか大体読める。（ハンターが増えまくる時と全然増えない時で、はっきり分かれやすい） Party Pooper NPCにまぎれて、ハンターに気付かれないように目標（Objective）をクリアするゲーム。制限時間内に5ヶ所の目標をクリアすれば隠れる側の勝利。全滅もしくは時間切れでハンター側の勝利。マップは現在2種類。元は4種類。 Hider（隠れる側） 隠れる側は、NPCと区別できるような行動をしないことを心がけ（ダッシュジャンプ、道につっかえる、不規則なスニーク、キョロキョロ視線を変えるなどは危険）、目標地点に近づく必要がある。周囲の状況を伺うには、3人称視点（F5キー）をうまく活用したい。 目標は特定のNPC（移動型 上に名前が付いているNPC。）と家具や装置についている固定型がある。目標の実行中は音がなる上、一切移動ができない（移動すると最初からやり直し）。近くにハンターがいない時を見計らって起動しよう！ちなみに、他の人が目標を実行中は自分は目標を実行出来ない。 移動型の目標はハンター側にも見えているが、固定型の目標は毎回ランダムな位置が選ばれ、ハンターは位置がわからない。（ただし手慣れのハンターは固定型の位置もだいたい把握して行動しているため、注意が必要） 他のNPCをクリックすることで、移り変わることができる。ハンターに発見された場合に有効だが、音がなるのでみだりに使わないほうが良い。 ハンターに倒された場合、ゲーム終了までスペクテイターモードで見学となる。復活はできない。 Seeker（ハンター側） ハンターは怪しいと思う人物を攻撃する。ただし(NPC)を攻撃すると数秒間スタンになる上、ダメージを受ける。5回失敗して体力が0になるとゲームから脱落となるので、叩きすぎに注意！終盤まで探し続けるには、体力管理が重要。 ブレイズロッドで人物に"Suspicious"（こいつは怪しい）、"Checked"（こいつはNPCだった）をつけられるが、バグで上手く機能しないことも。しかも自分以外の他のハンターには見えないので、あまり意味はない。 音がなったら誰かが目標を実行中なので、とりあえず音のなる方へ急ごう！ バグ ハンター側でTabキーを押すと、隠れているプレイヤー（と一部のNPC）の顔と名前が見えてしまい、ある程度目星をつけて簡単に探せてしまう。 （検証動画は非公開になっていたため削除） マップ Prop Hunt Warehouse 倉庫をテーマとしたマップです。 Prop Hunt唯一のマップ。いかにもな感じの倉庫。結構入り組んでいて、簡単に鬼を撒ける。 Party Pooper House Party パーティー中の館をテーマとしたマップです。 館のくせにダンスルームがあったりする。調理場や控室もあることから、ダンス大会等の会場なのかもしれません。一方通行の通路もあり、逃げるのには丁度良さそうだ。待機中は庭にいるのだが、外の景色を見ると秋の山中らしい。 Party Pooper Pool Party プールのある館をテーマとしたマップです。 巨大なプールがある館です。プールは浮き輪だらけで、飛び込み台なんかもあります。他にも海のような屋台だってあります。家はテレビがあったり書斎があったり意外と小さいですが、2階にはアスレチックだってあります。
https://w.atwiki.jp/eyes_33/pages/39.html
シンプルなビューヘルパー 全体のヘルパーは、 app/helpers/application_helper.rbにメソッドを書けばOK！ デフォルト設定では、app/helpers/以下の全ての***_helper.rbファイルが有効ですな。 HTMLを返すビューヘルパー タグを返す時に、content_tag/tagメソッドを使うと便利らしい これらのタグを使えば、文字列のエスケープをしてくれて、かつタグはそのままだから。 こんな感じか？ def list_tag(collection,prop) content_tag( ul) do # ul を作成 collection.each do |element| # ul の中に li を作成 concat content_tag( li, element.attributes[prop]) end end end 本体を持つビューヘルパー うーん、「本体を持つ」の意味が判らんかった…。 結局、 blockを使ったブロック渡しの話か？ -
https://w.atwiki.jp/kojiro/pages/528.html
OBJECT.PROPERTIES
https://w.atwiki.jp/k-project/pages/106.html
K-PROJECTは、代表である清瀬桜李を唯一の構成員とする、個人製作同人サークルの名称である。2010年創設。 名前の由来 K-PROJECTのKは、元々桜李の旧名支線亭賀毛女（Kamome Shisentei）の頭文字から取られたものであるが、現在は清瀬(Kiyose)の頭文字としている。 外部リンク K-PROJECT - 通称『本部』
https://w.atwiki.jp/xperiarc/pages/32.html
root化について初期化方法(SEUS使用) root化 Wi-Fiアクセスポイント化(Wi-Fiルータ化) カメラシャッター音変更(無音の追加) 電源を入れた時のアニメーションを変える システムファイルを書き換える バッテリー表示を１００段階表示に変更 コメント root化について Android端末は、デバイス本体のシステムファイルなどを書き換える権限が与えられていません。Root化を行うことで、本体内のデータを書き換えの権限を与えることができます。それにより、システム内の書き換えが必要なアプリの利用やカスタムロム、カスタムカーネルといった改造が可能になります。 ただ、DOCOMO様の保障が受けられなくなる行為です。また、失敗すると起動しない状態に陥ることがあります。さらに、動作が不安定になるなど、思いもよらぬトラブルに繋がることがあります。すべてにおいて自己責任でお願いします。 初期化方法(SEUS使用) PC、ネット環境も必須です。 １．ここよりSEUSをダウンロード(SO-01Bと書いてありますが、使えますので気になさらず) ２．PCにインストール(アップデートとかもしてください) ３．SEUSを立ち上げ、電源の切れたXperia arcの戻るボタンを押しながらUSBでPCとつなぐ ４．おわり SEUSは普通に画面の指示通りにしたら使えます。 システムファイルをいじる人とかは最初にSEUSのインストールとかarcのドライバとかしておいたほうがいいかもです。 root化 スマートフォン以下手順できますが、PCでされることを薦めます。(←理由はないが) １．Xda developers(http //forum.xda-developers.com/showthread.php?t=1044765)にて、「GingerBreak-v1.20.apk(2011/04/30時点)」をダウンロードする。(ユーザー登録が必要です) ２．スマートフォン本体の設定→アプリケーション→提供元不明アプリにチェック ３．GingerBreak-v1.20.apkをスマートフォン本体にて実行→インストール→実行 ４．「Root device」を押す。しばらく放置→再起動。 ５．おわり。 Wi-Fiアクセスポイント化(Wi-Fiルータ化) PC作業。(「Super Manager」というアプリを使用した場合の説明です) １．Dump_System_3.0.A.2.181_ADB_pulled.rarをダウンロード→解凍。 ２．解凍されたフォルダ/binのなかにある「hostapd」ファイルをスマートフォンのSDなりにコピー スマートフォン作業 ３．アンドロイドマーケットより「Super Manager」をダウンロード→インストール→起動 ４．「Settings」を押して「ROOT」の「Enable ROOT function」にチェック→戻る ５．「File Explorer」にて(２．の)「hostapd」を長押ししてコピーする。 ６．/system/bin/にて長押ししてペースト(system階層に入る時何か聞かれるので「R/W」を押す) ７．/system/内の「build.prop」をコピーしてSDへペースト ８．SD内の「build.prop」をテキスト編集にて編集 ９．「ro.tether.denied=true」を見つけて「true」を「false」に変更→保存 １０．SD内の「build.prop」をコピーして/system/内へペースト(何か聞かれたら「R/W」を押す) １１．電源ボタン長押し→再起動 １２．設定→テザリングとポータブルアクセスポイント→ポータブルアクセスポイントの設定は各自してください。 １３．ポータブルアクセスポイントにチェックを入れて １４．おわり。 カメラシャッター音変更(無音の追加) 上に書かれているWi-Fiと似たような作業です。 １．「build.prop」の中に書かれている「ro.camera.sound.forced=1」の「1」を「0」に変更 ２．再起動 ３．カメラのメニューにて「シャッター音off」の項目が追加される。 ４．おわり。 電源を入れた時のアニメーションを変える 電源いれた時にソニーエリクソン→ドコモの表示のやつです。 １．「/system/media」内の「bootanimation.zip」を差し替える。 ２．おわり 「bootanimation.zip」はgoogleで検索すればたくさん出てきます。好きなのに差し替えましょう。 自分で作成されたい方へ、PCでzipファイルを解凍して、みれば・・・わかるかもしれません。 システムファイルを書き換える 表示されているアイコン・表示バー等が変えられるようになります。 システムファイル書き換えは少し間違えれば、初期化しなくてはならなくなるので、初期化したくない人はやめましょう。 PC必須です。やり方は複数あります。そのうちの何個か書いておきます。PCに詳しくない人は少し大変かも知れません。 Root Explore等システムファイルを書きかえれるアプリを持っている場合は、Java Development Kit(JDK)、Android SDKがいりません。 必要ソフト： 7-Zip(リンク先にDLリンク有)圧縮・解答ソフト .apkファイルにファイルを追加削除するために使います。 Apk Manager 4.9(XDAにDLリンク有(登録不要))システムファイルの変換ツール .apkファイルの展開(分解)、再変換するために使います。解凍して好きなところにおいてください。 Java Development Kit(JDK) .apkファイルを本体に書き換えるために必要です。(これがないと下のAndroid SDKが動かないはず) Android SDK(ZIP版)(リンク先にDLリンク有) .apkファイルを本体に書き換えるために必要です(任意の場所に(すきなところに)解凍してください) 作業→SDK Managerを起動→しばらく待つ→インストールボタンを押す。しばらく待つ→終わればすべて閉じてください。 マイコンピュータ→右クリック→プロパティー→システムの詳細設定(このへんはXPは若干違うかもです)→システムのプロパティーウインドウの詳細設定タブ→環境変数を押す→「システム環境変数」の中に「Path」がある人は「編集」を、ない人は「新規」を(編集の人は選択して)押す。→編集の人は変数値に「C ￥～展開したとこ～￥android-sdk-windows￥platform-tools￥」を追加(ドライブ名も自由です。)(セミコロン半角「；」でパスは区切ってください)新規の人は変数名「Path」変数値「C ￥～展開したとこ～￥android-sdk-windows￥platform-tools￥」を追加(ドライブ名も自由です。)」すべて閉じてください。一度PC再起動をお勧めします。 バッテリー表示を１００段階表示に変更 (前置き)上の「システムファイルを書き換える」をよく読んでください。 １．Xperia arc内の「system/framework/framework-res.apk」をSDなりにコピーしてPCへ移動なりコピーなり。(初期のものは残しておきましょう) ２．Apk Manager 4.9にてframework-res.apkを分解(展開)(使い方は検索するとたくさん出てきます。こことか) ３．「framework-res.apk\res\drawable\stat_sys_battery_charge.xml」、「framework-res.apk\res\drawable\stat_sys_battery.xml」を１００段階に表示するように書き換える。 ４．Apk Manager 4.9にて変更したものを変換 ５．初期のframework-res.apkを「7-Zip File Manager」を使って「４．」で変換された「３．」のファイルを上書きする。１００段階分の画像を「res\drawable-hdpi」に入れる ６．framework-res.apkをSDカードへ移動なりコピーなり。 ７．システムファイルを書きかえれるソフトを持っている人はframework-res.apkの名前を適当に変更して「system/framework」内へ、パーミッションを「６４４」に変更後「framework-res.apk」へリネームしてください。 ８．「７．」のようなソフトを持っていない人は、PCとXperia arcをつなぎ→PCから自動検出されたもの(マウント）を解除→コマンドプロンプト(cmd)よりコマンド入力 SD直下に「framework-res.apk」をおいてください コマンドプロンプトを立ち上げたら以下の4行を上から順に入力 adb shell su mount -o remount,rw -t yaffs2 /dev/block/mtdblock2 /system dd if=/sdcard/framework-res.apk of=/system/framework/framework-res.apk ９．再起動で立ち上がれば、完了 １０．再起動しつづけたら・・・・電池パックを抜いて、上にある初期化をしてください。(どこかが間違っています。) 最後に、100段階になっている「framework-res.apk」は検索するとたくさん出てきます。ゆえに、好みのものがあれば「7-Zip File Manager」にて置き換えるだけなので、「２．」～「４．」の作業は省かれます。(ぶっちゃけそっちのほうが楽だったりします。失敗もしないだろうし・・・) 最後の最後に、適当に書かれています。すいません。こことかこことかここに詳しく書いてあります。 コメント ついに取得可能に http //kimobiler.blog133.fc2.com/blog-entry-179.html -- acroのroot (2011-08-31 02 18 51) 名前 コメント 今日 - 昨日 -