• Ver0.7.0 0.7.1抜粋 #Minecraft #JointBlock

    2017-04-13 14:101
    クローズに伴い、7.1を触ってない人も居ると思うので、
    こちらも抜粋。

    ※例によって記事内の文書や画像の転用OKです。
     ただし間違ってる部分もあると思うので自己責任で。

    0.7.0&0.7.10.7.2&0.7.30.7.2&0.7.3Ring

    ──────────────────────────────────

    0.7.0 2016年9月04日 37ページ目 PostNo.282272
    0.7.1  2016年9月11日 38ページ目 PostNo.282868

    ──────────────────────────────────

    [0.7.0新要素一覧]
    ◆jarの統合
    ◆R.I.N.G.
    ◆試験的に燃料スロット追加
    ◆/jbbuildobjコマンド
      ↑に伴いobjファイルの読み込み部分をフルスクラッチ

    ──────────────────────────────────
    [/jbbuildobjコマンド仕様]

    ◆アセンブル状態のユニットからCarvingのレンダリング情報のみを抜き出してobjファイルとして出力します
    ◆ブロックやモデルなどは出力されません。Carving部分のみです
    ◆「/jbbuildobj 出力ファイル名 [オプション:t]」
     でConfigフォルダ下「JointBlock」フォルダの「objout」フォルダに現在時刻名のフォルダを作成し、
     その下に指定したファイル名でobjファイルを出力します
     ※自動生成されりゅ 1kbだったら大抵失敗してる。
      成功率は低いので、選択するブロックを変えて10回前後トライ
      成功した時はマイクラがしばらく固まるのでわかる。
    ◆一緒に出力されるmtlファイルは色情報が入っています
     objファイル内で紐付けが指定されているのでobjのファイル名を変える場合はobj内の該当箇所とmtlのファイル名も変更して下さい
    ◆tオプションをつけると全ての面が三角形で出力されます
    ◆「/jbbo」「/jbobj」でも可
    ◆なんか出なかったりエラーだったりした場合は「こういうデータでエラーがでたよ」とご一報くださると直るかもしれません
    ◆クライアントの描画能力を借りてobjを構築する仕組みなので、処理能力はクライアント依存です(サーバー側は一切関わりません)
     というのもあって普段はちょっと気にしているメモリの消費量やGcへの配慮などは一切ありません
     ->つまり処理が重たい、と思っておいてください
    ◆メッシュ面の統合などはモーション部位区切り毎に行っているのでそのあたりを意識して機体を作ると出力がきれいかもです
    ◆書き出す際に限界がなくともJBで読み込む際には頂点数の限界があるのでご注意ください
     JBで読み込ませる目的で出力する場合は腕や脚などのパーツ毎に小分けしてobj化するといいかもです
    ◆mltを読み込むようにするためにobjロード部分をフルスクラッチで書き直しています
     今までに読み込めていたデータが読み込めなった、などのケースもご一報くださると直るかもしれません
     コア下のモデル最下部を中心にobjファイルがつくられる。
     ちなみにニコ立体に載せるにはこのobjだとだめで、私の場合いったんブレンダーにインポートして、メタセコイア形式(mqo)でエクスポート。
     mtlファイルはそのままでいいので、mqoとmtlファイルで圧縮してアップしてます。

    ──────────────────────────────────
    [変更点一覧]

    ◆新アイテム「パラメータ転写メモリ」を追加(クリエイティブ専用)
     スニーク右クリックでコピー、他のブロックに右クリックでGUIを開きコピーです。
     もはや、これがないとめんどくさく手機体が組めないw
     0.7.3からは特殊設定もコピー出来るようになった。



    ◆初期値入力画面でCTRLキーを押すと「削除」「コピー」「ペースト」が表示されるように
     追加するで、初期値をレイヤー化



     Ctrlを押すと上にコピペダブと、左にブロック移動タブが出る


     コピー元のレイヤーでCopyを押す。


     コピー先のレイヤーでPasteを押す。これで初期値が複写される。
     またDelを押せば問答無用でレイヤー削除される。
     作業量を考えたらY/Nないままがいいかもね。



     解説がないけど、左のタブは、チューナーと同じように次のブロック、
     前のブロックへの移動用。
     初期値のコピーは他のブロックへも可能なので、連続して変更する場合は便利かも。
     コアに近い方が「P」遠い方が「F」ね。
     分岐は判断してないので、戻ってく時はいいけど、
     先に行くときはどこ行くかわからんかも。




    ◆座席の設定に「搭乗者のYaw強制同期」を追加

     OP(席1)のときはRINGでOPCutしているとき以外は使わないほうがいいです

    ◆部位破壊を完全廃止

     再びの廃止。やっぱり不評みたいだったので…
     意外と楽しかったけどね(笑)対戦だとコクピット破壊で逆転とか、
     武器破壊で形勢逆転とかあったし。
     HP半分以下になると結構ヤバイ。
     クリエイトじゃない場合は大変かもね。

    ◆キーMCTLの検知キーを増加

     各種移動キーとマウスホイールの上下を追加しました
     WASD+ジャンプとスニーク、マウスホイールの上下。
     割と画期的で面白いです。
     Ringで代用できるようになったけど、設定簡単だからまだお世話になるね。

    ◆jar統合にともないJBRobotModelのConfigを廃止
     モデルのフォルダ名は「JointBlock」固定にしました。
     (たぶんあんまり変える人もいないだろうし…)

    ◆カービング無分割を追加
     スニークキーを押しながらパテを適用すると無分割から始まります


    ◆全アクションについて指示者なしでもアクションの実行を可能に
     問題がでるかも。変な挙動があったらご報告ください
     これわかんない。

    ◆各パーツの値の更新・通信方法を若干修正
    ◆GUIのスクロールバーをマウスホイールでも上下できるように
     またスクロールバーの表示方法を若干改善
    ◆クライアント側設定「cutoffMouseScrollWithCtrl」を追加
     デフォルトではoff(false)ですon(true)にするとCTRLを押しているときにMincraft側のホイールキーイベントを殺します
     特にいらない方は気にしなくてもよいと思います
     アイテム選ぶのにホイール使うからねぇ。汎用キーとして使う場合必要かも。

    ◆サーバー側設定「unitEnergyRecoveryMode」を追加
     0がデフォルトで、新仕様の燃料消費モードです
     1にするとレガシーモードでユニットは燃料を消費せずENを回復します
     1にしとけば石炭入れなくても動くし、アセンブル後、即EN満タンになります。
     石炭で動くロボットってのもなんか不思議。
     何かでエネルギーアイテムを生成できるといいかもね。


    ◆サーバー側設定「unitFuelEfficiencyMult」を追加

     燃料値の算出に使用しています

    ◆サーバー側設定「worldMaxEntityRadiusModifier」を追加
     ※この項目を触るとMinecraftバニラ全体に影響するので、変更に際しては下記をよくご理解のうえ変更をお願いします
     -背の高いユニットを組み立てたときなど、攻撃などが上部のバウンダリに当たらない現象に遭遇されたかたも多いかと思います
     これは衝突判定時に他のEntityを検索する際にチャンクを縦に分割した領域ごとにEntiyを保持しているためで、
     衝突判定以前に領域が検索にかからなければEntityそのものが抽出されないということが起こるからです。
     上記worldMaxEntityRadiusModifierは数値を上げることで検索する上下領域を増やし、
     衝突判定時の検索でEntityが判定対象として抽出されるようにします。
     (これにより「ユニットの上のほうだけ攻撃が当たらない」ということが起こらなくなります)
     反面、全ての検索時に検索領域が増えることで処理のコストが増大します(バニラや他MODの処理にも関わってきます)
     以上トレードオフをご理解のうえ変更をお願いします

    ◆サーバー側設定「entityJointedTrackingRange」を追加
     ユニットのトラッキングレンジをいじります
     一応設定を設けてみましたが、、たぶん問題ない?

    ──────────────────────────────────
    [バグ修正・改善]
    ◆種消費バグ修正
    ◆Te状態のコアインベントリがセーブ時に正常に保存されない場合があるバグを修正
    ◆スライダーバネKeyMCTLの入力項目の刻みが10単位になっていたのを修正


    漏れがありそうなので加筆される可能性大
    ──────────────────────────────────
    [R.I.N.G.仕様]
    ◆ユニットの燃料画面でセットすることでアセンブル後は毎tick動き、各ノードの処理を実行していきます
    ◆ページ毎にMAX24ノード、32ページまでひとつのR.I.N.G.に登録可能です
    ◆サイクルモードでは前回tickで止まった場所から再開します
     ショットモードでは毎tick0ページ0ノードから処理を開始します
    ◆サイクルモードでは1tick内に無限にノードを処理できるわけではなく、
     下記のルールに従ってtick内処理を中断して次のtickに処理を引き継ぎます
     (ルール①)
      同tick内で同じノードを二度実行しようとすると中断。次tickはそのノードから始まります
     (ルール②)
      24(1リングMAXノード数)*3=72の数のノードを処理すると中断。
     上記いずれの場合でも次tickは前tickに中断したノードから始まります。
     以上ルールによってひとつのユニットが無限にCPUリソースを消費することを防いでいます
     ただ、上記仕様のためノードの処理がどこで止まるか、また、どこから再開されるかの保障はなく、
     意図した動作にならない場合もあると思います。
     必ずtick内に動作させたいノードがある場合などはショットモードを選択してみてください
    ◆全てのノードは出力を持ち、他のノードから参照されたときに必ず何かの値を出します
     基本的には
      ・真偽値(TRUE,FALSE)
      ・実数(浮動小数点)
      ・整数(浮動小数点を受け取り手に応じて整数に切り捨てたもの)
     が返されます
    ◆ノードは大別して
      ST系ノード(シンタックス系ノード。つまり構文ノードです)
      DR系ノード(命令形ノード。ユニットやパーツへチャンネルを解して命令を出すノードです)
      TG系ノード(トリガー系ノード、あるいはセンサー系ノードと呼んだほうがいいかも?)
     に分けられます
    ◆上記DR系ノードは実行される際、必ずその仕事内容と関わる「チャンネル」を介して実行を行います
     チャンネルには一つのノードのみ登録でき、あるノードが登録されている間は他のノードの登録を受け付けません
     (強制的にクリアするためのノードもありますが、基本的にはこのルールです)
     全てのDR系ノードには「仕事期間(tick)」があり、仕事期間を経過するとチャンネルから退きます
    ◆OPCutにチェックを入れたR.I.N.Gがセットされたユニットは席1の基本操作を受け付けなくなります
    ◆変数系ノードの内部値はjavaのdoubleすなわち倍精度(64bit)浮動小数点です
    ◆シングルでプレイしている場合のみ/jbringdebugコマンド(/jbrd・/jbdrでも可)
     「/jbringdebug on/off またはスロット番号」
     スロット番号は左上から右へ0, 1、左下から2, 3です
     (サーバーサイドから直接実行情報を見に行っているだけなので外部サーバーの場合は情報を取れません)
     サーバーから情報をネット越しに送信するようにすればマルチでもデバッグ可能ですが。。たぶんやりません)

    <20160905 GUIの機能について追記>
    ◆左のノードリストからドラッグ&ドロップでノードをページに追加
    ◆ページのリング状でノードを選択し、右側に表示された入力項目から各ノードの値を設定
    ◆REFとFIXが切り替えられる項目について
     FIX(:FIXED=固定値)はユーザーが入力した値そのままを利用します
     REF(:REFERENCE=参照値)は指定したノードの出力値を利用します
     ※例えばモーションDRノードでローテーターの回転値をユーザーのYAWから取りたい場合などは
      ユーザー状態センサーノードのYAW(相対)からY軸の値をとることで追従っぽいことが可能です
      (ただユーザー状態センサーノードの各検出値は乗っていない場合でも0を出力するのでその切り替え判断も必要ですが)
    ◆REF項目があるノードは左クリックでドラッグすることで線を他のノードへ接続可能
     (※もちろんノードインデックスを直接指定するのでもOK)
    ◆Shiftを押しながらリング上のノードをクリックすることで複数選択が可能
    ◆ノードのTIPSに書いてあるInfやNaNって?
     Infは浮動小数点表現の無限
     NaNは不正な計算(ゼロ除算とか)などにより生じる非数のことです


    ──────────────────────────────────
    [0.7.1変更点]
    ◆コアの特殊設定に「スレーブ独立・モーション」「スレーブ独立・OP」の項目を追加
     項目の追加に伴い移動系およびキー系のMCTLの動作を以下のように修正
     ・移動系トリガーのMCTLはスレーブ接続時にデフォルトでは動かなくなるよう修正(マスター接続時は初期値に固定されます)
      モーション独立にチェックを入れた場合のみ移動判定を拾ってモーションを実行します
     ・キー・アイテム系MCTLは「OP独立」を選択しない場合はこれまで同様にマスターよりキー入力等を受け取り処理を行います
      「OP独立」を選択した場合はスレーブ本体の入力にもとづいて処理を行います
      また、 「OP独立」にした場合、スタビライザー系(親の回転をリセット系)の基準回転はマスターではなくスレーブ本体のyaw値から再計算されます


    [バグ修正・改善]
    ◆/jbbuildobjでゼロスケーラーをかませるとエラーとなるバグを修正
     ※ただしゼロスケール部位はにフェイスの統合がされない場合があります(扱う少数表現の誤差のため)
      なるべくゼロスケールの部位は除いて出力したほうが余分なデータを出さないので良いかと思います
    ◆法線の計算が不正となり特定の平面が出力されない場合があるバグを修正
    ◆R.I.N.G.のアクション指示でノーマルなど一部ジョイント種が反応しないバグを修正

    ◆スレーブのyawをマスターより取得していたのをアフィン変換から改めて算出するよう修正

     具体的には座席の向いている方向からyawを取り出します。なので極(直上、直下方面)付近では小さな差でもブレが大きくなるのでその点ご留意ください。
    解るようなわからないような。

    ◆上記スレーブyaw等、R.I.N.G.で取得できるものはスレーブユニット本体のものに固定(マスターのものを見に行かない)
     ->warosukeさんご提案の共有ノード(あるいはマスターへのミラーなど)で相互に値を見に行けるようにする予定。。。予定
    まずはRingの使い方をマスターしてからですね!

    ◆GUIにてText項目を出したままマウスホイールをスクロールすると入力先項目がずれるバグを修正(ホイール入力があるとテキスト項目を閉じるように)
     ->まからさんの書いてたのはこのことでしょうか…? 他の現象でしたらまた教えてください。
    アザース


    上にも書きましたがたぶんR.I.N.G.データはverupに伴い旧データは使えなくなると思います。
    (もう少し拡張性のあるデータ形式に変更したい。。。行き当たりばったりでごめんなさい)
    開発版についてアドバイス・ご指摘を頂いた方々にはここに御礼申し上げます。
    他にも何か気づいたことや不備・あるべの思い至ってなさそうな点、バグなどありましたらお手数ですがまた書き込んでおいてください。
    Ring二期、はじまったよ!


  • 広告
  • Ringについての考査 #Minecraft #Jointblock

    2017-04-12 12:4513
    更新された中のRing部分だけを抜粋。

    ※例によって記事内の文書や画像の転用OKです。
     ただし間違ってる部分もあると思うので自己責任で。

    0.7.0&0.7.1
    0.7.2&0.7.30.7.2&0.7.3Ring


    ──────────────────────────────────
    46ページ目 PostNo.299844

    2017年4月05日(水) 21:59

    Ring部分抜粋
    ──────────────────────────────────
    [0.7.2新要素一覧]
    ◆ターゲットシステム
     
    RINGにやらせたかったことを実現するキモの新システムです
     ユニットあたり5つのターゲットを持つことが出来ます
     設定したターゲットはキーMCTLの新機能「ターゲットへ回転(ローテーター用)」と組み合わせることで
     パーツをターゲット方向へ向けることができたり、RINGの「移動タスクノード」と合わせて自律移動などを行わせたりできます


     [ターゲット指定方法その①:ターゲットサイトアイテム]
     ユニットに搭乗して新アイテム「ターゲットサイト」を持つと一定範囲のEntity上にターゲット選択リングが現れるので
     右クリックでターゲットを選択することができます
     複数選択する場合は右クリックを押しっぱなしでそれぞれをドラッグオーバーしてください
     ctrlキーを押すごとにターゲットの指定方法が「生物のみ」「Entity全て」「ブロック指定」に切り替わります
     ブロック指定の状態ではブロック座標をひとつのみターゲットとすることができます
     [ターゲット指定方法その②:RINGのノード「ターゲット設定指示ノード」]
     後述のセンサーノードの機能などで取得したEntityIDをターゲット指定ノードに渡してやることで
     RING内でターゲットを指定することが出来ます
     
     なお0番ターゲットは固定でアセンブル主になります
     上手く組み合わせればRINGでターゲットを自動検索して射撃する機体なんかも作れるかも
     
     (※注意※ターゲット情報はEntityの保存情報に含まれていません
      セーブ・ロードを挟む、チャンクのアンロードを挟むなどで頭は空っぽになるのでご留意のうえご活用ください)
     
    ◆センサー機能(主にRINGで使用)
     新アイテム「センサーMCTRL」を配置することで対象ブロックを位置センサーとしてRINGに認識させることができます
     「センサー状態検知ノード」よりセンサーの位置を取得することができるほか、
     「Entity検索指示ノード」により検索されたEntityIDを取り出すこともできます
     
    ◆移動タスク指示(RING機能)
     ターゲットに追従してユニットを移動させることができます
     ただ経路検索のコストがユニットの高さに比例して跳ね上がるので、一般MOBなどに比べると若干頭が悪いところがあります
     ジャンプを活用しないなどもろもろの制限はありますが、その点ご理解いただけるとありがたいです
     
     (※ごめんなさい。ひとまず歩行系とホバー・ヘリだけの対応です。エアクラフト・フロート・宇宙などは未実装です)

    ◆Entity状態検知ノードとBlock状態検知ノード
     それぞれEntityIDやブロック座標を渡してやるとそのEntity/Blockの一部情報を取得して出力します
     ※ただし「Block状態検知」のほうは現状唯一のオーバーパワーノードとして「enableOverpowerNode」設定の影響を受けます
      設定ファイルを変えるか(デフォルトでは否設定)、「jbcset enableOverpowerNode true」で一時的に有効化できます
      (使い方によっては鉱脈検索機なども作れてしまうため)

    ◆ベクタ入出力(RING機能)
     
    詳細な説明は割愛。4値までのなんちゃってベクタを扱える感じです。座標などを受け渡ししたかったので付け加えました
     現状ノードの代入機能でベクタは渡せないのであしからず


    ──────────────────────────────────
    [変更点一覧]
    ◆RING保存データ形式の変更

     0.7.1のRINGは使えませんごめんなさい。(データ形式をだいぶ変えちゃいました)
    ◆RINGノードの全体的な挙動変更
     -コントローラー越しにRingDebugもできるように
     -TG系ノードはTICKで最初に値を要求された時点での値で同TICK間は固定するように(循環参照対策)
     -TG系ノードは通過時にも値を更新するように
     -TG系の例外時にはERROR値を返すように変更
     -ERROR値を受け渡されたDRは仕事をしないように
     -ifにERROR値判断を追加
     -Linkノードで循環参照を防ぐためにリンク深度(リンクのリンク)を最大5に設定
      (TG系と同じくTICK内で最初に更新されたリンク先で同TICK間は固定)
     -座席番号項目を全てRef可能に
     -キー入力DR・検知ノードに項目「シングル/ダブル」を追加
    ◆RINGの他ページ呼び出し時、呼び出し元情報を限定でstackする仕様に
     8呼び出しまでスタック。スタックオーバーフロー時は古い順から消えていきます


    ──────────────────────────────────
    [0.7.3修正・追加要素一覧]
    ◆RING移動タスク「自由に徘徊」などのランダム目的地到達判定が場合によって不正となる問題を修正


    [おまけ②:RINGサンプルいくつか]
    ※全てRINGを設置したユニットの設計図データなので設計図とコンストラクタに突っ込んでください

    改めて俯瞰すると移動タスクchのクリアとかターゲットのクリアとかアトラクター処理とか色々足りないですが、そのうち追加していきます、、、

    正式への格上げはもうしばらく様子見

    ──────────────────────────────────
    フォーラム47ページ PostNo.300337
     
    2014年1月22日
    [RINGざらっと解説]
    ◆[基本の動作概念]
    ・RINGは0ページ0番から開始し、ノードを順番に実行していきます(順次実行)
     ノードは時計回りに矢印で繋がっていると思ってください(ごちゃごちゃするのでRING画面では省略していますが)
     1TICK内で処理できるだけのノードを処理します
      ×間違った理解 → 1TICKで1ノードを処理
      ○正しい理解  → 1TICKで複数ノードを処理
    ・標準のモードである「サイクル」だとページの最後まで到達すると同ページゼロ番に戻ります
     (時計回りに処理が続けられるイメージです。11時の次は0時になるように、ひたすら針は回り続けます)
     ただそれだけだと時計の針が延々と回り続けて処理が終わらず、CPUのリソースを無限に消費し続けることになりますが、
     下記のルールにおいてTICK内で処理が一時中断される制限を設けています
      -TICK内で規定数以上のノードを通ると一時中断。
      -TICK内で同じノードを二度通ると一時中断。
     次のTICKでは中断したノードから再開されます
     
     ※要約※
     RINGは時計回りの順次実行!
     TICK内で制限に引っかかるまで順番にノードを処理!
     RINGはTICKをまたいで実行され続ける!
     
    ──────────────────────────────────
    ◆[もっと具体的な動作のイメージ]
     まずはものすごい単純な例を書きます
     たとえば1ページ、ノードが6つあるRING(例1)があるとします
     
    [(例1)RING構成]

      →①→
     ⑥   ②
     ↑    ↓
     ⑤   ③
      ←④←

     〔ユニットを起動してから最初のTICK〕
     Ⅰ.ユニットの内部処理がRINGを起動します
     Ⅱ.そのTICK内でノード①、②、③、④、⑤、⑥と順番に処理をしていきます
     Ⅲ.そのまま①にさしかかると①はこのTICK内ですでに通っているためRINGは一時中断されます。
     〔次のTICK〕
     Ⅰ.ユニットの内部処理がRINGを再び起動します
     Ⅱ.前回TICKは①で中断されていたので①から再開し、また①、②、③、④、⑤、⑥と処理します
     Ⅲ.前回TICK同様に①にさしかかると①はこのTICK内ですでに通っているためRINGは一時中断されます。
     〔以下略〕
     
     上記は分岐のない場合の単純なケースですが、次は分岐のあるケースです
     たとえば⑤のノードがジャンプノードで、条件によって③にジャンプするRING(例2)があるとします

    [(例2)RING構成](例1とは別のRINGの話ですよ)

      →①→
     ⑥   ②
     ↑    ↓
     ⑤→→→③
      ←④←

     〔ユニットを起動してから最初のTICK〕
     Ⅰ.ユニットの内部処理がRINGを起動します
     Ⅱ.そのTICK内でノード①、②、③、④、⑤と順番に処理をしていきます
     Ⅲ.⑤では分岐条件によってそのまま⑥に進むか③に飛ぶかの選択があります
       今回は③へジャンプしたとしましょう。このとき本来ならば順番に処理されるはずの⑥、①、②は
       スキップ(順番を飛ば)されたことになります
     Ⅳ.RINGは③を処理しようとしますが、このTICK内ではすでに処理されているノードなのでRINGは一時中断されます
     〔次のTICK〕
     Ⅰ.ユニットの内部処理がRINGを再起動します
     Ⅱ.前回TICKは③で中断されていたので③から再開し、また③、④、⑤と処理していきます
     Ⅲ.再び⑤の条件分岐です。今回も全TICKと同様にジャンプ条件が成立し、③へとジャンプしたとします
     Ⅳ.RINGは③を処理しようとしますが、このTICK内ではすでに処理されているノードなのでRINGは一時中断されます
     〔以下略〕


    ───────────────────────────────────────
    ◆ノードの基本特性「すべてのノードは出力を持つ」

    ・「出力」って書いちゃうと何かを放出してるようなイメージですが「状態」のほうがイメージが易いでしょうか
     「いずれのノードも何らかの数値を抱えていて、他のノードに問い合わせを受けるとその値を返答する」
     それだけの話です


    ◆ノードの大まかな種類
    ・構文系ノード(ST:SyntaxNode)
    ・指示系ノード(DR:DirectionNode)
    ・検知系ノード(TG:TriggerNode)
    ※後ろの略称はあんまり気にしなくていいです。あるべが仕様を書き散らすときに使ってるだけなので
     (特にTriggerって呼び方は混乱のもとかも。ただステートノードだとSTで被るし。
      センサーだとセンサーノードと混同するし。。まあ呼び方はどうとでもです)

     ※要約※
     RINGは「構文」「指示」「検知」の三種類のノードで成り立っている!


    ◆[構文系ノード]
     ユニットやMCの動作とは関係なくRING自体の制御に関するノードです
     たとえば代表的なもので「IFジャンプノード」がありますが、RINGの流れを条件によって分岐させるノードです
     (たとえば本来であれば0,1,2,3..と順番に実行される流れを「2の次に3を飛ばして4や5へ」という風に
      文字通り先のノードへとジャンプさせるためのノードです。飛び越されたノードは実行されません)
     「もし(if)・・ならばスキップ(ジャンプ)する」ので「IFジャンプノード」です
     正直これさえ覚えておけば、他の構文系は必要になったらでいいと思います(変数系とか計算系とかは欲しくなったらで)
     
     ※要約※
     IFジャンプノードがあれば分岐が書ける!

    ───────────────────────────────────────
    ◆[指示系ノード]

     ユニットや(R.I.N.G.MCTRLが積まれた)ブロックに対して何らかの指示をするノードです
     ノードリストでは上のほうに集まっているノード群です
     たとえばユニットを前後に移動させたり、ローテーターを回したりなどの指示が可能です
     逆に言うとRINGはこの指示系にある処理以外のことは何もできません
     (今のところアトラクターなどが対応ノード未実装なので動かせないかな。。)
     指示系ノードには「チャンネル」という概念が絡んでくるのですが、、、
     ひとまずは「特定のMCTRLとノードを結び付けるキーのようなもの」の理解で大丈夫だと思います
     具体的にチャンネルが何なのか理解を深めたい方は項[チャンネルについてもっと詳しく]を読んでみて下さい。

     ※要約※
     ユニットやブロックへの指示は指示系ノード!

    ───────────────────────────────────────
    ◆[検知系ノード]

     ユニットやMCワールドの状態を認識して値を出力するノードです
     リストでは下に集まっているノード群で、クエスチョンマークの添えられたものは全て検知系のノードです
     基本的には通っても自分の値の更新意外は何の処理も実行されません。値の出力だけを担う専門家です
     一番わかりやすいものは「キー状態検知ノード」でしょうか
     指定したキーが押されてるかどうかで「出力」が変化するノードです
     特に構文系ノードの説明で取り上げた「IFジャンプノード」と組み合わせることで真価を発揮します
     キー状態検知ノードにIFジャンプノードをつないでやることで
     「キーを押されているとき以外は回転処理をスキップ(ジャンプ)」などの機能を実現することができます

     ※要約※
     状況判断は検知系ノード!

    ───────────────────────────────────────
    ◆[各ノード種類が具体的にどんなケースで使われるか]

     たとえば「座席に人が座っているときだけローテーターを動かす」という処理をRINGに記述するとして
     「座席に人が座っているとき」というのを検知ノードが担い
     「だけ」を構文系ノード(具体的にはIFジャンプノード)が担い
     「ローテーターを動かす」を指示系ノードが担うことになります

    ───────────────────────────────────────
    ◆[ノードの設定項目で「R」とか「F」とか切り替えられるのは何?]

    ・F:Fixed:つまり「固定値」です
     ユーザーの入力した値がその項目での設定値になります
     こちらは各MCTLの設定でもお馴染みですね
     (ローテーターでXの初期値に90を設定←こういうのと同じです)
    ・R:Reference:つまり「参照値」です
     参照とはつまり「見る」こと。→他のノードの出力を見に行ってその値を使うことです
     (あるべも「あちらを見てください」を「あちらを参照ください」みたいに言いまわすことがよくあるもよう)
     ユーザーの入力した値ではなく、他のノードが出力した値をもって処理を行うということです
     この方式の強みは「プログラム実行中に値をころころ変えられること」に尽きます(「値が動的である」とか言ったりします)
     主に検知ノードなどが出力した値を参照することになると思います

     ※要約※
     F:固定値とは「ユーザーが入力した値を使わせる」こと!
     R:参照値とは「(他のノードの出力値を)見に行く」こと!

    ───────────────────────────────────────
    ◆[Rでいちいちノード番号入力するのめんどくさい!]

    ・右クリック→ドラッグで引き出せる線を参照先のノードに引っ張ることで参照先IDX番号を設定できます
     ノードにRef可能項目が複数ある場合は線を引き出した状態で左クリックで項目が切り替わります
     
     ※要約※
     右ドラッグで線を繋げる!項目の切り替えは線を出した状態で左クリック!

    ───────────────────────────────────────
    ◆[その他ちょっとこまごました話]

    ◆[真偽値って??]
     よく「コンピューターは0と1で動いている」と言われたりしますが
     この0と1を「そうでない」「そうである」という概念にあてはめて「真偽値」などと呼んだりします
     一般的には
      0(:false)は「違う」こと。偽、否、違う、そうじゃないこと
      1(:true)は「合っている」こと。真、可、合致、そうであること
     という風に扱われます
     プログラムの世界ではこの通念が拡張され、たとえば整数世界では
      0:false
      0以外の数:true
     というように0のみを「false(偽)」として扱い、それ以外なら「falseではない=true(真)」と扱ったりします
     RINGもこの「0以外はtrueとして扱う」というルールを採用しています。この場合、当然「1」もtrueです

    ◆[ベクタ??って??]
    ・無視してOK!
     よほど変わったことをするのでなければV1とかV2とかベクタとかVectorとか書いてあるのはスルーで大丈夫です
     代入ではベクタが使えないなど実装も中途半端ですし、4値のベクタ計算実装してませんし、
     はっきり言ってあるべの自己満足領域です

    ◆[チャンネルについてもっと詳しく]
    ・ある特定の機構に処理を実行させるにあたり、どのノードに処理をさせるか判別するための仕組みです
     チャンネルを解することで機構は実行のタイミングでどのノードに従って更新処理などを行うかが解ります
     実行するときにひとつの要素に対して複数のノードが競合しないようにする仕組みでもあります
     ターゲット検索などの重たい処理もチャンネルを解することでtick内に一機体で複数回実行できないよう制限する役目も
     もっとイメージを掴みたい方はDROPBOXのDEVフォルダにある概念図をご参照ください


    ───────────────────────────────────────
    ◆[RINGを作っていくときひかっかりそうなところ]

    ・Q「ショットモードが途中で止まるんだけど。。」
     ショットモードは「毎TICK必ず0ページ0番から始まる」わかりやすいモードですが
     基本ルール「定められた数以上のノードを通ると中断」から逃れるものではないため
     TICK内で非常に長い処理を行わせようとすると最後まで辿りつけない場合があります
     基本的には「毎TICK絶対に行わせたい処理がある」というケース以外では推奨しません
     また分岐処理などで同じノードを二度通ろうとしても終了するため、かなり処理内容は制限されます

    ・Q「指示系ノードが動かなくて、RingDebugで見てみると「err」を出してる。。。」
     指示ノードの入力として参照したノードが「err」を出していませんか?
     たとえば座席状態検知ノードで誰も席に座っていないのにその状態を問い合わせたりすると「err値」を返します
     err値を参照した指示系ノードはチャンネルへの登録自体に失敗するので動作しません
     参照先の検知ノードなどが「err」ではないちゃんとした値を出力しているかどうか確認しましょう
     RINGにはいわゆる「例外系」はないので、かっちりとした処理を組むには適切に「err」値をハンドリングすることが必要です

    ・Q「思ったとおりに動かなくて、RingDebugで見てみるといくつかのノードが空ノードに置き換わってる」
     RINGのページ設定画面で「権限」のチェックがいくつか外れていませんか?
     一括で特定グループの指示を無効化するための仕組みで、権限に適合しないノードは実行前に空ノードに変換されます

    ・Q「座標はわかるけどEntitIDって?」
     Entityの個体を識別するMCの内部IDです。たとえば豚が二匹いた場合、それぞれにユニーク(かぶらない)な値が振られます
     基本的にMCによって生成順に一匹にひとつIDが振られ、セーブ&ロードなどを挟むと同じ個体でもIDは変わります
     
     似たようなものにBlockIDがありますが、これはEntityIDとは別に「ブロック種別」に与えられた番号で、ワールドごとに固定です
     (セーブ・ロードを挟んでも変わらないが、ワールドが異なると同じ種類のブロックでも値が違う可能性がある)
     このあたりの一意性・一貫性・IDの有効サイクルなど理解していないと思った動作にならないことがあるのでご注意ください
     (たとえばRINGでゴールドブロックのIDを割り出して書き留め、それを地下から検索するようなRINGを組んだとしても、
      他のワールドにそのRINGを持ち込むとIDが変わっていて動作が異なる、というミスが予想されます)

    ・Q「いわゆる再帰処理を組んだんだけど、思ったとおりに動かない。。。」
     ごめんなさい、他リングの呼び出し過程は8呼び出し前までしか記憶できません
     (プログラムごとにセーブ時の実行状態を保存するのにある程度の枠を設けなければならなかったため)
     末尾再帰化できる再帰以外はたぶん書けないと思います

    ・Q「つまりRINGって、あるTICKでどこから始まるか、どこで終わるか不定ってこと?そんなの不安定すぎじゃ。。。」
     そうです
     なので処理が長くなればなるほど「必ずしもTICK内で実行されないノード」が増えることになります
     ある程度制御をはっきりさせるテクニックとしては、たとえば「1ウェイトノード」を任意の処理の前に置けば、
     必ずそこでTICKの処理が中断され、次のTICKはその次からのノードから開始されることが保証されます

    ・Q「ひょっとして検知系ノードって通らなくてもいいんじゃ。。。」
     よくそこに気付きましたね!
     他ノードからの問い合わせでも値を計算して返すので通らなくても機能します
     固定ジャンプですっとばしたら実行ノード数の節約になります
     ただRingDebugで見るとき問い合わせされない限り値が更新されないのでちょっと不便かもです


  • Ver0.7.2と0.7.3を色々検証とか #JointBlock #Minecraft

    2017-04-12 12:376
    2017/4/12 22時 Ring関連部分をRingスレに移動
    2017/4/14  2時 各種検証解説を青文字で記述&画像のっけ
    2017/4/15 23時 アドオンと/jbboに付いてだいたいまとめ終わった。
    あとはラージユニット補正の検証とアドオンの作成ぐらいかな。

    ※例によって記事内の文書や画像の転用OKです。
     ただし間違ってる部分もあると思うので自己責任で。

    0.7.0&0.7.10.7.2&0.7.30.7.2&0.7.3Ring
    ───────────────────────────────────────

    おおきくRingと、既存機能のブラッシュアップがありますね。
    Ringについては皆さん興味津々な様なので私はあえて様子見。
    別スレにしときます。(というかたぶん深くて1スレでは収まらない。)

    親記事には、フォーラムの文書抜粋と、まとめた結果を掲載。
    コメントに検証中の内容や結果を書き込み。
    コメント自体は自由書き込みなので、質問や報告などしてくだされ。

    ───────────────────────────────────────
    47ページ目 PostNo.300343 2017年4月11日
    JointBlock0.7.3(DEV:開発版)

    DROPBOXからダウンロード

    ───────────────────────────────────────
    46ページ目 PostNo.299844 
    2017年4月05日(水) 21:59

    ※070より「JointBlock1710.jar」と「JBRobotModel.jar」の二つのjarを「AllInOne.jar」として統合しています
     070より前のverよりアップデートの際は上記両方のファイルを削除の上導入をお願いします


    以下Dropboxの「DEVELOP」フォルダよりダウンロードをお願いします
    JointBlock0.7.2(DEV:開発版)
    DROPBOXからダウンロード

    旧verワールドはユニットのアセンブルをできるだけ解いた状態でアップデートをお願いします
    (一部属性の互換性がないのでそのままだと挙動が一部おかしくなります。落ちたりはしないと思うのですが念のため)
    なお0.7.1のRINGは引き継げませんごめんなさい。


    長らくご無沙汰しておりました。今回は大半がアセンブル後ユニットのパラメータ・挙動まわりの更新です
    一度は断念したRINGですが、何度か挫折の末どうにかこうにか構想に近い形まで持っていってみました
    だいぶ力不足を痛感する今日この頃です

    以下0.7.1→0.7.2の変更点です
    0.7になってからの変更点は以前の投稿をご確認ください
    ※補足
    0.7.0 2016年9月04日 37ページ目 PostNo.282272
    0.7.1  2016年9月11日 38ページ目 PostNo.282868


    ───────────────────────────────────────
    [0.7.2新要素一覧]

    ◆ユニット化条件の撤廃
     現状ほぼ無意味な制約でしかなかったユニット化条件を完全に廃止してみました
     上記に伴い構造・ブロック数より算出していたパラメータはユニットで固定化になります
     代わりにコアにアドオンを追加することにより各種パラメータが変動するようにしました
     詳しくは下記アドオンシステムにて
     なるほど、一応ユニット構成は出るけど関係なくて、どのタイプでも選択可能。



    ◆アドオンシステム
     ユニットにアドオンを積むことで体力・ENや移動パラメータを増強できる仕組みです
     アドオンには二種類あり
      -アイテムとしてのアドオン
      -モデルとしてのアドオン
     があります

     アイテムアドオンはコアの専用タブからスロットに追加することでアセンブル後に効果を発揮し、

     モデルアドオンはモデルとして配置されていればアセンブル後に効果を発揮します
     各パラメータ補正はユニット固有パラメータを元に算出されるので、
     補正値はもともと対象パラメータの高いユニット型ほど高くなります

     (例えば横移動がもともと遅い四足歩行型などは横移動アドオンを載せてもあまり効果は高くありませんし、
      HPとENが高い車輪型はそれぞれアドオンでのHP・EN値の伸び率が良くなります)
     ↑やってみたけどアドオンの%自体は変わらない気がする。
     %で増えるので、元値の高いユニット程効果が高いのは確か。
     のび「率」って言っちゃうとへんかも同じ%

     (※以下ちょっとややこしい話。パッケージを作って遊びたい方以外はあんまり関係ないかもです)
     デフォルトアドオンではほぼ活用されていませんが、「リミットキー」(ゲーム内では主に略称「LK」で表示)
     というシステムにより、パッケージなどで追加されたアドオンなどでバランスを調整することができるようにしました
     リミット(制限)キーの名のとおり、ひとつのコアに乗せるアドオンを制限するための仕組みです
     アドオンはリミットキーに属することができ、リミットキーの上限コストによって積載制約を課すことができます
     例)リミットキーA(上限コスト5)に属したアドオンX(LKコスト1)とアドオンZ(LKコスト3)があるとして
      アドオンXを2つとアドオンZを1つ積んだ場合、リミットキーAのコストチェックでは総コスト5以内なので積載OK。
      アドオンXを3つとアドオンZを1つ積もうとした場合、アドオンZの追加はコストチェックにかかって弾かれることになります
      (※ちょっと微妙な仕様ではありますが、コストの積み上げは検索あるいは読み込み順になります)
     これはモデルアドオンにも適用可能なので、たとえばユニットにつきモデル武装やモデル部位の積載制限をすることができます
     (アドオンが無効になるだけかモデルの乗ったブロックが除外されるかはLKに設定可能)
     「アイテムアドオン」をコアに載せるとそれぞれ+-が付く。
     載せれる数は9個だけど、LK指定があるものは、コスト5を超えると加算されない。
     効果は同じアドオンでも重複するので、9つすべて同じにすると結構デカく変わる。
     (もうちょっと%小さくてもいい気がする。まぁBascを弄ればいいかもね。)
     これで機体の性格をタイプやブロック数以外で出す事が出来るようになった。

     「モデルアドオン」はブロックに「アドオンあり」のモデルをブロックに組み込むと効果がある。 

     組み込んだ際、いくつまで効果があるかは、各モデルに設定してあるLKによる。
     LK(りみっときー)と言うグループが作れて、同じLK内で最大コスト5まで効果がある。
     コストとどのLKに所属するかはモデル毎に設定できる。(3Dモデル導入で
       ※下の方の記事[モデルパッケージ・アドオン追加用json例]参照
     それを越した場合、サーチ時「無視」に入れられて効果はない。

     これはつまり、モデル導入時に「増加装甲」とか「増加パラペラントタンク」とか作ったり、装備するとHPは増えるけどスピードが遅くなるとか、強力な武器だけど、基本エネルギーがごっそり減るとか、そんな装備を作れるって事ですね。
    変化させることのできるパラメータのリストを作っておくといいかも。

    LKについては部位毎に属性を作ったり、単純に重量に見立てたり出来ますね。
    ただ、彫刻したどこかにモデルが埋まってて見つからないとかそんなこともありそう。
    (実際ウチのモデルはどこかに頭が埋まってました。まだ見つけてませんw)

     デフォルトだと頭と手のモデルにアドオン効果がある。



    基本アドオン LK:無し 
    基本アドオン(体力+A) HP+40% EN+20%
    基本アドオン(体力+B) HP+80% EN-40%


    基本アドオン(En+A) HP+20% EN+40%
    基本アドオン(En+B) HP-40% EN+80%

    基本アドオン(左右移動+) HP-10% 前方移動-5% 左右移動+10%
    基本アドオン(前方移動+) HP-10% 前方移動+10% 左右移動-5%

    基本アドオン(ステップ+) HP-10% EN-10% ステップ高+3


    基本アドオン(ジャンプ+) EN-5% 前方移動-2% 左右移動-2% ジャンプ力+20%


    基本アドオン(スラスト+) HP-10% EN回復間隔+3tick スラスター+30%



    サブタイプアドオン LK:JBSUBTYPE COST1

    基本アドオン(ST・ヘリ) HP-40% EN-20% サブタイプ:ヘリ型
    基本アドオン(ST・エア) HP-40% EN-20% サブタイプ:エアクラフト型 
    基本アドオン(ST・ホバー) HP-40% EN-20% サブタイプ:ホバー型
    ↑謎 それぞれのタイプどれにしても効果は発動する。


    ◆パターンコーナーB

     パターンコーナーAの赤ちょぼからシームレスに切り替え可能です
     (内部的には別パターンに切り替えていてインジケーターで[CornerB]と表示されます)
     ビット数を抑えるのがひとまず限界で虎の子の最後のパターン枠を使い切ってしまったのでつらい感じです
     (各コーナの両端に差をつけるのが理想ですがビット数が爆発して今の仕組みではきつい…
      分割数を抑えて自由度の高い新タイプのパターンカービングを作る、、、?
      それともいっそ自由に三角形を結べるタイプを作るべき…?)

     4パターンから5パターンに増えてますね。

    ノーマル

    1かい赤ちょぼクリック。底面固定の四角柱

    2かい赤ちょぼクリック。 左面固定の謎角形

    3かい赤ちょぼクリック。 右面固定の謎角形


    4かい赤ちょぼクリックで、コーナーB。3角柱が追加された。



    底面合わせが出来るので、こんな感じなのが作れる。
    これで多角錐、多角柱が作れるようになった。


    そのままし四角柱にしたもの。これは前からできた。
    これだと四角錘、四角柱しかできなかった。



    2種混合。 4番目は底面を上下反転させてる。
    赤ちょぼを押さないノーマルのコーナーは、
    上面4角、底面3角になるので、A型?とB型を繋げる事が出来る。

    髪型作る幅が広がってそう。
    そして広がる沼w
    まぁロテタ造形よりはマシかな。

    ───────────────────────────────────────
    [変更点一覧]
    ◆スケーラーを100超えて設定できるように
     ブロック数とステータスの相関が壊れた今となっては100%までの縛りが意味を失ったので試しに解放してみました
     でかいやつを少ないブロックで作るには拡大できたほうがいい。。?
     あるべの想定外の不具合があるかも。何かありましたらご報告下さると助かります
     300%までデカく出来るようになった。
     アセンブル中にY128を超えた位置に移動するとアセンブル途中で固まるのかも。




    ◆アクションのスケールバグ(伸縮によって弾速や速度が変わるバグ)をやっぱり修正
     アドオンのほうに調整項目を設けました
     スラスターや弾速変更の方法が変わる訳ですね。
     今まで作ったモデルはほとんど見直しがいるかも。


    ◆スラスターのspeedLimit計算方法を変更。デフォルト値を「1.0」に

     パッケージなどで独自スラスターを追加されていた方はすみませんが再調整をお願いします。。
     わお、全部見直しだっ
     まぁ割と適当に設定してたから、適当に調整しよう。
     それよりmoveSpeedとspeedLimitの関係がいまいちわからんです。
     Limitスピードを3倍にすると三倍以上のスピードですっ飛んでく。
     加速度を3倍にしても速度が上がる。
     この辺調整されたのかな?

    ◆ユニット化条件廃止に伴う変更
     今まで足の長さで算出していたジャンプ力は初期値確定時のコアの高さから算出するよう変更(+アドオンで増強可)
     同じく足の長さで算出していたラージユニットウェイト(腕の振りを鈍くする割合)もコアの高さから算出
     もしマニュアルでラージユニットウェイト値を設定したい場合はコアの特殊設定から
     ステップ高はユニット別に基礎値固定(+アドオンで増強可)
     ジャンプ力や腕の振りをコアで直せるのね。
     成層圏までジャンプ出来たのはダメになったと(笑)
     早くも遅くも出来るのは便利ですね。これでPLの動きに合わせられるかも。
     あとこれで、もう一つ上げるつもりの動画がボツにw
     遅延と足延長を使ったスケート走行ギミックだったのです。
     これで簡単に海上でスケートする艦むすが作れる♪


    ◆パラメータコピーに特殊設定を追加
     それに伴いコピー先のブロック種別が違っていても特殊設定のコピー用にGUIが開けるよう変更
     おー、透明化とかシートの設定とかもコピーできるようになった。
     これでいちいちGUI開いて透明化しなくてもいいや。
     しかもブロックタイプ違っても透明化のコピー出来るね。



    ◆モーション無効の項目に「アクション無効」「両方無効」を追加
     (従来の「する」は「モーション無効」に)
     待ってました!
     これでJBCMで武器を切り替えて、アクションさせないようにできる。


    ◆エアクラフト型の飛行時エネルギー消費を廃止

     ただし崖などから無理やり着陸した場合のペナルティ消費はそのまま


    ◆パス検索コスト軽減のため衝突の判定箱のサイズを従来の2から1に変更

     これにより1x1のくぼみにも入るように
     経路検索時、任意の高さぶんの検索があるのでどうしても横幅の判定を減らさないとつらかったので。。
     ちょっと改悪かなと思わないでもないですが、、、すみません
     何気にツボw
     作業場にある水回りのブロックの上に並べてたのだけど、
     前は渡れたところが渡れずおぼれてました。
     これで家の中にもドアから入れるかもしれませんね。
     Ringでフォローさせれば一緒にダンジョン探索なんかも出来るようになるかも。
     穴にハマるねーさまの図



    ◆ActionBulletの爆発に関するjson項目を追加

     「ignoreDamageCooldown」ヒット後の無敵時間を強制0にしてダメージを与える(デフォルトfalse)
     「cutExplosionNockBack」爆風作用をカットする(ダメージ自体のノックバックはする)(デフォルトfalse)(※ミサイルに適用した)
     「explodeAffectsBlocks」爆発がブロックに影響するかどうか(デフォルトtrue)
     「explodeAffectsEntity」爆発かEntityに影響するかどうか(デフォルトtrue)
     ※旧来の「dummyExplode」はtrueを設定すると上記両方がfalseになる項目に。
     「explosionSize」で爆発サイズを設定できるように(省略すると1.5)
      各デフォルト値は
       バズーカA型3.0
       バズーカB型4.0
       ミサイル1.5
      数値を大きくすると処理の負荷も相応に上がるのでご注意ください
     無敵ありか無しの二つだとバランスはクールタイム次第って事かぁ。
     複数の武器で攻撃する場合は、全部なしにしと、多弾ヒットしないってことですね。
     あとすでに他の攻撃で無敵の時はどうなるんだろ。

     爆風のノックバックは何気に面白かったけど、デフォルトは無になったのね。

     その方がバランスはいいと思う。
     打ち上げられて死んでいく様はちょっと面白かった。

     範囲の上限ないのかな?ないならヤバイモノが作れますねw
     3Dモデルは大抵上限設定されてないから無いはずw

    ◆config設定「disableUnitRequirement」廃止
      タイプ条件の必要ブロック数上限
    ◆config設定「maxUnitHealth」廃止
      ユニットのHPの最大値
    ◆config設定「maxUnitEnergy」廃止
      ユニットのENの最大値
    ◆config設定「fixHealthAndEnergyAtMax」廃止
      不明
    ◆config設定「largeUnitAbilityFixType」廃止
      不明
    ◆config設定「baseUnitHealth」追加
    ◆config設定「baseUnitEnergy」追加
     ※上記二つにユニット型それぞれの倍率がかかり基本の体力・エネルギー値となります
     つまりブロック数はHP/ENに関係なく、タイプとアドオンだけで決まるのか、
     と思ったらそうではなかった。
     最大値が無くなった代わりにベース値が出来ただけでした。








    ◆コマンド「jbspeedworld」廃止
      不明
    ◆コマンド「jbdis」の仕様を変更
     「/jbdis」だけでも実行可能に(範囲64)
     「/jbdis」のみの場合は他ユニットスレーブ状態のユニットを解体できないように
     スレーブも無理やり解体したい場合は「/jbdis 数値 force」で強制解体
      意外と便利。数値入れないだけでも楽ちんだし
    ───────────────────────────────────────
    [バグ修正・改善]
    ◆特殊設定の共通項目をチェックすると固有設定がクリアされていたバグを修正

    ◆ローテーター系MCTL項目の「最小角度」「最大角度」がのきなみ%表記になっていたのを修正
    ◆ノミとペイントガンのアイテムアイコン上の番号文字色を黄色に変更(白だとアイテム数とかぶるので)
     またペイントガンの7番は表記を「B」に統一
     確認 便利になった。


    ◆Edit入力で項目がずれるスライダー由来バグを修正

    ◆RINGのGUIでボタン右クリックでtick音が聞こえなかったのを修正

    ◆パレット画面でctrlを押すとパレット番号ごとにコピー&ペーストが出来るように(アイテム
    データではなくメモリ経由)
     おー、便利
     同じコア内でも、別のコアへもコピペできますね。

     アイテム依存ではないってのは、パラメータ転写メモリと同じですね。
     金型や設計図はアイテムデータなので、複数持てば複数コピーできますが、
     パレットはダメってことですね。





    ◆コアGUIの一部チェックボックスでアセンブルフラグが初期化され「OP独立」などのフラグがクリアされてしまうバグを修正

    ◆エアクラフト型のコア高さが0より大きいとコア位置が正常に計算できていなかったバグを修正

    ◆エアクラフト型の通信不正により回転によってはクライアント側が落ちる致命的なバグを修正

    ◆ディスアセンブル時にユニットの描画が暴れる現象・幽体離脱現象を修正(できてる…はず…)

    ───────────────────────────────────────
    [モデルパッケージ・アドオン追加用json例]

    全て「addon」フォルダ内に置いてください

    「リミットキー定義json」
    コード: 全て選択
    {
    // (必須)リミットキーフォーマット
    "format": "limitKey",
    // (必須)リミットキー名
    "limitKeyName": "S_WEAPONS",
    // バージョン
    "version": 12,
    // コスト制限値
    "costLimit": 5,
    // 制限を越えたモデルアドオンをブロックごと除外するかどうか
    "ignoreModelOnExceed": false,
    // リミットキー表示名(直接書くか、langのキーを指定)
    "limitKeyDisplayName": "jbp.sample_cubes.limitkey.sweapons.name"
    }


    「アドオン定義json」
    コード: 全て選択
    {
    // (必須)アドオンフォーマット
    "format": "addon",
    // (必須)アドオン名
    "addonName": "hWeapon",
    // リミットキー名(なくてもいいです)
    "limitKeyName": "S_WEAPONS",
    // リミットキーコスト
    "limitKeyCost": 2,
    // 以下の補正値は書いたものだけ(具体的には値が0でないものだけ)有効になります
    // 最大体力補正値
    "maxHealth": -0.1,
    // 最大En補正値
    "maxEnergy": -0.1,
    // En回復tick補正値(整数)
    "energyHealInterval": -1,
    // ジャンプ力補正値
    "jumpPower": -1,
    // ステップ高補正値(整数)
    "stepHeight": -1,
    // 前方移動補正値
    "forwardSpeed": -0.5,
    // 左右移動補正値
    "strafingSpeed": -0.5,
    // スラスター補正値
    "thrusterPower": 0.5
    }


    「アドオンアイテム定義json」
    コード: 全て選択
    {
    // (必須)アドオンアイテムフォーマット
    "format": "addonItem",
    // (必須)アドオンアイテムID 0-127
    "addonItemId": 0,
    // アドオン名(アドオン定義jsonにて書いたものを指定)
    "addonName": "hWeapon",
    // アドオンアイテム表示名(直接書くか、langのキーを指定)
    "addonItemName": "jbp.sample_cubes.addonitem.supermana.name",
    // アイコンファイルパス
    "itemIconFile": "model/texture/iconFront.png",
    // 販売コスト
    "merchant": {
    "item": "minecraft:sugar",
    "meta": 0,
    "cost": 30
    }
    }

    20170411追記:モデルにアドオン効果を追加する場合は以下の一文をモデル定義jsonに記述してください
    コード: 全て選択
    "addonName":"アドオン名"

     上のアドオンの記事で書かれてた3Dモデル導入の書き方。
     モデルの追加と、LK追加の2つがセット


    ───────────────────────────────────────
    今回拾いきれなかったご要望はすみません。とりあえずやりたいことだけやった感じのアップデートになってしまいました

    その甲斐あってかRINGで実現したかったことの8割くらいはできたかな、といったところです

    しばらく様子をみてご反応をいただいだうえ仕様が確定したら正式verとして上げようと思います

    また何かご要望・改善案などございましたら適等な感じでご投書ください
    調整などこうしたほうがいいなどのご意見もありましたらお願い致します

    ───────────────────────────────────────
    [0.7.3修正・追加要素一覧]
    ◆コマンド「/jbshowconnection」の追加(クライアント側コマンド)
     「/jbscon 数値」で指定数tickの間、ブロック接続方向を可視化します
     ただしこのコマンドは「アセンブリチューナー」を持っているときのみ接続が見える仕様です
     アセンブル後のユニットも接続方向が見えるようにしましたが、スケーラーなどの繋がりは結局まだわかりにくいかもです
    結局まだわかりにくいかもです。
    私の組むものが悪かったのだろうw

    普通に組んだものなら結構便利だとおもう。











    wwww
    側面装甲とか甲板の補修はめっさ助かります!
    ソリッドな物はちょっと厳しいですね~。

    ◆アトラクターのキー・アイテムMCTLに「複合」バインド追加
     有効化・無効化を別キー(別アイテム)にそれぞれ設定可能

     2キーで変更するのは、切り替わってるかどうかが分かりにくいからかな?
     (切り替えるキーに合わせてスケーラーをバネ式にしておっきくしたりはしてた。)

    ◆コマンド「/jbbuildobj」の引数に「c」を指定できるように
     「/jbbuildobj 出力ファイル名 c」のように「c」をつけるとコアを中心としてobjを出力するようになります
     (※外部パッケージ用のobjを出力する再、セットしたモデルがブロック位置を基準に描画されるよう調整される)

     取りあえず出力はできたけど、モデル化はまだうまくいってないです。
     あと、Jbboは一発でデータが取れないことが多く、何回か繰り返すと成功する感じですね。
     バージョンが上がって成功率は上がったようです。

    ◆コマンド「/jbbuildobj」でobjファイル内のmtlファイル名が日付になっていたのを"同ファイル名.mtl"を記述するよう修正
     地味に手間がへってますか^q^

    ◆mtlファイルのマテリアルでKd以外にも不透明度を記述可能な「d値」を読み込むよう修正
     これによりモデルレイヤ1でmtl付きobjを出力すると不透明度が反映されます(別に書き出されたりはしません、、、手動追加でおねがいします、、、)



    ───────────────────────────────────────
    [おまけ①:「/jbbuildobj」を利用したパッケージモデル用objファイルの作成]
    「/jbbuildobj」を使用するとカービングで作成した形状がobjファイルとして出力できますが、
    それをzipパッケージ用のモデルとして用いることで3dソフトを使用しなくても簡易的に武器のモデルなどが作成できます
     [おおまかな手順]
     ①コアを中心としてカービングを使用した形状を作成します
     ②一旦ユニットをアセンブリし、「アセンブリチューナー」アイテムでユニットのどのブロックでもよいので選択します
     ③チャットウィンドウから「/jbbuildobj 出力ファイル名 c」コマンドを実行します
     ④minecraftの「config」フォルダに「JointBlock」というフォルダ、その下に「objout」というフォルダが作成され、
      さらにその下に出力時の日付でフォルダが作成されます。
      その中にコマンド引数の「出力ファイル名」で指定したファイル名で 拡張子が「obj」と「mtl」の二つのファイルが出力されていると思います
      objはポリゴンの頂点データ、mtlはコアのカラーパレットから読み出した色情報が、質感(マテリアル)データとして書き出されています

     ⑤本来であればテクスチャ画像と一緒に指定するobjファイルですが、ver0.7以降ではmtlファイルとセットでzip内に配置されたobjは

      テクスチャ画像ではなくmtlの色情報を見に行くようにしてあります
      (つまりテクスチャが不要。/jbbuildobjで出した二つのファイルのみでモデルとして認識)
      ただし以下のルールに従ってください

       ・obj内の「mtllib」行に続くmtlファイル名の指定はobjファイル名と揃える(obj名を変えた場合など)

       ・mtlそのもののファイル名もobjファイル名と揃える(obj名を変えた場合など)
       ・objとmtlはzipで同じ階層に置く

     ⑥zipの構成に従ってobjファイルを配置し、モデルjsonを記述することで出力したobjを外部パッケージの取り込みモデルとして

      使用することが可能になります
      (zipの詳しい作り方についてはこのトピック内か、トピック内外でもまとめておられる方がおられるのでご参照ください)

     以上、もし興味があれば試してみてください

     ※「ひとつのobjにつき複数のmtlを容易して色変えモデルを作れないものか?」というご要望は当然でてくるものとは思いますが、
       各頂点情報とmtlの読み込みはセットになっているため、分けたものを読み込むのと結局は同等になります。
       なので色変えverを作成する場合は手間ではありますが別セットのobjとmtlをそれぞれご用意ください)
     V0.7.3で/jbbo xxx cしたobjじゃないとダメな様子。
     "textureFile": "model/texture/xxx.png"の部分は弄らなくていい。
     objファイルとmtlファイルは同じ名前で同じフォルダに入れとく。
     あと当然ながらカービングしてない所はobjにならないので注意。

     コアの中央から生成されるので、モデルを入れた時ブロックのどの位置に出したいか
     考えて位置調整してから/jbboする事。
     例えば銃ならグリップをコア中央にすれば、ロテタに入れた時、グリップを中心に回る。
     腕とか足なら、本体連結部をコア中央にするって事。








    ───────────────────────────────────────