When using the Iron Chests mod with a diamond chest, there are more than 9 columns so the code that parses the item rules works incorrectly. This creates a nullpointerexception on InvTweaksSortingHandler:101 where the rule.getPreferredSlots() is null

This chunk:

            // Extract chars
            for(int i = 0; i < constraint.length(); i++) {
                char c = constraint.charAt(i);
                int digitValue = Character.digit(c, 36); // radix-36 maps 0-9 to 0-9, and [a-zA-Z] to 10-36, see javadoc
                log.info("char {} digitValue {}", c, digitValue);
                if(digitValue >= 1 && digitValue <= containerRowSize && digitValue < 10) {
                    // 1 column = 0, 9 column = 8
                    column = digitValue - 1;
                } else if(digitValue >= 10 && (digitValue - 10) <= containerColumnSize) {
                    // A row = 0, D row = 3, H row = 7
                    row = digitValue - 10;
                } else if(charEqualsIgnoreCase(c, 'r')) {
                    reverse = true;
                }
            }

Will fail if either code is out of bounds. This is more likely to happen if the row (mapped from 1-9) falls out of bounds.

Rather than completely not supporting bigger chests, you should do a simple sort where it will just sort them by ID, or name, or something, this way bigger chests can still be organised and not completely random!

@Kobata could we close this?

Having issues with Storage Crates in Actually Additions and it seems that this is not going be fixed since been a year plus sadly.

This is a reminder for whenever I end up messing in the core of sorting/these modes.

It's just still one of the parts of the mod I don't entirely understand so I'm trying to avoid breaking it further.

7812cce should've disabled the buttons and ability to use the non-default modes on these types of chests though.

given it's (as far as I can tell without actually understanding everything that's going on in the code snippets above) a simple matter of an array being too big, I don't suppose this is fixed or will be fixed in the near future?
if not, I'm considering submitting a pull request. Then again, I've never actually worked with a mod and only know basic, beginner-level Java, so I might not be the best person to help

A really temporary hack is this (only helps in supporting columns up to 17 i believe)

                int digitValue = Character.digit(c, 36); // radix-36 maps 0-9 to 0-9, and [a-zA-Z] to 10-36, see javadoc
                // If we get a -1 digit, assume we have overflowed 9 columns, i don't think its easy to overflow 26 rows
                if(digitValue == -1) {
                    // '9' represents column = 8
                    column = c - '9' + 8;
                } else {
                    if(digitValue >= 1 && digitValue <= containerRowSize && digitValue < 10) {
                        // 1 column = 0, 9 column = 8
                        column = digitValue - 1;
                    } else if(digitValue >= 10 && (digitValue - 10) <= containerColumnSize) {
                        // A row = 0, D row = 3, H row = 7
                        row = digitValue - 10;
                    } else if(charEqualsIgnoreCase(c, 'r')) {
                        reverse = true;
                    }
                }

Those modes are so horribly broken I'd probably be most likely to just disable them for anything not the right size, honestly.

Even when it works, it likes to swap between a few different orderings.

Fair enough, feel free to close if its a wont-fix.