昔のHTMLで書いていた頃の日記をサルベージし、元のHTMLは消滅させよう計画、第2弾。物によってはリンク切れしてますがご容赦下さい。
ファミコン版、太陽の神殿ASTEKA II(東京書籍, 1988、日本ファルコム, 1986)の攻略方法を紹介します。
元はPC-8801用に日本ファルコムが作ったゲームで、なぜか東京書籍がファミコンに移植しています。一応前作であるASTEKA(PC-8801用、日本ファルコム, 1985)の続編ですが、ストーリーに繋がりはないらしいので気にしなくても良いです。私も前作は持っていません。
設定を簡単に紹介します。高校生の男の子(主人公)とクラスメートの女の子が主役です。女の子の父は考古学者でしたが、遺跡を調べている途中に変死し、ガイドだけが生還しました。主人公と女の子は現地ガイドのラウーラとともに、父が解けなかった遺跡の謎を解明に挑みます。
父が変死したショッキングな遺跡に行くというのに、女の子が意外と元気で楽しそうです。夏休みを利用して出かけるところを見ると、バカンスか何かと勘違いしているのでしょう。んなことはどうでもいいんですけど。
建物の名前と、大体の位置を掲載いたします。
マップが妙に広い(8x8画面)割には、建物の数はそれほど多くありません。左下の「元々何かあったけどボツになった」と言わんばかりの空き地が気になります。
クリアまでは一本道であり、選択を間違えても取り返しがつくものが多いですが、ミスるとリセットしなければならない個所があります。ハマりやすいと思われる個所を以下に列挙しておきます。
自力クリアの際は以上の点にお気をつけください。
悪霊を「見る」したとき、勝てそうにもない…と出なければ、悪霊に勝てる状態です。しかし勝負は時の運なのか、なぜか負けることがあります。正しい順序で攻略している確信があっても、戦う前にはパスワードを聞くようにしましょう。
東の密林から森の中に入り、森の西端に行き尼僧院にワープすると、神様がヒントをくれるので、詰まったら行ってみましょう。
何でこんな機能があるのか知りませんが、エンディングでツーショット場面になったら、コントローラで顔のパーツを動かせます。スタート、A、B、は使わないようです。
こんなところでしょうか。気づき次第、追加しようと思います。
クリアまでの道筋の一例を示します。建物間の移動に一番時間がかかるので、なるべく移動がないようにし最速を目指したつもりです。
※あくまでも一例です。この他にもクリア方法はあります。
研究室
ラウーラと会う
尼僧院
高僧の墓
高僧の墓 - 右の部屋
カスティーリョ
カスティーリョ - 財宝の部屋
南の泉
カラコル
千柱の間
カラコル
千柱の間
カラコル
カラコル - 2階
カスティーリョ
カスティーリョ - 財宝の部屋
カスティーリョ - 地下室
戦士の神殿
南の泉
戦士の神殿
(ジャガーがいない)
ジャガーが出てきたら
球戯場
高僧の墓
高僧の墓 - 右の部屋
高僧の墓 - 地下迷路
球戯場
カスティーリョ
カスティーリョ - 歯車の部屋
いけにえの泉
カスティーリョ - 地下室
カスティーリョ
カスティーリョ - 歯車の部屋
いけにえの泉
球戯場
球戯場 - 最深部、神殿の部屋
球戯場 - 神殿内
球戯場 - 最深部、神殿の部屋
魔王の神殿
以上でクリアーです。
この記事にコメントする
昔のHTMLで書いていた頃の日記をサルベージし、元のHTMLは消滅させよう計画、第1弾。物によってはリンク切れしてますがご容赦下さい。
ローカルなネタって一杯あって面白いですよね。今回かなりツボにはまったので、紹介します。ご当地チェックというサイトです。北海道民なので北海道のページを延々と見ていたら、うそ!これ常識じゃないか!ってのが一杯ありました。言えてる、と思ったものにコメント加えてみました。
この記事にコメントする
目次: 自宅サーバー
Wikipediaでお馴染みのMediaWikiを使ってみました。インストールは非常に親切で、わかりやすいです。これは良いです。
データベースのセットアップが面倒くさかったので、データベースドライバにはSQLiteを選択してセットアップしました。
簡単ですね。強いて言えばPukiWikiを既に動かしていた環境なので、PHPを動かすまでのハードルが無かった、というのは大きいと思いますが、それを差し引いて考えてもMoinMoinに比べて格段に親切です。
さすがWikipediaの根幹を成すシステムです。ショボい自宅サーバ(Atom D2700)にも関わらず、表示も編集も速いです。
機能面に不満はないですが、個人のメモ帳として使うには、やや大げさすぎる感はあります。トークや議論のような機能はWikipediaのように、大人数で編集しあうサイト向けで、個人利用だと全く使いません。
あ、それとね…見た目のカスタマイズは必須だと思います。デフォルトだとWikipediaそっくりの見た目になっちゃうので、ぱっと見で混乱しそうです。
この記事にコメントする
目次: Linux
自作ARMエミュレータをJavaアプレットにして、ブラウザから実行できるようにしてみました。超暫定につき、とりあえず自宅サーバにのみ置いています。おそらくそのうち消えます。
セキュリティの警告やエラーが出て、アプレットが動かない場合は [コントロールパネル] - [Java] - [セキュリティ] タブ - [高] の設定を [中] にすると動くかもしれません。後で元の設定に戻すことをお忘れなきように…。
速度が遅いとか、GUIがダサいのはさておき、SeaMonkeyで実行すると3回くらいResetボタンを押すとハングします。リロードしても直らないし、どうもメモリリークしているようです。
どうしても動かなくなったら、タスクマネージャからjp2launcher.exeを探してKillした後に、ページをリロードすると再び動きました。
明らかにバグってるので直したいのですが、JDK付属のアプレットビューアだときちんとメモリが解放されるんですよね。差が良くわかりません…。
セキュリティの警告が出ないJavaアプレットを作成するには、シマンテックやジオトラストなどの認証機関からRSAセキュリティ証明書を発行してもらい、アプレットに署名しなければならないようです。
この証明書の維持費が異常に高くて、年数万円はザラです。企業が作成するならまだしも、個人で作成するにはJavaアプレットはコストが掛かりすぎます。
やってらんないぜー。
安全のために、つまり悪意を持った第三者にアプリを書き換えられないように、アプリには信頼できる署名を入れましょう。という理屈はごもっともですが、そのコストを開発者側が負担するのは辛いものがあります。
署名が不要になるように、つまり悪意を持った第三者に書き換えられても安全を保てるように、アプリで使える機能を限定しましょう。とすると、今度は機能が全然足りなくてろくなアプリが作れず、やはり開発者には辛いものがあります。
コストの高い自由な環境orコストの低い不自由な環境、さあ、どっち?という究極の二択です。ま、どっちもイヤですよね。
30年くらい前だと思いますがNeXTの頭が切れる人達は、アプリケーションストアという仕組みを作りました。アプリ審査で悪意のあるアプリを弾き、プラットフォーム側がストレージと秘匿通信を提供することで、今まで開発者側が負担していた安全確保、流通のコストをプラットフォーム側で肩代わりしました。
アプリケーションストアの登場により、開発者は「コストの低い自由」を手にすることができたのです。素敵ですね〜。
アプリケーションストアは、今やスマートフォンにはなくてはならない存在となっています。プラットフォームを作るってのはこういうことなんでしょうね。
この記事にコメントする
目次: 自宅サーバー
今まで、コードのキーワードやコメントの文字色の変更を、手作業でやっていましたが、いつも間違えるし、何より面倒くさくてやってられません。
巷のハイライトライブラリを使って自動化だ!ということで、highlight.js(公式サイトは背景の小豆色が目に厳しい)を導入しました。
公式サイトのUsageリンクの先に説明があります。まずはダウンロードページから、highlight.jsとスタイルシート達をダウンロードします。
ダウンロードの際は、ハイライトしたい言語をチェックする必要があります。メジャーな言語には最初からチェックがついていますが、さらにハイライト対象にしたい言語があれば、追加でチェックを入れてください。
ダウンロードしたzipファイルを展開したら、自身のページに配置します。
以降の説明ではstyles内の *.cssをcss/highlightに置き、*.jsをscripts/highlightに配置した、と思って読んでください。
自身のページに、下記の三行を追加します。
<link rel="stylesheet" type="text/css" href="/css/highlight/vs.css">
<script type="text/javascript" src="/scripts/highlight/highlight.pack.js"></script>
<script type="text/javascript">hljs.initHighlightingOnLoad();</script>
CSSについては1つのテーマごとに1つのCSSファイルが作られていますから、お好きなテーマというかCSSを選んでください。
もちろんdefalut.cssを使っても、例に挙げたvs.css(VisualStudio風の色遣い)のままでも構わないです。この辺りは好き好きでどうぞ。
嬉しかったことは、特に言語を指定しなくても、それなりに推測して色を付けてくれることです。コードが短いと推測を間違うようですが、例え違う言語のハイライトだったとしても読み見やすさは格段にアップします。こりゃ便利です。
残念だったことは、行数表示がないことです。これは開発のポリシーによるもので、あえて実装していないし、するつもりもない(highlight.jsのドキュメントより)らしいので、そういうものだ、と思って諦めます。
この記事にコメントする
目次: 自宅サーバー
以前から調子が悪いなとは思っていたのですが、スマホから3G/LTE回線を使って、このブログにアクセスすると、タイムアウトして一切表示できないことがわかりました。
正確に言うと、トップページだけは表示できますが、過去の日記を表示させようとするとブラウザがダンマリを決め込んで、しまいに「サーバーが応答しない」と言われてエラーになります。
Apacheのアクセスログを見ると「サーバーが応答しない」と言われるときは、そもそもサーバーにリクエストが来ません。これはサーバに来るより前のどこかで止められていると思われます。
まず、スマートフォン側のブラウザ設定、セキュリティソフト、コンテンツフィルタなどを疑いましたが、どのブラウザを使っても、要らないセキュリティソフトを全部アンインストールしても、フィルタの契約を全部解除しても、やはり同じ症状が発生します。
じゃあ違いはURLくらいだろう、ということで、HTTP GETリクエストを飛ばせるアプリ(Ping&DNSを使いました)でリクエストを切り詰めて調べてみると、GETリクエストに ?action=cmdを入れたとき、どのサイトへのアクセスであろうと、問答無用でHTTP通信が遮断される、ということがわかりました。
例えば、
http://www.yahoo.co.jp/?action=cm
というURLにアクセスした場合はヤフーのトップページが表示されますが、
ここでcmをcmdに変えて、
http://www.yahoo.co.jp/?action=cmd
というURLにアクセスすると、するとヤフーのトップページが表示されず1分位経った頃に、ブラウザがタイムアウトの画面を出すはずです。
症状が発生するのは3G/LTE回線のみ、Wi-Fi接続だと症状は発生しない、かつ、奥さんのiPhone 5sでも全く同じ症状が出ることから、恐らくドコモの通信網のどこかで止められていると推測されます。
タイムアウトにはかなり時間が掛かるのと、一度引っかかるとそのサイトには何をしてもしばらくアクセスできなくなります。試されるときはご注意を!
しかし、一体何のために入れたルールなのだろうね…?
スマホから見られない原因がわかりましたので、このブログ側での対策を考えます。
調査から、日記を表示するのか、編集するのか、投稿するのか?など、ブログの動作を指示するための引数arg_action=cmd_xxxxがNGに引っかかっていると思われます。よってarg_action=cmd_xxxxを、全てarg_act=cmd_xxxxに置き換えます。
とは言っても、修正は一行でOKな作りにしていたので、楽勝でした。過去の俺は何を考えてこんな凝った作りにしたんだろうなあ?おかげで楽だったから良いけどさ…。
おいおい、いきなり削ったらデグレするだろ?既存のリンクはどうするんだ?というご心配については、ありがとう、でもほぼ問題ありません!が、答えです。
まず、新たに張っていただいたリンクについては、今までより改善します。つまりPCからもスマートフォンからも見ることができます。
またGoogleさんを始めとする既存のリンクについては、今までと同等です。つまりPCなどからは見られますが、スマートフォンからは見られない状態のままです。
何故かというと理由は2つ。1つ目は、既存のリンクのほぼ全てが「日記を表示」するためのリンクであることです。
2つ目は、ブログの動作にデフォルト値が存在することです。変更後のブログに、変更前のarg_action引数を指定すると単に無視されて、ブログの動作としては、デフォルト値である「日記の表示」が使われます。
なので細かい話をすると、コメント投稿とか、日記編集というリンクを張っていたサイトにとっては、今回の改修によりデグレすることになります。
他人のブログを編集するためのリンクを張るサイトは居ないだろう、という判断ですが、もし該当する方が居ましたら、お手数ですがリンク張りなおしていただければ幸いです。
この記事にコメントする
目次: ブラウザー/メーラー
SeaMonkeyがいきなり2.26から2.29にバージョンアップしたので、長らくアップデートを忘れていたのか?とちょっと焦った…。
ツルゲーネフ「片恋」二葉亭四迷 訳の「死んでも可いわ…」について。
その一節はあるけれど、I love youの訳語ではないので、都市伝説というか、誤解かな。
リンク先(FLAMA技術Blog - 二葉亭四迷は「I love you.」を「死んでもいいわ」と訳していない。)は原著にまで当たっていて大変参考になりました。
メモ: 技術系の話はFacebookから転記しておくことにした。
この記事にコメントする
目次: 車
買ってから2回目となるレガシィの車検です。今回はレガシさんを購入したネクステージ大阪茨木店さんにお願いしました。お値段は大体14万円くらいでした。
そういえばネクステージ大阪茨木店は、スバル専門店だった(少なくともレガシィを買ったときは)のですが、いつのまにかミニバン専門店に様変わりしていました。1社専門だと売れ行きが厳しいのでしょうか?
毎年、夏になるとカーセキュリティが暑さで誤報を発して、近所迷惑極まりないので、車検と同時にカーセキュリティを調整してもらいました。
センサーの位置を変えたそうですが、残念ながらもう暑くないので、調整の成果は来年にならないと確認できません…。
この記事にコメントする
目次: 自宅サーバー
長いこと開発が停滞しているPukiWikiに鞭打って使ってきました(※)が、そろそろ置き換えようかと思います。置き換え候補としてはWikipediaでお馴染みMediaWiki、TWiki、MoinMoin辺りが割と活発なプロジェクトのようです。
(※)と思ってたら、開発が再開して7月に1.5.0がリリースされました。6年ぶり?くらい?
MediaWikiはPukiWikiと同じくPHPで書かれているのは良いのですが、データベースを使うらしく面倒だったので、Python以外に何も要らないMoinMoinを試してみました。環境はApache 2.2 + WSGI + Python 2.7.3です。
MoinMoinのセットアップは初見殺しが多くてわかりづらいです。私は下記の手順で設定しました。とりあえず動きましたが、合ってるのかなあ、これ。
とりあえず使ってみた感想としては、閲覧は速いですが、編集は異様に遅いです。遅すぎてイライラする。これを常用するのは厳しいぞ…。
Pythonで書かれたCGIはライブラリの位置(site-modules)を設定ファイルに書く必要があって面倒です。私の場合、メインのSakuraのサーバと、サブの自宅サーバとで、パスを書き換えねばならず面倒くさいです。
今使っているMercurialのWebフロントエンド(hgwebdir.cgi)もPythonで書かれていて、ライブラリの位置を設定ファイルに書く必要があります。CGIをバージョンアップする度に、設定を上書きして潰してしまいInternal Server Errorに遭遇して、そういえば設定が要るんだった、と思い出します。
Python自体は簡潔で良い言語だと思いますが、CGIになると面倒くさくてイマイチというか…、単に私の管理方法が悪いだけなのか…。とにかく、あまり好きになれません。
この記事にコメントする
| < | 2014 | > | ||||
| << | < | 09 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| - | 1 | 2 | 3 | 4 | 5 | 6 |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | - | - | - | - |
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: