Angband 4.0beta status

[Nick]

1. Save a game with graphical tiles
2. Exit Angband
3. Remove lib/xtra/graf/graphics.txt
4. Start Angband
5. Load the saved game
6. Watch Angband crash and burn

Why would you do that?

Your chest crash was interesting. I can see why the crash happened, but can't see how the situation arose; it also seems to be the same basic cause as the previous mimic-related crash you had.

I am aware that there are a bunch of tile related oddities, and at some point will do some tile-focussed debugging, but haven't got there yet. I'm also likely to be not updating for most of next week.

[tumbleweed]

Why would you do that?

Uhh... it kind of happened?

here's the tl;dr version:

1. modded a tile set and gave my version a separate menu entry
2. moved the image and the edited graphics.txt to a new beta release
3. found a bug in the new beta
4. loaded a save in the old beta to see if the issue affected it as well
5. Kaboom

I am aware that there are a bunch of tile related oddities, and at some point will do some tile-focussed debugging, but haven't got there yet.

No sweat. What would you like me to do about further tile-related oddities I find?

1. keep posting in this thread
2. shut up for now and collect them for a later thread
3. post them in a separate thread
4. other (please specify)

[Nick]

What would you like me to do about further tile-related oddities I find?

1. keep posting in this thread
2. shut up for now and collect them for a later thread
3. post them in a separate thread
4. other (please specify)

Post them here if they seem to add new information, I guess.

[Nick]

There's some FOV rendering oddity going on in non-1x1 text modes that I can't quite describe. See attachment.

Also note: again no equipment displayed between gold and strength on the left, just like in non-1x1 graphical modes.

So what's happening here is that the tile code allocates an area of regular grids - 3x3 or whatever - to draw each tile in. So if you leave it as 3x3 and go back to text mode, it draws the each text grid in one corner of that box (I don't remember which). This is a consequence of the fairly hacky way large tiles are implemented.

As for the lack of equipment display in the sidebar, that's because it messes up the sidebar arrangement if you try to fit more than a single grid's worth in there.

The hope is that with the interface-game split that has happened with the current restructure, someone will decide to write a modern Windows interface that deals with things like tile handling much better; until then, it's likely to still be a bit creaky.

[tumbleweed]

Your chest crash was interesting. I can see why the crash happened, but can't see how the situation arose; it also seems to be the same basic cause as the previous mimic-related crash you had.

Might be something going wrong during level creation.

I have another one of these reproducible mimic crashes on the level I'm currently on. Attached is a save file from the very moment I entered the level, and another one with @ close to the mimic, plus a map that shows where the mimic is.

Curiously, if you beeline to the mimic it (probably?) looks like 2 Turquoise Rings of See Invisible, while now - after clearing most of the level - 'l'ooking shows a pile of 2 objects - and the list of visible objects shows 5 Turquoise Rings of See Invisible but nothing else at that location.

[tumbleweed]

As for the lack of equipment display in the sidebar, that's because it messes up the sidebar arrangement if you try to fit more than a single grid's worth in there.

Well, the graphical tiles could be downscaled to fit, but I guess it's largely a nitpick that's probably best left for later, or even for a revamped Windows (or cross-platform!) interface.

And the lack of equipment display at >1x1 in text mode is just weird imo.

edit: don't miss the update on assertive mimics

[Ingwe Ingweron]

Angband 4.0 dev a05a05c

Part of the can't back out bug. - Just zapped a flavored rod and turned out to be a Rod of Identify. Didn't have anything to identify, but the Rod is {charging}. In 3.5.1, not having anything to identify a charge would not be used. Likewise, if I did have something to identify, and chose not to, in 3.5.1 a charge would not be used.

[Nick]

Update 280b6ee fixes:

• Game slowdown when running (I think)
• Adds some help files

so not much, but I wanted to get the running fix out.

I have some questions, too:

1. Rings switching hands - is that every time?
2. How often is monster memory vanishing? Has anyone checked if their lore.txt file (in lib/user on Windows, ~/Documents/Angband on OSX) seems to correlate with current monster memory?
3. How often is the slow lock-picking happening, and with what type of character?
4. Are we there yet? (No, we're not there, and you can't have an ice cream).

[tumbleweed]

Update 280b6ee fixes:

1. Rings switching hands - is that every time?

I just did some quick testing: it does seem to depend on the rings.

For example, I equipped two Rings of Damage, one (+0,+8) and one (+0,+9). After exiting and reloading, the (+0,+9) would always be on the right hand, no matter how I equipped them before exiting.

The (+0,+8) one is a ring I just found, the other one has been my trusty companion for many levels. Maybe that's a clue?

[Nomad]

I just did some quick testing: it does seem to depend on the rings.

For example, I equipped two Rings of Damage, one (+0,+8) and one (+0,+9). After exiting and reloading, the (+0,+9) would always be on the right hand, no matter how I equipped them before exiting.

The (+0,+8) one is a ring I just found, the other one has been my trusty companion for many levels. Maybe that's a clue?

I've noticed this before with rings of damage, too. (And thank you for reporting it as a bug, and proving I'm not going mad!) So far as I can tell, it happens when you have two stat rings of the same type, where one gives a higher stat boost than the other. Let's call them High Ring and Low Ring.

The swap bug occurs when you equip High Ring to slot c, and then Low Ring to slot d. If you exit and reload, the rings will have swapped over so that High Ring is now in slot d. (Further exiting and reloading does not cause them to swap back - once it's moved there, High Ring always stays in slot d.)

This happens most of the time, but not always. I'm not completely certain why not, but I think it has to do with the order you put the rings on - i.e. if you put High Ring in c and then Low Ring in d, they will swap; if you're already wearing Low Ring in d and then stick High Ring in c, they won't. Possibly.

EDIT: Okay, it effects dissimilar ring pairs as well, so this theory is wrong: looks like it may be down to order of pickup as tumbleweed suggests below.

[Ingwe Ingweron]

....So far as I can tell, it happens when you have two stat rings of the same type, where one gives a higher stat boost than the other....

Not just rings of the same type. I've seen damage swap with stat rings and with element rings. For quite awhile I thought I was going mad, switching rings and forgetting, but finally reported the problem when I was absolutely sure it was happening on its own. The higher - lower theory is interesting. I'll watch for it. It seems to happen on exit and reload.

I inscribe the "c" rings with @1 and the "d" rings with @2, making swapping with other rings in inventory or rewielding easy. I've got "y" keymapped to "w1c" and "j" keymapped to "w2d". When a @2 ends up in "c" or a @1 ends up in "d" then I know the swap bug has bitten me.

[Ingwe Ingweron]

Continuing my perusal of the edit files.

p_race.txt #height and #weight still have hgtfemale, modhgtfemale, wgtfemale, and modwgtfemale.

That's fine for them to be present in case the removal of gender choice is reverted or for variants, but note #height female stat and mod are still actually being used for the "Elf" race (not to be confused with High-Elf).

[tumbleweed]

I just did some quick testing: it does seem to depend on the rings.

For example, I equipped two Rings of Damage, one (+0,+8) and one (+0,+9). After exiting and reloading, the (+0,+9) would always be on the right hand, no matter how I equipped them before exiting.

The (+0,+8) one is a ring I just found, the other one has been my trusty companion for many levels. Maybe that's a clue?

After further testing, it seems to depend on which ring was picked up first.

1. Drop any two rings on the floor.
2. Pick them up and equip them.
3. Exit and reload.
4. Check your hands.
5. The ring that was picked up last will be on your left hand. Magic!

Tested with the aforementioned rings of damage, plus a Ring of Constitution <+3> and a Ring of Intelligence <+5> that was lying around nearby.

Confirm/Deny?

[Nomad]

After further testing, it seems to depend on which ring was picked up first.

1. Drop any two rings on the floor.
2. Pick them up and equip them.
3. Exit and reload.
4. Check your hands.
5. The ring that was picked up last will be on your left hand. Magic!

Tested with the aforementioned rings of damage, plus a Ring of Constitution <+3> and a Ring of Intelligence <+5> that was lying around nearby.

Confirm/Deny?

Yep, after some testing I think you might be right actually. So the high vs. low bonus stuff may just have been a complete coincidence.

[Nomad]

1. How often is monster memory vanishing? Has anyone checked if their lore.txt file (in lib/user on Windows, ~/Documents/Angband on OSX) seems to correlate with current monster memory?

All right, I think I've spotted the problem! Having just started afresh in the newest version of 4.0, turns out I didn't actually have a lore.txt file. It looks like lore.txt is A, only created when your first character dies, and B, only being updated on character death, not when you save during an ongoing game. So when you exit and restart, monster knowledge is wiped back to the state it was at your most recent character death, and does not retain anything new that your still-living character has learned since then.