Tweaking Manual Labor

[Josharias]

Name: Manual Labor
Summary: Tools a workman needs to make digging and chopping easier.
Current Goal:
Curator: Josharias
Location: https://github.com/Terasology/ManualLabor
Compatibility: Singleplayer, Multiplayer
Gameplay:
Provide a base set of functionality when it comes to the digging part of a voxel game. This includes building tools to mine faster, dig better, chop harder.
The main gameplay mechanic is that blocks take a bit of time to break. If you want to relocate a large amount of material for a house, it would be convenient to have a tool that would break blocks in a fraction of the time. However, tools do not last for forever and eventually break, causing you to craft a replacement tool. That pain can also be reduced by finding better materials to craft your tools with.

Recent Changes:
Bug fixes and more. v1.0.1

Spoiler: Change Log

2016-05-29 - v1.0.1

• Bug fixes
• Integrate with Workstation 1.0.0
• Metal box recipe change
• Add wooden display block

2015-07-02

• Add the ability to tweak processing times based on the player or workstation.

2015-05-05

• Added crude shovel and crude axe. Removed stone tool, because it was confusing what to do with it.

2015-1-25

• Bonus damage on tools based on what it is made out of.
• Craftable torches.
• Campfire block.
• Creation of charcoal from wood chunks.

 

[Josharias]

Yay journal integration!

 

[Marcin Sciesinski]

Great! Happy that journal is used by other people.

 

[Josharias]

Its not beautiful, but it at least enables crafting stuff from nothing. I give you the overridden inventory screen (default 'I' key) which you can craft the first assembly table from.

 

[Josharias]

I finally buckled down and created a youtube video...

 

[Cervator]

Very cool! Been needing that

Will try to post places tomorrow

 

[Cervator]

Just realized as I rewatch while adding to news post - your active tool in a workstation renders on top of it?!? Very nice touch! Any major obstacles to also rendering non-tool items on top intelligently?

 

[Josharias]

Rendering items like on top of the workstation is easy thanks to the ItemRendering module (https://github.com/terasology/itemrendering). It works with items or blocks. There are a couple quirks yet. One being that 32x32 icons do not have a correct center location, so they are offset from where you would think they should go. Probably not a hard fix, bit just something to address.

Thanks Cervator!

 

[Skaldarnar]

The item rendering is awesome - it makes the whole thing more dynamic and less abstract I really like how the manual labor takes time as well instead of having instant crafting.

One minor remark: I think its a bit irritating that you grind ores with a hammer at the assembly table, but instead of grinding the stone as well you get an oven... Does it make sense to have different tools for smashing/grinding things and actually assembling stuff?

 

[Josharias]

That is a good point, Skaldarnar. Hammer usage is definitely inconsistent in that regard. It is a challenge trying to select tools for tasks that make sense. Hammers seem such an integral part of some sorts of assembly (think friction fit metal pieces, or screwless wood part assembly) as well as for breaking things apart. Maybe it would make sense to have specialized hammers... sledge hammer for crushing tasks, and a mallet for more precise work?

 

[Josharias]

Materials used in crafting tools can now add bonus damage (more balancing required).

Crafting torches now available. Options available for crafting with sticks and plant matter (from grass), or from sticks and charcoal (crushed and "smelted" wood).

New block, the campfire which provides substantially more light than just a torch.

The range compared to a normal torch:

 

[Cervator]

Cool stuff

Curiously, the campfire seems to cast a round light, while the torch is more square. What's up with that? If the torch is currently square shouldn't we make it rounder? Or does the campfire just look rounder since it is so much bigger so the granularity hurts less?

 

[Josharias]

I was playing around with the light options that exist. The campfire is attaching a LightComponent to an entity and placing it in the world (giving it also a LocationComponent). That as apposed to the torch which is using the block's "luminance" property which interacts with the chunk's light propagation. The chunk's light propagation is what makes it a square.

All in all, it has been an interesting experiment so far. Interestingly, lights inserted into the world in this way do not get blocked by obstructions. So if you put the campfire inside a building, it would also light the outside of the walls as well. Possibly I am still doing it wrong, but experimentation must start some place.

 

[Josharias]

New mechanism: sifting. Now you can separate out the undesirable substances out of ores using water and a little man power. More polish required still, but it has a fluid display and is "functional".

 

[Josharias]

Introducing the sledge hammer for crushing tasks, and the mallet for more precise work. (thanks for the idea @Skaldarnar) Tool and item assembly requirements have been reworked for better clarity. Sledge hammers will only crush ores into chunks now. Mallets take care of all the assembly efforts.

Also, I forgot about a side project that happened when developing the sifting mechanism, the magnifying glass. In order to better understand the material composition of tools and items one must analyze an item and it will display its composition.

Right clicking with the magnifying glass brings up a dialog. Drop the item to be analyzed into the input, and it will analyze the item, displaying the details beside.

 

[Josharias]

Added crude shovel and crude axe. Removed stone tool, because it was confusing what to do with it.

 

[prestidigitator]

Just an observation. I suppose this might be more related to Machines or Workstation, but I'm not sure which yet (just starting to get the hang of the architecture and modules) and actual the recipes came from ManualLabor so I'm just putting it here for now. I was putting stone, a fireplace, and a mallet in the assembly table, and couldn't figure out why it wouldn't build a hearth. I thought there must be something wrong with the recipe, so I kept going over and over the prefabs, components, etc. involved and really couldn't see anything wrong. Then finally I realized that if I had less than 8 stone in there, it would produce the hearth instead of the fireplace. I feel pretty silly now, but it does bring up the issue of ambiguous inputs. Given inputs of 8+ stone plus a fireplace, it's choosing the output that goes with the 8 stone rather than the one that goes with 1 stone and 1 fireplace. Is that the intuitive choice? Will there always be an intuitive choice? Should there be some kind of explicit disambiguation mechanism for the user, or at least an indicator of some sort to show there could be different outputs given another choice of counts?

 

[manu3d]

I was playing around with the light options that exist. The campfire is attaching a LightComponent to an entity and placing it in the world (giving it also a LocationComponent). That as apposed to the torch which is using the block's "luminance" property which interacts with the chunk's light propagation. The chunk's light propagation is what makes it a square.

All in all, it has been an interesting experiment so far. Interestingly, lights inserted into the world in this way do not get blocked by obstructions. So if you put the campfire inside a building, it would also light the outside of the walls as well. Possibly I am still doing it wrong, but experimentation must start some place.

I saw this message only now. It make sense that a light source that is not taking advantage of the light propagation system will light up surfaces behind other surfaces. This is due to the rendering engine currently supporting only one shadowcasting light, internally called "main light", that is effectively the light positioned in the direction of the sun/moon. More shadowcasting lights are technically possible (adding GPU memory use and render passes) but they pose the question: how many lights should be shadowcasting? And if the player is visiting an area where the number is exceeded, which lights should get priority? And as the player moves through an area and the lights get dynamically prioritized and de-prioritized, how can lights suddenly starting or stopping to cast shadows be made visually acceptable?

On top of that, parts of the lighting code in the rendering engine have been currently commented out as they don't seem to be working correctly and there seems to be other lighting bugs to be ironed out, compounding any lighting issue. In this context, and for the time being, I suspect it is best for all light sources to work through the light propagation system.

 

[prestidigitator]

This is due to the rendering engine currently supporting only one shadowcasting light, internally called "main light", that is effectively the light positioned in the direction of the sun/moon. More shadowcasting lights are technically possible (adding GPU memory use and render passes) but they pose the question: how many lights should be shadowcasting? And if the player is visiting an area where the number is exceeded, which lights should get priority? And as the player moves through an area and the lights get dynamically prioritized and de-prioritized, how can lights suddenly starting or stopping to cast shadows be made visually acceptable?

It seems reasonable to prioritize based on general brightness in the viewing player's vicinity. I say, "general brightness" because a small light might brightly light things close to it, but its intensity will fall off quickly enough not to be a significant source of shadows in the environment. It should be possible to figure out a rough metric for the average amount of illumination a light would generate within a reasonable radius of the viewing player (using rate of fall-of plus either intensity and distance or illumination evaluated at the player's position). Also, lights which are very close to the viewing player (e.g. that the player is carrying) shouldn't generate shadows because (neglecting reflections) the player wouldn't be able to perceive those shadows very easily. Obviously whether the light is fully obscured would be an issue, though. If you're inside a completely enclosed room (with no windows), the nearby torch should be prioritized over the sun even if it's noon. Does the light propagation system keep track of which lights provided the propagated light (and how much of it)? If so, that would seem to be good information to use as an input for shadow source prioritization.

 

[Josharias]

...Given inputs of 8+ stone plus a fireplace, it's choosing the output that goes with the 8 stone rather than the one that goes with 1 stone and 1 fireplace. Is that the intuitive choice? Will there always be an intuitive choice? Should there be some kind of explicit disambiguation mechanism for the user, or at least an indicator of some sort to show there could be different outputs given another choice of counts?

My personal goal is to minimize if not eliminate this disambiguation through having a wide variety of items to craft together. Basically, making this problem go away just by careful planning. Until then, it is definitely a non-intuitive mechanism. Any suggestions are welcome.