Bugs: V3.1.2

[bio_hazard]

I haven't been playing the nightlies so this may not be a new bug (if it's even a bug):

If Smeagol drains you to 0 gold, he doesn't seem to teleport away any more. Not sure if this is intended or not.

[Zababa]

I think having an option to bold uniques, or use a distinctive background, or something, would be good. ...

I like d_m's idea of distinctively coloured background for the uniques. In fact, I think it would be handy for some other monsters (e.g. those not yet encountered/slain), too.

[Magnate]

I like d_m's idea of distinctively coloured background for the uniques. In fact, I think it would be handy for some other monsters (e.g. those not yet encountered/slain), too.

Whereas I, on the other hand, said I would slay all his descendants if a single non-black background ever appears anywhere in Angband (except for terrain). YMMV.

[Derakon]

I suspect we'll find that changing the background color will make for an ugly game. It would also potentially cause problems for players who expect solid-color blocks to be walls (even if there's a character embedded in the block). I'd rather try changing the font style first.

...heh. Bold for unique, italic for faster-than-you, underlined for out-of-depth?

[takkaria]

Whereas I, on the other hand, said I would slay all his descendants if a single non-black background ever appears anywhere in Angband (except for terrain). YMMV.

I'm interested in z-term getting this functionality but happy to leave it other people to figure out how to best use it.

[Magnate]

I'm interested in z-term getting this functionality but happy to leave it other people to figure out how to best use it.

Well, Derakon made my point in a more coherent way: solid blocks instinctively mean walls, so the best use of non-black backgrounds would be for different terrain types, as discussed extensively in another thread (glass walls, lava, water, etc. etc.).

I am adamantly opposed to non-black backgrounds for monsters or items. If we want fancy graphics, people have gone to great lengths to produce tiles of varying sizes.

[Zababa]

Secondary monitor unplugged

I just experienced a very unpleasant bug. (At least under Windows XP.) When I first run 3.1.2 on my laptop today, I moved the angband window to the secondary display attached to it, and maximized it there. Then I played and closed angband again, unplugged the secondary monitor (without deactivating it in the display control panel), hibernated the laptop, woke it up again and let it run without the secondary display. When I now start Angband, it crashes immediately. Obviously, with the secondary display missing, it cannot find the coordinates for positioning its window. I don't know which files I have to delete or modify to get back to Angband's default window size and position, so I just deleted it as a whole and downloaded it and extracted again.

[takkaria]

Well, Derakon made my point in a more coherent way: solid blocks instinctively mean walls, so the best use of non-black backgrounds would be for different terrain types, as discussed extensively in another thread (glass walls, lava, water, etc. etc.).

I am adamantly opposed to non-black backgrounds for monsters or items. If we want fancy graphics, people have gone to great lengths to produce tiles of varying sizes.

I wouldn't suggest making non-black backgrounds the default, but I don't see any harm in having an option to make e.g. uniques be inverse video or somesuch.

[d_m]

I wouldn't suggest making non-black backgrounds the default, but I don't see any harm in having an option to make e.g. uniques be inverse video or somesuch.

I like the option from an accessibility point of view. If I work through all the other junk I'm supposed to do first I may try to add this.

[buzzkill]

I just experienced a very unpleasant bug. (At least under Windows XP.) When I first run 3.1.2 on my laptop today, I moved the angband window to the secondary display attached to it, and maximized it there. Then I played and closed angband again, unplugged the secondary monitor (without deactivating it in the display control panel), hibernated the laptop, woke it up again and let it run without the secondary display. When I now start Angband, it crashes immediately. Obviously, with the secondary display missing, it cannot find the coordinates for positioning its window. I don't know which files I have to delete or modify to get back to Angband's default window size and position, so I just deleted it as a whole and downloaded it and extracted again.

Tinkering with angband.ini in the root folder might slove your problem.

[Magnate]

I wouldn't suggest making non-black backgrounds the default, but I don't see any harm in having an option to make e.g. uniques be inverse video or somesuch.

Well, you're the boss, and if it's only an option then I can't complain.

[Zababa]

... but I don't see any harm in having an option to make e.g. uniques be inverse video or somesuch.

I don't think inverse video will look good on them guys. I imagined something like dark-brownish background. What was on your mind, d_m?

[half]

I wouldn't suggest making non-black backgrounds the default, but I don't see any harm in having an option to make e.g. uniques be inverse video or somesuch.

It is quite easy to do this. I've done it for my variant in progress by overloading the meaning of the attr. There are 256 'colours' to play with, but I've restricted myself to 8 sets of 32 colours. To get the real attr, I take the attr mod 32, I use the attr div 32 to get the 'display mode'. For example, 0-31 are the normal display, 32-63 are solid blocks (background the same as foreground), 64-95 are dark grey background (a little darker than 'D'), and 96-127 could easily be inverse video or something if I need more.

This overloading route means that you don't need to change the term code at all, just the display code in the main-xxx.c files (setting the background colour and foreground colour based on the value of the attr). Incidentally, it finally solves the solid block issue on windows and mac for good: just have an option for solid block in the display options that sets the attr to the 'solid block' mode where the background is set to the same colour as the foreground (i.e. my solid block walls are actually #s, but with modified background colours).

[Nick]

This overloading route means that you don't need to change the term code at all, just the display code in the main-xxx.c files (setting the background colour and foreground colour based on the value of the attr). Incidentally, it finally solves the solid block issue on windows and mac for good: just have an option for solid block in the display options that sets the attr to the 'solid block' mode where the background is set to the same colour as the foreground (i.e. my solid block walls are actually #s, but with modified background colours).

That's cunning. I may have to pinch it.

[half]

That's cunning. I may have to pinch it.

Please do. I don't think my variant will be released within the next few months, so don't wait on the code, but the code is not difficult. Of course you could have 64 colours and 4 modes instead of 32 and 8 if you want, I just couldn't think of a way to use more than 32 colours, and I know I can easily change to 64/4 if I decide to do so later.