二つ目だ。マオです。

まさかのエイプリルフールネタ、第二段。
今回はニコ動のお祭りなので、YouTubeにはアップしない予定だ。
ってか、そんな事したら日本語読めない人がビックリしちゃうからね。
昨日の23時30分から作成して、何とか今日中に上げる事が出来た。
見た目だけやるなら、サクサク作れるな・・・デバッグとかしなくて良いってステキだ。
もちろん、UgoCraftには搭載されません。

以下、中身の解説なので、動画を見てからのがイイゾー。

最初の岩盤さん。
いつも、寂しそうに待ってるだけなので、追いかけさせてみた。
でも、よく見ると土台が全部岩盤だったりするという悲しみ。

物理エンジンがパワーアップした大砲さん。
ひねりが加わりました。
時間が無い為に、X方向に飛ぶ物しか綺麗にひねりが入りません。
当り判定とか考えると、絶対実装しないと心に決めた。

新しいコアブロック。
正直、何に使うのか分からない。
これも当り判定とか考えると(略)

最後の巨大カボチャ。
あれ、視線の位置によっては表示されなくて、それのせいで何度も撮り直しするはめに・・・。

さて、本当の2.1を作らないとな・・・何かエネルギーを使い果たした感がある(笑)

データ破壊の可能性。マオです。

設定項目「Block_size」について、問題になりそうな物を発見したので、記事にしておく。
この項目は変換可能なブロック数を設定できるのだが、一応3200辺りが限界と説明に書いてある。
しかし、これはブロックからUgo objectになった時の目安で、稼働中のUgo objectを表示させた時は、データ圧縮率の関係で変換限界数がもっと少なくなる。
この稼働中の表示というのは、セーブデータを読み込んだ時にUgo objectが表示できる範囲にプレイヤーがスポーンした時や、プレイヤーが移動中にUgo objectが読み込まれる範囲(大体130ブロックくらい)に入ると発生する。
その時に公式のデータ転送量限界を超えてしまうと、クラッシュしてしまう。
しかも再度入り直しても、限界を超えたデータを読み込むのでクラッシュしてしまい、ゲームが出来なくなってしまうのだ。
困った事に完璧な解決手段というのを思い付かない。
変換するブロックによって、データ量が変わってしまうので、一概に「このブロック数なら大丈夫」と言えない。
Block_sizeを私が指定している3200個ギリギリで設定して運用している人は注意して下さい。
この問題は旧UgoCraftでも起こりうる問題で、1.4以降のバージョンで発生します。
ModLoaderMPを使用していたバージョンでは、起こらない問題です。
いつか出来るであろう、バージョン2.1では安全策くらいは実装したいな。

そういえば、これを見つけたのはUgoCraft2.1の実験中で、2.1ではBlock_sizeの限界がもう少しだけ引き上げられそうです。
上の注意で言う所の、ブロックからUgo objectに変換される時の限界サイズが、3200から6000くらいに上がりました。
稼働中表示限界を考えると、5000くらいなら安心なのかしら？
ここら辺は追試しないとなぁ・・・まだ安全策を作ってないから実験が出来ないね。
1.2.5の人には関係の無さそうな変更点なんで、もう一つくらい何か作りたい所だな。

たまにはこんな話もしてみる。マオです。

数日前より、いくつかUgoCraftの動画が投稿されて、それに釣られて「私もウゴクラ入れてみる！」なんて方が多いようで、アクセス数が跳ね上がっています。
実際に入れて遊んでくれていれば幸いね。

さて、UgoCraftは大きなブロックを動かしたり、大量のUgo objectを動かすと重いです。
しかし、同じブロック数やUgo object数でも、場合によっては軽くなったりする可能性があったりします。

「構造物の見えない部分はブロックを置かないようにしておけば軽くなるんじゃね？」
軽くなる場合もありますが、重くなる場合もあります。
まず、基本知識としてコアブロックを起動した時、「A:変換対象の検索→B:ブロックをUgo objectに変換→C:Ugo objectの動作→D:Ugo objectをブロックに変換」というプロセスが存在します。
以下、それぞれのプロセスをABCDの形で表記します。
見えない部分のブロックを中抜きした場合、ABDは軽くなりますが、Cは単純に軽くなるとは言えません。
ABDのプロセスは変換対象のブロック全てを処理していますが、Cのプロセスに関しては表面上で見えているブロックしか処理していません。

画像の中身がしっかり詰まった鉄豆腐は、右の方がブロック数的には多いですが、処理ブロック数は一緒です。
厳密には処理内容は変わってきたりしますが・・・。
しかし、この法則は1×1×1の通常ブロックに限られます。
例えばくり貫いた中に松明を敷き詰めてみたというパターンは最悪です。
この場合は、全てのプロセスにおいて負荷がかかります。
実例として、20×20×1の鉄ブロックの上に松明を敷き詰めた場合と、20×20×2の鉄ブロックをスライドさせて比べましたが、前者は変換時のラグが酷い事になりました。
松明には検索時の接続ルールチェックも存在したり、描画処理も通常のブロックと比べたら複雑なので、確実に重くなりますね。

「大量にUgo objectを作ると重いよー＞＜」
それ、全部を見渡せる位置で目視していませんか？
確かに大量に動かすと重くはなりますが、そのUgo objectを視界に入れないと軽くなる場合があります。
動いている所を全て目視で確認したいのは分かりますが、空を見たり地面を見たりするのも良いものですよ？

まあ、ぶっちゃけ一番楽なのは、パソコンのスペックを上げ(略)

うっかりうっかり。マオです。

1.5.1版UgoCraftのバグ修正版公開です。
Ugo object化する予定のブロックに立てかけられた、Ugo object化しない作動レールが設置されている状態でコアブロックを起動すると、作動レールがアイテム化してしまう不具合の修正です。
こんな事は誰もしないだろうから気付かないと思うけど、ソースコードを眺めていたら気付いてしまったよ。
不安がある人はバージョンアップすると良いかもしれない。

そういえば新バージョンからは、Minecraftのマイナーバージョン(1.5.1だと、5の部分)の最新に対応している、最新のModのみをダウンロード出来るようにして、過去のバグが入っているバージョンは公開しないようにした。
一応、Minecraftバージョンアップ対応時には両方出しておくが、UgoCraftのバージョンアップ時には消す事にしている。
バージョンに拘りがある人は、早めに入手して保存しておく事をお勧めする。

後、私が過去に作ったサンプルデータが欲しい人は、しばらく待って欲しい。
忙しくなってしまって、データ移行作業に手間取っているのだ。
遠隔プレートとかが無かった時代のデータは、そこら辺を活用した楽な作り方に変えようと思っている。

何か移行の後処理がまだまだ残ってると実感したわ・・・。

これでバージョンアップラッシュが終わって欲しい。マオです。

UgoCraftの1.5.1対応版公開です。
ついでに変換処理の一部を軽量化・・・出来ているといいなぁ。
もう少し突っ込んだ軽減処理を考えているんだけど、実験が面倒過ぎてやる気が起きないんだよね。
そろそろ、バージョン2.1って感じに変わるレベルでの機能追加変更したいけど、暖かくなってきて忙しくなるから作業時間がどんどん減っていく。
まあ、適当にやっていくかねぇ。