[MOD 0.16] Miniloader

[lordkrike]

Therax,

Thanks for your hard work. Your support of a free mod is unreal. That's how many updates in a week?

[Inspired]

Hi, thank you for the hard work!

Another Bug Report. When trying to create a blueprint of a single building (by clicking on the same spot) an error appears that zero size is not supported.
Here is the screenshot:


With the mod disabled the same action works.

[staviq]

Hi,

I think 0.16.17 broke something because i haven't had this problem before: Express Minloader is too slow for Express belt:

https://youtu.be/a4IIyvLV6BM

EDIT:

It only happens so far if there are many diffrent items on a belt, it does work fine if only one type of item is on a belt, so if you are goint to test this, make a mess on the belt

[Therax]

I went through the mods, and for some reason changing 1 to 2 in tech_reqs on line 215 in data.lua fixes the issue:
local main_prereq = data.raw["technology"][tech_prereqs[2]]

Didn't really understand why, but it works, so feel free to make that change if it suits you.

This would unfortunately change the costs of the technologies, so it's not really a viable option. I changed the way tech_prereqs are processed slightly, which may fix your problem. If it does, it points to a bug, possibly in Omnimatter or Omnimarathon, but I'm unable to test those mods (they're crashing at launch for me, even with no other mods enabled).

Another Bug Report. When trying to create a blueprint of a single building (by clicking on the same spot) an error appears that zero size is not supported.

I'm pretty sure this bug report was intended for Bulk Rail Loaders, but was posted to this thread because of a bug in the mod portal. I'm working on a fix nevertheless.

It only happens so far if there are many diffrent items on a belt, it does work fine if only one type of item is on a belt, so if you are goint to test this, make a mess on the belt

Thanks for this hint! I was able to track down the problem, and it's not 0.16.17, but a bug I introduced back when fixing Nanobots support. It should be fixed in v1.5.7.

[SqFKYo]

This would unfortunately change the costs of the technologies, so it's not really a viable option. I changed the way tech_prereqs are processed slightly, which may fix your problem. If it does, it points to a bug, possibly in Omnimatter or Omnimarathon, but I'm unable to test those mods (they're crashing at launch for me, even with no other mods enabled).

Would you like to elaborate what you did? It solved the issue, so it would be very interesting to see how to avoid the problem in the future.

[Therax]

Would you like to elaborate what you did? It solved the issue, so it would be very interesting to see how to avoid the problem in the future.

The Miniloader techs take their cost from their first prerequisite, so in the case of the yellow miniloader, from Logistics 2 (red+green). This happened by Lua reference, which had the nice property that any mod that changes the cost of Logistics 2 would also change Miniloader. From looking at Omniscience, it looked to change the costs of techs that take blue tier or higher science, so I wouldn't have expected Logistics 2 or Miniloader to be affected, but I guess it's doing something more complex.

My change was to make a copy instead of a reference, which loses the link between the cost of the two techs.

[SqFKYo]

The Miniloader techs take their cost from their first prerequisite, so in the case of the yellow miniloader, from Logistics 2 (red+green). This happened by Lua reference, which had the nice property that any mod that changes the cost of Logistics 2 would also change Miniloader. From looking at Omniscience, it looked to change the costs of techs that take blue tier or higher science, so I wouldn't have expected Logistics 2 or Miniloader to be affected, but I guess it's doing something more complex.

My change was to make a copy instead of a reference, which loses the link between the cost of the two techs.

Thanks for the explanation. This is very weird. Omniscience's basic idea is to first give omnipacks to specific techs, and then attach omnipacks to each tech that requires those techs as prerequisite.

[staviq]

It only happens so far if there are many diffrent items on a belt, it does work fine if only one type of item is on a belt, so if you are goint to test this, make a mess on the belt

Thanks for this hint! I was able to track down the problem, and it's not 0.16.17, but a bug I introduced back when fixing Nanobots support. It should be fixed in v1.5.7.

Thanks !

[orzelek]

Would you like to elaborate what you did? It solved the issue, so it would be very interesting to see how to avoid the problem in the future.

The Miniloader techs take their cost from their first prerequisite, so in the case of the yellow miniloader, from Logistics 2 (red+green). This happened by Lua reference, which had the nice property that any mod that changes the cost of Logistics 2 would also change Miniloader. From looking at Omniscience, it looked to change the costs of techs that take blue tier or higher science, so I wouldn't have expected Logistics 2 or Miniloader to be affected, but I guess it's doing something more complex.

My change was to make a copy instead of a reference, which loses the link between the cost of the two techs.

What you describe would happen if any of Omni* mods actually replaces technology. You would end up with reference to it's previous version and that could have interesting consequences. It's a bit of a guess without actually debugging it

[Therax]

What you describe would happen if any of Omni* mods actually replaces technology. You would end up with reference to it's previous version and that could have interesting consequences. It's a bit of a guess without actually debugging it

It seems like I'd see the opposite effect: changes intended be Omniscience would be missing, rather than what we're seeing, unintended changes propagating to strange places.

[Inspired]

Another Bug Report. When trying to create a blueprint of a single building (by clicking on the same spot) an error appears that zero size is not supported.

I'm pretty sure this bug report was intended for Bulk Rail Loaders, but was posted to this thread because of a bug in the mod portal. I'm working on a fix nevertheless.

Yeah, my bad, should have specified that. This is the thread Mod portal redirects to, so I posted it here.

[pleauser]

I experienced an oddity tonight. I created a blueprint of two loaders connected by green wire, after setting them to enable if anything > 0.
it appeals to me to have the game automajikally create green (or red) wire

i then pasted the blueprint over the other 4 or so loaders next to them and then, slow on the uptake, realized that those pasted loaders, although they had the same apparent settings and were wired
were outputting on one side still as if they are not connected to the circuit network. manually removing and replacing the wiring did the trick. I don't have the time to give more detail,
its the same map save i shared before just with newer versions, the same area too. just expanded lead storage :-p

edit: if you need more detail, of course, I can get it.. just won't be til tomorrow. friday after work

[staviq]

Hi.

I have just noticed, the Miniloader versions for Bob's mods ( Faster miniloader and Extremly fast miniloader ), have the exact same speed.

Tested with this setup, all 3 chests are loaded with 1k of anything, bottom 2 miniloaders finish at the exact same time, and blue one finishest last as it is supposed to.

I'm not sure if it's related somehow, but the original Loader Redux mod had the exact same issue.

[Therax]

I have just noticed, the Miniloader versions for Bob's mods ( Faster miniloader and Extremly fast miniloader ), have the exact same speed.

Tested with this setup, all 3 chests are loaded with 1k of anything, bottom 2 miniloaders finish at the exact same time, and blue one finishest last as it is supposed to.

I'm not sure if it's related somehow, but the original Loader Redux mod had the exact same issue.

As I recall, this is because the loaders are directly next to each other with no belt in between. This means the distance an item has to travel at belt speed is something like 0.1 tile, which effectively removes the belt as the bottleneck and throughput is instead limited by tick rate. Can you test again with at least 1 belt segment between the miniloaders?

I don't remember the exact details from my testing, but it was something like this:

For a blue belt, it takes two ticks for an item to leave the tile it starts in (from where the loader or inserter entity drops it) to the adjacent tile, where the other loader can pick it up. As soon as the second loader removes the item from the belt, that immediately makes room for another item to be put on the belt by the first loader. This is contrast to when there's at least one belt tile in between, where the item has to move the width of an item-on-ground entity (7 pixels IIRC) before the next item can be placed on the belt. For a green or purple belt, it takes 1 tick. Actual tick numbers are probably different, but this gives the idea of the quantization effect I'm getting at.

Without any belt segments, the flow is more comparable to chest-to-chest inserter throughput with no stack bonus, or perhaps assembler-to-ground-to-assembler inserter handoff. Loader Redux would be the same, except with vanilla loader entities instead of inserters.

[Deadlock989]

Been doing some modding myself this weekend (link) and ran into an issue with red miniloaders. I've been making belt stacking machines which have recipes which produce output exactly calibrated to the speed of yellow, red and blue belts. Red miniloaders don't quite compress the belt no matter how much I fiddled with the maths. For the longest time I thought it was a rounding problem at my end, but when I use vanilla loaders or Loader Redux the problem goes away (and they're not overloaded, either, because no backlog forms). Yellow and blue miniloaders work perfectly. My hunch is that this is some sort of rounding issue, or perhaps it's because you use inserters and it's something to do with the arm travel time syncing up.

[hreintke]

Using the 1.5.7 version.

When placing two miniloaders on distance 1 there is still flow.

minloader.JPG (41.28 KiB) Viewed 8324 times

Noticed some remarks on underground belts -> I am not using a mod what updates them

[orzelek]

Using the 1.5.7 version.

When placing two miniloaders on distance 1 there is still flow.

minloader.JPG

Noticed some remarks on underground belts -> I am not using a mod what updates them

I think this is side offect of how miniloaders work.
I'd say it might not be a bug but looks a bit strange - like it's "loading" the tile and then "unloading" it further.

[hreintke]

No problem.

I just saw the behavior and wanted to let you know.

I noticed it because I use a lot of miniloader -> chest -> miniloader construction for buffering and belt balancing.

[jamiechi1]

I have had the game crash in the latest builds (version 16) several times when placing this. It always seems to happen if I place the miniloader directly between a requester chest and a train car. It seems that the miniloader needs a belt on one side or the other to work correctly. It may have happened when I clicked R to rotate the mini loader to try to get it to work. This never happens if I have a belt on the input (or output) of the miniloader.

Edit:
Link to files: https://drive.google.com/open?id=1gee-U ... dWiYI9PrDv


@hreintke This probably happens because this is how inserters work in version 16. They place something on the ground and the next one picks it up again.

[Therax]

I have had the game crash in the latest builds (version 16) several times when placing this. It always seems to happen if I place the miniloader directly between a requester chest and a train car. It seems that the miniloader needs a belt on one side or the other to work correctly. It may have happened when I clicked R to rotate the mini loader to try to get it to work. This never happens if I have a belt on the input (or output) of the miniloader.

Do you get an error message when the problem occurs? Can you send a save or instructions on how to consistently reproduce the problem?