LFがうpできない・・・?
どうもおいなりです。開発中のゲームはGitlabCEで管理してるんですが、その中のLFSを管理する機能がいつからか死んでいたのでメモ書きを。(結論のみは一番下へ)
まず最初の事象がこれ
・LF(LargeFile)をPushしたところ no such hostエラーで突き返される
あれっ。その前に認証は通ってるはずだからアドレス間違ってるはずないんだけど…。
ってことでLFをうpするときの流れを調べる。
・・・がイマイチ分からず独自の判断で対処することに。
エラー内容を詳しく見てみると、LFの投げ先URLが不思議な文字列に。
理想 [httρs://FQDN/USERNAME/PROJECTNAME.git/git-lfs/........続く]
実際 [httρs://XXX-XX-XX-XXX/USERNAME...(以下略)]
ってか区切りが . (ドット)じゃなくて - (ハイフン)でそもそも繋がるはずもないが。
これは2番に原因があるのでは…?
アレコレしているうちにもう一つの問題を見つけてしまう…。
・CloneURLも名前解決された風のURLにすり替わっている
あれっ。(二度目)
「これってCloneURL変え方分かればどうにかなるんじゃね?」という安直な考えの基
ここを参考に再設定し、CloneURLを再確認すると…。
http://FQDN/USERNAME/PROJECTNAME.git/git-lfs/........続く
治ってるじゃん。
簡単なことでした。これでPushしても問題ないネ!
(略あり)LFS: Put https://hoge.huga.com/USERNAME/PROJECTNAME.git/gitlab-lfs/objects/RANDOMSTRING/5: read C:/PROJECTFOLDER/.git/lfs/objects/f2/ca/RANDOMSTRING: file already closed
・・・あれっ。(三度目)
肝心なところが治ってないじゃん。ってかなんだよalready closedって。
な訳でまたネットグルグルしてると…。
どうやらHTTPSからHTTPにループリダイレクトしているのが問題。
/opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml を開いてみると…
htpps: false だったので trueに勝手に変更。(実際はNG)
(じつはここでCloneURLもhttpsになってるんです)
再度Pushしてみると…。
無事うp完了。
ってことでクッソ眠いので雑マトメ。
gitlab_rails['gitlab_host']をしっかり設定しよう。
- BatchAPIはうp先URLをそこから持ってくる。
- 人によってはhttpsからhttpにループリダイレクトされてないか確認。
addressable asset system におけるterrain描画不具合?
お久しぶりです。駅員となって時間がたって、溜まってた不満が大爆発しそうです。
それはさておき、タイトルの通りの不具合?を見つけたので書置きしておきます。
事象
・AASでDLしたterrainが表示されない。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
検証①
・ビルドインのシーンと、サーバーに配置したシーンを用意。
・どちらにもterrainを用意。
・それぞれをロードする。
結果①
どちらも表示される
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
検証②
・ビルドインのシーンと、サーバーに配置したシーンを用意。
・サーバーに配置したシーンのみterrainを用意。
・それぞれをロードする。
結果②
terrainを用意したシーンを読み込んでも、terrainは表示されない。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
原因として考えられるのは、terrainを描画するシェーダーがビルドデータにあるかどうか。
①の場合、ビルドデータにterrainを使用しているので、ビルド時にシェーダーも入れてくれる。
②の場合、AASのデータにしかterrainがないので、シェーダーがビルド時に含まれず描画エラーになる。(ログを見てもShader Unsupported: 'Nature/Terrain/Standard' となっている)
依存関係を気にせずパックしてくれているので安心しきっていましたが、まさかここで罠があるとは・・・。
とりあえず現段階ではダミーでもいいので初期シーンでterrainを入れておけばセーフかと。
けものフレンズ3D テスト版 仮公開場
サーバーは借りてますが、サイトはまだ構築中なのと研修で忙しいので、不具合は山盛りですが一旦置いておきます。数時間で消すのでお早めにDLを。
不正しないでね☆(てきとう
・同意の上DLしてください (2019/04/07 18:55 追記:公開終了しました 追加公開は様子見で)
ほげどっとてきすと
謎題名。
先日とあるTweetでこんなことが…。
これどうやって解読するんだ….? pic.twitter.com/zYpJFbVc34
— コミさん (@komi_edtr_1230) 2019年3月11日
大量に羅列された文字…。
504b03041400090008002855304e1eb374d15c0000005200000008001c00686f67652e7478745554090003bc8b3e5cc58b3e5c75780b000104f601000004140000007cf1b1609ca3b35cf055b23011cd31d0cb4ca9150f1a99ff9950928f95b3f6ed36003e6acafde9c784617033ac49d4d1656804e0428641e185b3b50d7bdb7d71cfee3716f53fff1910729d9e27ba5c3ff554a2d2244dfd339741752f504b07081eb374d15c00000052000000504b01021e031400090008002855304e1eb374d15c00000052000000080018000000000001000000a48100000000686f67652e7478745554050003bc8b3e5c75780b000104f60100000414000000504b050600000000010001004e000000ae0000000000
今回はこのどうでもいい文字に立ち向かいました。
アルファベットがFまでしかないことから、16進数なのは一般人でも何となく察せる。
不意に変換したくなってきたので文字に変換かけてみると…。
PK (U0N�t�\Rhoge.txtUT ��>\ŋ>\ux�|�`���\�U�0�1��L����P������6>j���DŽap3�I��eh�B�Aᅳ�PK (U0N�t�\Rhoge.txtUT ��>\ŋ>\ux�|�`���\�U�0�1��L����P������6>j���DŽap3�I��eh�B�Aᅳ�{�}q��7�?�r��'�\?�T��$M�3�Au/PK�t�\RPK (U0N�t�\R��hoge.txtUT��>\ux�PKN�
とりあえず定番のUTF-8で。
先頭にPKと書いてありますが、ここから何かしらの圧縮ファイルと判断。
途中でhoge.txtと何かを匂わす記述も…。
(ちなみにMZで実行ファイルなど色々あります。変なファイル送られてきたら使えるかも?)
圧縮ファイルなのは理解。試しにテキストエディタでコピペして拡張子変えたところで不発。そこで運よくVSを開いていたので、16進数の文字をバイト配列に変換して書き出してみたくなった。(実際のところ、情弱カスなのでファイル書き出しの処理が不安で調べてる)(こうしてクソコードは生まれる)
んで出来上がったのがこちら(3分クッキング並
このためにGit使うのもアレだけど…。
大体察してたお目当てのブツは出てきたが…。
そんなもん知らないので、PikaZip.exeに頑張ってもらう。
決着。
ZOZO Technologysさんいいものください。
・感想
初めてzipをわちゃわちゃしたなぁと。楽しかったです。(ボ貧&小並感)
AAS(Addressables Asset System)で更新作業
まず初めに‥‥
・AB(Asset Bundle)すら使ったことない奴がAAS使いこなせるのかしら
本題…
・AASを使ってアセットの更新をしたいんだが、挙動が分からない。
現在0.6.6のAASが公開されていますが、あれこれ有力な情報はフォーラム程度なので何か不明な挙動しても解決に時間を要するんですよね…。
今回いくつか実験をしてみて気になったところを書いてみます。
・今回やったこと
更新したデータ(シーンのオブジェクト削除)を正常にDLしてくれるのか検証
・手順
1.ビルドデータに含まれるScene(以降Aと呼ぶ)を作成する。これはSceneをロードするためのものなので、今回の実験には大きな関係はない。
2.AASに登録&サーバーに乗っける為の、Scene(以降Bと呼ぶ)を作成する。
3.Addressables.DownloadDependenciesで事前に全アセットをダウンロードし、AからBをロードするスクリプトを作成。
4.ビルドする。
5.Bのコンテンツ修正前と修正後で1回ずつ起動し、切り替わっていることを確認する。
※ただしローカルサーバを用いる。
・結果
上記の写真通り更新されました。
ここまでは理想通りの結果。だがしかし、追加の実験をして分かった事が。
・追加
この後ローカルサーバを遮断(いわゆるオフライン状態)にし、再度起動してみる。
予想であれば、先ほどの実験で更新データをダウンロード済みなので、変わらず更新後の状態が表示される。
か、変わってねぇ...。元に戻ってる…。
前の段階で更新データをDLしたにも関わらず、オフラインにした途端元に戻ってる…。
・なぜか
AASの仕組みの一部として、クライアント(ユーザーPC)にあるコンテンツカタログを用いて、アセットを管理しています。カタログに書いてあるアセットを持っていない場合、カタログに示されたアドレスでアセットをDLし設定によってはキャッシュにため込みます。
サーバーにあるカタログは常に最新を示しているので、クライアント側はサーバーのカタログと同期させ常に新しいアドレスを持ちます。
クライアント側の更新されたカタログはC:\UsersUSERNAMEi\AppData\LocalLow\CompanyNameE\PROJECTNAME\com.unity.addressablesに格納。がこれはオンライン時の話なんです。
実はオフラインの時、別のカタログを読み込んでるっぽい。
ビルド場所\Hoge_Data\StreamingAssetsにsettings.jsonが居るかと。
その中身、"m_Keys": [ "AddressablesMainContentCatalog" ]
名前の通りメインのカタログですが。その下のアドレスを見ると…。
{UnityEngine.AddressableAssets.Addressables.RuntimePath}/catalog.json
これは今見ているsettings.jsonと同じフォルダにあるcatalog.jsonを示しています。
そう、これはビルド時に参照していたカタログ…。オフラインの時や、初回起動時はココを参照しているらしい。んで、更新なんてされるはずもなく…この結果。
・んじゃ解決方法は?
予測だが更新カタログの保存場所を変えるのかな…?
見つかったら追記します。すっごい眠い(午前3時08分)
Introduction
ツイッターに書いたらフォロワー消えそうなことや、ゲーム開発のちょっとした気付きでも書いておこうかなと。
ニコブロはもういいし、Qiitaは書いていい身分では無いと思うのでお預け。(もうちょっと成長したら書きます…)