MCP v9.05
FML v7.10.99.99
Minecraft Forge 10.13.4.1492
Calculator 1.8.3

https://drive.google.com/file/d/0B_wljXPJi507VUNCY2VWNnRldFU/view?usp=sharing

The Flux Plug and Flux Point doesn't seem to transfer any energy on the network it's assigned to... In fact, it doesn't seem to work at all. You can see in the video, I tried to transfer RF into a capacitor bank and none went through. You can also see that the Flux Plug says that the only Flux Point is receiving 20.5 kRF.

What modpack is that?

It's my custom modpack.

you don't have it uploaded anywhere?
It looks neat. I'd like to check it out.

yeah can replicate, Flux Plug on a Vibrant Capacitor from EnderIO would just crash the server immediately even if the sides are configured to only output.

@n2ation could you possible post the crash report?

Description: Ticking block entity

java.lang.ArrayIndexOutOfBoundsException: 16
at sonar.calculator.mod.common.tileentity.misc.TileEntityFluxPlug.receiveEnergy(TileEntityFluxPlug.java:311)
at cofh.thermalexpansion.block.cell.TileCell.transferEnergy(TileCell.java:201)
at cofh.thermalexpansion.block.cell.TileCell.func_145845_h(TileCell.java:162)
at net.minecraft.world.World.func_72939_s(World.java:1939)
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:489)
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:636)
at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:334)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:547)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:427)
at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685)

A detailed walkthrough of the error, its code path and all known details is as follows:

-- Head --
Stacktrace:
at sonar.calculator.mod.common.tileentity.misc.TileEntityFluxPlug.receiveEnergy(TileEntityFluxPlug.java:311)
at cofh.thermalexpansion.block.cell.TileCell.transferEnergy(TileCell.java:201)
at cofh.thermalexpansion.block.cell.TileCell.func_145845_h(TileCell.java:162)

-- Block entity being ticked --
Details:
Name: thermalexpansion.Cell // cofh.thermalexpansion.block.cell.TileCell
Block type: ID #3097 (tile.thermalexpansion.cell // cofh.thermalexpansion.block.cell.BlockCell)
Block data value: 4 / 0x4 / 0b0100
Block location: World: (51,94,-129), Chunk: (at 3,5,15 in 3,-9; contains blocks 48,0,-144 to 63,255,-129), Region: (0,-1; contains chunks 0,-32 to 31,-1, blocks 0,0,-512 to 511,255,-1)
Actual block type: ID #3097 (tile.thermalexpansion.cell // cofh.thermalexpansion.block.cell.BlockCell)
Actual block data value: 4 / 0x4 / 0b0100
Stacktrace:
at net.minecraft.world.World.func_72939_s(World.java:1939)
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:489)

it also crashes with Thermal expansion Energy Cells.

I have 16gb and 1.8 64bit java. I just downloaded it and i'll get back to you with a review.
It looks really nice. Thanks for the download!!

Hey @Badcholo sorry for the big delay. Here's my custom modpack if you're still interested in trying it out. Let me know when you have it so I can disable the link.

https://drive.google.com/file/d/0B_wljXPJi507S0tGNUxlbTVZQ3c/view?usp=sharing

As usual, allocate more RAM to Minecraft and use 64-bit Java if possible. I allocate 6GB and use 64-bit Java 1.8.0_65.

Can I join to this community? 😄 I getting nearly same exception, except the ArrayIndexOutOfBoundsException says 8 not 16. It happens with EnderIO conduits and Flux Plugs (it does not crash the server since EIO prevents this) and also with ImmersiveEngineering HV capacitors and Flux Plugs. Flux Points - as i saw - not affected here.

Also I'd like to put a reference to SleepyTrousers/EnderIO-1.5-1.12#2804

@SonarSonic can you make it work with your Advanced Power Cubes?

Everyone try updating to 1.8.5, still not able to transfer power but it won't crash now...http://minecraft.curseforge.com/projects/calculator/files/2263785

Wasn't aware it didn't I will let you do that in the next update :)

^^^ this config works. make sure you shift right click on the side where the flux plug is so that the Advanced Power Cube is sending that way.

sounds good, I'll check it tonight. I also hope flux points will interact w/ capacitor banks too as we do not have Thermal Expansion in our pack, only EIO.

Okay i've done it. I'll post an update soon and i'll see what you think

If I loose 100-200 RF from the buffer, it's seems acceptable for me, but there are some techniques to keep the energy in NBT (at cost flux points will not stack anymore)...

Ohh, I noticed your new comment just now... I'm very excited!

I think it's fine if you need a buffer item like an Advance Power Cube for the Flux Plugs ( it works as buffer just as described), since you usually only need 1 to draw power from your storage, the rest should be Flux Points, as long as those work and feed machines and such just fine I think no modification is needed.

The new gui will display buffer at the top (for the whole network)

Remaining buffer when destroyed will be added back to the network. if not all can be added it will be stored on the stack which is dropped. When connected back to the network it will add back any previous power

Sounds cool. If you make an obfuscated jar I can do a hard test this weekend.

@hron84 there is a workaround for that, but I've been avoiding it as it would involve having an Energy Buffer on the Flux Plug. At the moment no energy is stored in the system at any time. The other option is to change the whole sending system, which may make things a bit more laggy. Any ideas?

i sugest a more request based system, each tick you aquire on each receiver how much energy the connected machine accepts, store that in the network

next tick you first try to provide that power to the machines and recalculate how much energy they want

When you say store, do you mean actually storing the energy as in removing it, or saving how much can be given calculating how much is needed then accepting that exact amount on the next tick? Either way how much should be allowed to pass at once do you think?

saving how much it wants and then the next tick first calculate how much you can get, then transfer the energy, clear the maps that save it and then do it all over again

@SonarSonic you misunderstood me. I think Flux point should interact with capbanks like any power transferring pipe/conduit does, check the requirements and transfer the requested energy. @AEnterprise 's solution sounds great for me, this is what I expect from the system at the user side.

yeah It would be better if it was normal. but then i'd lose control over the network. The advantage Flux Networks have over tesseracts etc is that each network is run via one block instead of loads of blocks all sending. It gives me way more control over where energy goes and how fast it goes etc, but does cause other problems to sadly. @AEnterprise 's method does work though it just is less efficient then being able to pull directly from nearby handlers

And what is the disadvantage of having a small buffer in flux points? If I read correctly it popped up in the tread previously, but - as I'm not a mod developer - I don't understand why this idea became discarded. If you have a static, but relative small (or configurable) buffer, you can keep the control of the RF flow, as you can still measure how much energy drained from the buffer but you will have a possibility to be compatible with RF API users.

The same amount of energy might not be needed on the next tick meaning you have energy which isn't doing anything. When the plug is destroyed energy could be lost from the buffer. Those are the main problems.

should be good in latest version

@SonarSonic cool, I'll check it anyway, I plan to hard test it in this weekend and report if we face with any issue. Hopefully you will never hear me anymore :-)

First off - Good Song
Are you sure your putting energy into the plug? The totals say that it isn't getting any. The total on the right is for the maximum it could receive not how much it is actually receiving. It could have been charging your inventory without you realising? Perhaps also try breaking all the blocks and putting them back. If this works I have a good idea what it could be.

Yes, that red crystal-looking thing with the glowing orb on it (Draconic Evolution's Energy Transceiver) is supplying RF to the conduit network which my Flux Plug is connected to. The Flux Plug is actually right next to the Transceiver.

I just made a superflatworld to test with just CoFHCore, Thermal Foundation, Thermal Expansion, Thermal Dynamics, and Ender IO. It looks like the Flux Network functions properly with Thermal Expansion items like energy cells and it doesn't function at all with Ender IO capacitor banks and energy conduits.

https://drive.google.com/file/d/0B_wljXPJi507dlY3T2d2WENsYUU/view?usp=sharing

Okay I'll need to look into this. :)

Oh dear. Well, that's fine. I think the best workaround is just to use Thermal Dynamics fluxducts as a medium between Ender IO and Calculator. Thank you for such a fun mod!

On a side note, I started a brand new modpack with Calculator included, so I won't really be able to test it or find more bugs until I get endgame again (currently early game).

a possible workaround would be to use the receive energy function of the rf api with simulation of a huge number to see how much energy it would accept and to then try to give it that energy

the difficulty is how the energy is managed. To prevent lag the method is run from a single Flux Plug which is allocated as the master, which goes through every block on the network individually this allows for all the different transfer settings for the entire network. This also means the receiveEnergy function is hard to integrate. Any ideas would be appreciated though :) https://github.com/SonarSonic/Calculator/blob/master/sonar/calculator/mod/common/tileentity/misc/TileEntityFluxPlug.java

you could when going through the network before transfering energy have each node ask how much energy can be accepted with the simulation of the RF api, another option would be to work with a adjustable buffer, connection holds a small amount of RF that it tries to push each tick, if all energy is used up it increases it's buffer, if not all energy is used it decreases it

Could work, if there was an easy way to work out if I can draw power from the handler or not. Otherwise the network would pull power and it would send it therefore doubling output

Okay there is no easy solution to this other than if EnderIO change some of there main classes. Due to the way I send/receive energy it's pretty difficult to fix it. This is because EnderIO blocks don't let you directly alter their stored energy. Leave it with me...