Logistic System Suggestions

[azoundria]

Thanks for letting it assign multiple robots at once! I haven't noticed any lag at all, so great work.

1) I think this is easiest to implement of all my suggestions. Have it prioritize the character above all placed requester chests. This means, the player gets his resources before any requester chests, if there is scarcity.

2) It would be cool to have a screen to shift priorities for the other chests, rather than just first placed, first serviced. I don't know how it works behind the scenes.

3) It may also be cool to have an option where it prioritizes the chests that have no supply before those that do. Rather than fill up one chest with iron plates, it would distribute the iron plates it has between all the chests, starting with the chest with the least iron plates in stock/delivery.

4) When you run low on resources it does the negative number, which is basically a sum of the difference in what logistic robots can carry versus what's in the chests. In the immediate future, you could make that display as 0. Longer term, however, I feel that it would be more useful to calculate resources as:

(TSupp + TInReq + TStore + TTransit) - TReq

Where TSupp is the total in the supply chests, TinReq is the total in the requester chests, TStore is the total in any storage chests, TTransit is the total currently in logistic robots, and TReq is the total being requested by all requester chests.

5) It is difficult to see the total of all resources, because they go off the screen, and I actually had to get items I don't care about into a requester chest so I could see the ones I do. I was wondering if you could have a screen which shows all the totals at once. Alternatively, when you hover over an item in either the player's logistic system or choosing what to request in a requester chest, it could also display the total there (along with the production numbers).

6) There is no way to know what items are being delivered in the personal logistic system. This would be useful to know.

[ssilk]

Good suggestions.
To 1: you can replace a requester with a smart chest. With that the other chests will have higher priority. I don't quite understand that, because you always can put stuff yourself into a chest and help it out.

To 2: a very good question. How become the robots their task? I'll look, if I can find that out. But I know, if you change this algorithm it would work only significant better in some special situations. Which might be avoided in normal cases.

To 3: yes, now I understand. Your problem is, that the algorithm doesn't spread the parts equally. I found me also sometimes in that situations, that even if I had enough items and enough bots stand around, they don't deliver. I mean - very carefully! - its a bug. And always, when I try to reproduce it, it's gone. The last time I saw it in v0.6, so maybe you mean something quite different... In other words: maybe you save the game and then restart it? This helped in my case...

To 4: yes, but I would say, that switching between TReq only and all the other values, including the current, is also useful. How much items are currently requested? Or much more like the production-info, we can have a logistic system info?

To 5: too modern. We are all used to calculate the total amount in head. no, this is fine.

[azoundria]

1) As of 0.7.0, you have a PERSONAL logistic system, where the items come directly to you. I think that the logistic robots should bring things to you before they go about any other chests.

2) In my experience, they seem to go through each requester chest in the order they were placed, and fulfill each order based on the closest resources. My suggestion is to allow the priority of requester chests to be changed. Perhaps it could be as simple as having a priority on each chest.

3) You are mentioning a different bug here, which was fixed in 0.7.0. It was not really bug, but a limitation in the system that was removed. I am referring to the case where I have no iron plates left, and I build a new requester chest for iron plates. All the other requester chests have iron plates in them, and will be okay for some time, but it still prioritizes keeping them topped up over filling up the new requester chest.

4) A full display could be made available upon hovering over the item. Excellent idea.

5) How could I possibly calculate a total, when it would change a massive amount in the time it takes me to visit each chest and I'm dealing with hundreds of chests?

[shade]

2) In my experience, they seem to go through each requester chest in the order they were placed, and fulfill each order based on the closest resources. My suggestion is to allow the priority of requester chests to be changed. Perhaps it could be as simple as having a priority on each chest.

Yes and no if you see how they work you can see it's not the order of chest but i think it like a "task list" who as been update on requester event only, so your character ( i think too ) used the same system, his personal logistic slots work same as the requester chest .. do the same task list

[azoundria]

That would match my observation.

It's most likely represented as a LinkedList, a structure where each entry points to the data location of the next item.

As an example of how you could easily create a heirarchy (Urgent, High, Medium, Low), you simply create a pointer for the start and end of each list. For example, if you want to insert into the Urgent list, you insert between the end of the Urgent list and the start of the High list. When a chest changes priority, the entries at the old priority need to be found/removed and they need to be inserted at the new priority. Reading the list is the exact same for the logistic robots.

[ssilk]

Hm. I dunno if priorities would solve the problem, that some chests aren't filled. But another algorithm does. I think the algorithm should try to have the chests equally filled up for one type of item. Makes totally sense to me.
Example: chest1 requests 100 items, chest2 10000. Both are empty and it makes now much sense to handle both chest identically, until chest 1 is satisfied. Which means, the "priority" depends on already delivered.

To 1: yes, should be obvious to fulfill first the players needs.

To 3: no I really had some situations, where the chests where not filled and when I loaded the game it suddenly worked. It happened, when I added and removed chests. Like if the linked list was unlinked at some point and regenerated at restarting.

To 5: I would mean, technically they are difficult to count... Think to the items on belts, which can be enormous. But yes, could be interesting to see "items on belt: 30000, items in chests: 8000". And so on and splittable by type. And so on: in all chests, in types of chests, in assemblies/furnace/inserter etc., in turrets, visible mineable, covered mineable...enough to be updated every minute only.

To added 6: a logistic system statics should show that.
...

And now when I think to it again, priorities would make sense. Not much levels needed, I would say three or five (not four, because then you have no neutral center!). For me three would be enough. I need to say "delivering ammo is most important, and then I have tasks which should be done only, if everything else is full. But the difference between making 3 and 5 is only a constant changed in the code and another representation on screen.

[azoundria]

Hm. I dunno if priorities would solve the problem, that some chests aren't filled. But another algorithm does. I think the algorithm should try to have the chests equally filled up for one type of item. Makes totally sense to me.
Example: chest1 requests 100 items, chest2 10000. Both are empty and it makes now much sense to handle both chest identically, until chest 1 is satisfied. Which means, the "priority" depends on already delivered.

That sounds exactly like my suggestion 3.

To 3: no I really had some situations, where the chests where not filled and when I loaded the game it suddenly worked. It happened, when I added and removed chests. Like if the linked list was unlinked at some point and regenerated at restarting.

I have not encountered this bug. The particular case I am referring to involves a scarcity of resources.

To 5: I would mean, technically they are difficult to count... Think to the items on belts, which can be enormous. But yes, could be interesting to see "items on belt: 30000, items in chests: 8000". And so on and splittable by type. And so on: in all chests, in types of chests, in assemblies/furnace/inserter etc., in turrets, visible mineable, covered mineable...enough to be updated every minute only.

This can be solved by keeping a running tally that is updated as items are picked up or deposited (or robots are destroyed). At present, it tracks all the items that are requested to be delivered to all chests, so this should be simpler than that.

And now when I think to it again, priorities would make sense. Not much levels needed, I would say three or five (not four, because then you have no neutral center!). For me three would be enough. I need to say "delivering ammo is most important, and then I have tasks which should be done only, if everything else is full. But the difference between making 3 and 5 is only a constant changed in the code and another representation on screen.

I would be alright with 5, though I don't think that there is a need for two levels below the neutral one. Most players would not use the 'low' priority, so having a 'very low' seems like it would be a waste. Basically, I put high, medium, low for normal operation, and had an urgent status in case something needed to be done ahead of everything else (like life or death).

[kovarex]

There is very easy (almost one-liner) solution of this.
Every time a Requester is served (logistic robot sent to it), it will be put to the end of the priority queue.
This would make robots fill all requesters almost equally.