Mudlet: バグスピードウォークルームに触れる

作成日 2019年04月02日  ·  10コメント  ·  ソース: Mudlet/Mudlet

問題の簡単な要約/要求された機能の説明:

OPEN Area Continentマップ(すべての部屋が接触している場所)でこのバグに何度か気づきましたが、その理由に気づきませんでした。

私がマッピングしていたいくつかの領域で、部屋を接触させ、サイズ10を並べて接触させることにしたことに気づきました。

経路が実際に行く必要のある場所の手前で止まっていることに気づきました。部屋が境界に触れているため、スピードウォークが終了したと想定しています。

問題を再現する手順/機能を追加する理由:

エリアでは、部屋が境界線に接触しているだけで、部屋をダブルクリックして、部屋がどのようにパスするかを確認してから、それらが接触しないようにします。パスは正しく機能します。

説明する画像は次のとおりです。

bug-pathing

bug medium

最も参考になるコメント

これに対する私の修正を参照してください-そして私も他のエリア機能の部屋へのスピードウォークを見つけました-これは実際には意図したとおりです(少なくともグリッドモードがオフになっているとき!:stuck_out_tongue_winking_eye :)

全てのコメント10件

また、これに加えて、部屋がこれほど近くにあるときに部屋のサイズを小さくすることは機能しますが、バグがなくなる前に部屋のサイズを7に減らす必要があります....控えめに言っても非常に興味深いです。 コードを見ないと、なぜこれが起こるのか想像できません。 これを修正するのがそれほど難しくないことを願っています。私は部屋のサイズ10を使用し、部屋のサイズ10の外観が大好きなので、このバグは私を悲しくさせます:(

推測では、マウスクリックの位置に最も近い部屋を決定するコードには、おそらくわずかなオフセットがあり、隣接する部屋を台無しにしていると言えます。 頭に浮かぶことがいくつかあります。

  • 小数の結果( double型)を生成するいくつかの計算が行われている可能性がありますが、保存されているか、 int値と比較されており、 qRound( ... )比較される前に
  • やや関連している- doubleまたはfloat値は==比較でテストされています-これは決して良い考えではあり

:bulb:複雑なìfで始まる3ビットのコードをT2DMap::paintEvent(...)で見てみましょう:

        if (((mPick || __Pick) && mPHighlight.x() >= roomRectangle.x() - (mRoomWidth * rSize) && mPHighlight.x() <= roomRectangle.x() + (mRoomWidth * rSize)
             && mPHighlight.y() >= roomRectangle.y() - (mRoomHeight * rSize)
             && mPHighlight.y() <= roomRectangle.y() + (mRoomHeight * rSize))
            || mMultiSelectionSet.contains(currentAreaRoom)) {

メンバー(QPoint) T2DMap::mPHighligthtは、前のT2DMap::mouseDoubleClickEvent(...)呼び出しでダブルクリックイベントが発生したx / y座標に設定されているため、それを確認するために使用されている制限を確認する必要があると思います。部屋はダブルクリックの範囲内にあります。

確認したいことの1つは、エラーが対称的であるかどうかです。つまり、どちらの側でも同じように発生し、上下でも同じように発生します。そうであれば、制限を縮小する必要があります。 そうでない場合は、コーディングの問題があります。 計算に関与するそれらの値のメモその一部であり、私が考えるfloatまたはdoubleとしないintタイプ、およびy軸が反転していること(IIRC)2 Dマッパー...

あなたは正しいに違いない。 また、マッドレットを再起動した後、エラーを再現できなくなり、以前とまったく同じエリアにいます。 以前は毎回やっていて、簡単に再現できて、今は全然できません。 つまり、マッドレットを再起動した後、何かがバグを起こし、修正されたようなものです。

次回このバグが発生したときは、gotoRoom()を呼び出して、それが影響を受けるかどうか、またはダブルクリックするだけかどうかを確認します。

更新、あなたはそれを釘付けにしたと思います@SlySvenマッピング中にバグが今日私のために再浮上しました。 ダブルクリックして部屋へのパスを繰り返し試すことができましたが、バグが続きました。 ただし、 lua gotoRoom(23979)を使用すると、部屋に正しくパスされました。

ターゲットの周囲に設定された4つ(または対角線が心配な場合は8つ)の部屋の場合、この誤った選択はターゲットの周囲で均等に発生しますか?

また、各潜在的な部屋の領域にオーバーラップがある場合、部屋が描画される順序に依存する可能性があります(範囲内にある最初に描画された部屋はスピードウォークプロセスをトリップします)-そしてQSetを繰り返し処理しているため、順序は不確定です...

{デバッグの目的で、部屋ID表示オプションを使用して、代わりに部屋の描画順序を表示することをお勧めします。各部屋が繰り返され、各T2DMap::paintEvent()の開始時にリセットされると、カウンターがインクリメントされます:nerd_face:}

ターゲットの周囲で均等に発生するわけではありません。たとえば、意図的にいくつかの部屋を近づけた場合、ダブルクリックして移動できる部屋もあれば、目的地にいるように配置されたままの部屋もあります。

実際のレイアウト:
2019-04-04_17-21_1

いくつかの部屋をまとめました:
2019-04-04_17-21

サイズ10/10では、すぐに再現するのがとても簡単で、描かれた順番によって重なり方が違うものになっているようです。隣の部屋が歩いて行くように、他の部屋が歩いて行かないように集まっているので、私も見ることができました。赤いターゲットで点滅した部屋をダブルクリックすると、それは正しくなく、オーバーラップが実際にそれに影響を与えていることを示しています。

これは、部屋のクリック可能な表面が部屋のボックスを超えていることを意味しますか? なぜこれが起こるのかわかりません...これが起こるとき、私は部屋の真ん中を注意深くクリックしています。

これは、部屋のクリック可能な表面が部屋のボックスを超えていることを意味しますか? なぜこれが起こるのかわかりません...これが起こるとき、私は部屋の真ん中を注意深くクリックしています。

それは私の推測です-私は以前に参照したそれらのifテストに欠陥があると強く疑っています-(そして描画順序もおそらくそれを複合しています-選択領域が正確であれば問題にはなりません評価済み)...:心配:

エリアの境界にある部屋をクリックすると、エリアから外れることがあることがマッピング中に今日わかったため、問題は別のエリアの部屋にも及びます。

2019-04-06_01-23

これに対する私の修正を参照してください-そして私も他のエリア機能の部屋へのスピードウォークを見つけました-これは実際には意図したとおりです(少なくともグリッドモードがオフになっているとき!:stuck_out_tongue_winking_eye :)

これに対する私の修正を参照してください-そして私も他のエリア機能の部屋へのスピードウォークを見つけました-これは実際には意図したとおりです(少なくともグリッドモードがオフになっているとき!stuck_out_tongue_winking_eye)

それはすごいね! また、私のグリッドモードは実際にはグリッドモードを使用していません、ハハハハ。 だから私はその素晴らしい機能を利用できるようになると思います。 私のマッパーでは、ほとんどの部屋でx、yで2のオフセットを使用し、大陸で1のオフセットを使用します(部屋のサイズが10/10のグリッドの外観が必要な場合、これは非常に見栄えがよく、見栄えがします。エリア入口用です。)

このSlySvenを修正していただきありがとうございます!

2019-04-07_00-05

このページは役に立ちましたか?
0 / 5 - 0 評価