Japanese board.

Elona開発ファイル所有者の情報交換トピック

Postby Noa on Tue Mar 08, 2011 8:30 am

要望がありましたので、Elona開発ファイル所有者のために、情報交換のトピックを作成しました。
開発に関する質問や、意見交換、現在進めているプロジェクトがかぶっていないかの確認などにお役立てください。
匿名でもかまいません。


User avatar
Noa
Moderator
 
Posts: 355
Joined: Mon Jul 07, 2008 12:55 pm

Re: Elona開発ファイル所有者の情報交換トピック

Postby vivivich on Sat Mar 12, 2011 1:26 am

かたつむりもいいとこですが、いつまでも発言がないのは寂しいので書きこんでみます。

VimDeHotSoup
hp.vector.co.jp/authors/VA038334/archive/index.html
とりあえずタグジャンプや補完などひと通り使え、ビルドして起動できるところまでは確認しました。
(タグジャンプで4千行目とかに飛ぶとシンタックスが有効にならない…?)

また、今までに行われた1.22の不具合修正についての書き込みをまとめたスレを立ててくださった方がいるようです。
("餅"から辿れます。匿名の御仁らに感謝しつつ修正箇所を勉強させてもらってます)

英語フォーラムのElona存続プロジェクトはどうなるでしょうね。
競争でなく協力できればと思いつつ、やどかりのようにソースコードを読んでますが。


vivivich
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby 海月 on Sat Mar 12, 2011 5:32 am

うーん…英語版のほうのフォーラムではそこそこ活動が行われているようですが、
こちらのほうではさっぱりですね。
ソースコードの所有者の人たちが協力して、
とりあえずソースコード中にコメントを入れたりして見やすくする作業は必要だと思うのですが…。

私のほうでも個人的にソースコードの解読をしていますが、
なにぶん容量が多いのでなかなか作業がはかどりません。

PS.地震大変でしたね。elonaプレイヤーの皆様は無事なのでしょうか…
ノースティリスだけじゃなく日本にも地殻変動が…。


海月
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Sat Mar 12, 2011 6:43 am

中華にelonaが支配されてオワタ


Guest
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Sun Mar 13, 2011 2:38 pm

遅ればせながら、ソースコードを入手した者の一人ですが。
自分は完全に趣味的な意図で受け取っているので、真面目に今後の継続考えていらっしゃる方に何らかの協力はしたいと思ってはいます。
が、現状だとそもそもどういったことが望まれてるのか微妙に分からないので、なんとも…。

なので当面は誰か音頭取ってくれる人が出てきてくれるといいな、と思ってちょくちょくのぞきに来ます。


Guest
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby vivivich on Mon Mar 14, 2011 1:40 pm

海外フォーラムの動きの翻訳っぽいものなんて需要ありますかね。

----
Official Elona Continuation Project
elona.squares.net/forum/viewtopic.php?f=3&t=4777

Daedric: (存続プロジェクトを呼びかけた人)
正式な後継を目指すプロジェクトとしてこんなの考えてるよ(詳細なマイルストーン)。協力者募集!
(協力するよー!という声や、勝手に公式ヅラすんなよといった声が寄せられる中、数日後…)
先に手をつけてる人がいたからひとまず様子見するよ。レスつけてくれたみんな、ありがとう。
あと日本にいる人の無事と健康を祈ってます。


jdstroy: (おそらく先に手をつけていた人)
えっと、Daedricに書けって言われたから書いときます。
HSPlet改造してJavaへの移植を目指してます。コンパイルまではできました。けどまだ問題があって…ちょっと時間かかりそう。
オープンソース化の予定は今のところ立てられません。少なくともNoaさんに認めてもらわないといけないので。
素材のライセンスの問題もあるから、移植版を初めて一般公開するときは画像や音声抜きで出すと思います。

将来的にはこれがElonaの後継になったらいいなーって思ってます。
メンテナンスしやすくして、サウスティリスとか未完成な部分も作って、
未翻訳部分を訳したり、今も少しいる韓国のプレイヤーのために韓国語モードを作ったりするのもいいかな。
まだこういうとこに注力する余裕はありませんが。

まずは今のElona(1.22…というかHSPのソースの最新のもの)のバグ以外の要素を漏らさず移植することを目指してます。
いつかはNoaさんにプロジェクトに戻ってきてもらえたらと思ってます。
もしそこまでできなくても、Elonaの方向性について助言をもらえたらいいなぁ。

今はこんなとこです。質問とかあれば後で答えます。もう寝る時間なので(´・ω・`)
あ、スレッド分けるべきだったね。明日やっときます。
----

意訳や誤読、読み飛ばしもかなり多いので話半分にどうぞ。

2chのほうでもC/C++への移植を試みている人がいると見た記憶がありますが、最近どうなってるのか私は把握してません。
何にせよ、Elonaの1.22開発版に続くものを目指すという立場ならば、
今のところはオリジナルで行われている処理の理解につとめておくのが良いかなぁ、と思い私はそうしています。
Last edited by vivivich on Thu Mar 17, 2011 6:18 pm, edited 2 times in total.


vivivich
 
Posts: 13
Joined: Sat Mar 12, 2011 11:30 am

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Mon Mar 14, 2011 3:33 pm

おー、翻訳ありがとうございます。
海外フォーラム気になってはいたのですが、英語が全然読めないものなんで助かります。

2chにC/C++移植試行してる人がいるのかー、
私もC/C++に移植しようかなとか思ってる身なんで、情報交換できたらなとか思います。


Guest
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Mon Mar 14, 2011 4:22 pm

因みにご存じの方もいるかもですが。
Elonaの前身のサイトページが生きていて、そこにのあ猫さんがElonaで使用しているテクニックの記載があります。

homepage3.nifty.com/rfish/hsp1.html

特にcallや配列変数の#define呼出し等は多くのソースで使用されているので、把握しておくと解析もはかどるかと思います。
上記のページはGoogleで検索して偶然見つけただけなので他にもスクリプトについての情報記載があるかは分かりません;


Guest
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby Nyamonaki on Thu Mar 17, 2011 1:24 pm

とりあえずあちこちに分散されているバグ情報、バグの修正情報を譲渡されたソースに対して適用する場合の修正点まとめ
※なにをさておいても、公式フォーラムや、2chの解析・改造スレ、外部板のElona不具合修正スレ等に色々書いてくれた人に感謝

以下、箇条書きでだらりと行きます
--------------------------------------------------------------------------------------------------------------
カジノ表示バグ
 ミニゲームのカジノでのBJ時に画面描画がおかしい
 対処
 screen.hsp 121行目
  なぜかコメントされていたのでコメントを外す

心眼エンチャントクリティカル率補正バグ修正
 「それは心眼の技術を上昇させる」のエンチャントの付いた武具を装備しても
 心眼スキル上昇によるクリティカル率の上昇が加味されない
 対処
 calculation.hsp 421行目
  クリティカル率の再計算位置がまずいので421行目を無難と思われる494行目付近へ移動

遺物系マテリアル未出現バグ修正
 「鳥の羽」、「ウサギの尻尾」等のマテリアルが出現しない
 対処
 proc.hsp 32行目
  atxLv+=sAnatomy(pc)/3の前にatxSpot = atxRemain1の記述を追加

高レベルネフィア取得マテリアルバグ修正
 高レベルのネフィアなどでマテリアル採集をしても「クズ」しか採集できない
 対処
 material.hsp 14行目
  lv--:rare--をlv++:rare++へ変更
 material.hsp 15行目
  matLv(p)<lvをmatLv(p)>lvへ変更
 material.hsp 16行目
  matRare(p)<rareをmatRare(p)>rareへ変更
 ※マテリアルの入手バランスに影響があるので要調整?

食べた物に付与されていたエンチャントにより適用される効果の修正
 「運勢を維持する」が付与された生もの製の武具を食べると落ちる
 対処
 item.hsp 1197行目
  if enc2=encSustain{をif ((enc2=encSustain)&(enc!rsLUC)){に変更する事で
  「運勢を維持する」によって成長期が発生しないように対処できる
 ※運の成長率が0%なのが問題?運に成長率を設定するのとどちらが良いか?

鍵開けバグ修正
 開錠に失敗した場合にそのまま再挑戦すると開錠難度が不正な値になる
 対処
 action.hsp 861行目からの*lockpickサブルーチン
  サブルーチン開始直後にグローバル変数valに渡されてきた開錠難度を別変数に退避し、
  開錠判定を退避した別変数で行うようにする

レシピ選択画面の表示ずれ修正
 config.txtにてwindowH.を600以上に設定した場合に、テスト用フライパンなどを
 使用してレシピ選択ウィンドウを表示すると右ウィンドウの調合の手順以下の表示位置が
 ずれる
 対処
 blend.hsp 287行目
  dy=120をdy=y+48に変更

カジノ景品おまけのエーテル抗体の取得率修正
 カジノ景品のおまけで貰えるエーテル抗体の取得率が連勝数が4の時が最大で以降
 連勝するごとに下がっていく
 対処
 Noa氏への問い合わせの結果、「連勝すればするほど取得率が上がるように」が意図との
 ことだったので
 txtadv.hsp 737行目
  if rnd(200)>(winRow*5+5)をif rnd(200)<(winRow*5+5)へ変更
 ※エーテル抗体の取得難度が上がると思われるため要調整?

アニメ表示部の修正
 アニメ表示が意図されたように表示されていない
 対処
 screen.hsp 927行目
 ifの条件に関わらずpreparePicItem 17が実行されている
 Noa氏への問い合わせの結果、「記憶が定かではないが多分記述ミス」とのことことだったので
 else後のpreparePicItemのパラメータを17から18に変更
 ※item.bmpを見て「多分18かな?」と判断したので正しい値かどうかは不明

追加打撃、追加射撃時のダメージ属性修正
 属性ダメ追加があると追加打撃/射撃時にその属性で攻撃してしまう
 対処
 action.hsp 1452行目
  最後に:ele=0を追加

光源範囲修正
 光源の届く距離が南北と東西で1マス違う
 対処
 init.hsp 67行目
  maxFovに設定する値を15から17へ変更
 screen.hsp 1003行目
  sx(3)=cX(pc)-maxFov/2-2をsx(3)=cX(pc)-maxFov/2へ変更
 system.hsp 1621行目
  repeat maxFov+4をrepeat maxFovへ変更
 system.hsp 1623行目
  dist(x*10/12,y,maxFov/2,maxFov/2)<maxFov/2を
  dist(x,y,maxFov/2,maxFov/2)<(maxFov-2)/2)へ変更
 system.hsp 1630行目
  repeat maxFov+4をrepeat maxFovへ変更
 ついでにウィンドウ高さの768制限を解除(変更)
 screen.hsp 17行目
  2つの768を適当な任意の値へ変更

家具価値再計算バグ修正
 修飾子の付いている家具を素材変化すると価値がおかしくなる
 対処
 item_data.hsp 1183行目
  originalValue=iValue(ci)*100/mtRef(1,p)で素材価値適用前の価値を
  計算している部分を
  ・家具の場合
  ・修飾子が付いている場合
  を加味して計算するように変更する
  以下、例
  if ( refType = fltFurniture ) {
   // 家具の場合
   if ( iSubName(ci) != 0 ) {
    // 修飾子がある場合
    originalValue = iValue(ci) * 100 / (80 + iSubName(ci) * 20)
   } else {
    // 修飾子がない場合
    originalValue = iValue(ci)
   }
   originalValue = iValue(ci) - mtRef(1, p) * 2
  } else {
   // 家具以外の場合
   originalValue = iValue(ci) * 100 / mtRef(1, p)
  }

オパートス信仰によるダメージ減衰バグ修正
 オパートスを信仰する事によって得られるはずのダメージ減衰が無効になっている
 対処
 chara_func.hsp 1469行目
  ダメージ減衰処理自体は1474行目で判定しているが現在HPに対するダメージの
  適用が1469行目なので意味がなくなっている
  1474行目での判定と同じ物を1468行目より前に追加すればよい
  以下、例
   if ( (tc == pc) & (cGod(pc) == godEarth) ) : dmg = dmg * 90 / 100
 ※PC以外のNPCにも信仰が設定されるようになったため(tc == PC)は不要?

画面下部のステータス表示部にゴミが残る問題修正
 画面最下部、4桁に達している主能力の1の位にゴミが出る
 対処
 screen.hsp 176行目
  sx=inf_raderW+cnt*47+168をsx=inf_raderW+cnt*47+168-2に変更
 screen.hsp 179行目
  gcopy selInf,0,440,24,16をgcopy selInf,0,440,28,16に変更

ダイエットバグ修正
 体重が上限に達してると痩せられない
 対処
 chara_func.hsp 1866行目
  if mode=0をif ((mode=0)&(a>0))に変更

低名声時(1000未満)の盗賊団の頭領のレベル調整
 名声が1000未満の場合、盗賊団の首領が基本レベル(Lv12)で生成される
 対処
 action.hsp 673行目
  encounterLv=cFame(pc)/1000の後ろに:if encounterLv=0:encounterLv=1を追加
 ※名声1000~1999時と同じレベルになるため要調整?

バックパックが満杯のときに、井戸(聖なる井戸)の水を空き瓶で汲むと落ちるのを修正
 対処
 アイテムが満杯でitem_createの戻り値がfalseかつciに-1が設定されているのに
 そのままitemName(ci,1)を実行しようとしてitemName内部で落ちる
 以下、例
 action.hsp 1623行目
  1623行目の直後に
  if (inv_getFreeId(pc) == falseM) : item_num ciDip, 1 : txtInvFull : goto *turn_end
  の行を追加し、アイテムが満杯の場合はメッセージを表示し何もしないようにする
--------------------------------------------------------------------------------------------------------------
以上が今のところこちらで把握、対処済みな不具合などになります
行数は若干ずれがあるかもしれませんので各自で察して補正お願いします

以下、ソースを解析、修正していて気付いた点
・上記の不具合まとめでも出ているpreparePicItem(#defineマクロ)が使用時の記述によっては意図しない不正な展開を
 される事があります
 ※まさに不具合まとめで示している箇所
 #deffunc辺りに書き直すといいかも知れません(速度面が多少気になりますが)
・譲渡されたソースをそのままHSP 3.21でコンパイルしようとするとエラーが発生します
 原因はHSP 3.2から追加されたラベル変数に関連する物で一つ上の記事で紹介されているページにて記載されている
 パラメータを設定してgosubを行う部分を#defineを使用してcallに置き換えている部分にあります
 対処はinit.hsp 4261行目で
 #define global call(%1,%2=0) procRef%2: gosub *%1
 と定義されている部分を
 #define global call(%1,%2=0) procRef%2: gosub %1
 に変更し、「全ての」callマクロ使用部分の第一パラメータの先頭に*を追加すればコンパイルできるようになります
 例:call act_melee を call *act_melee に変更


Nyamonaki
 
Posts: 9
Joined: Mon Jul 28, 2008 1:51 pm

Re: Elona開発ファイル所有者の情報交換トピック

Postby vivivich on Thu Mar 17, 2011 6:10 pm

ゲスト wrote:Elonaの前身のサイトページが生きていて、そこにのあ猫さんがElonaで使用しているテクニックの記載があります。
homepage3.nifty.com/rfish/hsp1.html

Nyamonaki wrote:とりあえずあちこちに分散されているバグ情報、バグの修正情報を譲渡されたソースに対して適用する場合の修正点まとめ

とても役立ちそうだったので翻訳して海外フォーラムに投げ込んでみました。
elona.squares.net/forum/viewtopic.php?f=3&t=4777&start=30#p28019
誤訳などないかチェックしていただければ幸いです。

NoaさんのHSP TIPSも訳そうかと思ったけど、気がつけばもう3時。おやすみなさい(´ω`)…


vivivich
 
Posts: 13
Joined: Sat Mar 12, 2011 11:30 am

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Fri Mar 18, 2011 4:02 am

ところで、ソース譲渡された方の中で、著作権に絡む記述を見つけた方はいらっしゃいますか?

ニーズがあるかは別として、画像・ライブラリなどを除外したElona固有のHSPソースについてはGitHubなどで共有していければ、各人の作業も効率的になると思うのですが。

現状、素材や外部ライブラリ以外で公開出来ないような箇所というのを全て除去出来ればそういった試みも可能かなぁと考えてます。


Guest
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Mon Mar 21, 2011 9:27 am

ワァォついに譲渡のお願いメールしちゃった
ところで
・カジノの抗体入手率は不等号反転だけだと現状より極端に下がるがあれ(おまけ程度)が本来のバランスなのか
っていう事までは誰か聞いたのかな
明らかなバグ以外のリトシスとか自宅店員とか生きた武器とか裏技とかバランスとか色々聞きたい事あるけど
その辺直すべきか否かってのはやっぱ各自で考えるしかないんだろうな
Noaさんにプレッシャー掛けるつもりは毛頭ないが、俺らにはどう頑張ってもNoa版elonaは作れないんだなぁと再確認したさ


Guest
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby vivivich on Tue Mar 22, 2011 2:14 pm

ゲスト wrote:ところで、ソース譲渡された方の中で、著作権に絡む記述を見つけた方はいらっしゃいますか?

ニーズがあるかは別として、画像・ライブラリなどを除外したElona固有のHSPソースについてはGitHubなどで共有していければ、各人の作業も効率的になると思うのですが。

現状、素材や外部ライブラリ以外で公開出来ないような箇所というのを全て除去出来ればそういった試みも可能かなぁと考えてます。

ソースを共有して今後一つのプロジェクトとして動くのであれば、何らかのバージョン管理システムは必要になると私も思います。
ただ、今HSPのソースコードでそれをやるとなると、ちょっと腰が動きません。

同じ文面で受け取っているかわかりませんが、Noaさんからのメールに書かれていたのとだいたい同じ理由です。(開発ファイルの公開についてのくだり)
* たいへんな労力がかかるだろうということ
* 複数での開発に向いたソースコードではない(とNoaさんが言っている)こと
あと、私の場合は「今後も開発にHSPを使い続けていくべきと言い切れない」というのも理由です。
Noaさんの開発環境の遺産を使えば、ちょっとした数値の変更や、アイテムの追加などは簡単に行えるという利点がありますが、それ以上に不具合への対処が大変になりそうだと思っているので。

些か消極的ではありますが、私は何らかの移植版のソース公開を待つつもりです。
海外フォーラムのjdstroyさんのものか、彼の作業が頓挫してDaedricさんが移植したものか、はたまた2chの人のものか、どれになるかわかりませんが。

言葉の壁はありますが、いくつもの後継プロジェクトが乱立して争うよりは、うまく協力できれば…と思っています。翻訳ばかりしてるのはそういった理由からですね。
jdstroyさんの移植作業にはHSPのソースコードを整理するという項目もあるので、こちらの不具合情報修正情報を伝えることで既知のバグが移植に伴い修正されるかと思っています。(移植で新たにバグが起きる?それはそれ、これはこれ)
話がそれたのでこの辺にしておきます。

----
ゲスト wrote:・カジノの抗体入手率は不等号反転だけだと現状より極端に下がるがあれ(おまけ程度)が本来のバランスなのか
っていう事までは誰か聞いたのかな

まとめには問い合わせたと書かれているようですが、これのことではありませんか?
Nyamonaki wrote:カジノ景品おまけのエーテル抗体の取得率修正
 カジノ景品のおまけで貰えるエーテル抗体の取得率が連勝数が4の時が最大で以降
 連勝するごとに下がっていく
 対処
 Noa氏への問い合わせの結果、「連勝すればするほど取得率が上がるように」が意図との
 ことだったので
 txtadv.hsp 737行目
  if rnd(200)>(winRow*5+5)をif rnd(200)<(winRow*5+5)へ変更
 ※エーテル抗体の取得難度が上がると思われるため要調整?



ゲスト wrote:Noaさんにプレッシャー掛けるつもりは毛頭ないが、俺らにはどう頑張ってもNoa版elonaは作れないんだなぁと再確認したさ

開発がチーム体制になることでNoaさんの負担軽減→Noaさんがチームメンバーとして復帰→メンバーで話し合うことでインスピレーションが生まれ、Noaさんが今まで一人で作ってきたもの以上のものが作られる…
なんて妄想もしてしまいますが。
結局のところ受け入れられるかどうかはプレイヤーの方達の気持ち次第なので、できることをやるしかありませんね。

----
Jdstroyさんの移植作業に立ちはだかる問題について以前の翻訳では完全に省略してしまったので、もしかして日本では信頼度が低いのかなぁ…と思ったので、少しだけ訳します。
3月13日時点での現状報告と、対処の箇条書き3点のうち1つ目まで。Javaにそこまで明るくないので、うまく察していただければ。
jdstroy wrote:While HSPlet can compile Elona, it produces a .class file which is too large to fit within the constraints of the Java specification .class files. In particular, the Java constant pool has a limitation of 65535 (more or less) items, and HSPlet produced ~130000 constants for the constant pool.

There are several ways to attempt to fix this issue, but they all take time.

* Change the source code to reduce branches in HSP (which, in turn, reduce the number of methods created, which reduce the number of method names and reduces the number of constants in the constant pool). This can be done by parsing the HSP source code and rearranging it/optimizing it for size.
* Optimize the bytecode, in-memory (which will inline short methods, which will reduce the number of method names, which will reduce the number of constants in the constant pool). This can also be done, and it is rather generic, but it requires knowledge of Object Web ASM's in-memory tree representation of bytecode.
* Change the source to call out to the native environment to obtain constants (straight forward to reduce constants). This is a very generic process, and this is how I'm planning to extend Elona.

<翻訳開始>
HSPletでElonaをコンパイルできたけど、できる.classファイルがでかすぎてJavaの仕様に引っかかる。
もうちょっと突っ込んだ話をするなら、定数を一時的に保持しておける数が最大で65535個までなんだけど、HSPletは13万個弱の定数を吐き出してしまう。

これに対処する方法はいくつか思いつくけど、どれも時間がかかりそうだ。
・ソースコードに手を加えてHSPでの枝分かれを減らす。(つまり、作られるメソッドを減らす、で、それでメソッドの名前と定数の数が減る)
これはHSPのソースコードを整理することで実現できる。
・バイトコードの最適化~云々
・ネイティブ環境の命令を直で呼ぶように変更~云々
<翻訳終了>

parseとrearrangeとoptimizeのうまい訳し分けが思いつかない!(整理・整頓・最適化?)
ので「整理」一言で済ませる大雑把ぶりですが、参考になれば幸いです。

これ以降、海外フォーラムはjdstroyさんのJava移植待ちのようになっていて、
* 「プログラムできるぜ!」「テストプレイヤーなら…」といった新たな協力の意思表明
* 移植に使う言語(Java?C++?)やクロスプラットフォーム対応などの議論
* 「jdstroyさんのブログとかないの?進捗知りたいんだけど」「まだ無い」
といったことが話されているようです。

日本にも協力したいという人はきっと多いかと思うので、また時間があるときにDaedricさんの協力者募集(既に一時停止中)のところでも訳そうかと思います。
今のところプログラミングが(大なり小なり)できるという人と、技術はないからテストプレイとかで協力するという人がほとんどで、
Elona用の素材(画像・音声)を提供するよといった声はまだ見られません。
Daedricさんの機械翻訳のスレッドが、日本語フォーラムの協力の意思表明スレッドになると良い感じ?

おそらく向こうでは、今のところ日本に後継のプロジェクト(サーバーやWebサイトの管理も引き継ぐ)は無いという認識だと思います。
(派生ヴァリアントについては、開発している人が複数いそうだと伝えました)
Daedricさんは、「Elonaは日本のゲームなんだから、日本にプロジェクトがあれば優先すべき」といったことも言ってくれていますが、
彼を見ていると今までのElonaやNoaさん、プレイヤーへの配慮がたくさんにじみ出ているので、日本からもどんどん参加者を送り込んで一つのプロジェクトとしてまとまったらいいんじゃないか、というのは私の意見です。

長々と失礼しました。
Elonaの発展と、震災復興を願っています。「金!!」


vivivich
 
Posts: 13
Joined: Sat Mar 12, 2011 11:30 am

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Tue Mar 22, 2011 9:10 pm

ファイル所有者ではありませんが、1つ宜しいでしょうか?

いずれは C/C++ または Java 環境に移行させるべきかと思いますが、それには時間が掛かるはずです
移行が終了するまでの間、一般ユーザーは 1.16 安定版~ 1.22 開発版の地点で足踏みすることになってしまうので、
配布された 1.23(仮) 開発版のソースを元にバグフィックスや調整を行ったものを 1.23 安定版として公開するべきではないでしょうか


Guest
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Thu Mar 24, 2011 2:05 am

※エーテル抗体の取得難度が上がると思われるため要調整? って書いてあるから
「連勝すればするほど取得率が上がるように」ってだけしか答えてもらってないんだと思った
俺はバランスもそれっぽいし不等号反転だけでいいと思うけど、きつくする場合は正当な理由が無いと受け入れてもらいにくいからね


Guest
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby 海月 on Thu Mar 24, 2011 8:50 am

海外のフォーラムではJavaで開発する方向になっているんですか?
うーん…私もJavaには詳しくないのでなんとも。 C++なら分かるんですけど…。

あと、私もelona ver1.22のバグフィックスや修正をして安定版を出したほうがいいと思います。
安定版の1.16リロfix2もバグがあることはありますしね…。
でも、いきなりバージョンアップした人が困惑しないように、修正箇所をしっかり明記したり、
バランスを再度見直すなどの工夫がいると思います。


海月
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby kirito on Fri Mar 25, 2011 1:03 pm

みなさま、議論御苦労さまです。

私もElona信者で開発に協力したいと思っているのですがファイル所有者ではない者の一人です。

>配布された 1.23(仮) 開発版のソースを元にバグフィックスや調整を行ったものを 1.23 安定版として公開するべきではないでしょうか
私も安定板をリリースするのは賛成なのですが、まずは開発体制を整えるのが先決のような気がします。

vivivich様の書かれた通り、様々なプロジェクトが乱立してしまうより公式として一つのプロジェクトを維持管理する方が
noa様の意思に沿うような気がします。

細部のバグフィックスについて語るのも大切ですが、まずはそういった体制・環境を整える事について議論してみるというのは如何でしょうか?
いくつか例を挙げますと
・SourceForge.JP等を利用する
・リポジトリを用意してコミットする
・RedmineやGitHubを利用する
などなどです。

あくまで一意見で恐縮ではございますが・・・
皆で協力してnoa様のelonaの世界がより素晴らしいものへと広がる事を祈っております。


kirito
 
Posts: 3
Joined: Mon Feb 21, 2011 2:34 am

Re: Elona開発ファイル所有者の情報交換トピック

Postby x00 on Fri Mar 25, 2011 2:37 pm

うーん。
私の個人的な所感なのですが、
公式プロジェクト維持を望んでいるのは、
elonaユーザーのような感じがします。

本人に直接確認したわけではないですが、
規約とかメールを読んで感じたのは、
ユーザーに楽しんで頂ければ、形式はあまり
気にしてないような印象を受けました。

でも、トラブルの類いを懸念してたので
乱立するよりは、纏まった認識の元に、
プロジェクトを動かすのは良いと思います。

原形ソースのほうは、
Noaさんの確認が取れれば、オープンソースにしても良いとありますが、
プロジェクトの方針とか体制が整ってからNoaさんにお願いしたほうが良いのかなとか思います。

ソースの量多いから確認も大変だと思うし。

もしかしたら、書き直したほうが早く管理出来るようになるかも。


x00
 
Posts: 3
Joined: Thu Mar 24, 2011 12:21 pm

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Fri Mar 25, 2011 3:58 pm

jdstroyさんの状況報告、それに加えて救援要請(?)の翻訳です。どうやら苦戦しているようです。
elona.squares.net/forum/viewtopic.php?f=3&t=4777&start=60#p28151
jdstroy wrote:Status: Working on infrastructure; some basic optimizations applied to source to reduce constant pool size and executable size. Constant pool is still over limit at ~135k entries. Indirect constant pool reduction through original source appears to be difficult to achieve the desired constant pool size. More drastic measures will likely be required (e.g. manipulation of generated intermediate representation without relying on correctness of bytecode).

If we have some JVM experts, compiler/optimization experts, or ObjectWeb ASM experts, this is my call to you. Please step up; your help is needed for this port of Elona!

<翻訳開始>
状況: 基礎部分に取り組んでいる; コンスタントプールのサイズと、実行体サイズを減らすために、いくつか基本的な最適化をした。コンスタントプールはまだ大きすぎて、13万5千弱のエントリーがある。オリジナルのソースを変更して、間接的にコンスタントプールのサイズを縮小するのは難しいとわかった。もっと抜本的な対策が求められてるみたいだ。(例えば、--訳注:ええっと、ごめんなさい、この文は知識が足りず無理でした。"バイトコードの正しさに依存しない、生成された中間表現の操作"?なんのこっちゃ)

もしJVMに明るい方、コンパイラと最適化に詳しい方、ObjectWeb ASMに強い方がいたら、どうか助けてください。お願いします、Elona移植にあなたの助けが必要です!
<翻訳終了>

翻訳し終わってから思ったのは、手助けできる人=英語できるだから翻訳する必要なくね?ということ。
まぁ現状報告の部分もあるので載せておきます。

同じポスト内でオープンソース化する際のライセンスについても話しているようでした。
オープンソース化自体は賛成、だけどGPLは絶対イヤ。使うならApache License2.0みたいなやつかな。…といったことをおっしゃっています。

----
ゲスト wrote:俺はバランスもそれっぽいし不等号反転だけでいいと思うけど、きつくする場合は正当な理由が無いと受け入れてもらいにくいからね

店の商品入れ替え周期のような例もあるので、バランス絡みの問題は慎重にならざるをえませんね。

----
海月 wrote:海外のフォーラムではJavaで開発する方向になっているんですか?
うーん…私もJavaには詳しくないのでなんとも。 C++なら分かるんですけど…。

元のフォーラムでも同じような声がありました。その後の流れは…
C++がわかるならJavaもすぐわかるって!
ここで宗教戦争してもしょうがないよね。
…と言った感じでした(超省略していますが)。今は再びJava移植待ち状態になってる感じです。
もしも(無いことを願いますが)、jdstroyさんが移植をギブアップした場合は、
Daedricさんは移植をC++で試みると前に言っていました。(hsp3cnvが使えるかな?だとか)

----
kirito wrote:細部のバグフィックスについて語るのも大切ですが、まずはそういった体制・環境を整える事について議論してみるというのは如何でしょうか?
いくつか例を挙げますと
・SourceForge.JP等を利用する
・リポジトリを用意してコミットする
・RedmineやGitHubを利用する
などなどです。

なんたるタイミング!ちょうど向こうのフォーラムでも開発専用のフォーラムを立てるだとか、コードホスティングサービスだとかの話が始まったところでした。
とりあえずSourceForgeについては、既にライセンスを決めてあるものしか利用できないらしく、現時点で使う予定はない、とはjdstroyさんの意見です。
(意訳。彼は「利用規約をよぉぉーく読んで」としか言ってません)

体制を整えると言っても、開発が進行中のものが私が知ってるだけでも6つはあるので、結局共通して役立ちそうなバグ探しと翻訳に戻ってしまうんですよね…。
(日本に複数開発体制になりそうなものがあるのかどうかも…?)
開発専用フォーラムが立ち上がったり、移植の進展など、向こうで新しい動きがあればまた翻訳しようと思います。


Guest
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby vivivich on Sat Mar 26, 2011 12:38 am

海外フォーラムの動きの震源地、Daedricさんの提案を翻訳しました。
elona.squares.net/forum/viewtopic.php?f=7&t=4778&p=28109#p28109

このポストやこれに続く詳細なマイルストーンのポストで、今後の開発についてイメージしやすくなり、
海外フォーラムが、協力の意思表示をしやすい空気になっているんだと思います。

x00 wrote:本人に直接確認したわけではないですが、
規約とかメールを読んで感じたのは、
ユーザーに楽しんで頂ければ、形式はあまり
気にしてないような印象を受けました。

又聞きかつ推測ではありますが、「実際に進んでるプロジェクトのどれも喜んでサポートする」と考えておられそうだ、と私も思います。
elona.squares.net/forum/viewtopic.php?f=3&t=4777#p27895
Daedric wrote:Second, I have talked to Noa, and based on those conversations my impression is that he is happy to support any real project. I have requested of him to help make a real project "Official" if it is stable and if he likes it. He seemed very open to the idea.


翻訳を通してこっちの盛り上がりも加速すれば、と思いつつ送信。(あ、上のポストログインせずに投稿しちゃってる…)


vivivich
 
Posts: 13
Joined: Sat Mar 12, 2011 11:30 am

Re: Elona開発ファイル所有者の情報交換トピック

Postby Nyamonaki on Sun Mar 27, 2011 1:26 am

周りの状況もよく見ずにひたすらバグを潰しているにゃもなき冒険者です

ある程度の意味は読み取れるものの自分で文章を書くほどの英語力がないのでvivivichさんの翻訳には感謝しています

jdstroyさんが作業中のHSPletによるJavaへの移植(変換?)についてですが「基本的な最適化」の中に#defineで定義されているマクロを
#deffucで命令化するというのは入っているのかな?というのが聞いてみたいところです
そのうえで13万5千弱のエントリーがあるってことでしたら内部的に持っている日本語、英語の文字列リソースを外部に持つってのが
手っ取り早いような気がします(作業量としては膨大ですが)
とりあえず仕組みとかよく理解してないので見当違いのこと言ってるかもしれません


Nyamonaki
 
Posts: 9
Joined: Mon Jul 28, 2008 1:51 pm

Re: Elona開発ファイル所有者の情報交換トピック

Postby kirito on Mon Mar 28, 2011 3:06 pm

vivivich様、またまた翻訳ありがとうございます。
海外のDaedric様の投稿は開発体制が細かく言及されていて素晴らしいですね。
大変勉強になりました。

また、HSPletによるJavaへの移植について海外のjdstroy様に問い合わせて頂いているようですね。
ありがとうございます。
私もNyamonaki様のように日本語、英語の文字列リソースを外部(CSVファイル等)に持たせて、プログラム内で参照・変換させるようにすれば
文章の差し替えや多言語への対応が円滑にできるのではないかと思います。

2chや餅を見る限り個々人で開発を進めていらっしゃる方が多いようなので、
そういった方々のお役に立てるよう、ゲーム内の使用素材の著作権関連や現状のバグフィックス状況等をまとめた一覧表みたいなモノを作ろうと思っているのですが、
開発者の皆々様にご質問させて下さい。
WEBドキュメントは色々ありますが、どのような媒体が使い易いでしょうか?
・wiki(Wiki for Elonaのように見慣れている)
・Redmine(バグ管理ができる)
・その他(他に良いのがありましたら教えて下さい)

Wiki for Elonaの解析スレの豊富な情報に今気がつきました><
丈夫なロープで吊ってきます・・・
先人の知恵は素晴らしい・・・


kirito
 
Posts: 3
Joined: Mon Feb 21, 2011 2:34 am

Re: Elona開発ファイル所有者の情報交換トピック

Postby x00 on Mon Mar 28, 2011 5:12 pm

参考までに、既存であるそれっぽいものをあげてみる。

「Elonaの改造・解析に関するまとめwiki」
www47.atwiki.jp/elona_valiant/

たまに著作権関連の調査情報とかあったりするスレ
「elonaのソース譲渡関係の集会場」
jbbs.livedoor.jp/bbs/read.cgi/game/45610/1299200625/

私の意見としては、上記wikiに解析情報と載ってたりするので、
開発の取っ掛かりとして、著作権とかも一緒に載せとけば、
制作者としては見やすくなるのではと思います。


x00
 
Posts: 3
Joined: Thu Mar 24, 2011 12:21 pm

Re: Elona開発ファイル所有者の情報交換トピック

Postby vivivich on Tue Mar 29, 2011 1:03 pm

jdstroyさんの移植版(仮)のWikiができたようです。
elonadev.myxwiki.org/xwiki/bin/view/Main/WebHome

----
Nyamonaki wrote:ある程度の意味は読み取れるものの自分で文章を書くほどの英語力がないのでvivivichさんの翻訳には感謝しています

テキトーな英語なので誤解の温床になっていないか心配ですが、負担軽減のメリットのほうが大きければいいなぁ、などと考えつつ、
#defineマクロの件と、文字列リソースについて翻訳&投下してきました。

前者については、(NoaさんのHSP開発TIPSを訳していないこともあり)「よくわからん」と言われてしまいました :P
jdstroy wrote:I've not done anything with #defines and #deffunc, but if one generates code with less constants, then I'm willing to look into it.

『#defineと#deffuncには何もしていない。けど、もし誰かがそれで定数の数の減ったコードを生み出したとなれば、私も見てみるよ』
だそうです。これの前に試そうと思っている別の対策が既にいくつかあるみたいですね。

後者については、メンテナンスのしやすさ向上も期待できるし、やってみる価値は十分あるという返事でした。
(数字も交えて説明してくれている部分は気合いを入れないと読めなさそうなので飛ばし読み)

jdstroyさんの今後の計画に多言語化は含まれているので、移植版ではいずれテキストを外部に持つよう変更されると思います。


vivivich
 
Posts: 13
Joined: Sat Mar 12, 2011 11:30 am

Re: Elona開発ファイル所有者の情報交換トピック

Postby Nyamonaki on Wed Mar 30, 2011 7:32 pm

vivivichさん、翻訳&投下ありがとうございます

私の勘違いでなければHSPletは入力ファイルとして*.axもしくはPACKFILEを指定し、それをJavaに変換する(ような)物だと思っています
で、前述した#defineを#deffuncに変換、他私なりの最適化(?)を施したstart.axを添付しますのでこれを変換した場合、
各種数値(constants, methods)がどの位変化するのか知りたいです
大して変化が無いようならばもう一つの文字列リソースの外部ファイル化の方を模索してみたいと思います

と、ここまで書いて思ったのですが、もしかして実行時に各種CSVファイル(item.csv等)を配列に読み込み、実処理はその配列への
アクセスにするだけでも結構効果あるのかも?
start.zip
(809.67 KiB) Downloaded 6222 times


Nyamonaki
 
Posts: 9
Joined: Mon Jul 28, 2008 1:51 pm

Re: Elona開発ファイル所有者の情報交換トピック

Postby vivivich on Sat Apr 02, 2011 6:44 am

+++元のポストに加筆があったので修正しました。
jdstroy wrote:Nyamonaki: Yes, that's correct. HSPlet takes .ax / PACKFILEs as input and interprets that at compile time to generate Java bytecode. Thanks for the start.ax -- your changes reduced the numbers of methods:

3189 fields, excluding literals
19494 literals
22683 fields
8589 methods

+++36712 constants in constant pool, with no literals
132518 constants in constant pool

At first, I wasn't sure why there are so many constants in the constant pool at first; looking at VMspec, (the Java Virtual Machine Specification), I thought I understood the reason: three constant pool entries per method, four constant pool entries per HSP literal, and three constant pool entries per field (without a value):

8589 * 3 + 19494 * 4 + 3189 * 3 = 113310

Which is pretty close to the current actual constant pool size.

But apparently it isn't as easy as I thought. I stepped into the code to trace some of the constant pool population, and it looks like duplicates are being removed properly, which means that the actual number should be much lower. I'll need to look into this a bit more to understand it completely.

+++Over all, though, it looks like it may be feasible to compile Elona on to HSPlet -- 36712 + 19494 < 65535, so there's a possibility that these constants can be exported to several classes and linked in to the main class.

いつもどおり、大体の翻訳を貼りつけときます。
<翻訳開始>
Nyamonakiさん
うん、それで合ってるよ。HSPletは .ax か PACKFILE を入力ファイルとして受け取って、コンパイル時にそれを変換してJavaのバイトコードを吐き出す。
添付の start.ax ありがとう。 --あなたの変更でメソッドの数が減ったよ。

3189 fields, (リテラルを除く)
19494 literals
22683 fields
8589 methods

+++リテラルを除けば、36712個の定数がコンスタントプールにある。
コンスタントプールには 132518 個の定数がある。

最初に、僕は何故こんなにもたくさんの定数がコンスタントプールにあるのかがわからなかった。 Java Virtual Machine の仕様を見て、その理由がわかった気がする。
メソッドごとに3つのエントリーがコンスタントプールにあり、同様にHSPリテラルごとに4つ、フィールドごとに3つ(値以外)あるようだ。

8589 * 3 + 19494 * 4 + 3189 * 3 = 113310

これは今の実際のコンスタントプールサイズにかなり近い。

しかし、どうも事は思っていたほど簡単じゃないらしい。
コードに踏み込んで、コンスタントプールの一団を追ってみた。で、どうやら重複は適切に取り除かれてるように見えた。
つまり実際の数はもっと小さくなってもおかしくない。これが何を意味するかもうちょっと突き詰めて見てみる必要があるみたいだ。

+++けど、ひっくるめて考えるに、ElonaをHSPletでコンパイルすることは可能なように見える。 -- 36712 + 19494 < 65535 (訳注:リテラル以外のconstants + リテラルの数 < コンスタントプールの定数の限界)、つまりこれらの定数は複数のクラスへ出力されて、それからメインクラスへリンクされている可能性がある。
<翻訳終了>

技術的知識に欠けるため直訳っぽい箇所もありますが…なんとかこれで伝わると良いなと思いながら翻訳。

以前の数値がこんな感じでした。(貼り忘れ)
jdstroy wrote:~135000 total constants in the constant pool after simple restructuring the item database
~33000 constants generated when the literals (Strings, Doubles/Floats, Integers) are removed.
~9000 methods generated

constants総計が135000弱→132518
+++リテラルを除いたconstants数が33000→36712
methodsが9000弱→8589

最後の2行は、マクロを命令呼び出しにしてコードの重複が取り除かれても、
それがコンスタントプールのエントリーを減らすことに単純にはつながらない…ということでしょうか。(数は減ってますが)

+++察するに、HSPletの変換過程でリテラルが定数数を爆発させていそうだから、その対処法を探っているのだと思います。

+++あと、まったく関係ありませんが彼の署名欄がジュア様なのにさっき気づきました。
"I-it's not like I'm porting it for you, or anything! I'm just rewriting it for maintainability! So don't get the wrong idea!"

+++べ、別にあんたのために移植しようとしてるんじゃないんだから!メンテナンスしやすいように書き換えてるだけよ!勘違いしないでよね!
Last edited by vivivich on Sun Apr 03, 2011 11:00 am, edited 5 times in total.


vivivich
 
Posts: 13
Joined: Sat Mar 12, 2011 11:30 am

Re: Elona開発ファイル所有者の情報交換トピック

Postby Nyamonaki on Sat Apr 02, 2011 4:31 pm

vivivichさん、翻訳&投下および返事の翻訳ありがとうございます

ふむ、methodsの方に主に効果が出たのかな? < #define to #deffunc
気になってたliteralsの方はどの値と比較すればいいのだろう?
どんな変更がどの値に効果を及ぼすのかちょっと分かりにくかったので手間をかけますが
今回添付の3種類のstart.axでも各種数値を出してもらえるとありがたいです

それぞれの大まかな内容は
start1.ax
 db.hspを変更
 ・*db_item_setサブルーチンで各種アイテム情報を直接設定している部分を配列より指定するように
 ・上記に必要な配列情報を設定するサブルーチンを作成
 ・*db_itemサブルーチン内のランダムアイテム生成部をループ化(配列化したため可能に、影響度合いは分からないけれどラベルを約800個削減)
 +α

start2.ax
 上記start1.axでの配列情報を設定するサブルーチンを外部ファイルからデータを読み込むと仮定して削除
 ※必要なデータが設定されていないためまともに動作しません

start3.ax
 上記start1.axで同じ値を連続して配列内に設定しているような部分を一括置換で最適化(?)
 例
 元
 filter_item(792) = ""
 filter_item(791) = ""
 filter_item(790) = ""
 filter_item(789) = ""
 filter_item(788) = ""
 filter_item(787) = ""
 変更後
 nullsring=""
 filter_item(792) = nullsring
 filter_item(791) = nullsring
 filter_item(790) = nullsring
 filter_item(789) = nullsring
 filter_item(788) = nullsring
 filter_item(787) = nullsring

以上よろしくお願いします
start.zip
(2.24 MiB) Downloaded 486 times


Nyamonaki
 
Posts: 9
Joined: Mon Jul 28, 2008 1:51 pm

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Mon Apr 11, 2011 5:40 am

このゲームがiphone等のモバイル機器に移植されたら良いなと思っている。
いつでもelonaれる・・・こんなすばらしいこと他に無いだろう?


Guest
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Wed Apr 13, 2011 2:37 pm

キーボードじゃないelonaなんて...


Guest
 

Re: Elona開発ファイル所有者の情報交換トピック

Postby Guest on Fri Apr 15, 2011 1:52 am

技術が無い上身勝手な意見ですが
noaさんを頭に据えて有志で開発とかって無理なんですかね?
ストーリー的にはnoaさん以外の人がやってしまったら二次扱いされてしまいそうですし
noaさんや開発してる人の意向もあるだろうし失礼だとは思うし
言うべきか迷ったけど、elona好きだから自然消滅するような自体になるくらいなら
非難受けても言うべきなのかなと思った次第です
自分勝手な意見で申し訳無いです


Guest
 


Return to Elona@Jp



cron