Mouse playability

[Magnate]

Ouch. Ouch.

So, first, Derakon: I don't think Jeff or Nick was talking about v4, they were talking about the code that is 3.4-dev, which is really quite different from 3.1.x, albeit not hugely different from 3.2.0 or 3.3.x. I can sympathise with Nick's chagrin after spending countless hours upgrading to the 3.1.2v2 codebase only to see signficant further changes. What must be even more galling is that the speed of development is so unpredictable: it was awesome, but then we had almost six months of very little, and who knows when it will pick up again and in what direction.

I think this is the third or fourth time Jeff has written roughly the same rant about how awful V has become since takkaria encouraged people who can be bothered to contribute code, so much doesn't need addressing again. There is no benign dictator willing to devote his/her time to shepherding the devteam, ensuring progress towards a coherent overall vision, etc. Yes, this would be the best situation, but if nobody wants the job we can't help that.

I'm glad Jeff likes the UTF-8 work. I find it absurd that he considers the bitflag work a detriment, by focusing on the cost of converting to it. Its value is in what it opens up afterwards. Whatever you want to do with objects or monsters, you now have a coherent and intuitive set of functions to test and manipulate their flags. You no longer have to think "ooh, do I need TR2_ or TR3_ for this one?" and so on.

The effects rewrite, if I ever do it, will achieve the same result for effects - but it won't help the core/UI split, much. To be fair to rr9, the existing projection code is pretty well ready for the split anyway.

Anyway, I'm really sorry if I've come across as critical of what Nick and Jeff want to do. It wasn't my intention to be anything other than constructive. There are few active coders in the *band world today, and if they're prepared to do the work on UI improvements it's up to those of us who aren't to make the best use of whatever they produce and be grateful for it. I hope that Nick's suggestion of using the current version as the jumping-off point will prevail despite Jeff's reservations.

[Magnate]

When I mentioned Angband 3.4, I was referring to whatever is out there at github under the Master branch. Naturally, I can't quite tell which version it is, because the version number that has been at the top of defines.h for decades is no longer there.

The version number is now given by the command "git describe". This takes the form vX[-foo-Y-gZ] where:

X is the old-style version number (3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0 etc.). If you're actually playing a released version, this should be all it says.

foo is "dev" for pre-release development versions (as in the current v3.4-dev), but it could also be "RC" for release candidate versions (e.g. v3.4-RC1-Y-gZ etc.). Once v3.4.0 is released, the dev versions will immediately become v3.5-dev while a separate 3.4 maintenance branch will eventually become v3.4.1 and so on.

Y is the number of commits since version X was named.

Z is the actual git commit ID of the version you're looking at.

Like a lot of git-related things, this sounds excessively complicated, but it's actually brilliant. It allows us to describe any version with pinpoint accuracy, which is great for bug-hunting.

[Blue Baron]

First of all I am wondering what you think about the mouse support / context menus that I already wrote and are already in 3.4-dev and v4. The game should be entirely playable by mouse except entering numbers. Just make sure mouse_movement is on and right click.

Next, I don't really have the time to implement this any time soon, so I am just giving my thoughts on what has been discussed.


About the CoreUI split: I agree that while a master message queue might be needed for message ordering, it is mostly separate from how the messages are displayed on screen. However I also disagree that the textui functions shoud move to a main file. I think that all of the ports should be able to fall back on to the text ui. So I think there should be be the text ui with port specific overrides for specific interactions.

Anyways, what you do will probably shape the CoreUI split so I think you should implement what you want with that in mind.


About detachable side panels: To me this means the map covering the whole screen with floating (but lockable) subwindows in the main window. Also I think this is best implemented as part of the CoreUI split.


About graphical menus: As I said above, I think there should be be the text ui with port specific overrides for specific interactions. A way to do it might be to add more terminal hooks, and test on use, since they would be optional, unlike the current hooks. For instance, the top of the get_item function could become:

bool get_item(params)
{
    if (Term->get_item_hook)
        return *(Term->get_item_hook)(params);
  ... rest of current function

the hook function could open a graphical menu (decided by the port) and return the id of an item selected or let an existing inventory (or equipment or floor or hotkey bar) window know it is interested in the next selection from it.


About buttons: I don't think buttons should be part of the tile sheet but have "skins" - an image file and a text file that tells a port what area of the image is used for what button or menu element with dimensions in pixels rather than in tile cells.

Also I think text buttons should be able to be be anywhere on screen, not just on the bottom row, so they can be over arbitrary text on the screen (if a prompt includes 'press ESC to exit' a user can click on that section of the prompt and an ESC key press will be put into the key queue.)

I started working on something like this. The initial possible API is at the bottom of button.c. The idea was that a menu function would ask the ui to show a predefined list of buttons, then the function could and and remove from that list. a graphical menu would take that list and rearrange / reinterpret for display the labels of the list (with the list id) as it wants to.

I think graphical buttons needs to be almost entirely in the ports, except for the functions to request information from the core. (Unless ports can access the information directly, like now, but that is less of a split.) (takkaria: I think that if the core does not have the information it needs it should request it from the ui/ports, rather than fail, and uis/ports should be able to request the information they need from the core. either directly or through api functions.)

About zoom mode: in windows you could add additional tests to square_to_pixel and pixel_to_square, as well as the actual size changes to term_pict_win and term_text_win for a consistent look. The SDL port would be harder since SDL doesn't have a stretch and blit function, but this would be an optional command anyways.

[nppangband]

I think this is the third or fourth time Jeff has written roughly the same rant about how awful V has become since takkaria encouraged people who can be bothered to contribute code, so much doesn't need addressing again.

I can fully understand not agreeing with or caring for what I posted or my occasional rants, but I would like to request that statement be acknowledged as a bit off. Only because I don't think Angband is awful and I most certainly haven't singled out Takkaria, his efforts or anyone elses, and I would hate for the impression to be lingering out there. What I do think is that Angband isn't quite Angband any more. It is D_MBand/MagnateBand/FixxixBand/TakkariaBand and many other ***Bands, all rolled up into one. All are fine individual efforts, but because they are all combined together in one place things are getting pretty messy. Also, I think the general roguelike community has moved on to other things, and they aren't coming back unless the UI is improved regardless of the feature changes you all have done.

{snip some bitflags stuff}Whatever you want to do with objects or monsters, you now have a coherent and intuitive set of functions to test and manipulate their flags. You no longer have to think "ooh, do I need TR2_ or TR3_ for this one?" and so on.

Please bear in mind that NPP has many more lines of code that involve flags, since all aspects of terrain are handled by flags as well (some of which uses up alot of processor time, such as re-calculating LOS, lines of movement, movement, and lines of fire every time something changes. Those three things are separate in NPP). So bitflags in NPP would have been a bigger job.

Anyway, I'm really sorry if I've come across as critical of what Nick and Jeff want to do. It wasn't my intention to be anything other than constructive.

My apologies as well. Angband coding is a labor of love for the devs. It is personal for all of us.

[Antoine]

No new dumps this year, despite all the cool features, FA already have.

Presumably many who would have played FA are now playing Sil
A.

[Magnate]

I can fully understand not agreeing with or caring for what I posted or my occasional rants, but I would like to request that statement be acknowledged as a bit off. Only because I don't think Angband is awful and I most certainly haven't singled out Takkaria, his efforts or anyone elses, and I would hate for the impression to be lingering out there. What I do think is that Angband isn't quite Angband any more. It is D_MBand/MagnateBand/FixxixBand/TakkariaBand and many other ***Bands, all rolled up into one. All are fine individual efforts, but because they are all combined together in one place things are getting pretty messy.

Sure. You've said that before, and I don't really disagree with it (I would love there to be a unifying force but there isn't) - it's just that you said it a lot more angrily this time ;-)

I wasn't accusing you of singling out takkaria btw, just noting the start and nature of the period with which you're discontent.

Also, I think the general roguelike community has moved on to other things, and they aren't coming back unless the UI is improved regardless of the feature changes you all have done.

This is a fair cop - the basic problem is that we have no real UI people on the devteam, so it gets neglected. Blubaron has done sterling work though, so I hope you and Nick will build on that.

Please bear in mind that NPP has many more lines of code that involve flags, since all aspects of terrain are handled by flags as well (some of which uses up alot of processor time, such as re-calculating LOS, lines of movement, movement, and lines of fire every time something changes. Those three things are separate in NPP). So bitflags in NPP would have been a bigger job.

Yes, I accept that. V will doubtless eventually use flag-based terrain (ticket #581), and hopefully in a way which is compatible with NPP. But I do wonder if the age-old dream of bringing good stuff from variants back to V gets impossibly hard once the variant has matured/diverged beyond a certain extent. After all, the last thing we imported was the monster pain messages which, according to at least one observer, were the start of the message ordering problems!

[CunningGabe]

But I do wonder if the age-old dream of bringing good stuff from variants back to V gets impossibly hard once the variant has matured/diverged beyond a certain extent.

I think this is spot on. For most pairs of variants (including V), the best way to bring good stuff from one to the other is probably to look at the ideas and the broad code structure, and then write the code from scratch to suit your variant's structure and sensibilities. Porting over code directly for anything but relatively minor changes is very challenging and not very satisfying.

[nppangband]

After all, the last thing we imported was the monster pain messages which, according to at least one observer, were the start of the message ordering problems!

I didn't know about that. What is happening? Feel free to post a link to another thread or ticket, and I might be able to figure out what is going on.

I did have to fix a couple things in NPP after I did that patch for vanilla, mostly monsters being counted twice for the same pain message in project_m. The codebases are so different at this point, I wouldn't know where to look or if my fixes would even apply to Vanilla.

[Magnate]

I think this is spot on. For most pairs of variants (including V), the best way to bring good stuff from one to the other is probably to look at the ideas and the broad code structure, and then write the code from scratch to suit your variant's structure and sensibilities. Porting over code directly for anything but relatively minor changes is very challenging and not very satisfying.

Hmmm. Git is supposed to make this a lot easier, which is why I was musing about the extent of divergence. I bet it would be a great help for any variant forking from V now (like PowerWyrm's, say), but way less for older variants like NPP. (Note that Sil, although recently released, is based on an old version of V.) I *think* this is why Nick put so much effort into updating FA ... ;-)

[nppangband]

Presumably many who would have played FA are now playing Sil
A.

It could very well be, but I hope that isn't true. The idea that the Angband community can't sustain interest for more than one or two variants at a time is troubling.

When NPP was at the peak of its popularity (NPP 3.x and 4.x), it was either the most popular variant du jour, or second most popular (TOME at that point could either be considered the most popular variant, or a standalone game that had taken on a life of its own). Around that time, Zangband was starting to fade, but was still quite heavily played. Oangband also had a strong following, as did Sangband. All were being actively played and discussed non-stop. There were several others that got frequent mention (DRAngband, POSBand, Hengband, UNAngband, etc....), and I am going by memory and I am doubtless missing a couple others. And of course Angband was the most played of all.

That was around the time steamband was released. It caused a sensation similar to what sil is doing right now. Even though everybody gave it a try, the other variants never got shut out. I would hate to think that even a smoking-hot variant like sil could possibly have the power to make all of the others invisible.

[nppangband]

Hmmm. Git is supposed to make this a lot easier, which is why I was musing about the extent of divergence. I bet it would be a great help for any variant forking from V now (like PowerWyrm's, say), but way less for older variants like NPP.

The Angband code has changed so much, it is barely useable to me. And I guess vice-versa if the messages patch I did is causing so much trouble.

Angband may as well be written in python now. {see derakon's thread}

[Magnate]

I didn't know about that. What is happening? Feel free to post a link to another thread or ticket, and I might be able to figure out what is going on.

I did have to fix a couple things in NPP after I did that patch for vanilla, mostly monsters being counted twice for the same pain message in project_m. The codebases are so different at this point, I wouldn't know where to look or if my fixes would even apply to Vanilla.

Indeed. I don't think Nick is right that the message oddities are traceable back to that patch anyway - ISTR some from before that, such as "The foo dies. The foo is no longer confused.". Not to worry, it's way past time I refactored project_m anyway .... ;-)

[Derakon]

The Angband code has changed so much, it is barely useable to me. And I guess vice-versa if the messages patch I did is causing so much trouble.

Angband may as well be written in python now. {see derakon's thread}

Oh gods, don't expect anything to come from that thread. Seriously, don't. I generate theorycrafting and design ideas as a hobby. Almost none of them are followed through on.

[Magnate]

That was around the time steamband was released. It caused a sensation similar to what sil is doing right now. Even though everybody gave it a try, the other variants never got shut out. I would hate to think that even a smoking-hot variant like sil could possibly have the power to make all of the others invisible.

I don't think it does. I think a lot of other things have changed - the number of players of roguelikes might have gone down a fair bit in these days of facebook games and angry birds, and the number of roguelikes has gone up a lot in the intervening years. I think it's just dilution really - angband variants are now competing not against each other but against all the Brogues and 7DRLs and so on and so on.

[Antoine]

It could very well be, but I hope that isn't true. The idea that the Angband community can't sustain interest for more than one or two variants at a time is troubling.

... I would hate to think that even a smoking-hot variant like sil could possibly have the power to make all of the others invisible.

I don't say that Sil is generally cannibalising all attention from other variants: I just think that the kind of person who wants to play FA is particularly likely to be the kind of person who wants to play Sil.

(Note: I love First Age Tolkien mythos and think both FA and Sil are very cool)

A.