今まで簡単にはできなかったことが CCK2.5.0ベータ機能を使うと
数行のscriptで 実現できるようになりました。ほんとなの？
やってみました。室内人数のカウントができました
その過程で・・・勉強したことを書いてみます
この記事が役立つ人
webデザインのjavaをやっていない人 数学は得意でも英語が苦手な人向けでしょうか
解説というより学習中の体験記です
解消できていない投げっぱなしの疑問もあります悪しからず
目次１==スペルミスを減らす。キャメル方式のルール==
今まで簡単にはできなかったことが 数行のscriptで 実現できるようになりました。
その一方で、cluster scriptが難しくなったのでしょうか、
もっと楽しかったはずなのに、自分の脳が衰えたのでしょうか・・・トホホ
今までは
秀丸エディターで事足りていましたが、脳の衰えを補完すべく
『
VScodeの使い方がわからん!機能が多すぎる』 ・・・心の叫びです
検索しても畑違いのHtmlとかwebの例だったりするのでスキップしちゃいます
当方はそういう機会も興味もないのでさっぱりです
『
VScodeの文字の色分けがわからん!!』 ・・・心の叫びです
文字の色がカラフルで多機能そうですが
この色は 必ずこうだという 確証もなく 一覧表も見当たらず
結局、無視していることが多いですね、気休めに過ぎないのでしょうか
『そもそも大文字小文字の区別が必要だった』がっくし orz ○|￣|_
日常生活ではグダグダですから・・・・
grep検索でも大文字小文字区別なしで使っていました
ところが未だに プログラム関係では 『大文字小文字の区別』がシビアでした
そんなことは承知していたはずでした。
自分としては、 ユーザー定義の変数名やメッセージやsignal名は
小文字に統一して
命名していたので罠にはかからないはずでしたが
・・・・甘かったようです
例えば・・・・・
『過去形じゃないよ IDだよ！』
ItemTemplateId（正） これが肉眼では 過去形に見えています
ItemTemplated（誤） ・・・という具合にミスタイプしそうです
scriptが テキストで提供されていなかったので
大丈夫だろうと点検してみると・・・・
てっきり間違っているではありませんか
ItemTemplateId（正）
ItemTemplateld（誤） アイディーIDが エルディーlDになっています
フォントによっては 微妙に区別できたり似通ってたりするので
スライドの文字では[ l I 1 ]＝[アイ エル いち] の判別がしにくいですから
括弧 {( が違う行にぶっ飛んだりしていますので手直しが必要です
これでも点検できると思います）
次の例は 何と言ってもベータ機能でよく見かける単語
[ playerHandle ]の
タイプミスでした
『 playerHandle と PlayerHandle とどっちが正しいの？』
playerHandle（正） ・・・後述
PlayerHandle（誤） script内では使うことはないようです
documentを見ると PlayerHandle という文字も見かけます
playerHandle と PlayerHandle とどっちを使えばよいのかわからなくなりました
コピペだけでは突破できません。何かルールがあるようです
英単語の真ん中あたりに大文字があるなんて、おかしな英文だと思ったら
キャメル方式だそうです
数学は得意ですが 英語は苦手です。
camel caseってなんだろ？
programでは半角スペースが使えないから 半角を詰めて
単語の区切りに大文字を使っているようです
それがキャメル方式だそうです
クラス名は大文字で始まるというルールがあるようです
アッパーキャメル方式（upper camel case ）
UCC と言うらしい
缶コーヒーみたいな用語ですね。アルファベット３文字ってだめなのよね
フルスペルが思い出せないのよね
ローワーキャメルケース（lower camel case）
LCC の覚え方はないのでしょうか
小文字先頭
ラクダ->小文字
ラクダ->子持ち
ラクダ・・・・ばんざ～い
・・・絵にしてみました、単なる覚え方です 根拠はありません
変数名は 小文字先頭のキャメル方式です
メソッド名は 小文字先頭のキャメル方式です
プロパティ名は 小文字先頭のキャメル方式です
大文字先頭のキャメル方式の出番はありません
おお～～ これでスペルミスの頻度を下げれそうです
例 o.object.playerHandle プロパティ名は小文字先頭のキャメル方式
例 PlayerHandle documentだけで見かける 先頭大文字のキャメルケース
気がついたのですがreferenceになにやら
P とか M のマークがあるのは Property method のことかもしれない
なにか重要な区別らしい・・・『クラスって何だ？』
『property と methodの違いって何だ？』
・・・それはもっとまともな記事を読んでいただくとして・・・
referenceの使いかたがちょっとわかってきたかもしれません
目次２==== データ構造を知る JSON.stringify====
徹底解説「ベータ機能完全に理解した！」に挑戦してみることにします
フェイドラさんの モーションブース スライド70の 次の4～5行が
キモらしいですが さっぱりわかりせん
アロー関数が1行に2つもあるし ドットが深いし、
どれがClusterベータ新機能か
・・・ということで 勉強に半年ぐらいかかると思っています
let previousOverlapPlayers = $.state.overlapPlayers;
let currentOverlapPlayers = $.getOverlaps().map(o => o.object.playerHandle).filter(p => p!= null);
let newOverlapPlayers = currentOverlapPlayers.filter(c => !previousOverlapPlayers.some(p => p.id==c.id ));
let exitPlayers = previousOverlapPlayers.filter(p =>!currentOverlapPlayers.some(c => c.id == p.id));
$.state.overlapPlayers = currentOverlapPlayers;
とはいえ、わかってないのに知ったかぶりで改造を試してみました
当然、エラーがでます
ヒントになるエラーがほしいところですが[ Undefined ]のエラーが多いです
スペルミスでもドット表記ミスでもこれが返ってくる
Undefined は未定義という意味だそうですがヒントになりませんね
ちなみに Under fined というと 罰金未満だそうです
TypeError: Cannot read property 'filter' of undefined
TypeError: Cannot read property 'playerHandle' of undefined
Cannot read property '0' of undefined
『エラーメッセージが見当違い！』
『エラーメッセージが不親切！』・・・と叫びたいですが、
それは以前からそうでした programのデバグはそういうものでしたね
どこから 解き明かしていけばよいでしょうか
map , filter とか 知らないコマンドも多いですし どうも配列関係らしい
当方は 配列って あんまし いじった記憶がないので 探索は迷走します
どうも getOverlapsが 大物らしい
（正確な用語が検証できていません 悪しからず）
ジェイソンファイルって聞いたことがあります
ホラー映画『
13日の金曜日』のジェイソン（Jason ）が想い浮かびます
データ構造がわからないとデバグが迷走するばかりのようです
$.log だけでは足りないので
JSON.stringify を 使って可視化することにします
その件は以下の記事にも書きましたが その続きです
-----------以下はgetOverlapsの配列の中身の１例です
"selfNode":{"state":{}
,"useGravity":false
,"velocity":{"x":0,"y":0,"z":0}
,"angularVelocity":{"x":0,"y":0,"z":0}
}
,"object":{"itemHandle":null
,"playerHandle":{"id":"cf0015a4-xxxx-xxxx-891c-1a60c0adaa27"}
}
------------さらに わかりやすく
getOverlapsの中身を見やすい表に書き直しました 図参照
最下段横が 数値データ です
縦にたどると ドット記法 になります
例 selfNode.velocity.y
例 object.playerHandle.id
「お～～なるほど！こういうことか」
データ構造がわかれば、ドット記法が正確に書けるので
コピペや当てずっぽうでミスしなくなり undefinedエラーが減りました
これで 配列も怖くない・・・
（単純な配列でないこれをなんというのだろう？）
（
連想配列 オブジェクト配列
JSON配列・・だろうか？）
これは、 誰かの参考になるでしょうか
自分としては レファレンスの getOverlaps の 戻り値の例として
図解を補足すればいいんじゃないかと思うぐらいの大発見でした。
目次３==== 室内人数カウント別解 ====
再び室内人数カウントの話しです
getOverlapsが どうも大物で 配列データも複雑で階層が深いようなので
getItemNearの方が 配列の深みに足を取られず 扱いやすいように思います
(～Nearは２通りあります getItemsNear と getPlayersNear です ）
（両者ともベータから本採用になるそうです）
というわけで 室内人数カウント を Nearで作りなおしてみました
getOverlapsとgetItemNearはScriptの扱いが案外と似ています
何が違うか どう使い分けるのか
getItemsNearの方が 原始的で単純です
getItemsNearの
接触結界の形は球体の一種類だけです
（Collider , shape , 数値半径 ひっくるめて
接触結界と呼んでみました）
getItemsNearに Colliderは不要です 数学的な半径を指定するだけです
script内でいくつにでも増やせられるメリットがあるように思います
それに対して
getOverlapsの方が item,player両方に感知できるとか汎用性が高いです
何と言っても shape という新機能が使えます
『shapeって何だ colliderとどう違うのか！』・・という心の叫びです
『何を新しく開発したのか』
getOverlapsの方はdetector shapeを複数配置できるので
複雑な輪郭の部屋や迷路にも対応可能でしょう
注 mesh collider は convexオンに限るので中途半端でした
注 sampleワールドでは 半透明に可視化しましたが
実際の運用ではそんな可視化optionはありません。悪しからず
「getOverlapsのScriptを getItemNear に書き換える場合は 主に2箇所ですみます」
１
変更前 let overlaps = $.getOverlaps(); //detector shapeが必要
変更後 let overlaps = $.getItemsNear($.getPosition() , maxDistance); //それが不要
２
変更前 let itemHandle = overlap.object.itemHandle;// 配列が深い
変更後 let itemHandle = overlap; // getItemsNearでは配列が単純
これで何かすごい展開があるのでしょうか
コマンドを比較検証して確かめた時のメモなので
実用性があるかどうかはわかりません
・・・トホホ
・・・・以上 体験記でした 完全理解にはまだまだ道が遠いです
勘違い、誤字脱字ありましたらごめんなさい
ベータ関係以外にも参考資料を提示されているかたに感謝
参考tool かおもさんの CSEmulator V2 2.0以後
Cluster Script関係メモ（基本β）
参考文献
ほ
びわんさんの
ClusterScript Beta playerHandle重複排除
参考文献 フェイドラさんの ベータ機能完全に理解した！
参考文献 滝 竜三さんの 【ベータ機能】
近くのプレイヤーについてくるペットをつくる（プレイヤー情報取得）
#cluster #ClusterScript
