Closed henriksjostrom closed 8 years ago
should not besides enough storage space another method would be to use tesseracts and ME Interface
Yes, having some pipes from the chest into an interface made it work again. Why the import buses fail I still have no clue.
You might just be asking too much of that import bus. Maybe you could divide your incoming resource stream between two or more chests that each get processed by their own bus. Just one extra chest/bus pair doesn't lean too hard on your resources, but it would immediately halve the load for the current bus.
It is not a single import bus, it is 12 with full acceleration upgrades and they did stop completely.
Ah, your top post repeatedly speaks of "ender chest", not "ender chests", so I assumed 'one chest, probably one bus'. I still have trouble imagining 12 buses accessing one chest, though. So maybe there are more chests, too?
If so, then I'm at a loss too.
Well I had 1 chest with 6 import buses, the issue arose so I upgraded by adding another 6. Did not help
Are you by chance using an outdated version? There was a bug, when they had 4 upgrades installed, that they fail
Or maybe running out of power? Try slapping a dense energy cell on that network and see if the issue is still there
I am using rv2-beta-8 (FTB infinity 1.2.1).
I had 230 dense energy cells in the network at last count storing 370 MAE and the network only draws roughly 10kAE. Power it should not be.
However I have noticed a few more things, when crafting on occasion it seems to not arrive at any crafting plan, nothing appears in the UI and I can only cancel. Trying a few seconds later generally solves this.
Furthermore the network can suddenly stop exporting to.
This might be crafting related as the network stopped exporting once I started a bunch of crafting jobs (crafting interfaces with storage interface on to make sure a certain amount of items are always available)
To me that sounds like a processing/storage issue: too many tasks and not enough processors and/or storage units. The network is too busy solving the crafting issues, and no longer gets around to moving objects.
quadrupled amount of processors to 40. Storage about 40 empty 64k drives I think. Issue remains.
I suppose it might be to many tasks and my computer can't keep up.
Sorry to hear that that isn't the solution either... But your computer not keeping up...? That is the last possible conclusion. Nobody wants to hear that their hardware is outdated or can't keep up with them anymore :)
Hm, no CPU core is working on full, plenty of RAM left. Shouldn't be the computer, hard to rule out but there should be resources available for use.
Have you looked at your network? It sounds like you have a really complex network with a lot of power and importing items and moving in general. It's also likely you are powering multiple networks off of one, And probably even more likely you are trying to 1-way storage bus certain networks. Are you sure it's not a network conflict? Have you considered using an interface and item conduits or something equivalent to move the items? 1 block from an interface with extra utilities upgrades and such is quite fast at importing. You can make a singularity in a few seconds if you do it right. Its probably even faster than using ME imports at the benefit of regaining channels. I think once you start trying to do -everything- with AE/ME, things start becoming more complicated than necessary. Considering you can really accomplish a lot more by inserting into interfaces strategically positioned to suck in items at a location, OR a tesserect next to an interface as was mentioned.
For your specific setup, it sounds like it might be a storage issue, or a network conflict. And when I say network conflict you have to consider recursive p2ps, togglebuses, etc. I know a lot of people out there like to make moving AE2 systems, that literally transform their purpose when meeting certain conditions with toggle buses and emitters etc. If your system has a lot of moving parts, (aka channel flipfloping etc.) You have make sure it's not a network issue first. You could for example, be trying to import into a network through a storage bus that is extract only and so it's not able to import into that system because storage is full or there is no storage because the 1way is in favor of the secondary system instead of the primary system where you're manipulating items etc.
This may be a longshot...I ran into a similar issue, but it wasn't based on time. Do you have a security terminal? If I recall, I had to make a general access card for the security terminal that allowed anyone to put items into my network. The ender chest > import bus > interface was having a weird issue and that is how I resolved it.
Makes perfect sense; the chest isn't the player, so may need to be considered a foreign entity. Stuff from foreign entities is suspect, and must therefor not be imported :) (Yeah, I'm cutting that corner very close, I know... :))
They must use some sort of instanceof playerentity check when events get passed for network security, so although in theory it would sound like it makes sense, there's probably something deeper there if it required that to fix the issue. Because a chest would be a BlockEntity and not even a LivingEntity or something if a player check was passed to something. I can't imagine that's something they would overlook since it would compromise the ability to insert any item into a secure system.
In saying that, I have not had any issue using imports on locked me systems. And using ender chests as well, but, our versions might be different etc. Does not mean your issue is not real. You could post some screenshots of the thing that is not working?
I'm not assuming they overlooked anything. I'm assuming that it's intentional. Even though I have no proof of that.
It would not compromise anything at all, I think, if the system ignores block-entities. As long as it doesn't allow any foreign entities - block or player - in, I'd say it's working. It would just require that whoever uses the system, works around any security-like issues such as this, to get the network to work on their own chests, but not at those of others!
But you're right that it could be better. And maybe it's still something completely different. We're just not at the bottom yet.
Its not possible, They can't track by entityblock player names or entity names in general unless those names are given at the times they're created and stay with them through their lifetime and I can tell you that that's not likely. Seeing as how the default minecraft mechanics do not store any names. So you're talking about nameless system that can tell the difference. It's just not there. And to invoke that sort of system goes against what they're purposed those terminals for, and also its not an explained mechanic, so it's totally new to all of us if so.
EDIT: Because, they've made their mod to work without any mods other than AEMod on base minecraft. So unless they care enough to track chests placed by players, they're not going by non-existent blockentity names that relate to the player.
Why would we assume that the system views chests as players? I'm not going there. I only suggested that maybe the system views chests as not the player. Which it would be right about, because blocks aren't players. And since theis chest is not the player, it might be viewed with suspicion...
And I'm not going to assume that they overlooked something or made a big mistake, either. Maybe this was the intention. I'm not yet convinced of the contrary, until one of the author tells me otherwise. I may be wrong, and I may be right, but this is what I think right now.
What I'm saying is that your idea is not physically OR sanely possible based on what this would be like. It's more likely that the OP did something wrong that was fixed unintentionally before he made a modification to the security terminal. The way you're talking about it makes it sound like chests are being treated like entities, but, They would only check for players, because thats what the security terminal does, unless as I said, something deeper is going on, but the assumption that they would treat any block as a non-player entity and check for permissions is insane This is because it would require registering events with the minecraft engine to check for those events and I can't see them consciously putting that in only to find the entities are nameless with comparing against whats in the security terminal. even the catchall idea of the general card would work against the whole "any player" condition not "any entity". But, a look at the code;
package appeng.api.networking.security; public class BaseActionSource { public boolean isPlayer() { return false; } public boolean isMachine() { return false; }
And this code
package appeng.api.networking.security; import net.minecraft.entity.player.EntityPlayer; public class PlayerSource extends BaseActionSource { public final EntityPlayer player; public final IActionHost via; @Override public boolean isPlayer() { return true; } public PlayerSource(EntityPlayer p, IActionHost v) { this.player = p; this.via = v; }
This would suggest that their networking security works, most likely, nothing like what you're saying. Which Is what I'm trying to get across, and I'm telling you based on what i've pasted, it makes completely no sense that a chest would trigger this code.
I keep saying that a chest is NOT a player, and therefor it cannot be THE player either. But you keep reading that I treat the chest as a player. If you can't refrain from putting words in my mouth, then I'm done here. Believe what you will, and have a nice day!
Chest, non-player entity or not, Look at the calls, It will only execute players, ever. Putting words in your mouth? I'm modifying what you're saying because i'm using chest as an example of that foreign entity you referred to. Any non-chest entity would be treated the same, is it a player? Nope, No executed code.
Security is on the server, so there is no way, that a TE itself can do that. The block itself needs to defer its call onto the server side and be evaluated there (which is why its so problematic) to determine if its protected or free to access before-hand
@gixbit I have a rather complex network, I use 2 main tricks. Export bus with level emitters to regulate items I want to keep a large amount of in the network. ME interface with storage bus to hold a small level of items in the network
I have no subnetworks. But my network is very large, for example I have 76 export buses.
I do have some level emitters that trigger export buses almost all the time (enderquarry mines with speed and full power, my level emitters make some export buses export stone so I have at most 100K in the network.)
@Loothor I have a security terminal but have only used it for link my wireless terminal to the network.
I can tell you its network specific. Other networks on the server will still have functioning import buses while another won't.
I have in my world one enormous network and one little network for the ore processing with 23 busses and 10 p2p tunnels for energy, water and item inflow. I am encountering this issue since I updated to rv2 beta 14 and it only happens when the 64k storage in the me chest is full.
Are you suggesting, that you can not import, because your storage is full?
On the processing network with the me chest the export bus stops exporting sometimes when the storage is full.
Our server has around IDK, maybe a dozen large networks and a few small ones. Talking to other players last night, we are sure what when this issue occurs, it is network-specific.
Today I noticed that I could force-reset an entire network by dropping a few extra controllers adjacent to the network's controller-array to make the array invalid...and then break those extra controllers to reboot the network. Things work again for a while. Maybe I'll work up a reset switch with a few piston blocks. :P
ugh.. this sounds like AE1 management xD
I can tell you that, My network is not nearly as hectic as that but, I shift responsibilities to subnetworks. For example, I have 36 alvearies in a random location with a quantum ring on a subnetwork, it gets fed amounts of certain items to make sure it can make its own frames, I do not actually send frames on its own because it also has it's own infinite supply of wood in the area, as well as seeds and so on for making impregnated frames, etc.
By a design like this, I can ensure that my master system can use the items from that system, and that everything is settled handled by micromanaging a smaller network. And I use both imports and exports on security restricted me systems, I have not encountered an issue with things stop importing.
The only time I have ever encountered an issue with exporting and importing items is when the system is part of a sub system or an inventory you're inserting to has a storage bus, similar to storage busing an ME system. At that point if you try to insert into an extract or bi-directional system or inventory, (at least under circumstances I have tested), it will refuse to move the items, this is probably because, when you try to export into some inventories the current priority of that inventory or me system is taken into account, and also currently held items by whichever inventory.
There are certain things you cannot do easily without utilizing separate me systems. For example, crystal accelerators, and automatically crafting quartz stuff, also, making processors without overusing all your silicon and redstone without emitters, but using patterns instead. By a design like this, it can utilize things more intuitively to achieve the same goals as exports and imports and emitters. Interfaces can do pretty much anything in my experience and item conduits can do the rest, IN most cases.
In my experience the current way ae2 runs highly emcourages sub systems.
OK, so import buses aren't the only things that stop working. IO ports stop, interfaces stop - both crafting and creating types. Inscribers get "stuck" - they stop halfway through pressing...they pause with a half-filled progress bar and just sit there.
Reboot network, works for a few min.
In that case it is a feature of AE2, as we will stop ticking additional grids, if it already exceed 50ms of CPU time in the current tick. We probably should turn it into a real queue to ensure every grid is ticked at some point instead of the first come, first served way currently and starving some.
Thanks yueh, whatever the consequence...we'd rather it work slower than not at all if it comes to that.
IMO, I've never considered export and imports to be the end game for moving items. I feel like interfaces would be more efficient as it is these that you can filter items from, move two items from the same pipe. Considering it sounds like your server is using them as the ultimate endgame transport, I would consider that overkill. It's probably easier to pull items with transdimensional receivers or pull with pipes and achieve the same effect. In general the speed of ME, is lacking when you're trying to do multiple items. easier with enderio or etc. I mean, I'm using 390 of them on one me system for autocrafting frames. That's probably overkill too, but, if it wasn't just me and one other guy, I'd try to do it better.
With all due respect @gixbit, I can autocraft Tesseracts, High voltage solar arrays, and Bedrockium drums, just to name a few of the things I got shoved in IDK how many interfaces. All the pulverizing, frame filling, etc, etc. - all automated. I could provide pretty pictures, but I digress. I assure you, I haven't overlooked any loop, any better way etc. I can craft 10 64k storage cells in a snap! (Admittedly because I have two dozen inscribers with level emitters keeping me well supplied with a thousand processors of each type.)
Why? This is minecraft! If you are not overdoing it, you are doing it wrong! That's my mantra.
It was all running great and I concidered it nearly complete. But then, it all went sour unexpectedly.
Several other players on our server are now building their own awesome ae2 networks, and a tipping point has been reached. I turned my network off, completely, so they could actually play.
The hardware this server runs on is an overclocked, liquid cooled, ram-drive using beast. we are lucky for that and...well, only mentioning that part because on hosted gear this issue would have probably come up a LONG time ago.
If what yueh implied is true: Every server tick, ae2 scans all loaded chunks and "ticks" all grids it finds until 50ms has been reached then that's it....then we have a design problem here. That does mean there is a chance that some grids will never be ticked at all...and the behavior will be unpredictable.
I'm not expecting a fix tomorrow. This sounds like a very difficult problem and there is lower hanging fruit, perhaps.
I might be wrong about the tick handling as it has multiple phases. Some things are guaranteed to run each tick. Some can be delayed when the queue exceedes 50ms of processing time, but that is additional time to the previous phases. So nothing actually prevents it from using 100ms per tick. I do not know out of my head which parts will use the additional queue, but I am certain about annihilation planes, ME tunnels and SpatialIO transfers.
But in general nobody was able to provide an AE2 only test setup to verify it. (or reports of TPS issues etc). So in my opinion it can (and most likely is) still be an issue with power, chunk loading etc. I also remember NEI interfere did at one point somehow interfere with DSU and by it also breaking AE2 in some way.
It's pure chaos trying to figure out what mod did what to make things break, injected bytecode etc... As bad as it sounds I dont think minecraft is the best platform for mods like AE2. This is an excellent mod and it would do well in a better place. I would love to see that someday. Independence from minecraft. Many mod devs have gone on to make games. I could imagine this team making a game would be very interesting.
EDIT: It has never interested me to play minecraft after I originally played vanilla. I only play with mods like AE2.
But in general nobody was able to provide an AE2 only test setup to verify it.
Sorry. I know. Just symptoms.
I will try to repro, but ti's going to take some time; a few weeks probably to set up, given the time I have to invest in it. ...but I don't think I could reproduce it with AE2 alone, I'll need a few more things so that I can give ae a lot of stuff to do. I think TE, Mek, and extrautilities should do the job well. (and chickenchunks...and probably a few other essentials)
Which will make the test mostly useless as any of these mod can also cause issues. For example mekanism had an issue with an update cascaded triggered by AE2 (and maybe other mods).
I can recommend activating the UnsupportedDeveloperTools
(ae2 config).
The replicator card for example allows you to copy any SCS and quickly duplicate a single setup multiple times. This will also include the config for any AE2 part, so you can create 1 tillable setup with some export/import buses and create a huge system with it.
If you think vanilla minecraft + AE2 has not enough items, my indev environment with only these has about 7k unique items (each different damaged tool counts as one)
It's not the item count. It's complicated recipes: build a tesseract from raw materials. There is a LOT of crafting going on making a bedrockium drum; it takes 147k cobble to make just one.
also I don't think I can make ae2 busy enough with just ae2+vanilla; one of the things that keeps ae2's import and storage system quite busy is an speed3-upgraded enderquarry or two. or three.
I could probably toss mek out of the mix, but TE and extrautils...I don't see how I could possibly repo this without them.
The amount of items used for crafting something is really irrelevant. There is nearly no difference between extracting 1 cobble or 147k cobble (if stored in the same cell/inventory). Vanilla has not nearly as long crafting chains as modded. But crafting Jack o'Lantern from coal blocks/wood/pumpkins is one of the longer chains in vanilla. Or things like trapped chests, if you want some processing (vanilla furnaces are enough).
Also XU is nowhere near the throughput of AE2. You can easily build system with a throughput of several 100k items per tick (for a few items). Or builds to import 576 different items each tick from a single block, which is really taxing and impossible to achieve with ender quarries.
impossible to achieve with ender quarries.
Challenge accepted. (I'll get back to you, I need some time to set this up.)
Oh, silly question, what's XU?
XU = eXtra Utilities
derp. ty.
http://www.reddit.com/r/feedthebeast/comments/2tmp2w/ae2_interface_and_molecular_setup_for_auto/
I think I'm on to something, emphasis mine.
Unfortunately, I found out during on a survival world about how unusual the pathfinding can be, especially if you have interfaces touching or near one another. Back when I was newer to AE2 I saw some weird things happen that could only be solved by removing and replacing blocks. Everything was in the same place, but replacing reset the pathfinding and forced it to work correctly.
Except I'm not sure about the designs in that reddit thread.
I don't think two assemblers that each "belong" to different interfaces should ever touch.
...and about that, Why on any \world is this allowed to work? (ten assemblers attached to a single interface.)
For some reason my AE network stops importing from my ender chest. It has storage and power so that is not the issue.
When the server starts it imports for a little while and then stops. This could be related to the fact that my ender chest has a rather massive item inflow, essentially everything I want to put into the network comes through it. It gets filled up almost instantly when the network stops.
Is there some other requirement that I should be aware of when it comes to importing items?