I've built a gridlike base using lots of transporter drones and have now gotten to a point where there are several copper- and iron plate suppliers. I've noticed that often the drones will go far away to get for instance iron plates, even if there is a supplier right across the street, with full stock.

Is there anything I can do to influence where the drones go? Other than not building a grid :-)

Its random, the depots and the suppliers are just iterated in a random order.

It would be quite expensive, to for instance, loop through all the suppliers and see which is closest, or make sure there isnt a more optimal choice.

Being random, and that the update is just 1 depot per tick, the script time usage is kept more steady

You can for instance, split the road network

not important, but on reading the above (and having nothing better to do :-)
i got a question and some thoughts ... :-)

iterated (=sequentially) and random at the same time ?
could this (with really bad luck that i always have when RNG is involved) lead to one pair of provider/requester (or several that don't need or don't have items) being checked a million times (a million ticks) in a row and thus doing nothing at all for a while?

without looking at how it is currently done: what about a simple roundrobin for all requesters (1 second for every 60 requesters, 1 minute for a huge road network with 3600 requesters; maybe having a setting to choose how many requesters per tick), and for each of them that needs more items doing another roundrobin on all providers, possibly with a priority (additional value in the depot or signal attached to it) so that first all providers in one list for one priority are checked for enough items (again using simple roundrobin), if none found doing a roundrobin on the next list of providers with the next lower priority, etc ? this might increase the time for the script, but still keep it relatively low when no complicated distance calculations for each pair are needed all the time (no updates of the network needed to find shortest routes with lots of exact pathfinding to find which depots to pair).

or just the other way around: since requesters have a specific item set, one list of requesters per item type. then iterate (roundrobin) on all providers and for each item type with at least a full stack in them quickly find a requester in those shorter lists that needs those items.

also : instead of having priorities, simply build 2 or 3 providers at one location so that items from that station have more chances to be taken. being able to network (connect with wires) could also be helpful if that was available.
not perfect (no main station and a backup station only if main is empty), but maybe worth testing and exploring ...

There is an update order list, which is stepped through 1 each tick.
Once we reach the end of that list, the list is shuffled, and the index is reset to 1 (0 in Lua)

Checking for work regarding the supply and requesters is backwards to how you think,
Since supply depots can hold many types of items, but requesters only request 1, the work is done on the supply depot side. There is a relatively cheap API function to get the contents of the supply depot, and then for each Item I know exactly which requesters want it, so i don't have to iterated through every requester on the map.

Doing it the other way around, would mean iterating through all supply depots, as there is no way to know what items the supply depot contains without checking it.

When returning the list of request depots for an item, a new list is created and shuffled, as that would also have some unknowable bias if unshuffled.

thanks for explaining!

i always feel better when i know some more details even if that knowledge is not always really needed :-)
your method seems to be a better implementation of my second general thought (above: "or just the other way around") :-)

with your description, the same provider chest might send another drone after a single tick (if one was sent last from the list, the list was shuffled and the depot ended up at the top of the new list), and with a worst case of twice the average time (if it was handled first, then shuffled and ended up at the end of the list), but guaranteed(!) to be handled exactly once on each of these cycles, for a guaranteed (and not random) average !? nice!

If it is really random what is the point of buffer depots? From what I've seen they get used as intended, i.e., drones pick up from the closer buffer depot instead of driving far away to the supplier depots.

with almost daily and sometimes hourly updates, (as far as i remember, this was before the invention of buffers)
a discussion from a month ago is not only a dead zombie, but a rotten corpse :-)