Arrow drawing bug- unnecessary horizontal line being drawn

[FrostionAAA]

I installed “triplea_windows-x64_1.9.0.0.2728.exe”.

I don’t have any other versions installed at the moment, so this version is where can see the bug, but I don’t know if it is an older bug. It is also present and can be reproduced in the tutorial map.

The short version:
If a units moves from one place to another, generating an arrorw, and both ends of the arrow can be displayed inside the viewable area, then everything is OK.

But if one of the ends of the arrow is outside the viewable area in the west/left direction, then the end of the arrow in that direction is moved to a far-right/far-east destination.

It seems that it does not matter if it is the pointy or round end of the arrow that gets hidden from view, the error is the same.

I made a screen recording of the bug to supplement these pictures. (8 MB, MP4)
Showing is so much easier then telling :-)
https://dl.dropboxusercontent.com/u/91867373/ArrowBug.mp4

Before the left side of arrow is hidden, all is good:

After hiding the left side, the arrow bug is seen:

[ron-murhammer]

@FrostionAAA Yeah, I noticed this as well. We'll need to fix this.

[RoiEXLab]

I hate Math for this particular case...
The Problem is clear to me as I was working on the "new" Arrow/Path UI...
On infinite-scrolling Maps the Point Coordinates are not the same like the screen coordinates, e.g. a USA in the east has the same Map-Coordinates as the same USA in the west, but the Screen coordinates differ.
In order to have a straight line between coordinates unlike #863 I implemented a system which "corrects" the screen coordinates if the map coordinate is off-screen...
The Route is not coming from nowhere, it's actually coming from the same map-coordinate, but a different screen coordinate, the one in the east.

@DanVanAtta @ron-murhammer
If you may have a look at RouteDrawer.java, you may notice that this correction is done for all points each...
If you have any theoretical ideas on how to solve this, please let me know...

[ron-murhammer]

@RoiEXLab Would it be possible to write a unit test that fails because of this issue?

[DanVanAtta]

@ron-murhammer I am concerned that we will not be able to catch this bug via unit test effectively without some major work. A patch fix would be good here if it allows for this feature to catch the 1.9 train. Otherwise we're at about at point where features that fail get Q/A are going to be reverted, instead of being patched. We need to get 1.9 out.

edit we're about at the point where we should revert instead of patch, not necessarily there yet.

[ron-murhammer]

@DanVanAtta Agree and I'm fine reverting the route draw changes if necessary.

[RoiEXLab]

@DanVanAtta @ron-murhammer
A fix wouldn't be too hard... The only thing I'm struggling with is what exactly to check...
How does the left point differ from the right one?
Is it nearer to to middle of the screen? Is it nearer to the next point (if so, what is the next point)?

[RoiEXLab]

I'll try to get a PR out today...

[RoiEXLab]

#1065 has a fix

[RoiEXLab]

This should be fixed now, please close the issue then

[RuinChristmas]

is this the same issue?

[RoiEXLab]

No it's not, but somewhat related... This happens very rarely to me, and when it does I cannot reproduce it. This has a lower priority... But I will see what I can do once I'm back home

[RuinChristmas]

@Roi if you play revised, set the other players to AI and move the fighter
like that I think it always happens

On Aug 29, 2016 10:51 AM, "RoiEX" notifications@github.com wrote:

No it's not, but somewhat related... This happens very rarely to me, and
when it does I cannot reproduce it. This has a lower priority... But I will
see what I can do once I'm back home

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1056 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARAwI1QeniRER-nsEVjzbsZbsfbu0Olxks5qkv_ggaJpZM4Jjq9b
.

[RoiEXLab]

Ok then...
@DanVanAtta @ron-murhammer
If this issue is urgent, the method that is not properly working is the normalize(all)lines method... This Method is supposed to make the lines go through map borders.
I would like to help, but without my PC I'm only half a developer.

[DanVanAtta]

Does not sound like it is terribly urgent. A point fix is going to be acceptable enough. Going forward the key will be to preserve lobby->client compatibility, and save game compatibility.

[Cernelius]

Looks like it is just broken for whatever wrapping path, except maybe the ones wrapping on both axis (I see that "HexGlobe FFA" is fine). Since TripleA maps normally wrap, I'm not sure if this is can be even called an improvement over the stable, all around.

Are you sure you want to release this?

[DanVanAtta]

how common is the problem exactly? is it just the one rare path??

@RoiEXLab , thoughts on how to fix?

[DanVanAtta]

looks whenever there is a route from the left of the map seam going to the right of it, the direction is reversed.

Should be an easy enough of a fix it looks, once we spot where the problem is.

[Cernelius]

Sorry, just noticed that the problem exists for HexGlobe FFA too, on the X axis; just not on the Y axis.

So, I guess the only wrapping maps that would be unaffected would be those with Y only (not X) scrolling.

I suggest you use HexGlobe FFA as the main referring game for this issue.

[DanVanAtta]

#1199 has a fix for the horizontal case. On hexglobe, it looked like things were fine, but I would not be 100% surprised if the vertical case had issues.

[RuinChristmas]

It works now if you go directly there but if you move a fighter from hawaii towards china, then wait, decide you want it in ECan, you get this:

If you go around the world, in 1.8.0.9, it draws a neat arrow but now does this:

[Cernelius]

I confirm what Ruin says.

There is something serious bugging off when you select an unit and go around with the mouse to possible destinations (nobody else but this: not clicking anything else but the initial selection of the unit), and it happens even if you never actually try to wrap around a border.

For example, here the Yamamoto submarine seems convinced that the best way of going to an adjacent sea zone (I didn't set any path with Ctrl or anything) is by going 24 times around the world:

I surmise that you need to make sure that the path is given at any time regardless of what paths were given in the past, as it seems the previous ones somewhat influence the current one for no reasons.
In the above case, I obtain that if I previously go around with the mouse, while it doesn't happen if I only move it from the starting to the ending sea zone.
It looks like the previous paths leak into the new ones.

[RoiEXLab]

@DanVanAtta what have you done? You created a monster!
I'd suggest reverting your fix + my cleanup PR in order to create a new, better fix

[ron-murhammer]

Yeah, this I think is the only showstopper bug we have left.

[DanVanAtta]

@RoiEXLab , please double check which updates introduced this. The update I applied a week ago made the problem a lot less likely.

[DanVanAtta]

@Cernelius , from which SZ is the sub in? I was not able to repro.

I've only been able to reproduce when the unit is very far from the map 'seam'. Which is a rare thing. @ron-murhammer , we can fix this in a point release since no game data is involved. Hence I do not think it is a show stopper.

[RoiEXLab]

@DanVanAtta Sorry, if I'm wrong at some point...
AFAIK There was this "small" bug which had this single line in some cases. I think the bug seen now is the result of #1199

[DanVanAtta]

"this single line in some cases"

Which single line? Which "small" bug?

[RoiEXLab]

@DanVanAtta I mean the Screenshot sent by @RuinChristmas

[DanVanAtta]

I was able to repro the screenshot from @RuinChristmas . That was a problem before #1199. The move in that screenshot is not a valid move. Hence, this issue AFAIK is going to be pretty rare to hit. I'm concerned by Cernel's report that he can hit it with movement to an adjacent territory (which I have not been able to repro, hoping for some more info)

[DanVanAtta]

@Cernelius can you give details on how you were able to get the screenshot above, which SZ was the sub in to start with? I put a sub in every pac SZ in that region and could not hit the route wrapping problem.

[Cernelius]

Of course, I'm using the latest prerelease (3154).

As I said, it is a thing that sums up, so I cannot reproduce it exactly as before, unless I like make the same moves, I guess.

Just select the submarine and move the mouse around (nothing else!); you should soon see horizontal lines piling and piling up in a neverending stream of red spaghetti.

It always happens in a different way, like:

or:

And, yes, never happened with the current release.

[DanVanAtta]

Still, not seeing it. Please give step by step instructions if you would @Cernelius . Which SZ is the sub in?

[DanVanAtta]

Okay, hit it. Looks like first you have to move the mouse cursor and route to be very far away, scrolling around the map. Once triggered, adjacent territories no longer have their routes drawn correctly.

[Cernelius]

Ah yeah, forgot to say that the map was zoomed 50% (as you can see). You are unlikely to hit it if that one is at 100%, I guess, but it is quite easy at 50%.

[Cernelius]

And, yes, it starts from a move somewhere illegal, and then it continues when you go legal, but this is quite easy to hit in WAW at 50%, because you hit the islands or the borders that are a "none" spot; I don't really know which one of the two causes it.
The more you move around, the more they sum up.