Make it so you return a negative integer from the RF API indicating how many times you should call it again to get all the bits. For longs, you'd return -2. Other negative integers would require BigInteger precision (except -1 which would be invalid).

I like to call this negative variant/hack "RF-Big", because it's passing BigIntegers thru the RF API. It's similar to how Unicode/UTF-8 works.

Not the DE dev here, so dont take my word for it. But as an observer of mod dev, and player of DE and other RF mods, this discussion probably belongs in the Cofh API git. Like it was discussed here:

https://github.com/CoFH/Feedback/issues/759

Alternatively, it be a stand alone hack and not part of a content mod like DE. If it was stand alone, all other mod authors can decide if they want to be tied to the performance hit you are proposing.

Enderio said no already: SleepyTrousers/EnderIO-1.5-1.12#2700 (comment)

I'm sure if we pushed it other mods would adapt.

Edit: All EIO said was "we don't need it", which says nothing about what would happen if other mods started doing it. Maybe they'll add it if we add it.

The issue with this is every mod that uses the RF API would have to implement it and that is just not going to happen. It may also cause serious issues with some mods since the api should only ever return a positive number for energy stored (or 0) most mods wont be expecting the possibility of a negative number and it could cause some serious issues.

Edit: One possible solution i am considering for this entire issue is to actually split the storage of the core into multiple separate buffers each of which can be individually accessed by the pylons. The internal buffers would be arranged kind of like partitions on a hard drive where you have a total volume and that volume can be used to create partitions any size you like between 0 and MAX INT. It would also be possible to setup interactions between the buffers allowing you to do things like connect them in series and have them all automatically drain into the next. Basically allowing them to be setup as one big storage buffer which would work similarly to how it dose now. Except that there would be no longs and the energy levels returned by getEnergyStored and getMaxEnergyStored would make sense because they would only be reading the buffer that the pylon is connected to.

Not sure if or when i will do this but it would be one possible solution to this entire problem (for Draconic Evolution at least)

@KingLemming Would like to know what you think of this idea.

Adding the hack will cause crashes, at first, but then the other mods will adapt to it. (or ppl will just stop using your mod, both reduce crashes)

In my opinion that would just be very bad practice. Mod A should not have to change how it uses an api because mod B dose something that the api was never designed for.

You could add it for pushing/pulling only.

At least you'd have to trigger it first (pass in a negative value) and you'd know the caller knows how to handle negative values.

(Transfer speeds of upto 2^63-1 RF/t? why not!)

Because even i dont need to move energy that fast... (and thats really saying something)