View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002483 | Industrial-Craft² | crossmod-compatibility / submodules / API | public | 2019-02-05 00:26 | 2019-02-10 03:32 |
Reporter | orangelynx | Assigned To | Chocohead | ||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | resolved | Resolution | no change required | ||
Summary | 0002483: ISemiFluidFuelManager:addFluid amount and power have mixed up types | ||||
Description | In 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). | ||||
Tags | 1.12.2, EU, Fluid | ||||
Minecraft Version | 1.12.2 | ||||
|
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. |
|
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. |
|
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? |
|
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. |
|
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. |
|
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. |
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 |