Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
so...suggestions, anyone?
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.
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.
* 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.
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.
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.
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 :/
on a pump, left output to router right input. router output to centrifuge input.