Bug speedwalk rooms touching

[Jieiku]

Brief summary of issue / Description of requested feature:

I had noticed this bug on the OPEN Area Continent maps several times(where all rooms are touching), but did not realize the reason it happens.

I noticed it in a few areas I was mapping where I decided to have rooms touching, size 10 touching side by side.

I noticed that the pathing stops short of where it actually needs to go, it assumes because the rooms are touching borders that it has finished the speedwalk.

Steps to reproduce the issue / Reasons for adding feature:

In an area just have rooms touching borders and then try double clicking the room to see how it paths to it, then make them not touch, and the pathing works correctly.

Here is an image to illustrate:

[Jieiku]

Also to add to this, decreasing the room size when rooms are this close works, but you have to decrease the room size down to 7 before the bug goes away.... its very interesting to say the least. without looking at the code I cannot imagine why this happens. Hope this is not too difficult to Fix, I use room size 10, and I LOVE the way room size 10 looks, so this bug makes me sad :(

[SlySven]

At a guess I would say that the code that determines the room nearest to the position of the mouse click probably has a slight offset and that is messing up for rooms that are adjacent. There are a couple of things that spring to mind:

• there could be some maths going on that produces a fractional result (double type) but is being stored or compared to int values and things are not being qRound(...)ed before being compared.
• somewhat related - double or float values are being tested with an == comparison - which is never a good idea!

💡 Take a look in, let me think, T2DMap::paintEvent(...) at the three bits of code that begin with a complicated ìf:

        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)) {

The member (QPoint) T2DMap::mPHighligtht is set to the x/y coordinates where the double click event occurred in a preceding call to T2DMap::mouseDoubleClickEvent(...) so I think you will want to check the limits that are being used to check that a room is within the range of the double click.

One thing you will want to check is if the error is symmetrical - i.e. happens equally on either side and also equally above and below - if so then the limits may just need shrinking; if NOT then there is coding problem. note that some of those values involved in the calculation are, I think float or double and not int types, and that the y axis is inverted (IIRC) for the 2D mapper...

[Jieiku]

You must be right. Also after a restart of mudlet I can no longer reproduce the error and I am in the exact same area as I was earlier. Earlier it was doing it every single time, and was easily reproduced and now I cannot get it to do it at all. So its almost like something got buggy then fixed after a restart of mudlet.

Next time this bug presents itself, I will try calling gotoRoom() and see if that is affected as well or just the double clicking.

[Jieiku]

Update, I think you nailed it @SlySven The bug resurfaced for me today while mapping. I could try pathing to the room repeatedly with double clicking and it kept bugging. However once I used lua gotoRoom(23979) it pathed to the room correctly.

[SlySven]

For four (or even eight if we are concerned about the diagonals) rooms set around the target does this mis-selection happen evenly around the target?

Also, it could be that it depends on the sequence in which the rooms are drawn if there is an overlap in the region for each potential room (the first room that is drawn that is in range will trip the speed walk process) - and as we are iterating through a QSet for this the order is indeterminate...

{For debugging purposes it might be informative to use the room Id display option to instead display the room drawing order - with a counter incremented after each room is iterated through and reset at the start of each T2DMap::paintEvent() 🤓 }

[Jieiku]

it does NOT happen evenly around the target, for instance if I purposely stick a handful of rooms close together, some of them I can double click and move to, others it just stays put as if I am already at my destination:

actual layout:

clumped some rooms together:

with size 10/10 it was very easy to immediately reproduce, it seems like your on to something with them overlapping differently depending on drawn order, because with them clumped like that some neighboring rooms would walk to and others would not, also I could see on double click the room that it flashed with the red target, and it was incorrect, indicating that the overlap is indeed affecting it.

does this mean that the clickable surface of rooms extends beyond the rooms box? I do not understand why this would happen... I am carefully clicking the middle of the room when this happens.

[SlySven]

does this mean that the clickable surface of rooms extends beyond the rooms box? I do not understand why this would happen... I am carefully clicking the middle of the room when this happens.

That would be my guess - I strongly suspect there are faults in those if tests I referred to previously - (and the drawing order is probably compounding it as well - which would not be an issue if the selection areas were accurately evaluated)... 😟

[Jieiku]

Found out today while mapping that clicking a room on a boundary of an area, can sometimes take you out of the area, so the issue extends to rooms in another area.

[SlySven]

See my fix for this - and I too have just found the speedwalk to room in the other area feature - which actually is as intended (at least when grid mode is turned off! 😜)

[Jieiku]

See my fix for this - and I too have just found the speedwalk to room in the other area feature - which actually is as intended (at least when grid mode is turned off! stuck_out_tongue_winking_eye)

THAT IS AWESOME! Also My gridmode does not actually use gridmode, hahahaha. So I guess I get to make use of that awesome feature. in my mapper I use an offset of 2 in x,y for most rooms and an offset of 1 in continents (where im wanting the grid appearance, with a room size of 10/10, this looks really good and has a pleasing look to it for Area entrances.)

Thank you so much for fixing this SlySven!