{"action":"created","issue":{"url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/393","repository_url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2","labels_url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/393/labels{/name}","comments_url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/393/comments","events_url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/393/events","html_url":"https://github.com/AppliedEnergistics/Applied-Energistics-2/issues/393","id":47895239,"number":393,"title":"Centralized pattern storage and molecular assembler enhancements.","user":{"login":"king5327","id":3391168,"avatar_url":"https://avatars.githubusercontent.com/u/3391168?v=3","gravatar_id":"","url":"https://api.github.com/users/king5327","html_url":"https://github.com/king5327","followers_url":"https://api.github.com/users/king5327/followers","following_url":"https://api.github.com/users/king5327/following{/other_user}","gists_url":"https://api.github.com/users/king5327/gists{/gist_id}","starred_url":"https://api.github.com/users/king5327/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/king5327/subscriptions","organizations_url":"https://api.github.com/users/king5327/orgs","repos_url":"https://api.github.com/users/king5327/repos","events_url":"https://api.github.com/users/king5327/events{/privacy}","received_events_url":"https://api.github.com/users/king5327/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":22,"created_at":"2014-11-05T22:14:04Z","updated_at":"2016-08-26T21:05:45Z","closed_at":"2014-11-05T22:44:30Z","body":"The way crafting is done through molecular assemblers is probably the most annoying thing for me in this.\r\n\r\nWhen you smelt something through a furnace, it makes sense that you'd need export buses, because you're turning the item back into a real thing, smelting it, and transforming it back. With molecular assembler chambers, you're not changing the object outside the system, you're having it 'react' with other objects to form another, all within the system (although it's still becoming matter for a moment, but because the MA has both annihilation and formation cores within its recipe). This brings the obvious question: why do we need interfaces to interact with it?\r\n\r\nI believe that it would be far more versatile if it were alternatively possible to store the crafting patterns in one or more cuboids on the network. Crafting CPUs would need a bit more memory and time to find the correct one if there isn't any interface with said pattern in it, but it would allow any MA to craft any pattern within the network (at a small cost of time) if the MA specialized in that pattern is in use (should there be one). Once loaded into the CPU, the pattern doesn't need to be looked up again until the current request finishes. The 'crafting pattern provision' (there are better names) blocks should be able to hold as many patterns (per block) as the pattern provider in AE1 did. Another little detail is that any pattern on the network that feeds into a specialized MA should be available to all of them for that same time and CPU cost. It doesn't feel like a network if you have to start making duplicate resources when one would suffice.\r\n\r\nAt the very least, I beg that this be a config option."},"comment":{"url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/comments/242851483","html_url":"https://github.com/AppliedEnergistics/Applied-Energistics-2/issues/393#issuecomment-242851483","issue_url":"https://api.github.com/repos/AppliedEnergistics/Applied-Energistics-2/issues/393","id":242851483,"user":{"login":"Tcll","id":773959,"avatar_url":"https://avatars.githubusercontent.com/u/773959?v=3","gravatar_id":"","url":"https://api.github.com/users/Tcll","html_url":"https://github.com/Tcll","followers_url":"https://api.github.com/users/Tcll/followers","following_url":"https://api.github.com/users/Tcll/following{/other_user}","gists_url":"https://api.github.com/users/Tcll/gists{/gist_id}","starred_url":"https://api.github.com/users/Tcll/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Tcll/subscriptions","organizations_url":"https://api.github.com/users/Tcll/orgs","repos_url":"https://api.github.com/users/Tcll/repos","events_url":"https://api.github.com/users/Tcll/events{/privacy}","received_events_url":"https://api.github.com/users/Tcll/received_events","type":"User","site_admin":false},"created_at":"2016-08-26T21:05:45Z","updated_at":"2016-08-26T21:05:45Z","body":"Tou-che\r\nI may come across as being an A, probably because I deal with enough developers who insist their codes are diamond when they're made of glass.\r\nTrust me when I say I'm a good guy, but mind the fact I do have a problem wording myself.\r\n\r\nAs for my comment above, I mean what I say constructively, not offensively, and I'm sorry to those who took it that way.\r\n\r\nIf you read my issue, you'll understand what I mean by poor design.\r\nI've been trying to build something efficient for years now, and the best I currently have is a bunch of nodes consisting of 16 interfaces  with the same recipes, each with 6 of their own MAs.\r\nit's so fast, though I haven't had it long enough to bench it..."}}
{"actor":{"display_login":"Tcll"}}