FactoryMod v2

[gmlaxfanatic2]

Hey guys, Its been a while, but my recent conversations with /u/space_fountain made want to come back and code something I have been thinking about for a long time, what the next iteration of a FactoryMod should look like. I've thrown together some code to get an idea of where I am going with it and wanted to share my thoughts with you to get preliminary feedback. The primary changes I want to make is much more flexible creation of new kinds of factories so that the code base is easier to maintain, and much more efficient and controllable use of tick through Runnables, which should allow many more factories to be operational without impacting performance.

The repo is here: https://github.com/gmlaxfanatic/Contraptions

But I'll just paste the Readme at the end to give people a good idea of where I am headed. Note: I don't care so much about creating specific new factories at the moment, mostly I am just trying to put together a framework that will allow other people to easily create new factories in the future, so the next Nether Factory or Printing Press can be created in a much more extensible code base.

Contraptions

Contraption's goal is to provide a framework for adding increased functionality to blocks in minecraft. At its core it is meant to be highly flexible to the addition of new functional elements to individual minecraft blocks, allowing for the simple creation of a wide range of different kinds of interactive structures. This program will allow tens of thousands of interactive blocks to be added to the minecraft world in an efficient manner giving rise to emergent constructions of complex machinery.

The Contraption

A contraption is a single minecraft block that pieces together a bunch of widgets and resources. Widgets are functional components that interact with the minecraft world and the resources of the contraption. Resources are simple values within the contraption that represent a range of different properties, they allow widgets to interact with each other and factories to keep track of their current state. Via the composition of multiple widgets and resources contraptions will easily give rise to complex behavior and interaction with the minecraft world and other contraptions.

Potential contraptions include:

1. A Factory which costs a good bit to make but allows people to execute custom recipe using it. However the factory continously consume energy, and when it runs out it is destroyed! However it will automatically consume fuel held within it to regenerate energy, and may also be energized via a power plant.
2. A loader, which simply loads all the items in its inventory into the block infront of it. However this takes a lot of energy, and overtime the loader just being around will drain energy as well.
3. A Unloader, about the same as the loader, but it unloads items from sorrounding blocks into itself instead.
4. A Power Plant that will provide energy to all contraptions within a radius of itself, that way the contraptions don't have to fuel themselves!
5. A Trigger, this simply trigger sorrounding contraptions to do something, like have a factory produce a recipe.

Widgets

A contraption's widgets are what allow it to do things, and each contraption implementation decides how specifically to use the widgets that have been coded. These widgets can respond to events, do things over time, or respond to other widgets in the same contraption or others. Programmatic constraints dictate that widgets should not trigger chunk loads and should not be required to run frequently.

Tentative Widgets:

1. Match widget: A widget that when triggered attempts to consume a set of items, but only consumes them if the inventory only contains those items.
2. Production widget: A widget that when triggered attempts to convert one set of items in the contraption to another set of items
3. Decay widget: A widget which drains a resource over time.
4. Generation widget: A widget that will convert a set of items into a resource.
5. Load widget: Load items from surrounding containers over time
6. Unload widget: Unloads items to surrounding containers over time
7. Aura widget: Influence the resources of surrounding contraptions every so often
8. Trigger widget: Trigger widgets in ajoining functional blocks
9. Teleportation widget: Teleport the interacting player to nether
10. Effect widget: Bestow an effect upon the interacting player

[justin kilpatrick]

This sounds like an interesting idea, what sort of computational complexity are we looking at? 

[Brian Landry]

I'm preventing computational complexity by keeping all actions local to each Contraption, and therefor each Contraption's actions are O(1) with # Contraptions. The only method that scales O(n) with Contraptions is finding one given a location, but that is a readily solvable problem.

Every kind of action by the Contraption is either triggered or scheduled to repeat with a controllable number of ticks, so instead of checking in on everything every tick (like FactoryMod currently does), the computationally heavy actions could be set to occur once every 200 ticks, and the quick ones every 10 ticks. I'm hopeful this could allow scaling to a large number (10,000+?) of Contraptions efficiently. Example planned actions include: push ItemStacks to and from surrounding blocks, consume/produce itemstacks, change internal variables, change variables of Contraptions within a local area, teleport a player, and trigger other contraptions. 

[staygroovy57]

Sounds like something definitely worth exploring and ttk2 had recently been voicing the desire of getting involved with multi-block factories.

In addition, I would suggest that item compactors/decompactors be looked at as a way to feed these devices in a convenient manner that isn't constantly hampered down by going beyond the limitations of Minecraft mechanics.

[justin kilpatrick]

I think this might be the way to go forward, do you think it would be feasible to replace all of botting with stuff like this? (trying to explore the limits of the idea)

[Brian Landry]

So I only follow civcraft development, so I don't know what is actually botted in game, but I can make a few points.

Contraptions will automate item movement and recipe usage without chunk loading, so assembly line type bots will be unnecessary.

To replace botted farming is harder from a design standpoint. My current thought is a Contraption that generates XP based on how much land area it is the closest Contraption to, so someone produces XP at a rate related to the territory he can exert his influence over (like this). This will lead to great player vs player interactions and have a global rate of XP generation set by us. I've found an O(n*log(n)) algorithm implementation to calculate the controlled land in Java too.

I'd be interested in hearing from involved players what the main uses of botting actually are.

[justin kilpatrick]

so global territory independent rate of xp production that is capped by people around the map?

[Brian Landry]

So there is a single global rate of XP production, then people build a Contraption to tap into a percent of that rate. How big a percent they get is related to the land the Contraption controls. Land control at a block can be determined simply by asking which Contraption (of a specific type) is the closest, that Contraption then gets to generate XP based on control of that block. (The actual algorithm works differently and quicker)

1 dimensional example where blocks go from 0 to 100:

Case 1) Contraption A @ position=40: A generates 100XP/day

Case 2) Contraption A @ position=40, Contraption B @ position=50: A generates 45 XP/day, B generates 55 XP per day

Case 3) Contraption A @ position=40, Contraption B @ position=50, Contraption C @ position=70: A generates 45 XP/day, B generates 15XP/day, C generates 35XP/day

[justin kilpatrick]

this is a really really cool idea, I think this might be the best suggestion in ever. combined with a few other ideas that I want to flesh out. 

[Nick]

Just replace 'XP' with 'factory efficiency rating' and turn it into a general scaling factor used with any factory production, if enabled for the factory.

N

[justin kilpatrick]

why not xp too and have factories in general make "environmentally affected factories" less effective. 

[Nick]

Xp would just be another factory product.

N

[justin kilpatrick]

well yeha, we want it as an input to higher level factory stuff. 

[Matthías Valdimarsson]

I'm having a really hard time picturing what this will look like in practice and how you mean to store the information.

[Brian Landry]

So I've made a good bit of progress, and have been doing java docs along the way. So you can poke around them here: http://gmlaxfanatic.github.io/Contraptions/dist/javadoc/index.html

Just don't try to run it, that's my next goal... Once its working I'll make more detailed writeups for the general population, Config writers, and Java developers.

I'm using JSON for the config btw. 

[Gavin Jenkins]

Everything about the contraptions sounds very confusing to me. The loader and unloader sounds like an expensive version of a dropper and hopper, so why would I use them instead of their free versions? Or is the suggestion to replace those? If so, that would bear a lot more discussion first.

The widgets are less confusing, and sound fine, however I'm not sure I see how they are more useful than current factories.

Replacing production line botting would require things I don't see listed here, but could easily be included and would make this seem more useful. Like "widget that tries to craft the first item slot's item, using stuff in the remaining slots" or a filtering chest, etc.

The XP Voronoi idea is pretty cool! Do note that it would not actually conform to territory controlled politically, however. It would hugely disproportionately benefit tiny countries, since they make one factory that inevitable Voronoi's large tracts of land outside their borders, unless other people completely surround them with multiple factories at much higher cost.

[Jake Jungbluth]

I think you are confusing this framework as an implementation

This would be tools to create multi block factories by developers as I understand it 

[gmlaxfanatic2]

Gavin, great feedback.

First, I'll say my main goal behind Contraptions is to make the actual code much nicer and more extensible than FactoryMod, so that improvement might not be immediately evident (what jjj said).

But to the implementation, it would be really great if you could further specify exactly what these blocks would need to do to replace assembly line bots (I really have no clue). 

Yes, one thing would be to just replicate hoppers and dumpers, unfortunately at a higher cost, but with the advantage they run without the chunk being loaded. Still might not be a useful implementation.

However another implementation could be an item sorter (these don't really exist in minecraft right?).

Lastly, I want to implement an automatic crafter, which will trigger adjacent factories to execute their recipes (do bots do none factory recipes right now?)

And lastly to the XP idea, I think you get that completely, and I'm very interested to see how scenarios like the one you described work themselves out in game.

[Christopher Connor]

gavjenks: You're an idiot. You have no idea what you're talking about. Even if this were an implementation, rather than a framework, droppers and hoppers are buggy and slow as fuck. A way of moving items without making the server process every dropper/hopper they go through would be much appreciated by everyone who automates item transportation.

landrypants: To replace assembly line bots, you mainly need to make factories have configurable input and output containers. If it were possible to have one factory output into another's input chest, then activate the next factory, there would be no need for a player to move the items.

[Brian Landry]

Christopher, please keep insults like that outside of the development group, they do not help with a constructive discussion.

Thanks you for the feedback though. I think I will be implementing Contraptions that can accomplish what you say, so hopefully they will replace the buggy/slow droppers and hoppers.

[Bob Pendragon]

Whoa. No need for insults or hostility.

[Gavin]

Yes hoppers could be recoded better. The problem is that:

1) This said it would require fuel. As a player, I would not spend a bunch of fuel if I had both this and hoppers available, even though hoppers are slower and worse for the server. Selfishly for my own farm it would be a poor choice, probably.

2) If you MAKE people use these, then you have an issue with "what about all the people that invested in hoppers? Are we replacing them all? But then they won't be hooked up to fuel." / breaking every farm on the server.

That's why I said "It would bear a lot more discussion" not "bad idea"

But apparently this is for devs to designf actories, not a modular device for players? In which case, I'm afraid I just don't quite see the point of a hopper-like device at all in a pre-packaged factory. If it's dev-designed and prepackaged, then it's no fun to have modules anyway, so why bother with the lag they create (even if less than the minecraft equivalents would be)? Just make an all at once factory like now, if that's how it is. Simpler to make and no more or less fun or creative for players.

[Christopher Connor]

landrypants/bobpndrgn: Ok, you're right. I've just been getting really fed up with how much he likes to talk with no experience.

Gavin: There's no reason for it to be "a bunch of fuel", all of this is tentative and would be balanced before hitting the server. You say you'd use hoppers anyway, are you actually running a farm or just making this up? I'm running a carrot farm and the only way I can handle the volume of carrots is using a glitch to make droppers faster and limiting the size of the farm. There is currently no way of handling large volumes of items without the help of a player.

* Hoppers are the only thing that can pull in items other than players/bots, and they are too slow.

* Droppers can move items horizontally at a good speed using a glitch, but have to be fed manually or by hoppers.

* Minecart chests can carry 27 stacks, but are hopper/player only.

* Supercarts can transport large volumes but must be loaded by players.

So the only effective way of transporting large amounts of items quickly over a short (in-chunk) distance is droppers, but they still can't handle factory assembly lines because they only push, not pull.

[Gavin]

Er didn't hit reply all. Somewhat relevant:

Me > Use a waterway to move crops before they get hoppered

Chris > A hopper can't handle 576 items per minute

Me right now > Use several waterways and hoppers... A double chest can have 8 hoppers going into it while still opening it from below. If you need more you for higher hopper bandwidth you would have to suffer the minor inconvenience of two chests next to each other.

This is all a bit tangential, perhaps, but what other need is there, gameplay/farming/etc.-wise for replacing hoppers (other than, of course, lag) or moving items around mechanically?


IF the new system allows for auto crafting factories, and things like that, then that would create a need, perhaps. By the way, I will get to specing a system that would be good for that in a little while, gmlax

[Matthías Valdimarsson]

Hoppers need a check every block, custom implementations reduce load from moving items by orders of magnitude.

[Rourke750]

Gml could you add something like this http://www.reddit.com/r/Civcraft/comments/2ywhx7/morning_changelog_20150313/cpdqs3j

The first line of lore would be a unique identifier and below that would be a description of the item. Then in config you specify what damage extra or how much extra damage it takes and does by specifying the id or enchantment.

[Brian Landry]

Current and future implementations of Factories support complete custom display name and lore specifications. So yes, producing an Item with lore is easy and can be handled through config changes.

The difficulty arises when integrating with enchanting, ideally the lore would be produced prior to enchanting then you would enchant the lored item (I think this is supported by minecraft?). If this solution works I'd suggest you just go with it.

Otherwise factorymod currently has strictly defined inputs>outputs, so you can't say add a string of lore to any sword with any enchantments, instead you need a unique recipe for each kind of enchanted sword in order to convert it to a sword with lore.

[Matthías Valdimarsson]

Please add the possibility of having an or statement for inputs

[Jake Jungbluth]

Do you mean like have the factory auto-select the recipe?

[Matthías Valdimarsson]

Also sub groups for recipes would be nice, it would make using factories with a huge number of recipes easier to use.

On 18 Mar 2015 16:16, "Jake Jungbluth" <jjj...@gmail.com> wrote:

Good idea that would be extremely nice

On Wed, Mar 18, 2015 at 10:54 AM, Matthías Valdimarsson <goldma...@gmail.com> wrote:

From the available ingredients yea

[Rourke750]

gml want me to fork contraptions into the civ repo and add you as a member so you can push updates there?

[Brian Landry]

Add me as a member if you don't mind, I figured I wouldn't stick in the repo until its in a state I would want other people going at it or putting it on CivTest.

I still need to figure out maven and versioning and stuff for it, never done that before...

[Rourke750]

Don't worry about maven. I can do that for you.