Set Amount of Items/Buildings that are buffered

[NSADrone]

Is your feature request related to a problem? Please describe. Personal Logistics Add-on currently Buffers a number of items based on Logic I cannot determine.

i.e. I requested 2 stacks of Drones and 2 stacks of vessels Personal Logistics Buffered 400 Drones but 1100 Vessels

Requested 1 stack of Mining Machines and 1500 were buffered. Requested 1 stack of Vertical Launching Silos and 900 were buffered Requested 1 stack of Chemical Plants and 550 were buffered

Requested 15 stacks of Foundation only 74 are buffered

Describe the solution you'd like An option added to the UI to set the number of items or stacks to be Buffered.

Describe alternatives you've considered Making the Logic more consistent, or making this visible in the Config File.

Additional context Add any other context or screenshots about the feature request here.

[mattsemar]

It always tries to add 1 full logistic vessel's worth of items to the buffer. This is so that when your inventory falls below the requested amount, it can be replenished without costing another trip. If there aren't that many available then it will add as many as it can find.

My guess is that you don't have very much foundation available in your network. What does the tooltip show for foundation when you hover your mouse over it?

[NSADrone]

I was looking at amounts buffered in a snapshot. Now that I understand the Logic, it somewhat makes sense. I currently have Tech researched so that my vessels have a capacity of 1400.

So in this case there were 74 Foundation buffered because the App had buffered 1400 and then transferred 1326 to my inventory. I have over 28000 Foundation available between 2 different ILSs.

I still think this would be a useful feature as I would love to be able to buffer 10,000 Foundation since that is about how many I use when I visit a new Planet. But, I would also not need 1000+ Science buildings and I currently have 1100 in buffer.

[abesto]

Adding another data point to this: I looked for a personal logistics mod to solve two things.

• QoL: I want to set how many belts I want in my inventory, and never think about belts again. Your mod takes care of this beautifully!
• Wasted materials: some buildings are very expensive. My current solution is basically using the blueprints of Nilaus to request a reasonable number of items into 10 (?) stations on each planet I "colonize", but even that's a fair amount of waste - I won't use most buildings on most planets, and I never clean up after myself. Even so, this is significantly better than the current state of the mod. OTOH this solution doesn't hit my goal for QoL :)

I was initially thinking that maybe something like a checkbox for "buffer only the requested amount" would work well, but a naive implementation for that behaves terribly when the checkbox is enabled, and the request size is increased in tiny increments but many steps (i.e. "I keep clicking the + sign"): it would possibly result in logistics vessels being launched with one item each. It's also a new, unique mechanic, which is kind of a smell.

(Apologies for the wall of text)

An Idea

But DSP already has a solution for this class of problems: the minimum cargo load for logistics vessels. While thinking about how that would directly apply to this mod ("minimum logistics vessel load" still makes sense, and maybe we want an extra "minimum buffer load"?) I realized that given "minimum vessel load" support in personal logistics, I'd actively want to not have a Buffer at all. I'll set my requested amount to be large enough so that I don't usually need a refill for a single building task, and the minimum vessel load setting will ensure deliveries don't waste energy. This matches my intuitions about how logistics work from Factorio. It also gives me complete control / removes a magical black box, while also solving both my wishes (QoL and no wasted materials).

There's some lack of clarity in this though. Consider request=10, minimum_load=5, inventory=6. We have two possible outcomes:

• We don't send a shipment.
• We do send a shipment with size 5 (=minimum_load).

I'd somewhat expect to ship 5 items, but that is not necessarily the correct behavior. Doing so gets us in trouble again when I click the + button to increase the request size one by one. We could possibly get around this by adding another slider saying "if you send a shipment, send at least this many items", but what if my request and auto-trash numbers are the same? Do we ship items, and immediately send them back? Maybe this is where we could use that Buffer then...

Or possibly a simpler solution is defining "Minimum Vessel Load" to mean the same thing as "Request Threshold" in LTN-land, in which case we would not send a shipment in the above example. This is (I think?) in line with the current meaning of this option in DSP. Even though it's slightly less ideal as far as wasted energy goes, it is significantly simpler to reason about (both for the mod developer and the player), so this is my favorite currently.

To sum up

• IMHO it'd be great if, instead of a Buffer, we'd have an extra setting for Request Threshold (Minimum Vessel Load?)
• Crucially for UX, I'd want to configure this threshold in terms of number of items, instead of % of vessel. Researching a new level of vessel capacity doesn't suddenly mean my preferences for shipments change!
• And if one wants to be really funky, we could conceivably have separate settings for each of these for PLS/ILS.

Re. implementation, the logic part of this might be fairly straightforward (indeed, it gets rid of the need to manage Buffer data, reducing complexity). The most tricky part seems to be building the UI in a non-confusing way, and making sure all the edge-cases work in a non-surprising way. I'm somewhat motivated to give the implementation a go (possibly behind a config option), but 1. I don't have a C# environment 2. I haven't worked on DSP mods before, and most importantly 3. I wanted to throw these ideas out there, see first if they even make sense to anyone other than myself :D

[abesto]

If there aren't that many available then it will add as many as it can find.

That reminds me: "Minimum Vessel Load" also functions as Provide Threshold from LTN, so it'd also provide (heh) a fix for "hey a new building is ready, let me go and send a logistics vessel with this single building".

[mattsemar]

Wasted materials: some buildings are very expensive. My current solution is basically using the blueprints of Nilaus to request a reasonable number of items into 10 (?) stations on each planet I "colonize", but even that's a fair amount of waste - I won't use most buildings on most planets, and I never clean up after myself. Even so, this is significantly better than the current state of the mod.

How is this better? To me, it seems like you're overthinking things.

What I do is to have 1 planet where things like artificial stars are made. I then set min request to 2 stacks and recycle to 5 stacks of artificial stars.

If there are 1.75k available on the supply planet then all of them are sent to my buffer. If there are only 101 then that's how many go to the buffer. Once they're in the buffer then 60 (2 stacks) of them come to my inventory. If I clear out 300 stars on a planet, then suddenly my buffer has 2.05k. In that case, the extra 0.05k are sent back to the supply planet.

I think the problem you're describing only happens when your production capacity for factory buildings is too low.

By the way, though, the buffer is a huge simplification in terms of complexity. Especially for expensive items. I can use the 60 stars in my inventory several times and my inventory is refilled from the buffer. It's only when the buffer is fully depleted do you have to ship items. Finding places to ship items from is where most of the complexity actually comes from.

The main reason I left this open is that I can see the how it would be useful to be able to buffer 60k belts before laying down a huge planetwide blueprint. What's stopped me from implementing that is a combination of UI complexity and the feeling that it's kind of cheating to have a virtual inventory that big

[abesto]

How is this better?

I can set the supply limit on the producing planet, and the request limit on the requesting planet, to low numbers (say, 100 or so). With the Buffer, I can't. I'm guaranteed to have logistic-vessel-size number of buildings wasted that I will never use. I'll never build 1.4k labs. I'll never build 1.4k ILSes. The list goes on :)

I think the problem you're describing only happens when your production capacity for factory buildings is too low.

Negative, it just takes longer to waste those 1.4k buildings.

The main reason I left this open is that I can see the how it would be useful to be able to buffer 60k belts before laying down a huge planetwide blueprint. What's stopped me from implementing that is a combination of UI complexity and the feeling that it's kind of cheating to have a virtual inventory that big

I agree that'd be cheating, and if I wanted to do that, I'd want the game to (a) make me set my request size to 60k (b) set up explicit in-game buffering by setting up an ILS on the destination planet, and setting THAT to request the tons of belts, so that my (smaller) in-inventory requests can then be filled from there more frequently.

[mattsemar]

I can set the supply limit on the producing planet, and the request limit on the requesting planet, to low numbers (say, 100 or so)

You should be able to do the same thing with the mod. If you limit the supply to 100 total then requesting 2 stacks of, for example, interstellar logistics stations will load all 100 into your buffer and then remove 2 stacks for your inventory. No more will be fetched from stations until all 100 have been used.

[abesto]

Hm, I'm confused then. Guess I'll do some testing to better understand the current behavior. Thanks for taking the time to respond!

[abesto]

Oooh, I missed the crucial fact that shipments are not continually scheduled, only triggered when the buffer is emptied (and then never triggered again until the buffer is emptied again). Then yes, this is actually a solution to what I want, amazing! Thank you, and sorry for the noise!