View Issue Details

IDProjectCategoryView StatusLast Update
0002483Industrial-Craft²crossmod-compatibility / submodules / APIpublic2019-02-10 03:32
Reporterorangelynx Assigned ToChocohead  
PrioritynormalSeverityminorReproducibilityN/A
Status resolvedResolutionno change required 
Summary0002483: ISemiFluidFuelManager:addFluid amount and power have mixed up types
DescriptionIn the API, the ISemiFluidFuelManager has a function

void addFluid(String fluidName, int amount, double power);

However, I believe amount should be double and power should be integer since per tick only integer valued packets of EU can be generated (32,128,...), whereas 0.5 mB / Tick may be consumed (according to wiki page https://wiki.industrial-craft.net/index.php?title=Semifluid_Generator).
Tags1.12.2, EU, Fluid
Minecraft Version1.12.2

Activities

Chocohead

2019-02-05 01:07

developer   ~0005900

You're slightly misunderstanding how the usage is calculated:

Forge has no way to extract half a mb from a (normal) tank. Thus when the usage appears to be 0.5 mb/t, that works out as 1 mb every other tick in game. Thus the amount is an integer as it is how many ticks the fuel will take to burn before more would have to be extracted. Or to put it another way, how many ticks the fuel burns for.
As for power, it's supported and flows as a double since 1.6.4 therefore even though it might often not be apparent you can have fractional EU. This was so you could have proper loss calculations dropping the EU a little for each cable rather than by 1 after x many cables. Solar panels at sunrise and sunset generate fractional EU to account for the sun being lower in the sky for example, with whole loss turned on in the config it will wait until it's buffered 1 EU before trying to send however. Practically speaking emitting fractional EU is more likely to happen from balance config ratios than something you'd design for, but the value of a fuel could be effected by those configs therefore it uses doubles.

Hope that clears up the logic; the interface is very much designed with practical usage in mind rather than immediately obvious fuel values.

orangelynx

2019-02-05 09:10

reporter   ~0005901

Thanks for the clarification. One thing though: if you say that "amout" is the amount of ticks it takes the generator to burn 1mB, does that mean that the generator cannot consume more than 1mB per tick? Also, if I'm not missunderstanding again, the Javadoc should perhaps be updated to reflect the property more accurately from

"* @param amount amount of fluid to consume per tick"

to

"* @param amount ticks per unit fluid" or something.

orangelynx

2019-02-05 09:54

reporter   ~0005902

I just did a few live experiments. I tested fluids with values (amount, power) as

A = (1, 8)
B = (2, 16)
C = (3, 32)

A fuel cell (1000 mB) of each cell was used up in the same amount of time, but the amount of mB "drawn in" by the generator was in increments of "amount" (for oil, that is 10mB btw). After consuming everything, fuel A produced 8 k EU, B 16 k EU and C almost 32k EU (because 1mB was left stuck in the tank).

Oil produced 8k EU (contrary to what the wiki says (16k EU) on 2.8.110).

So I think my understanding is flawed when it comes to "ticks". I assumed them to be uniform time increments equal for all blocks. But if all fuels A-C were used up in the same time despite having different "amount per tick" values, that does not seem to be the case?

Chocohead

2019-02-08 01:14

developer   ~0005905

I had a look at the usages more carefully and apologise for the confusion, amount works a little differently to how I first described it. At least I got power right ;)

Essentially amount is the minimum amount of fluid needed to start burning/converting, when amount is reached that much will be drained and added as a fuel buffer. Thus it is how many ticks it takes for the fuel to burn whilst simultaneously being how much fluid will be used per intake. Hence the results you saw, C would have drained 3mb every third tick whilst A would have drained 1mb every tick. This is down to the way the semifluid generator works using 1mb every tick to convert for power, technically speaking if you made your own generator you could consume all amount per tick and output all the power at once.
By extension this means you can't control the rate at which fuel is used as it stands, it will always be consumed at 1mb every tick, but it does allow setting a bar for how much fuel you need before it will start burning. The numbers can be balanced out at least that a "faster burning" fuel produces less power per mb than a "slower burning" one.

orangelynx

2019-02-10 01:42

reporter   ~0005911

Thanks for confirmation. I think it would be nice to see a SemiFluid Generator that consumed variable amounts of fluid per tick, allowing "lighter" fuels like Buildcrafts (to be) gaseous fuel to be consumed at a faster rate than say heavy oil.

Perhaps I'll take that as inspiration for another quick-hack addon ;)

can be closed.

Chocohead

2019-02-10 03:32

developer   ~0005912

It shouldn't be too troublesome to allow fuel consumption rate to be changed looking at how things work now, you're welcome to explore the problem (/solution) in the meantime as it will be at least a couple of days until I will be able to get around to it myself.

Issue History

Date Modified Username Field Change
2019-02-05 00:26 orangelynx New Issue
2019-02-05 00:26 orangelynx Tag Attached: 1.12.2
2019-02-05 00:26 orangelynx Tag Attached: EU
2019-02-05 00:26 orangelynx Tag Attached: Fluid
2019-02-05 01:07 Chocohead Assigned To => Chocohead
2019-02-05 01:07 Chocohead Status new => closed
2019-02-05 01:07 Chocohead Resolution open => no change required
2019-02-05 01:07 Chocohead Note Added: 0005900
2019-02-05 09:10 orangelynx Status closed => feedback
2019-02-05 09:10 orangelynx Resolution no change required => reopened
2019-02-05 09:10 orangelynx Note Added: 0005901
2019-02-05 09:54 orangelynx Note Added: 0005902
2019-02-05 09:54 orangelynx Status feedback => assigned
2019-02-08 01:14 Chocohead Note Added: 0005905
2019-02-10 01:42 orangelynx Note Added: 0005911
2019-02-10 03:28 Chocohead Status assigned => resolved
2019-02-10 03:28 Chocohead Resolution reopened => no change required
2019-02-10 03:32 Chocohead Note Added: 0005912