何かバグがサクサク見つかる。マオです。

1.5.1版UgoCraftのバグフィックスと機能改善です。
斜めスライドのマーカー設置不具合を直していたら、別のプレートを貼り付けたネザークォーツブロックの表示不具合も見つけてしまい、ついでに修正しています。
後、前に出ていたブロックサイズ問題も根本解決は不可能ですが、クラッシュしないように修正しておきました。

1.2.5版に関しても斜めスライドは修正しなければいけないのですが、別のバグを見つけてしまったので、もう少しかかりそうです。
次のアップではテクスチャを1.5用と同じ配置・ファイル名になった上で、SpriteID軽減用テクスチャ(これは今までに使用していた、軽減テクスチャのファイル名が変わっているだけ)も必要になるので、UgoCraftのテクスチャを変えている人は注意して下さい。

少し仕事の方が忙しくなったり、実験で満足の行く結果が出せなかったので、今月に予定していたUgoCraft2.1は延期したいと思います。
その代わりに、そこで搭載するつもりだったデータ圧縮によるブロック限界数の増加を前倒しで導入しておきました。
変換限界は情報の少ないブロックで6000ブロックくらいに増えてはいますが、ブロックサイズ問題も良く考えて設定した方が良いですね。
限界は増えても、スペックが足りない場合は重くて使い物にならない気がしますが・・・。

ともかく、やる事はサクサクやっていくとしよう。

一応、こんな可能性があるらしい。マオです。

新UgoCraft使用者で、Ugo objectがガクガクするという方へ。
Javaのバージョンを確認してみて下さい。
古いバージョンだと、ガクガクして動かないという報告がありました。
現在Javaは7でUpdate 17が最新です。
ただ最新版が入っていても、旧版が削除されていなくて、そちらを参照されてMinecraftが起動している場合があります。
Minecraftで、どのバージョンが使われているかを手っ取り早く知る方法は、Minecraftを起動して「設定→情報収集設定」のjava_versionで確認する事が出来ます。
1.7.0_17とあるなら、Java7 Update17で起動している事になります。
もしそれ以外だった場合は、Windowsなら「コントロールパネル→プログラムと機能」で、Java7 Update17以外のJavaが残ってると思われるので、それらを削除します。
他の事でJavaを使っているなら、確認して削除してね。
で、もしMinecraftが起動しないなら、もう一度Javaの最新版をインストールすれば、問題無いはずです。

今度から動作確認しているJavaのバージョンも書いた方が良いのかしら・・・。
Javaはバージョンが上がると、大体速度が良い感じにアップする。
6から7に上げた時の、ループ処理の改善には感動した記憶があるんだよね。
何かしら問題を抱えてる人がいるなら、それもJavaのバージョンも考慮すれば解決するかもしれないね。

二つ目だ。マオです。

まさかのエイプリルフールネタ、第二段。
今回はニコ動のお祭りなので、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を視界に入れないと軽くなる場合があります。
動いている所を全て目視で確認したいのは分かりますが、空を見たり地面を見たりするのも良いものですよ？

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