[MOD] Deadlock's Stacking Beltboxes & Compact Loaders

[mrvn]

Apropo snapping code. That seems to get things wrong for me a lot of the time. I often end up with a loader with the belt side towards a warehouse. Could it be that the code has problems with containers that are larger than 1x1?

I did some testing and couldn't reproduce either this issue or the issue reported by KoS about bots placing loaders the wrong way round.

I'll need more info (are you placing them by hand or by bot, exactly what are you placing them next to - several mods provide "a warehouse") and ideally a zipped save.

I using Angels+Bobs mods, Bluebuild rewritten and a few others. Nothing with loaders. No construction bots yet. I did disable the snapping options and that made things reliable. Let me enable snapping again and test how to reproduce it with as few modules as possible.

[Deadlock989]

Bluebuild rewritten

It's almost certainly this. It uses the same methods as Nanobots and that is causing issues with the snapping code. Still trying to work out why.

[Deadlock989]

The issue is that both Nanobots and Bluebuild are firing off the player on_built_entity event when they revive ghosts. DCL assumes that this event is only ever going to be fired by a player, because that's what the event is for - there is a separate event for vanilla construction bot building that DCL deliberately ignores. Essentially we only want to fiddle with loaders when a player places them, not when they have pre-defined directions and modes from a blueprint. These other mods call the player build event for a blueprint build, which wrecks that assumption.

The issue doesn't arise with other loader mods like Loader Redux and Miniloaders because they use a different logic, almost the reverse. They snap to belts and belt-like things, whereas DCL snaps to entities that have an inventory. If these "fake bots" from the other mods build a beltbox or anything else with an inventory before they build the loader that's next to it, the loader gets snapped to it, overriding whatever direction it had in the blueprint.

So I have choices, none of which are very palatable.

1. Make special cases for these other mods, looking for the various flags they pass (or don't), opening myself up to a never-ending list of other mods which fire off the event.
2. Completely re-write the snapping logic so that it doesn't snap to inventories.
3. Delete DCL's snapping entirely. It is only there because loaders default to output mode when placed, which I find mildly annoying during play, but much less annoying than this issue.
4. Classify this as Someone Else's Problem and either ignore it or report it to these other modders.

[mrvn]

But my issue was with the loaders snapping with the belt to the warehouse while the placement was with the loader towards the warehouse.

If the warehouse or belt is build first then it should snap with the loader towards the warehouse and belt towards belt. If the loader is placed first it should not change it at all since neither end has a entity with inventory or belt. Since the ghost is the right direction that would mean in all cases it should end up right.

There should only be a problem if the ghost is placed the wrong way. In which case it would magically repair it sometimes.

[Deadlock989]

But my issue was with the loaders snapping with the belt to the warehouse while the placement was with the loader towards the warehouse.

If the warehouse or belt is build first then it should snap with the loader towards the warehouse and belt towards belt. If the loader is placed first it should not change it at all since neither end has a entity with inventory or belt. Since the ghost is the right direction that would mean in all cases it should end up right.

There should only be a problem if the ghost is placed the wrong way. In which case it would magically repair it sometimes.

I disagree. The issue doesn't occur with vanilla construction bots. It doesn't occur when manually placing loaders. I can only reproduce it with Nanobots and with Bluebuild, and only when snapping is enabled. I've checked their code and mine. They are firing player build events for blueprint ghost construction and my view is that this is questionable practice. I've reported it to the mod authors and also discussed Nanobots with Nexela on someone's Discord. I'm now waiting to see what the response is. If they fix their stuff, that's great. If they don't, I'll decide what to do.

[mrvn]

But my issue was with the loaders snapping with the belt to the warehouse while the placement was with the loader towards the warehouse.

If the warehouse or belt is build first then it should snap with the loader towards the warehouse and belt towards belt. If the loader is placed first it should not change it at all since neither end has a entity with inventory or belt. Since the ghost is the right direction that would mean in all cases it should end up right.

There should only be a problem if the ghost is placed the wrong way. In which case it would magically repair it sometimes.

I disagree. The issue doesn't occur with vanilla construction bots. It doesn't occur when manually placing loaders. I can only reproduce it with Nanobots and with Bluebuild, and only when snapping is enabled. I've checked their code and mine. They are firing player build events for blueprint ghost construction and my view is that this is questionable practice. I've reported it to the mod authors and also discussed Nanobots with Nexela on someone's Discord. I'm now waiting to see what the response is. If they fix their stuff, that's great. If they don't, I'll decide what to do.

That is all true. But the question still remains why it snaps the wrong way. I will test it some more tonight and report back what actually happens when. I can create some bots in a sandbox too to compare results.

[Deadlock989]

Deadlock's Compact Loaders 1.2.6
Date: 02. 03. 2018
Inter-mod support:
- Look for "revive" flag passed by Nanobots in on_entity_built and cancel snapping.

[mrvn]

I've tried the snapping options again (both options are on). I've build a container with belts going in and out in all 4 directions with a warehouse and a wooden chest. In each set of 6 the top left I build from hand till it was perfect. Then I build everything else but the loaders. I then placed loaders manually on the bottom 2 containers and last I blueprinted the remaining 3 and let bluebuild go wild.

bad loaders with bluebuild

loader.png (4.7 MiB) Viewed 5878 times

As you can see the snapping to a container with unloaders screws it up in all cases for bluebuild.

- loaders end up with the belt towards the container so they have to be deconstructed and placed again
- unloaders are placed as loaders so they have to be rotated

I also note that when manually placing it always places loaders even if the belts indicate otherwise. It would be nice if the loader could snap to belts too to determine weather it should be a loader or unloader.

I did a second test building loaders facing the wrong way. Left is the design and right is after bluebuild.

placing loaders facing thw rong way

loader2.png (788.59 KiB) Viewed 5878 times

Here the unloaders are snapped towards the container but now are unloaders. The loaders are only reversed and are now unloaders.

In summary using bluebuild the snapping always breaks things if the loader is placed after the container. And in some cases it doesn't even snap towards the container, just alters the direction.

Last I did another test. I blueprinted the loaders and then tried placing them manually. When doing this with underground belts before the placement it shows the belt flowing in the same direction as the ghost and after placement that is the case. So one actually places the ghost. Not so with loaders. It ignores the direction the ghost is flowing and always places a loader. This is probably something the vanilla loaders need to support and not something you can mod, right?

[Deadlock989]

Last I did another test. I blueprinted the loaders and then tried placing them manually. When doing this with underground belts before the placement it shows the belt flowing in the same direction as the ghost and after placement that is the case. So one actually places the ghost. Not so with loaders. It ignores the direction the ghost is flowing and always places a loader. This is probably something the vanilla loaders need to support and not something you can mod, right?

In my tests both loaders and underground belts are not q-pipetted correctly when their output mode is facing towards the belt. viewtopic.php?f=7&t=58310

Q+click does not actually revive a ghost, it just plonks whatever you end up with in your cursor down and removes the ghost. Bluebuild claims to be simulating q+click but really it is reviving ghosts and simulating construction bots. The author is aware of the issues. If he/she puts in a flag like Nanobots does then I can catch it, otherwise, it will continue to cause problems with mods like Compact Loaders which expect that on_built_entity is fired only when a player manually places entities.

[Deadlock989]

Meanwhile

[mrvn]

Last I did another test. I blueprinted the loaders and then tried placing them manually. When doing this with underground belts before the placement it shows the belt flowing in the same direction as the ghost and after placement that is the case. So one actually places the ghost. Not so with loaders. It ignores the direction the ghost is flowing and always places a loader. This is probably something the vanilla loaders need to support and not something you can mod, right?

In my tests both loaders and underground belts are not q-pipetted correctly when their output mode is facing towards the belt. viewtopic.php?f=7&t=58310

Q+click does not actually revive a ghost, it just plonks whatever you end up with in your cursor down and removes the ghost. Bluebuild claims to be simulating q+click but really it is reviving ghosts and simulating construction bots. The author is aware of the issues. If he/she puts in a flag like Nanobots does then I can catch it, otherwise, it will continue to cause problems with mods like Compact Loaders which expect that on_built_entity is fired only when a player manually places entities.

I wasn't talking about Q+click. That one is broken too and probably explains why bluebuild gets loaders turned around. It must do some Q+click internally to place the ghost. If it's using the same function as the hotkey they both get bad data.

I was talking about hovering with the mouse over a ghost with the item in hand. The direction the underground belt is facing doesn't change. But if it is facing the right direction then the direction of the belt is matched to the ghost (going in or going out). Not so for loaders.

[mrvn]

Meanwhile

Note to self: Don't stack half/half belts.

[Deadlock989]

I wasn't talking about Q+click. That one is broken too and probably explains why bluebuild gets loaders turned around. It must do some Q+click internally to place the ghost. If it's using the same function as the hotkey they both get bad data.

No, it doesn't. It revives ghosts. I've been through the code. The ball is in their court.

[Deadlock989]

Version: 1.4.7
Date: 04. 03. 2018
Inter-mod support:
- Added two new functions for modders.
- deadlock_stacking.remove(string) will search DSB's native technologies for any recipe unlocks with a matching substring and remove them.
- deadlock_stacking.reset() will clear all stacking recipes from all DSB technologies, leaving only the machine unlocks.
- See the modding readme for more details.
Bugfixes:
- Addressed a global variable pollution issue.

[mrvn]

I wasn't talking about Q+click. That one is broken too and probably explains why bluebuild gets loaders turned around. It must do some Q+click internally to place the ghost. If it's using the same function as the hotkey they both get bad data.

No, it doesn't. It revives ghosts. I've been through the code. The ball is in their court.

Yeah, thinking about it again made me realize the problem can't be there. With snapping turned of it works 100% of the time.

That said how can the ball be in bluebuilds court. Bluebuild places the entity correctly on it's own. Only when snapping is enabled the loaders are wrong 100% of the time.

Even if bluebuild isn't supposed to send a player build event how does that turn the loader away from the container or turn the direction around? Bluebuild should revive the ghost and everything should be placed right. Then I guess it sends the player build event to simulate the player building stuff. Now the loader should see that it is already facing the container and do nothing. Everything should be fine.

You've been through the code. Does bluebuild rotate the entity after placement and after the player built event or what happens that you say bluebuild is at fault? Who rotates the loader away from the container?

[orzelek]

I wasn't talking about Q+click. That one is broken too and probably explains why bluebuild gets loaders turned around. It must do some Q+click internally to place the ghost. If it's using the same function as the hotkey they both get bad data.

No, it doesn't. It revives ghosts. I've been through the code. The ball is in their court.

Yeah, thinking about it again made me realize the problem can't be there. With snapping turned of it works 100% of the time.

That said how can the ball be in bluebuilds court. Bluebuild places the entity correctly on it's own. Only when snapping is enabled the loaders are wrong 100% of the time.

Even if bluebuild isn't supposed to send a player build event how does that turn the loader away from the container or turn the direction around? Bluebuild should revive the ghost and everything should be placed right. Then I guess it sends the player build event to simulate the player building stuff. Now the loader should see that it is already facing the container and do nothing. Everything should be fine.

You've been through the code. Does bluebuild rotate the entity after placement and after the player built event or what happens that you say bluebuild is at fault? Who rotates the loader away from the container?

It's more about trying to update rotation of revived entity based on it's current neighbors. And if they are ghosts they don't exist yet so they are not detected. And since it pretends to use player built event without added flag from bluebild side there is no way to identify when snapping should and shouldn't happen.

[mrvn]

I wasn't talking about Q+click. That one is broken too and probably explains why bluebuild gets loaders turned around. It must do some Q+click internally to place the ghost. If it's using the same function as the hotkey they both get bad data.

No, it doesn't. It revives ghosts. I've been through the code. The ball is in their court.

Yeah, thinking about it again made me realize the problem can't be there. With snapping turned of it works 100% of the time.

That said how can the ball be in bluebuilds court. Bluebuild places the entity correctly on it's own. Only when snapping is enabled the loaders are wrong 100% of the time.

Even if bluebuild isn't supposed to send a player build event how does that turn the loader away from the container or turn the direction around? Bluebuild should revive the ghost and everything should be placed right. Then I guess it sends the player build event to simulate the player building stuff. Now the loader should see that it is already facing the container and do nothing. Everything should be fine.

You've been through the code. Does bluebuild rotate the entity after placement and after the player built event or what happens that you say bluebuild is at fault? Who rotates the loader away from the container?

It's more about trying to update rotation of revived entity based on it's current neighbors. And if they are ghosts they don't exist yet so they are not detected. And since it pretends to use player built event without added flag from bluebild side there is no way to identify when snapping should and shouldn't happen.

But the problem (only) arises when the loader is build last and snapping happens. When the loader is built first no snapping happens and the loader ends up the way it was blueprinted. Same if snapping is disabled.

The first problem I see is that the snapping turns the inserter AWAY from the existing container. That should never ever happen. The snapping is supposed to make the loader always face the container, right? This I figure must be a bug in the loader.

The second problem is that the direction of the loader is reversed. That part I can see is a problem for bluebuild. Because if I understand the code right when the loader is already facing the container the snapping reverses the direction of the belt. There is no way to get this right without some flag like nanobot sets.

It's odd that with snapping if a container is present you modify the loader no matter how it is placed. If its facing the container you do something, if it is not facing the container you still do something.

So I had a thought: Why is the snapping going that way? Wouldn't it make sense to reverse the default direction of the belt in the loader? That way if the loader is already facing the container nothing happens. If the loader is facing away from the container then turn it around and change direction. Two snapping options become one, the code becomes shorter, no check needed for nanobot (or bluebuilt) [as long as you don't blueprint loaders that are facing away from a container, so the flag check might still be a good idea].

[Deadlock989]

It's odd that with snapping if a container is present you modify the loader no matter how it is placed. If its facing the container you do something, if it is not facing the container you still do something.

Purely personal preference. I don't like loaders being in output mode by default when you put them down, it starts pulling stuff out of the container even if you haven't finished building everything else yet. You can turn that specific snapping off in the mod settings if you have a different preference. That's why it's there.

This is all working as intended except for this one case where third party mods do highly questionable things with player build events, and you can work around it by turning off the snapping. I've made one more change which moves snapping config settings to per-player rather than startup which I'll upload later, and I'm minded to make snapping start as off in the config by default, but aside from that I'm not touching this code again until/unless Bluebuild changes. I'm working on a new mod which is about a million times more interesting.

[mrvn]

It's odd that with snapping if a container is present you modify the loader no matter how it is placed. If its facing the container you do something, if it is not facing the container you still do something.

Purely personal preference. I don't like loaders being in output mode by default when you put them down, it starts pulling stuff out of the container even if you haven't finished building everything else yet. You can turn that specific snapping off in the mod settings if you have a different preference. That's why it's there.

This is all working as intended except for this one case where third party mods do highly questionable things with player build events, and you can work around it by turning off the snapping. I've made one more change which moves snapping config settings to per-player rather than startup which I'll upload later, and I'm minded to make snapping start as off in the config by default, but aside from that I'm not touching this code again until/unless Bluebuild changes. I'm working on a new mod which is about a million times more interesting.

Still no explanation why the loader ends up facing away from the container. I'm going to debug this tonight if I find time after looking at the rail bulk loaders that have a bigger bug that, well, bugs me. Adding the same flag as nanobots to the bluebuild event shouldn't be to hard to do locally.

I too don't like loaders in output mode. So why then is that the default? Forgot to mention that as well with my suggestion to turn the loaders around by default.

[Deadlock989]

I too don't like loaders in output mode. So why then is that the default?

I have no clue, ask Wube.