重なったときにY座標を比較して０番が大きかったら下から当たった、そうじゃなければ上から当たったみたいに判断してみるとか？ まあ移動量が大きすぎると失敗するけど、その場合はさらに移動量も考慮するとか色々条件を増やすしかないかとー

マップエディタは確かに更新データの際にエラーが出る時期がありましたねー…。せっかく見つけてもらったのに使えない時で残念です…。 今は不具合報告を聞くことはないのでとりあえずはちゃんと動いているみたいですし、機会があったらまた使ってみてください〜。

PUCHI LAUNCH、デフォルトで設定されているのはスマイルメニューだけですね…。 デフォルトで何を設定して欲しいですか？　各種スマイルツールなのかな？

くろねんどさんの意見を参考に人気のないツールは廃止、もしくは統合を検討しています。 ただ全部は厳しい（というか需要ない）し、ランチャーなどは軽さを優先してるんで、その辺もふまえての調整になると思います。

ランチャーとマップと言うことで、やっぱりこの２大人気なんだなぁ、っと参考になりました。ありがとうございます！ 愛用してもらえて嬉しいです。これからもよろしくお願いします！ ＞Rwiiugさん 設定ですか〜。デフォルトの設定ってなかったですかね…。もう古くて覚えてないや…。ただランチャーなので設定（使うもの）が固定化出来ないのもネックですね。 今度アップデートする際は参考にします。ご意見ありがとうございました！ ＞ZEXさん

全部！？　嬉しいです〜！ 改善点とか要望は気づいたときでいいんで気楽に言ってくださいね〜。これからもよろしくお願いします！ ＞つばさ☆さん 公式ツールはなかなか対応してくれませんからねー…。苦労して作ったのでマップの利用者が居て嬉しいです。マップはもうちょっとバージョンアップしたい点もあるんですが需要が微妙に低いのでなかかな手つかずです…。 ＞あきとさん

まげさんも愛用してくれていたんですね。嬉しいです！ そういえばプチコンのバージョンアップでサウンド停止命令が出来たんですよね！　その辺も対応せねば！　ということでそれは採用です！笑 今後ともよろしくお願いします！ ＞まげさん 全部合体したら無駄に重くなるというかランチャーは軽い方が良いでしょうしねー…。LRですか〜。なかなか悩ましい問題ですね…。良い代案があればいいのですが…。でも意見ありがとうございます！ ＞くろねんどさん

コメントありがとうございます！　個別のコメントはこの後でということで、とりあえず全体的にはやっぱりランチャーが人気があって時点がマップ？って感じですかね〜。 LOADERとかSAVERも地味に便利だと思うんですが、プチコンのバージョンアップでその辺改善されてきてるので必要性が下がってしまった感じですかねぇ…。

結局NEXTは内側から閉じないと意味がないので制御変数があろうがなかろうが問題ないんでしょうね〜

セーブというのはプログラムのことですか？　それともゲーム中のデータ（変数）のことですか？ どのぐらいわかっているのかにもよるんで、知ってることは出来るだけ書くと回答がもらえやすいと思いますよ〜。

お久しぶりです！ 僕はPUCHIシリーズという開発系のツールを作っていますが、それが今では利用されているのかどうかちょっと気になってます。なのでミニミニアンケートです！ もし今でも使ってくれているツールがあったら教えてください。全部使ってるというのが一番嬉しいけど１つでもOKです、笑 また知らなかった！とかツールに対する要望とかアンケートに限らずPUCHIシリーズに関する意見ならなんでもOKなので知りたいです。 アンケートの回答は、今後の機能追加やバージョンアップの優先度などの参考にさせてもらおうと思っています。というかその為のアンケートだったりします…。 という感じなので、もし使っている人がいたら是非是非コメントよろしくお願いします！

プチコン自体はゲームじゃないので、面白いかどうかは個人の力量によりますね〜。という事で、とりあえず楽しみたいなら公開キー！

一応。 BGのない場所という意味では0番ならないとも言える。 そして普通はタッチ対象としてはスプライトなりテキストなりグラフィックなりでボタンとか描いて判定する事が多い。で、スプライトなら一発で判定する命令があるけどテキストとかグラフィックだと文字とか色とか一部しか判定できないので、大体は座標で判定する事が多いような気がする。 ということもふまえて、何でどうするか考えると良いでしょう。

なぜいっぱいおくひつようがあるんだろう…

0じゃないときに以前の値（Y）に戻しているみたいなので、それは正しい動作じゃないんですか？

一つのやり方のヒントの断片だけ。別にこの方法が唯一でもないです。 DIM EF[8] IF EX[I] == -100 THEN 〜 EF[I] = 0(またはFALSE) ENDIF IF EX[I] < X && !EF[I] THEN SCORE=SCORE+1 EF[I] = 1(またはTRUE) ENDIF

やっぱり原因はそうですよね。 ということでもうちょっと根本的に改善しないと駄目かもしれませんが、一番簡単なのは敵にもう一つ飛び越えたかどうかのフラグ用の変数を持たせて、それで判定を重複させないのが手っ取り早いんじゃないかなと言う気がしますね。

なんとなく気づいたのは、その増えない時って自分も移動しながら飛び越した時じゃないですか？　止まってジャンプしている時は必ず増えるなら原因としては特定出来た感じですが、今の自分の移動量っていくつになってるんですかね？

とりあえずIF分ですが、僕が見た感じでは、 IF X < EX[I]+ES[I] && X >= EX[I] THEN のような気がする。つまりEX[I] + ES[I]は以前の座標になるはずなので、前の座標が自分より前で、今の座標が自分より後ろなら飛び越えたって感じね。 IF時のかつのアンドはANDより＆＆の方が理解せずに利用した際の誤動作が少ないと思うので＆＆の方がオススメです。

sayさんのプログラムを試したときにはFORループの問題もあって直らなかったからよくわからなく感じていたみたいですねー。 とりあえずうまくいって良かったです。これからも頑張ってください〜。