I decided to set my sights on this mod, it's fairly new and adds a length-3 inserter using the purple icon from the old "Filter inserter".

Curious to see what happens when I load it with More Long Inserters, the Extra Long is ignored (obviously don't try to make a long version of it) and not moved to your new subgroups (similar to the Steam inserters when we were testing the IR3 Patchset).

I'm not sure what you consider correct behaviour when you find an inserter you haven't encountered before, but since your description says this:

I wanted an inserter mod that dynamically added a long inserter variant for every inserter in the game, being compatible with as many inserter mods as possible, while also adhering to a proper menu order

I thought I'd bring it to your attention. Presumably there's a reason why you don't take everything in data.raw.inserter and add it to your subgroup.

(Don't try loading Extra Long Handed Inserter with your build of the IR3 Patchset, it will crash.)

Off-topic aside: I'd like to know how you were able to host these images on the Factorio servers for your Information page, without adding them to the Gallery.

Hm, while the current implementation (leaving all unsupported inserters behind in the original subgroup) isn't entirely wrong, it would probably be better to make some kind of attempt to sort the ones that aren't fully supported.

The sorting logic is actually pretty annoying to deal with for what it is; it's basically entirely hard-coded, with the only major differences depending on the number of modded inserters in the game.

Under mostly vanilla conditions (less than 10 total inserters), then they can all fit in one row, which are sorted by base, long (in the order of burner, yellow, blue, bulk, stack). This excludes Heat, Nutrient, and Pipe, which I believe get sorted into different rows, separate from the vanilla ones.

If there are less than 20 total inserters, then they can all fit into two rows, which are separated by base and long variants (in the order of burner, yellow, blue, bulk, stack). Modded inserters generally fall next to the most appropriate inserters, like steam next to burner, faster-non-bulk after blue, faster bulk after bulk, faster stack after stack, etc. Oh, and Pelagos gets its own rows as well, for their diesel powered inserters (since there are multiple and use different fuel type)

And then the most common scenario, more than 20 total inserters or complex burner setting enabled; row 1 gets burner, steam, Pelagos diesel; row 2 gets base electric; row 3 gets long variants; and then heat/nutrient/pipe inserters fall into rows 4-6 (yes, we seriously need that many rows)

And then of course, anything that's not in the list gets left behind.

I suppose if I wanted to do this automatically, I'd probably keep the simplest variation as it is (under 10 inserters, use manually coded sorting), otherwise group by fuel type (burner/steam/diesel), then electric arm length 1, electric arm length 2, electric arm length.. more than 2, and then my heat/nutrient/pipe inserters after that. Hmmm... I'll work on that after my other work is completed (currently focused on space things)

Off-topic aside: I'd like to know how you were able to host these images on the Factorio servers for your Information page, without adding them to the Gallery.

I'm honestly surprised those are getting factorio-based domain links, considering that the images on the mod portal are linked directly from imgur.

Must be some sort of caching thing, because doing the same thing to the image posted above shows the proper imgur link

Must be some sort of caching thing, because doing the same thing to the image posted above shows the proper imgur link

I think we have the answer. Imgur blocks several countries including mine so I can't see that version of the image, and the devs are doing us a favour.

I don't envy the mission you've taken on with this mod, it doesn't sound easy.

Just thinking through how I'd sort inserters in pseudocode, after you generate your long variants.

Let W = data.raw["utility-constants"].default.select_slot_row_count (the width of one recipe row)
Let T = the total number of non-hidden entries in data.raw.inserter with valid crafting recipes

Sorting from major to minor:

• Arm length (ascending), each of these buckets would be one subgroup
• Power source
  • Solid fuels (burner, then nutrients)
  • Fluid fuels
  • Heat
  • Electricity
• Forced stacking (non-stacking before stacking)
• Swing speed (slowest to fastest)

If T <= W (all fit on one row), Arm length becomes the most minor sort criterion after Swing speed.

If there are any rows which exceed W, split by the next minor criterion until they're short enough.

Then maybe a final pass to try and combine adjacent rows if they both fit in <= W.

I've also been working on this one, and it's definitely had its ups and downs. Bright side, I have the new logic working for the most part, just have to iron out the edge cases.

Specifically, diagonal inserter doesn't really have a good place; it's pretty late in the tech tree when Igrys is enabled (locked behind Igrys, which is locked behind Vulcanus), otherwise it unlocks at Automation-1, with the basic long inserters.

And of course, the extra long inserter, which is a unique one-of, appears to be faster than a long inserter (which itself is already faster than a basic yellow inserter) but still slower than a fast inserter.

Piped inserters logic is generic enough to have made piped versions of both, which puts them out of sync with the nutrient, heat, and long inserter rows (and is already bugged on top of that, since I didn't see stack pipe inserter in my testing).

I'm thinking I might just have to add diagonal compatibility to heat, nutrient, AND long inserters, just to align with row 1 again (maybe give them more use, since I saw somebody on the Foundry discord asking about the use of diagonal inserters in general), and then add extra long versions of every inserter in the game for yet another row. Most of the logic for that is already in place, just need to splice the graphic and then duplicate the long inserter table.

Aaand I just realized more heat inserters logic is also broken; I wanted to see if that would still work with the new row sorting logic, but it just doesn't work at all, even with the old logic. So many fixes, so little time

Finally implemented the sorting functionality, and expanded the More Long umbrella to include diagonal and extra-long inserters

So if complex burners are enabled, you get burner, burner diagonal, burner long, burner extra long, burner bulk, burner stack; if disabled, the burner, burner long, and burner extra long go in front of their electric variants; the electric rows should go by burner, base, diagonal, fast, bulk, stack

I just wanted to release the thing already, so I still haven't fixed the more heat inserters logic, didn't even look at it, maybe I'll come back to fix that later.

Heat and nutrient do not have diagonal/extra long compatibility yet, but the latest version of pipe inserters does, so those are also tbd, but I think the sorting looks good enough for now.

EDIT: I just noticed your comment about supporting Extra Long with More Long with IR3, whoops. I didn't re-test any of the new changes with IR3 at all, hope that doesn't mess anything up for you (or worse, mess things up in a way I need to fix from my end)

Using just More Long Inserters with IR3 gives me three rows of inserters (which I assume is intended):

• Burner / Steam inserters and their long versions
• Electric inserters
• Long Electric inserters

All of the overlay icons work correctly as well.

I've recently added support for using Stack inserters from the mod by Xorimuth. These are working correctly, as well as adding them from Space Age the usual way.

Adding "Extra Long Inserter" into the mix causes the game to crash with this error on load:

Failed to load mods: File __kry-inserters__/graphics/icons/dir-base-extra-long.png not found

Obviously failing to find an IR3-specific icon. Not sure why, since it should be using the red base like the other electric inserters.

(Just to jog your memory, Extra Longs use the purple "Filter Inserter" icon from 1.1.)

Ahh, that makes sense; extra longs use a different base than long (purple base instead of red base), and the IR3 check I added for long is vague enough to apply to extra long as well. It should probably be using the extra long base regardless, or maybe an alternative, depending on what looks better.

Aaand I might have forgotten to apply the extra long overlay image (unless I did it months ago), but so far, two easily fixable issues (at least until we see how it looks when the game loads lol)

Hold on a minute, why are we changing the base of the Extra long inserter..?

(Shemp loads the game using only More Long Inserters and Extra Long Inserter together.)

OH! You're making everything into an extra-long version, how unexpected! I only wanted the singular Extra long to get put into the right subgroup. This development might warrant some more detailed conversation...

I'll need to think about how to approach recipe costs and research, but I noticed that the standard Extra long unlocks at "Automation 2" and you put the burner version there, then the higher versions (bulk, stack) unlock with their respective techs.

In IR3, I've put the Extra long into the "Inserters 2" tech (ir-inserters-2, next to the Fast inserter) and I don't expect any burner/steam versions to be available early, so with some luck, your normal recipe/tech handling code will put everything in its right place.

EDIT: I also happened to test Bob's Adjustable Inserters since I just added compatibility for it, and it seems you've already done so as well. Everything works as expected.

I made a special overlay icon just for Extra longs too, here it is:

-- Draw the blue arrows overlay icon
local setting = settings.startup["ir-inserter-overlays"]
if setting and setting.value == "on" then
    -- Give this overlay icon a distinct colour and style to
    -- distinguish it from the length-2 inserters
    table.insert(inserter.icons, {
        icon = "__base__/graphics/icons/arrows/signal-left-right-arrow.png",
        tint = {0.5, 0.9, 1.0},
        icon_size = 64,
        icon_mipmaps = 4,
        -- The vanilla icon is a bit smaller than Deadlock's one
        scale = 0.4,
        shift = {-8, 8},
        -- This goes out of bounds, but we don't want to shrink the
        -- overall icon
        floating = true,
    })
end

LOL Yup, I was putting off the Extra Long/Diagonal compatibility because I knew it would be time-consuming, but I knew the end result of fully integrated compatibility would look better than just the minimal sorting compatibility. I also had this other request earlier and decided I might as well try, and the end result turned out fairly well (in terms of the crafting menu, at least)

I didn't pay too much attention to the technologies, apart from ensuring the unlocks.. existed lol. I suppose I should go back and check that they are following their base form inserter (though burner extra long should follow the same logic as burner long)

So I guess that's 3 things to look at now: missing dir-extra-long image file, apply extra long overlay icon, and check tech unlocks match base form inserters.

Okay, so I can't test IR3 compatibility directly, since even after attempting to patch IR3 with the latest update, I keep getting technology loop errors when attempt to load with Extra Long (before even attempting to add More Long). It loads up fine with just IR3 and More Long, but you already knew that

Looks like the only oddity involving the techs is extra-long-fast being available with red science, before the base form extra-long which requires red/green, but I can fix that from my end. Although that means extra-long-fast can technically be researched.. without getting the original fast inserter first, which is its own oddity, but meh, close enough.

I don't think there's any code regarding bob's adjustable inserters? Since boblogistics is the one that adds new inserter variants. Unless you meant tech-wise? That does make sense, since the technology matching logic is relatively dynamic

Anyways, I put in the new code to attempt to fix compatibility anyways, reusing most of what I did for long inserters, so it should work? But again, can't really test. Implemented the potential fixes in v5.1.23

EDIT: Fully implemented in v5.1.24