[MOD 0.16] Miniloader

[jodokus31]

I have another idea.
I have many use cases, where I want to output a mixed lane of items from a trainstation warehouse f.e. iron on one side and copper on the other
At the moment I just use 2 loaders, one set to filter iron and the other for copper and then side load them to one belt.
Sometimes I need many outputs and the Warehouse has 12 useable output slots (at least in my setup). Sometimes, I take 2 long filter inserters on one slot to save space.

Bildschirmfoto vom 2018-06-13 10-08-40.png (1.9 MiB) Viewed 6944 times

My idea:
Would it be possible to create an option on the miniloader to output a mixed lane? That would be very neat, maybe cheaty

[Therax]

Would it be possible to create an option on the miniloader to output a mixed lane? That would be very neat, maybe cheaty

I think this would be possible. I'm not sure how to let the user configure it, though. Creative Mode lets you do this by using 2 different filter slots in the same inserter, and then using Lua scripting to actually create the items, but Miniloaders actually use the filter slots on its inserters for... filtering. It would also be challenging to capture the settings in blueprints and recreate them.

[jodokus31]

Would it be possible to create an option on the miniloader to output a mixed lane? That would be very neat, maybe cheaty

I think this would be possible. I'm not sure how to let the user configure it, though. Creative Mode lets you do this by using 2 different filter slots in the same inserter, and then using Lua scripting to actually create the items, but Miniloaders actually use the filter slots on its inserters for... filtering. It would also be challenging to capture the settings in blueprints and recreate them.

Thank you for analysis. I don't have any idea either. Maybe some sort of additional UI like Bobs inserter does... Or connecting f.e. a "constant combinator" via circuit network to configure (which would also start to diminish the neatness)
But I don't know if it is worth for some cases, where it would be handy.

[Therax]

Updated to 1.6.0. I finally got around to working up new graphics that are more in keeping with vanilla belt graphics, and that don't have nasty overlap with assemblers due to the previous graphics being larger than a 32x32 pixel tile. Let me know what you think!

[eradicator]

Let me know what you think!

I never used Deadlocks loaders because i found them too flat/plain. I always liked that redux loaders (which you based yours off i think?) had more structure to them than a flat cuboid. It also made them better distingushable from undergrounds on a glance. Sure, they did look a bit like plastic toys, and if it fixes the overlapping... So that's that. Now may come the hords of praisers who love change for the sake of change [/sarcasm] :P.

[Therax]

I never used Deadlocks loaders because i found them too flat/plain. I always liked that redux loaders (which you based yours off i think?) had more structure to them than a flat cuboid. It also made them better distingushable from undergrounds on a glance. Sure, they did look a bit like plastic toys, and if it fixes the overlapping... So that's that. Now may come the hords of praisers who love change for the sake of change [/sarcasm] .

And here I was expecting you'd like the change because of the fix for sprite layering artifacts at long last.

[eradicator]

I never used Deadlocks loaders because i found them too flat/plain. I always liked that redux loaders (which you based yours off i think?) had more structure to them than a flat cuboid. It also made them better distingushable from undergrounds on a glance. Sure, they did look a bit like plastic toys, and if it fixes the overlapping... So that's that. Now may come the hords of praisers who love change for the sake of change [/sarcasm] :P.

And here I was expecting you'd like the change because of the fix for sprite layering artifacts at long last. :)

Protip: I'm always the first at the pitchfork-rental-service when change happens! :p
(Also apparently i rewrote that post one time too often, because i was certain that i mentioned that i do indeed like the fixed layering.)

[Dunsay]

Thanks for a great mod, therax!

I may have discovered a (minor) bug:
When a belt is fully compressed and less than 50% of the total belt capacity is consumed, miniloaders seem to only pull items from a single lane of the belt. Seems to be consistently left side.

I realize this may be a side-effect from using inserters internally to pull items off a belt, considering that inserters do prioritize pulling from one side even when placed at the end of a belt.

[Therax]

I realize this may be a side-effect from using inserters internally to pull items off a belt, considering that inserters do prioritize pulling from one side even when placed at the end of a belt.

That's correct. Inserters can't be setup to prefer picking up from any particular lane. They bond to an entity, and for belts that means they prefer one side over the other. It's not usually an issue when using miniloaders for bulk transfer and both lanes are consumed. For lower volume applications you may want to put a lane balancer in front if that's important to you.

[eradicator]

I realize this may be a side-effect from using inserters internally to pull items off a belt, considering that inserters do prioritize pulling from one side even when placed at the end of a belt.

That's correct. Inserters can't be setup to prefer picking up from any particular lane. They bond to an entity, and for belts that means they prefer one side over the other. It's not usually an issue when using miniloaders for bulk transfer and both lanes are consumed. For lower volume applications you may want to put a lane balancer in front if that's important to you.

As far as i remember from the "3-lane-splitter" thread and the experiments i did there this isn't entirely true. An inserter prefers to take from the lane that is closest to it's pickup position. This means that if you have two inserters you can have each one of them prefer a different side of the belt, same as on the outputting side. (Unless i rember incorrectly :p).

[Cadde]

I noticed a peculiar thing that happens with my fast miniloaders and construction robots.
This is however not on the most recent version and i don't intend to make a complete bug report but rather a note of sorts.

When you use a deconstruction planner on miniloaders and only miniloaders, ALL construction robots leave their "nest" to deconstruct the miniloaders.
But only the number of bots actually required will pick up miniloaders. Could this be because there's a number of hidden inserters in each miniloader?
Either way, the reason i make this post (and even this account) is because at the same time... A number of miniloaders disappeared from inventory when this happened. That is POOF, gone. I had to shoot in more into the storage chest to complete re-construction by blueprint when everything was supposed to be there already.

Could this be due to the fact more than one construction robot would go to construct or destruct each miniloader in some kind of peculiar race condition?

As i said, i am only making a note of the occurrence. If i had more time and energy to delve deeper i would.

[Optera]

With the flat sprite it would look nice if the circuit connector appeared on the side of the belt entity instead of being hidden inside it.
Would make checking if a loader is connected to logistics network much simpler.

[Medium9]

The most important thing first: Thanks for this amazing mod!! This enables some reeeeally neat builds that wouldn't be possible vanilla, and I also don't think it breaks any complexity or depth. By now I pretty much consider it part of the core game, personally.

I've just now updated to the 1.6.1 version and have two issues with it:

1) When using the deconstruction planner, the loaders will be removed with the underlying tile EVEN IF the planner was set to only remove tiles of a specific type. (I'm currently ridding my base of plain concrete tiling, and have set my planner to "whitelist, only, concrete", and every miniloader of any kind will also be deconstructed if it was placed on concrete. This caused me some major headaches and rebuilding to do. Could this be resolved somehow?
(This was also the case with my last version, which was 1.5.something, so not new with 1.6.1)

2) The new graphics are neat, but the filter loaders do no longer show the filter settings in alt-mode. That's rather inconvenient. Any chance to have them back?


Huge thanks again and take care!

[Therax]

When you use a deconstruction planner on miniloaders and only miniloaders, ALL construction robots leave their "nest" to deconstruct the miniloaders.
But only the number of bots actually required will pick up miniloaders. Could this be because there's a number of hidden inserters in each miniloader?

Yes, this is exactly correct. When you mark an entity for deconstruction, usually you can put a ghost in that tile, which makes it much easier to perform upgrades and mass changes, but that works only if every colliding entity in that tile is marked for deconstruction. So Miniloader marks each of the associated inserters for deconstruction, but as soon as the first robot arrives and deconstructs the first entity, all the rest disappear, so the other bots no longer have any work to do.

It's a bit wasteful of power and bot throughput, which can be an issue with personal roboports, and as you note it's confusing. I could probably change this behavior, but it's not my highest priority given the amount of code work that would be needed.

Either way, the reason i make this post (and even this account) is because at the same time... A number of miniloaders disappeared from inventory when this happened. That is POOF, gone. I had to shoot in more into the storage chest to complete re-construction by blueprint when everything was supposed to be there already.

Could this be due to the fact more than one construction robot would go to construct or destruct each miniloader in some kind of peculiar race condition?

As i said, i am only making a note of the occurrence. If i had more time and energy to delve deeper i would.

There was in fact a bug here, due to a misunderstanding of the order in which robot deconstruction is performed. Thanks for the report!

With the flat sprite it would look nice if the circuit connector appeared on the side of the belt entity instead of being hidden inside it.
Would make checking if a loader is connected to logistics network much simpler.

Good point. I often forget about the logistic network connection graphic.

1) When using the deconstruction planner, the loaders will be removed with the underlying tile EVEN IF the planner was set to only remove tiles of a specific type. (I'm currently ridding my base of plain concrete tiling, and have set my planner to "whitelist, only, concrete", and every miniloader of any kind will also be deconstructed if it was placed on concrete. This caused me some major headaches and rebuilding to do. Could this be resolved somehow?
(This was also the case with my last version, which was 1.5.something, so not new with 1.6.1)

The interaction between tiles and entities when using robots is a bit unusual, and I was missing a case. Thanks for the report!

2) The new graphics are neat, but the filter loaders do no longer show the filter settings in alt-mode. That's rather inconvenient. Any chance to have them back?

Yes, these will be back. Unfortunately there doesn't seem to be a way to hide the inserter arrows, which are redundant with the giant arrows on top of the loader body, while still showing filter icons.

[Optera]

Perhaps my initial idea wasn't thought through well.
Placing connectors on the side for vertical orientations will always make them clip into neighboring entities.

2018-10-08-13-12-13-6482385.png (68.69 KiB) Viewed 6585 times

For horizontal orientations the position could be the south wall, but that would clip too

2018-10-08-13-11-26-8487201.png (63.54 KiB) Viewed 6585 times

That basically leaves only connectors on top of the loader akin to belts as option that would look good.

[eradicator]

When you use a deconstruction planner on miniloaders and only miniloaders, ALL construction robots leave their "nest" to deconstruct the miniloaders.
But only the number of bots actually required will pick up miniloaders. Could this be because there's a number of hidden inserters in each miniloader?

Yes, this is exactly correct. When you mark an entity for deconstruction, usually you can put a ghost in that tile, which makes it much easier to perform upgrades and mass changes, but that works only if every colliding entity in that tile is marked for deconstruction. So Miniloader marks each of the associated inserters for deconstruction, but as soon as the first robot arrives and deconstructs the first entity, all the rest disappear, so the other bots no longer have any work to do.

An interesting problem (need to think about my own mod in that regard). But my immedeate reactions are:
1) Why is there more than one colliding entity per loader? Shouldn't it be sufficient if only one part has a collision_box?
2) Failing that i guess you could remove all but one entity in on_marked_deconstruct and put them back in on_cancel_deconstruct, but that is clearly a lot more code.

[Therax]

That basically leaves only connectors on top of the loader akin to belts as option that would look good.

This solution is (I think) not possible as well, due to sprite draw order. Each miniloaders consists of at least 3 entities: a loader to provide the belt and one or more inserters per lane depending on belt speed.

One of the inserters is the entity that is actually circuit connectable and renders the wire connector, but inserter bases (platforms) are always rendered before/under items on belts, which are themselves rendered before the loader body/structure. So there's a very tricky dance between the inserter's base sprite, the circuit connector sprites (including LEDs and wire connectors, which are selectively rendered based on configuration and circuit vs logistic network connection), the belt sprites, sprites of items on belts, and the loader's structure sprite.

I was never very happy with the way the circuit connector displayed with the old sprites either. As far as I can it is impossible to fit a circuit connector entirely within the tile. There needs to be a "window" in the loader structure sprite for the connector to be visible at all, and that window allows items on the belt to "peek" through the supposedly solid loader structure.

[Therax]

1) Why is there more than one colliding entity per loader? Shouldn't it be sufficient if only one part has a collision_box?

A belt connectable entity, including a loader, is required by the Factorio core to have a collision box. I think this is so the tile footprint of the belt can be computed and then used by inserter logic to determine if the belt is under an inserter's pickup or drop points. However, the placeable entity for a miniloader is an inserter, because loaders are not circuit connectable. This needs to have a collision box to accurately tell the player where it can be placed when in the cursor stack or in blueprints.

I could have a placement proxy entity for cursor and blueprint purposes, replaced via scripting. This is what I do in Bulk Rail Loaders, in fact, but it would be quite a bit of work to move Miniloader to that model.

2) Failing that i guess you could remove all but one entity in on_marked_deconstruct and put them back in on_cancel_deconstruct, but that is clearly a lot more code.

This gets even worse because each of the entities has an inventory as well: items on the belts or in inserter hands. These items would need to be stored somewhere like an invisible chest and then restored as well. They can't be simply scripted state, i.e. In a Lua table somewhere, because some items have identity and their own internal state (blueprints, armor, Factorissimo buildings, etc.).

[eradicator]

(blueprints, armor, Factorissimo buildings, etc.).

I love how you point out the importance of factorissimo buildings on belts :D. But yea, the migration to placement proxy would be quite a bit of work. Though i don't think you need it to work for blueprints. Blueprints should be able to work like they do right now, and the only difference would be when the player initially places the entity via proxy? I don't know your exact internal structure but it could be something like: proxy_item.place_result = $whatever_your_current_place_result is and then $whatever_your_current_place_result.placeably_by = proxy_item. But i'm sure i'm missing some stupid edge case again.

[Medium9]

The interaction between tiles and entities when using robots is a bit unusual, and I was missing a case. Thanks for the report!

Yes, these will be back. Unfortunately there doesn't seem to be a way to hide the inserter arrows, which are redundant with the giant arrows on top of the loader body, while still showing filter icons.

Thanks for the feedback, your great work, and also the super interesting in-depth discussions here (also with other users). As a dev myself (I just haven't gotten into modding yet), it's always ejoyable to get a whiff of the intricacies of the game and the mod API.

I have no qualms with the inserter arrows (although I was irritated by that only one is shown now on the exits, but they gladly work the same). When in alt-mode the arrows on top of the loaders would mostly be hidden by the filter icon anyways I'd assume, so they will actually be beneficial especially when zoomed out a bit.

Edit: Woah woah! I've just seen that you already released a new version with both my points looked at! You're FAST! And off I am, looking at the new goodness

Edit2: Ahhh, now I see what you mean. The arrows cover a good bit of the filter icons. Mhhh, that's nasty. If they were juuuust a bit smaller, but I fully understand that this is out of your hands. Thanks nevertheless - 1/3 of an icon is still miles better than none, especially when you just want to check if all unloaders of your huge LTN end point have been set (which was mostly what prompted my desise to have them back; I missed a couple...)

And I see there are also yet again both arrows on the output, so that point in my original answer is moot. Overall definitely a big improvement, and I am SO happy that I can now tend to my ugly tiling