Trying to get pebbles <-> stone conversions working in compacting drawers and failing.

The server and my client are both set with the following in config:

    S:compactingRules <
        minecraft:clay, minecraft:clay_ball, 4
        minecraft:stone:5, exnihiloadscensio:itemPebble:3, 4
        stoneDiorite, exnihiloadscensio:itemPebble:2, 4
        minecraft:stone:1, exnihiloadscensio:itemPebble:1, 4
        minecraft:cobblestone, exnihiloadscensio:itemPebble:0, 4
        tile.stone.diorite, item.itemPebble.diorite, 4
        minecraft:stone, minecraft:stonebrick, 1
        minecraft:stonebrick, minecraft:stonebrick:3, 1
     >

The clay/ball default and the stone/brick/chiseledbrick (used example from the API documentation for that) work. The others don't, and I can't determine why not.

Tried adding whitelist just in case (only really applies to diorite itself - the pebbles have no oredict name), but didn't help.

    S:oreWhitelist <
        stoneDiorite
     >

What am I doing incorrectly?

Those were only added after the first attempt (minecraft:stone:5, exnihiloadscensio:itemPebble:3, 4) failed by itself.

Any reason that one doesn't work? That's neither invalid resource name nor oredict.

Well I see several invalid resource names (e.g. item.itemPebble.diorite -- you need to qualify it with the mod ID). Ore dictionary keys are not supported for this registry (which I assume is stoneDiorite). Instead you'd need to pick a discrete item, and make sure the associated ore dictionary key was clear to substitute items.

My only thought is double-checking that you have the correct resource name. If you're sure it's correct, you could try adding it through the MineTweaker API and see if it makes a difference.

I was able to partially resolve my original complaint by adding recipes through MT as you suggest.

However, this process revealed an underlying issue in storage drawers that was complicating things: the registry seems to only support 1/4/9 shapeless recipes, regardless of the value specified.

Expected Behavior

When the custom registry contains e.g. minecraft:coal:0, minicoal:miniCoal, 8 and shapeless recipes exist for both directions (coal<->minicoal*8), a single compacting drawer supports coal and minicoal (and coal blocks).

Observed behavior

A compacting drawer supports coal and minicoal (and coal blocks) only if the recipes are for quantity 9 instead of quantity 8 for the 'small' item.

Example

In particular, the various 'tiny coal' solutions (actuallyadditions, minicoal, and others) that convert 1 coal into 8 'tiny coal' can't be made to work correctly with storage drawers.

Using minicoal for testing as it adds only 4 recipes:

• 1 coal -> 8 mini coal, shapeless
• 8 mini coal -> 1 coal, (box-shaped recipe, like planks->chest)
• 1 charcoal -> 8 mini charcoal, shapeless,
• 8 mini charcoal -> 1 charcoal, (box-shaped recipe, like planks->chest)

8 tiny coal :: 1 coal

Minetweaker script to remove the shaped recipe and add an 8-mini-coal shapeless recipe:

recipes.removeShaped(<minecraft:coal:0>, [[<ore:miniCoal>,<ore:miniCoal>, <ore:miniCoal>], [<ore:miniCoal>, null, <ore:miniCoal>], [<ore:miniCoal>, <ore:miniCoal>, <ore:miniCoal>]]); 
recipes.addShapeless(<minecraft:coal:0>, [<ore:miniCoal>, <ore:miniCoal>,<ore:miniCoal>,<ore:miniCoal>,<ore:miniCoal>,<ore:miniCoal>,<ore:miniCoal>,<ore:miniCoal>]);

StorageDrawers.cfg section:

registries {
    S:compactingRules <
	minecraft:coal:0, minicoal:miniCoal, 8
    >

This should produce a compacting storage drawer for coal that takes coal blocks, coal, and minicoal, but it doesn't.

9 tiny coal :: 1 coal

However, change the 8 pieces to 9 and everything suddenly works.

recipes.removeShaped(<minecraft:coal:0>, [[<ore:miniCoal>,<ore:miniCoal>, <ore:miniCoal>], [<ore:miniCoal>, null, <ore:miniCoal>], [<ore:miniCoal>, <ore:miniCoal>, <ore:miniCoal>]]); 
recipes.addShapeless(<minecraft:coal:0>, [<ore:miniCoal>, <ore:miniCoal>,<ore:miniCoal>,<ore:miniCoal>,<ore:miniCoal>,<ore:miniCoal>,<ore:miniCoal>,<ore:miniCoal>,<ore:miniCoal>]);

^{Above, the only change is that the 2nd line simply has one additional <ore:miniCoal>, in the array.}

registries {
    S:compactingRules <
	minecraft:coal:0, minicoal:miniCoal, 9
    >

^{Above, the only change is that the relevant line contains 9 instead of 8.}

I'll dig around. I'm certain I removed the limit a while ago and I don't see anything obvious in code, so it must be broken someplace less obvious.

I'm not seeing it...

I tested with actuallyadditions tiny coal, and put this in my rule list:
minecraft:coal, actuallyadditions:itemMisc:10, 8
It populated a drawer with a x8 conversion.

I did find one potential problem: the compacting rule list was getting processed during the pre-init pass, so it may have tried to apply rules before other mods registered their items. When you did your testing above, did you change your rule from 8 to 9 before starting the game, or from the in-game mod options menu?

When you did your testing above, did you change your rule from 8 to 9 before starting the game, or from the in-game mod options menu?

Before starting the game.
I tried both ways, but ultimately I resorted to always shutting client & server down, changing it in the configs, and then restarting them. Changes never seemed to 'go live' when made through the in-game mod options menu, nor using forge's /reloadconfigs and minetweaker's mt /reload in-game.

Might it indeed be related to mod order? I've had mixed success getting things added so far - mod order being a confounding factor might explain it. For instance, I've tried..

• minecraft:wool, minecraft:string, 4 worked
• minecraft:stone, minecraft:stonebrick, 1 + minecraft:stonebrick, minecraft:stonebrick:3, 1 worked
• minecraft:stone:5, exnihiloadscensio:itemPebble:3, 4 didn't work (didn't try minetweaker)
• minecraft:ender_pearl, enderio:itemPowderIngot:5, 9 worked after adding recipe in minetweaker:
  recipes.addShapeless(<enderio:itemPowderIngot:5> * 9, [<minecraft:ender_pearl>]);

The only ones that worked without any extra steps were the ones using only vanilla items.

Otherwise, one thing I did observe is that when I'd make the change on the ingame menu (on the client only), it'd display as if it worked -- but only for a frame.
What I mean is that after making the change there, rightclicking on an empty compacting drawer with tiny coal would, for literally about a single graphical frame, draw the drawer with all three appearing(*) but then immediately redraw with just the tiny coal up top and nothing else.
I experienced the same thing when adding wool->4x string in-game too, which is what originally led me to try restarting everything (which succeeded for that recipe).
I suspected that was simply from it not getting properly set on the server configs, though.

*In other words, coal block up top, normal coal on the bottom left, newly added tiny coal on the bottom right, exactly as desired

I'm actually surprised that the configs I pasted in my first reply didn't work, though.

They are 100% repeatable for me.

That actually pushes me further toward suspecting something like mod order is playing a part. I would absolutely have expected your config with the aa tiny coal to not work, from my testing.

When I get a chance I can see about making a forge profile with mods stripped down to just storage drawers and minetweaker and see what happens with some other purely vanilla items, and then try adding just minicoal/actuallyadditions/etc and see what happens.

the compacting rule list was getting processed during the pre-init pass, so it may have tried to apply rules before other mods registered their items

90% sure this is it.

Otherwise, one thing I did observe is that when I'd make the change on the ingame menu (on the client only), it'd display as if it worked -- but only for a frame.
What I mean is that after making the change there, rightclicking on an empty compacting drawer with tiny coal would, for literally about a single graphical frame, draw the drawer with all three appearing(*) but then immediately redraw with just the tiny coal up top and nothing else.
I experienced the same thing when adding wool->4x string in-game too, which is what originally led me to try restarting everything (which succeeded for that recipe).
I suspected that was simply from it not getting properly set on the server configs, though.

Client changes won't affect server, and the server will enforce its version of truth.

90% sure this is it.

If Drawers & Bits is present in the pack, SD is probably getting boosted much higher in the load order. Otherwise it usually loads late enough that you might miss this behavior.

There will probably be a new release out tonight.

The load order fix is out in 3.7.8/4.2.8.