Ender IO Forestry

Ender IO Forestry

954k Downloads

[Endergy] Stellar Conduits internal buffer

bpwhelan opened this issue ยท 11 comments

commented

Issue Description:

Stellar conduits are largely unusable due to it's internal buffer. I'm not sure if this is a worthwhile "fix" or change (or even possible) due to how the conduits are already implemented. I also don't know if a fix complies with the overall theme of the mod.

What happens:

Conduit attempts to fill it's internal buffer (which never happens). This leads to conduits being more useful as batteries instead of conduits.

What you expected to happen:

Similar behavior to thermal dynamics' Cryo-Stabilized Fluxduct, where it doesn't have an internal buffer but still transfers when needed.

Steps to reproduce:

  1. Hook up a single stellar conduit to any battery in the game.
  2. Watch it eat all your power.

Affected Versions (Do not use "latest"):

  • EnderIO: 5.0.36
    -Endergy: 5.0.36
  • EnderCore: 0.5.41
  • Minecraft: 1.12.2
  • Forge: 14.23.5.2768
  • SpongeForge? no
  • Optifine?no
  • Single Player
commented

This is Intended Behavior and atm Henry has no plans to change it

commented

This is Intended Behavior and atm Henry has no plans to change it

I assume that it's intended behaviour because the conduit targets machines first, then the buffer. But the problem is when using it with other mods, like mekanisms Quantum Entangloporter, which sets priority based on RF needed.

What happens is when you have two quantum entangloporters, the first one placed will have priority over the second, which makes sense and should work perfectly, were it not for the fact that the first one has to count every single conduit, half a trillion RF in my base, making it nearly impossible to use the quantum entangloporter.

I don't know if you understood what I said so sorry if you didn't, but regardless if this is intended behaviour or not, it's very flawed and it should be at least configurable on the configs.txt in my opinion.

commented

It fills buffer first Then fills machine

commented

It fills buffer first Then fills machine

That's even worse?? So you're telling me that if I want to use a stellar conduit, let's say with a simple setup.

Vibrant Capacitor --> Conduit --> Alloy Smelter

That the conduit will have to fully charge, before charging the machine, so I have to get 2000000RF to even be able to use the machine? The vibrant capacitor doesn't even take that much energy mind you, if that is how it's intended to work, surely you can see the problems with it right?

commented

It fills buffer first Then fills machine

I truthfully don't understand why this is how the energy flow works and is "intended" :\

They're meant to be a conduit (and thus, the transfer of energy) - not a battery - so why do they fill themselves before they fill the destination?

Having the buffer is useful, but it's the prioritization of its internal buffer that's the real issue here IMO. It should prioritize the output devices, not itself. I feel like this doesn't really impact any other conduits currently because their buffers are low, so it doesn't "show" itself as easily.

commented

As the order in which tiles tick is not defined in the game the conduits needs to have a buffer into which a generator can transfer energy. And the conduit itself will transfer energy into all machines.

Let's say a conduit has 1000 FE storage. Then a generator can insert 1000 FE per tick into the conduit to fill the conduit's storage. The conduit itself then can transfer it's 1000 FE into one or more connected machines - emptying it's own storage. This process repeats each tick.

As you can see in this example the conduit storage is what limits the transfer amount - so higher transfer rate => bigger conduit buffer.

commented

As the order in which tiles tick is not defined in the game the conduits needs to have a buffer into which a generator can transfer energy. And the conduit itself will transfer energy into all machines.

Let's say a conduit has 1000 FE storage. Then a generator can insert 1000 FE per tick into the conduit to fill the conduit's storage. The conduit itself then can transfer it's 1000 FE into one or more connected machines - emptying it's own storage. This process repeats each tick.

As you can see in this example the conduit storage is what limits the transfer amount - so higher transfer rate => bigger conduit buffer.

Uhm I did not know that, but if so, then why not do it like the thermal expansion infinite flux duct? Or something similiar? Surely there has to be a way to make it actually usable.

commented

i had the problem to but the storage is the max output

commented

This makes the cables really annoying to use, as it starts to eat and sink all of your energy into cables which makes the rest of your connected devices be starved for energy.

commented

More than annoying, it makes them almost impossible to use. I just got done converting my base to them, and then spent the last 2 hours troubleshooting my base to figure out why i had no stored power anywhere. Conduits shouldn't be acting like batteries, especially if we can't see their internal buffer. It makes the whole network impossible to visualize and troubleshoot properly. Please fix these conduits as Ender IO energy conduits are amazing, but this forces me to use fluxducts for high throughput power.

commented

I have no problem in ATM 3: Remix, it would drain buffer into devices that needed power... It would drain my generator's buffers until I maxed it out. The only annoyance is the conduit probe states the max storage is 2^31 - 1 and it is more than that.