Miniloader internals

[lean stratus]

This works for me.

[heady sentinel]

hi thanks

[lean stratus]

Miniloader internals

[heady sentinel]

my problem statement is as follows - someone on SE-K2 discovered a neat little perk for K2 loaders to be able to snap after being cloned (spaceship launch/arrival)

we figured that it didn't work for miniloader because it isn't handling on_entity_cloned event

I did something like this if use_snapping then snapping.check_for_loaders(ev) end to handle that event and it worked

I wonder if the order of cloning the entities going to screw the system?

I am not very sure whether I should update_inserters as well

this is how it worked for k2

[clever pivot]

Sorry to interject, why would you snap after cloning? Their orientation shouldn't change. Who would make it snap again on purpose

[heady sentinel]

the use case is for spaceship - with this property you only need one loader and it will snap accordingly to load/unload depending on the neighbour underground/belt

[clever pivot]

If you're going to do that, then do it explicitly imo.

[heady sentinel]

do you mean design the loading/unloading separately? or something about the mod programming?

[clever pivot]

I mean the modding. Explicit detection if its appropriate to switch output / input

Even something crude sounds better than messing with all cloned "loaders"

[heady sentinel]

in miniloader there's already a library for snapping snapping.check_for_loaders. I'm not sure if I want to reinvent the wheel

[clever pivot]

No.

You're missing the point. Don't change it unless you should.

If you're actually depending on clone order, that's bad. Find and reverse i/o instead of praying.

[lean stratus]

I think the point is to separate the "on_entity_cloned" which can happen anytime for any reason from the specific use case of SE spawning a spaceship on a surface.

SE should add a specific event for that happening, then we can talk about adding specific behavior for Miniloader to treat it as a "freshly built" thing instead of a generic "cloned from somewhere, we don't know from where or why."

Cloned entities (in general) should be exactly the same as their origin.

[clever pivot]

^ that's part of it. Its fine to use the event, but creating some check criteria first will save a lot of headache later.

[lean stratus]

I have a lot of questions from that screenshot about what's causing the belts to reverse as well.

Because it's not just the K2 loader. There's something deeper happening.

[clever pivot]

Oooh something is reversing the belt too, isn't it?

I've never seen a mod that does that.

[fossil drift]

The K2 snapping logic will snap adjacent loaders when a belt entity is cloned or rotated. That is likely what is happening here.

Editor extensions' infinity loader snapping is similar (almost identical code)

https://git.sr.ht/~raiguard/Krastorio2/tree/master/item/scripts/loader-snapping.lua#L72

[heady sentinel]

there's nothing about spaceships in SE's interface, and according to Earendel I don't think the spaceship system is in its final form

regarding the belt reversing

I understand it's confusing

but the one that is being set is the one on land (outside of spaceship), whether it is going in or out

[lean stratus]

Miniloader also has logic to snap loaders when an adjacent belt is rotated, though. https://github.com/mspielberg/factorio-miniloader/blob/master/control.lua#L161

[heady sentinel]

the loader, and the underground segment on the ship switches automatically

[lean stratus]

So if that's what's supposed to happen there may be a bug.

I'll have to have a deeper look.

[heady sentinel]

I think I need to clarify further

the desired behaviour isn't changing how the loader snaps by manual manipulation

assuming the two pictures are different locations - the bottom image is where I want to load the ship, the top image is where I want to unload the ship

[lean stratus]

something is causing the underground belt to change direction. Is code in SE that "something?"

[heady sentinel]

I don't think it is caused by SE, isn't it vanilla behaviour to snap the underground when placed?

[lean stratus]

It is happening automatically when the underground in the ship is cloned on the new surface? I just have lots of questions I'll need to investigate.

[heady sentinel]

clone isn't supposed to change the underground?

[lean stratus]

I guess the delta is that miniloader doesn't look for adjacent belt entities being cloned into existence. That seems fragile though, since the order that entities are cloned isn't defined.

[heady sentinel]

yea that's my main concern actually

[fossil drift]

I think the underground flipping is the game engine. It sees a potential neighbour and hooks it up

[heady sentinel]

but if we do the snapping check on both the entities and the belt that should work regardless of order?

[fossil drift]

IIRC belts auto rotating like this was a happy accident according to the SE folks

[heady sentinel]

yea it was brought up in chat just now

and I was curious

[fossil drift]

Ack, sorry

I'm currently packing to move so I'm very distracted 😅

[heady sentinel]

I have found a peculiar nature of clone_brush function. I have tagged the following points in the miniloader code for spaceship launch testing:

• find_miniloaders function when it has found a miniloader for a neighbor belt
• 1 for is_miniloader_inserter, in the on_entity_cloned handler
• 3 for is_miniloader, in the on_entity_cloned handler
• B for check_for_loaders call - for when on_entity_cloned isn't a miniloader or miniloader_inserter (B for belt maybe?)
  Here is the print result

I think there is some kind of staging process here. The belt is able to find the correct miniloader and snap to it even before the miniloader cloning events are raised.