OK. So. Been on the unstable FTB pack before now. Tried a more recent version. Something... something isn't right, and iti s hurting my head to try to figure out. The math... doesn't make sense. Something has to be wrong somewhere.

I started with http://forum.craftersland.net/topic/10815-rftools-endergenic-generator-designed-by-me/ This design I found. It seemed to be the most innocious, simple, hard to screw up one. I went into singleplayer superflat.

I built it, pearl travelling clockwise, starting going north, pearl injector in the south west corner.

Northwest generator: 10, 0 loss.
Northeast generator: 10, 0 loss.
Southeast generator: 10, 0 loss.
Southwest generator: 9, 40-4500 loss.

I built the same thing. Pearl going counterclockwise, sequencers and monitors flipped appropriately.

Southeast generator, 9, 4000 loss.
Northeast generator, 9, 4000 loss.
Northwest generator, 9, 4500 loss.
Southwest generator, 10, 0 loss.

Why. Why is it different?

What's worse, in the clockwise setup, just to find out what the hell was going on, I set every single sequencer to fire IMMEDIATELY on-off-on-off, starting at the first position. Do you know what happened?

Northwest: 2, loss 0.
Northeast, 2, loss 0.
Southeast, 2, loss 0.
Southwest, 1, loss 4000-4500

I tweaked the southeast to southwest connection. Delayed it a tick.. Southwest then became 9, loss 0. That means it isn't landing when it should, somewhere along the lines.

So, I tried tweaking the linked build in the same way. Just delay the problem generator a tick right? THen it's 9/9/9/9 with no loss on any of them. Is there a problem in the code somewhere? Am I missing something obvious? I have a headache...

Tileentities tick in a certain order in a chunk and this endergenic requires very deterministic timing. That's why you can't get reliable results when you (for example) change order or something. It is even possible that timing changes when you place new tile entities in the same chunk as that can change the order in which tile entities a ticked.

Nothing that I can do about it. That's something you have to find out with experimentation

Well once every tile entity is placed down and nothing else is it will remain stable

Or even just... load back in. Like I loaded back in thinking 'OK wait what if I tweak the sequencer priming the original engine' and ran it... laod and behold, the northern two ticked at 7, the southern two ticked at 2. That isn't even a tick out of order, that's just... I don't know. No loss on any of 'em so it's not holding, and all four sequencers are just set to ## on the first one. It's not following any kind of logic! I mean if one of them were off, yeah, tick order, but two in exactly the same way?

I just... don't understand how to get it just right when it keeps changing with no rhyme or reason.

Then why did it change between me closing and re-opening Minecraft again? I mean it's a pack so something might have fucked with the update rate or something as it re-loaded, but... ugh. It should... logically be very simple to do this, with a bit of design and calibration, but... sometimesi tj ust doens't work anything like the way it should. Maybe it'll be less frustrating after some sleep.

Because then it rebuilds the chunk. At that time it will remain stable if you load it again and again. It is not random. It is just undefined

That sounds... very difficult to account for on any kind of long term build. If linking the endergens together made a multiblock, would it tick at the same rate?

I use this setup exclusively with much success. I have noticed anything around the gens will cause them to tick wrong (tile updates and such like pipes) and as such I run this setup extremely efficiently as long as its in one chunk that has very little to nothing else in it. I keep it in my base, but nothing goes in the same chunk.

However you can stack more setups like this. Ive stacked 10 full setups like this ontop of each other piping out the power (100k+ a tick).

Im just saying it does work and is reliable if you keep it isolated. Its the downside/quark of endergens. ( i still prefer them )

If you have issues then try placing this is a void world by itself and see how reliable it is for you. On my heavy/big builds I typically do this and never have any issues.

The list of pearls is not static. This list of pearls is specific for each endergenic tile entity

My mistake. =) Though I'll keep looking for a solution.

I have been having issues with the endergenic generator, so I looked into the code to find the reason.
As you say, the tiles are loaded in a specific order, making it difficult to make a perfect system.

I did find however, that line 350 "handlePearls();" in EndergenicTileEntity.java is called for every tile, while it is working on a static list of pearls accessible to every generator. Meaning that pearls will arrive much faster than predicted at any given generator (when more than 1 generator exists), simply because this code is run multiple times every tick.
This could easily be solved by only running this line of code once every tick instead of once for every generator per tick (checking a time variable or something).

I've worked out a solution, which would negate the issue.
Let the destination handle pearls that are sent to it, instead of the sender.
This just needs a small fix as well, so the destination does not update the pearl, if it was added in the same tick. (check on world tick)

EndergenicTileEntity.java : 575
//pearls.add(new EndergenicPearl(distance, destination, currentAge+1)); TileEntity te = world.getTileEntity(destination); if (te instanceof EndergenicTileEntity) { EndergenicTileEntity endergenicTileEntity = (EndergenicTileEntity) te; endergenicTileEntity.addPearl(new EndergenicPearl(distance, destination, currentAge+1, getWorld().getWorldTotalTime())); } else { Logging.log("Pearl: destination is gone?"); }

EndergenicTileEntity.java : new function
public void addPearl(EndergenicPearl pearl){ pearls.add(pearl); }

EndergenicPearl.java : 16
private final long initiated; public EndergenicPearl(int ticksLeft, BlockPos destination, int age, long initiated) { this.ticksLeft = ticksLeft; this.destination = destination; this.age = age; this.initiated = initiated; }

EndergenicPearl.java : 41
if(world.getWorldTotalTime() == initiated){ return false; } ticksLeft--;

Hope this can be of some use. =)

Will check this out later. Thanks

Just store the tick number the pearl was received in, and only start acting on the knowledge of its appearance in the following tick...
(arriving pearl is put in 'buffer' that remembers when it arrived, and in terms of onTick logic the buffer is considered empty if the pearl arrived in the current tick)
This might break existing builds, but would fix the race condition problem.