Tweaking Machines

[Josharias]

Name: Machines
Summary: A library module with an assortment of machine infrastructure.
Scope: Mod
Current Goal:
Curator: Josharias
Github: https://github.com/Terasology/Machines
Compatibility: Singleplayer, Multiplayer

Related:
All the process definition infrastructure has moved to the workstation module
https://github.com/terasology/workstation


Recent Changes:
Pink fluids finally fixed. Water in a tank now uses the fluid registry to determine color. (2015-6-19)

Spoiler: Change log

2015-6-19

• Pink fluids finally fixed. Water in a tank now uses the fluid registry to determine color.

2015-1-25

• General UI Improvements. Support for multiple widgets on the right or left hand sides of the UI.

2014-10-24

• Fluid transport now interacts directly with FluidInventoryComponent blocks

2014-10-23

• Pipes, pumps, and tanks

2014-10-16

• Conveyor system now only works with single items and avoid stacking.

2014-10-15

• Multiplayer fixes for the mechanical power network
• Use the new interaction logic from engine
• Natural power regen/decay

Older

• Item Rendering
• Item Transport
• Mechanical Power
• Machines

Vision:
Provide the necessary systems to do neat things like the Assembly table (see discussion) or complex furnace systems. Integrate with the Terasology module ecosystem in a way that allows extension.

Main Features:

• Item Transport
  • Ejection/extraction of items to/from adjacent inventories
• Mechanical Power
  • Uses the BlockNetwork module to enable transfer, storage, and production of energy
• Machines
  • A default UI implementation for an inventory based workstation process that allows a single visual extension
  • A system to simplify setup of a block to be a machine. It will automatically add an inventory, slot mappings, and extension of the default UI
  • Surface Placement block family to assist connecting devices in the right direction
• Fluid Transport
  • Pipes, pumps, and tanks

 

[Josharias]

Getting started with processes

Turns dirt into grass: Grass.prefab

{
    "ProcessDefinition" : // This triggers the prefab to be included in processing.
    {
        "processingTime" : 3000 // sets the time that it takes the process to run (in milliseconds)
    },
    "RequirementInput" :
    {
        "requirements" : ["Assembly"]
    },
    "BlockInput" :
    {
        "blocks" : {"core:dirt" : 1}
    },
    "BlockOutput" :
    {
        "blocks" : {"core:grass" : 1}
    }
}

Getting started with machines

Basic machine with 3 block input slots, 1 tool slot, 1 output slot, and automatically processes: workbench.prefab

{
    "ProcessingAction": // This will call up the default UI
    {
        screenId : "SomeScreenIdThatYouHaveCreated"
    },
    "MachineDefinition" :
    {
        BlockInputSlots : 3,
        BlockOutputSlots : 1,
        RequirementInputSlots : 1,
        RequirementsProvided: ["Assembly"],
        AutomaticProcessing : true
    }
 
}

Edits:
2014-1-16 Change "schematic" to "process", MachineDefinition is all that is required to get a machine working
2014/1/20 Add RequirementsProvided to MachineDefinition.
2014/1/21 Add count of blocks on input and output
2014/1/22 Add processing time to the process definition
2014/1/25 Add automatic processing, requirement output slots, screenId

 

[Mike Kienenberger]

This seems like a restatement of crafting, but maybe I don't really understand crafting that well. I guess the difference would be that this is more of a fixed location + time crafting?

In any case, this is the kind of system we need to be Dwarf-fortress-like, and I'm all for it

 

[Josharias]

Changes

• Change term "schematic" to "process" to better reflect the input/output nature of what this does.
• Add runtime machine creation through adding a MachineDefinitionComponent to an entity (not perfect, but more stable than previously).
• Partially implimentation of items that provide requirements.

 

[Esereja]

I think this sytem works simulates well thigs like oven,saw mill....

 

[Josharias]

Changes

• Added MachineDemo module with implementations of : BasicAssemblyTable, EnduringlyHotFurnace (there is no fuel mechanism, it is just always hot like tamale), Sawmill (turns 1 trunk into 4 planks)
• Added Hand Saw (turns 1 trunk into 1 plank on an assembly table)
• Added Industrial Saw (a handheld version of the sawmill)

 

[Cervator]

Cool to see this coming, any plans to integrate with BlockNetwork, Signalling, or indeed the crafting in WoodAndStone? You seem to be a little higher up the tech tree, so maybe a natural progression thing

 

[Josharias]

As Cervator would say: "Integrate all the things!"

I would love to do integration with those mods as well. Creating infrastructure for various kinds of multiblock machines would be neat (using BlockNetwork or some sort of similar tech). Signalling will also quickly become a staple for on/off control of machines. It is neat seeing the work MarcinSc is doing with WoodAndStone, At some point we should probably collaborate... I am still doing a lot of exploration with this codebase so it is likely too soon to do any serious collaboration.

 

[Josharias]

Changes
- Add title to generic screen
- Add processing time mechanism
- Added tool slot to generic screen

 

[Skaldarnar]

Awesome! I've quickly done two three versions of a handsaw icon:

without outlines, 16x16​

with outlines, 16x16​

with outlines, 32x32​

If you want to include one of them just go ahead, if you want something changed just let me know
I can make an icon for the stationary saw as well if need be.

sawmill icon, 32x32​

Last a suggestion on processing or iron ores: How do like

iron ore --break--> iron nuggets --melt to--> iron ingots​

​

iron nugget, 16x16​

iron nugget, 32x32​

Edited with new versions of icons.

 

[Josharias]

Thanks for the icons Skaldarnar. Icons for the dialogs are a decent idea! I had not thought about that.

When I figure out how to do icons I will surely integrate these (I think there is currently some work being done with icons with NUI that I will wait for).

 

[Josharias]

Changes

• Add an output step that happens after consuming the input but before any delayed output. This allows for interesting things like adding components to the machine while it is processing.
• Add automatic processing. As soon as there valid input, it triggers processing.
• Machines now drop their internal inventory when destroyed
• Allow displaying a custom UI screen upon activating a machine (while still maintaining the normal machine to UI link up)

Demo Changes

• Add a bloomery which gets heated to 100 degrees and then provides the "Furnace" requirement to itself.
• Add a bloomery heater which consumes fuel (currently coal) to heat the block above it.
• Added automatic processing to the sawmill and enduring furnace

Also, my first youtube video post ever! Complete with in game music <chuckle> (thank you fraps for making a 30 second limit. It makes for nice and concise demonstrations. If only people at work would do this at meetings).

Yes, the UI is still ugly as a duckling.

 

[Cervator]

Nice! Posted to our social networks

Would you consider the Machines module stable enough to include with the game download?

 

[Josharias]

It is getting there quickly. There is one more feature I want to add (validating the output steps so that you cant overflow the inventory), and then some code cleanup.

 

[Josharias]

Changes

• Add output validation for block output (you can no longer start a process that cant fit its output blocks)
• Add item input and output
• Add the ability to redirect the input or output entities to the original block placed. This allows external systems to interact with your processes more easily
• Reorganize the codebase
• Moved the codebase to an official Terasology repository

 

[Josharias]

Idea cooking - Item Transport
What use is machines without a way to automate the input and outputs?

Currently cooking at: https://github.com/Josharias/Terasology.MachineDemo

 

[Marcin Sciesinski]

The demo looks really nice, but while appealing, in a big world with multiple players and multiple "machine lines" it might be a source of huge lag, which is why I'm not a fan of "buildcraft" style of item transportation, where items are passed from block to block. That is a lot of block metadata updates for the purpose of visual transportation of items.

 

[Josharias]

I do agree that it can be a large source of lag, as with any of the systems we are creating that iterate entities. Theoretically (I havent done thorough testing), there should only be communication when an item enters an inventory. All the animation parts are done on the client. At its very core, this implementation is just server side inventory manipulation with a client side rendering mechanism.

 

[Marcin Sciesinski]

So, where is the item "stored" during transportation on the server? As for iterating over entities, there are ways of avoiding this depending on what you want to do to the entities. If there is no updates on any of the blocks during the "transportation" part, then it should be ok, as no bytes will be sent between client and server.

 

[Josharias]

The item is stored in a normal inventory slot. The server adds a animation component that describes where it was, where it is going, and when it will get there (all constrained to inside the current block). This triggers mesh and location components added on the client (if I am correctly understanding how a client side system works) and updated in real time on the client. The server then removes the animation component or updates with a new block location.
Does this sound viable?