Nightlies embark on long journey towards 3.3

[retrobits]

As of last night I am occasionally seeing green stairs and doors. Maybe its a problem with my eyes?

[PowerDiver]

I cannot see the color L_PURPLE on my system, using X11. Cave spiders and lesser balrogs are written in the same black as the background. I don't know if my monitor colors are off or it is something else. When I change the color through the visuals I can then see the monsters, but that info does not survive the save/reload process.

My debugging process was significantly slowed by mistaking the problem as L_PURPLE when it was actually PURPLE that was causing the problem. I must have misread monster.txt. D'oh! I've noticed several issues.

Most importantly, there are some pref files with V: lines screwing up the color table, for some systems but not all. In particular, lib/pref/font-gtk.prf and lib/pref/font-x11.prf contain the line

V:16:0x01:0x00:0x00:0x00

which gives r/g/b of 0/0/0 to the color PURPLE, rendering it black. I haven't liked some other color changes, e.g. dark green and light green are too similar for me now, so I wonder if there are other errors.

Strangely, while the two pref files mentioned above contain lines for V:0 through V:31, lib/pref/font-mac.prf contains lines only from V:0 to V:15. No other lib/pref files contain any V: lines.

These V: lines act on the angband_color_table. It is defined as having a range of MAX_COLORS, which is 256, but only BASIC_COLORS of 28 lines are provided. Also, there are 32 lines in the pref files mentioned earlier overwriting 32 lines of the color table. Perhaps this is all as intended, but it sure looks strange to me.

[Nick]

Prior to 3.2 the 32x32 tileset displayed perfectly in Vanilla. Since 3.2 there are a few graphic bugs that were, prior to 3.2, strictly limited to variants that didn't have big tile/double tile support (that's all of them except FA). I believe Nick acknowledged that it's something he did to big tile/double tile, though I could be mistaken.

Yes, that's right. I think I'm also right in thinking that FA doesn't have these problems (yet ), so in principle it should be fixable without too much trouble. It may just be a matter of I was less inclined to just throw around screen refreshes when I was coding for V than FA...

[d_m]

I assume that none of the dev team plays with tiles so this be off your radar even though I've brought it up before.

Prior to 3.2 the 32x32 tileset displayed perfectly in Vanilla. Since 3.2 there are a few graphic bugs that were, prior to 3.2, strictly limited to variants that didn't have big tile/double tile support (that's all of them except FA). I believe Nick acknowledged that it's something he did to big tile/double tile, though I could be mistaken.

I think you're right that none of the devs usually play with tiles, although I have recently been trying to use them in SDL and under WINE (to test for Windows).

Would you be willing to open one or more tickets on trac.rephial.org for these issues and add the keyword tiles. I'm sure that these issues have been brought up on oook but there are a lot of "known problems" floating in my head right now and I don't want to lose track. In particular, if you wouldn't mind taking screenshots from 3.2 and an earlier version to illustrate the changes, that would be very helpful to me.

For what it's worth, I *have* noticed problems in tiles, but paradoxically the tiles in Linux were kind of broken even before 3.2 so I don't have a great perspective on the current state of them (or of the problems that Nick/3.2 introduced).

To conclude: sorry that things are broken and hopefully they can be fixed.

[buzzkill]

Please fix 32x32 tile mode

I assume that none of the dev team plays with tiles so this be off your radar even though I've brought it up before.

Prior to 3.2 the 32x32 tileset displayed perfectly in Vanilla. Since 3.2 there are a few graphic bugs that were, prior to 3.2, strictly limited to variants that didn't have big tile/double tile support (that's all of them except FA). I believe Nick acknowledged that it's something he did to big tile/double tile, though I could be mistaken.

My point is, I like it to be fixed for 3.3 before it spreads further (it's already been carried forth into RePos). If nothing else just revert to pre 3.2 status as constantly having to ctrl-r is cumbersome to the point of not bothering to do so, which results in flawed information (monsters, walls, etc) being displayed on the screen, which results in (probable) death.

[Magnate]

Awesome. Thanks a lot.

EDIT: I just checked, and the font error is gone, and I have blocks instead of hashes, but the invisible cave spiders remain. Now that I have evidence it's not the x11 problem, I'll try again to debug it myself.

I diffed vs what I tested less than a day ago, and the changes are ENORMOUS. You guys are crazy.

We are lucky. At the moment we have five active devs, plus takkaria, plus patches and fixes supplied by others. I don't think it's been this busy since 3.0.9 - definitely not since I joined.

EDIT: er ... that's not meant to imply that takkaria is not active! I just meant five devs *plus* the actual maintainer ...

[PowerDiver]

I fixed this in staging at noon today... it should get merged to master in the next day or two, I expect.

EDIT: I just pushed staging to master, so the next build should be fixed.

Awesome. Thanks a lot.

EDIT: I just checked, and the font error is gone, and I have blocks instead of hashes, but the invisible cave spiders remain. Now that I have evidence it's not the x11 problem, I'll try again to debug it myself.

I diffed vs what I tested less than a day ago, and the changes are ENORMOUS. You guys are crazy.

[d_m]

The L_PURPLE problem is still there in the git clone I just did.

I fixed this in staging at noon today... it should get merged to master in the next day or two, I expect.

EDIT: I just pushed staging to master, so the next build should be fixed.

[PowerDiver]

I think correcting on read is a bad idea too, but I try to avoid touching the savefile where possible for the fear of introducing accidental bugs.



Does that still happen with the latest git version?

The question is whether, when you read in a trident (1d8), should it be changed to a trident (1d10)? That's the sort of thing introduced into load.c.

IMO only changes that will cause errors should be changed. If the damage sides were negative, that would be worth fixing. If a dungeon level is too large, sure fix it, but why do anything if it is a little small?


The L_PURPLE problem is still there in the git clone I just did. I changed the color_table line in variable.c to copy the pink line to no effect. It appears to be the line number rather than the values that is the problem. Perhaps it is related to the x11 font error I reported. It's not hard for me to get around, but people should watch out for similar problems. I should have mentioned walls changed from blocks to hashes too. I figured that was related to fixing blank walls in windows, but maybe it is related to my problem.

[takkaria]

Who is the genius who decided to reorder the spells again?

I am making mistakes modifying the code because of the way savefiles are being "corrected" when they are read in. There are also bugs being introduced, such as recreating the town every time because xmax and ymax are diff from dungeon levels. I think the whole idea of correcting on read might be a bad idea, even though I see the possible benefits.

I think correcting on read is a bad idea too, but I try to avoid touching the savefile where possible for the fear of introducing accidental bugs.

I cannot see the color L_PURPLE on my system, using X11. Cave spiders and lesser balrogs are written in the same black as the background. I don't know if my monitor colors are off or it is something else. When I change the color through the visuals I can then see the monsters, but that info does not survive the save/reload process.

Does that still happen with the latest git version?

[Timo Pietilä]

Don't you have to save that info off explicitly into a .prf file somewhere?

I'm not sure if this is still the case in nightly editions, but in 3.2 saving visual preferences is in different place than editing them (one is in options - interact with visuals, other is in knowledge menu). This is a flaw in current vanilla UI that should be fixed.

[camlost]

When I change the color through the visuals I can then see the monsters, but that info does not survive the save/reload process.

Don't you have to save that info off explicitly into a .prf file somewhere?

[PowerDiver]

Who is the genius who decided to reorder the spells again?

I am making mistakes modifying the code because of the way savefiles are being "corrected" when they are read in. There are also bugs being introduced, such as recreating the town every time because xmax and ymax are diff from dungeon levels. I think the whole idea of correcting on read might be a bad idea, even though I see the possible benefits.

I cannot see the color L_PURPLE on my system, using X11. Cave spiders and lesser balrogs are written in the same black as the background. I don't know if my monitor colors are off or it is something else. When I change the color through the visuals I can then see the monsters, but that info does not survive the save/reload process.

[Derakon]

Individual creeping coins in NPP are legitimate threats but not overpoweringly so, especially if you have sources of magical attack (their main threat is their incredibly high AC). Coin pits are, as you said, a dangerous temptation. Not that there's anything wrong with that.

[Timo Pietilä]

Not that Vanilla's creeping coins are especially threatening, but if we were to import NPP's set then they would be..

Slight side-note: if we do that people will be getting killed a lot more, especially if we add money pits. "money, money, money, drool, can't think straight, what's that? RIP?".

That thing was the single most dangerous feature into game, not because it wasn't difficult to avoid, but it was difficult to avoid getting tempted too much.