Bug

If having multiply emitters along a "highway" of transmitters, the closer to the receiver the emitter is the more likely it will try and path to a far away emitter rather then the near receiver.
+++

Please open separate issues for each of these so we can better keep track of them.
Also please elaborate on suggestion 2 when doing that, because as it stands right now we can't possibly know what you mean by "Vacuum Upgrade".

Please open separate issues for each of these so we can better keep track of them. Also please elaborate on suggestion 2 when doing that, because as it stands right now we can't possibly know what you mean by "Vacuum Upgrade".

done

Wanted to update this.

Further testing shows its practically impossible to easily predict the logic of more advanced networks.

Example.

This configuration

The hidden emitter and the visible receiver can both reach it, but the emitter does not send the items to that receiver but the farther away one. The farther away emitter will send it too the visible receiver

However if placed like this, even though logically they should act the same, the hidden emitter pushes the items to the visible receiver.

Perhaps the ability to assign some sort of frequency to the Emitters and Receivers might fix this. I understand sorting works, but trying to do in general items pushing, like "this barrel goes to smelting" is a issue.

oh i almost forgot to mention. In either configuration the way its goes is just a chance. i think its like 9/10 chance to got its primary direction. So randomly it will go the other way. every 1/10 times.

If you make a grid like this then place a stack in the emitter. It can really show the inconsistencies. As some items get stuck in loops even thought they can easily go directly to the receiver.

Just wanted to clarify. The intended purpose of the above pictures involving the hidden emitter. Was a out of sight smelter array, using one channel of transmitters to send and receive. I got it working but to the weird logic it would seemingly at random have a loss in stuff do to the items being sent to the wrong receiver.

I now know about wool occlusion which made this a bit silly. However it was a good showcase of the earlier issue with how the logic is hard to figure out on more complex networks involving 1 row of transmitters.

Hey! We just released an update (v1.2) that fixes some item transporting consistency issues. Please try it out and tell us what you think!

After some quick testing this setup caused items to go the wrong direction.

With these three transmitters going in a circle

the output emitter was this one

These to transmitters clogged which the items going to the two emitters

Hello, I'm the other developer of SculkTransporting. If I'm interpreting the item signal directions in your setup correctly, everything seems to behave intentionally (from a purely logic standpoint). The leftmost transmitter in your screenshot gets its signal from the transmitter straight to the right of it, and sends it to the nearest sculk block, which just so happens to be the transmitter (the bottom one in the loop) instead of the receiver (since that one is further away), and that bottom transmitter closes the loop since the rightmost transmitter is closer to it than the receiver.
I understand that this behaviour is unintuitive, I think I would generally suggest not forming loops using transmitters if possible because of exactly that quirk of the closest-priority mechanic. You can prevent loops by (e.g. in your setup) placing a transmitter between the currently leftmost one and the receiver (thus making that newly placed transmitter the closest one to the loop, so all items in the loop will eventually land in that transmitter), or strategically placing wool to interrupt the loop (e.g. in your setup, placing wool between the leftmost transmitter in the loop and the one below it should stop the loop and allow items to pass to the receiver correctly).

Logically speaking though shouldn't the receiver have a higher priority than a transmitter for the item to be sent to it, with closer receivers being favored over farther or flipped with farther being higher then closer?

So it looping like this when it can easily reach a receiver is illogical. Unintuitive and illogical would be the items going the wrong way on a transmitter line causing a clog.

This is why i suggested a frequency system or even a priority system.

As it stands the mod is really vanilla friendly, but is being outshined by other mods by the fact it is unintuitive outside of short range transportation. Hard to gather due to needing to find a deep dark biome and then constantly dodge wardens(and other things if modded) while collecting items and upgrades needing multiple end cities worth of echo shards for endgame. It also has logical failings when you do a setup that should logically work but end up working only partially or not at all. I really like the mod, which is why i have made the numerous posts that i have as i want it to shine to other the way i believe it can. I understand it wont be the fastest, nor will it be the most "do it all". However it should at least be reliable.

Yes wool solves the issues in most cases, but not all cases. Having these inconsistencies will cause issue like people not using your mod due to how expensive the end game is vs how unreliable it is.

Most people like having a central storage system with multiple things inputting into one, if these issue stand this is not possible unless each line is a dedicated line until the receiver, which means a lot of wool, sculk, and echo shards. All because the inconsistencies cause items to go one way or the other when 2 transmitters are the same distance away from the starting transmitter. Due to the cost unless its the only item transport mod in the pack, no one will feasibly want to use the mod unless they are able to easily kill or not deal with the warden. Even then they may not do it much thanks to the cost of endgame needing to find multiple end cities.

An example of how you can make this consistent, is that when a receiver gets placed it scans for connected transmitters ever like 20 ticks or something (not to fast to prevent lag) and gives a priority number starting at like 1000 counting down.

the receiver would always be 1000. Higher numbers would be more likely for the item to travel to it, lower be less likely.

you could also add a frequency but you would have to add the ability to put a filter like thing on the receiver and transmitter, it would update the network saying "hey im over here" so that items the emitter had marked would ignore receivers and transmitters marked otherwise. This would allow a more compact sorting system or multiple networks using one main bus.

There will still be issues, but this way its more consistent

thinking on it

To make this more easily expandable it might be better to count up rather then down, with the lower number being higher priority . So that networks did not have a hard cap of transport entities.

To clarify how it would function.

When you place a receiver, it would give itself number 1. It would then scan for nearby transmitters, if found it would give any in range number 2, it would redo the scan from transmitters numbered 2, any within thier range without a number will be marked as 3 ect.

An update scan would happen periodically to check for changes to redo the numbers if needed. With number updates only occurring if there is a lower possible number for the same receiver.

To reduce or prevent lag you can limit the number of scanners at once.

In cases of multiple receivers on one line then it would follow the current rule of new receivers have less priority for updating numbers. So if Receiver A was first and Receiver B was place by transmitter with priority 10, then Receiver B would be give priority 11. If it was in range of P10 and P11, it would be given P12. Pretty much w/e pre-existing P# is the highest, the new receiver would be that +1.

In cases where 2 transmitters intersect from 2 different receivers, the one with the higher number wins and will redo the the lower number receiver as its own.

Loops can still occur if multiple receivers are active but are less likely since the setup need for it would require intentionally doing it.

Filtered Transmitters get a -1 to their priority if their not a 2.

If some how the number of transport entities reach the integer limit, right before it have the priority go back to 1 but now it would be like 1(1), so each following number would look like 2(1) 3(1). Ect, or just have it hard cap at that and say "no more transport blocks can be added"

Hello, I think I'm slowly starting to get what you mean by "inconsistent". The core idea of our item transportation was that it is based (as much as possible) on vanilla sculk signals, which are just signals travelling from one transmitter to another without knowing where the nearest receiver is. Your idea of assigning priorities to transmitters based on their distance to the next receiver strays away from this concept, but also resolves a lot of issues with item signals that loop (if implemented correctly), so I'm a little on the fence whether we should implement such a system. bl4ck, if you're reading this, what's your opinion on this (so our current, vanilla-based, loop-prone, purely distance-based system vs. a hidden and thus unintuitive, but much more consistent priority system)? Also in regards to performance implications of such a reverse-pathfind algorithm, I feel like this is something that would be discussed in a computer science lecture somewhere.

Having said that, recipes becoming too expensive in the endgame is definitely something we can improve on too. If you want to, you can open a separate issue describing just that, maybe we can make the recipes a little less expensive.

Understandable. I think i get your side a bit more.

You are trying to be "under the hood" vanilla based. Where i am trying to be "on the surface" vanilla based.

Could have it be a secondary system that is a fallback in case of loops. Example being have each transmitter keep a temporary count of how many times an items passes through it and how long that item is held, if the count is showing a loop(so like 5 or more) or is showing its not moving(5 seconds or so), have it use the priority system till its at least one transmitter away from the looping transmitters or stuck transmitter.

To help players identify these issues you could have problem transmitters glow or something to indicate "there is a loop or stuck here".

Could also make the system an upgrade for the receiver. Called "tracking". That way in order to make it more reliable its any optional thing.

Though i would still recommend doing the secondary thing to prevent bug reports.

This priority system sounds very complex (not conceptually) and is not exposed to players thus making it unintuitive, as Redstone said. I feel like a system that utilizes some kind of frequencies seems best, especially since that is fully customizable by the player as opposed to working silently in the background. If instead of implementing an obstruse hidden system we implement a frequency system, nothing would change about this being based on vanilla's sculk signals, just the destinations signals get sent to are modified in a way. I don't think that would be detrimental at all; We already have item filtering for the transmitter, which is very similar to frequencies.
My immediate thought is setting frequencies based on wool colors. It makes thematical sense, and 16 frequencies doesn't seem too over the top. Though something to keep in mind is that we want to keep the mod UI-less, so adding too many block interactions can quickly become overwhelming, or even impossible to cleanly implement.

One more tweak to think about is whether transmitters should prioritize any receiver they find. With the above-mentioned frequency system, receivers that a transmitter should not send to can just be put on a different frequency.

Fair, perhaps you could attach it to a new block? Like you dye the skulk barrel and that sets the frequency? That way it reduces the block interactions and make more of a purpose for the barrel.