Nightlies embark on long journey towards 3.3

[PowerDiver]

Originally Posted by takkaria

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.

[d_m]

Originally Posted by PowerDiver

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]

Originally Posted by d_m

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.

[Magnate]

Originally Posted by PowerDiver

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 ...

[buzzkill]

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.

[d_m]

Originally Posted by buzzkill

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.

[Nick]

Originally Posted by buzzkill

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...

[PowerDiver]

Originally Posted by 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.

[retrobits]

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

[PowerDiver]

Originally Posted by retrobits

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

Are those on the border of your trap detection area? I think this counts as a bugfix, as previously when they were not green that meant the border was not fully displayed. It gets a little strange when a clear monster is on a greenlit border tile.