The trading computer is causing lag/skip/freeze in item picker lists.
Seen in large adventures or with many additional nodes added to SOTP by extensions.

Only occurs if large numbers of nodes are known. Setting all nodes to 'unknown' removes the lag.
Uninstalling the tradingComputer also removes the lag.

With Renegade, TBR, CC and Semesta loaded into SOTP, (count (sysGetNodes)) gives 113 nodes.
After setting all nodes to 'known' trying to scroll down the Cargo Hold item list with either the Down arrow or PgDn will cause the screen to stay frozen on one item. On releasing the key after a few seconds the display will skip to the last item in the list.
Loot screens show similar behavior. Items will loot in an irregular manner as the list skips to widely separated items. Note: all screens are working but show erratic/skipping behavior.

In the Network mod with 148 nodes, the Loot screen can freeze for many seconds (but there may be bad code in this mod amplifying the problem).

Also occurs in Sell screens.

Cargo Hold, Loot and Sell screens all use rpgItemTradingComputer.

Cargo Hold screen showed this behavior only once in VOTG (87 nodes).

Renegade, CC and Semesta loaded (55 nodes) doesn't show any unusual behavior in any of the screens.

Assuming TSB isn't an adventure and adds more nodes, loading it as well should make the lag more noticable.

EDIT: Was also happening in 1.8b1.

zip
Network dev 35.zip
assumedpseudonym 26 Jul 2018:

 As TBR’s developer and someone who runs SOTP/CC/EP/TSB/TBR/Renegade/Semesta topology regularly, I can confirm that it gets laggy in a hurry. It gets bad enough that I occasionally just debug the trading computer off of the playership — which I will also confirm works. I shudder to think how my old and mostly retired Atom would handle things… x.x

nms 26 Jul 2018:

Currently, rpgItemTradeComputer calls sysGetItemBuyPrice and sysGetTopologyDistance for every system in the game. Since it only recommends selling in systems up to three systems away, it only needs to call sysGetItemBuyPrice for those systems. But sysGetTopologyDistance might be the bigger problem for large numbers of systems, since its complexity grows exponentially with the distance between them. Instead, we should search from the current system for neighboring systems and their neighbors, etc. We could limit the number of systems checked in case a huge number are within range. And we should save the results for each system. This could be done at game creation, on entering each system for the first time, or the first time it's needed. It could be done in TLisp using sysGetStargates and sysGetStargateDestination, or a new C function could be added.

Related: Trade computer gives different recommendations at different stations

relanat 1 Aug 2018:

I was thinking of trying to modify it so it created a node list of only systems within 3 distance. Possibly doing this in <OnScreenInit> might work. Then all the items in that station could use this list. Given that 50 known nodes doesn't show any lag this is one possibility.
EDIT: Probably best to create it the first time it is needed and then save it for the rest of the game. Doing it at game start or on first system enty might make game creation or gating take longer. Although there shouldn't be much delay. Dunno.

nms 3 Aug 2018:

As discussed on the stream, we should handle the possibility of the topology changing, so caching data about it, either in the engine or in TLisp, will require keeping track of when the topology last changed (or for TLisp maybe firing an event when it changes).

george moromisato 3 Aug 2018:

After looking at the code, I see a few of possible solutions:

1. We could enhance the sysGetNodes call to take a criteria of some sort. We could then specify that we're only interested in nodes within 3 gates.

2. The call to sysGetTopologyDistance currently uses a recursive procedure to figure out distance between any two nodes. During the recursion, we temporarily store distances in the node itself. But after the call is done, we flush all that information. If we could keep this information around, then multiple calls to sysGetTopologyDistance would be much faster (assuming at least one of the nodes is the same).

3. We could enhance sysGetTopologyDistance to take a list of nodes in the second parameter. In that case, it would return a list of distances between the first parameter and each node in the second parameter. Like in #2, this would allow us to cache the distance information in each node.

george moromisato 12 Aug 2018:

I've fixed this in 1.8 Beta 3:

  • There was a bug in the main loop. If a key-press took longer than a frame to handle, then we would stop animating. For example, if you leaned on the down-key in one of these dock screen, the screen would never update (it would freeze) until you got to the end of the list. This happened because we keep trying to process the keys and never got a chance to update the frame. I've fixed this in 1.8 Beta 3 so that we always paint.
  • I added some code to the Trade Computer to cache its list of nodes (nodes within 3 gates). The list is cached with the screen, so we don't need to recalculate every key-press. But since we recalculate every time you bring up a screen, we don't have to worry about the topology changing (unless it changes mid-screen, but even then, you will just get stale info until the next time).
  • With the code above, moving through the list is very fast, but entering the screen takes over a second. I added a criteria parameter to sysGetNodes to try to optimize this, but in doing so I discovered a bug in sysGetTopologyDistance. The bug made this call much slower than needed. Fixing the bug solved the performance issue.