InterstellarLogisticsOpt

InterstellarLogisticsOpt

中文看我

減少星際運輸塔尋找供需配對、決定派船時的 CPU 開銷，適合物流塔較多的大型存檔。適配遊戲 0.10.35.29104，需要安裝 UXAssist 1.6.0 或更高版本。

使用

在遊戲內 UXAssist 的「星際物流優化」頁調整，設置從下一次模擬更新開始生效，無需重新讀檔。

| 設置 | 默認值 | 作用 |

|---|---:|---|

| Enabled | true | 開啓優化；關閉後使用原版調度 |

| AmortizeFactor | 1 | 調度間隔係數，範圍 1 至 30。設爲 N 時，派船檢查頻率降爲原版的 1/N；1 保持原版頻率 |

係數作用於全部航線，包括塔對塔、行星、恆星和物流分組。設爲 5 時，檢查頻率爲原版的 1/5，原本每 10、30、60 tick 執行的檢查，改爲每 50、150、300 tick 執行。這裏的 tick 是模擬更新次數。

優化了什麼

本塔供需不足時，遊戲仍可能需要維護對端的優先級鎖。mod 會省去沒有作用的庫存讀取和重複鎖刷新，保留必要的鎖維護和配對游標更新。這項優化在係數 1 時也生效。

係數大於 1 時，按塔編號把派船檢查錯開到不同 tick。每座塔按自己的固定相位執行檢查，減少同一 tick 集中處理大量塔的情況。

使用時留意

係數越大，派船響應越慢，也可能限制物流吞吐。例如在 60 UPS、係數 5 下，一座忽略優先航線的塔，每分鐘最多通過普通調度新派出 12 艘船；其他塔送取貨和返程裝貨另算。航程較短時，更容易受到這個限制。

相位分散會改變不同塔之間的檢查順序，較長的檢查間隔也可能讓優先級鎖在下次檢查前失效。因此，係數大於 1 時，以部分優先級準確性和響應速度換取性能，不能保證嚴格遵循原版的跨塔優先級順序。

單座塔的配對檢查一次完成，各塔的工作量也不相同，因此相位分散不能保證消除所有尖峯。CPU 開銷和 UPS 不會按係數等比例變化，調大系數後也要留意生產和實際送貨量。

性能截圖

兩張圖的 SampleAndHoldSim Ratio 均爲 200，按關閉和開啓優化的順序展示，開啓時係數爲 5。

| 面板讀數 | 關閉 | 開啓，係數 5 |

|---|---:|---:|

| CPU 圓環 | 19.708 ms | 12.354 ms |

| 物流調度 | 8.414 ms | 0.066 ms |

具體效果隨存檔、係數和其他 mod 設置變化。

關閉：

開啓，係數 5：

README

Reduces the CPU time spent matching supply and demand and dispatching interstellar ships in large saves. Supports game 0.10.35.29104 and requires UXAssist 1.6.0 or later.

Usage

Change settings in the InterstellarLogisticsOpt tab of UXAssist. Settings take effect on the next simulation tick without reloading the save.

| Setting | Default | Effect |

|---|---:|---|

| Enabled | true | Enable optimization; turning it off restores native dispatch |

| AmortizeFactor | 1 | Dispatch interval multiplier, from 1 to 30. At N, dispatch checks run at 1/N of their native frequency; 1 keeps the native frequency |

The factor applies to all routes, including station, planet, star and logistics-group priorities. Factor 5 runs checks at 1/5 of their native frequency: every 50, 150 or 300 ticks instead of every 10, 30 or 60. These are simulation ticks.

What it changes

A station with insufficient supply or demand may still need to maintain another station's priority locks. The mod skips inventory reads and repeated lock refreshes that would have no effect, while keeping required lock updates and pair-cursor advancement. This also works at factor 1.

At factors above 1, station IDs stagger dispatch checks across ticks. Each station runs at its own fixed phase, spreading station visits over time.

Things to consider

Higher factors delay dispatch and may limit throughput. At 60 UPS and factor 5, a station set to ignore priority routes can launch at most 12 new ships per minute through ordinary dispatch. Deliveries and pickups by other stations, and return loading, are separate. Short routes are more likely to reach this limit.

Staggering changes the order of checks between stations, and longer intervals can let priority locks expire before the next check. Factors above 1 therefore trade some priority fidelity and responsiveness for performance; they do not preserve strict native priority order across stations.

A single station's pair scan runs in one call, and stations have different workloads, so staggering cannot eliminate every spike. CPU time and UPS do not scale directly with the factor; check production and actual deliveries after increasing it.

Performance screenshots

Both screenshots use a SampleAndHoldSim Ratio of 200. They show the mod disabled, then enabled at factor 5.

| Panel reading | Disabled | Enabled, factor 5 |

|---|---:|---:|

| CPU ring | 19.708 ms | 12.354 ms |

| Logistics scheduling | 8.414 ms | 0.066 ms |

Results depend on the save, factor and other mod settings.

Disabled:

Enabled, factor 5: