http://www.phys98.homeip.net/~ide/src/jnethack-3.4.3-0.10-yahpmon.patch.bz2
が404になっています。

すいません、アップし忘れていました。

アップロードしておきましたので、確認お願いします。

ありがとうございます。確認できました。動作もOKです。

ところで城の願の杖まで願いを得られなかったこと、祭壇での捧げ物を
ガマンしたこともあって初めて他職のクエストアーティファクトを得る
機会を得たのですが、他のサイトのスポイラーの記述に反して持つことが
できないようです。

結局力の杖の特殊効果は何なんでしょう？

> 結局力の杖の特殊効果は何なんでしょう？

えーと、特に特殊効果がある訳では。
一応、力の杖自体は中立のアーティファクトなので、
普通なら中立以外の時に持つのに不都合があるのですが、
それが（力の杖に関してのみ、）ないだけです。

# ぶっちゃけ、アーティファクトの意味があまりないです。
# アーティファクト数が増えるだけですし。
# 他には、捧げ物で力の杖が得られるかもってくらいです。

うーん、、、力の杖を持ってると他の属性のアーティファクト持てる、とか言うのはデマだったわけですか。
＃ちなみにそれ自身は無属性じゃないですか？

いっそのこと、「他の属性のクエストアーティファクトなども無条件で所持、使用できる」みたいな
特殊効果付けてしまっては如何でしょう？願いがややデフレ気味なTNGにおいては、たった一回の願いの放棄、は
あまりに安い代償かとは思いますけど。

> ＃ちなみにそれ自身は無属性じゃないですか？

そういえばそうでした。
と言う事で、力の杖自体の特殊効果ってないのと等しいと。

> いっそのこと、「他の属性のクエストアーティファクトなども無条件で所持、使用できる」みたいな
> 特殊効果付けてしまっては如何でしょう？

それはあまりにも便利すぎかと。
力の杖って必ず登場するものですし。
それに、

> 願いがややデフレ気味なTNGにおいては、

って状態であるのでなおさら。

なので、既存アーティファクトは、あまりにもひどい効果しかないものとかでないと
変更するつもりはなかったりします。

お世話になります。
0802版をWindowsのBCCでコンパイルしようとしていますが、
エラー E2140 ..\src\apply.c 4817: ここでは宣言はできない(関数 use_capture_ball )
と落ちます。こちらのエディターでは4810行あたりから見ても関係無さそうなコードなんですけど…。パッチ当てミスは無い模様です。何を確認し、何を提示すればよろしいでしょうか？

> お世話になります。
こちらこそお世話になります。

> エラー E2140 ..\src\apply.c 4817: ここでは宣言はできない(関数 use_capture_ball )
> と落ちます。

どうも、gcc と BCC の違いに引っかかったみたいです。
http://www.phys98.homeip.net/~ide/tmp/tng-20070802.patch
を試してみてもらえないでしょうか。

どうも、gcc は関数の先頭でなくとも変数定義しても問題ないので
不具合に気付かなかったようです。

ありがとうございました。無事コンパイル通りました。

ども、サクシャです。
いつもお世話になっております。

ところでJNetHack TNG 3.4 (2007.02.12版)のread.cを眺めていて思ったのですが、
聖別の巻物の処理において(1873行近辺)

　　　x = (al == u.ualign.type) ? 1 : ((al == A_NONE) ? -3 : -1);
　　　y = -rn2(x * 100);

rn2()の中の数が負というのは、あまり良く無さそうに思うのですが…どうなのでしょう？

一応、参照先に修正パッチ上げてみました。
修正がこれでいいのかは分かりませんが、ご検討下さい。

報告ありがとうございます。
確かに rn2()の中の数が負というのは良くなかったです。

致命的とは言えないですが、rn2() -> RND() と呼び出して、
余りを計算する除数として使われてました。
これって処理系依存な演算みたいです。

なので手元のソースに修正パッチ取り込んで置きました。

それで RND() も見たんですが、乱数使うときの禁じ手使っているようです。
# 欲しい範囲の乱数を得るために余りを使うってやつ。
まあ、ゲームだから多少許されると思いますが。


P.S.
便利そうなので、FHS パッチから TNG テスト版に Dungeon Map Overview 移植中です。
バージョンupの度に旧セーブデータがほぼ使用不能になる問題は共通ですが、
こちらには
http://www.phys98.homeip.net/~ide/jnethack.html#save-xml
なんて切札が。
一応、これを使うと旧セーブデータもある程度問題なく読めるかな、と。
# まだ、Dungeon Map Overview 対応はしてませんが。

P.S.2
FHS パッチへの怪物の騎乗パッチ移植ご苦労さまです。
TNG テスト版も移植済なので、プレイ時の印象など。

怪物が騎乗するために、鞍が迷宮に生成される確率が激増してしまったような。
対策は(放置も含め、)どうしたものかと思っています。

ども、サクシャです。

> RND()
この禁じ手部分を改善するパッチが、JNetHack Projectの各種パッチページにありますので、導入してみてはいかがでしょう。
　＃「乱数発生器にMersenne Twisterを使用するパッチ」。
　＃元々brassで使われてたものをvanilla用に分離したものです。
　＃FHSにも導入済み。

> Dungeon Map Overview
まだ一部英語表記が残っている所があったかもしれないので、どんどん和訳しちゃって下さい(笑)。
　＃これもvanilla用に独立パッチ作るかなあ。

> 怪物が騎乗するために、鞍が迷宮に生成される確率が激増してしまったような。
あ、言われて見れば確かに…。
brassやFHSパッチだと一度にポリパイルできる個数に制限がかかってるからまだしも、
制限なしで導入すると道具ざくざくになってしまいそうですね。

今は特に怪物が他の怪物に鞍を乗せる訳でもない(はずだ)し…
ほっとくかな(ぇ)

井出です。

> > RND()
> この禁じ手部分を改善するパッチが、JNetHack Projectの各種パッチページにありますので、導入してみてはいかがでしょう。

ここまでするのもどうかと思って。
この禁じ手部分のみ直してみるかも知れません。


> > Dungeon Map Overview
> まだ一部英語表記が残っている所があったかもしれないので、どんどん和訳しちゃって下さい(笑)。

既に残ってないみたいでしたけど。

一応パッチ取り込みは終ったので、もうちょっと見直して(３月下旬ですし)タイミングを見計らって
リリースしようかと思っています。
# でも、本家も狙っているのかも。(去年そうでしたし。)


> 今は特に怪物が他の怪物に鞍を乗せる訳でもない(はずだ)し…

一応、鞍が既についてれば乗りにいくようですが。
それとも、鞍を拾って付けに行かせるべきでしょうか？

> 制限なしで導入すると道具ざくざくになってしまいそうですね。

こっちはどうするかですが、ポリパイルに制限つけるか、
騎馬が死んだり、落馬した際に鞍が適当な確率で壊れたりすればいいかな、
とか思い付きました。

> 一応、鞍が既についてれば乗りにいくようですが。
> それとも、鞍を拾って付けに行かせるべきでしょうか？

ああ、既についている分に関してはそのままでいいと思います。
(馬を失った騎手も手近な他の騎馬に、と。)

鞍を拾って乗せるかどうかは、ちょっと迷いますが…
普通やらないかな？
　＃騎乗用に訓練されている怪物ばかりでもないでしょうし。

でも全怪物には適用しないとしても、中には
・他の怪物に勝手に鞍をのせて騎乗してしまう怪物(コードが多少面倒そう)
・鞍が無くても乗りこなしてしまう怪物(これは楽そう)
がいても面白いかもですね。
　＃今はエルフ系がそれに当たる…のかな？

>> 制限なしで導入すると道具ざくざくになってしまいそうですね。
> こっちはどうするかですが、ポリパイルに制限つけるか、
> 騎馬が死んだり、落馬した際に鞍が適当な確率で壊れたりすればいいかな、
> とか思い付きました。

あ、そうか。
確かに自然に壊すのもありですね。
　＃幻影の投射物の様に、魔法的に壊す事ばかり頭にあったので
　＃これでは不自然だろうと思い書かなかった。

大層な事でもないので返信で。

空瓶生成の処理に関して1、2点気になった箇所があったので、修正してみたdiffを同じ所(の下方)に上げました。
ついでに、怪物が飲んだ時にも空瓶が残るようにしてあります。
ご検討下さい。

> 空瓶生成の処理に関して1、2点気になった箇所があったので、修正してみたdiffを同じ所(の下方)に上げました。

報告ありがとうございます。

パッチを見ましたが、空瓶が残った場合のメッセージを盲目か否かで分けるのですね。
ただ、ghost_from_bottle() では make_bottle() を呼ぶ前の所で盲目か否かに関わらずに瓶の中身が空かどうか
分かる仕様になっている様です。なので、空瓶が残るのが分かってもおかしくなさそうです。
また、空瓶が生成されたけれどそれを落してしまった時も、落すのは今まで手に持っていた物のはずなので、
わざわざ「何か」だとしてメッセージを分けなくてもいいのではないかと思います。

メッセージを分けるなら、ghost_from_bottle() でのメッセージも整合させた方がいいかなあ、とか、
引数で渡さなくても make_bottle() の中で 「Blind」 参照してもいいかなあ、とか考えました。


> ついでに、怪物が飲んだ時にも空瓶が残るようにしてあります。

こっちは安定版はそのままで、テスト版の方は採り入れようかなと考えています。
# 盲目のときに空瓶が残るのも安定版はそのままかな。
# びっくりして瓶割ってしまったとかでも不自然ではないかも知れませんし。

最近、関数 makemonあたりで何か変更がありました？
fighterパッチ当てると、うちでは

..\src\makemon.c:
エラー E2380 ..\src\makemon.c 1204: 文字列または文字定数が閉じていない(関数 makemon )
エラー E2379 ..\src\makemon.c 1205: ステートメントにセミコロン（；）がない(関数 makemon )

と止まってしまうようになりました。
当方のコンパイル環境が若干変わってしまったからかも知れませんが…

＃メイン環境変更のため、VMのWin2kをZIPしてLAN越しに子供用のWinXpマシンに
＃保存したら展開不能…Winの性能の低さを忘れていてイチから環境構築しなければ
＃ならないハメになってしまい井出さんとこの更新の反映がぜんぜんできませんでした。

> 最近、関数 makemonあたりで何か変更がありました？

テスト版の方でしょうか？
詳しいバージョンも見ないとなんとも。

つい最近いじったのは確かですが。

ちなみに、最近のは Subversion 管理なので、リポジトリ参照で分かります。

svn log -v http://svn.phys98.homeip.net/jnethack/jnethack-tng/trunk/src/makemon.c
で変更のあったリビジョンを調べて、
svn diff -r 変更のあったリビジョン-1 http://svn.phys98.homeip.net/jnethack/jnethack-tng/trunk/src/makemon.c
とすれば良いと思います。
詳しくは Subversion のマニュアルを見てもらうってことで。


原因の方はちょっとこれだけでは分かりませんが、パッチ当て失敗している部分があるかも知れません。

> .\src\makemon.c:
> エラー E2380 ..\src\makemon.c 1204: 文字列または文字定数が閉じていない(関数 makemon )
> エラー E2379 ..\src\makemon.c 1205: ステートメントにセミコロン（；）がない(関数 makemon )

そちらでの .\src\makemon.c の 1204 行の前後数行も書いてもらえるとありがたいです。
こっちのソースだと対応する部分が曖昧にしか分かりませんので。