to get the discussion started:

引用自 Kherae：

I am dragoncat Khe. hi. Just a shoutout to people who want the item network stuff optimized: that's on the menu. I have a higher priority first, however. I'm nailing down an annoying bug with containers/routerrs loading: entityIds are not static, so I gotta make a workaround. totally doesn't help I have to fight off my own lousy memory. imagine you start working on a fix, take a nap, and forgot everything you were doing. hiya!
I feel it important to note the biggest drawback with my item network, performance-wise. In order to take items from a container...the container must be loaded. thing is, using loadRegion doesn't just load where the container is, it loads the entire sector it's in. it's this, or the router completely ignoring unloaded containers. I chose the first option, because I want my entire network functioning regardless of distance. It's not as easy as using keepAlive, either, with the container links. Open to suggestions, but preferrably in discussions. I'm making a post there.

so...suggestions, anyone?

I have no idea how Starbound modding works, but what I would personally do, if the normal container logic isn't good enough for performance, is to make network-enabled containers, rather than storing the item data themselves, poll a "master database" of item containers with what content they hold, and just update this on interaction. Then, in turn, have the item network not be concerned with the containers themselves but merely their "entry" in said network database. Then, whenever a container is disconnected, turn them into regular containers.

That is, assuming I haven't completely misunderstood how the item network works, but as I understand it, it just allows you to connect any container with any other and allow interaction via usage of terminals or FU machines.

well, it'd be nice if that were a viable option, there are a few issues to it.

• Deliberately avoiding centrallization of entire networks, so...routers. they're flexible things, truly, though I do have improvements in mind for some functionality. putting a long list of inputs/outputs in is tedious...
  
• doesnt alleviate the main concern of loading connected containers that are in unloaded sectors, and the loss of entityID information upon area unload. already doubling down on this, though. system doublechecks by coordinates. the loss of IDs is somewhat annoying. causes unwanted behavior.
  
• quite frankly, a databank would be redundant. routers need to know what is where at time of execution, not where it was a second ago. So they poll container locations (and the containers there), marked by container links or matching code. they load the area, get the new container's id if it's still there, then start routing stuff.

and yes, there is some misunderstanding of how the item network works.
FU machines and container links are endpoints in the item network. all they links are for is marking down input/output containers...same with the code I added to FU machines. repeaters/routers carry information about all connected objects in both directions, on separate tables.Routers have the job of moving items between containers, and do the main brainwork. That's their job. As stated, they're fairly flexible. But I'm still looking into coding improvements...

so...in short: idea would be nice, but it's a big hassle and doesn't solve some of the bigger problems.

how do FU's watchers work? could you reuse the code from them for keeping stuff loaded instead of having to write and optimize your own?

The main problem I was thinking of to solve was "doesnt alleviate the main concern of loading connected containers that are in unloaded sectors". Surely, with the approach I suggested, this wouldn't need to be the case? By having a master list that doesn't depend on loading specific containers' sector. All that is needed is to ensure consistency, by -- once the player ends up within the area of the container -- syncing its content to what it is supposed to be by checking if it's connected to an item network, and if so, reload the content using it.

FU's watchers do the same thing my routers do, in a way. the watchers just spam world.loadRegion(<insert rectangle for 20 tilesin all directions) every 20 seconds, while active. Fiq, the container has to be loaded to withdraw from it, unfortunately. unloaded means no ID, no ID means no withdraw. or deposit

So you're saying this wouldn't be possible? :
* A container is connected to an item network
* The item network assigns an ID to the container, stores the items of the container, etc, in its item network "database" (potentially creating one if you just made a new network)
* Whenever you want to access a container's items within the network, you simply look at this database, pull item data from there, etc. If the region the container is in is loaded, also update the container's content
* If the region is NOT loaded, still pull items from the db.
* Whenever a container connected to an item network is loaded, refresh the container's content according to the network's master list
* If the container is disconnected somehow from a network without its region being loaded, fallback to loadRegion logic

This isn't perfect and would potentially be awkward to do logic for, but this way, you avoid the need to have the container's region in memory.

it's possible, but it's a lot of work...and involves setting up more wiring nodes and filtering for them.
one of the main design goals I had for this project was removing any and all delays between when an object is taken from a container, and when it's added to another one. that means either the routers send the transfer message to the databank (not gonna happen), or the router does the transfer as they do now, but based on database stored info. (which leads to synchronization issues) storing item info in a central location is possible, it's just annoying to implement. it adds some script overhead to the system, some lag, and I'm not really sure whether that it will actually be an improvement.
also, the part you're missing, the part that's most important, is that IDs are not fixed. the game generates a container's ID, but it can and will change. the coordinates are a fallback in case of that change. If I did have a central databank, it'd have to somehow know what routers are near what container IDs, WITHOUT using IDs. the only option, sadly, is using coordinates.

Right, I am aware that it is awkward. I suggested it under the assumption that loadRegion (for whatever reason, but it wouldn't surprise me from what I've heard of how poorly optimized this game is) caused severe lag if done on a major scale. Yes, it does introduce overhead, and synchronization issues if you fail to properly refresh container content before a player decides to interact with it, but it avoids loadRegion. As I said in the beginning -- I don't know how SB modding works -- so this might actually worsen performance. But really, I don't really see another approach to solve this that doesn't involve loadRegion in some way.

EDIT: Also, I should clarify, that I was aware of the ID thing since you mentioned it beforehand -- when I said "assign an ID", I just meant a way to identify the container, whatever the best means of doing that is, which clearly entity ID isn't.

mhm. basically this is an aspect that can't be dealt with without breaking the network.
so that brings up other methods of optimizing code...and I am kinda out of ideas there too. I'm really against the centrallized controller idea, or I'd probably go that route. so instead, I have to go for cautioning people against using insane amounts of routers or heavily redundant networks :/

Hi, I do not understand how the Router works. I tried to connect a solar panel and a container to the input port. I connected a container to the output, but nothing happened.

Searl, you dont connect solar panels to 'em (yet). also, if nothing's happening, it's probably because the solar panel's wire node is sending a zero. I need to change 'power' to say 'logic' I suppose. if it's not the solar panel's output being a zero, then it might be a bug. I finally finished some work gutting certain annoying bugs...last night. only just pushed the changes on git so they're probably not live

引用自 Khe：

Searl, you dont connect solar panels to 'em (yet). also, if nothing's happening, it's probably because the solar panel's wire node is sending a zero. I need to change 'power' to say 'logic' I suppose. if it's not the solar panel's output being a zero, then it might be a bug. I finally finished some work gutting certain annoying bugs...last night. only just pushed the changes on git so they're probably not live

Thank~

ok but how do i transfer items from say a pump to a centrifuge... the router UI is very vague and there are no explanations i can find on google.

/spawnitem networkguide-codex
on a pump, left output to router right input. router output to centrifuge input.