3.3 bug: ignore functionality

[bulian]

It seems if the number of items in one level (>256) gets to be too large the game crashes. Save file is attached. Press K and have fun. Then read ?destruction and press K. No crash. I managed to clean down to the bottom corner of the GV before I realized what happened and then was playing with a greater draconic Q a second time, got nenya and was stupid enough not to save. This was the third go. With previous destroy functionality this could be avoided but this level can not be cleared.

When two chests are stacked, the bottom chest cannot be opened or disarmed, though this is maybe the same as before.

Also, the GV on this level should be removed IMO from the edit file since tele other is now a bolt not beam.

[Timo Pietilä]

Also, the GV on this level should be removed IMO from the edit file since tele other is now a bolt not beam.

Why would that vault be any different to others like it?

[Magnate]

It seems if the number of items in one level (>256) gets to be too large the game crashes. Save file is attached. Press K and have fun. Then read ?destruction and press K. No crash. I managed to clean down to the bottom corner of the GV before I realized what happened and then was playing with a greater draconic Q a second time, got nenya and was stupid enough not to save. This was the third go. With previous destroy functionality this could be avoided but this level can not be cleared.

When two chests are stacked, the bottom chest cannot be opened or disarmed, though this is maybe the same as before.

Yes, this chest bug is already known (ticket #1187).

The 256-item problem is new - many thanks for spotting it. It seems to me to be the most serious bug in 3.3.0 so far. I will try to confirm tonight, and open a ticket for it.

[bulian]

To elaborate a bit more, I was able to clear both vaults with generous use of ignore items on the floor. It seems so long as the number of items either visible on the floor or in the item list (displayed in a subwindow) remains <256 the game is fine.

FWIW, the reversibility of ignore compared to destroy is nice.

Why would that vault be any different to others like it?

Not sure if you looked at the file, but this is the GV with two parallel horizontal corridors in the middle feeding into a gigantic open room. I certainly would have ignored it were it a non-ironman game. I guess I don't feel so strongly but this is one of the most difficult geometries I've seen, and I'm pretty sure it was designed with -teleother as a beam in mind.

[Timo Pietilä]

Yes, this chest bug is already known (ticket #1187).

The 256-item problem is new - many thanks for spotting it. It seems to me to be the most serious bug in 3.3.0 so far. I will try to confirm tonight, and open a ticket for it.

I can already confirm that that attached savefile crashes, reason for it I can't tell.

[Magnate]

I can already confirm that that attached savefile crashes, reason for it I can't tell.

Thanks Timo - this is now ticket #1517.

[Timo Pietilä]

Not sure if you looked at the file, but this is the GV with two parallel horizontal corridors in the middle feeding into a gigantic open room. I certainly would have ignored it were it a non-ironman game. I guess I don't feel so strongly but this is one of the most difficult geometries I've seen, and I'm pretty sure it was designed with -teleother as a beam in mind.

There are worse, V-shaped comes to mind, and then there is one with several long parallel corridors, "false wall" I think it was called, the "Hellpit" which is basically just huge open space with tens of 40-lvl OoD monsters roaming freely and the "The I in the Storm" which has similar open areas, just a bit more obstacles here and there.

Some of these were close to impossible even with beaming tele-other if you had bad set of monsters in it. OTOH you can ignore those you can't handle so it's OK for me to have such vaults. Some of them became a mental exercise to "how do I separate that one from that group so that I can deal it alone" with tele-other being bolt.

This one you encountered has doors in that center corridor dividing it into sections making access to it much less dangerous than in first seems, also monsters that have access to that are not that bad, the most of the really bad ones have restricted access to the open areas (or don't know how to get there).

[Magnate]

Thanks Timo - this is now ticket #1517.

Fixed in the next dev version, and for 3.3.1. For some reason we defined MAX_ITEMLIST as 256 - there are no comments explaining why, so I just increased it arbitrarily. Let me know if you see any odd behaviour when there are very large numbers of items on the floor.

[Timo Pietilä]

Fixed in the next dev version, and for 3.3.1. For some reason we defined MAX_ITEMLIST as 256 - there are no comments explaining why, so I just increased it arbitrarily. Let me know if you see any odd behaviour when there are very large numbers of items on the floor.

That limit used to be the limit where game starts "compacting" items. Maybe the real bug hides in that compacting code?

[Magnate]

That limit used to be the limit where game starts "compacting" items. Maybe the real bug hides in that compacting code?

No, they're not the same limit. This is simply the number of different types of item which can appear in the item list - used to size arrays in the display_itemlist() function. You're thinking of the "Maximum number of objects on the level" in lib/edit/limits.txt, which I think is z_info->o_max - that's currently 1024, but could easily be higher. It used to be about limiting memory use, but since Angband's memory footprint is about 5MB and the average phone now has about 100x more RAM than that, it's not really an issue unless we need to run angband on a dishwasher.

[Timo Pietilä]

No, they're not the same limit. This is simply the number of different types of item which can appear in the item list - used to size arrays in the display_itemlist() function. You're thinking of the "Maximum number of objects on the level" in lib/edit/limits.txt, which I think is z_info->o_max - that's currently 1024, but could easily be higher. It used to be about limiting memory use, but since Angband's memory footprint is about 5MB and the average phone now has about 100x more RAM than that, it's not really an issue unless we need to run angband on a dishwasher.

Different types of items in object.txt is 418, if that counts only base items. If the limit was smaller than that it was probably the bug source.

[Magnate]

Different types of items in object.txt is 418, if that counts only base items. If the limit was smaller than that it was probably the bug source.

Indeed. The actual limit on object kinds is z_info->k_max, which is currently set at 570. I can't see why MAX_ITEMLIST should need to be less than that - in fact it needs to be more, because artifacts appear separately in the item list, so it ought to be at least z_info->k_max + z_info->a_max.

[Jungle_Boy]

It used to be about limiting memory use, but since Angband's memory footprint is about 5MB and the average phone now has about 100x more RAM than that, it's not really an issue unless we need to run angband on a dishwasher.

I would definitely spend more time in the kitchen if this were possible