Plenty of arguments can be made either way, but in general I've been following the "if you can already do it, then there's no reason to make it easier."; Now this means do it right, and the current solution works very well.
If I craft an item that require lot of crafting like a EV CompactWindmill, often the autocrafting stops working and the only way to restart it is to remove and replace the ME Controller.
P.S. My server crash when you try to craft a Firework but you don't have the right color for the Firework Star (with AE r13) Crash Report
Sorry for my English
If you can recreate the crash in rv14 I'll fix it, if it won't crash its probably already fixed, and the crafting issue is hear to stay until the AE2 re-write is complete.
First, You can simply that by replacing the chest and the import bus with an interface.
Second, if you can build it already, I'm probably not going to add anything that makes it easier. There are 100's of feature I could add to make things simpler, easier, or just less work, but AE is supposed to be part of a game, not a utility that removes hours of potential gameplay and fine tunes or just hands out solutions
Plenty of arguments can be made either way, but in general I've been following the "if you can already do it, then there's no reason to make it easier."; Now this means do it right, and the current solution works very well.
I like this guy's idea, but I had a different idea as well, as far as 'speeding up' the crafting. My idea is more of a MAC upgrade.
Currently, there are two interior pieces for the MAC, the CPUs, and the Pattern providers. I have an idea for an optional third block that overhauls the way the crafting is handled. The way I see it working now, of course, is that it pieces together each piece one item at a time. Say you want to autocraft a 64k storage unit from complete scratch. When you watch the process go, you'd notice immediately that the basic processors get sent to the processing unit (furnace of whatever sort) one by one as each piece is assembled.
What I'm thinking this third block could do is analyze the recipes from the end product down to the basic materials, figure out the number of each item/product needed, then have it begin crafting in chunks of items, finishing that item set before moving to the next set of items (craft the 36--less if there's already some in the system--basic processors needed, send all to the furnace in one chunk, then continue the next tier of craft). This wouldn't be just an instant make a stack or however many need at once though, as the machine should be upgraded like the CPUs work. I'm thinking that the new block (called adv cpu or something similar) would start at analyzing the recipe-list for the end product with the first adv cpu, then begin making in stacks of four with the second adv cpu, and for each adv cpu added after, increase the stack crafting by 4. (or by 8 for each, whichever would work best). This way, it'd be crafting as though you were manually shift-click crafting using a crafting terminal.
I have no idea if this method is viable, but I like the idea of it. While I could use the method dgendreau suggested with the interface/export/level emitter method, I think it'd be awesome to see an upgrade option for the MAC.
Maybe going further with it even, you could require some new types of heat vents for the adv cpus, or maybe a new frame block to house the upgraded MAC. Or, even making a secondary MAC that has only the adv cpus and adv pattern provider, so that you have the basic MAC that does the bulk of crafting, then you have the adv MAC that can craft in chunks rather than one piece at a time. Yeah, we can go bigger with the basic MAC, but speed increase becomes miniscule after a point, and eventually unnoticeable.
)( EDIT:: )( So....apparently my idea is a bit late, as this is essentially being put into AE2. Ignore my idea here.
I like this guy's idea, but I had a different idea as well, as far as 'speeding up' the crafting. My idea is more of a MAC upgrade.
Currently, there are two interior pieces for the MAC, the CPUs, and the Pattern providers. I have an idea for an optional third block that overhauls the way the crafting is handled. The way I see it working now, of course, is that it pieces together each piece one item at a time. Say you want to autocraft a 64k storage unit from complete scratch. When you watch the process go, you'd notice immediately that the basic processors get sent to the processing unit (furnace of whatever sort) one by one as each piece is assembled.
What I'm thinking this third block could do is analyze the recipes from the end product down to the basic materials, figure out the number of each item/product needed, then have it begin crafting in chunks of items, finishing that item set before moving to the next set of items (craft the 36--less if there's already some in the system--basic processors needed, send all to the furnace in one chunk, then continue the next tier of craft). This wouldn't be just an instant make a stack or however many need at once though, as the machine should be upgraded like the CPUs work. I'm thinking that the new block (called adv cpu or something similar) would start at analyzing the recipe-list for the end product with the first adv cpu, then begin making in stacks of four with the second adv cpu, and for each adv cpu added after, increase the stack crafting by 4. (or by 8 for each, whichever would work best). This way, it'd be crafting as though you were manually shift-click crafting using a crafting terminal.
I have no idea if this method is viable, but I like the idea of it. While I could use the method dgendreau suggested with the interface/export/level emitter method, I think it'd be awesome to see an upgrade option for the MAC.
Maybe going further with it even, you could require some new types of heat vents for the adv cpus, or maybe a new frame block to house the upgraded MAC. Or, even making a secondary MAC that has only the adv cpus and adv pattern provider, so that you have the basic MAC that does the bulk of crafting, then you have the adv MAC that can craft in chunks rather than one piece at a time. Yeah, we can go bigger with the basic MAC, but speed increase becomes miniscule after a point, and eventually unnoticeable.
MACs are being completely re-imagined for AE2, and crafting will work much differently as well, most notably will be the planning of the task, rather than AE's Just do stuff and hope it works out approach.
MACs are being completely re-imagined for AE2, and crafting will work much differently as well, most notably will be the planning of the task, rather than AE's Just do stuff and hope it works out approach.
Hi
I just have updated to the latest version of factorization.
In this version neptunepink changed the barrel code and it seems that your storage buses aren´t working anymore?
Did i do something wrong or is this just the code change in the barrel system?
Looks like Neptunepink changed the name of the barrel class, so AE can no longer find it by the original name, it will require a new release to fix it.
Hey, I'm a real big fan of the mod and i was wondering if AE could add its on auto smelting and auto macerating multiblock structures to the game.You're a very creative person, so that's all I'm going to say. I hope you think this is a good idea because I would love to see what you could come up with.
Hey, I'm a real big fan of the mod and i was wondering if AE could add its on auto smelting and auto macerating multiblock structures to the game.You're a very creative person, so that's all I'm going to say. I hope you think this is a good idea because I would love to see what you could come up with.
Why? There numerous other mods that'll do it for you that can basically all be automated with AE.
Hey, I'm a real big fan of the mod and i was wondering if AE could add its on auto smelting and auto macerating multiblock structures to the game.You're a very creative person, so that's all I'm going to say. I hope you think this is a good idea because I would love to see what you could come up with.
You can trust in the fact that If I came up with some cool stuff I would probably add it to the mod, I'm generally not going to go out of my way to add content to AE thats a mirror image to another mod, or its content.
That said, I don't have any cool ideas regarding this, so while its not a no, its an unlikely.
I personally don't think AE is in shadow, it does things in a unique way and basically everything in it fits well into the whole. I don't feel the need to add ore processing to AE, just because most tech mods have ore processing, nor do I feel the need to participate in the Ore Duplication "arms race".
You can trust in the fact that If I came up with some cool stuff I would probably add it to the mod, I'm generally not going to go out of my way to add content to AE thats a mirror image to another mod, or its content.
That said, I don't have any cool ideas regarding this, so while its not a no, its an unlikely.
I personally don't think AE is in shadow, it does things in a unique way and basically everything in it fits well into the whole. I don't feel the need to add ore processing to AE, just because most tech mods have ore processing, nor do I feel the need to participate in the Ore Duplication "arms race".
I'm trying to use one of the fuzzy storage busses to store a bunch of Thaumcraft's mana beans in a non-drive location (the number of item types they take up is just maddening), but the bus doesn't seem to like any bean that has an aspect I don't yet have a bean for, how would I fix that?
I'm trying to use one of the fuzzy storage busses to store a bunch of Thaumcraft's mana beans in a non-drive location (the number of item types they take up is just maddening), but the bus doesn't seem to like any bean that has an aspect I don't yet have a bean for, how would I fix that?
I don't really know anything about mana beans, but AE doesn't care about any of TC's aspects or features, it just treats them like every other item, so it might be related to where you trying to store them.
I don't really know anything about mana beans, but AE doesn't care about any of TC's aspects or features, it just treats them like every other item, so it might be related to where you trying to store them.
I'm thinking it might be how Azanor has chosen to code the beans. Would there be any way to set the fuzzy storage bus (or any of the buses) to ignore NBT data as well as the metadata/damage split?
I'm thinking it might be how Azanor has chosen to code the beans. Would there be any way to set the fuzzy storage bus (or any of the buses) to ignore NBT data as well as the metadata/damage split?
Fuzzy buses always ignore NBT, cept with bees. and the damage value has a config option.
Unless they are in the ore dictionary, and only some of the beans are in there, and not all of them I can't think of any reason for this.
ah, I think that's the problem, they don't appear to be in the ore dictionary and I don't have a bean for every aspect yet.
I was just pointing out that the ore dictionary changes the behavior, if they are not in the ore dictionary it still ignores NBT, its possible they are all different unique damage values however, if that's the case the fuzzy bus will treat them as 100% different items, since they are "sub types" and not "damageable items"
i've been playing with the spatial storage in a slightly modified ftb unleashed pack.
it appears that the spatial storage creates a new dimension for each spatial io cell, with a region bounded by unnamed blocks.
access is of course available regardless of spatial io via tpx commands(and thus command blocks), gt teleporter with interdimensional, and even mystcraft linking books.
i was initially going to inquire if it was possible to name the individual spatial io cells, or otherwise manually differentiate them for the purposes of sorting and automation, with a holodeck implementation in mind...
unfortunately duplication of a spatial cell simply duplicates the link to a given dimension. so pretty please, creative spatial cell?
write once read many? only issue i see is player transport on them, so perhaps disable that on the creative cells without disabling storage of other entity types if possible. then finally a working holodeck.
Fair enough.
If you can recreate the crash in rv14 I'll fix it, if it won't crash its probably already fixed, and the crafting issue is hear to stay until the AE2 re-write is complete.
Currently, there are two interior pieces for the MAC, the CPUs, and the Pattern providers. I have an idea for an optional third block that overhauls the way the crafting is handled. The way I see it working now, of course, is that it pieces together each piece one item at a time. Say you want to autocraft a 64k storage unit from complete scratch. When you watch the process go, you'd notice immediately that the basic processors get sent to the processing unit (furnace of whatever sort) one by one as each piece is assembled.
What I'm thinking this third block could do is analyze the recipes from the end product down to the basic materials, figure out the number of each item/product needed, then have it begin crafting in chunks of items, finishing that item set before moving to the next set of items (craft the 36--less if there's already some in the system--basic processors needed, send all to the furnace in one chunk, then continue the next tier of craft). This wouldn't be just an instant make a stack or however many need at once though, as the machine should be upgraded like the CPUs work. I'm thinking that the new block (called adv cpu or something similar) would start at analyzing the recipe-list for the end product with the first adv cpu, then begin making in stacks of four with the second adv cpu, and for each adv cpu added after, increase the stack crafting by 4. (or by 8 for each, whichever would work best). This way, it'd be crafting as though you were manually shift-click crafting using a crafting terminal.
I have no idea if this method is viable, but I like the idea of it. While I could use the method dgendreau suggested with the interface/export/level emitter method, I think it'd be awesome to see an upgrade option for the MAC.
Maybe going further with it even, you could require some new types of heat vents for the adv cpus, or maybe a new frame block to house the upgraded MAC. Or, even making a secondary MAC that has only the adv cpus and adv pattern provider, so that you have the basic MAC that does the bulk of crafting, then you have the adv MAC that can craft in chunks rather than one piece at a time. Yeah, we can go bigger with the basic MAC, but speed increase becomes miniscule after a point, and eventually unnoticeable.
)( EDIT:: )( So....apparently my idea is a bit late, as this is essentially being put into AE2. Ignore my idea here.
MACs are being completely re-imagined for AE2, and crafting will work much differently as well, most notably will be the planning of the task, rather than AE's Just do stuff and hope it works out approach.
Looks like Neptunepink changed the name of the barrel class, so AE can no longer find it by the original name, it will require a new release to fix it.
I don't know at this point.
Why? There numerous other mods that'll do it for you that can basically all be automated with AE.
Why stay in the shadows of other mods?
You can trust in the fact that If I came up with some cool stuff I would probably add it to the mod, I'm generally not going to go out of my way to add content to AE thats a mirror image to another mod, or its content.
That said, I don't have any cool ideas regarding this, so while its not a no, its an unlikely.
I personally don't think AE is in shadow, it does things in a unique way and basically everything in it fits well into the whole. I don't feel the need to add ore processing to AE, just because most tech mods have ore processing, nor do I feel the need to participate in the Ore Duplication "arms race".
Fair enough.
I don't really know anything about mana beans, but AE doesn't care about any of TC's aspects or features, it just treats them like every other item, so it might be related to where you trying to store them.
I'm thinking it might be how Azanor has chosen to code the beans. Would there be any way to set the fuzzy storage bus (or any of the buses) to ignore NBT data as well as the metadata/damage split?
Fuzzy buses always ignore NBT, cept with bees. and the damage value has a config option.
Unless they are in the ore dictionary, and only some of the beans are in there, and not all of them I can't think of any reason for this.
ah, I think that's the problem, they don't appear to be in the ore dictionary and I don't have a bean for every aspect yet.
I was just pointing out that the ore dictionary changes the behavior, if they are not in the ore dictionary it still ignores NBT, its possible they are all different unique damage values however, if that's the case the fuzzy bus will treat them as 100% different items, since they are "sub types" and not "damageable items"
it appears that the spatial storage creates a new dimension for each spatial io cell, with a region bounded by unnamed blocks.
access is of course available regardless of spatial io via tpx commands(and thus command blocks), gt teleporter with interdimensional, and even mystcraft linking books.
i was initially going to inquire if it was possible to name the individual spatial io cells, or otherwise manually differentiate them for the purposes of sorting and automation, with a holodeck implementation in mind...
unfortunately duplication of a spatial cell simply duplicates the link to a given dimension. so pretty please, creative spatial cell?
write once read many? only issue i see is player transport on them, so perhaps disable that on the creative cells without disabling storage of other entity types if possible. then finally a working holodeck.