Factory pipe system #3621
Open
Factory pipe system #3621
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The system is mostly stable, but it needs a bit more testing. This is meant to be used for complex laser-like pipes that form a network, but in practice it can be used with any mechanic that can be represented as a graph. Factory networks are completely minecraft-agnostic, so they can be used with anything. There is an example test implementation (see TestFactoryNetwork et al) that has everything a base network should do. There are also two base classes that remove most of the useless boilerplate for factory hatches and factory pipes. It is highly recommended to subclass these if possible. A typical factory pipe system would subclass StandardFactoryGrid and StandardFactoryNetwork. It is highly recommended (but not necessary) to make the grid a static singleton. A grid tracks all networks & elements and generally only handles graph/network topology updates. A network is a logical group of factory elements. If your pipe system needs to do anything special, the network is the best place to do it. A factory element represents a real machine in the world and can be a pipe, hatch, multi, or anything else. When a machine is placed in the world, it should immediately add itself to the grid, even if it's not connected to anything. The grid will automatically join two adjacent machines together. Factory elements don't have a superclass, they all implement a shared interface (see TestFactoryElement). All three types refer to each other recursively via generics. The grid & network subclasses should refer to the others, and the element interface should refer to the grid and the network. The element interface shouldn't have any generics that refer to the pipe system - they should all be pre-specified.
Dream-Master
added
the
new feature
|
I'll note I'm using this system on the Artificial Organisms branch and it's working great |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This system is meant to be used for complex laser-like pipes that form a network, but in practice it can be used with any mechanic that can be represented as a graph. Factory networks are completely minecraft-agnostic, so they can be used with anything.
There is an example test implementation (see TestFactoryNetwork et al) that has everything a base network should do.
There are also two base classes that remove most of the useless boilerplate for factory hatches and factory pipes. It is highly recommended to subclass these if possible.
A typical factory pipe system would subclass StandardFactoryGrid and StandardFactoryNetwork. It is highly recommended (but not necessary) to make the grid a static singleton. A grid tracks all networks & elements and generally only handles graph/network topology updates. It shouldn't hold any network or element specific state.
A network is a logical group of factory elements. If your pipe system needs to have any special logic, the network is the best place to do it. If the network holds state, it shouldn't be tied to a specific element or set of elements - it should basically be global state.
A factory element represents a real machine in the world and can be a pipe, hatch, multi, or anything else. When a machine is placed in the world, it should immediately add itself to the grid, even if it's not connected to anything. The grid will automatically join two adjacent machines together. Factory elements don't have a superclass, they all implement a shared interface (see TestFactoryElement).
A component is a way for factory elements to expose an interface network-wide. It's useful for exposing custom behaviour (i.e. storage) to all other elements on the network. The standard factory network will let you query components automatically (in a manner similar to interface dependency injection).
All three types refer to each other recursively via generics. The grid & network subclasses should refer to the others, and the element interface should refer to the grid and the network. The element interface shouldn't have any generics that refer to the pipe system - they should all be pre-specified.