Science & Industry

In PI what happens if there are multiple source for a given factory's inputs?

Do they get split across the inputs, or is one randomly chosen? Is it the same one every time?

Personally I just have everything dropped into a storage facility than to the factory and than the final product dropped into the launchpad.

If you're routing from an extractor, directly to a factory or a factory to another factory, as far as I'm aware, there's no storage to soak up an excess. Which includes when the timing of cycles is different.

So if your extractor is pulling more than your factory can handle, you'll lose materials, unless you route via a storage facility to buffer it.


If you have multiple storage facilities, and you route the same thing multiple times to a factory, then you're fine. But that's not what I was talking about.

Harvester -> Storage -> Factory -> Storage -> Launchpad

That way you don't lose anything.

For more complex stuff ...

Harvester -> Storage -> Factory -> Storage -> Advanced Factory -> Storage -> Launchpad

If you place an actual spaceport thing it gives cheaper launches and plenty of storage space right there. The then it becomes ...

Harvester -> Spaceport -> Factory -> Spaceport

or

Harvester -> Spaceport -> Factory -> Spaceport -> Advanced Factory -> Spaceport

See? Very simple, and nothing is lost.

Ok, I answered this question myself. Here is the answer:

Internally, all of the facilities and routes on a planet are in a list IN THE ORDER IN WHICH THEY WERE CREATED

Each facility is checked one at a time, in the order in which it was created. If it needs inputs, each route is checked sequentially in the order in which the routes were created to attempt to fulfill the input.

What this means is that how close a source is from its destination or how much of a commodity it has is irrelevant. All that matters is when its routes were created.

There is consequently no way to draw from storage in a balanced way. The first storage that has any inputs will be tapped for as much as it can provide.

(Obviously, the EVE programmers need more expertise implementing resource allocation algorithms. LOL)

Well, just to state the obvious (or at least the obvious to a skilled programmer) , if multiple sources feed a factory, then the factory should draw from them equally to the extent the inputs are divisible. For example, if the cycle requires 30 units and you have 3 input storage areas then each should provide 10. Progamming this is, however, complicated when there is a complicated network.

I didn't say incompetent. I just pointed out they used the policy that was easiest to program, but from a player perspective what amounts to essentially a random policy. For example, there is no way you can simply look at a planet layout and tell how the inputs will be fulfilled. In fact, unless you write down the order in which you made your routes, it is impossible to know in-game what will happen. Obviously this is a highly non-optimal approach that was only taken because it was easy to program. Let's consider the possibilities for a more skillful programmer:

- Balanced Fulfillment, (as already described above). This would be hardest to program but the best solution. Intelligent routers use algorithms like this which are very complicated

- User-specified ordering. BGP and other gateway protocols use a negotiated best first algorithm, easier to program than automatically balanced, but still pretty hard

- Nearest first. Third choice might be a nearest first, with the secondary policy that if two inputs are equally near then it comes from the one with the most resources, and in clockwise fashion for inputs with identical counts. Easier to program than the first two, but still pretty hard.

- Most first. Easiest of all the good strategies would be most first. In this scheme inputs are ordered by total storage, and then alphabetically in the case of ties. Destinations are ordered alphabetically. The fulfillment then proceeds in those orders. This is pretty easy to program and gives a predictable result which case be determined from the client interface. Even a pretty weak programmer could figure this one out.

Then finally we have the strategy actually chosen: ordering by route creation time. I suppose this is even easier than the last mentioned algorithm to program, but is, from a systems perspective unacceptable because it is opaque, ie you can't tell what will happen from the client, other than by experimentation. In other words it is not a deterministic algorithm from the user perspective.

Claiming that this was a "design choice" is nonsense, because the results are effectively random and clearly inferior to pretty much every other possible algorithm. It was not a design choice, it was some individual programmers choice who was trying to figure out how to get the PI to work before a deadline.

You suggested they need more expertise, and before you even begin, exactly what is it that tells you these weren't their possibilities and they simply chose to go with the straight list. Bearing in mind it's not just about how complicated it is to design, it's also about how fast it can tick through the process across all of the PI installations across the universe. Considering how tiny the gain would be for using your "best" solution (I honestly can;t think of many situations it would benefit where the PI layout wouldn't be disastrously bad anyway, feel free to shed light on this) it wimply wouldn't be worth the extra cycles to build a different system. The way it is works and it works well.

Those are certainly some of the options. I would consider the bottom to potentially be "unordered" though. So they don't particularly worry about what order it is in, as long as the PI keeps ticking, which it does. There's no need to specifically state any order.

It's only inferior by your measurements though. I personally think it works fine as is. And you have to remember that you are talking from your point of view, where you don't know the inner workings around it. It's very possible that there were several reasons why the way it works now was chosen. You are making an awful lot of ungrounded assumptions.

Do you have any professional programming experience? Not to be mean or anything like that, but it does sound like you technically know what you are talking about, but have no actual experience on the job. There's a lot of time when design considerations come from outside the specific task at hand.