recompiled AngbandCE
J-Rodder
that saves properly. Anyone who runs it let me know how it works for
you on your platform, you should just be able to replace the .exe
Also, I am posting here the XML files needed to run the menu I posted
earlier. I am still interested in getting a variant running, with
possibly this same iconic system. This version could still use some
tweaking however.
http://jrodder.googlepages.com/angbandce.exe
http://jrodder.googlepages.com/J-Skin.rar
In the skin file, you can just use those to overwrite the existing
files, and it should work fine.
Enjoy!
The Fury
Wanna port FuryBand?
J-Rod
getting Bolt's version to compile properly and save. The issue I am
seeing is that there's not many people proficient in working in CE, and
then that person also has to like Angband and it's variants. :) That
being said, I'd love to see furyband or ToME ported to CE, and I'd be
willing to do any gfx associated with the port. I am just not good
enough to know what to do with source that doesn't have a workspace
already created, or how to implement the XML menu like Vanderhuge did.
The Fury
> Heh, the major problem is I am not a coder by any means. I had help
> getting Bolt's version to compile properly and save. The issue I am
> seeing is that there's not many people proficient in working in CE, and
> then that person also has to like Angband and it's variants. :) That
> being said, I'd love to see furyband or ToME ported to CE, and I'd be
> willing to do any gfx associated with the port. I am just not good
> enough to know what to do with source that doesn't have a workspace
> already created, or how to implement the XML menu like Vanderhuge did.
>
>
I can do basic things, but trying to rewrite things so that it works on a
handheld is beyond me as well.
mrkrrtft
Do you have a link to the "whole" install archive? I found AngbandCE a
long time ago, but it was unusable due to the skin. Your skin is tons
better.
Thanks,
mrkrrtft
J-Rod
http://www.thangorodrim.net/download.html
J-Rod
what, but I am having problems getting a macro running. If you figure
that out, drop me a line, will you? -Jared
Twisted
CERN particle collider manage to figure out Angband's macro editor UI
(and if anyone can, they will be first), you'll be the first to know.
(To be sure, you may want to take out a subsription to
_Scientific_American_ or something, though.)
--
I am the terror that flaps in the net!
I am the undocumented, unusable user interface in your new software!
I am TWISTED!
sfrisius
I just tried running it on my iPAQ 3955 and when I run it I get an error that
says "the system cannot find the path specified." Is there a specific
directory that it needs to be installed in?
Thanks!
--
- Scott
Si
> Also I forgot to add, I am not sure if I am missing something obvious or
> what, but I am having problems getting a macro running. If you figure
> that out, drop me a line, will you? -Jared
Macros will not work in that version of AngbandCE (along with the knowledge
screens). I have corrected this and also made it compatible with VGA handhelds.
I'll upload the exe and additional files at some point.
I am also working on a port of ToME, though I am a little stuck in lua at the
moment (the rest is pretty much done I think).
Si
Si
> I just tried running it on my iPAQ 3955 and when I run it I get an error that
> says "the system cannot find the path specified." Is there a specific
> directory that it needs to be installed in?
That could be one of a few things. Don't run it from the shortcut it creates,
run it directly from the exe. Also I found that the cab does not create all the
standard libraries - you may have to manually create any it prompts you for.
Si
Si
> Macros will not work in that version of AngbandCE (along with the knowledge
> screens). I have corrected this and also made it compatible with VGA handhelds.
> I'll upload the exe and additional files at some point.
As promised, here they are:
http://homepage.ntlworld.com/the_griffins/angbandce.zip
As with the previous instructions, install the original AngbandCE first and then
add/replace the new files.
Si
Travis Poppe
Slightly off topic, but...
I'm curious to know if AngbandCE is modified in a way that makes it
playable with a somewhat large/normal font on these small handheld
screens? I have a Jornada 720 running Debian Linux, and the only font I
can play Angband in (6x9) is hard on my eyes and almost unenjoyable to
use. If such changes have been made, could they be ported back into the
original copy?
Thanks,
--
Travis Poppe | ASCII Ribbon /"\
IRC: tlp @ irc.freenode.net | Campaign against \ /
"All great truths begin as blasphemies." | HTML e-mail and x
-- George Bernard Shaw | proprietary attachments / \
Si
> I'm curious to know if AngbandCE is modified in a way that makes it
> playable with a somewhat large/normal font on these small handheld
> screens? I have a Jornada 720 running Debian Linux, and the only font I
> can play Angband in (6x9) is hard on my eyes and almost unenjoyable to
> use. If such changes have been made, could they be ported back into the
> original copy?
Am I right in thinking that as you have linux on your handheld, you are simply
playing Vanilla Angband? So the problem is that you need a 6x9 font in order to
fit the 80x24 screen on your device?
My device has a VGA screen so I play with an 8x15 font in AngbandCE ( see
screenshot here: http://homepage.ntlworld.com/the_griffins/CapScr0001.png ). If
the font size is made any bigger, then AngbandCE makes the game screen
scrollable. However I do not find this quite so playable as if you scroll right
you will lose status info and can miss short messages, hunger etc. This has been
partially remedied in AngbandCE by the use of a control window that echos these
messages. I know that ToME allows you to reduce the screen smaller than 80x24
(at least in 2.2.7 on my desktop) - not sure whether Vanilla allows that.
It should be possible to modify the display routines so that your character is
'centred' off-centre to the map but central to a small device screen and then
to only draw that part of the display. However all the status messages around
the screen edge are hardcoded to exactly fit 80x24, so there would be a bit of
work in sorting all that out so you can still get that information.
Si
Travis Poppe
> On 2006-09-25 09:52:38, Travis Poppe <t...@LiquidX.org> wrote:
>
>> I'm curious to know if AngbandCE is modified in a way that makes it
>> playable with a somewhat large/normal font on these small handheld
>> screens? I have a Jornada 720 running Debian Linux, and the only font I
>> can play Angband in (6x9) is hard on my eyes and almost unenjoyable to
>> use. If such changes have been made, could they be ported back into the
>> original copy?
>
> Am I right in thinking that as you have linux on your handheld, you are simply
> playing Vanilla Angband? So the problem is that you need a 6x9 font in
> order to fit the 80x24 screen on your device?
This is correct.
> My device has a VGA screen so I play with an 8x15 font in AngbandCE (
> see screenshot here:
> http://homepage.ntlworld.com/the_griffins/CapScr0001.png ). If the
> font size is made any bigger, then AngbandCE makes the game screen
> scrollable. However I do not find this quite so playable as if you
> scroll right you will lose status info and can miss short messages,
> hunger etc. This has been partially remedied in AngbandCE by the use
> of a control window that echos these messages.
Ah, I see you're using the graphical tiles; I am not. Either way, you're
right in that scrolling around would be annoying. Here is a screenshot
of Angband on my Jornada 720 with a 6x9 font, running in a terminal:
http://lickwid.net/~tlp/j720/screenshots/angband.png
> I know that ToME allows you to reduce the screen smaller than 80x24
> (at least in 2.2.7 on my desktop) - not sure whether Vanilla allows
> that.
Nope, it does not. However, I think this would be doable by rearranging
a few things; with the default xterm font on my Jornada, I've got
something like 16 lines instead of 24 to work with (and >= 80 columns).
I managed to hack this restriction out of vanilla once, but certain
character statistics/messages were not visible, and the various
inventories did not display everything. The inventories would be easy to
remedy by allowing more scrolling; the player statistics would have to
be toggled or something.
> It should be possible to modify the display routines so that your character is
> 'centred' off-centre to the map but central to a small device screen and then
> to only draw that part of the display. However all the status messages around
> the screen edge are hardcoded to exactly fit 80x24, so there would be a bit of
> work in sorting all that out so you can still get that information.
Indeed.
Si
> Ah, I see you're using the graphical tiles; I am not. Either way, you're
> right in that scrolling around would be annoying.
That is just personal preference. I've used tiles since Moria on my Amiga came
with them on by default. Once you can recognise all the monsters in one system
there is little point changing! You can of course also play AngbandCE in ascii
(or Adam Bolt's tileset if you prefer, but as that is double-width you cannot
avoid scrolling).
> Nope, it does not. However, I think this would be doable by rearranging
> a few things; with the default xterm font on my Jornada, I've got
> something like 16 lines instead of 24 to work with (and >= 80 columns).
> I managed to hack this restriction out of vanilla once, but certain
> character statistics/messages were not visible, and the various
> inventories did not display everything. The inventories would be easy to
> remedy by allowing more scrolling; the player statistics would have to
> be toggled or something.
You're quite right. I'd forgotton about the inventory screens in my suggested
solution.
Si
Nick McConnell
> On 2006-09-26, Si wrote:
It seems to me that Angband on portables would be greatly improved by
a) removing the hardcoded 80x24 restriction and
b) introducing capacity for a pointer-driven interface.
Actually, I think an optional pointer driven interface would be good for
non-portables too. There is some precedent already (UnAngband, FAAngband),
and this could certainly be improved - making regular menus and subscreens
clickable, for example. I don't know what the isues for then porting this
stuff back to WinCE or Linux portables would be, though.
Nick.
--
Nick McConnell
FA + "Ooog" DN L:42 DL:57 A+ R++ Sp w:Rog
FA*/A/NPP/O/Po/St/Un W/L H- D c-- f- PV+ s- d++ P++ M+
C-- S- I* So+ B+ ac GHB SQ? RQ+ V-/V+@ F:NPP notes, etc.
Si
> It seems to me that Angband on portables would be greatly improved by
> a) removing the hardcoded 80x24 restriction and
> b) introducing capacity for a pointer-driven interface.
>
> Actually, I think an optional pointer driven interface would be good for
> non-portables too. There is some precedent already (UnAngband, FAAngband),
> and this could certainly be improved - making regular menus and subscreens
> clickable, for example. I don't know what the isues for then porting this
> stuff back to WinCE or Linux portables would be, though.
The first thing I'd say is that since I added the onscreen keyboard (as an
alternative to the skinned versions), Angband is very playable on 640x480 VGA
devices - to the extent that I have had a winning mage character (very keyboard
intensive as you know). However most of the devices out there will not have that
kind of spec yet.
a) Absolutely essential! The annoyance of attempting to play AngbandCE with
scrollbars was what drove me to hacking around with the source code in the
first place (despite no previous experience of WinCE or C itself...). I do not
think it would be too difficult to amend the screen display routines to just
show less of the screen and forcing centre on character would probably be
sensible. The main things would be how to provide all the status information
and how to display long lists (could be implemented with subsequent pages like
shop inventories I guess - though I think we are generally more likely to be
short of columns than rows).
b) AngbandCE was originally coded so that you can select objects from lists by
clicking on them, so that's a start I guess. I still find it a lot easier to
click the appropriate letter on my keyboard (as the keys are 'taller' than the
onscreen rows so I don't need to be so accurate), but where that is not an
option it seems like the best way forward. Casting spells would be more of a
pain that way, but at least you can put the more common ones into macros. I'm
not sure how you've coded your pointer driven interface, but I imagine it works
in a similar way on WinCE (providing you haven't used right or double clicks).
In WinCE a tap on the screen generates a WM_LBUTTONDOWN notification to the
window.
One of the big interface questions on mobile devices is actually diagonal
movement. Most devices these days will have a fourway directional pad which is
generally very convenient for controlling the movement of your character.
However diagonal movement is essential for certain dungeon features as well as
in melee etc. In AngbandCE's new interface I got around this by moving the top
line of the keyboard to a number pad on the right, which can be used when the
situation dictates (this also made my keyboard 'shorter' giving me more pixels
to play with for the screen proper). kMoria on the Palm gets around this by
interpreting a click at the top left of the screen to be a request to move NW
etc (infact there are virtual concentric circles and a click in the outer band
is interpreted as run in that direction).
Si
Andrew Sidwell
> On 2006-10-02 23:45:47, Nick McConnell <nckmc...@yahoo.com.au> wrote:
>
>> It seems to me that Angband on portables would be greatly improved by
>> a) removing the hardcoded 80x24 restriction and
>> b) introducing capacity for a pointer-driven interface.
>>
>> Actually, I think an optional pointer driven interface would be good for
>> non-portables too. There is some precedent already (UnAngband, FAAngband),
>> and this could certainly be improved - making regular menus and subscreens
>> clickable, for example. I don't know what the isues for then porting this
>> stuff back to WinCE or Linux portables would be, though.
>
> The first thing I'd say is that since I added the onscreen keyboard (as an
> alternative to the skinned versions), Angband is very playable on 640x480 VGA
> devices - to the extent that I have had a winning mage character (very keyboard
> intensive as you know). However most of the devices out there will not have that
> kind of spec yet.
<snip insightful and interesting bit>
I think this hints that really, for smaller or even generally more
interesting displays, there needs to be a reworking of the display
system. Anything else will be at best a hack on top of the existing
layer. The question is -- how do we do this sensibly?
Zangband made a start with having dedicated functions that are used for
all selectable lists onscreen, which can easily be translated into GUI
menus, so it'd be a start to do that.
I love the idea of having concentric circles to do motion. A nice
interface night me some kind of superimposed, translucent arrows that
you can press to move in that direction.
I don't have a handheld, so it's all speculation from me, but I do think
it's something worth working towards if there's sufficient interest.
Andrew Sidwell
Si
> I think this hints that really, for smaller or even generally more
> interesting displays, there needs to be a reworking of the display
> system. Anything else will be at best a hack on top of the existing
> layer. The question is -- how do we do this sensibly?
I think whatever we do, there will be a range of hacks at the WinCE end - it is
a case of trying to minimise that. For example, at the very least *bandCE will
require a toolbar of sorts as there are just not enough hardware keys for all
the functions that you would need. I would see the toolbar having say space,
escape, Y and N keys (unless we had a popup for those situations) and then a
row of keys to be used for launching macros (I did this for AngbandCE to good
effect by assigning a load of high ASCII values to some dummy keys). The other
evil thing about WinCE is that it does not like unicode, therefore every system
function call needs to be wrapped in mbstowcs and wcstombs functions... lovely.
My knowledge of *band source code only really extends to Vanilla 2.9.2 (as that
is what I have been working with on AngbandCE), so things may have changed in
the intervening years. However if it is not already, we probably ought to
separate out the dungeon display code from the status area around the edge.
This could then give us the option of going full screen say by toggling the
status area (maybe have HP and SP superimposed somewhere on the display in this
mode?) and also changes to the status area during development should not then
require any recoding of the dungeon display.
> Zangband made a start with having dedicated functions that are used for
> all selectable lists onscreen, which can easily be translated into GUI
> menus, so it'd be a start to do that.
That would be ideal. In AngbandCE there are hacks all over the place to make the
various lists clickable (and there are still some missing...).
> I love the idea of having concentric circles to do motion. A nice
> interface night me some kind of superimposed, translucent arrows that
> you can press to move in that direction.
So assuming the @ is on the central square, I would see it working something
like this:
..............
.77788888999..
7777888889999.
7777788899999.
7777788899999.
4477788899666.
44444iii66666.
44444iii66666.
44444iii66666.
4411122233366.
1111122233333.
1111122233333.
1111222223333.
.11122222333..
..............
Where the character displayed above is actually the keypress sent to the term
when that square is clicked. Clicking any further out would pass a '.' before
the number to invoke running in that direction.
Therefore to access the inventory you could click on (or just around) the @.
Then clicking on an item should bring up a popup containing the commands you
can perform on that item (I assume there is a set of flags on an object that
can just be read off?). For example if you clicked on object f and then
selected wield, the interface would then call Term_keypress('w') followed by
Term_keypress('f') to avoid changing the underlying code too much.
Other interface thoughts that I've had:
- Click on stats to bring up character page
- Click on SP to cast a spell (an alternative to clicking on the book in the
inventory and selecting cast)
- Click on HP to rest
- Click on Hungry to eat
- Lists should come up by default. eg m should be keymapped to m*. Selecting a
spell book should also list the spells without having to press space.
- When in targeting mode you should be able to click on a target rather than
cycling through them.
- 'easy alter' should be on by default (if it is not already)
- allow destroy of worthless/cursed items without prompt (I know ToME can do
this already, not sure about other *bands)
Si
Nick McConnell
> On 2006-10-02 23:45:47, Nick McConnell wrote:
>
> > It seems to me that Angband on portables would be greatly improved by
> > a) removing the hardcoded 80x24 restriction and
> > b) introducing capacity for a pointer-driven interface.
> a) Absolutely essential! The annoyance of attempting to play AngbandCE with
> scrollbars was what drove me to hacking around with the source code in the
> first place (despite no previous experience of WinCE or C itself...). I do not
> think it would be too difficult to amend the screen display routines to just
> show less of the screen and forcing centre on character would probably be
> sensible. The main things would be how to provide all the status information
> and how to display long lists (could be implemented with subsequent pages like
> shop inventories I guess - though I think we are generally more likely to be
> short of columns than rows).
Yes, in fact that's not too hard at all. I've hacked FA a little (just under
linux), and , sure enough, status info and lists are the only real problem. I
think a hardcoded minimum would still be the simplest way to go, but I think I
could get it as low as 28x16 (and that's in FA, which has more status
messages). That still leaves enough room for important status stueff, and
lists should be OK if they're all left-justified.
> b) AngbandCE was originally coded so that you can select objects from lists by
> clicking on them, so that's a start I guess. I still find it a lot easier to
> click the appropriate letter on my keyboard (as the keys are 'taller' than the
> onscreen rows so I don't need to be so accurate), but where that is not an
> option it seems like the best way forward. Casting spells would be more of a
> pain that way, but at least you can put the more common ones into macros. I'm
> not sure how you've coded your pointer driven interface, but I imagine it works
> in a similar way on WinCE (providing you haven't used right or double clicks).
> In WinCE a tap on the screen generates a WM_LBUTTONDOWN notification to the
> window.
Heh, I hadn't realised lists were clickable in AngbandCE. That helps.
> One of the big interface questions on mobile devices is actually diagonal
> movement. Most devices these days will have a fourway directional pad which is
> generally very convenient for controlling the movement of your character.
> However diagonal movement is essential for certain dungeon features as well as
> in melee etc. In AngbandCE's new interface I got around this by moving the top
> line of the keyboard to a number pad on the right, which can be used when the
> situation dictates (this also made my keyboard 'shorter' giving me more pixels
> to play with for the screen proper). kMoria on the Palm gets around this by
> interpreting a click at the top left of the screen to be a request to move NW
> etc (infact there are virtual concentric circles and a click in the outer band
> is interpreted as run in that direction).
The main function of the FA/Un pointer interface is to allow you to head
automatically to a spot you click on, so this largely solves the diagonal
movement issue. It might actually lead to playing without using the hardware
buttons at all.
Nick McConnell
> On 2006-10-03 16:11:09, Andrew Sidwell wrote:
>
> > I think this hints that really, for smaller or even generally more
> > interesting displays, there needs to be a reworking of the display
> > system. Anything else will be at best a hack on top of the existing
> > layer. The question is -- how do we do this sensibly?
>
> I think whatever we do, there will be a range of hacks at the WinCE end - it is
> a case of trying to minimise that. For example, at the very least *bandCE will
> require a toolbar of sorts as there are just not enough hardware keys for all
> the functions that you would need. I would see the toolbar having say space,
> escape, Y and N keys (unless we had a popup for those situations) and then a
> row of keys to be used for launching macros (I did this for AngbandCE to good
> effect by assigning a load of high ASCII values to some dummy keys). The other
> evil thing about WinCE is that it does not like unicode, therefore every system
> function call needs to be wrapped in mbstowcs and wcstombs functions... lovely.
I agree with you both. Freeing up the display system is a good plan; IMHO
probably the best way to do this is to have an option for "small mode" which
allows less than 80x24, reduces the status displays, menus, maybe 'C' screen
and '~' screens, etc. But yes, there are still going to be a bunch of hacks
for any small portable system.
> My knowledge of *band source code only really extends to Vanilla 2.9.2 (as that
> is what I have been working with on AngbandCE), so things may have changed in
> the intervening years. However if it is not already, we probably ought to
> separate out the dungeon display code from the status area around the edge.
> This could then give us the option of going full screen say by toggling the
> status area (maybe have HP and SP superimposed somewhere on the display in this
> mode?) and also changes to the status area during development should not then
> require any recoding of the dungeon display.
I think a small mode would cover this.
> > Zangband made a start with having dedicated functions that are used for
> > all selectable lists onscreen, which can easily be translated into GUI
> > menus, so it'd be a start to do that.
>
> That would be ideal. In AngbandCE there are hacks all over the place to make the
> various lists clickable (and there are still some missing...).
Yeah, that does sound good.
> > I love the idea of having concentric circles to do motion. A nice
> > interface night me some kind of superimposed, translucent arrows that
> > you can press to move in that direction.
>
> So assuming the @ is on the central square, I would see it working something
> like this:
>
> . .............
> . 77788888999..
> 7777888889999.
> 7777788899999.
> 7777788899999.
> 4477788899666.
> 44444iii66666.
> 44444iii66666.
> 44444iii66666.
> 4411122233366.
> 1111122233333.
> 1111122233333.
> 1111222223333.
> . 11122222333..
> . .............
>
> Where the character displayed above is actually the keypress sent to the term
> when that square is clicked. Clicking any further out would pass a '.' before
> the number to invoke running in that direction.
The Un/FA pointer interface works quite like this, with the added feature that
clicking further away invokes a path-finding algorithm.
> Therefore to access the inventory you could click on (or just around) the @.
> Then clicking on an item should bring up a popup containing the commands you
> can perform on that item (I assume there is a set of flags on an object that
> can just be read off?). For example if you clicked on object f and then
> selected wield, the interface would then call Term_keypress('w') followed by
> Term_keypress('f') to avoid changing the underlying code too much.
>
> Other interface thoughts that I've had:
>
> - Click on stats to bring up character page
> - Click on SP to cast a spell (an alternative to clicking on the book in the
> inventory and selecting cast)
> - Click on HP to rest
> - Click on Hungry to eat
> - Lists should come up by default. eg m should be keymapped to m*. Selecting a
> spell book should also list the spells without having to press space.
> - When in targeting mode you should be able to click on a target rather than
> cycling through them.
> - 'easy alter' should be on by default (if it is not already)
> - allow destroy of worthless/cursed items without prompt (I know ToME can do
> this already, not sure about other *bands)
I'd been thinking along thes lines too. I'm planning to go right through the
command list and find a way to do nearly everything with the pointer.
Si
On 2006-10-05 00:04:29, Nick McConnell <nckmc...@yahoo.com.au> wrote:
> I agree with you both. Freeing up the display system is a good plan; IMHO
> probably the best way to do this is to have an option for "small mode" which
> allows less than 80x24, reduces the status displays, menus, maybe 'C' screen
> and '~' screens, etc. But yes, there are still going to be a bunch of hacks
> for any small portable system.
Some devices with rectangular screens can only operate in portrait mode.
Therefore a good feature of this "small mode" would be the ability to toggle
the status area from beside the map to beneath it to provide a more appropriate
area for the dungeon display.
> The Un/FA pointer interface works quite like this, with the added feature that
> clicking further away invokes a path-finding algorithm.
Nice touch. I like that.
> > a) Absolutely essential! The annoyance of attempting to play AngbandCE with
> > scrollbars was what drove me to hacking around with the source code in the
> > first place (despite no previous experience of WinCE or C itself...). I do not
> > think it would be too difficult to amend the screen display routines to just
> > show less of the screen and forcing centre on character would probably be
> > sensible. The main things would be how to provide all the status information
> > and how to display long lists (could be implemented with subsequent pages like
> > shop inventories I guess - though I think we are generally more likely to be
> > short of columns than rows).
>
> Yes, in fact that's not too hard at all. I've hacked FA a little (just under
> linux), and , sure enough, status info and lists are the only real problem. I
> think a hardcoded minimum would still be the simplest way to go, but I think I
> could get it as low as 28x16 (and that's in FA, which has more status
> messages). That still leaves enough room for important status stueff, and
> lists should be OK if they're all left-justified.
Do the messages on the top line just get split into smaller chunks when you
reduce the screen width?
The smallest Windows Mobiles smartphone screens are 176x220 pixels which with a
5x8 font gives you 35x27 to play with. Other screen sizes are 240x240,
240x320/320x240, 480x480 (VGA) and 480x640/640x480 (VGA). Personally I use
640x480 with an 8x15 font to give me 80x24 (with a 120 pixel high control area
beneath).
> Heh, I hadn't realised lists were clickable in AngbandCE. That helps.
At present it appears to be only store and inventory lists that work this way
(spells certainly don't). It is done quite crudely, for example if you clicked
object 'm' in the standard inventory screen, it would attempt to cast a spell.
> The main function of the FA/Un pointer interface is to allow you to head
> automatically to a spot you click on, so this largely solves the diagonal
> movement issue. It might actually lead to playing without using the hardware
> buttons at all.
It would probably allow this, but I can still see the need for the hardware
buttons (particularly for high level characters meleeing a corridor of lower
level bad guys by holding down the direction button!). The other hardware
buttons are also useful for mapping macros to.
Si