Bug 4.0.5, Target Cursor

[Tibarius]

Just tried to use 4.0.5 windows version.

Bug: The target cursor does not highlight the actual targetted monster but instead is somewhere located on the bottom section of the main window.

Correct Behavior: The target cursor should highlight the actual targetted monster.

Ocurrence: Always (so it should be easy to re-produce the bug). I switched two birth options (sell for gold and no usefull starting kit). UI-Options: Use old target by default and highlight target with cursor.

This leaves 4.0.5 unplayable for me ... *sigh*.

[Nick]

Yeah, this is a known bug - x and y mixed up in cursor position, I believe

[mrfy]

Same bug in the macos version, but it's definitely not unplayable. it's just a display bug, doesn't affect game play.

[bart9h]

Same bug on Linux, using either the SDL or the X11 frontend. Seems like it's not system-dependent. It's annoying, but definitely not unplayable. The actual cursor is on the right place, it's just displayed on the wrong place. I tried the latest git version, and it's still there. Please fix this! k tx by

[t4nk]

line 369 of ui-game.c:

        move_cursor_relative(player->px, player->py);

Looks pretty innocent, right? But someone - who that was? - decided to use backwards order for coordinates (y, x) throughout the whole textui. Besides, pre_turn_refresh() should check for OPT(show_target)... I think... I sent a patch, it seems to work I didn't do a lot of testing.
Anyway, whose idea was to use y, x order? It's just super annoying. Was it Ben Harrison? I remember in school we always used x, y coordinates - in this particular order; x first, y second. Is this different in different countries or what? Now Angband sometimes uses x, y, sometimes y, x, which is very error prone. I considered normalizing all that (to x, y) in new textui... I'll probably have to do it.

[Derakon]

Anyway, whose idea was to use y, x order? It's just super annoying. Was it Ben Harrison? I remember in school we always used x, y coordinates - in this particular order; x first, y second. Is this different in different countries or what? Now Angband sometimes uses x, y, sometimes y, x, which is very error prone. I considered normalizing all that (to x, y) in new textui... I'll probably have to do it.

It is unfortunately semi-common (not just in Angband) to specify coordinates as (row, column), which works out to (y, x). I agree with you that it's super annoying, and if I knew who introduced it to Angband I'd probably want to chew them out (or at least ask why), but it's been like that for ages. Ben Harrison or earlier, I think.

[Pete Mack]

(y,x) goes all the way back to rogue, and primitive green-screen terminals, where (col, row) was a common form.

[t4nk]

Funny stuff... consider ui-target.c. Why does pathfinder work (press 't', navigate to a square, press 'g' and go there) when targeter does:

    case 'g':
        cmd_set_arg_point(cmdq_peek(), "point", y, x);

How does that work when cmd_set_arg_point() takes x, y? Because do_cmd_pathfind() does:

    /* XXX-AS Add better arg checking */
    cmd_get_arg_point(cmd, "point", &x, &y);
    ...
    if (findpath(x, y)) {
    ....

and, of course, findpath()...

bool findpath(int y, int x)

I guess I'll have to leave the y, x stuff as it is, "fixing" it will just wreck the game at this point

[AnonymousHero]

Now Angband sometimes uses x, y, sometimes y, x, which is very error prone. I considered normalizing all that (to x, y) in new textui... I'll probably have to do it.

If you're going to do anything about this, might I suggest introducing a "struct point { int x, int y}" instead? In most places, coordinates (x,y) aren't actually plucked out of thin air, but rather come from somewhere else, e.g. monster coordinates, object coordinates, player coordinates. In those cases, the relevant structs should just have a "point" embedded in them instead of separate (x, y) coordinates.

EDIT: If you want a less "noisy" method than struct-initialization for creating coordinates out of thin air you could always introduce a function: "point make_point(int x, int y)".

[kandrc]

It's older than Rogue. It's part of curses (which Rogue used). And curses does in that way because terminals do it that way. And terminals do it that way because Indo-European languages (and specifically English) do it that way (i.e., of course indexing characters is not part of English, but when we need to refer to letters in text, it's far more sensible to talk about a line before an offset).

Long argument short, long historical precedent suggests that if you're using (x,y) when dealing with text or text-based stuff, you're doing it wrong.

[kandrc]

It works because there are (apparently) two bugs in the listed code, and they cancel each other out.

Funny stuff... consider ui-target.c. Why does pathfinder work (press 't', navigate to a square, press 'g' and go there) when targeter does:

    case 'g':
        cmd_set_arg_point(cmdq_peek(), "point", y, x);

How does that work when cmd_set_arg_point() takes x, y? Because do_cmd_pathfind() does:

    /* XXX-AS Add better arg checking */
    cmd_get_arg_point(cmd, "point", &x, &y);
    ...
    if (findpath(x, y)) {
    ....

and, of course, findpath()...

bool findpath(int y, int x)

I guess I'll have to leave the y, x stuff as it is, "fixing" it will just wreck the game at this point

[t4nk]

It works because

I thought I already explaned why it works

[t4nk]

If you're going to do anything about this, might I suggest introducing a "struct point { int x, int y}" instead?

After some thinking I decided to do exactly that. Thank you! Angband actually already has "struct loc". Hopefully that will make the ui a little less bug prone...