今回は掘削機を作ってみます。
掘削機は真下にあるブロックを採掘してくれる装置です。
まずは部品の採掘用パイプ(Mining Pipe)を作ります。
レシピは鋼鉄*6、ツリータップ。
掘る深さのぶんだけ数が必要となります。
次は掘削機。
レシピは機械部品、電子部品*2、採掘用パイプ*2。
あっさり完成しましたが、ついでにポンプ装置(Pump)も作っておきます。
ポンプ装置を隣接させておくと、掘削機が水と溶岩も拾ってくれるようになります。
レシピは機械部品、電子部品、採掘用パイプ*2、ツリータップ、空のセル*4。
なお空のセルはスズ*4です。
何故かセルそのもののレシピがどこにも見当たらなくて難儀しました。
両方ができあがったらくっつけて置き、掘削機に電線を繋ぎます。
掘削機には男のロマン、ドリルを投入し、ポンプ装置には空のセルを配置するといよいよ作動開始です。
掘削機から真下に向かって穴を掘り、鉱石や石などのブロックを片端から採取してくれます。
このように下にパイプが伸びていきます。
って自宅の真下にこんな穴があったのか。
なお、掘ったアイテムはそこらへんにぽろぽろこぼしてしまいますが、チェストを隣接させておくとそこに入れてくれます。
真下しか掘ってくれないので、地表で使った場合はこれだけ準備しておきながら60個程度しか採掘できません。
さらに別の場所を掘りたいときには掘削機をいちいち移動しないといけなかったりと、あまり効率的な機械ではありません。
まあ正直ネタ要因です。
そこらへんはBuildCraftに任せてしまうということなのでしょう。
マインクラフトのまとめ
掘削機は真下にあるブロックを採掘してくれる装置です。
まずは部品の採掘用パイプ(Mining Pipe)を作ります。
レシピは鋼鉄*6、ツリータップ。
掘る深さのぶんだけ数が必要となります。
次は掘削機。
レシピは機械部品、電子部品*2、採掘用パイプ*2。
あっさり完成しましたが、ついでにポンプ装置(Pump)も作っておきます。
ポンプ装置を隣接させておくと、掘削機が水と溶岩も拾ってくれるようになります。
レシピは機械部品、電子部品、採掘用パイプ*2、ツリータップ、空のセル*4。
なお空のセルはスズ*4です。
何故かセルそのもののレシピがどこにも見当たらなくて難儀しました。
両方ができあがったらくっつけて置き、掘削機に電線を繋ぎます。
掘削機には男のロマン、ドリルを投入し、ポンプ装置には空のセルを配置するといよいよ作動開始です。
掘削機から真下に向かって穴を掘り、鉱石や石などのブロックを片端から採取してくれます。
このように下にパイプが伸びていきます。
って自宅の真下にこんな穴があったのか。
なお、掘ったアイテムはそこらへんにぽろぽろこぼしてしまいますが、チェストを隣接させておくとそこに入れてくれます。
真下しか掘ってくれないので、地表で使った場合はこれだけ準備しておきながら60個程度しか採掘できません。
さらに別の場所を掘りたいときには掘削機をいちいち移動しないといけなかったりと、あまり効率的な機械ではありません。
まあ正直ネタ要因です。
そこらへんはBuildCraftに任せてしまうということなのでしょう。
マインクラフトのまとめ
PR
前回Zend_ControllerでSmartyを使えるようにしましたが、フロントにごりごりコードを詰め込んでいて見た目がいまいちです。
もっとコントローラで処理する方法はないでしょうか。
Zend_Controller_ActionにはURLから呼び出されるアクション以外にも、必ず呼ばれるメソッドが幾つか用意されています。
Zend_Controller_Action::init()、preDispatch()、postDispatch()のみっつで、init()はコンストラクタで、preDispatch()はアクションの実行前、postDispatch()は実行後に呼ばれます。
そこで毎回使用するデータベース接続などはinit()に書くと便利、ということになります。
ところが普通にIndexController::init()に実装すると、別のコントローラHogeControllerを呼び出した場合は実行されない、という事態になってしまいます。
各コントローラのinit()はあくまでコントローラ単位の共通要素となります。
では全コントローラで共通して行える処理はないのかというと、デフォルトではありません。
Zend_Controller_Actionと各コントローラの間にひとつ基底クラスを噛ますことになります。
html/index.php
今後コントローラが増えても、同様にBaseControllerを継承すればZend_View_Smartyが使用できるようになります。
他にもDB接続や定義ファイルの読み込みなど、共通して使うものはここに書くとよいでしょう。
つうかこのくらい最初から用意してほしい気がするんだが。
ちなみにこれもコントローラなんでhttp://zend.localhost/base/index/とか入れられると直接呼ばれてしまいます。
もしかしたらcontrollersフォルダ外に出すとかした方がいいかもしれません。
もっとコントローラで処理する方法はないでしょうか。
Zend_Controller_ActionにはURLから呼び出されるアクション以外にも、必ず呼ばれるメソッドが幾つか用意されています。
Zend_Controller_Action::init()、preDispatch()、postDispatch()のみっつで、init()はコンストラクタで、preDispatch()はアクションの実行前、postDispatch()は実行後に呼ばれます。
そこで毎回使用するデータベース接続などはinit()に書くと便利、ということになります。
ところが普通にIndexController::init()に実装すると、別のコントローラHogeControllerを呼び出した場合は実行されない、という事態になってしまいます。
各コントローラのinit()はあくまでコントローラ単位の共通要素となります。
では全コントローラで共通して行える処理はないのかというと、デフォルトではありません。
Zend_Controller_Actionと各コントローラの間にひとつ基底クラスを噛ますことになります。
html/index.php
<?php
define('APP_DIR', dirname(__FILE__).'/../application/');
require_once('Zend/Controller/Front.php');
Zend_Controller_Front::run(APP_DIR.'controllers');
application/controllers/BaseController.php
<?php
//require
require_once('Zend/Controller/Front.php');
require_once('Zend/View/Smarty.php');
require_once(APP_DIR.'smarty/libs/Smarty.class.php');
class BaseController extends Zend_Controller_Action{
public function init(){
define('SMARTY_DIR', APP_DIR.'smarty/libs/');
define('SMARTY_TEMPLATE_DIR', APP_DIR.'templates/');
define('SMARTY_COMPLIE_DIR', APP_DIR.'smarty/templates_c/');
define('SMARTY_CACHE_DIR', APP_DIR.'smarty/cache/');
define('SMARTY_CONFIG_DIR', APP_DIR.'smarty/config/');
$this->view = new Zend_View_Smarty(SMARTY_TEMPLATE_DIR, array(
'compile_dir'=>SMARTY_COMPLIE_DIR
, 'cache_dir'=>SMARTY_CACHE_DIR
, 'config_dir'=>SMARTY_CONFIG_DIR
));
$viewRenderer = $this->_helper->getHelper('viewRenderer');
$viewRenderer->setView($this->view)
->setViewBasePathSpec(SMARTY_TEMPLATE_DIR)
->setViewScriptPathSpec(':controller/:action.:suffix')
->setViewScriptPathNoControllerSpec(':action.:suffix')
->setViewSuffix('html');
}
}
application/controllers/IndexController.php
<?php
require_once(APP_DIR.'controllers/BaseController.php');
class IndexController extends BaseController{
public function indexAction(){}
public function hogeAction(){}
}
IndexControllerでは、Zend_Controller_ActionではなくBaseControllerをextendsするように変更しました。今後コントローラが増えても、同様にBaseControllerを継承すればZend_View_Smartyが使用できるようになります。
他にもDB接続や定義ファイルの読み込みなど、共通して使うものはここに書くとよいでしょう。
つうかこのくらい最初から用意してほしい気がするんだが。
ちなみにこれもコントローラなんでhttp://zend.localhost/base/index/とか入れられると直接呼ばれてしまいます。
もしかしたらcontrollersフォルダ外に出すとかした方がいいかもしれません。
献血推進功労者表彰式に行ってきました。
私のようなパンピーを呼びつけるくらいだから適当な立食形式とかそんなんかと思っていたら、知事とか赤十字のお偉いさんとかが山ほど来てる大真面目な式典でした。
でもやったことといえばどっかの企業とかが表彰されるのを延々聞いてひたすら拍手するだけの簡単なお仕事。
正直退屈。
最後にab bankというバンドの生演奏がありました。
メンバーの二人が輸血を受けた経験があるらしく、そこらへんから繋がってきたみたい。
最初見たときは何処の作業員だよとか思いましたが、まあそこそこしっかりした演奏でした。
おみやげとしてバッグやらコップやらもらいましたが、行く価値があるかどうかはちょっと微妙。
ちなみに銀色有功章のところに載ってるので暇なら探してみてね。
それは突然、運命の相手が1 ヒロモト ヒロキ
☆☆☆☆☆
コンピュータが自動的に相性が最高のパートナーを選び出す時代。
といってもディストピアなわけではなく、拒否権はあるし大多数はむしろ選択を心待ちにしている、そんな明るい明日。
主人公にも心待ちにしていたパートナー通知が、そして喜び勇んで行ってみると……
まあ設定以外はよくあるベタな話なんですが、なんつーても1話が素晴らしすぎる。
それは突然、運命の相手が2ヒロモト ヒロキ
☆☆☆☆
うーむ少々普通のギャルゲに成り下がってしまった感が、というか一巻一話がよすぎたので見比べてしまうとどうしてもな。
まあ単品としてはそれなりに良いです。
スレイヤーズすまっしゅ。4 蘇る王 神坂 一
スレイヤーズすまっしゅ。5 恋せよオトメ
☆☆☆☆
いやあ、まだやってたんだな、これ。
スレイヤーズすぺしゃるのころと何も変わらない短編集です。
本作は私をこっちの道に曲がらせてしまった最大の原因なんですよねえ。
昔クラスにとっても可愛い子がいまして、全然ヲタには見えない普通の人だったんですが、何故か突然卒業文集でスレイヤーズの紹介を始めたんですよ。
どういうことだ。
せっかくなので一作試しに買ってみたんですが、その後見事に坂道を転げ落ちました。
人をこんな風にしておいて彼女は今何をやってるんだか。
ケイブ シューティング アートワークス
☆☆☆
イラスト集なので読み物的なところはほとんどなくて評価しづらいですな。
まあ何か気に入った作品があれば買ってみてもいいかも。
個人的にはこれ系統は余り興味がないので比較的どうでもいいかんじです。
では何故買った。
私のようなパンピーを呼びつけるくらいだから適当な立食形式とかそんなんかと思っていたら、知事とか赤十字のお偉いさんとかが山ほど来てる大真面目な式典でした。
でもやったことといえばどっかの企業とかが表彰されるのを延々聞いてひたすら拍手するだけの簡単なお仕事。
正直退屈。
最後にab bankというバンドの生演奏がありました。
メンバーの二人が輸血を受けた経験があるらしく、そこらへんから繋がってきたみたい。
最初見たときは何処の作業員だよとか思いましたが、まあそこそこしっかりした演奏でした。
おみやげとしてバッグやらコップやらもらいましたが、行く価値があるかどうかはちょっと微妙。
ちなみに銀色有功章のところに載ってるので暇なら探してみてね。
それは突然、運命の相手が1 ヒロモト ヒロキ
☆☆☆☆☆
コンピュータが自動的に相性が最高のパートナーを選び出す時代。
といってもディストピアなわけではなく、拒否権はあるし大多数はむしろ選択を心待ちにしている、そんな明るい明日。
主人公にも心待ちにしていたパートナー通知が、そして喜び勇んで行ってみると……
まあ設定以外はよくあるベタな話なんですが、なんつーても1話が素晴らしすぎる。
それは突然、運命の相手が2ヒロモト ヒロキ
☆☆☆☆
うーむ少々普通のギャルゲに成り下がってしまった感が、というか一巻一話がよすぎたので見比べてしまうとどうしてもな。
まあ単品としてはそれなりに良いです。
スレイヤーズすまっしゅ。4 蘇る王 神坂 一
スレイヤーズすまっしゅ。5 恋せよオトメ
☆☆☆☆
いやあ、まだやってたんだな、これ。
スレイヤーズすぺしゃるのころと何も変わらない短編集です。
本作は私をこっちの道に曲がらせてしまった最大の原因なんですよねえ。
昔クラスにとっても可愛い子がいまして、全然ヲタには見えない普通の人だったんですが、何故か突然卒業文集でスレイヤーズの紹介を始めたんですよ。
どういうことだ。
せっかくなので一作試しに買ってみたんですが、その後見事に坂道を転げ落ちました。
人をこんな風にしておいて彼女は今何をやってるんだか。
ケイブ シューティング アートワークス
☆☆☆
イラスト集なので読み物的なところはほとんどなくて評価しづらいですな。
まあ何か気に入った作品があれば買ってみてもいいかも。
個人的にはこれ系統は余り興味がないので比較的どうでもいいかんじです。
では何故買った。
男のロマンを作ります。
レシピは鋼鉄*5、充電池、電子部品。
2011-11-03_13.33.11
採掘用ドリル(Mining Drill)ができました。
これはなにかといいますと、充電式で無限使用可能なピッケル+シャベルです。
正直これでとどめておく必要性はあまりないので、一気にダイヤモンドドリル(Diamond Drill)までレベルアップさせましょう。
黒曜石も掘れる強化版ドリルです。
レシピは採掘用ドリル+ダイヤモンド*3。
黒曜石を掘るためにダイヤモンドつるはしを作ることを考えれば安いものです。
採掘用ドリルより電力を使うかわりに超速くブロックを削ることができます。
むしろ速すぎて余計なところまで削ってしまうレベル。
慣れると物凄く快適すぎて普通のつるはしには戻れません。
お次はチェーンソー(Chainsaw)
名前のとおり斧の上位種で、木を最速で伐採できます。
まあ木こりMODが入っていればいらないといえばいらないんですが。
レシピは鋼鉄*5、電子部品、充電池。
さて、ドリルもチェーンソーも充電しながら使う必要があって少々面倒です。
特にドリルはかなり減りが早いため、まともに運用するには電池を大量に持ち歩かなくてはなりません。
充電を肩代わりするバットパック(BatPack)を作りましょう。
レシピは充電式電池*6、電子部品、スズ。
これを体に装備していると、ドリルやチェーンソーを使うときに自動的にそちらから電力を使ってくれるという優れものです。
つるはしを大量に持ち歩く必要がなくなり、延々地下作業を続けられるようになります。
なお、バットパックも装備扱いなので、電力が無くなった状態で下手にダメージを受けると壊れてしまいます。
注意しましょう。
マインクラフトのまとめ
レシピは鋼鉄*5、充電池、電子部品。
2011-11-03_13.33.11
採掘用ドリル(Mining Drill)ができました。
これはなにかといいますと、充電式で無限使用可能なピッケル+シャベルです。
正直これでとどめておく必要性はあまりないので、一気にダイヤモンドドリル(Diamond Drill)までレベルアップさせましょう。
黒曜石も掘れる強化版ドリルです。
レシピは採掘用ドリル+ダイヤモンド*3。
黒曜石を掘るためにダイヤモンドつるはしを作ることを考えれば安いものです。
採掘用ドリルより電力を使うかわりに超速くブロックを削ることができます。
むしろ速すぎて余計なところまで削ってしまうレベル。
慣れると物凄く快適すぎて普通のつるはしには戻れません。
お次はチェーンソー(Chainsaw)
名前のとおり斧の上位種で、木を最速で伐採できます。
まあ木こりMODが入っていればいらないといえばいらないんですが。
レシピは鋼鉄*5、電子部品、充電池。
さて、ドリルもチェーンソーも充電しながら使う必要があって少々面倒です。
特にドリルはかなり減りが早いため、まともに運用するには電池を大量に持ち歩かなくてはなりません。
充電を肩代わりするバットパック(BatPack)を作りましょう。
レシピは充電式電池*6、電子部品、スズ。
これを体に装備していると、ドリルやチェーンソーを使うときに自動的にそちらから電力を使ってくれるという優れものです。
つるはしを大量に持ち歩く必要がなくなり、延々地下作業を続けられるようになります。
なお、バットパックも装備扱いなので、電力が無くなった状態で下手にダメージを受けると壊れてしまいます。
注意しましょう。
マインクラフトのまとめ
Zend_Controller標準のビューはZend_Viewですが、機能は貧弱です。
というかサンプルのテンプレートを見ればわかりますが、ほとんど素のPHPです。
ヘルパーはかなり用意されていますが、使い方を見てもどうも全然便利そうに見えない不思議。
というわけでSmartyに差し替えましょう。
幸い公式自らSmarty用ラッパを公開してくれています。
まずはSmartyの準備。
applicationディレクトリ内にSmarty用ディレクトリを作成。
application/
├templates/
└smarty/
├libs/
├cache/
├configs/
└templates_c/
templatesフォルダにテンプレートを置き、それ以外の本体やキャッシュなんかはsmartyフォルダに突っ込むことにします。
Smarty公式サイトからダウンロードして解凍、中身のlibsフォルダをapplication/smarty/libsに設置。
次にZend_View_Smartyクラスをさくっとコピーして、Zend/View/Smarty.phpに設置します。
これはZend_ViewからSmartyを呼び出せるように連携させるクラスです。
ダミーのindex.htmlを設置。
application/templates/index/index.html
html/index.php
Fatal error: Cannot access protected property Zend_View_Smarty::$_smarty in C:\hoge\fuga\html\index.php on line 21
あら？
具体的に死んでる行はここ。
setViewBasePathSpec($view->_smarty->template_dir)
なんでかというとZend_View_Smartyでprotected $_smarty;ってやってるせい。
http://helog.jp/php/zend-framework/984/とかPHP5.3.0なのにどうして動いてるんだろう？ふしぎ。
今回はテンプレートディレクトリをSMARTY_TEMPLATE_DIRで定義してるので素直にsetViewBasePathSpec(SMARTY_TEMPLATE_DIR)と書き直して実行。
見事にSmartyの適用に成功しました。
setViewScriptPathSpecとかsetViewScriptPathNoControllerSpecとかはリクエストパラメータの処理方法みたいです。
よくわからないのでとりあえずそのままで。
setViewSuffixはテンプレートの拡張子です。
デフォルトは'phtml'とかいう変な拡張子になっているので'html'に変更します。
以上で、Zend_ControllerでSmartyを利用することができるようになりました。
というかサンプルのテンプレートを見ればわかりますが、ほとんど素のPHPです。
ヘルパーはかなり用意されていますが、使い方を見てもどうも全然便利そうに見えない不思議。
というわけでSmartyに差し替えましょう。
幸い公式自らSmarty用ラッパを公開してくれています。
まずはSmartyの準備。
applicationディレクトリ内にSmarty用ディレクトリを作成。
application/
├templates/
└smarty/
├libs/
├cache/
├configs/
└templates_c/
templatesフォルダにテンプレートを置き、それ以外の本体やキャッシュなんかはsmartyフォルダに突っ込むことにします。
Smarty公式サイトからダウンロードして解凍、中身のlibsフォルダをapplication/smarty/libsに設置。
次にZend_View_Smartyクラスをさくっとコピーして、Zend/View/Smarty.phpに設置します。
これはZend_ViewからSmartyを呼び出せるように連携させるクラスです。
ダミーのindex.htmlを設置。
application/templates/index/index.html
<html><body>Hello, World!{$smarty.now}</body></html>
最後にZend_Viewを呼び出すかわりにZend_View_Smartyを呼び出すように設定変更します。html/index.php
<?php
//define
define('APP_DIR', dirname(__FILE__).'/../application/');
define('SMARTY_DIR', APP_DIR.'smarty/libs/');
define('SMARTY_TEMPLATE_DIR', APP_DIR.'templates/');
define('SMARTY_COMPLIE_DIR', APP_DIR.'smarty/templates_c/');
define('SMARTY_CACHE_DIR', APP_DIR.'smarty/cache/');
define('SMARTY_CONFIG_DIR', APP_DIR.'smarty/config/');
//require
require_once('Zend/Controller/Front.php');
require_once('Zend/View/Smarty.php');
require_once(APP_DIR.'smarty/libs/Smarty.class.php');
//Zend_View_Smarty
$view = new Zend_View_Smarty(SMARTY_TEMPLATE_DIR, array('compile_dir'=>SMARTY_COMPLIE_DIR, 'cache_dir'=>SMARTY_CACHE_DIR, 'config_dir'=>SMARTY_CONFIG_DIR));
//Zend_Controller_Action_Helper_ViewRenderer
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('ViewRenderer');
$viewRenderer->setView($view)
->setViewBasePathSpec($view->_smarty->template_dir)
->setViewScriptPathSpec(':controller/:action.:suffix')
->setViewScriptPathNoControllerSpec(':action.:suffix')
->setViewSuffix('html');
//実行
Zend_Controller_Front::run(APP_DIR.'controllers');
実行。Fatal error: Cannot access protected property Zend_View_Smarty::$_smarty in C:\hoge\fuga\html\index.php on line 21
あら？
具体的に死んでる行はここ。
setViewBasePathSpec($view->_smarty->template_dir)
なんでかというとZend_View_Smartyでprotected $_smarty;ってやってるせい。
http://helog.jp/php/zend-framework/984/とかPHP5.3.0なのにどうして動いてるんだろう？ふしぎ。
今回はテンプレートディレクトリをSMARTY_TEMPLATE_DIRで定義してるので素直にsetViewBasePathSpec(SMARTY_TEMPLATE_DIR)と書き直して実行。
見事にSmartyの適用に成功しました。
setViewScriptPathSpecとかsetViewScriptPathNoControllerSpecとかはリクエストパラメータの処理方法みたいです。
よくわからないのでとりあえずそのままで。
setViewSuffixはテンプレートの拡張子です。
デフォルトは'phtml'とかいう変な拡張子になっているので'html'に変更します。
以上で、Zend_ControllerでSmartyを利用することができるようになりました。
さて、安定して電力を供給できる環境ができたので、便利な機械をどんどん作っていきましょう。
まずは電気炉(Electro Furnace)。
電気で動くかまどです。
ソーラーで動くので、燃料いらずのかまどといってもいいでしょう。
素材も鉄のかまど、電子回路、レッドストーン*2と安価です。
鉄のかまどを全部置き換えてしまってよいでしょう。
万一電力不足で動かなければそのときだけ通常のかまどを置けばいいだけですし。
なお、精錬速度もかまどよりかなり速くなります。
次は抽出機(Extractor)。
メイン用途は樹液からからゴムを抽出することになります。
普通に焼くと樹液ひとつからゴムひとつですが、抽出機を使うとなんとゴムが3つできあがります。
レシピはマシンブロック、電子回路、ツリータップ*4。
また、ゴムの木そのものを突っ込んでもゴムができあがります。
なんといっても素晴らしいのはRedPowerで追加される馬鹿でかいゴムの木からもゴムに変換できること。
これにてゴム不足問題が一気に解消されることになります。
最後に圧縮機(Compressor)。
高度な機械を作るために必須の装置となります。
また、多少手間ですが、石炭からダイヤモンドを作成することができます。
レシピはマシンブロック、電子回路、石*6。
以上で基本の機械装置4種類が完成しました。
太陽光でいつのまにか充電されているので、いくら使っても電気を使い果たすことはほぼありません。
使用機会の多い粉砕器、電気炉あたりはもっと増やして並べておくととっても便利になります。
ひととおり機械を作ったので、次はEUリーダー(EU-Reader)を作ります。
EUリーダーはケーブルに流れるEUを知ることができるということで、つまり要するに電圧計です。
作成した発電機や電気機械が正しく接続されているか、電圧は足りているかなどを調査できます。
レシピは銅ケーブル*4、電子部品とあとグロウストーンダストです。
使い方はケーブルに向かって右クリックです。
一回目のクリックで測定を開始し、2回目以降はそれまでに流れたEUの平均値を知ることができます。
なお、耐久値はなく無制限に使用可能です。
ついでにスキャナー(OD Scanner)も作りましょう。
レシピは銅ケーブル*3、電子回路*2、充電池、グロウストーンダストと意外と高コスト。
使用すると、自分の真下にある鉱石を数値で示してくれます。
が、で、この24が具体的にどんな鉱石なんだということについてはわかりません。
ほとんど意味なし。
なお、バッテリー駆動なので耐久力はありますが使い切ってもなくなりません。
蓄電池や充電池で充電し直せばいくらでも使えます。
マインクラフトのまとめ
まずは電気炉(Electro Furnace)。
電気で動くかまどです。
ソーラーで動くので、燃料いらずのかまどといってもいいでしょう。
素材も鉄のかまど、電子回路、レッドストーン*2と安価です。
鉄のかまどを全部置き換えてしまってよいでしょう。
万一電力不足で動かなければそのときだけ通常のかまどを置けばいいだけですし。
なお、精錬速度もかまどよりかなり速くなります。
次は抽出機(Extractor)。
メイン用途は樹液からからゴムを抽出することになります。
普通に焼くと樹液ひとつからゴムひとつですが、抽出機を使うとなんとゴムが3つできあがります。
レシピはマシンブロック、電子回路、ツリータップ*4。
また、ゴムの木そのものを突っ込んでもゴムができあがります。
なんといっても素晴らしいのはRedPowerで追加される馬鹿でかいゴムの木からもゴムに変換できること。
これにてゴム不足問題が一気に解消されることになります。
最後に圧縮機(Compressor)。
高度な機械を作るために必須の装置となります。
また、多少手間ですが、石炭からダイヤモンドを作成することができます。
レシピはマシンブロック、電子回路、石*6。
以上で基本の機械装置4種類が完成しました。
太陽光でいつのまにか充電されているので、いくら使っても電気を使い果たすことはほぼありません。
使用機会の多い粉砕器、電気炉あたりはもっと増やして並べておくととっても便利になります。
ひととおり機械を作ったので、次はEUリーダー(EU-Reader)を作ります。
EUリーダーはケーブルに流れるEUを知ることができるということで、つまり要するに電圧計です。
作成した発電機や電気機械が正しく接続されているか、電圧は足りているかなどを調査できます。
レシピは銅ケーブル*4、電子部品とあとグロウストーンダストです。
使い方はケーブルに向かって右クリックです。
一回目のクリックで測定を開始し、2回目以降はそれまでに流れたEUの平均値を知ることができます。
なお、耐久値はなく無制限に使用可能です。
ついでにスキャナー(OD Scanner)も作りましょう。
レシピは銅ケーブル*3、電子回路*2、充電池、グロウストーンダストと意外と高コスト。
使用すると、自分の真下にある鉱石を数値で示してくれます。
が、で、この24が具体的にどんな鉱石なんだということについてはわかりません。
ほとんど意味なし。
なお、バッテリー駆動なので耐久力はありますが使い切ってもなくなりません。
蓄電池や充電池で充電し直せばいくらでも使えます。
マインクラフトのまとめ
先日バットボックスを作成しました。
蓄電容量40000EU、出力32EUで、出力は大抵の機械を問題なく動かすことはできますが、蓄電容量は粉砕できるアイテム64個(1スタック)分と少々心許ないです。
そこで、バットボックスの上位種であるMFEトランスミッタ(MFE Transmitter)を作ってみます。
まず素材として必要となるのがエナジークリスタル。
端的に言うと充電池の上位版で、充電池が10000EU貯めておけるのに対し100000EUを保存することができます。
素材はダイヤモンド*1+レッドストーン8となります。
MFEトランスミッタのレシピは、エナジークリスタル*4+銅ケーブル*4+マシンブロックです。
つまりMFEトランスミッタにはダイヤモンドが4つ必要ということです。
それだけのコストを支払うだけのことはあり、蓄電容量は600000EUとバットボックスの15倍、出力電圧も128EUという値になります。
さて、このMFEトランスミッタと前回のソーラー発電機を組み合わせてみましょう。
とりあえずソーラーパネルの花をいくつか用意します。
それぞれから銅ケーブルを引き、電線を集約するところにMFEトランスミッタを設置します。
こうすることで、コストと蓄電容量のバランスの取れた発電施設が完成します。
MFEトランスミッタは最上位機種のMFSユニットでもいいのですが、作るのが大変なのでいったんはMFEトランスミッタで完成させるとよいでしょう。
ちなみに写真では花同士の間隔をひとつ間違っており、隙間が少し空いてしまっています。
花のひとつづつは十字型で隙間なく埋めることができるので、特に理由のない限り詰めてしまいましょう。。
まあ、いずれは花を崩して平面にするのですが、今から気にしてもしかたないね。
さてその次ですが、MFEトランスミッタから銅ケーブルを引き、末端に粉砕器を接続します。
やりますよね？ね？
爆発します。
そりゃもう見事に木っ端みじんになりました。
銅ケーブルの耐圧性能は低圧の32EUしかなく、粉砕器も記載はありませんが定格電圧が2EUなので低圧用でしょう。
それに対してMFEトランスミッタの出力は中圧の128EUです。
銅ケーブルの先に機械装置を設置した時点で一気に許容量以上の電圧が流れ込み、爆発四散してしまうという寸法です。
従って行わなければならないことは、MFEトランスミッタの出力を低圧32EUに降圧させることです。
そのための機械が低圧変換装置(LV Transformer)となります。
レシピは木材*4+銅*3+銅ケーブル*2とリーズナブル。
低圧変換装置を設置すると、ぽっちが3つある面がひとつ、ぽっちが1つある面が5個できます。
この3ドットの面から128EUを受け取り、1ドットの面から32EUの電圧を出力するのが低圧変換装置の役割となります。
なお、レッドストーン入力を渡すと動作が逆転し高圧から出力になりますが、とりあえず今のところ使いません。
まずMFEトランスミッタの出力から低圧変換装置の入力に、金ケーブルで接続します。
レシピは金*3で裸の金ケーブル、裸の金ケーブル+ゴムで金の絶縁ケーブル、金の絶縁ケーブル+ゴムで金の2倍絶縁ケーブルとなります。
裸ケーブルは感電するので素直に2倍絶縁しておきましょう。
MFEトランスミッタと低圧変換装置はべつに直結でもいけるのですが、今後の取り回しを考えて、ちょっと離して設置しました。
これで、低圧変換装置からの出力を問題なく粉砕器につなげることができるようになりました。
蓄電容量40000EU、出力32EUで、出力は大抵の機械を問題なく動かすことはできますが、蓄電容量は粉砕できるアイテム64個(1スタック)分と少々心許ないです。
そこで、バットボックスの上位種であるMFEトランスミッタ(MFE Transmitter)を作ってみます。
まず素材として必要となるのがエナジークリスタル。
端的に言うと充電池の上位版で、充電池が10000EU貯めておけるのに対し100000EUを保存することができます。
素材はダイヤモンド*1+レッドストーン8となります。
MFEトランスミッタのレシピは、エナジークリスタル*4+銅ケーブル*4+マシンブロックです。
つまりMFEトランスミッタにはダイヤモンドが4つ必要ということです。
それだけのコストを支払うだけのことはあり、蓄電容量は600000EUとバットボックスの15倍、出力電圧も128EUという値になります。
さて、このMFEトランスミッタと前回のソーラー発電機を組み合わせてみましょう。
とりあえずソーラーパネルの花をいくつか用意します。
それぞれから銅ケーブルを引き、電線を集約するところにMFEトランスミッタを設置します。
こうすることで、コストと蓄電容量のバランスの取れた発電施設が完成します。
MFEトランスミッタは最上位機種のMFSユニットでもいいのですが、作るのが大変なのでいったんはMFEトランスミッタで完成させるとよいでしょう。
ちなみに写真では花同士の間隔をひとつ間違っており、隙間が少し空いてしまっています。
花のひとつづつは十字型で隙間なく埋めることができるので、特に理由のない限り詰めてしまいましょう。。
まあ、いずれは花を崩して平面にするのですが、今から気にしてもしかたないね。
さてその次ですが、MFEトランスミッタから銅ケーブルを引き、末端に粉砕器を接続します。
やりますよね？ね？
爆発します。
そりゃもう見事に木っ端みじんになりました。
銅ケーブルの耐圧性能は低圧の32EUしかなく、粉砕器も記載はありませんが定格電圧が2EUなので低圧用でしょう。
それに対してMFEトランスミッタの出力は中圧の128EUです。
銅ケーブルの先に機械装置を設置した時点で一気に許容量以上の電圧が流れ込み、爆発四散してしまうという寸法です。
従って行わなければならないことは、MFEトランスミッタの出力を低圧32EUに降圧させることです。
そのための機械が低圧変換装置(LV Transformer)となります。
レシピは木材*4+銅*3+銅ケーブル*2とリーズナブル。
低圧変換装置を設置すると、ぽっちが3つある面がひとつ、ぽっちが1つある面が5個できます。
この3ドットの面から128EUを受け取り、1ドットの面から32EUの電圧を出力するのが低圧変換装置の役割となります。
なお、レッドストーン入力を渡すと動作が逆転し高圧から出力になりますが、とりあえず今のところ使いません。
まずMFEトランスミッタの出力から低圧変換装置の入力に、金ケーブルで接続します。
レシピは金*3で裸の金ケーブル、裸の金ケーブル+ゴムで金の絶縁ケーブル、金の絶縁ケーブル+ゴムで金の2倍絶縁ケーブルとなります。
裸ケーブルは感電するので素直に2倍絶縁しておきましょう。
MFEトランスミッタと低圧変換装置はべつに直結でもいけるのですが、今後の取り回しを考えて、ちょっと離して設置しました。
これで、低圧変換装置からの出力を問題なく粉砕器につなげることができるようになりました。
チェストのパワーアップを行えるMODをいくつか。
何故かチェスト系MODの作者は日本人が多いです。ふしぎ。
まずはUsefulFunc。
幾つかの便利機能の詰め合わせですが、そのうちのひとつに「多段チェスト」機能があります。
どういうものかというと、こう。
本来チェストの上にブロックがあるとチェストは使えませんが、このMODを入れると縦に並べても全てのチェストが使えるようになります。
非常に便利ですが、元々「チェストのふたを開ける」ために上に空間が必要だったことを考えると、少々美意識に反する気もします。
導入は世界観を考えてから行いましょう。
とか書いてたら公式で多段チェストが実装されてしまったので気にする必要はなかったらしい。
次はカラーボックス。
こちらも同じ作者のMODで、羊毛でチェスト(ColorBox)を作成することができます。
レシピは羊毛*8
手元に白と黒しかなかったので写真は二色ですが、使用した羊毛の色に応じて全16色が作成できるようです。
容量は通常のチェストと同じ9*3マスです。
特徴としてはUsefulFunc同様重ねて使用できることと、二つ並べても連結しないこと、そしてカラフルなことです。
連結しないのを逆手にとって、いくつも横に並べて使用することができます。
気軽に作成でき、ぱっと見わかりやすくてよいMODです。
次に錬金チェスト。
これは単品ではなく、Equivalent Exchange(EE)という大型MODの機能の一部です。
錬金チェストのレシピは共有結合粉(Si)、共有結合粉(Fe)、共有結合粉(C)、ダイヤ、石*2、チェスト、鉄インゴット*2と、他のチェストに比べてだいぶめんどくさいです。
なお共有結合粉はEE固有のアイテムで、装備を修理したりすることができるみたいです。
レシピは共有結合粉(Si)が石炭、丸石。
共有結合粉(Fe)がレッドストーン、鉄インゴット*2。
共有結合粉(C)がダイヤ、グロウストーンダスト*2。
なお、ここらへんのレシピはバージョンによってどんどん変わってるみたい。
今回のレシピはバージョン5.4.1のものです。
錬金チェストのスペックは、収容量が13*8の104個で通常チェスト(27)の約4倍
またカラーボックス同様複数並べても連結することがなく、並べて設置することができます。
そして最大の特徴は、EEの一部のアイテムを錬金チェストに入れておくことによって、錬金チェストがその効果を発揮するようになることです。
効果が発動って何？
持ってるだけで周囲11マスのアイテムを自動吸収する指輪とか、土や砂利を鉄や金に変換してくれる宝珠(土2048→レッドストーン64→金4→ダイヤ1)とか、そういったチート級のアイテムがEEにはいくつか存在し、それをチェストに入れておくとチェスト自体がその効果を発動するようになります。
とはいえそのようなアイテムの作成にはダイヤが72個必要だったりと手間暇をひたすら浪費する廃人向けMODなので、深入りしないかぎりあまり関係のない話ではありますが。
おつぎはMulti Page Chest。
レシピはダイヤ+チェスト*8。
複数ページの名前からしてわかるとおり、最大の特徴はその収容能力。
13*9マス*5ページで585個ものアイテムを保管しておくことが可能です。
さすが赤いだけのことはある。
最後にUsefulChest。
レシピはダイヤ+チェスト。
Multi Page Chestより安価なのに、13*8マス*10ページで1040個もの莫大なアイテムを保管しておくことができるという文字通り桁違いのMOD。
なおかつソート機能、ゴミ箱機能付きとレシピ的にも容量的にも機能的にもこちらの圧勝です。
かなり反則気味。
ぶっちゃけUsefulChestが便利すぎて他のチェストが選択候補になりませぬ。
何故かチェスト系MODの作者は日本人が多いです。ふしぎ。
まずはUsefulFunc。
幾つかの便利機能の詰め合わせですが、そのうちのひとつに「多段チェスト」機能があります。
どういうものかというと、こう。
本来チェストの上にブロックがあるとチェストは使えませんが、このMODを入れると縦に並べても全てのチェストが使えるようになります。
非常に便利ですが、元々「チェストのふたを開ける」ために上に空間が必要だったことを考えると、少々美意識に反する気もします。
導入は世界観を考えてから行いましょう。
とか書いてたら公式で多段チェストが実装されてしまったので気にする必要はなかったらしい。
次はカラーボックス。
こちらも同じ作者のMODで、羊毛でチェスト(ColorBox)を作成することができます。
レシピは羊毛*8
手元に白と黒しかなかったので写真は二色ですが、使用した羊毛の色に応じて全16色が作成できるようです。
容量は通常のチェストと同じ9*3マスです。
特徴としてはUsefulFunc同様重ねて使用できることと、二つ並べても連結しないこと、そしてカラフルなことです。
連結しないのを逆手にとって、いくつも横に並べて使用することができます。
気軽に作成でき、ぱっと見わかりやすくてよいMODです。
次に錬金チェスト。
これは単品ではなく、Equivalent Exchange(EE)という大型MODの機能の一部です。
錬金チェストのレシピは共有結合粉(Si)、共有結合粉(Fe)、共有結合粉(C)、ダイヤ、石*2、チェスト、鉄インゴット*2と、他のチェストに比べてだいぶめんどくさいです。
なお共有結合粉はEE固有のアイテムで、装備を修理したりすることができるみたいです。
レシピは共有結合粉(Si)が石炭、丸石。
共有結合粉(Fe)がレッドストーン、鉄インゴット*2。
共有結合粉(C)がダイヤ、グロウストーンダスト*2。
なお、ここらへんのレシピはバージョンによってどんどん変わってるみたい。
今回のレシピはバージョン5.4.1のものです。
錬金チェストのスペックは、収容量が13*8の104個で通常チェスト(27)の約4倍
またカラーボックス同様複数並べても連結することがなく、並べて設置することができます。
そして最大の特徴は、EEの一部のアイテムを錬金チェストに入れておくことによって、錬金チェストがその効果を発揮するようになることです。
効果が発動って何？
持ってるだけで周囲11マスのアイテムを自動吸収する指輪とか、土や砂利を鉄や金に変換してくれる宝珠(土2048→レッドストーン64→金4→ダイヤ1)とか、そういったチート級のアイテムがEEにはいくつか存在し、それをチェストに入れておくとチェスト自体がその効果を発動するようになります。
とはいえそのようなアイテムの作成にはダイヤが72個必要だったりと手間暇をひたすら浪費する廃人向けMODなので、深入りしないかぎりあまり関係のない話ではありますが。
おつぎはMulti Page Chest。
レシピはダイヤ+チェスト*8。
複数ページの名前からしてわかるとおり、最大の特徴はその収容能力。
13*9マス*5ページで585個ものアイテムを保管しておくことが可能です。
さすが赤いだけのことはある。
最後にUsefulChest。
レシピはダイヤ+チェスト。
Multi Page Chestより安価なのに、13*8マス*10ページで1040個もの莫大なアイテムを保管しておくことができるという文字通り桁違いのMOD。
なおかつソート機能、ゴミ箱機能付きとレシピ的にも容量的にも機能的にもこちらの圧勝です。
かなり反則気味。
ぶっちゃけUsefulChestが便利すぎて他のチェストが選択候補になりませぬ。
コードジェネレータ？
自動でプログラム作ってくれるの？仕事が楽になるね！やったね！
と思ったかどうかはわかりませんが、実際問題としてZend_CodeGeneratorは自動プログラミングの一種と言えるかというと全然言えません。
ちょっと試しに使ってみましょう。
上のソースはわざと丁寧に書いており、実際にはメソッドチェーンが効いたり値を配列で纏めて設定できたりもするのですが、それでもインプットよりアウトプットのほうが張るかに小さくなるという結果は揺るぎません。
コードジェネレータを使って楽をしようという試みはほとんど無謀ということがわかるかと思います。
ではこれは何のためにあるのかというと、要はzf create projectとかsymfony generate:projectみたいなものです。
というかzf create projectは実際にZend_CodeGeneratorを使っています。
自動でプログラム作ってくれるの？仕事が楽になるね！やったね！
と思ったかどうかはわかりませんが、実際問題としてZend_CodeGeneratorは自動プログラミングの一種と言えるかというと全然言えません。
ちょっと試しに使ってみましょう。
<?php
header('Content-type: text/html; charset=UTF-8');
require_once('Zend/CodeGenerator/Php/Class.php');
//クラス
$class = new Zend_CodeGenerator_Php_Class();
$class->setName('Hoge');
//ドキュメント
$docblock = new Zend_CodeGenerator_Php_Docblock(array(
'shortDescription' => 'クラスサンプル'
,'longDescription' => 'これはZend_CodeGeneratorで生成されたクラスです。'
));
$class->setDocblock($docblock);
//プロパティ
$property1 = new Zend_CodeGenerator_Php_Property();
$property1->setName('property1');
$property1->setDefaultValue('value1');
$class->setProperty($property1);
$class->setProperty(array(
'name'=>'property2', 'defaultValue'=>'value2', 'static'=>true, 'visibility'=>'private'
));
//メソッド
$method1 = new Zend_CodeGenerator_Php_Method();
$method1->setName('method1');
$method1Param1 = new Zend_CodeGenerator_Php_Parameter();
$method1Param1->setType('string');
$method1Param1->setName('param1');
$method1Param1->setDefaultValue('default');
$method1Param2 = new Zend_CodeGenerator_Php_Parameter();
$method1Param2->setType('int');
$method1Param2->setName('param2');
$method1Param2->setDefaultValue( new Zend_CodeGenerator_Php_Parameter_DefaultValue("null"));
$method1->setParameters(array($method1Param1, $method1Param2));
$class->setMethods(array($method1));
//完成したクラス
print($class->generate());
以上の記述で、できあがるのが下のクラス。
/**
* クラスサンプル
*
* これはZend_CodeGeneratorで生成されたクラスです。
*/
class Hoge
{
public $property1 = 'value1';
private static $property2 = 'value2';
public function method1(string $param1 = 'default', int $param2 = null)
{
}
}
うん、まあなんだそのちょっと待て。上のソースはわざと丁寧に書いており、実際にはメソッドチェーンが効いたり値を配列で纏めて設定できたりもするのですが、それでもインプットよりアウトプットのほうが張るかに小さくなるという結果は揺るぎません。
コードジェネレータを使って楽をしようという試みはほとんど無謀ということがわかるかと思います。
ではこれは何のためにあるのかというと、要はzf create projectとかsymfony generate:projectみたいなものです。
というかzf create projectは実際にZend_CodeGeneratorを使っています。
