Mechanical Power Sources & Line Shafts

[redram]

So this is my giant power suggestion post I've been wanting to do for a while.  Some of this has been touched on in other threads, but I wanted to lay it all out in post, to try to make the flow of it more apparent.  It's going to be very long, lot of spoilers.  I'll be going through the general "ages" of power, and also giving examples of how they might be applied.  I'll also try to touch on some of the considerations for automation.  Hope you have your coffee. 

EARLY POWER

Early Power encompasses animal power, and also wind and water.  Though wind and water could require metal components.   But all will be the only available power pre-iron, which gives them a decent use window.  They have in common that one power source will only power one (*maybe* two) 'machine'.  You cannot accumulate or divide power with these sources, and some forms of animal power cannot even use shafts, they must be directly beside what they are intended to power.

ANIMAL POWER

Spoiler

The earliest power source, available in the stone age, would be animal power.   This could be divided into two or three tiers:

Running Wheel.   The running wheel in this scheme is the smallest unit of power.  It consists of your stereotypical (semi)circular running wheel, with a rabbit or other small animal inside.  This will have limited uses.   For instance, if the fire pit capacity were reduce to 16 units of food, but the player could construct a rotating spit, that could hold four stacks of 16.  They can either sit there and turn it by hand, or, (preferably) hook up a rabbit wheel to it.   Perhaps it could also be used to power fans (to dry jerky or herbs quicker, or affect alchemy) or stir pots, or make icecream.  Maybe other small uses.  The wheel is powered by whatever food the animal prefers.  Probably mostly vegetables.  A small trough would be built into the graphic, which would show a number of food icons, so the player can see about how much food is there.  The food is consumed over time.

Basically this power source is practically fan service.  People like pets, but if you give them a possible use, they will like them even more.  People would eat this up I think.  Later, when mechanisms and lines shafts are available, you could actually hook up these wheels to a line shaft to accumulate power.  This would be hugely inefficient, but I think players would do it anyway, for the lols.  Allowing people do have a lot of flexibility in the power scheme down the road will, I think, be a huge draw.

Treadmill - This is optional and probably not needed, but it would allow medium animals (dogs) to be used.  This, unlike the wheel, has actual historical precedent.  might be used for a smaller version of a grindstone?  Or maybe it can power two small 'machines', one on each side?  Online sources suggest dog/sheep treadmills were often used to power butter churns.  FYI there were also horse-size versions of treadmills.

In both the wheel and treadmill, once the food runs out the animal leaves the device, so it behooves the player to build a small pen around the area the animal will get off, if the device is not otherwise contained in a building.  Animals are either picked up and placed on the treadmill (if small), or maybe once food is in the trough they automatically get on the machine.

Beam Power - Beam power is for oxen, donkeys, and horses.  They walk in a circle around whatever is being powered.   The most obvious use would for the quern.  And btw, the horizontal mill stone that we're familiar with from TFC, I think was only ever historically powered by wind or water directly, I think it may have been too heavy a load for animals, which more typically used a vertical stone as shown below, near as I can tell.  The only images I could find o animals powered a horizontal mill stone involved some pretty large wooden gearing to multiply the animal power. 

I would suggest (as the name implies) that beam power require a special resource - beams.  I suggested beams before, here.  They'd be a good stone age use for animal power conveyance I think, and could have applications in other machines and constructs.  But in the scope of "Beam Power", the power source involves one beam.  For the quern, maybe it just takes some rope and a beam to make the quern animal powered (plus leather for the harness, but that's not quern-specific).  I'm not really entirely sure what other uses you might be able to put an animal walking around in a circle.  But grinding is such a chore, I think that even if that were the only thing, it'd still be worth it.  Possibly you could hook a horse up to a vat to mix mortar faster?  Crush grapes?  Press oil?

Now another form of beam power might be the "horsepower".   Horsepower power units are very hard to google image search because horsepower applies to millions of other engines and machines, obviously.   But if you put in "horse powered gears" you'll find the stuff. 

It's basically a self-contained gearbox, that was often used as a hoist, having a spool underneath, but could also create torque power on a shaft (as shown in above pictures).  Not sure if this has much of a role to play in the game, unless it were able to be made from copper or bronze.  But at the same time I'd hate to let the player avoid some of the other power forms.  If this were iron age, it might be useful possibly as a portable power source.  You put it in your wagon (unlike most other power sources) and when you get where you're going you unhitch the horse, and hook them up to the horsepower.  Again, it would require a beam.  Which could be felled on-site, or carried in the wagon.  Might be the first practical mine hoist power source (but holds limited rope length).

 

ELEMENTAL POWER

Spoiler

Wind Power - with windmills, the player reaches the next level.  They produce less power than a water wheel, but are not as site-constrained.  And much more power than animals.  They take a lot of linen or leather to flesh out the sails, maybe also many beams.  May or may not require metal, depending on exactly when they are desired to be available.  Wind (and water) power are better than animal power, in that they can use power transmission shafts to send the power to places not in their immediate vicinity.  I'd suggest that windmills have some mechanic to perhaps work better at a certain height, or check around them (when placed) for obstructions (such as landforms or buildings), and if they find too many they tell the player this.  Maybe they once in awhile recheck, to make sure the player hasn't enclosed them in a box or something.  

Water Power - Water wheels produce even more power than windmills, but are specific to certain areas of water (maybe).  There has been a bit of discussion of water wheels (and even windmills) in another thread.  I would much prefer for wheel-power capable spots to be world-gen only, preferably in world-genned rivers of some width.  The could appear as areas of water with some turbulence, or something.  Or where water falls.  I'm basically hoping the player won't be able to create water source blocks till the iron age at least, but then only via pumps.  This makes finding such natural occurring spots very special.   Water wheels would also require beams, possibly metal.  And like windmills they could transmit the power via shafts.  If river turbulence areas can be many blocks in width, then maybe the player can gang the wheels side by side to get more power. 

In general I think both windmills and water wheels should have a wear component, though not a fast one by any means.  Maybe every 10 grindstones or so?  Perhaps the player can grease the hubs with animal fat to prolong the life.  With wind and water power, the player can power primitive trip hammers and perhaps even stamp mills.  Though both should probably require some metal components (hammer head, and stamp heads), which will wear out faster if copper or bronze, vs iron.

You could even have it so that the horsepower could power these things, albeit at greatly reduced speed.   And you could further have it that a 3-gang water wheel works faster than a 1-gang.  But I think if so, the relationship should not be linear.  Maybe 2 wheels do the same work in 90% the time of one wheel, and 3 wheels in 80% of the time.  Depends how easy it is to power 3 wheels.   

Now windmills and water wheels can transmit power via wooden power shafts and cog wheels, but the disadvantage of these might be that they cannot divide or accumulate power.  So you can only power one machine at a time, per power source.  You can use them to power multiple items when you get to the iron age, and get line shafts.  These limitations I think balance it so that you don't need to make wood cogs and shafts wear out, vs iron ones.  Just the wind/water hubs, and the machinery itself.

These next sections aren't going to have as much detail laid out right now, since they involve so very much detail.  I may expand them at a later date.

STEAM POWER

In the iron age, things could start to get interesting.  The player can build boilers, which consist of a large multiblock iron tank (the metal sheets placed and riveted in-world), and a burner.  They are separate modules, allowing the player to heat the boiler with whatever fuel they choose.  Options would include wood and coal at a bare minimum, but further down the tech line might be alcohol and magma, maybe even oil or methane gas.   Coal  could be powDered with a specialized grinder, and blown in to increase the heat potential.  The idea would be to allow the player to start adding on technological gizmos to automate and/or improve the engine setup, customizing it in a way not possible with Early Power.  There could be safety valves, without which if the temperature goes too high the boiler explodes.  Governors, without which if the machine runs too fast it wears faster.  And of course eventually steam pistons and maybe steam lines.

COMBUSTION POWER

An optional power, combustion power could again have various sources.  Wood gas, alcohol, refined oil.  Depends on how far the vanilla game wants to take things.  To be clear, I'm not talking about something like a modern car engine.  I'm talking about early 20th century hit-and-miss engines, and the like.

ELECTRIC POWER

To get really steampunk, electric power.   To suck up all that extra copper you haven't used for ages.  Again, I'm not talking boring modern electric motors.  Good "open frame" or "antique"  electric motor, and you find the really interesting not-OSHA-approved stuff.

LINE SHAFTS

Spoiler

Along with the iron that allows steam power, would come line shafts.  Line shafts would be revolutionary in that they would allow the player to hook up multiple power sources, to accumulate smaller power sources into a larger total amount of power.   They would also allow one large engine to power many smaller machines by spreading it out.   I think line shafts would be a much loved feature of the game, as they would involve a lot of planning and organization.  You have to lay out the lineshafts in an efficient way, but also have the takeoff pulleys and belts aligned in a efficient way.  And the shops they would make would, I think, look incredible:

Lineshafts would consist of 3 parts: Pulleys, shafts, and brackets.  Lower tier metal lineshafts would have to have brackets more often, and could only handle a certain maximum power.  They would be so numerous that it probably would no be a good idea to have them wear out.  It'd be too much maintenance I think.   The pulleys would be connected to machines by leather belts.  This would be a large leather use, and the belts should wear out I'd say.  If leather working were a skill, high skill belts would be a high demand item, for the longer lasting quality. 

Now if lineshafts are adopted as a major mechanic, this also suggests that machines  probably need to have consideration in their models to accomodate this.  That is, they need to have a point on the model, where the player can attach a pulley.  In order for pulleys to align in a universal fashion, they'd probably need to be of a uniform location within the block space (centered in all directions, most likely), and only have maybe a maximum of 3 sizes or something, though one size would probably suffice.  This assumes that machines can have other power sources though.  Perhaps a machine can also be hand-powered, having a hand crank flywheel.  This would be tedious, and only make sense for a few machines, but the tedium would drive the player toward lineshaft or other power technology.  Some machines also might accept a driveshaft directly.

If you want to get more complicated, you could justify pulley sizes by speed.  So certain machines require certain speeds of operation.  With 3 pulley sizes for both lineshaft and machine, you can have 7 speeds (if the pulleys are the same size the speed is the same, no matter the pulley sizes).  So fastest speed would be large pulley on lineshaft and small on machine.  Good for drill presses or lathes.  Slowest speed would be small pulley on lineshaft and large on machine.  Good for churning or sawing.  Same size pulleys would be medium speed.  Or you could just have small and large pulleys, which gets you 3 speeds in total.  If the player arranges things too fast, the machine wears out very fast (though it does also operate faster).  Too slow and the machine operates slower than it could, or may not operate at all if it doesn't have the torque.  The upgrade would be gearboxes.  gearboxes could be paired with governors to regular the speed as the player wants.  Or, more advanced gearboxes could have fully adjustable ratios.

I think if set up properly, the lineshaft/gears portion of the game could be very interesting, and certainly much more visually compelling than the super-simplified mechanics of vanilla MC.  It could possibly even allow the player to do ridiculous but fun things, like creating a rabbit powered wheel farm hooked up via lineshaft, that produces the same power as a steam engine.

SUMMARY
So, in summary, power sources could go Small Animal via running wheel (no tech gate) --->Medium Animal via treadmill? (tech gate metal?)--->Large Animal via beams (tech gate transport)--->Elemental Power (tech gate linen, maybe metal? windmill more universal, water wheel location limited) ---> Steam power & line shafts (tech gate iron) ---> Combustion Power? (tech gate steel)

I think the advancement from simple powering of machines to lineshaft would feel like a personal industrial revolution to the player, and if done right the myriad possibilities would be very compelling. 

 

 

[Elwood]

I absolutely love the idea of powered things and I agree with your proposed progression.  I think the biggest problem is necessity.  Like what is the real problem we are trying to solve with automation? 

Granted there are some immediate needs for automation in the current state of VS like mass production of construction materials (making brick, wood, plaster, etc) 

In years of playing modded MC I always asked myself. "why am i building all of this automation or generating large amounts of 'energy'?".  I would use my 'magination to create a problem to solve. "we need to produce 64 blocks of iron to appease the lava gods" or use a modpack with quests.

I love automation and mechanics but need some real purpose besides avoiding the tedium of grinding to survive.   

VS needs to first create a problem for us to solve using mechanics and mass production.  Maybe the trade system might fit the bill but that could be too much like "questing". Maybe grain and other products need to become a "resource" that is continually depleted to maintain some bonus you have gained.  eg. a full granary gives health bonus to the owner if it stays full.  But then to keep that progression going or maintaining it we likely need to have bigger threats near the more advanced villages/players like raiders so need to build walls and defenses or you reach. perhaps the need to keep an armory full of swords to keep attacks away.  drives the need to build a bigger forge.

If VS can ever give a real sense of progression and a purpose to keep maintaining it will be the best survival game ever.  

[Telem]

Well one of the goals could be transportation in multiplayer it´s normal to have multiple settlements which will, sooner or later, become connected to each other.

Just today I had some chat with Stroam about trading and this should be possible in a time efficient manner.

Things like windpowered chariots(holiday in denmark I´ve often seen people ride a surfboard with wheels on the beach) normal carriages maybe flying ships( remember the archimedes mod in MC?) could provide for that. In addition this could give another perspective for the great and beautiful worlds that are generated.

[Stroam]

I have to agree with Elwood there that there first needs to be a problem before mechanical stuff becomes a solution. For instance, gregtech if you break it down you see a cycle of:

• gather resources and generate fuel
• make power generators
• make more machines to make better generators with higher fuel demands
• repeat upgrading everything until running out of better power generators.

While I love the complexity of gregtech it did feel like it was a self perpetuating cycle that without other mods that needed those higher tier products, was pointless. Now a lot of games take the easy route and have better products make better gear. Players love better gear even if they have no need of it.

My point being introduction mechanical systems to VS should be slow, deliberate, sufficiently complex, with marginal but incremental gains. All system start out very rudimentary and often time barely work and not much better than a more manual and time tested processes. Over time by using different materials and more sophisticated pieces a system will keep gaining 5% efficiency and break down less with each upgrade. The final result is a machine that does a task that use to take many people, many hours to accomplish.

To make conditions ripe for mechanical systems there needs to be processes in VS which take a lot of time and have a lot of steps. For instance a machine that turns bread into grain currently would be useless because it's so easy to do in mass. Even making brick blocks right now only has 3 steps which does not make it a good candidate for machine introduction. Before mechanical systems are introduced there also needs to be a better way to collect and distribute resources. This is where transportant and markets come into play. Before markets and transportation there needs to be a reason for people to come together.

IRL people game together mostly due to food which as technology and methods improved, allowed farmers to support  non farming occupations. This is why complex societies developed first in areas with less abundant food. I'm not sure what would bring people together in a video game.

[redram]

The reason I made this thread largely has to do with how even the simple machines are designed.  The part about line shafts and the pulley, drive shafts and so forth, and how that needs to be positioned in a way that works across all machines.  While certainly the assets are not needed now, a comprehensively planned system will be easier to execute in the long run, and a roadmap will inform decisions made in the early stages of the game.

As for the why, at some point you have to ask the question why are we playing this game?  Why am I spending all this time mining?  I always found it quite humorous that in pretty much every TFC lets-play, the thing that you probably spend 50% or more of your time doing - mining - was mostly excluded from the videos, because it was so grindy.   To me the game at it's heart is about discovery, but what good is that if you can't use the things you discover?  It's really a topic deserving it's own thread.  I can probably name dozens of design paths the game could take to 'make use' of power, but it all boils down to 'if you want the better thing you first need this'.  In my opinion, the more limited the game is to 'real life', the more limited it will be in game mechanics and their usefulness.  But ultimately it's up to the vision of the devs.   

[Elwood]

I think understand your point. I should be able to choose any power source i want.  Like if i am a farming community i might choose wind power since i can grow flax for linen sails.  I can choose power transmission, shafts, belt drives and gearboxes based on resources i have or the design i want (wood & iron for shafts and gears or hides for belts).  But the key thing is all power and transmission should be interchangeable and should all work together regardless of my choices.

So both power and transmission should be part of the fundamental systems of the game and not dependent on mods. (or we will just end up with power systems with various acronyms)

Also what should be fundamental to the game is whenever a new concept or product is created there should be some vision of how the production processes of the product can progress.  eg. start with manual linen farming->  human powered loom -> external power -> mechanical looms-> mass production of linen cloth which also requires mass farming of flax, water pumps, irrigation.  (I still don't know why i need so much linen but someone else can solve that)

 

[Stroam]

Well then let's not talk about power sources since those or the obvious stuff. Let's talk about how you'd uses structural components, mechanisms, and control components and assemble them into parts that you can add to the machines. I want to hear about bearings, axles, splines, fasteners, seals, lubricants, gear trains, belts and chains, linkages, cams, brakes, clutches, buttons, switches, indicators, sensors, actuators. I want to hear about complex systems of ropes and pulleys with different mechanical advantages. I want to hear about how all these parts are made and assembled without a crafting grid magic. Most of all I want to hear about the limits of these systems and what happens when something goes wrong.

[redram]

18 hours ago, Stroam said:

Well then let's not talk about power sources since those or the obvious stuff. Let's talk about how you'd uses structural components, mechanisms, and control components and assemble them into parts that you can add to the machines.

I don't think that the power sources are necessarily obvious.  The details are not, certainly.   I also didn't really want to step too much on Milo's Logical Mechanics post, which  I think is more concerned with the 'communicating' parts, rather than power generating parts. 

But yes, to go into a bit more detail, I do think that as you progress, the 'engines' should have more and more internal parts that wear out, but that can also provide bonuses if a quality system is in play.  In the animal power age, probably nothing wears out (except the animals themselves). In the elemental tier I mentioned that maybe you can grease the wind or water wheel hub to make it last longer.  The hub itself might slowly wear out over time, perhaps also the linen (patches could disappear, leading to a ragged appearance and decreased power).  In this scenario the assemblage should be comprised of a hub, and four blades (windmill) or 8 paddle sections (water wheel).  So if the hub wears out, you can break it down and get the other parts back.

When you reach machine power, things could get interesting.  Bearings as a wear component would give ongoing use for tin and lead in the form of babbitted bearings.  Higher quality bearings extend the crankshaft life, and also last longer.   Crankshafts and pistons would also be wear items common to both steam and combustion engines.  If the engines are multi-block enough, the player maybe has to remove one of the blocks to access the piston, and more to access the crankshaft and bearings.  Valves might also be another internal wear item.   In this way rebuilding an engine becomes and actual task that takes some time and work.  If that's the case the parts should not wear out in a day of course.  But again, I think this kind of stuff could be a real driver for a quality system, as people attempt to get the most 'souped up' engine they can, with the best parts, for highest efficiency.

There could be sight oilers as an accessory, which would be glass and brass, and may require special tools (jewelers tools) to create.  They could be an accessory that increases life of piston and crankshaft.  The player would need to watch them and keep them filled with oil for them to be effective.  A single engine might have several.  Later you can construct and oiler manifold, which is a single box that will oil all the points, so you only have to fill one thing, and it holds more oil.

For hit and miss engines, the magneto would be a very important wear item, again composed of fine parts.  When constructed, it has a built-in 'life'.  After that life expires it dies, and the engine won't work till a new one is installed.  Quality extends life, obviously.

Both steam and hit and miss engines would need water.  Steam engines would need lots of water, and the player will need to have a storage tank piped to the boiler.  There might be a few ways to accomplish this.  Maybe a rain-filled water tower if you don't use the engine a lot.  Or maybe an aqueduct system if you do.  Perhaps they can build a pump that pumps water into the tank.  Hit and miss engines use much less water (it's only for cooling, not steam power) so in that case the player can fill the engine's built-in tank by hand, or pipe in a small amount via a small pump.  This makes the pump a convenience accessory item, and not a fundamental part of the engine itself. 

Clutches could be as simple as a slack-pulley for smaller engines, or iron geared mechanisms for larger. 

As mentioned above, flyball governors could be an iconic accessory.

If VS steam engines are of the walking beam type, then the different parts - boiler, piston, beam, flywheel - would all in fact be separate pieces that could be arranged, to a degree, in varying configurations.  The boiler could in theory be quite remote from the rest of the parts.  The piston-beam-flywheel would need to be a bit more standardized in arrangement, but could allow for a certain amount of elevation separation.

It can all be as complex or not as the devs want.  And while steam is certainly a long ways off, Tyron working on the mechanical rendering system right now it looks like.  So maybe it's worth discussing some basic ideas?  Like the notion of limiting power division in pre-steam machines? (which btw should reduce the number of sprocket formats Tyron has to animate).  Maybe I'll go rev Milo's thread to talk about the 'communication' bits.

 

 

[tony Liberatto]

I love the idea of Mechanical Power.

I hate the idea of Modern Machines that use gasoline or Electricity. 

Steam is a maybe.

I like the game to have a cap on Middle age.

there are wonderful machines that the human imagination created on those times, with only Water or Wind Power.

[Erik]

I'm with tony, rotary energy should be the cap of the game since it's the most interesting to tinker with and is really sturdy and not as compact as electricity. The endgame could be in the vein of steampunk where players automate everything with simple tools and huge machines, powered by steam, governed by gears. And railcraft-esque trains. Who doesn't like trains?

I've once worked out a system for automation and power in VS, it's fairly complex and divides power into two systems: Mechanical power and gear power. Mechanical power is used for work and has two properties: torque and speed. Gear power is a "redstone replacement" and has one property: direction of rotation (clockwise, counterclockwise or not rotating). While there could be a argument for consistency and therefore to combine both systems, I think that would cause things to be too complex and would also have negative effects on performance.

Spoiler

Mechnical Power and Gear computing

0 Gear motors (1 Output): Output gear power
0.1 Mechanical Converter: Outputs constant gear power if powered by mechanical power
0.2 Spring Drive: Uses a spring (item) to provide constant gear power as long as the spring is charged

1 Gear: States: 0 (not rotating), + (rotating clockwise), - (rotating counter-clockwise)    Gears next to each other always invert value (rotation), A single block can house up to 6 gears (Microblock like the saltpeter ore)
2 Pole: States: 0, +, -    Poles next to each other never invert value

FYI: [+] (rotating clockwise) translates to true or 1 and [-] translates to false or 0; Because a third state is already 0 (not rotating, translates to NULL), + and - is used to avoid confusion.

Rules: 
    Illegal gear circuits (two gears spinning in the same direction next to each other; [+&+ or -&-]) always cause all gears in the circuit to stop rotating [0]
    Inner-Microblock-Gear-Connections always 
    Gears naturally act as NOT Gates
    One tick long [+] or [-] rotations are considered pulses; Some devices need pulses others need constant power, some can use both
    The word "Input" always referes to gear power input.

3 Basic Logic Gates (2 Input, 1 Output): Full blocks, 2 Input sides and 1 output side, sides can be configured using a screwdriver
3.1 AND (Rotates clockwise [+] if both inputs are rotating clockwise [+&+] ELSE counter-clockwise [-])
3.2 OR (Rotates clockwise [+] if both inputs aren't rotating counter-clockwise [-&-] ELSE counter-clockwise [-])
3.3 XOR (Rotates clockwise [+] if input doesn't match [+&- or -&+] ELSE counter-clockwise [-])

Rules: 
    If one input of a gate is not rotating [0], the output is also not rotating [0]
    Gates work with pulses and constant power and output pulses exept when both inputs are powered using constant power

--This is were the real fun starts--

4 Geneva Mechanism (1 Input, 1 Output): Outputs pulses, configurable with screwdriver
4.1 Constant power: Outputs a pulse every straight numbered tick for [+] or uneven numbered tick for [-]
4.2 Pulse power: Outputs a pulse every X pulses (X can be configured by screwdriver)

5 Gear Counter (1 Input, 1 Output): Outputs pulse when reaching a value X, X is configurable with a screwdriver
5.1 [+] Pulse: Counter++;
5.2 [-] Pulse: Counter--;
5.3 IF Counter == X THEN Counter = 0; PULSE[+];

6 Gear Repeater (1 Input, 1 Output): Stores pulse value and outputs pulse value when the next pulse arrives
6.1 [X] Pulse: PULSE[Buffer]; Buffer = X;

7 Gear Buffer (2 Input, 1 Output): Stores pulse value and outputs it when second input is pulsed
7.1 First Input (Buffer Input) -> [X] Pulse: IF Buffer == [0] THEN Buffer = X;
7.2 Second Input (Controller Input) -> [-] Pulse: Buffer = [0];
7.3 Second Input (Controller Input) -> [+] Pulse: PULSE[Buffer];

9 Belt Driver (1 InOutput, 1 Belt connection side): Two belt drivers can be connected if they share the position on two axis and are in line of sight to each other. 
    If connected, they will share their State ([+],[-],[0]) and transfer it on the InOutput side.
    Sides can be configured using a screwdriver.
    Retain connection if moved by pistons, when connection conditions are still met.
    Require belt to be connected (item), player has to rightclick one belt driver.
    If connection is lost, two half belts are droped at the belt drives that used to be connected.

10 Piston Systems: A simplified copy of the Pistronics mod.
10.1 Rod: Part to be moved by rod driver. Connects to other rods. 3 Rods can be placed in one block. Rods only connect to other rods if they touch each other.
10.2 Rod Motor (4 Inputs, 2 parallel rod outputs): Copy of the mechanical piston in the Pistronics mod, but letting the rods move in both directions depending on the direction of power.
10.3 Connector: Can be placed on rods, acts like a regular minecraft piston head.
10.4 Sticky Connector: Can be placed on rods, acts like a regular minecraft sticky piston head.
10.5 Supersticky Connector: Can be placed on rods, acts like a regular minecraft sticky piston head and also stays sticky when moving sideways.
10.6 Rod Folder: Copy of the rod folder in the Pistronics mod, but with only one item slot.
Pistronics mod reference: http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1294844-pistronics-2-modular-pistons-rotators-and-statues
10.7 Rope: Like rods, but can only be placed in downwards direction (cheaper).
10.8 Pulley (4 Inputs, 1 downwards rope output): Rod motor and rod folder combined for rope only.
10.9 Anchor: Sticky connector for rope.
10.A Platform/Frame: Essentially MC Slime blocks.

11 Block Breaker (5 Inputs, 1 BlockInteractionSide, hasInventory): Breaks block in front of BlockInteractionSide when [+] pulsed and places it into the inventory.

12 Deployer (5 Inputs, 1 BlockInteractionSide, hasInventory): Uses items and blocks in its inventory as if the player rightclicked them in hand when [+] pulsed.

13 Ejector (5 Inputs, 1 ItemOutput, hasInventory): Basically a MC dropper.

14 Hopper (4 Inputs, 1 ItemInput on top, 1 ItemOutput on botton, hasInventory): Basically a BetterThanWolves hopper.

15 Conveyor System: Conveyor belts and firends. (Campfires can't be automated.)
15.1 Conveyor belt (hasInventory, 2 Inputs on unbelted sides): A line of conveyor belt blocks looking into the same direction is called a belt. 
    A belt needs to be constantly powered by gears, the direction the gears
    spin decides the direction of item movement. Gears that spin in the opposite direction on a belt cause the gears to jam [0] and the belt to stop working.
    The belt doesn't move the actual item entity, it is stored as an itemslot in the belt (BlockEntityMultiBlock would be useful).
    Conveyor belts are full blocks, items and blocks are rendered to move above them, meaning unalloved placed blocks on top of conveyor belts cause the items and blocks to stop
    moving further along the belt. 1 item can be transported via 1 conveyor belt block. Blocks can be transported on block steep slopes upwards and downwords.
    Items automatically get pushed into inventories at the end of belts (at one block above the actual belt blocks).
15.2 Elevator belt (hasInventory, 2 Inputs on unbelted sides): Like a comveyor belt, but moving items upwards and downwards safely.
15.3 Transposer (hasInventory, 4 Inputs, 2 parallel InventoryInteractionSides): When powered, moves items from one inventory to another. Direction of gears influences direction of itemflow.
    Can put items on conveyor belts, but needs to be placed facing the empty block above the conveyor to do so.
15.4 Filter (hasInventory, 4 Inputs, 2 parallel InventoryInteractionSides): Like transposer, but has a configurable filter that decides which items are pulled into the inventory.

16 Detector blocks (1 ObserverSide, 1 Input, 1 Output): Blocks that change the direction of a gear when detecting something the block in front of them (ObserverSide).
16.1 Conveyor detector: Needs to be placed facing the empty block above a conveyor. Detects items on the conveyor.
16.2 Filtered conveyor detector: Like conveyor detector, but has a configurable item filter.
16.3 Entity detector: Detects LivingEntities.
16.4 Particle detector: Detects particles (therefore also rain).
16.5 Light detector: Detects light.
16.6 Blockupdate detector: Detects blockupdates.
16.7 Block detector: Detects blocks.
16.8 Filtered block detector: Like block detector, but has a configuragle block filter.
16.9 Item detector: Detects ItemEntities.
16.A Filtered item detector: Like item detector, but has a configuragle item filter.
16.B Player detector: Detects players.
16.C Simple detector: Item, Rain, Entity, Block, Player detector combined.

17 Mechanical power system (not gear power): Tyrons original power system as present in VintageCraft.
17.1 Shafts and Shaft junctions: Transfer energy (torque and speed).
17.2 Gearboxes: Convert torque and speed.
17.3 Windmills: Unconsistant power output.
17.4 Waterweels: More consistant power output.
17.5 Manual generator: Player-powered, consitant power output. Can also be powered using animals.
17.6 Steam engine: Steam pressure to mechanical power.
17.7 Millstone: Mills things.
17.8 Saw: Saws things.
17.8 Mechanical hammer: Automated smithing.
17.9 Rotational blower: Essentially bellows, but using mechanical power.
17.A Stone pounder: Crushing bigger things.
17.B Spring charger: Charges springs.
17.C Fan: Pushes entities, harvests plants.
17.D Sewing machine: Wool and stuff.
17.E Balistica: Shooting really big arrows.
17.D Catapult: Shooting really big stones.

18 Bellows (2 Inputs, 1 AirOutput): Make things with fire hotter, like forges, campfires etc. [+] Power presses air out, [-] Power sucks air in (fast). 
    Sucks in air on its own (but taking more time than when powered). Player can press air out manually by rightclicking it.
    Needs careful automation to be effective

19 Turntable (1 Input, 1 BlockInteractionSide): Used for pottery.

20 Liquid overhaul: Handling liquids the minecraft way isn't very performance cheap nor interesting.
20.1 Liquid Source Blocks: Only placed during worldgen. Behaves like MC Classic water, but places liquid flow blocks instead.
20.2 Liquid Flow Blocks: Behaves like MC Classic water if connected to a liquid source block, but places liquid flow blocks instead.
    When not connected to a liquid source, it'll retain its volume (1/8 - 8/8 blocks). Flow causes it to equilize it's volume with adjacent liquid flow or
    air blocks. If columes can't be distributed (example: 1/8 next to 2/8 liquid flow blocks surrounded by stone), the overflow will be deleted instead of
    causing constant liquid height updates.
20.3 List of liquids: Saltwater, freshwater, lava
20.4 Properties of liquids: Luminosity (brightness of glow effect), viscosity (rate of liquid height updates)

21 Screwpump (1 Input, 2 BlockInteractionSides): Basically a BTW Screwpump powered by gear power.
21.1 Pipe (hasFluidInventory): Fluid pipe, that's it. Fluid insertion using screwpump. Outputs fluids into blocks with FluidInventory.
21.2 Fluid Grate (1 BlockInteractionSide, hasFluidInventory): Outputs fluids from pipes back into world.

22 Fire overhaul: Fire can burn at different temperatures, changing its brightness and color.
22.1 Burner (1 BlockInteractionSide at top, hasInventory): 1 One inventory slot for fuel. If lighted by torch it will slowely burn threw the fuel and produce
    the right temperature fire according to the fuel type. Bellows or rotational burners aimed at the grill block increase the temperature of the fire,
    but also the fuel consumtion rate.
22.2 Mechanical Burner (1 Input, 1 BlockInteractionSide at top, hasInventory): Like Grill, but can be lighted by [+] and extinglished by [-] pulses or constant power.
22.3 Grill (hasInventory): Basically a faster campfire for food only powered by fire/campfire beneath it.
22.4 Ceramic Grill: Unfired pottery can be placed on top and will be fired + some extra recipes. Needs fire beneath. Inspired by BTW kiln.
22.5 Pot (hasInventory, hasFluidInventory): Fluid-Item combined crafting. Some recipes need fire underneath.

23 Steam power system: Steam isn't a fluid, it behaves as a pressure (see Flaxbeard's Steam Power mod, this is basically a copy in many ways).
23.1 Steam Pipes (hasSteamInventory): Transfer steam/pressure.
23.2 Steam Tank (hasSteamInventory): Add a lot of volume to steam system / basically steam storage.
23.3 Steam Boiler (hasFluidInventory, hasSteamInventory): Needs fire underneath. Water is converted into steam.
23.4 Steam Gauge: Can be attached to a steam system and shows the pressure.
23.5 Mechanical Steam Gauge (1 Output): Like steam gauge but outputs [+] gear power when steam pressure reaches critical levels.
23.6 Steam Whistle: Makes a loud noise, when steam pressure reaches critical levels.
23.7 Valve Pipe (hasSteamInventory): Like pipe, but can be closed, which hinderes pressure flow. Can be toggled manually by rightclicking or by [+] to open and [-] to close.
23.8 Rupture Disc: When steam pressure reaches very critical levels, it'll pop open and release steam. 
    Needs to be replaced manually to be used again, otherwise a permanent steam leak.

 

[redram]

With regards to electric power, yes, it's certainly optional, and depends on the devs' vision.   I probably shouldn't have classified it as a power source: it's not.  You'd still have to generate electric power with on of the previous generation methods.  The advantage of electric power would probably be that you wouldn't have all the complicated connections - the lineshafts and 'gear power' Erik mentioned.  Electric power would basically just involve wires, which perhaps would be mostly invisible.  Thereby greatly simplifying the laying out of mechanics.  It'd also of course allow for arc furnaces and defensive tesla coils, etc.  As long as it's done in a steampunk fashion I think it'd be pretty awesome, but it's definitely a totally optional down the road thing.

Nice detailed summary there @Erik.  I never did really play vanilla MC, just TFC, so I never got into redstone.  I'm also not a programmer so the logic functions are not second nature to me.  I like the basic summary of blocks. 

I think it makes sense to have a 'logic system' that does not subtract power from the overall power system.  Only machines that actually do transformative work should need to do that.  I'm not totally clear why gear rotation directions are a necessary thing to track.  Doesn't minecraft get by with basically on or off for it's redstone (though I gather there is also signal magnitude, which you did not seem to address)?  I get that you're thinking the player can place individual gears, 1 per side of a block space, but is that perhaps a bit overly complicated?  In the context of this power-less logic system, Why not just have 'mechanisms' that are always a six sided block, with each side having the potential to output power?  Then you don't have to mess around with intermeshing and rotational directions.  the texture can be animated to portray rudimentary gear rotation or other movement, but no actual modeling of movement need take place.  These mechanisms would only be needed to divide the 'signal', the long range transmission being done by rods/belts/chains?  The player configures which side accepts input, and which ones output signal, via a wrench or other tool.  The texture on the given side changes accordingly: pto socket for signal input, different looking socket for signal output, and just blank metal plate for nothing?

Your list covers a good amount of stuff Erik, but I'm trying to think of things that may be more specific to a game such as VS that has more involved mechanics than vanilla MC.

With regards to automating smithing, I think there is a question of whether the system will still require ingots to be heated for the machines to smith?  In such a case we'd probably need a sensor that detects how hot the item(s) inside a heater are. Unless we want the player to simply have to time things right so that the piece is heated.  Maybe we need a timer block?  I know you can make such a thing with the right logic circuit but I think that's unnecessarily complex.   A timer block could probably be used for automated baking, brewing, and other such things.

A counter block might also be fun, so a player could for instance track the lifetime production of a line.

Tons of other stuff I'm sure, but that's off the top of my head for now.

[Erik]

40 minutes ago, redram said:

I'm not totally clear why gear rotation directions are a necessary thing to track.  Doesn't minecraft get by with basically on or off for it's redstone (though I gather there is also signal magnitude, which you did not seem to address)?

Well, most simple mechanisms could be constructed using only the on/off mechanics, but gear rotation adds a little twist and potential for optimization, extending the systems like signal strengths do for redstone.

46 minutes ago, redram said:

I get that you're thinking the player can place individual gears, 1 per side of a block space, but is that perhaps a bit overly complicated?  In the context of this power-less logic system, Why not just have 'mechanisms' that are always a six sided block, with each side having the potential to output power?

Such "clockwork microprocessors" would be awesome as an endgame option, but would also lessen the fun of building a complex design. Redstone always was a puzzle and that was because it had logical and spacial boundaries and I feel VS should try to replicate this.

54 minutes ago, redram said:

With regards to automating smithing, I think there is a question of whether the system will still require ingots to be heated for the machines to smith?  In such a case we'd probably need a sensor that detects how hot the item(s) inside a heater are. Unless we want the player to simply have to time things right so that the piece is heated.  Maybe we need a timer block?  I know you can make such a thing with the right logic circuit but I think that's unnecessarily complex.   A timer block could probably be used for automated baking, brewing, and other such things.

A counter block might also be fun, so a player could for instance track the lifetime production of a line.

A heat detector? Maybe, if it would have uses other than smithing. A timer? I like complex logic circuits, providing a simple timer block would take away some fun and challenge. Automation shouldn't be about crafting magic boxes that do all the work for you, it should be about clever engineering.

[redram]

53 minutes ago, Erik said:

Such "clockwork microprocessors" would be awesome as an endgame option, but would also lessen the fun of building a complex design. Redstone always was a puzzle and that was because it had logical and spacial boundaries and I feel VS should try to replicate this.

I don't think making the player place six gears in a single blocks space is really a spatial puzzle or a complex design.  I'm thinking mainly in terms of reducing the graphical complication of things.  But I know tyron just did a video with 1000 cog blocks, so maybe logic systems involving thousands of individually rotating gears isn't a problem? 

1 hour ago, Erik said:

A heat detector? Maybe, if it would have uses other than smithing.

Why would it need uses other than smithing?  If automated smithing still requires heated ingots, then the player needs a way to ensure they're heated to the right temperature.  Could have uses in alchemy or cooking, depending on how those systems work.

1 hour ago, Erik said:

A timer? I like complex logic circuits, providing a simple timer block would take away some fun and challenge. Automation shouldn't be about crafting magic boxes that do all the work for you, it should be about clever engineering.

One man's clever engineering is another man's waste of space

How about chutes as a primitive automation form?  They don't require any power at all.  The only requirement is that they move downward.  Either straight down or at a 45 degree downward angle.  You combine these with a divider, which is basically a hopper than takes incoming items that arrive in the top, and distributes them evenly amongst a number of outputs (maybe just two, maybe up to 5).  Stacks get split, single items are distributed in turn.   This for instance could be used to divide a load of stuff to be ground amongst many grindstones, to speed the operation as a whole. 

I think that how the heating mechanic gets changed will have significant implications for logic.  I was advocating for heating to become a situation where the entire lot gets finished at once.   But in a situation where you're trying to sequentially grind up things and add them to be baked, there's the potential to waste fuel if more and more items keep getting added.  We'll either need for the process block itself to be able to signal when it's full (or even partially full) and hence when the heating should start, or we'll need a sensor block to sense accomplish the same.   On the other hand, if items continue to output one at a time, but we simply fix the complete restart for each item, it may be that the player can regulate the speed of item input sufficiently to ensure stuff heats up fast enough to cook.  On the balance I think I'd still prefer the former.

[heptagonrus]

Talking about primitive electricity visuals, don't forget the Leyden jar. May be a portable rechargeable power source for journeys.

https://en.wikipedia.org/wiki/Leyden_jar

[Tyron]

Love the line shaft thing redram, that would work very well with the planned mechanial power sytem.
An Electric age is indeed a bit questionable for our vision of the game. If we add it, then perhaps as a seperate DLC and/or only super low tech electricity
 

On 4/1/2018 at 10:31 PM, Elwood said:

VS needs to first create a problem for us to solve using mechanics and mass production.  Maybe the trade system might fit the bill but that could be too much like "questing". Maybe grain and other products need to become a "resource" that is continually depleted to maintain some bonus you have gained.  eg. a full granary gives health bonus to the owner if it stays full.  But then to keep that progression going or maintaining it we likely need to have bigger threats near the more advanced villages/players like raiders so need to build walls and defenses or you reach. perhaps the need to keep an armory full of swords to keep attacks away.  drives the need to build a bigger forge.

That's pretty much why I've been delaying mechanical power for so long already. It should integrate well into survival play without causing too much obsoletion. 

On 4/1/2018 at 10:31 PM, Elwood said:

If VS can ever give a real sense of progression and a purpose to keep maintaining it will be the best survival game ever.  

Attempting to redefine the voxel survival genre - that's what we're all here for!  

[Erik]

34 minutes ago, redram said:

Why would it need uses other than smithing?  If automated smithing still requires heated ingots, then the player needs a way to ensure they're heated to the right temperature.

To minimize the components in the logic system. If smithing automation would be the only use for heat detectors, then maybe change smithing instead of adding a unique component for every possible application of the logic system. But a heat detector would probably have many possible applications, like you mentioned.

39 minutes ago, redram said:

I don't think making the player place six gears in a single blocks space is really a spatial puzzle or a complex design.  I'm thinking mainly in terms of reducing the graphical complication of things.

Six gears in one block wouldn't make very much sense, four is the logical maximum if accounting for direction of rotation. This simple logical limitation creates a simple spacial puzzle that needs to be accounted for in every design. This also means that machines need a lot of space causing a space optimization puzzle. And sturdy machines look so much better and add a sense of accomplishment, very reminiscent of building a huge factory in Factorio.

This is also the reason why I'm strictly against any electrical system, as it would only replace rotary power and gear computing with simpler and more boring looking systems, not adding new possibilities, but simplifying old possibilities, causing a loss of challenge.

53 minutes ago, redram said:

One man's clever engineering is another man's waste of space

Engineering fundamentally is problem solving, that's what makes it fun. If there are no problems to solve, like spacial design, it's just turns into a dull, unrewarding task without challenge. A game without challenge is hardly a game.

 

 

[redram]

1 hour ago, Erik said:

Six gears in one block wouldn't make very much sense, four is the logical maximum if accounting for direction of rotation.

The spoilered list you gave above specifically lists 6 gears as the per-block max, in item 1.  But ya, I guess the rotations wouldn't mesh. 

1 hour ago, Erik said:

This is also the reason why I'm strictly against any electrical system, as it would only replace rotary power and gear computing with simpler and more boring looking systems, not adding new possibilities, but simplifying old possibilities, causing a loss of challenge.

I mean, I guess if you consider giant arcs of electricity sizzling and popping, and glowing glass jar battery banks 'boring'.  I'll reiterate, electricity would not replace combustion power.  You don't just pick electricity off the ground, it has to be generated.  Electricity would simply be a simpler way to extend and store combustion power.  But indeed, it's probably best as a later dlc/addon.

2 hours ago, Erik said:

Engineering fundamentally is problem solving, that's what makes it fun. If there are no problems to solve, like spacial design, it's just turns into a dull, unrewarding task without challenge. A game without challenge is hardly a game.

So ok, you find clockwork timers to be "magic boxes".  Despite that the technology has existed - depending on how you define it - possibly since the antikythera mechanism, and certainly since the 14th century - well within VS's timeline.  You seem to think that such devices should be ballooned out to their smallest constituent parts.  I'm going to assume you did not make the spoilered list you gave them.  Because nearly the entirety of section 16 is "magic boxes".   Would you agree then that all those devices should be exploded into smaller parts that would logically accomplish the overall function, or not be available at all?  15.4 filter also sounds pretty magical to me.  Section 5 sounds like a box of gears doing the same thing you could do with a large logic array - too magical then?   Sections 6 and 7 don't really explain how they work - it's not obvious to the uninitiated like me.  Unlike section, which 4 gives me a mechanism name that's easy to google.  That geneva mechanism is a really neat thing btw, I love it.  Totally endorse that as an exploded component of a vanilla MC repeater, if I understand VMC repeaters correctly...

[Elwood]

4 hours ago, redram said:

How about chutes as a primitive automation form?  They don't require any power at all.  The only requirement is that they move downward.  Either straight down or at a 45 degree downward angle.

I like the idea of chutes for automation. At least as a start to semi-automating some processes like grinding grain or rolling logs into a sawmill.

For more semi-automation. In primitive times a rope and basket was used for raising loads. (mining or digging wells or raising hay to a loft).  A person or mule would pull the rope to raise the load.  Combined with chutes could provide early automation for loading resources into chutes. 

Problem with early automation is it was never fully automated and almost always had humans helping.  A human pulled the rope or walked with the mule. Maybe human power next to machines (hired NPCs) is a form of power.  Need to be fed or paid or they stop working. 

[redram]

3 hours ago, Elwood said:

For more semi-automation. In primitive times a rope and basket was used for raising loads.

The thing about that is it requires reworking the very nature of many materials so that they're heavy, and the player can't carry many of them, nor carry them upward easily.  This idea was discussed some in another thread.   If that does indeed come to be, then yes, certainly lifting 'machines' will be needed even in the early game.

The idea of hiring npcs would be fun I think.  They could have specializations and such, so you could hire general labor, or a fisherman, or a hunter, etc.  They become a resource in their own right, where you're excited to find one with good skills.  This is very much a thing in Dwarf Fortress.  The downside might be if their AI starts to really hog game resources.  NPCs are kind of a whole 'nother topic though. 

I think there is a big question to be answered, about just how far VS wants to take automation.   There's the obvious precedent of minecraft, but minecraft is a much more simplified game that, to the best of my knowledge, does not have extended wait periods for products, nor conditions placed on raw materials (like how hot they are).  How would we automate leather making, for example?   Will there actually be hoppers full of hides, going into vats of liquid, and pulled out again by some kind of machine?  Was anything in Erik's list above capable of that? What about bees and skeps?  And later presumably box hives?  Is that stuff going to be automated so the player has no risk whatsoever from bees?   At some point you're approaching robotics and really starting to risk breaking the theme and/or believability, I think.   

How about charcoal making.  Does that get automated?  The deployer in Erik's list only mentions simulating right clicks.  Well that picks up firewood.  You have to shift-click to place it.  Does it also have that function?  Then the machine sits idle for a day or whatever, and starts up again?  Block breaker would then have to pick up the charcoal.  So automated charcoal kilns would basically be a wall of deployers on one side and a wall of breakers on the other?  Might work.  Is it what's wanted?  Is there anything that won't be automatable?  Some things, like grinding, really really lend themselves well to automation within a given tech window.  Others just don't.  Is there a line to be drawn?

Then, there's the issue of hokey mechanics.  In minecraft they were charming, I guess, and allowed the many ways of accomplishing tasks, in ways that probably weren't planned by the creators.  Flood your field to harvest your crops?  Sure why not?  But is that the kind of thing we want in VS?   Item 17.C in Erik's list is a fan which " Pushes entities, harvests plants".  Harvests plants?  Are we so desperate to have automated harvesting that we're going to use such an unbelievable mechanic?  Or if we can't think up a logical way to accomplish a task, will we simply allow that to be a thing which can't be automated? 

[tony Liberatto]

41 minutes ago, redram said:

Then, there's the issue of hokey mechanics.  In minecraft they were charming, I guess, and allowed the many ways of accomplishing tasks, in ways that probably weren't planned by the creators.  Flood your field to harvest your crops?  Sure why not?  But is that the kind of thing we want in VS?   Item 17.C in Erik's list is a fan which " Pushes entities, harvests plants".  Harvests plants?  Are we so desperate to have automated harvesting that we're going to use such an unbelievable mechanic?  Or if we can't think up a logical way to accomplish a task, will we simply allow that to be a thing which can't be automated? 

2

Completely agree with Redram. what I have seen is automation for the sake of automation. I could never understand why anyone would need an automated chicken and egg farm. Who would eat that much?

Also, there is a distinction between Mechanical Power and automation.

With mechanical power, the player is able to do things that he would not be able to do otherwise or do it faster and more efficiently.  

Automation is a process that does not even requires the player to be present. It will be just filling up chests and chest with resources that the player in most cases will not even use. We definitely do not need or want this in VS.

To be honest I never even liked the concept of redstone. It was like magic, and I hope VS will not go in that direction. 

Of course to effectively introduce mechanical power we will also have to add problems that the use of mechanical power will solve:

1. Grind Grains.
2. Crush stones.
3. lift ores
4. travel faster.
5. Blow your forge with a mechanical bellow.
6. Irrigate your crops. 

The list is big and much can be introduced that will make the game richer in details.

But I do not want Electricity, Redstone(I.e. Magic power) Or machines that work by themselves. No pipes that distribute the production into magic chests.

 

[redram]

I don't think anyone is proposing redstone.  Erik's proposal makes a point of it being entirely geared.  To me, some processes lend themselves to the idea of automation, some don't.  Metalworking perhaps most of all.  I think straight copying minecraft's array of logic tools will lead to thematically inconsistent devices.  But there can be a meeting in the middle, it's just how far do we want to allow the player to take it?

For instance automated clayforming.  I think everyone agrees it would be nice to have a machine that will form some of the basic clay stuff - you put in some clay, turn the flywheel, and eventually out comes some bowls or whatever.  Only works for 'simple' shapes (not the anvil mold).  But how far to go from there?  How about a tank, which holds water, and the player tosses in a quantity of clay, and after X hours that clay turns to slip.  This slip can be piped into the former.  (The valve can be manual, or automated) The ejection of the formed pieces can be automated.  Can they be ejected into a chest?  Or a hopper that diverts them into a chute or conveyor belt (chute wouldn't strictly make sense for green clay, but abstractions...).  Can the chute/conveyor then deposit them in a furnace, where they are baked for Y time?  And after Y time a timer prompts the furnace to eject them?  Possibly into another series of chutes/conveyors?  Can they be automatically glazed, and fired again?  Then again into chutes/conveyors, and they go through a bunch of sorters and if they're bowls they end up in a chest in the apiary.  If they're ingot molds they end up in a chest in the smithy.  If they're tool molds they end up in a different smithy chest.  If they're planters they end up in the greenhouse.  How far along that continuum do we go?  The glazing and firing steps may require additional devices.

Crop harvesting - blower makes no sense.  However, how about you can put an automated harvester machine of some kind (scythes?) attached to a minecart, driven by an engine?  That's not entirely illogical.  Followed by another modified minecart that sweeps up the cut crops and seeds.  Which are dumped and sorted into seeds and straw/flax/whatever?  So if you want to automate crops you have to plant them within 2 to 3 square of a railroad track.  It's a use for minecarts.   Just because one method makes no sense does not mean something cannot be made  up that does. 

A magical sorter makes no sense; optical recognition technology has existed for only a few decades, I think.  However, if every item is given a weight and size, you can sort by weight and size, based on weight triggered trap doors, and size-based diverters.  It's not a perfect sorting technology, but you could use it to separate saplings from sticks from logs, and seeds from flax or vegetables.  Ores from stones from raw stone blocks.  Bowls from ingot molds from planters.

Daylight sensor?  Ridiculous.  However, a specially crafted highly focusing lens focuses daylight,  heats a small boiler, which creates steam, which triggers an actuator piston.  Or optionally heats a tank of mercury, triggering the actuator.

Many of the minecraft 'magic boxes' can be translated into a logical device.  How far are we willing to go?

[Erik]

13 hours ago, redram said:

So ok, you find clockwork timers to be "magic boxes".  Despite that the technology has existed - depending on how you define it - possibly since the antikythera mechanism, and certainly since the 14th century - well within VS's timeline.  You seem to think that such devices should be ballooned out to their smallest constituent parts.  I'm going to assume you did not make the spoilered list you gave them.  Because nearly the entirety of section 16 is "magic boxes".   Would you agree then that all those devices should be exploded into smaller parts that would logically accomplish the overall function, or not be available at all?  15.4 filter also sounds pretty magical to me.  Section 5 sounds like a box of gears doing the same thing you could do with a large logic array - too magical then?   Sections 6 and 7 don't really explain how they work - it's not obvious to the uninitiated like me.  Unlike section, which 4 gives me a mechanism name that's easy to google.  That geneva mechanism is a really neat thing btw, I love it.  Totally endorse that as an exploded component of a vanilla MC repeater, if I understand VMC repeaters correctly...

There doesn't need to be a timer, because there is already a counter. Who can count can also time. It's not about realism, it's about creating a Turing complete system. Section 16 only covers detectors. Building a detector with the parts already present is impossible, if you don't use exploits and glitches (block-update detectors in pre-1.11 Minecraft...). Detectors are already their own minimum, they change the signal if they detect. The filter is a simple solution to sorting, could be changed, please present a better option for sorting with conveyor belts. Yes, a large logical array or exploitation of the piston system could replace the counter, maybe it should? But maybe, based on how frequently counters are used, it shouldn't? The gear repeater is basically a redstone repeater, the buffer is used to store values use them later. They are essential to keeping the system Turing complete, but they could also be replaced by exploiting the piston system. I chose to include them because I want the gear system to be independent of other systems. They could also be used to create a counter, but that would be very complicated.

My vision was not to be entirely realistic, I tried to have a system that was Turing complete, aka you could build a working computer with it. A logical system would be useless, if it couldn't interact with the world, so it needs inputs and outputs. The inputs are detectors (also buttons and levers, which I forgot to put on the list). Outputs do the heavy lifting, they are the essential part for automation. My idea was to emulate everything the player can do and more, while staying minimalist and not abstracting to much. 

10 hours ago, redram said:

I think there is a big question to be answered, about just how far VS wants to take automation.   There's the obvious precedent of minecraft, but minecraft is a much more simplified game that, to the best of my knowledge, does not have extended wait periods for products, nor conditions placed on raw materials (like how hot they are).  How would we automate leather making, for example?   Will there actually be hoppers full of hides, going into vats of liquid, and pulled out again by some kind of machine?  Was anything in Erik's list above capable of that? What about bees and skeps?  And later presumably box hives?  Is that stuff going to be automated so the player has no risk whatsoever from bees?   At some point you're approaching robotics and really starting to risk breaking the theme and/or believability, I think.   

Simple machines that do simple tasks and combining to big complicated machines seems actually very believable to me, because the player can see how the machine operates. Is it thematic for a game about realistic survival? No. Is it thematic for a game about building? Absolutely. 

10 hours ago, redram said:

How about charcoal making.  Does that get automated?  The deployer in Erik's list only mentions simulating right clicks.  Well that picks up firewood.  You have to shift-click to place it.  Does it also have that function?  Then the machine sits idle for a day or whatever, and starts up again?  Block breaker would then have to pick up the charcoal.  So automated charcoal kilns would basically be a wall of deployers on one side and a wall of breakers on the other?  Might work.  Is it what's wanted?  Is there anything that won't be automatable?  Some things, like grinding, really really lend themselves well to automation within a given tech window.  Others just don't.  Is there a line to be drawn?

Then, there's the issue of hokey mechanics.  In minecraft they were charming, I guess, and allowed the many ways of accomplishing tasks, in ways that probably weren't planned by the creators.  Flood your field to harvest your crops?  Sure why not?  But is that the kind of thing we want in VS?   Item 17.C in Erik's list is a fan which " Pushes entities, harvests plants".  Harvests plants?  Are we so desperate to have automated harvesting that we're going to use such an unbelievable mechanic?  Or if we can't think up a logical way to accomplish a task, will we simply allow that to be a thing which can't be automated? 

In my opinion, everything the player can accomplish, a machine should also be able to accomplish. But you are right, not every mechanic lends itself towards automation. An simple way to avoid this problem and add even more excitement towards automation is to implement secondary, "higher tech" ways to do things, that are better tailored for automation. Like industrial metalworking or a turntable for pottery.

About fans: Unplanned automation possibilities seem like a flaw in Minecraft, that I would like VS to avoid. But your right about fans harvesting plants, it may be a bit unnecessary (got the idea from RotaryCraft). They should only push items, plants can also be harvested by block breakers. 

7 hours ago, redram said:

Crop harvesting - blower makes no sense.  However, how about you can put an automated harvester machine of some kind (scythes?) attached to a minecart, driven by an engine?  That's not entirely illogical.  Followed by another modified minecart that sweeps up the cut crops and seeds.  Which are dumped and sorted into seeds and straw/flax/whatever?  So if you want to automate crops you have to plant them within 2 to 3 square of a railroad track.  It's a use for minecarts.   Just because one method makes no sense does not mean something cannot be made  up that does. 

A magical sorter makes no sense; optical recognition technology has existed for only a few decades, I think.  However, if every item is given a weight and size, you can sort by weight and size, based on weight triggered trap doors, and size-based diverters.  It's not a perfect sorting technology, but you could use it to separate saplings from sticks from logs, and seeds from flax or vegetables.  Ores from stones from raw stone blocks.  Bowls from ingot molds from planters.

Daylight sensor?  Ridiculous.  However, a specially crafted highly focusing lens focuses daylight,  heats a small boiler, which creates steam, which triggers an actuator piston.  Or optionally heats a tank of mercury, triggering the actuator.

Many of the minecraft 'magic boxes' can be translated into a logical device.  How far are we willing to go?

A minecart with a scythe, apart from how ridiculous it would look, is a "magic box", at least with my definition. It accomplishes multiple tasks at the same time, destroying multiple blocks, moving and probably checking if the plant is ready to be harvested. My solution would be a piston powered array of block breakers and placers that moves over the crops to break them, replanting them on the next move, controlled by a timer.

Weight and size-based divertes make no sense, because every and block item would need a size and weight stat assigned to them. The only other feasible way of sorting items (without exploits like in Minecraft) would be a Better Than Wolves-like hopper.

Daylight sensor: Gameplay > Realism.

[redram]

 

1 hour ago, Erik said:

There doesn't need to be a timer, because there is already a counter.....Yes, a large logical array or exploitation of the piston system could replace the counter, maybe it should? But maybe, based on how frequently counters are used, it shouldn't?

I see.  So counters are used so often that they should be condensed into a magic box, but timers would not be used often enough?  Despite that tons of processes in VS require extended amounts of time?

19 hours ago, Erik said:

Engineering fundamentally is problem solving, that's what makes it fun. If there are no problems to solve, like spacial design, it's just turns into a dull, unrewarding task without challenge. A game without challenge is hardly a game.

 

1 hour ago, Erik said:

Daylight sensor: Gameplay > Realism.

I've given a believable option to allow the player to construct a daylight sensor that is not 'magical'.  I've given you a sorter that is not 'magical'.  But apparently these don't fit into the category of 'challenging problem solving' by your definition?  Saving players the hassle of having to construct a timer every time they want to time a process does not fall under 'gameplay', but 1-blocking daylight sensors and sorters does?

1 hour ago, Erik said:

A minecart with a scythe, apart from how ridiculous it would look, is a "magic box", at least with my definition. It accomplishes multiple tasks at the same time, destroying multiple blocks, moving and probably checking if the plant is ready to be harvested. My solution would be a piston powered array of block breakers and placers that moves over the crops to break them, replanting them on the next move, controlled by a timer.

I think it's interesting that a scythe cart would look ridiculous to you, but a piston array of block breaks and placers would not.   One of these things is much more believable within the stated scope of this game.  One is not.  I would argue the more believable one is the one that Leonardo DaVinci conceptualized around the 15th century:

I was certainly not imagining it as a one-box solution, though as an entity it would move as one, certainly.  And obviously it's not going to be a sprawling logic array.  I was thinking the harvester cart would be it's own thing, preceded or followed by the engine cart, in turn linked to the fuel supply cart.  The harvest cart would certainly need to require a lot of parts to be used in it's building, to make the cost of constructing it appropriate.    Why would you imagine the harvester cart to have it's own crop maturity sensors while your piston array works on a timer?

1 hour ago, Erik said:

Weight and size-based divertes make no sense, because every and block item would need a size and weight stat assigned to them.

Yes, that's exactly what I said.  Weight and size would need to be added to all items.  Which would not be a bad thing, as it would support inventory mechanics.  Now Erik, if you're arguing that any logic system can only be designed with items being exactly as they are now - no new mechanics or data - or that the number of devices is minecraft is the best and most appropriate number of devices for...reasons?  - we'll have to agree to disagree there.  My sorter suggestion makes far more sense from a believability standpoint vs a magic optical sorting hopper system.  The sorting trapdoor (if trapdoor - being a non-moving surface - offends your sensibilities, call it a dipping section of conveyor) has a configurable weight that it will allow to pass over.  Anything below that weight passes over, anything above falls through (or the conveyor dips, causing it to fall to the side).  You place a series of trapdoors/dippers from heavier to lighter limits, and it sequentially sorts out heavy items first, lightest items last.    Diverters are nothing more than a plank with an opening at the bottom of a given graphical height.  You place the larger openings first, the smallest last.  Your larger items are diverted first, your smallest last.  In this way you can sort your largest heaviest items, and your smallest lightest items, and everything in between.  It will take massively more room than magical optical sorting hoppers.  But 'engineering challenge', right?

I get that there is a compulsion, for those who are versed in engineering logic, to want to have that in the game.  It's natural for people to have a great affinity for things they are familiar with, and love to see it represented in detail. I'm asking, is that necessary?  Appropriate?  I just want to clarify what our standard is here.  If the standard is to be 'turing complete' or copy minecraft's redstone system, fine.  I'd just like to have it made clear.  And yes, I know Tyron has said he'd like it turing complete.   So that's kind of why I'm asking 'are you sure?' and 'if so how?' or 'maybe more appropriate as an addon or separate game mode?'  If the standard is to make interesting engineering challenges, and I present ways to explode section 16 into greater engineering challenges, and this is rejected, then this is inconsistent to me.   If the standard is gameplay and I present an option to ease the gameplay for people who are not electrical or computer engineers versed in logic array terminology, and that is rejected, then this is inconsistent to me.  I'm looking for some guidelines and consistency. 

If the game is to have a 'automation mode' (and I'm pretty sure I remember Tyron mentioning this) then hey, awesome, anything goes there obviously.  But if that's the case maybe it's also worth discussing what automation makes it's way into the 'normal' game, and what doesn't?

 

 

 

 

[Erik]

1 hour ago, redram said:

So counters are used so often that they should be condensed into a magic box, but timers would not be used often enough?  Despite that tons of processes in VS require extended amounts of time?

The counter is practically a timer. The only difference is that it has the "extra feature" that it requires a clock (pulses to count), which can simply be made with a geneva mechanism.

1 hour ago, redram said:

I've given a believable option to allow the player to construct a daylight sensor that is not 'magical'.  I've given you a sorter that is not 'magical'.  But apparently these don't fit into the category of 'challenging problem solving' by your definition?  Saving players the hassle of having to construct a timer every time they want to time a process does not fall under 'gameplay', but 1-blocking daylight sensors and sorters does?

It's not problem solving if you are copying the solution. Each daylight sensor would need to be constructed in the same way: Lens, mini-boiler, mini-turbine. Why not turn this into one block rather than three separate blocks just used for this function? How is this different from the timer? The components for the timer need to exist, if there is a timer block or not. But a lens, a mini-boiler and mini-turbine too, wouldn't need to exist on their own (A normal boiler and turbine would be to un-believable for this task and would make a burning box useless), thus making them only useful as a daylight sensor.

1 hour ago, redram said:

I think it's interesting that a scythe cart would look ridiculous to you, but a piston array of block breaks and placers would not.   One of these things is much more believable within the stated scope of this game.  One is not.  I would argue the more believable one is the one that Leonardo DaVinci conceptualized around the 15th century

First of, the device in the picture would have been used for killing people, it's a war machine. Both ways are ridiculous in their own right, I just prefer the piston powered machine.

1 hour ago, redram said:

The harvest cart would certainly need to require a lot of parts to be used in it's building, to make the cost of constructing it appropriate.

"Draconic evolution is balanced because it takes effort" - Things shouldn't be balanced by time investment (i.e. materials), but rather by challenge, cognitive or other.

2 hours ago, redram said:

Yes, that's exactly what I said.  Weight and size would need to be added to all items.  Which would not be a bad thing, as it would support inventory mechanics.  Now Erik, if you're arguing that any logic system can only be designed with items being exactly as they are now - no new mechanics or data - or that the number of devices is minecraft is the best and most appropriate number of devices for...reasons?  - we'll have to agree to disagree there.  My sorter suggestion makes far more sense from a believability standpoint vs a magic optical sorting hopper system.  The sorting trapdoor (if trapdoor - being a non-moving surface - offends your sensibilities, call it a dipping section of conveyor) has a configurable weight that it will allow to pass over.  Anything below that weight passes over, anything above falls through (or the conveyor dips, causing it to fall to the side).  You place a series of trapdoors/dippers from heavier to lighter limits, and it sequentially sorts out heavy items first, lightest items last.    Diverters are nothing more than a plank with an opening at the bottom of a given graphical height.  You place the larger openings first, the smallest last.  Your larger items are diverted first, your smallest last.  In this way you can sort your largest heaviest items, and your smallest lightest items, and everything in between.  It will take massively more room than magical optical sorting hoppers.  But 'engineering challenge', right?

Skipped that one line . Would your idea work? Yes, maybe it would be a better system, but it relies on mechanics not present in the game. Adding weight and size for this mechanic alone seems like a waste, the system needs to be implemented throughout the whole game, possibly revamping the whole inventory system or otherwise it would seem inconsistent and therefore lower the believably. If you design using mechanics that are not present, you need to design those too, I'm not against redesigning something and diverting from Minecraft.

2 hours ago, redram said:

I get that there is a compulsion, for those who are versed in engineering logic, to want to have that in the game.  It's natural for people to have a great affinity for things they are familiar with, and love to see it represented in detail. I'm asking, is that necessary?  Appropriate?  I just want to clarify what our standard is here.  If the standard is to be 'turing complete' or copy minecraft's redstone system, fine.  I'd just like to have it made clear.  And yes, I know Tyron has said he'd like it turing complete.   So that's kind of why I'm asking 'are you sure?' and 'if so how?' or 'maybe more appropriate as an addon or separate game mode?'  If the standard is to make interesting engineering challenges, and I present ways to explode section 16 into greater engineering challenges, and this is rejected, then this is inconsistent to me.   If the standard is gameplay and I present an option to ease the gameplay for people who are not electrical or computer engineers versed in logic array terminology, and that is rejected, then this is inconsistent to me.  I'm looking for some guidelines and consistency. 

If the game is to have a 'automation mode' (and I'm pretty sure I remember Tyron mentioning this) then hey, awesome, anything goes there obviously.  But if that's the case maybe it's also worth discussing what automation makes it's way into the 'normal' game, and what doesn't?

I'll explain how I would love to see the engineering potion of VS designed and implemented:

First of the implementation: Engineering should be an equal pillar of gameplay, like exploration, survival and building. But I think the best way to archive this is not to force the player to automate things, but provide the ability for automation. Because the gameplay pillars are so different from another, making some necessary would ruin the fun for others. Regarding play-styles: I would only want them to differentiate in mechanics, like hunger or the inventory system, but not (or only minimally) in content.

My main design principles for engineering:

1. Engineering should be able to accomplish everything the player can accomplish and more.
2. A block should have a minimal function and have a maximal application: A block breaker can only break blocks, but it can be used for many different things, like automated farms, quarries, etc. Your farming cart however only has one function and one possible application.
3. Each block needs at least one unique application.

[redram]

If the counter is that close to a timer it might have been more helpful to have said 'we already basically have a timer' rather than calling a timer a magic box. 

11 hours ago, Erik said:

But a lens, a mini-boiler and mini-turbine too, wouldn't need to exist on their own thus making them only useful as a daylight sensor.

From a point of view fixated only on what we have and the logic tools you presented, sure.  Now there was no turbine involved in my example, so I'm assuming you meant the actuator piston?  That's entirely different from a turbine.  I was thinking of it as a small piston type thing that acts as an interface between logic and other items.  it can't move blocks or anything like that - stuff that a real piston does - but it can flip a valve, press a button, etc.  It doesn't have to be right next to the tank, and that's where the setup variety comes in.  You could have the tubing from the tank branch and activate multiple actuators.  It quite frankly provides a variety of possibilities, if you just try to imagine them.

Small boiler too specific? Fine,  just call it a tank.  The same tank used in my clay slip storage example.  If it's a distinct piece there's no reason for the tank to be 6x6x6 voxels or whatever, rather than a full block, or 14x14x14, or whatever it's decided to be.  Tanks could have all manner of applications in alchemy, alcohol brewing, etc.  Same for piping of course. 

The lens is one component of a mirrored lighting array (a separate suggestion really - but just think of the mirrored light finale of the movie Legend.  That same mechanic means it's not necessarily set up the same way every time.  But even if that never made it into the game, a lens is a component part of spyglasses, maybe telescopes.  Possibly vision magnifier as part of clockwork tech tree.  It's irrelevant if the parts have no other use *within the Logic tools*.    If it's worth using two preexisting parts to make a timer, even though they will, from what I understand, ALWAYS be directly by each other, then why not make a daylight sensor be of specific parts with other uses, even if they are always beside each other (they do not have  to be)?

11 hours ago, Erik said:

First of, the device in the picture would have been used for killing people, it's a war machine. Both ways are ridiculous in their own right, I just prefer the piston powered machine.

Yes, I'm well aware of Leo's motivation.  And it was never built (afaik) for war because it would have been useless for war except as a terror device, and I'm sure that the people who actually conducted wars at the time recognized that.  It was far too complex to stand up to enemy attempts to disable it, or probably even the weapons and corpses that would have gotten tangled in it, not to mention uneven terrain and obstacles.  It basically would have only been useable on a dry desert salt flat.   But it could have been built in that time, unlike a crop harvesting piston array.    And it just so happens that VS is composed largely of large flat areas.

11 hours ago, Erik said:

Would your idea work? Yes, maybe it would be a better system, but it relies on mechanics not present in the game. Adding weight and size for this mechanic alone seems like a waste

Do any logic mechanics at all exist in the game yet?  If the non-existence of a mechanic is a reason no to add it, this game is going to hit a development wall really soon.  Weight and size are just numbers, data points.  They're not even mechanics.  A block causing an item to move in one direction or another is no different from conveyor belts.  And, as mentioned, the numbers *could* serve double-duty, if a more involved inventory system were implemented, which I and others have advocated.   I'm not claiming a size and weight sorting system would work 'better' than a standard MC-style system (assuming here that better means a more granular level of sorting).  It definitely would not, unless every single item had a different weight-size combination, which  would be a pain to manage.  I'm imagining all cobble, or all flowers, for instance, having the same weights.   So I'm straight up not saying it's more granular.  But it's more believable.  It brings verisimilitude to the process, imo.  Maybe it's ok if the system is not perfect? 

 

11 hours ago, Erik said:

But I think the best way to archive this is not to force the player to automate things, but provide the ability for automation.

Yes, agreed.  I was pretty into Oxygen Not Included until they added their logic system.  The feeling it gave me was 'ok, we're now going to make the game so that only those of you who are familiar with Logic devices can get the most from it.  All the rest of you are now second-class players.  You're either going to be inefficient, or you're just going to have to copy systems from those people who know what they're doing.'  It can create a feeling of a barrier I think, so I'd definitely say it needs to be as low-key as possible.  And as accessible to the layman as possible.  Geneva mechanisms are good - they represent quite well visually, what they're doing. 

11 hours ago, Erik said:

 

1. Engineering should be able to accomplish everything the player can accomplish and more.
2. A block should have a minimal function and have a maximal application: A block breaker can only break blocks, but it can be used for many different things, like automated farms, quarries, etc. Your farming cart however only has one function and one possible application.
3. Each block needs at least one unique application.

 

1. - disagree as a guiding principle.  If it turns out that way in a believable fashion great.

2. - Disagree.  The game is full of single-purpose items, and it's going to have more of them.  Every tool mold is single purpose.  Skeps are single purpose.  If a harvester is single purpose then every tool is single purpose item, as is every weapon.  It's nice when basic constituent items can have multiple uses - reeds, wood, honey, etc.  But end-use items - and especially end-use items at the top of the tech tree - do not need to have multiple purposes.

I don't know if I can offer a set of hard principles, because there's a lot of items in section 16 whose use I'm not sure of, but in my opinion, what's added should be guided by what is believable for a pre-electric society.  No magical sensors.  Come up with an analog way that it works, or don't add it.  Unless of course we get something akin to electric tech - maybe ruins-found stuff?  Try to avoid hokey minecraft stuff (I know, very subjective, but nonetheless).  Make it as intuitive and understandable as possible for your average person; try not to make people feel like they need to take a college course to use it.  Something like that.