キモブロ

Please spy check please, Fucking retard

L4D2のチャージャーの弱点 = パイプボム

ultraistterさんがL4D2やってるのかーということに気づいたのでチャージャーの秘密を書きます

投げた後のパイプボムがあると物理判定があるのでチャージャーはそこにぶつかっちゃいます。
なので突進してきてる方向にうまいことパイプボム投げることでそこで止めることが出来ます。

実用性0、そしてもうfixされてたりして

ヒカリエのオフィスエリアへの移動経路がわからない

8Fだかの広いカフェみたいなところからオフィスエリアへのエレベーターがあることは知ってるんだけど。941さんの記事を読んで予習しておこう
http://blog.kushii.net/archives/1783456.html

会社の下の階がショッピングモールなのって結構便利そうだけど映画館とかないのかな。映画館あったら最高なんだけど。東急シアターオーブってのが映画館ならいいのに。平日の先行公開映画をお昼とかに見に行けるみたいな。サイト見る感じ演劇っぽいんだよねぇこれ。演劇というのをぜんぜん見たこと無いのでまだ興味が無い。

demoファイルの問題について

demoファイルには録画したプレイヤーが試合中に実行したコマンドが記録されており、そのdemoを再生したプレイヤーは同じようにそのコマンドを実行してしまうという問題がある。

たとえば何が問題かというと、設定によってはcl_interpの設定、netgraphの設定など。そういうのを勝手に書き換えてしまうことがある。これを防ぐためにはdemoを録画する前にdemo_recordcommandsを0にしておいたほうが良い。人にdemoを見せる可能性のある人はこれをautoexec.cfgに記載しておくのが良いかも?

この仕様を逆に良い方向に利用するとすれば、超初心者に良い感じの設定をレクチャーするときに便利かもしれない。
demo_recordcommandsを1にして、demo録画を開始し、コンソールでexec autoexec.cfgしたあとでdemo録画を停止、生成されたdemoファイルを渡して「このdemoファイルを再生すればいい感じのlerp設定になるよ」みたいな事ができるかも。(試してない)

アート・オブ・コミュニティって本買った。


http://www.oreilly.co.jp/books/9784873114958/

目次

訳者まえがき
まえがき
はじめに

1章 アート・オブ・コミュニティ
    1.1 コラボレーション駆動のエートス
    1.2 コミュニティの本質
    1.3 コミュニケーションの基礎
    1.4 チャンスをつかむ
    1.5 コミュニティマネージャ:コミュニティになる
        1.5.1 個性をこじ開ける
        1.5.2 信用こそがすべて
        1.5.3 聞くことの価値
        1.5.4 エゴを避ける、さもなければ他の人があなたを避ける
        1.5.5 理論vs行動:行動が勝つ
        1.5.6 自分自身になる
    1.6 次章に向けて

2章 コミュニティ計画
    2.1 成功への計画
        2.1.1 コミュニティ:俯かん視点
    2.2 チーム:一体感を生み出す構成要素
        2.2.1 自分の場所を見つける
        2.2.2 一体感の単位
        2.2.3 読み手 vs 書き手
        2.2.4 実績主義
        2.2.5 一緒に働くこと=成功
        2.2.6 多様性
    2.3 コミュニティのデザイン
        2.3.1 オープンな中で焼き上げる
        2.3.2 ミッションステートメントの構築
        2.3.3 戦略計画の構築
    2.4 計画を書き上げる
        2.4.1 ブレインストーミングのためのアイディア
    2.5 一緒に綱を引く
        2.5.1 チーム:分割と統治
    2.6 戦略のドキュメント化
    2.7 まとめ

3章 風通しの良いコミュニケーション
    3.1 彼が言った/彼女が言った
    3.2 コミュニケーションチャンネルの構築
        3.2.1 わかりやすいコミュニケーションのための努力
        3.2.2 選択、選択
        3.2.3 コミュニケーションのメディア
    3.3 例を示して会話の仕方を伝える
        3.3.1 毎日のコミュニケーション
        3.3.2 長い文章
    3.4 まとめ

4章 プロセス:シンプルであれば継続できる
    4.1 獲得すべきものに視線を向け続ける
        4.1.1 大切なものから視線を外さないようにする
    4.2 最高のプロセスを構築する
        4.2.1 複雑な物を分解する
        4.2.2 プロセスをじっくり考える
    4.3 ニーズを査定する
        4.3.1 コミュニティのサイクル
        4.3.2 コミュニティの入り口
        4.3.3 貢献者を評価する
        4.3.4 フィードバックの管理
    4.4 プロセスに賛同してもらう
        4.4.1 プロセスをドキュメント化する
        4.4.2 つけやすくする
        4.4.3 プロセスを使用する
    4.5 プロセスの再評価
        4.5.1 習慣化する
    4.6 次章に向けて

5章 ワークフローを補助するツール
    5.1 自分のワークフローを理解する
        5.1.1 役割
        5.1.2 シンプルなワークフローの構築
        5.1.3 コラボレーションのメカニズム
        5.1.4 シンプルなワークフローのサンプル:Ubuntuのバグワークフロー
    5.2 最高のインフラの構築
        5.2.1 SaaS(ソフトウェア・アズ・ア・サービス)
    5.3 リソース崇拝を避ける
    5.4 技術コミュニティで使うツールについて考える
        5.4.1 バグのトラッキング
        5.4.2 ソースコード管理
        5.4.3 協調編集
    5.5 コミュニティの風通しの良さの維持
        5.5.1 ツールアクセス
        5.5.2 コミュニケーション
        5.5.3 レポート
    5.6 定期的なワークフローの見直し
        5.6.1 構造化したフィードバックを収集する
    5.7 次章に向けて

6章 Buzzの波を起こす
    6.1 マインドシェア
        6.1.1 マインドシェアのチャンス
    6.2 Buzzの波を構成する要素
        6.2.1 ミッション
        6.2.2 一緒に連帯する
        6.2.3 周りを動かす言葉
        6.2.4 活動家になる
        6.2.5 間違った行動をしないことが正しい行動
        6.2.6 誠実
    6.3 基地を設置する
        6.3.1 狙い
        6.3.2 最新情報に維持する
        6.3.3 会話を作り上げる
        6.3.4 オンライン化する
        6.3.5 マイクロブログ
    6.4 Buzzの波のサイクル
        6.4.1 計画
        6.4.2 ビルドアップ
        6.4.3 アナウンス
        6.4.4 レビュー
    6.5 Buzzのターゲット
        6.5.1 コミュニティのアナウンス
        6.5.2 コミュニティのサポーターを増やしていく
    6.6 アライアンスを作る
        6.6.1 プロのメディア
        6.6.2 アマチュアのメディア
    6.7 まとめ

7章 コミュニティの評価
    7.1 コミュニティの内省
    7.2 フィードバックの基礎
        7.2.1 目的の定義
    7.3 フックとデータ
        7.3.1 統計と自動収集のデータ
        7.3.2 調査と構造化されたフィードバック
        7.3.3 観察によるテスト
        7.3.4 評価システム
        7.3.5 一般的な認識を収集する
    7.4 匿名とプライバシー
        7.4.1 匿名
        7.4.2 プライバシー
    7.5 次章に向けて

8章 運営
    8.1 責任
    8.2 運営には価値がないわけではない
    8.3 運営とコミュニティ
    8.4 運営のケーススタディ
        8.4.1 リーダーに従う
        8.4.2 人々を参加させる
        8.4.3 刺激を与えることを目指す
        8.4.4 平穏を維持する
    8.5 リーダーから学ぶ
        8.5.1 独裁的でカリスマ的なリーダーシップ
        8.5.2 啓蒙的独裁体制
        8.5.3 委任による運営
    8.6 コミュニティ・カウンシルの設立
        8.6.1 評議会の設計
        8.6.2 カウンシル(評議会)の設立趣意書
        8.6.3 評議会メンバーの指名と選出
    8.7 サンプル:Ubuntuの運営
        8.7.1 まず最初に
        8.7.2 Ubuntuコミュニティの体制
        8.7.3 メンバーシップ
        8.7.4 エスカレーション
    8.8 運営の拡大
        8.8.1 いつがその時かを知る
        8.8.2 サブ・カウンシルを作る
        8.8.3 のコミュニケーション
    8.9 まとめ

9章 対立への対処
    9.1 動物の本能
        9.1.1 対立の構造
    9.2 嵐の前の静けさ
        9.2.1 議論好きな性格
        9.2.2 提案に対するバリア
        9.2.3 責任に関する問題
        9.2.4 正当性の欠如
    9.3 対立解決のプロセス
        9.3.1 ファシリテーターという役割
        9.3.2 対立の解決
    9.4 燃え尽き症候群に対処する
        9.4.1 燃え尽き症候群の発見と治療
        9.4.2 ワーク・ライフバランス
    9.5 まとめ

10章 イベントの開催と運営
    10.1 ファミリーの価値を創造する
    10.2 イベント
    10.3 準備を行う
        10.3.1 ステップ1:要求の理解
        10.3.2 ステップ2:協力者を探す
        10.3.3 ステップ3:締め切りの設定
        10.3.4 ステップ4:時間を作る
    10.4 物理的なイベントの準備
        10.4.1 共通の要素
        10.4.2 スプリントの準備
        10.4.3 サミットの開催
        10.4.4 アンカンファレンスの準備
    10.5 スポンサーの獲得
        10.5.1 自分のニーズの理解
        10.5.2 スポンサーの見つけ方と対応
        10.5.3 お金の取り扱い
    10.6 オンラインイベントの運営
        10.6.1 共通の要素
        10.6.2 オンライン・ミーティング
        10.6.3 オンライン・チュートリアル
    10.7 まとめ

第一幕の終わり
索引

TF2向けのローカル練習マップパックというのを作りました

ローカル練習に便利なマップを1つのzipにまとめてみました。割といろんなサイトから探してこなければならなくて大変だったので。

詳細は以下のフォーラムのページに記述したのでよろしければどうぞ!
http://game.kymt.me/forum/viewtopic.php?f=15&t=25

tr_walkwayでショットガン使うと赤い×マークが大量に出る問題の対処法

書いた
http://game.kymt.me/forum/viewtopic.php?f=15&t=26

あと今後はTF2に関する話題はこのブログではなくて全部フォーラムの方に投稿する感じにするので、よかったらTF2プレイヤーで読んでくれてた人はこのページも見てもらえると嬉しいです
http://game.kymt.me/forum/viewforum.php?f=15

あと何かあれば気軽にトピック立ててもらえれば。くだらない雑談とかでも質問でもガンガン新しいトピック立てまくるのがフォーラムの基本みたいなかんじで、有益なトピックに関しては"告知トピック"という状態にいずれ設定することになってて、そうなったトピックは常に一番上に表示されるようになるので全然問題ないんですね。フォーラムよく出来てる!