[戻る]
新着表示

タイトル
記事No
投稿日
投稿者
参照先
質問
459
: 2014/10/05(Sun) 14:42:42
kei

曲を入れようとしたところ、
740行目のデータが偶数ではありません
2行目の'*/'が不正です
といったエラーが出てどうしようもできない状態です...
一体どうすれば...
タイトル
記事No
投稿日
投稿者
参照先
Re^2: 質問
457
: 2014/09/26(Fri) 22:47:24
斜め

曲を無事に入れることができました!
早い対応ありがとうございます。
タイトル
記事No
投稿日
投稿者
参照先
Re: 質問
456
: 2014/09/26(Fri) 11:11:11
管理人

一度ゲームを起動すると曲リストのキャッシュが作られ、次回から検索されなくなるため、
これを更新するにはゲーム起動直後のBIOS風画面で、「F1」キーを押す必要があります。

画面に英語で「F1」は再検索、「F5」はスキップと表示されていますので、
このタイミングで押してください。
※およそ2、3秒間表示されています

詳しくは同梱のマニュアルをご確認ください。


もしくは、FILESフォルダ内にあるCACHE.DATを手動で削除しておくことで、
起動時に必ず再検索を行うことが出来ます。
タイトル
記事No
投稿日
投稿者
参照先
質問
455
: 2014/09/25(Thu) 20:50:14
斜め

曲の入れかたがわかりません、「BMS」ファイルの中にLR2で遊んでいた曲を入れてみたのですが読み込まれません

なにか別の手順を踏む必要があるのでしょうか?
タイトル
記事No
投稿日
投稿者
参照先
Re^5: 新機能要望
454
: 2014/09/22(Mon) 00:44:18
管理人

仕様が分からない限りはどうしてもなんちゃって処理になるので、
それっぽい動きにしたとしても、人によってはやっぱり違うと感じてしまうと思います。
これについてはひとまず、範囲調整を何らかの方法で行う形にしたいと思います。
※これにより判定が変わってしまうため、通信対戦のスコアはその時に全てリセットを行います

それと#LNOBJについてですが、どちらも音を出さないということで特に問題無さそうなので、これで確定したいと思います。
タイトル
記事No
投稿日
投稿者
参照先
Re^4: 新機能要望
453
: 2014/09/19(Fri) 22:38:42
桐山

返答ありがとうございます。

空POORについて説明ありがとうございます。
判定処理の優先度が1つ目のほうが常に高く、キー入力が遅い時の空POORの場合
確かに管理人さん仰るとおり空POORハマりすると理解できました。
現状の判定方法のままだと本家のような判定はできそうにないですね。。。

AC版の内部の詳しい処理は全くわかりませんが、
判定優先度が常に最低となっている空POOR判定のみを持った非表示オブジェを
BAD判定以上(と見逃しPOOR判定)を持った通常の表示オブジェに重ねてレーンに流す、、、
なんて感じにする処理の変更が必要そうですね。
エンジンレベルの改変は大変ですし、代案のほうでもそれなりに効果がありそうなので、
まずは判定範囲の改変を試してみたいと思いました。

#LNOBJの処理についてですが、
管理人さんの書かれている1〜4の処理での実装で良いと思います。
>#LNOBJは#WAVのIDを特殊な用途に変化させるというというイメージなので、
>いっそのこと#LNOBJのIDの音は常に鳴らさないと統一した方が分かりやすくてよいかなと思います。
50、60番チャンネルで#LNOBJのオブジェが指定されている場合についてですが、
譜面制作を多少やったことのある身の個人の感想としては、
#LNOBJは譜面制作中のロングの終端をわかりやすくするのに非常に便利に感じました。
1つまたは少数の#wavに終端オブジェを統一することによる便利さであることと、
#LNOBJで宣言したオブジェが終端として以外で使えなくなるという2点から、
#LNOBJのIDの音は常に鳴らさないように統一した方が良いと思いました。

以上です。詳細でわかりやすい返答ありがとうございました。
タイトル
記事No
投稿日
投稿者
参照先
Re^3: 新機能要望
452
: 2014/09/18(Thu) 04:03:28
管理人

いろいろ細かくありがとうございます。

フローティングに関してはスキン実装までお待ちください。
※以下の実装より先に行う予定です


空POORについてですが、まず現状のプログラムの詳細を説明しますと、
オブジェクトの判定は以下の通り、オブジェの時間を中心に叩いたときの時間の差がどのくらいかで判定されます。
http://www.charatsoft.com/develop/otogema/page/08main/img/hitarea4.gif
(実際にはカウント値の範囲で判定しているのではなく、テンポにより判定範囲はリアルタイムに変化します)

現在のプログラムはこの画像のBADのさらに外側に空POOR領域というのがあり、
その間に叩いてしまうと空POORが発生するようになっています。
現状この空POOR領域は極端に狭くなっており、およそ3フレーム(50ms)しかありませんので、
実は空POORを出す方が難しいかもしれません。

さて、例えば1つ目と2つ目がものすごく近い位置にあったとして、1つ目を見逃して2つ目を叩こうとした時に、
1つ目と2つ目の判定領域が重なっている場合は先に1つ目が判定されてしまうため、
結果的にBADなりPOORになってしまいます。

こちらのゲームではBADならば判定済みとなりますが、POORでは判定済みにはならない設定になっており、
もしPOOR範囲が広かったとすると、さらに次の3つ目や4つ目などの連続したオブジェがあって、
その3つ目や4つ目を叩いたつもりでも、まだ判定が残っている1つ目のオブジェが判定されてしまうため、
結局は1つ目のオブジェでBADが出るまでPOORが発生することになります。

その後ようやく1つ目がBADにより判定が終了して、次の2つ目の判定が始まりますが、
やはりこれもズレているため同じくBADが出るまでPOORが出ます。

そして3つ目や4つ目以降のオブジェも同じく前のオブジェを判定してしまうため、
結果的に連続オブジェが終了するまでPOORやBADが続き、いくら頑張ってもGOOD以上の判定になることはありません。
AC版では恐らくこれがBAD嵌りに繋がる仕様なのではないかと思います。

現状はこの空POOR範囲を狭くすることで、連続オブジェで前の判定が残っているオブジェがあったとしても、
すぐに範囲外になるため連続ミスにならないようになっています。

ちなみにAC版の空POORについては、これとはまた別な処理を行っているような感じがします。
例えば1つのオブジェが降ってくるとして、これを判定が入る少し手前から連打してみると、
そこからずっとPOORが連続で発生すると思います。
まだ判定バーより手前(上にある状態)であれば、こちらのゲームと同じくPOORなりBADが発生しますので挙動は似ていると思いますが、
違いはオブジェが過ぎたあと既にオブジェは存在していないはずなのに、ある一定時間POORが出る時間が存在することです。

これはボタン押下1回目でGREATを出した場合でも同じで、そこからすぐに連続でボタンを連打すると
その後は空POORが何度も発生するのが確認できます。
(もっと簡単な例では、1つのオブジェに2回パチパチっとボタンを押してみればPKGREAT→POORが見れます)

これはつまり、POOR判定だけはオブジェの判定が終わった後も続いているということだと思いますが、
同じ挙動を実装するとなると現状は難しいかと思います。
この辺りも含め、もしAC版の内部仕様をご存知でしたら詳しく教えていただければ助かります。

そこで代案ですが、密集地帯をとりあえず全部押せば突破出来るというのは、
恐らくGREATなりGOODの範囲が広いからではないかと思われます。
ですのでGOOD以上のトータル判定時間を減らし、その分BADやPOORを増やすことで調整出来るのではないかと思います。

 ○現状の設定は以下の通り(PKGREATの真ん中を判定の中心とする)
  −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
      ←未判定|POOR|BAD|GOOD|GREAT|<PKGREAT>|GREAT|GOOD|BAD|POOR|未判定→
  −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
   判定範囲の時間
    PKGREAT : 約38ms
    GREAT : 約48ms
    GOOD : 約83ms
    BAD : 約33ms
    POOR : 約50ms
    ※現在はPC遅延を考慮して若干ゆるい設定にしています
     (例えば30fpsしか出ないPCでは1フレームが33msとなりPKGREATを出しにくいため)




次に#LNOBJですが、認識に間違い無いということで安心しました。
いろいろ調べていただいたようでお疲れ様です。

まとめますと以下のような感じでしょうか。
 @10、20番チャンネルでは終端として使用(本来の#LNOBJの仕様通り)
 A50、60番チャンネルでは#LNOBJは無視され、常に2つの組で開始と終端を定義(50、60番チャンネルの仕様通り)
 Bそれ以外は基本的に記述ミスとしてエラー扱い
  ・10、20番と50、60番チャンネルで開始と終端が混在した場合
  ・10、20番で#LNOBJのオブジェを開始位置に配置した場合(そもそも#LNOBJは「終端」のはず)
 C10、20番で定義したロングと50、60番で定義したロングがかぶっている場合は自動補正(ワーニング出力)
  ・最終的にデータを整理する時に、ロング内にオブジェがあったりすると現状自動的に削除されるが、
   同じくロング内にロングがあった場合も削除して整合性を取る(本来はエラーだが既に機能があるので)

ひとまずこれなら実装は出来るかと思います。

なおcharatbeatHDXの独自機能として開始と終端のオブジェIDが異なる場合は、終端成功時にその音が鳴るという仕様がありますが、
これは10、20番チャンネルには適用しないという形にしたいと思います。

あと50、60番チャンネルで#LNOBJのオブジェが指定されている場合は鳴らしてもよい気がしますが、
#LNOBJは#WAVのIDを特殊な用途に変化させるというというイメージなので、
いっそのこと#LNOBJのIDの音は常に鳴らさないと統一した方が分かりやすくてよいかなと思います。
(例えば10番台チャンネルで#LNOBJを使ってロングを定義したとして、
 これをそのまま50番台チャンネルに移動しても#LNOBJにより終端の音は出なくなるため、
 結果的に10番だろうが50番だろうが同じ動作になるという利点がある)

このような仕様で問題が無いか、精査していただければと思います。
タイトル
記事No
投稿日
投稿者
参照先
Re^2: 新機能要望
451
: 2014/09/17(Wed) 09:25:20
桐山

返答ありがとうございます。

フローティングハイスピードについて、
何か企画されているということで、楽しみに待っていたいと思います。

空POORについて、
まず導入するメリットは本家環境に近くなるという点です。
空POORがない現状では、同じような難易度の譜面でのゲージ維持やミスカウントやクリアが
本家プレイの参考に全くならないほどにCharatbeatHDXのほうが簡単になってます。
また、空POORが無いために滅茶苦茶に押してもミスが少ないことで
見切れない譜面を見切ろうとして押すよりもテキトーに全押ししてるほうがミスが少なくなる現状は、
上達段階での上達の実感(ミスの減少やゲージの維持)を損なうことになります。
次に
>例えば連続オブジェにて、最初の1つをミスるとそれ以降も全てミスになってしまうといった不具合が発生します。
について、空POOR実装と特に関係のないことだと思いましたが詳しい説明をお願いします。
仮に連続オブジェの最初のオブジェを故意に早押し空POORを出した場合でも、
最初のオブジェの判定は残ってるため、見た目どおりの判定でプレイでき、ハマるとは思えません。
判定が消えて、目標となるオブジェが次のオブジェに移るBADハマりのほうが圧倒的に強いと思います。
実装については、既に非常に狭い範囲で空POORが実装されてますが、これの範囲を広げるだけではいけないのでしょうか?

#LNOBJについて、
>「ロングではないチャンネル(50、60番台ではなく10、20番台)にてロングを定義できる機能」
これで間違いないです。
現状の仕様についてBMSE1.3.8とuBMplayでいろいろ試してみた結果を書きます。

----ここから試行の条件と結果----
02→#wav02、10番台
03→#wav03、10番台、#LNOBJ宣言
緑02→#wav02、50番台
緑03→#wav03、50番台、#LNOBJ宣言

始点位置:譜面開始直後、そのレーンの最初のオブジェ、又はロング終端後最初のオブジェ
終点後:#wav02(10番台)を配置

始点-終点:結果
02-02:通常オブジェ2つ
02-03:ロング1つ
02-緑02:通常オブジェ1つ、終点と終点後のロング1つ
02-緑03:ロング1つ
03-02:通常オブジェ2つ
03-03:ロング1つ
03-緑02:通常オブジェ1つ、終点と終点後のロング1つ
03-緑03:ロング1つ
緑02-02:ロング1つ
緑02-03:ロング1つ
緑02-緑02:ロング1つ
緑02-緑03:ロング1つ
緑03-02:ロング終端だけのようなオブジェ2つ、始点の判定瞬間に終点のオブジェが表示判定共に消失
緑03-03:上同
緑03-緑02:上同
緑03-緑03:上同
----ここまで試行の条件と結果----

50番台と#LNOBJを同一のオブジェで扱うと、
50番台で「次のオブジェまでのロングになる」動作と
#LNOBJで「前のオブジェからのロングの終端になる」動作が合わさって
挙動が変になるようです。
本来の使い方以外の配置の仕様については多少変わってもあまり問題ないと思います。


以上です。検討よろしくお願いします。
タイトル
記事No
投稿日
投稿者
参照先
Re: 新機能要望
450
: 2014/09/15(Mon) 12:55:32
管理人

いつも遊んでいただきありがとうございます。

さて要望についてですが、まずフローティングについては現在スキン仕様側にて対応を考えており、
スキン対応時に何かしら実装されるかと思います。
※ちなみにスキンは単に画像を差し替えるだけではなく、スクリプトによりプログラマブルな仕様となるため、
 これにより自由にフローティングスピードの値を変更出来る形になる予定です

次に空POORですが、これを入れることによるメリットとは何でしょうか?
AC版では80%ぴったりでクリアすることで曲が解禁されるということで、
わざとPOORを出して調整するといった裏技があったと思いますが、
このゲームは特にそれを行っても何も起こりません。
また現状の状況ですが、過去記事と同様にエンジンレベルで対応していないため、
組み込みによるデメリットの方が増えるとなると本末転倒になるかと思います。
例えば連続オブジェにて、最初の1つをミスるとそれ以降も全てミスになってしまうといった不具合が発生します。
※実は現在のゲームでも判定位置からある程度ズレたところで叩くと空POORが発生しますが、
 この範囲は設定上かなり狭くなっているため、オブジェがそれ以上前だったり後だったりすると判定しないようになっています。
 つまり何も無い箇所で叩くと判定はされず、音だけが出るという空打ちが出来るようになっています。

最後に#LNOBJに関してですが、実はあまり仕様を分かっていないのが正直なところですが、
これは「ロングではないチャンネル(50、60番台ではなく10、20番台)にてロングを定義できる機能」と理解しておりますが、
間違いはありますでしょうか?
この時もし50、60番台でロングが定義されていた場合、無視されるのかこれもやはりロングとして読まれるのか、
また50、60番台で#LNOBJのオブジェクトが配置されていた場合はどうなるのかなど、
この辺りの詳しい仕様を教えていただければ対応可能かもしれません。
(調べてもたいてい終端を定義するとしか書かれてないため、詳細が分からないと間違った実装をしてしまう恐れがあります)
タイトル
記事No
投稿日
投稿者
参照先
新機能要望
449
: 2014/09/09(Tue) 21:55:28
桐山

charatbeatHDXで楽しく遊ばせていただいてます。
下記機能を追加していただきたく、検討よろしくお願いします。

・フローティングスピード(過去の書き込みにもありましたが、特に欲しいので
・空POOR実装
・#LNOBJで指定されたLNオブジェクトへの対応
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |

- WebForum -