[MOD 0.16] Miniloader

[wvlad]

Miniloaders are based on inserters and inserters are limited to 60 items/s when pulling from belts. Any belts faster than 60 items/s are going to see some strange behavior.

Then why it's unloading initially from the duplicating chest with full compression?

[Optera]

Miniloaders are based on inserters and inserters are limited to 60 items/s when pulling from belts. Any belts faster than 60 items/s are going to see some strange behavior.

Then why it's unloading initially from the duplicating chest with full compression?

Like Therax said Miniloader use very fast inserters. That means they have to chase items on belts and can't take items from belts as fast as they can put them on.
It just so happens that a 75 item/s belt is where inserters can put down a compressed belt but no longer pick it up.

2019-03-16-13-51-40-6000112.png (588.79 KiB) Viewed 6392 times

[wvlad]

Miniloaders at "Ultra fast" and faster speeds use vanilla loader entities in addition to inserters, giving a max throughput of ~180 items/second when interacting with chests and other containers

Looks like this feature sometimes doesn't work in my example (even with belt-chest-belt).

[Therax]

Don't nail me down on the 5s. I got rid of a mod adding a super mining tool. Being used to mine everything almost instantly, my perception is a bit skewed.

However it doesn't change that miniloaders take 10 times longer to pick up than belts. 1s vs 0.1s.
For comparison refineries mine in 0.2 and nuclear reactors in 0.5. There's no reason for a loader taking twice as long as a reactor to pick up.

Still sounds like a problem with your mining tool mod. Miniloaders should take as long as 2 belts if it were scaling everything together. Mind dropping a link so I can test?

EDIT: never mind, I misunderstood. I hadn’t realized that mining times had changed because of the elimination of mining tools. I’ll reduce mining time in the next release.

[Therax]

Like Therax said Miniloader use very fast inserters. That means they have to chase items on belts and can't take items from belts as fast as they can put them on.

Just to clarify, it’s not so much the chasing. It’s that every inserter picking up from a belt segment selects an item to chase and pick up at the start of each tick. So adding more inserters and increasing inserter speed still hits this fundamental limit of 1 item targeted per tick.

[wvlad]

Just to clarify, it’s not so much the chasing. It’s that every inserter picking up from a belt segment selects an item to chase and pick up at the start of each tick. So adding more inserters and increasing inserter speed still hits this fundamental limit of 1 item targeted per tick.

I thought the mod uses 2 inserters (1 per belt lane) therefore the total throughput should be 60x2=120 items/s

[Guilty]

Just to clarify, it’s not so much the chasing. It’s that every inserter picking up from a belt segment selects an item to chase and pick up at the start of each tick. So adding more inserters and increasing inserter speed still hits this fundamental limit of 1 item targeted per tick.

I thought the mod uses 2 inserters (1 per belt lane) therefore the total throughput should be 60x2=120 items/s

I was under the same impression...

[Therax]

Just to clarify, it’s not so much the chasing. It’s that every inserter picking up from a belt segment selects an item to chase and pick up at the start of each tick. So adding more inserters and increasing inserter speed still hits this fundamental limit of 1 item targeted per tick.

I thought the mod uses 2 inserters (1 per belt lane) therefore the total throughput should be 60x2=120 items/s

I was under the same impression...

The key phrase is “every inserter.” It doesn’t matter if you have 100 inserters, they all select the same item at the start of a tick, and only one of them can succeed in picking it up. The next tick the other 99 repeat the process.
Here’s the bug I posted.

[Guilty]

Just to clarify, it’s not so much the chasing. It’s that every inserter picking up from a belt segment selects an item to chase and pick up at the start of each tick. So adding more inserters and increasing inserter speed still hits this fundamental limit of 1 item targeted per tick.

I thought the mod uses 2 inserters (1 per belt lane) therefore the total throughput should be 60x2=120 items/s

I was under the same impression...

The key phrase is “every inserter.” It doesn’t matter if you have 100 inserters, they all select the same item at the start of a tick, and only one of them can succeed in picking it up. The next tick the other 99 repeat the process.
Here’s the bug I posted.

I guess there's nothing to be done. Miniloader is very fast as is for vanilla belts I suppose.

[Cadde]

He could make a "long" miniloader for ultimate belts that would work on two belt pieces at the same time. Then the limit would be 120 items/s.
But i would rather they added more belt specific LUA stuff so one could control items on belts directly through LUA without the need of inserters.

[orzelek]

He could make a "long" miniloader for ultimate belts that would work on two belt pieces at the same time. Then the limit would be 120 items/s.
But i would rather they added more belt specific LUA stuff so one could control items on belts directly through LUA without the need of inserters.

You can control items on belts through lua. And performance of this was more then 10 times worse then inserters AFAIK. There is simply no way you can match inserter performance. Even actual loaders are less performant.

[zOldBulldog]

I should have said it a long time ago, but better late than never. Thank you Therax for such a great and simple mod. It made my train loads and unloads so much simpler and cleaner.

It was fun to figure out all the vanilla ways of doing train stations, but it eventually got old and space-wasteful. Now your mod (and a few in-line buffer chests) is all I use for them. I can't see myself ever going back.

BTW... also thanks for already having released the version for 0.17.

[Cadde]

You can control items on belts through lua. And performance of this was more then 10 times worse then inserters AFAIK. There is simply no way you can match inserter performance. Even actual loaders are less performant.

Well OK then, what i meant to say was "Do it efficiently".

[enchant]

Sadly, 0.17.23 (and the latest Bob's updates) breaks the turbo/ultimate miniloaders.

https://steamcommunity.com/sharedfiles/ ... 1698744818

[Therax]

0.17.23 changed some requirements on technology naming, and Bob’s had to change his mods to respect that. If you don’t want to wait for the next official release, there is a workaround available:

https://mods.factorio.com/mod/miniloade ... 000b9961f4

[enchant]

That worked. I'm totally shocked! Not that it worked, but that I did the edit correctly.

Thanks!

[eduran]

On my current map I would like change a large number of old loaders (they are size 1x1) into miniloaders via a migration mod. This is the code I wrote so far:

Code: Select all

local function replace_entities(old_name, new_name)
  local s = game.players[1].surface -- only for myself in single player
  for chunk in s.get_chunks() do
      local entities = s.find_entities_filtered{name=old_name, area={{chunk.x*32, chunk.y*32}, {(chunk.x+1)*32, (chunk.y+1)*32}}}
      for _, entity in pairs(entities) do
          local position = entity.position
          entity.destroy()
          local new_entity = s.create_entity{name=new_name, position=position, force=game.players[1].force}
      end
  end
end

It works for replacing simple entities. But miniloaders consist of multiple entities and have an orientation. Any help on getting this to work is appreciated.

[Therax]

It works for replacing simple entities. But miniloaders consist of multiple entities and have an orientation. Any help on getting this to work is appreciated.

You probably don't need to walk over the surface chunk by chunk. A single call should suffice:

Code: Select all

local entities = game.surfaces.nauvis.find_entities_filtered{name=old_name}

You'll want to raise on_built_entity after each call to create_entity, providing all of the proper options for the new entity. I don't know what old loaders you are using, so I'm afraid I can't tell you how to correctly extract orientation from them. As long as you get the direction correct, I hope that Miniloader's snapping logic would take care of most of your cases, but I'd advise checking things over after you run your script.

[eduran]

Thank you, I think I am almost there now:

Code: Select all

local function replace_entities(old_name, new_name)
  
  local surf = game.surfaces.nauvis
  local entities = surf.find_entities_filtered{ name = old_name }
  for _, entity in pairs(entities) do
    local position = entity.position
    local direction = entity.direction
    entity.destroy()

    local new_entity = surf.create_entity{name = new_name, position = position, direction = direction, force = game.players[1].force}
    script.raise_event(defines.events.on_built_entity, {created_entity = new_entity, player_index = 1, stack = nil})
  end
end

Old loaders are the ones from Deadlock Stacking & Beltboxes. replace_entities is called like so for yellow loaders:

Code: Select all

replace_entities("transport-belt-loader", "miniloader-inserter")

It does properly replace all loaders with functional miniloaders. However, passing direction on its own does not work quite right. Half of the miniloaders are facing backwards and all of them have belts going in the wrong direction.

before.jpg (72.25 KiB) Viewed 6104 times

after.png (709.65 KiB) Viewed 6104 times

Is this something that is fixable in my code or do I need to do it manually?

[Therax]

That seems like a snapping bug. Do you have the snapping setting turned on?